Hi, I've changed the name of this thread, because I think the scope is wider than 199 :)
Regards, Christer -----Original Message----- From: Ian Elz Sent: 6. elokuuta 2008 16:51 To: Paul Kyzivat Cc: Christer Holmberg; SIP IETF Subject: RE: [Sip] Comments on draft-ietf-sip-199-00.txt Paul, I only included 'early dialog' as this is the term that is already used. We cannot criticize RFC 3261 for this as when it was written INVITE was the ONLY dialog creating transaction. Should some input be given to Robert Sparks' invfix draft as it is proposing corrections to the INVITE transaction state machines. Based on the existing draft (-02) sending or receiving a 1xx response places the transaction in the 'proceeding' state which is does not exit until a final response has been sent or received, or I assume the dialog/usage terminates. If we retain the state model of proposed in invfix then the 199 response should be treated as an invitation to the UAC to terminate the early dialog usage with a BYE method. If this does not happen the transaction will remain as 'proceeding' and the early dialog usage may also remain. The alternative is to modify the proposed transaction state models for special handling for the 199 response. This is something which I am not sure that I would favour. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 [EMAIL PROTECTED] -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 06 August 2008 13:25 To: Ian Elz Cc: Christer Holmberg; SIP IETF Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt Ian Elz wrote: > Paul, > > I don't believe that you can create 'multiple early dialog usages'. > > On an INVITE transaction can create an early dialog. The other dialog > creating transactions REFER and SUBSCRIBE, can only create established > dialogs. > > As you cannot start a second INVITE transaction while there is an > outstanding INVITE transaction on a dialog, early or otherwise. > > If you send a REFER or SUBSCRIBE method on an early dialog and you get > an acceptance response then you have an established dialog. Agreed. I should have pointed that out. However, the issue arises if you can get an early invite dialog usage with a confirmed dialog usage. In that case one must be careful with the rules to ensure that you don't accidentally terminate the confirmed usage as a side effect of processing the 199 on the early invite dialog usage. > If this is the early-dialog from an INVITE transaction then key question > is what is the validity of a provisional response in creating a dialog. > Is it early or established. While the provisional response is clearly > just that from a transaction perspective in this situation the meaning > of the proposed 199 provisional response is now transaction affecting > and not dialog affecting, i.e. the INVITE usage will not become > established although the other usage may be established. > > The existing state models in sip only discuss dialogs and transactions > and have not considered the dialog usage. When you send a reliable > provisional response to an INVITE you are in effect creating an > early-dialog usage. If this is the only dialog usage on the dialog you > have also created an early-dialog. If there is another usage on the same > dialog then the dialog state will depend upon the state of the other > dialog. IMO there really shouldn't be any "early dialog", ever. The dialog comes into existence, and departs, based on the existence of at least one usage. The dialog is the same whether the usages are early or late, or a combination. I agree that it would be helpful to recast all the state machines in terms of dialog usages rather than dialogs. Maybe that is a job for the draft standard version of 3261. > RFC5057, Multiple Dialog Usage (informational) does not discuss the > details involved in multiple usages and the impact on the sip state > models but I hope that this was a consideration when the initial drafts > were prepared. > > I am unsure if the concept of multiple usages on an early dialog was > ever considered when RFC5057 was in draft stage. The nuances of multiple > dialogs on an established dialog appears to have been enough to suggest > that the RFC specifically not recommend multiple usages without getting > into the 'dark area' of early dialogs and multiple usages. > > Whether it make sense to use a REFER or SUBSCRIBE inside an early dialog > is problematic. I am unsure whether these do make any sense. Would you > want to subscribe to specific event which occurs during the early dialog > phase of an INVITE transaction? Would you want to use REFER to perform a > transfer of a ringing call and does the protocol actually support this? > > If the answer to these questions is a definitive 'NO' then the issue > will have resolves itself. I fear however that there is no definitive > answer at this time. Right. Paul > Ian Elz > > System Manager > DUCI LDC UK > (Lucid Duck) > > Office: + 44 24 764 35256 > gsm: +44 7801723668 > [EMAIL PROTECTED] > > > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 05 August 2008 15:21 > To: Christer Holmberg > Cc: SIP IETF > Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt > > > > Christer Holmberg wrote: >> Hi, >> >>>> 7) Section 7: "A UAC that receives a 199 response for an early > dialog >> MUST NOT >>>> send any further requests on that dialog...". Can you point to any >> list discussion >>>> around this requirement? I think there's some danger to consider >> there. At the >>>> very least we need to make this statement multiple-usage safe. >>> This is a very good catch. This needs to be aligned with dialogusage. >> If the 199 contained the final response that triggered it, then that >> final response could be used to determine the impact >>> on the dialog or dialog usage or just the transaction. But if the 199 >> doesn't contain the final response, then this is a problem. >> >> I forgot to bring this issue up in Dublin. Sorry for that. >> >> First, we need to remember that the UAS may terminate every > dialogusage >> when sending the final response (depending on what final response is >> sent), without the UAC knowing it. And, due to the forking rules, the >> final response which is sent to the UAC may not even be the same which >> was sent by the UAS, if a final response from another UAS is chosen as >> the "best". >> >> Second, we need to remember that this only affects early-dialogusages. >> >> If needed, I guess we could include the final response which triggered >> the 199, but we could also simply say that if the UAC does not know to >> which dialogusage (if there are many) the 199 applies, it should not > do >> anything which may affect other usages for the same early dialog. > > The establishment of multiple early dialog usages is a pretty strange > thing. Do we know of any use cases for this? (E.g. an in-dialog REFER on > > an early INVITE. Is that legal?) > > Assuming it can arise, then I agree it is reasonable to treat the 199 as > > affecting only its dialog usage unless there is info with it (such as > the actual final response code) that gives evidence that the whole > dialog is gone. > > Thanks, > Paul > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
