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
