Hi, >>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.
Aaah, now I understand. The voice mail will send 200 quickly, so the early dialog between the UAC and the UAS will be terminated anyway, without a need to send 199. I guess we could say that the proxy can be configured not to send 199, if a 200 is expected quickly, or something like that. >>>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? I meant received from the UAS :) 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
