Re: [sipcore] 4028bis: forking

[Roman Shpount <[e-mail]>]

  Shinji,

The main purposes of session timers is to allow SIP proxies to maintain
dialog state for billing and other purposes. Proxies are the main agents
that insert Session-Expires header. In most cases there is no reason for UA
to use session timers since they can normally monitor call presence without
it. Your proposal makes the most common use case for session timers
impossible.

Min-SE exists mainly for the purpose of preventing badly behaving proxies
or UA from overload proxies on the call path or UAS. Not allowing proxy to
send 422 creates a big security risk.

My general attitude is that parallel forking is broken for a lot of use
cases anyway, so it should be avoided. I do not think a lot of production
deployments are actually use parallel forking. Most of the UA would not
handle multiple 200 OK responses that can be created as a result of
parallel fork. Session timers are, on the other hand, are used a lot. So I
would prefer to live with broken or under-specified parallel forking vs
breaking session timers.

Thank You,
_____________
Roman Shpount


On Mon, Jun 1, 2020 at 5:57 AM OKUMURA Shinji <[e-mail]> wrote:

> Hi,
>
> I've not intended to suggest a common solution to the fork-issue. I am
> interested in how the fork does not happen. It is related to the behavior
> of proxies and a UAS in the 1st phase that you mention. My suggestion is
> that a UAS and proxies SHOULD avoid returning 422 as much as possible.
>
> Considering backward compatibility, rules are as follows.
>
> a) A UAC and proxies should not insert a Session-Expires header.
> b) A UAC and proxies may insert a Min-SE header or increase the value of
> it.
> c) A UAS may insert a Session-Expires header into a 200 response.
> d) A proxy may insert a Session-Expires header into a 200 response, but
> must not modify it.
>
> Of course legacy proxies will return 422, but this is unavoidable.
> In that case, the following rule may be useful.
>
> e) If a proxy increases the value of a Min-SE header and it becomes
> greater than the value of a Session-Expires header, then a proxy should
> increase the value of a Session-Expires header to the value of a Min-SE
> header.
>
> However, this rule can be problematic in terms of backward compatibility.
>
> Shinji
>
> On 2020/05/29 11:30, Dale R. Worley wrote:
> > OKUMURA Shinji <[e-mail]> writes:
> >> As you point out, the other responses(407, 420, ...) cause the same
> problem.
> >> But session-timer is essentially a kind of pre-condition, so I'd like
> >> to avoid incoming calls to fail because of it. And I'd like to sort
> >> out also the rules in early dialog.
> >
> >> On 2020/05/27 19:16, Christer Holmberg wrote:
> >>> A proxy rejecting a request is not unique to the session-timer.
> >>>
> >>> If Alice receives a 422 she can send a CANCEL (if other early dialogs
> >>> have been established), and then a new initial INVITE.
> >
> > (This has a larger scope than just session-timers.)
> >
> > I don't know if the above writers intended this point, but reading what
> > they have said suggests to me this possible behavior for proxies (which
> > I don't recall seeing suggested):
> >
> > Note that 422 is one of a number of "pre-condition failure" response
> > codes.  Those have the properties (1) when they are generated, they are
> > generated nearly immediately from the INVITE, and (2) the UAC can adjust
> > the INVITE to prevent them.
> >
> > Suppose that if a proxy receives one of these "pre-condition failure"
> > responses, it immediately (or with short delay on a human scale) cancels
> > all remaining forks of the transaction and returns the failure response
> > upstream.
> >
> > The effect is to split the "early dialog" phase into two sub-phases, (1)
> > a very short phase where the forking of the INVITE effectively probes
> > for proxies and UASs that object to the the INVITE for "pre-condition"
> > reasons, and (2) a longer phase which resembles the current early dialog
> > phase.
> >
> > There are probably refinements needed to make this work in all cases.
> >
> > Dale
> >
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>