Bob Penfield wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat
Sent: Monday, November 24, 2008 9:33 AM
To: Christer Holmberg
Cc: [email protected]; 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
