Subject: [sipcore] Required normative revisions to support 199 response

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Dec 2010 20:44:39 -0500

In offline discussions, Robert, Cullen (and maybe others?) have 
questioned whether draft-ietf-sipcore-199-02.txt requires a normative 
change to RFC 3262 (100rel). We've gotten deep enough into this that it 
seemed proper to bring it back to the list for further discussion.

The issue is that this draft, as currently written, requires that the 
199 response be sent *un*reliably even if Require:100rel was specified 
by the UAC. It is (partially) mitigated by the introduction of a new 
'199' option tag. If Supported:199 is not present in the request, the 
199 response can't be sent. So the draft makes the argument that there 
is no backward compatibility issue, making this an extension rather than 
a change.

BUT, there is still a potential backward compatibility issue for other 
proxies that don't know about the 199 option. A dialog-stateful proxy 
upstream of the 199-sender might observe the unreliable 199 and not it 
to be inconsistent with the Require:100rel.

In addition, I realized that this draft also extends RFC 3261, in that 
it for the first time introduces a case where a *proxy* may *originate* 
(not just forward) a response in the context of an existing (early) 
dialog. According to 3261 a proxy that initiates a response is actually 
doing so in the role of a UAS, and so must add its own to-tag, thus 
creating a new dialog.

So, I have proposed that the specification for what goes on when sending 
199 be tweaked, in a way that is trivially different from an 
implementation perspective but that is conceptually significant. Namely:

- There should be no exception from Require:100rel. When a UAS sends
   a 199, if Require:100rel is in effect it MUST send the 199 reliably.

- When a *proxy* *originates*a 199, it is considered to be operating
   as a *proxy*, not as a UAS. Hence it is not bound by Require:100rel.
   Rather it is bound by Proxy-Require:100rel. The proposal is to
   make a revision to 3262 that says 100rel MUST NOT be used in
   Proxy-Require. And as now the proxy MUST NOT send the 199 reliably.
   That ensures there won't be a PRACK that would then possibly be
   forwarded on to the UAS that doesn't expect it.

   But the proxy is *originating* the 199 response in the context of the
   existing (early) dialog. It must make a response that is valid in that
   context. (E.g. the to-tag.)

This does not eliminate the impact on upstream proxies. They will still 
see an unreliable provisional response that might be surprising. So this 
still requires a revision to 3262. I really hated the idea of making a 
special case for the single 199 response code. So my proposal is:

- in any case where a proxy is permitted to originate a provisional
   response within an existing dialog (early or not) it must do so
   unreliably. (For now the only case this applies to is 199.)

- the 100rel option MUST NOT be sent (ever) in Proxy-Require.

The effect of this is that UACs and proxies may see unreliable 
provisionals even when Require:100rel is in effect. This is a (hopefully 
insignificant) backward incompatibility from 3262.

*** I'm requesting feedback on the above approach.
*** Are you happy with it?
*** Do you have a better idea?

While writing this I thought of another issue that needs discussion. 
When the proxy is constructing the 199, to be in the context of the 
dialog, how should it be constructed? The following are questionable:

- Contact address
- Record-Route
- History-Info
- (did I forget any that matter?)

The straightforward answer is that these should all be copied from the 
final response that triggered the sending of the 199. An alternative 
might be to copy from the response that the proxy considers to have 
established the early dialog. These *might* not be the same.

Alternatively, perhaps the proxy should generate the 199 response 
without the Contact since the contact does not reflect the sender of the 
response. But that would be contrary to some discussions that occurred a 
couple of years ago (aug 2008) on the sip-implementors list, which 
concluded (IMO) that 3261 implies Contact is required in all provisional 
responses.

*** Feedback on this issue also requested.

Disclaimer - the following is my take on things. While this has been 
discussed with Christer and Robert, they have not seen this message.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Dec 2010 21:18:09 +0100

Hi,

>   a 199, if Require:100rel is in effect it MUST send the 199 reliably.

I know that people (including me) wanted to allow a UAS to always send 199 unreliably.

However, I can live with Paul's suggestion (partly because I don't think Require:100rel is very often used in real deployments).,

>   unreliably. (For now the only case this applies to is 199.)

I had a look at 3262, and the follwoing statement could be added to section 4 (UAC behavior) of RFC 3262:

"The UAC MUST, even if it has required provisional responses to be sent reliably, be prepared to receive unreliably
sent provisional response, as such responses might have been sent by SIP proxies."

>- the 100rel option MUST NOT be sent (ever) in Proxy-Require.

I had a look at 3262, and one could argue that the usage of Proxy-Require isn't defined in the first place.

But, if we want to be explicit, the following statement could be added to section 4 (UAC behavior) of RFC 3262:

"A UAC MUST NOT insert a Proxy-Require header field with the option tag 100rel into the request."

>*** Do you have a better idea?

I am ok with the approach.

-----

>concluded (IMO) that 3261 implies Contact is required in all provisional

I think this has been discussed before, and as far as I remember none of the header fields above are required to be present in a provisional response - unless the response is used to create a dialog, which is not the case with 199.

So, unless I'm wrong, I would not like to re-open that discussion, because it is not part of what was supposed to be be brought to the list for discussion.

(From a debugging perspective, I actually think it could be good if the response from the proxy does not contain the header fields, which gives a hint that the response might have been generated by a proxy).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Dec 2010 18:19:43 -0500

inline

> However, I can live with Paul's suggestion (partly because I don't think Require:100rel is very often used in real deployments).,

I raise this because I am not happy with carving out response-code 
specific exceptions to 100rel.

And I don't find the efficiency argument compelling in this case.

> sent provisional response, as such responses might have been sent by SIP proxies."

I think I am ok with that, though currently only 199 gives proxies 
dispensation to send a provisional response that wasn't originated by a UAS.

> "A UAC MUST NOT insert a Proxy-Require header field with the option tag 100rel into the request."

You are right that 3262 doesn't assign any special behavior to a proxy 
if Proxy-Require:100rel is present. There is nothing in 3261 or 3262 
that would prevent the insertion of Proxy-Require:100rel. It would 
require all proxies to understand it, but that understanding doesn't 
call for any behavior. So I guess no added language is required.

> I think this has been discussed before, and as far as I remember none of the header fields above are required to be present in a provisional response - unless the response is used to create a dialo…

The requirement, or not, to include the Contact is my major concern.
You say that the response is not establishing a dialog, but that is not 
certain. The proxy believes the dialog to have been established, based 
on a previously received response. But unless that response was reliable 
and the PRACK returned, there is no certainty that the UAC knows the 
dialog to have been established. Its possible that the earlier 
provisional was lost, and the 199 is the first time the UAC knows there 
is a dialog.

> So, unless I'm wrong, I would not like to re-open that discussion, because it is not part of what was supposed to be be brought to the list for discussion.

Well, I think the above makes you theoretically wrong in rare cases.
But also, the question of whether non-100 1xx messages must have a 
Contact has not, afaik, been settled.

So we at least need to consider what behavior is required regarding 
Contact, and whether that is a normative change. Right now the 199 draft 
doesn't say one way or the other.

> (From a debugging perspective, I actually think it could be good if the response from the proxy does not contain the header fields, which gives a hint that the response might have been generated by…

Yes, it probably would be better for the Contact to be missing, since it 
definitely should not be used. Same for Record-Route.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Dec 2010 08:03:22 +0100

Hi Paul,

>I raise this because I am not happy with carving out response-code specific exceptions to 100rel.
>

So, propose to modify the text accordingly:

The following paragraph in section 5:

  "When a 199 response is sent by a UAS, since the provisional response
   is only used for information purpose, the UAS SHOULD send it
   unreliably even if the 100rel option tag [RFC3262] is present in the
   Require header of the associated request."

...will be modified into:

   "When a 199 response is sent by a UAS, since the provisional response
   is only used for information purpose, the UAS SHOULD send it
   unreliably, unless the 100rel option tag [RFC3262] is present in the
   Require header of the associated request."

The following paragraph in section 9:

   "When a 199 Early Dialog Terminated provisional response is sent by a
   UAS, since the provisional response is only used for information
   purpose, the UAS SHOULD send it unreliably even if the 100rel option
   tag [RFC3262] is present in the Require header of the associated
   request."

...will be modified into:

   "When a 199 Early Dialog Terminated provisional response is sent by a
   UAS, since the provisional response is only used for information
   purpose, the UAS SHOULD send it unreliably, unless the 100rel option
   tag [RFC3262] is present in the Require header of the associated
   request."

(even if/, unless"/s)

----

>I think I am ok with that, though currently only 199 gives proxies dispensation to send a provisional response that wasn't originated by a UAS.

So, first I suggest adding the following text to section 1 (Introduction):

"In addition, this specification updates RFC 3262 [reference], by mandating a UAC to be prepared to receive unreliably sent provisional responses
even if it has required provisional responses to be sent reliably."

Then, the question is then how to document the normative change. Do I include the whole new section 4 in the draft, or do I only say that the statement above is added to section 4 (see below)?

"X. Update the RFC 3262

The following statement is added to section 4 of RFC 3262[reference]:

The UAC MUST, even if it has required provisional responses to be sent reliably, be prepared to receive unreliably
sent provisional response, as such responses might have been sent by SIP proxies."

----

>call for any behavior. So I guess no added language is required.

Ok.

(I also think that an INVITE with P-R:100rel in most cases would be rejected)

----

>doesn't say one way or the other.

We need to separate between a 199 sent by a UAS and a 199 sent by a proxy.

When a UAS sends a 199, we can say that it must be generated according to 3261, 3262 etc. So, whatever header fields are required in a provisional response will be included in the 199.

When a proxy sends a 199, it will always be triggered by a final response. So, the race condition you mention would only take place when the dialog-establishment provisional response from the UAS doesn't reach the UAC before the 199, triggered by the final response from the UAC, does.

>Yes, it probably would be better for the Contact to be missing, since it definitely should not be used. Same for Record-Route.

Would you like me to add some text, e.g. something like:

"When a proxy send a 199 response, it SHALL NOT insert a Contact header field or a Record-Route header field to the response."

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 8 Dec 2010 14:32:54 +0100

> "The UAC MUST, even if it has required provisional responses 
> to be sent reliably, be prepared to receive unreliably sent 
> provisional response, as such responses might have been sent 
> by SIP proxies."
>

How about: 

"The UAC MUST support reception of all provisional responses, sent reliably or unreliably; use of the option tag value "100rel" in a Require header field does not change this requirement."

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Tuesday, December 07, 2010 8:18 PM
> To: Paul Kyzivat; SIPCORE
> Subject: Re: [sipcore] Required normative revisions to 
> support 199 response
> 
> Hi,
> 
> >is no backward compatibility issue, making this an extension rather 
> >than a change.
> >
> However, I can live with Paul's suggestion (partly because I 
> don't think Require:100rel is very often used in real deployments).,
> 
> >see an unreliable provisional response that might be surprising. So 
> >this still requires a revision to 3262. I really hated the idea of 
> >making a special case for the single 199 response code. So 
> my proposal is:
> >
> I had a look at 3262, and the follwoing statement could be 
> added to section 4 (UAC behavior) of RFC 3262:
> 
> "The UAC MUST, even if it has required provisional responses 
> to be sent reliably, be prepared to receive unreliably sent 
> provisional response, as such responses might have been sent 
> by SIP proxies."
> 
> 
> I had a look at 3262, and one could argue that the usage of 
> Proxy-Require isn't defined in the first place.
> 
> But, if we want to be explicit, the following statement could 
> be added to section 4 (UAC behavior) of RFC 3262:
> 
> >without the Contact since the contact does not reflect the sender of 
> >the response. But that would be contrary to some discussions that 
> >occurred a couple of years ago (aug 2008) on the 
> sip-implementors list, 
> >which concluded (IMO) that 3261 implies Contact is required in all 
> >provisional responses.
> 
> I think this has been discussed before, and as far as I 
> remember none of the header fields above are required to be 
> present in a provisional response - unless the response is 
> used to create a dialog, which is not the case with 199.
> 
> So, unless I'm wrong, I would not like to re-open that 
> discussion, because it is not part of what was supposed to be 
> be brought to the list for discussion.
> 
> (From a debugging perspective, I actually think it could be 
> good if the response from the proxy does not contain the 
> header fields, which gives a hint that the response might 
> have been generated by a proxy).
> 
> Regards,
> 
> Christer
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Dec 2010 14:42:29 +0100

Hi Keith, 

>>"The UAC MUST, even if it has required provisional responses to be 
>>sent reliably, be prepared to receive unreliably sent provisional 
>>response, as such responses might have been sent by SIP proxies."
>>
> 
>How about: 
>
>"The UAC MUST support reception of all provisional responses, 
>sent reliably or unreliably; use of the option tag value 
>"100rel" in a Require header field does not change this requirement."

Looks good to me.

Regards,

Christer

> > Subject: Re: [sipcore] Required normative revisions to support 199 
> > response
> > 
> > Hi,
> > 
> > I know that people (including me) wanted to allow a UAS to 
> always send 
> > 199 unreliably.
> > 
> > However, I can live with Paul's suggestion (partly because I don't 
> > think Require:100rel is very often used in real deployments).,
> > 
> > "The UAC MUST, even if it has required provisional responses to be 
> > sent reliably, be prepared to receive unreliably sent provisional 
> > response, as such responses might have been sent by SIP proxies."
> > 
> >