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

[Christer Holmberg <[e-mail]>]

Hi Paul,

>>> 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.
>>
>>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).,
>
>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.

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)

----

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

----

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

Ok.

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

----

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

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.

>>(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).
>
>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