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

[Christer Holmberg <[e-mail]>]

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



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