Subject: [sipcore] Table2/3 maintenance (was Re: [Sip] [Technical Errata Reported] RFC3261 (2910))

From: Robert Sparks <[email-masked]>
Date: Tue, 2 Aug 2011 13:48:49 -0500

(removing the RFC Editor, and setting reply-to to the sipcore list)

Some thing to think about when considering errata on the existing Tables 2 and 3 in RFC3261:

We have had many conversations about the utility of maintaining tables 2 and 3.
I think the most recent was around the Anaheim meeting - see the notes at:
<http://www.ietf.org/proceedings/77/minutes/sipcore.html>

We had strong support for not continuing to add information to Tables 2 and 3, but not
to remove the existing tables from the document.  Maintaining the existing table is
probably a separate question, but keep the arguments noted in the minutes above in
mind when choosing to do so.

RjS

On Aug 2, 2011, at 1:28 PM, Iñaki Baz Castillo wrote:

> 2011/8/2 Bob Penfield <[email-masked]>:
>> The entry in the table should be "c" (not "m"). A Contact is not required in a 100 Trying response. The Contact is only required for a 1xx that creates a dialog.
> 
> Right.
> 
> -- 
> Iñaki Baz Castillo
> <[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 2 Aug 2011 13:57:28 -0500

(Attempting to move this to the sipcore mailing list)

Further, they're only going to make sense for 1xx that is sent using 100rel.

So the errata as submitted is incorrect. We could just reject it and move on (my preference given the way we're handling Table 2),
or try to edit it to be more correct and put it in hold-for-document update (see <http://www.ietf.org/iesg/statement/errata-processing.html>).

RjS

On Aug 2, 2011, at 10:58 AM, Bob Penfield wrote:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of RFC Errata System
> Sent: Tuesday, August 02, 2011 10:54 AM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Sip] [Technical Errata Reported] RFC3261 (2910)
> 
> 
> The following errata report has been submitted for RFC3261,
> "SIP: Session Initiation Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2910
> 
> --------------------------------------
> Type: Technical
> Reported by: Iñaki Baz Castillo <[email-masked]>
> 
> Section: Table 2
> 
> Original Text
> -------------
>      Header field          where   proxy ACK BYE CAN INV OPT REG
>      ___________________________________________________________
>      Contact                1xx           -   -   -   o   -   -
> 
> Corrected Text
> --------------
>      Header field          where   proxy ACK BYE CAN INV OPT REG
>      ___________________________________________________________
>      Contact                1xx           -   -   -   m   -   -
> 
> Notes
> -----
> RFC 3261 says:
> 
> 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.
> 
> However Table 2 (page 162) says:
> 
>      Header field          where   proxy ACK BYE CAN INV OPT REG
>      ___________________________________________________________
>      Contact                1xx           -   -   -   o   -   -
>      Record-Route        2xx,18x    mr    -   o   o   o   o   -
> 
> Obviously Record-Route is optional since in the absence of a proxy doing record-routing, such header will not be present. However Contact header should appear as mandatory (m) for 1xx responses for INVITE rather than optional (o).
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC3261 (draft-ietf-sip-rfc2543bis-09)
> --------------------------------------
> Title               : SIP: Session Initiation Protocol
> Publication Date    : June 2002
> Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Aug 2011 00:24:27 +0200

> 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?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Aug 2011 00:56:18 +0200

> mind when choosing to do so.

I also think that table 2 (at least table 2) is not useful, and just
adds complexity. It's much better to explain/describe/mandate the
presence of headers in the text (IMHO).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 3 Aug 2011 10:46:10 -0500

(removing the rfc-editor and trimming the distribution to the lists)

> headers, *regardless* the usage of 100rel.

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ñaki Baz Castillo
> <[email-masked]>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Aug 2011 13:44:29 -0400

On 8/3/11 11:46 AM, Robert Sparks wrote:
>> 2011/8/2 Robert Sparks<[email-masked]>:

I don't get your point Robert.

Of course its true that this will only create an early dialog at the UAC 
if the UAC actually receives the (unreliable) response. If it doesn't 
receive it, it won't know of the dialog, and so won't try to use BYE to 
terminate the dialog. But if it does receive it, and does know of the 
dialog, it can then use BYE to terminate it. And in that case the UAS 
will concur that there is a dialog and so be able to properly process 
the BYE.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Aug 2011 00:05:45 +0200

Hi,

I agree with Robert's previous comment regarding the decision we previously made regarding maintaining the tables, but maybe something has to be done.

Because, especially regarding this specific case (Contact in responses), I have been involved in a number of discussions where some people argue that Contact must always be included, "because the RFC says so" (there seems to be products that will trigger an error if not always included), while other say it only needs to be included "when it makes sense".

Nothing an SBC shouldn't be able to fix, though ;)

I also agree with Paul. And, the UAC can not only use the early dialog for BYE - it can also use it for other mid-dialog requests (it can't send a new SDP offer, though, as it hasn't received a "real" SDP answer), and once the UAS gets that mid-dialog request it knows that the UAC received the unreliable response, so now IT can start sending mid-dialog requests. 

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 3. elokuuta 2011 20:44
> To: [email-masked]
> Subject: Re: [sipcore] [Sip] [Technical Errata Reported] 
> RFC3261 (2910)
> 
> >> 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."
> >>
> > message may never get to the UAC. Where I said "make sense" 
> above, it 
> > might have been better if I had said "be useful".
> 
> Of course its true that this will only create an early dialog 
> at the UAC if the UAC actually receives the (unreliable) 
> response. If it doesn't receive it, it won't know of the 
> dialog, and so won't try to use BYE to terminate the dialog. 
> But if it does receive it, and does know of the dialog, it 
> can then use BYE to terminate it. And in that case the UAS 
> will concur that there is a dialog and so be able to properly 
> process the BYE.
> 
> 	Thanks,
> 	Paul
> 
> >> Regards.
> >>
> >>
> >> --
> >> Iñaki Baz Castillo
> >> <[email-masked]>

---

From: Romel Khan <[email-masked]>
Date: Thu, 4 Aug 2011 15:09:14 -0400

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 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 send
"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 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.

Thanks.

On Wed, Aug 3, 2011 at 11:46 AM, Robert Sparks <[email-masked]> wrote:

> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use [email-masked] for questions on how to develop a SIP
> implementation.
> Use [email-masked] for new developments on the application of sip.
> Use [email-masked] for issues related to maintenance of the core SIP
> specifications.
>

---

From: Samir Srivastava <[email-masked]>
Date: Thu, 4 Aug 2011 21:15:43 -0700

Hi, IMHO presentation of information in tabulated form helps a lot to
starters. Like ABNF it helps parser developers (expert of syntax &
semantic analysis) to develop it without referring each line of SIP
rfc's. 3262 or 100rel should have updated table  Ideally each
subsequent RFC should conisder table updation. Tabulation of
information will be done by vendors internally anyway. So do it in
community. SIP needed hitchakers guide. Simplicity for starters
please. Regards Samir

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 6 Aug 2011 14:16:51 +0200

El 04/08/2011 21:09, "Romel Khan" <[email-masked]> escribió:
>
> So it is useful if one of UAS or UAC requires it, but it does not have to
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 entirely agree with it. And I also think that the fact that a 1xx response
without 100rel is not reliable does not mean that it does not create a
dialog so Contact and RR are required.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sat, 6 Aug 2011 21:31:40 -0400

> From: Samir Srivastava [[email-masked]]
> 
> rfc's.

The tables are a useful guide to starters.  But as others have noted,
it is very difficult to keep the tables up to date, and there is no
format for the tables that correctly presents the conditions for
all "optional" headers.

Parser developers may be tempted to use the tables to determine
whether a message has all the required headers, but it is nearly
impossible to make that determination other than while carrying out
the processing for the message.

The real rule for the presence of headers is: "Perform the processing
that is mandated by the SIP message.  Headers whose values are
required to perform this processing must be present; headers whose
values are not used in the processing are ignored.  If a needed header
is not present, the processing of the message is aborted and it has no
effect.  If the message is a request, an appropriate error response is
sent (if enough information is present in the request to allow doing
so)."

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sat, 6 Aug 2011 21:38:23 -0400

> From: Paul Kyzivat [[email-masked]]
> 
> Of course its true that this [a 1xx response to INVITE] will only
> create an early dialog at the UAC if the UAC actually receives the
> (unreliable) response. If it doesn't receive it, it won't know of the
> dialog, and so won't try to use BYE to terminate the dialog. But if it
> does receive it, and does know of the dialog, it can then use BYE to
> terminate it. And in that case the UAS will concur that there is a
> dialog and so be able to properly process the BYE.

I agree with Paul.  Indeed, if a UAC receives a 1xx response that does
*not* have a Contact header, processing of the response cannot be
completed (as the dialog information cannot be constructed), and so
the response must have no effect on the UAC.

In regard to Record-Route, omitting them in a 1xx is even worse, as if
the UAC receives the 1xx, the Record-Routes fix the route set for the
dialog, and correct Record-Routes set in the 2xx response can't change
the recorded route set.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 7 Aug 2011 12:27:10 +0200

El 07/08/2011 03:38, "Worley, Dale R (Dale)" <[email-masked]> escribió:

> the recorded route

Hi. I dont agree with this last assertion. AFAIR somewhere in the rfc is
stated that RR in the 2XX replaces any previous RR, even more when previous
RR came in not reliable responses. However the same is not true for the sdp.

IMHO rfc3261 defined non reliable responses but later all need responses to
be reliable (which would avoid all these issues). This is just a protocol
core error design (obvious taking into account all these discussions so many
years with no strong agreement).

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sun, 7 Aug 2011 21:27:33 -0400

> From: Iñaki Baz Castillo [[email-masked]]
> 
> Hi. I dont agree with this last assertion. AFAIR somewhere in the rfc
> is stated that RR in the 2XX replaces any previous RR, even more when
> previous RR came in not reliable responses. However the same is not
> true for the sdp.

Interesting!  I had thought the rule that the route set is never
changed was absolute.  But here is RFC 3261 section 13.2.2.4:

   [...]
   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.

      Note that the only piece of state that is recomputed is the route
      set.  Other pieces of state such as the highest sequence numbers
      (remote and local) sent within the dialog are not recomputed.  The
      route set only is recomputed for backwards compatibility.  RFC
      2543 did not mandate mirroring of the Record-Route header field in
      a 1xx, only 2xx.  [...]

> IMHO rfc3261 defined non reliable responses but later all need
> responses to be reliable (which would avoid all these issues). This is
> just a protocol core error design (obvious taking into account all
> these discussions so many years with no strong agreement).

True, but for backward compatibility, we have to tolerate unreliable
responses.

Dale