Robert, The work relating to multiple dialog usages may in time remove the requirement to have multiple usages on the same dialog. Due to the issues relating to B2BUAs which were briefly discussed in draft-marjou-sipping-b2bua-01 and the mapping of the dialog reference headers (Replaces, Target-dialog, Join and In-Reply-To) through B2BUAs I don't believe that we can totally remove multiple dialog usages until this handling is resolved.
The rejection of the sipping wg of this draft from forming part of the charter will result in the deployment of solutions using multiple dialog usages as use of an existing dialog will be the only way to ensure routing of requests where reference to an existing dialog is required, e.g. your example of subscribing to the dialog event package. The current problem is that the existing sip specification does not take account of multiple dialog usages and there are deployments which cannot successfully handle this case. To change the sip model to account for multiple usages is not in itself difficult but to make it backward compatible with existing implementation is the major challenge. As my major focus is IMS the use of B2BUA is pretty much a given. The issue with routing when the dialog reference headers are used needs to be resolved before it is possible to send requests on new dialog. In the current situation there is no option except to use multiple dialogs with all the issues that these create. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 [EMAIL PROTECTED] -----Original Message----- From: Robert Sparks [mailto:[EMAIL PROTECTED] Sent: 15 August 2008 22:19 To: Ian Elz Cc: Paul Kyzivat; Christer Holmberg; SIP IETF Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt It's my hope that the work related to avoiding multiple usages will make this an entirely academic discussion. On the chance that turns out to be untrue, however, the one place I can see this coming up more quickly than elsewhere is if a UAC decides it wants to subscribe to the dialog event package at each UAS that provisionally responds to its INVITE and decides to reuse the dialog identifiers that provisional response established. RjS On Aug 6, 2008, at 6:09 AM, 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. > > 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. > > 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. > > 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 _______________________________________________ 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
