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

Hi Robert, 

>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.

I assume you mean GENERATE a 199, right? That is what Brett is talking
about.

Because, if the proxy receives a 199, it would of course forward it
according to normal proxy rules.

I can remove the MUST, but I think we should have a SHOULD. If the proxy
supports the extension (and the UAC has indicated support of it), the
proxy should use it (except in scenarios like the one Brett described).

>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.

I will think about some wording.

Thanks for your comments!

Regards,

Christer





> >
> > 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