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

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