Re: draft-ietf-sip-199-02: comments and questions

Hi, 

>>>>Two alternative solutions I can think of:
>>>>
>>>>1. We mandate a forking proxy which supports 199 to store the C/R-R 
>>>>information received from the UAC, in order to insert it in any 199 
>>>>it generates for that session.
>>>>
>>>>2. We say that IF the forking proxy stores the C/R-R information 
>>>>received from the UAC, it shall insert it in any 199 it generates 
>>>>for that session.
>>>In effect the proxy is sending the response in lieu of the final 
>>>response it is not ready to forward. IMO it ought to include whatever

>>>Contact and R-R is present in that final response. There isn't any 
>>>need to *store* that information, since the final response is at hand

>>>when the 199 is being generated.
>> 
>>The problem with this is that the non-2xx final response will not
necessarily have Record-Route or Contact headers since 3261 does not
require it. In fact, a strict reading of Table 2 & 3 forbids them >>in
most error responses. If the proxy is going to generate a 199 response,
it should include the same Record-Route & Contact as the original early
dialog creating 1xx response.
>
>Good point.
>
>Unfortunately, that significantly raises the bar for the proxy to
implement this. It needs to store a lot more state than it otherwise
would need. Not a problem for a B2BUA of course, since it already 
>has to store that.
>
>This then leaves us in a situation where a proxy incurs this
significant extra cost to support 199, unless we make the inclusion of
the R-R and Contact optional in the 199. I guess the Contact is already
>optional (though we have had discussions about that), but isn't the R-R
required in all the provisional responses?

According to the tables in chapter 20 of 3261, Contact is optional in
1xx responses, and R-R is optional in 18x responses (the table doesn't
cover R-R for 199 :).

In addition, according to chapter 12.1.1 R-R is only mandatory in
responses which creates a dialog (which the 199 doesn't).

"When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values."

Having said that, I don't think it would have a significant impact even
if the forking proxy would have to store this information.

Regards,

Christer

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip