Bob Penfield wrote:
-----Original Message----- From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, November 24, 2008 9:33 AM To: Christer Holmberg Cc: sip at ietf.org; Brett Tate Subject: Re: [Sip] draft-ietf-sip-199-02: comments and questions Christer Holmberg wrote: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?
Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip