[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Sip-199-02: majors and nits from Robert
Hi,
I think it would also have been very useful to have a
Forking-Proxy-Require header.
Regards,
Christer
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 25. marraskuuta 2008 2:52
> To: Hadriel Kaplan
> Cc: Christer Holmberg; SIP IETF
> Subject: Re: [Sip] Sip-199-02: majors and nits from Robert
>
>
>
> Hadriel Kaplan wrote:
> >
> >> -----Original Message-----
> >> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> >> Sent: Monday, November 24, 2008 4:24 PM
> >>> If we can't think of any legitimate use for an option-tag in
> >>> Require,
> >> why should we allow it?
> >>
> >> Because there may be a legitimate use for it tomorrow, or
> next week,
> >> or next year.
> >
> > It occurs to me maybe we're talking past each other. When
> I think of the *Require* header, I think of what does any
> random endpoint/gateway getting this request have to support
> for this to succeed. I can see no value in having that
> behavior, and plenty of harm in doing so. I don't want a UAC
> maker to ever think it can require UAS' to implement 199 in
> order for its request to succeed.
> > But maybe what you're talking about is *Proxy-Require*?
>
> Well, we know tht Proxy-Require is way more evil.
>
> Even so, it probably is the thing that a UAC might want to
> use if it knew there were proxies doing the forking.
>
> Trouble is - B2BUAs cause a lot of trouble with
> Require/Proxy-Require. I suspect that Proxy-Require should
> have been MiddleBox-Require, and so applied to B2BUAs.
>
> So if you really need 199 responses any time a forked invite
> might have been abandoned, then I think you must use *both*
> Require and Proxy-Require. But that is pretty certain to
> guarantee that your call will fail.
>
> This has convinced me that there is no valid use of Require /
> Proxy-Require.
>
> Thanks,
> Paul
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip