Re: [sipcore] [Technical Errata Reported] RFC3261 (2910)

--===============2422714513332443738==
Content-Type: multipart/alternative; boundary=0016e651395e5c1e0e04a9d53095

--0016e651395e5c1e0e04a9d53095
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 04/08/2011 21:09, "Romel Khan" <[email protected]> escribi=C3=B3:
>
> So it is useful if one of UAS or UAC requires it, but it does not have to
be mandatory. Some comments:
> -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seem=
s
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 yin INVITE. In a VoIP service
provider 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.

I entirely agree with it. And I also think that the fact that a 1xx respons=
e
without 100rel is not reliable does not mean that it does not create a
dialog so Contact and RR are required.

--0016e651395e5c1e0e04a9d53095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><br>
El 04/08/2011 21:09, &quot;Romel Khan&quot; &lt;<a href=3D"mailto:romel.kha=
[email protected]">[email protected]</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; So it is useful if one of UAS or UAC requires it, but it does not have=
 to be mandatory. Some comments:<br>
&gt; -- RFC3261 mentions early dialog without mentioning RFC3262. Then it s=
eems logical to me that it needs to be made clear in this RFC3261 that earl=
y dialog must mean Contact and Record-Route (if=C2=A0Record-Route was recei=
ved in INVITE) headers is mandatory in 1xx without reference to 100rel.<br>

&gt;<br>
&gt; -- A UAS could always send 1xx with headers that are required for earl=
y dialog but it doesn&#39;t have to enforce 100rel (eg because the originat=
ion or UAS side itself may not support reliable provisional response handli=
ng, or reliable provisioning not really required for its operation).=C2=A0U=
AS could send &quot;support:100rel&quot; if it supports it,=C2=A0or it woul=
d not send it if it doesn&#39;t support this.=C2=A0In my opinion,=C2=A0if U=
AC hasn&#39;t sent 100rel required,=C2=A0it should be up to the UAS to deci=
de whether to enforce 100rel (with=C2=A0&quot;required:100rel&quot;)=C2=A0i=
f its application really requires SIP requests before call answer. If the o=
rigination side (UAC) side has a need to send early requests, like UPDATE, =
then the UAC should require 100rel from the termination side (UAS) by sendi=
ng this yin INVITE.=C2=A0In a VoIP service provider world,=C2=A0these kind =
of capabilities are configured during interconnect turn up. =C2=A0<br>

&gt;<br>
&gt; -- I notice that some vendors gateway implementations, even if gateway=
 is the termination side, require 100rel for the gateway to receive pre-ans=
wer requests such as UPDATE. This really didn&#39;t have to be this way. I =
have always seen these gateways, when it is the termination side, respond b=
ack SIP 183 with the headers that create early dialog. So if the originatio=
n side received the SIP 183 response, then there is no reason for the origi=
nation side to now not be able to send UPDATE request. Also,=C2=A0no reason=
=C2=A0for the termination gateways to not accept the SIP UPDATE without req=
uiring PRACK. =C2=A0=C2=A0</p>

<p>I entirely agree with it. And I also think that the fact that a 1xx resp=
onse without 100rel is not reliable does not mean that it does not create a=
 dialog so Contact and RR are required.</p>

--0016e651395e5c1e0e04a9d53095--

--===============2422714513332443738==
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.
--===============2422714513332443738==--