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

["DRAGE, Keith (Keith)" <[e-mail]>]

> "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: [e-mail] 
> [mailto:[e-mail]] 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,
> 
> >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).,
> 
> >- 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."
> 
> 
> >- 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."
> 
> 
> >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?
> 
> I am ok with the approach.
> 
> -----
> 
> >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.
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>