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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip