Hi, >>>>I've changed the name of this thread, because I think the scope is wider than 199 :) >>>Perhaps. But I don't think there is much to discuss. >>> >>>It seems clear that we don't have any way to cause a dialog with >>>*multiple* *early* dialog usages. This is because only an >>>invite-dialog-usage can be early, and you can only have one of those >>>per dialog. >>> >>>It seems technically possible to have a dialog that has both an early
>>>dialog usage and a final dialog usage. There may be question of >>>whether there is practical value in this, but for now I will simply >>>assume it is possible. We can discuss if it might not be possible, or >>>if it should be declared so, but I don't know if we need to. >>> >>>RFC 5057 addresses the impact of responses on the state of >>>transactions, dialog usages, and dialogs. The interesting question is >>>whether the proposed 199 response would require some alteration to >>>5057. The reason its interesting is because the 199 is effectively a >>>final response in disguise. But that brings it back to something that >>>ought to be discussed on the 199 thread. >> >>So, from a 199 point of view I guess the only thing we can do at the moment is to provide some text and say that care shall be taken when multiple dialogusages exist, and the 199 doesn't >>provide more information. >> >>think it is extremely rare that one would first establish a subscription dialog, and then send an INVITE and create an early invite usage within that dialog. I would even dare to say that no >>such implementations exist today, but I can of course be wrong... > >Agreed. I think the most likely way to get into the situation is to send a SUBSCRIBE, or more likely a REFER, within a dialog resulting from an early invite dialog usage. The REFER case may >actually be plausible. > >>As imentioned earlier, I also think it's not a good idea to create subscription usages within an early INVITE dialog. In case of forking you may send SUBSCRIBE to all UASes, and when some >>sends 200 OK for the INVITE you may have to unsubscribe to all the other UASes. etc etc. > >I can't think of a likely use for SUBSCRIBE. > >>And, because of all issues described in RFC 5057, I hope people won't define such use-case in future either. > >If we can find no deployed usages, we might take the opportunity to simply ban them. Yes. Something for the fix-the-bugs documentation work the WG has been discussing? Also, when we now have decided to start working on the info packages, people will have a choise to use those instead for early in-dialog cases (and in-dialog cases in general). 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 > _______________________________________________ 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
