I'm only halfway through -03 and I'll be sending more later, but this
winged one of the comments I was going to make.
I think this MUST that Brett was pointing to needs to be a MAY, not a
MUST or a SHOULD.
This is an optimization. Nothing breaks if the proxy decides to not
forward a 199 - you just don't
get the optimization.
Instead of going down the route of specifying how proxies can be
configured to behave, I suggest
the document simply say choosing how quickly to return a 199 is a
matter of implementation policy and
leave a note to implementers that in the absence of other reason, "as
soon as possible" will increase the
effectiveness of the optimization.
RjS
On Dec 8, 2008, at 1:33 PM, Christer Holmberg wrote:
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
_______________________________________________
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
