Re: draft-ietf-sip-199-03: comments and questions

"Christer Holmberg" <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <CA9998CD4A020D418654FCDEF4E707DF05C0FA22@esealmw113.eemea.ericsson.se>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.