Re: [sipcore] [Technical Errata Reported] RFC3261 (2910)
Romel Khan <[email protected]> Thu, 4 Aug 2011 15:09:14 -0400
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <CAFQP3_afcp=COozZqB+g39LU3XVtYi-tSrxCuyZkOLWbNVasfw@mail.gmail.com> |
--===============6977431422514553146== Content-Type: multipart/alternative; boundary=90e6ba6135a8a9886e04a9b2b804 --90e6ba6135a8a9886e04a9b2b804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So it is useful if one of UAS or UAC requires it, but it does not have to b= e mandatory. Some comments: -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems logical to me that it needs to be made clear in this RFC3261 that early dialog must mean Contact and Record-Route (if Record-Route was received in INVITE) headers is mandatory in 1xx without reference to 100rel. -- A UAS could always send 1xx with headers that are required for early dialog but it doesn't have to enforce 100rel (eg because the origination or UAS side itself may not support reliable provisional response handling, or reliable provisioning not really required for its operation). UAS could sen= d "support:100rel" if it supports it, or it would not send it if it doesn't support this. In my opinion, if UAC hasn't sent 100rel required, it should be up to the UAS to decide whether to enforce 100rel (with "required:100rel") if its application really requires SIP requests before call answer. If the origination side (UAC) side has a need to send early requests, like UPDATE, then the UAC should require 100rel from the termination side (UAS) by sending this in INVITE. In a VoIP service provide= r world, these kind of capabilities are configured during interconnect turn up. -- I notice that some vendors gateway implementations, even if gateway is the termination side, require 100rel for the gateway to receive pre-answer requests such as UPDATE. This really didn't have to be this way. I have always seen these gateways, when it is the termination side, respond back SIP 183 with the headers that create early dialog. So if the origination side received the SIP 183 response, then there is no reason for the origination side to now not be able to send UPDATE request. Also, no reason for the termination gateways to not accept the SIP UPDATE without requiring PRACK. Thanks. On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks <[email protected]> wrote= : > (removing the rfc-editor and trimming the distribution to the lists) > > On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote: > > > 2011/8/2 Robert Sparks <[email protected]>: > >> Further, they're only going to make sense for 1xx that is sent using > 100rel. > > > > This has been discussed in sip-implementors, and that assertion seems > > incorrect. As I've reported in the errata: > > > > > > Section 12.1: "Dialogs are created through the generation of > > non-failure responses to requests with specific methods. Within this > > specification, only 2xx and 101-199 responses with a To tag, where the > > request was INVITE, will establish a dialog." > > > > Section 12.1.1: "When a UAS responds to a request with a response that > > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all > > Record-Route header field values from the request into the response > > [...]. The UAS MUST add a Contact header field to the response." > > > > So it's clear that a 1xx response to an INVITE creates a dialog and > > then it MUST contain a Contact header and mirrored Record-Route > > headers, *regardless* the usage of 100rel. > > > > Am I wrong? if so, why? > > Not wrong, just incomplete. This will create an (early) dialog at the UAS= . > It may or may not create a dialog at the UAC without 100rel since the > message may never get to the UAC. Where I said "make sense" above, > it might have been better if I had said "be useful". > > > > > Regards. > > > > > > -- > > I=F1aki Baz Castillo > > <[email protected]> > > _______________________________________________ > > sipcore mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is essentially closed and only used for finishing old business. > Use [email protected] for questions on how to develop a SI= P > implementation. > Use [email protected] for new developments on the application of sip. > Use [email protected] for issues related to maintenance of the core SIP > specifications. > --90e6ba6135a8a9886e04a9b2b804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So it is useful if one of UAS or UAC requires it, but it does not have to b= e mandatory. Some comments:<div>-- RFC3261 mentions early dialog without me= ntioning RFC3262. Then it seems logical to me that it needs to be made clea= r in this RFC3261 that early dialog must mean Contact and Record-Route (if= =A0Record-Route was received in INVITE) headers is mandatory in 1xx without= reference to 100rel.</div> <div><br></div><div><div>-- A UAS could always send 1xx with headers that a= re required for early dialog but it doesn't have to enforce 100rel (eg = because the origination or UAS side itself may not support reliable provisi= onal response handling, or reliable provisioning not really required for it= s operation).=A0UAS could send "support:100rel" if it supports it= ,=A0or it would not send it if it doesn't support this.=A0In my opinion= ,=A0if UAC hasn't sent 100rel required,=A0it should be up to the UAS to= decide whether to enforce 100rel (with=A0"required:100rel")=A0if= its application really requires SIP requests before call answer. If the or= igination side (UAC) side has a need to send early requests, like UPDATE, t= hen the UAC should require 100rel from the termination side (UAS) by sendin= g this in INVITE.=A0In a VoIP service provider world,=A0these kind of capab= ilities are configured during interconnect turn up. =A0</div> <div><br></div><div>-- I notice that some vendors gateway implementations, = even if gateway is the termination side, require 100rel for the gateway to = receive pre-answer requests such as UPDATE. This really didn't have to = be this way. I have always seen these gateways, when it is the termination = side, respond back SIP 183 with the headers that create early dialog. So if= the origination side received the SIP 183 response, then there is no reaso= n for the origination side to now not be able to send UPDATE request. Also,= =A0no reason=A0for the termination gateways to not accept the SIP UPDATE wi= thout requiring PRACK. =A0=A0</div> <div><div><br></div><div>Thanks.</div><div><br><div class=3D"gmail_quote">O= n Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]">[email protected]</a>></span> wrote:= <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">(removing the rfc-editor and trimming the d= istribution to the lists)<br> <div class=3D"im"><br> On Aug 2, 2011, at 5:24 PM, I=F1aki Baz Castillo wrote:<br> <br> > 2011/8/2 Robert Sparks <<a href=3D"mailto:[email protected]">rjs= [email protected]</a>>:<br> >> Further, they're only going to make sense for 1xx that is sent= using 100rel.<br> ><br> > This has been discussed in sip-implementors, and that assertion seems<= br> > incorrect. As I've reported in the errata:<br> ><br> ><br> > Section 12.1: "Dialogs are created through the generation of<br> > non-failure responses to requests with specific methods. Within this<b= r> > specification, only 2xx and 101-199 responses with a To tag, where the= <br> > request was INVITE, will establish a dialog."<br> ><br> > Section 12.1.1: "When a UAS responds to a request with a response= that<br> > establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all<= br> > Record-Route header field values from the request into the response<br= > > [...]. The UAS MUST add a Contact header field to the response."<= br> ><br> > So it's clear that a 1xx response to an INVITE creates a dialog an= d<br> > then it MUST contain a Contact header and mirrored Record-Route<br> > headers, *regardless* the usage of 100rel.<br> ><br> > Am I wrong? if so, why?<br> <br> </div>Not wrong, just incomplete. This will create an (early) dialog at the= UAS.<br> It may or may not create a dialog at the UAC without 100rel since the<br> message may never get to the UAC. Where I said "make sense" above= ,<br> it might have been better if I had said "be useful".<br> <div class=3D"im"><br> ><br> > Regards.<br> ><br> ><br> > --<br> > I=F1aki Baz Castillo<br> > <<a href=3D"mailto:[email protected]">[email protected]</a>><br> > _______________________________________________<br> </div>> sipcore mailing list<br> > <a href=3D"mailto:[email protected]">[email protected]</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/sipcore" target=3D"_b= lank">https://www.ietf.org/mailman/listinfo/sipcore</a><br> <div><div></div><div class=3D"h5"><br> _______________________________________________<br> Sip mailing list =A0<a href=3D"https://www.ietf.org/mailman/listinfo/sip" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/sip</a><br> This list is essentially closed and only used for finishing old business.<b= r> Use <a href=3D"mailto:[email protected]">sip-implementors@cs= .columbia.edu</a> for questions on how to develop a SIP implementation.<br> Use <a href=3D"mailto:[email protected]">[email protected]</a> for new deve= lopments on the application of sip.<br> Use <a href=3D"mailto:[email protected]">[email protected]</a> for issues rel= ated to maintenance of the core SIP specifications.<br> </div></div></blockquote></div><br></div></div></div> --90e6ba6135a8a9886e04a9b2b804-- --===============6977431422514553146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP specifications. --===============6977431422514553146==--