The issue here is UAS may send 199 to terminate early-dialog with the intention to help UAC claiming resource May bring unexpected overhead (case 1 && 2 as in Paul's mail) or confusion (case 1 in Paul's mail, ordered to terminate non-existed early-dialog)
Thanks Rockson -----Original Message----- From: Paul Kyzivat (pkyzivat) Sent: Monday, June 16, 2008 8:18 PM To: Christer Holmberg Cc: Rockson Li (zhengyli); [email protected] Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt I don't understand the problem here. If the UAC receives the 199 as the first provisional response in a new dialog, then it will in effect create a new dialog and then immediately terminate it based on the 199. If the UAC doesn't understand the new semantics of 199 then it will treat it as an arbitrary 1xx response, and create a new dialog that then will have to time out. But that is no different than if the 18x response had not been lost. Paul Christer Holmberg wrote: > Hi Rockson, > > Ok, now I understand. You are talking about the case where the UAC > doesn't receive the 18x, and then gets confused when it receives the > 199. That can happen no matter whether it's a proxy or UAS that sends > the 199. > > I guess that is something which could happen, yes, and a UAC could > think a new early dialog has been created. As you say, a way to avoid > it would be to send at least one of the 18x reliable before a 199 is sent. > > But, I am not sure we want to mandate that, because I don't think > anything will break if this happens. > > Regards, > > Chrsiter > > > > ---------------------------------------------------------------------- > -- > *From:* Rockson Li (zhengyli) [mailto:[EMAIL PROTECTED] > *Sent:* 16. kesäkuuta 2008 4:51 > *To:* Christer Holmberg; [email protected] > *Subject:* Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > > Hi Christer, > > It would be easier for UAS to tell if it sends non-100 1xx response > creating early-dialog before sending 199. > However, it's a little bit difficult from UAC's perspective, since the > non-100 1xx response might not be reliable. > > If UAC does not get , say 180, but get 199 first, it looks like it > does not make any sense. > > One option is to mandate usage of 100rel, which might be too strict > for this draft. > > Regards, > -Rockson > ---------------------------------------------------------------------- > --------------------- > Date: Sun, 15 Jun 2008 13:52:24 +0200 > From: "Christer Holmberg" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > To: "Rockson Zhengyu Li" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>, <[email protected] <mailto:[email protected]>> > Message-ID: > > <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] > sson.se>> > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > You wouldn't send a 199 unless you have already sent a non-100 1xx > response, so the early dialog has already been created. > > Regards, > > Christer > > ________________________________ > > From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > [mailto:[EMAIL PROTECTED] On Behalf Of Rockson Zhengyu Li > Sent: 15. kes?kuuta 2008 14:43 > To: [email protected] <mailto:[email protected]> > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > > > Hi, > > > one questions on this draft. > > > Since RFC3261 says, non-100 1xx response for INVITE cause early-dialog > creation. > does this draft will normativly change the criteria, excluding 199? > > > If, the answer is Yes, I think it need be stated explicitly in the draft. > > > > thanks > > > Regards, > -Rockson > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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
