Re: [sipcore] 4028bis: forking

[Roman Shpount <[e-mail]>]

Shinji,

Proxies adding Session-Expires header is the primary reason for existence
of SIP Session Timers. This header is added almost exclusively by proxies
in order to maintain dialog state.

Because of this, your proposal makes no sense to me.

As I have said, I would much rather see parallel forking dropped from
supported scenarios.
_____________
Roman Shpount


On Tue, Jun 2, 2020 at 3:49 AM OKUMURA Shinji <[e-mail]> wrote:

> Roman,
>
> > I have an issue with two of your proposals:
> >
> > 1. Proxy cannot add Session-Timer
> > 2. Proxy cannot generate 422 response
>
> I'm not suggesting that proxy cannot add Session-Timer. The use of "should
> not" may not have been appropriate. I think it is a requirement levels
> issue.
> How about rephrasing it as follows?
>
> "A UAC and proxies MAY add a Session-Expires header, but it is NOT
> RECOMMENDED."
>
> Obviously, legacy proxies add a Session-Expires header, so another proxy
> need to be prepared for that.
>
> Shinji
>
> On 2020/06/02 15:16, Roman Shpount wrote:
> > Shinji,
> >
> > I have an issue with two of your proposals:
> >
> > 1. Proxy cannot add Session-Timer
> > 2. Proxy cannot generate 422 response
> >
> > Both break session timer as it is implemented and used now.
> >
> > Best,
> > _____________
> > Roman Shpount
> >
> >
> > On Mon, Jun 1, 2020 at 9:51 PM OKUMURA Shinji <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >     Roman,
> >
> >     Three(b, c, d) of my suggestions are the same as RFC4028. The last
> one(a) also does not violate the RFC4028. Therefore, this situation can
> occur even with the current regulations.
> >
> >     And rules regarding Min-SE have not changed. Even without using the
> 422 response, proxies can indicate the desired Min-SE to a UAS. So if there
> is a security risk, it means that the RFC4028 has the same risk.
> >
> >     Regards,
> >
> >     Shinji
> >
> >     On 2020/06/02 2:02, Roman Shpount wrote:
> >      >    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] <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[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] <mailto:
> [e-mail]> <mailto:[e-mail] <mailto:
> [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] <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]>>
> >      > https://www.ietf.org/mailman/listinfo/sipcore
> >      >
> >
>