> I am still not sure I understand. Even if the > device answers quickly, the proxy can still > send 199 if it receives an error response.
I agree. However the section 6.1 paragraph 2 text indicates that the proxy MUST send 199. I'd prefer that it is downgraded to a SHOULD to allow the 199 to be avoided when proxy redirecting to something expected to answer quickly. For instance consider, call-forward-no-answer to voice mail. After early dialog established and no-answer timer expires, the proxy sends CANCEL and forks the INVITE to voice-mail server expected to answer quickly. The current text indicates that proxy MUST send 199 if 487 received before the INVITE 200. > > > 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. > > > > Either alternative is OK with me. > > I checked 3261, and if I remember correctly C/R-R > are not mandatory, so I would propose option 2. I just noticed that you indicated "received from the UAC". Did you mean "received from the UAS"? If not, would the proxy insert it's own Contact? Thanks, Brett _______________________________________________ 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
