[sipcore] Required normative revisions to support 199 response

[Paul Kyzivat <[e-mail]>]

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