Subject: Re: [sipcore] Session timer fix

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 10:31:05 +0000

Hi Roland,

Since the originating Proxy is anyway going to forward the Session-Timer UPDATE requests, why does it remove “SE; supp”?

Regards,

Christer

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday 9 October 2017 at 12:34
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AW: [sipcore] Session timer fix

Hi,
sorry but I have an further issue where we have problems with session timer.
It is the procedures of stateful Proxy Servers where we can cause a race condition.

We have made the observation that due to the rules we have race conditions with using the session timer.

The case is where we have transfer of SIP messages through an network that is not supporting session timer.

Originating network and UAC does support session timer.
Intermediate network does not support session timer
And the terminating network does support session timer.

This may result with the following call flow.

UAC           Proxy           Proxy         UAS_2
   |                           |                |
   |-- INVITE -->|             |                |
   |    SE; supp |-- INVITE -->|-- INVITE (2) ->|
   |             |    none     |    SE; supp
   |             |             |                |
   |             |             |<-- 200 (2) ----|
   |<- 18x (2) --|<- 18x (2) --|    SE 1800;
   |   SE 1800;  |             |      UAS       |
   |     UAC     |             |                |
   |-- UPDATE -->|             |                |
   |            |-- UPDATE -->| <-- UPDATE ----|
   |             |             |                |
  |            |<- UPDATE ---| --- UPDATE --->|
   |<- UPDATE ---|             |                |
   |-- 491   --->|             |<-- 491     ----|
   |             |-- 491   --->|                |
   |             |<-- 491 ----|--- 491   --->|
   |<-- 491 ----|             |                |

This will happen when the session timer has the same length.
How do we can solve such race conditions. I see the main problem within the proxy behavior and the
Forwarding of the UPDATE (or re-INVITE) for session refresh.

Of course also the choice when the refresher shall sent the refresh may solve the problem.
But if the originating and terminating network is using the same software vendor the refresh time will be the same.
So seen from that kind of algorithm is needed to generate different session refresh times.

Do you see the same problems?

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Montag, 9. Oktober 2017 00:12
> An: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Betreff: Re: [sipcore] Session timer fix
>
> On 10/5/17 4:37 AM, Christer Holmberg wrote:
> > Hi,
> >
> >>> …
> >>>
> >>>> I'll propose that the session timer negotiation never be done with
> >>>> an UPDATE within an INVITE transaction. (Regardless of whether than
> >>>> INVITE is negotiating a session timer or not.) I think this
> >>>> resolves the problem that you have encountered. (Or we could
> >>>> require that the UPDATE and response care consistent session timer
> >>>> signaling with what is carried in the INVITE and its responses.)
> >>>
> >>> I had a chat with some product people, and they said that there
> >>> actually ARE cases where the session timer is negotiated using
> >>> UPDATE when the initial INVITE transaction is still ongoing. There
> >>> are cases where the INVITE only contains Supported:timer, but the
> >>> actual negotiation is done using UPDATE.
> >>
> >> Interesting! (I wonder why.)
> >
> > I haven’t been able to figure out exactly why. I was just told the
> > use-case exists.
> >
> >
> >> That sequence itself presents some ambiguities. The way I have always
> >> described how the session timer negotiation works is that *every*
> >> INVITE and UPDATE transaction affects s-t - it either negotiates it
> >> *on* or else it negotiates it *off*. (IMO this makes it very easy to
> >> understand.)
> >>
> >> That presents issues when you have an update nested inside of an invite.
> >> In the case you describe I might expect that the update would
> >> negotiate the timer on, and then the completion of the invite would
> >> negotiate it off again.
> >>
> >> How would the case you describe work if a proxy inserted S-E in INVITE?
> >> In that case, the UAC doesn't know about it until the 2xx from the
> >> invite. Before then it might try enabling a timer using UPDATE.
> >>
> >> I am inclined to keep things simple by saying that the 2xx response
> >> to every INVITE or UPDATE redefines the state of the session timer,
> >> either on or off. That will of course break the use case you describe
> above.
> >
> > The problem here is that the UAC sends INVITE with S-E, and then
> > receives an UPDATE with S-E before it has received a 2xx response to
> > the INVITE - making the UAC think that there is a S-E glare situation
> > (i.e., the UAS also tries to initiate session timer negotiation).
>
> Yes, I understand that is the case you are thinking of. But I was raising a
> different case:
>
> - the UAC sends an invite without a S-E.
> - a proxy along the path includes an S-E. (The UAC is unaware.)
> - later, the UAC sends an UPDATE with S-E.
>
> That violates the rule in your draft, but the UAC doesn't know it has violated
> it. So your rule for avoiding the problem in this case doesn't work.
>
>        Thanks,
>        Paul
>
> > I think the RFC is pretty clear on how things work once the session
> > timer has been negotiated (and, if it isn’t, we for sure can clarify that too).
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >>>>>
> >>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg"
> >>>>> <[email-masked]<mailto:[email-masked]> on behalf of
> >>>>> mailto:[email-masked]>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>>> seen from my point of view the UAC should ignore the Session
> >>>>>>>> timer proposal within the UPDATE.
> >>>>>>>> As long as the negotiation is  ongoing.
> >>>>>>>>
> >>>>>>>> Nevertheless we have also observed this curious session timer
> >>>>>>>> behavior in our network.
> >>>>>>>>
> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also to
> >>>>>>>> other sections to make it more readable.
> >>>>>>>> My experience is that people have problems in following how the
> >>>>>>>> session timer should work within a complex SIP networks (e.g.
> IMS).
> >>>>>>>>
> >>>>>>>> What is about updating the RFC4028.
> >>>>>>>
> >>>>>>> Like most of the older SIP RFCs, it probably deserves an update.
> >>>>>>> The problem is whether going to the trouble will have any effect
> >>>>>>> on implementations. I think the most we > should hope to do is
> >>>>>>> *clarify*
> >>>>>>> in
> >>>>>>> cases where there is ambiguity, so that when interoperability
> >>>>>>> problems arise it is clear who needs to change.
> >>>>>>
> >>>>>> Yes. In my case, implementation(s) WILL be changed. The question
> >>>>>> is WHICH
> >>>>>> implementation(s) :)
> >>>>>>
> >>>>>> So, my suggestion would be:
> >>>>>>
> >>>>>> 1)     Specify/clarify that SE must not be sent during session-timer
> >>>>>> negotiation
> >>>>>> 2)     Specify that one must send a 491 (or some other more
> appropriate
> >>>>>> code)
> >>>>>> response if receiving SE during session-timer negotiation
> >>>>>>
> >>>>>> For the above, I think we can do it using an errata.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Christer
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> -----Ursprüngliche Nachricht-----
> >>>>>>>> Von: sipcore [mailto:[email-masked]] Im Auftrag von
> >>>>>>>> Christer Holmberg
> >>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34
> >>>>>>>> An: Paul Kyzivat <mailto:[email-masked]>; mailto:[email-masked]
> >>>>>>>> Betreff: Re: [sipcore] Session-timer issue
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>>>> The following issue has been around for some time already
> >>>>>>>>>> (there is also  an errata #4744), and as it causes problems
> >>>>>>>>>> (the INVITE is rejected with a
> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to be
> >>>>>>>>>> fixed.
> >>>>>>>>>> People seem to have different opinions on which node is
> >>>>>>>>>> acting wrongly, so  I hope we can sort it out :)
> >>>>>>>>>
> >>>>>>>>> This is an interesting problem. I agree that it is unclear
> >>>>>>>>> exactly what ought to happen in this case. (But I don't
> >>>>>>>>> understand why someone thinks a 480 is a good way to resolve
> >>>>>>>>> it.)
> >>>>>>>>
> >>>>>>>> Whether 480 is the best solution or not is not the issue, in my
> >>>>>>>> opinion.
> >>>>>>>> One could also claim that the UPDATE should be rejected. Etc.
> >>>>>>>>
> >>>>>>>> The issue is that there is a session-timer negotiation "race
> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE
> >>>>>>>> could be part of such solution).
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Christer
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>      Thanks,
> >>>>>>>>>      Paul
> >>>>>>>>>
> >>>>>>>>>> Below is a call flow showing the problem:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> UA                Proxy                AS
> >>>>>>>>>>
> >>>>>>>>>> ------------------->
> >>>>>>>>>> INVITE (#1)
> >>>>>>>>>> Supported:timer
> >>>>>>>>>> SE:refresher=uac
> >>>>>>>>>>
> >>>>>>>>>>                          ------------------->
> >>>>>>>>>>                          INVITE (#2)
> >>>>>>>>>>                          Supported:timer
> >>>>>>>>>>                          SE:refresher=uac
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>                          <-------------------
> >>>>>>>>>>                          18x (#3)
> >>>>>>>>>>
> >>>>>>>>>> <-------------------
> >>>>>>>>>> 18x (#4)
> >>>>>>>>>>
> >>>>>>>>>> ++++++ early dialog established +++++++
> >>>>>>>>>>
> >>>>>>>>>>                          <-------------------
> >>>>>>>>>>                          UPDATE (#5)
> >>>>>>>>>>                          Supported:timer
> >>>>>>>>>>                          SE:refresher=uas
> >>>>>>>>>>
> >>>>>>>>>> <-------------------
> >>>>>>>>>> UPDATE (#6)
> >>>>>>>>>> Supported:timer
> >>>>>>>>>> SE:refresher=uas
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ------------------->
> >>>>>>>>>> 200 (UPDATE) (#7)
> >>>>>>>>>>
> >>>>>>>>>>                          ------------------->
> >>>>>>>>>>                          200 (UPDATE) (#8)
> >>>>>>>>>>                          Require:timer
> >>>>>>>>>>                          SE:refresher=uac
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>                          <-------------------
> >>>>>>>>>>                          480 (INVITE) (#9)
> >>>>>>>>>>
> >>>>>>>>>> <-------------------
> >>>>>>>>>> 480 (INVITE (#10)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> A few things to note:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N1:        The 18x does not contain the SE (Session-Expires)
> header
> >>>>>>>>>> field,
> >>>>>>>>>>              because according to section 4 of RFC 4028 the
> >>>>>>>>>> header field is only
> >>>>>>>>>>              allowed in INVITE, UPDATE and 2xx. So, when the
> >>>>>>>>>> UPDATE request
> >>>>>>>>>>              (#5) is sent, the initial session timer
> >>>>>>>>>> negotiation is still
> >>>>>>>>>>              ongoing.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N2:        The UPDATE request (#5) contains a Session-Expires
> header
> >>>>>>>>>> field.
> >>>>>>>>>>              Section 7.4 of RFC 4028 says:
> >>>>>>>>>>
> >>>>>>>>>>          "In a session refresh request sent within a dialog with
> >>>>>>>>>> an active
> >>>>>>>>>>           session timer, the Session-Expires header field SHOULD
> >>>>>>>>>> be present."
> >>>>>>>>>>
> >>>>>>>>>>     Now, a dialog (early) HAS been established when the UPDATE
> >>>>>>>> request is
> >>>>>>>>>>              sent, but as the initial session timer
> >>>>>>>>>> negotiation is still
> >>>>>>>>>>              ongoing, I assume the session timer isn¹t yet
> >>>>>>>>>> "active"?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> N3:        The UPDATE 200 response (#7) does not contain the
> >>>>>>>>>> Session-Expires
> >>>>>>>>>>              header field. It is added by the proxy, based on
> >>>>>>>>>> the procedures in
> >>>>>>>>>>              Section 8.2 of RFC 4028:
> >>>>>>>>>>
> >>>>>>>>>>                   "Because there is no Session-Expires or
> >>>>>>>>>> Require header field
> >>>>>>>>>>                    in the response, the proxy knows that it
> >>>>>>>>>> is the first
> >>>>>>>>>>                    session-timer-aware proxy to receive the
> >>>>>>>>>> response.
> >>>>>>>>>> This  proxy
> >>>>>>>>>>                    MUST insert a Session-Expires header field
> >>>>>>>>>> into the response
> >>>>>>>>>>                    with the value it remembered from the
> >>>>>>>>>> forwarded request.
> >>>>>>>>>> It
> >>>>>>>>>> MUST
> >>>>>>>>>>                    set the value of The 'refresher' parameter
> >>>>>>>>>> to 'uac'.
> >>>>>>>>>> The  proxy MUST
> >>>>>>>>>>                    add the 'timer' option tag to any Require
> >>>>>>>>>> header field in  the
> >>>>>>>>>>                    response, and if none was present, add the
> >>>>>>>>>> Require header  field with
> >>>>>>>>>>                    that value before forwarding it upstream."
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Now, one could argue that the UA should include something in
> >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution
> >>>>>>>>>> as the UA may be confused.
> >>>>>>>>>> Instead, based on my understanding of the text in section 7.4
> >>>>>>>>>> (see
> >>>>>>>>>> above) the UPDATE request (#5) should not contain any
> session
> >>>>>>>>>> timer information. This is also more or less what the errata
> >>>>>>>>>> suggests.
> >>>>>>>>>>
> >>>>>>>>>> Comments?
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Christer
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> sipcore mailing list
> >>>>>>>>>> mailto:[email-masked]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> sipcore mailing list
> >>>>>>>>> mailto:[email-masked]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> sipcore mailing list
> >>>>>>>> mailto:[email-masked]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> sipcore mailing list
> >>>>>> mailto:[email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>
> >>>>> _______________________________________________
> >>>>> sipcore mailing list
> >>>>> mailto:[email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> sipcore mailing list
> >>>> mailto:[email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >>>
> >>
> >
> >
>
> _______________________________________________
> sipcore mailing list
> mailto:[email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Jesske, Roland" <[email-masked]>
Date: Mon, 9 Oct 2017 11:35:57 +0000

Hi Christer,
Ok it is not the outgoing proxy of the originating network that deletes the supported header.
The outgoing proxy of the orig. network will keep the supported timer. But the incoming proxy of the intermediate network, which is also statefull will delete the supported timer. Same apply for the backward direction.

This is the typical interconnection usage.
So as I said this is a real issue we have.

   Originating       |  transit    | terminating
UAC           Proxy  | Proxy Proxy | Proxy         UAS_2
Session timer sup    |    no sup   | Session timer sup

Best Regards

Roland

Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Montag, 9. Oktober 2017 12:31
An: Jesske, Roland <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Betreff: Re: AW: [sipcore] Session timer fix

Hi Roland,

Since the originating Proxy is anyway going to forward the Session-Timer UPDATE requests, why does it remove "SE; supp"?

Regards,

Christer

Hi,

UAC           Proxy           Proxy         UAS_2
   |                           |                |
   |-- INVITE -->|             |                |

Roland

> >>> ...
> > I haven't been able to figure out exactly why. I was just told the
> > use-case exists.
> >
> >
> > timer has been negotiated (and, if it isn't, we for sure can clarify that too).
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >>>>>