Subject: [sipcore] 4028bis: forking

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 27 May 2020 17:12:00 +0900

Hi,

In following scenario,
(1) Alice sends INVITE.
(2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol.
(4) Proxy2 rejects INVITE by 422.
(6) Carol accepts INVITE by 200.

Eventually Bob never receive INVITE.

        Alice        Proxy1    Proxy2(->Bob) Carol
          |(1) INVITE  |            | ||
          |SE:1800     |            | ||
          |----------->|            | ||
          |            |(2) INVITE  | ||
          |            |SE:1800     | ||
          | |------------------------>|
          |            |(3) INVITE  | ||
          |            |SE:1800     | ||
          |            |===========>| ||
          |            |(4) 422     |       |
          |            |MSE:3600    |       |
          | |<===========|            |
          |            |(5) ACK     | |
          | |===========>|            |
          |            |(6) 200 OK |
          |            |SE:1800 |
          | |<------------------------|
          |(7) 200 OK  | |
          |SE:1800     | |
|<-----------|                         |
          |(8) ACK     | |
|----------->|                         |
          |            |(9) ACK |
          | |------------------------>|

I hope that 4028bis addresses this issue.

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 May 2020 10:16:24 +0000

Hi,

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.

Regards,

Christer

On 27/05/2020, 11.12, "OKUMURA Shinji" <[email-masked]> wrote:

    Hi,

    In following scenario,
    (1) Alice sends INVITE.

    Regards,
    Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 May 2020 13:48:04 -0400

Shinji,

>         Alice        Proxy1    Proxy2(->Bob) Carol

What do you think *should* happen?

	Thanks,
	Paul

> Regards,
> Shinji
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 27 May 2020 21:59:25 -0400

> Eventually Bob never receive INVITE.

True ... but that's acceptable.  Alice sent an INVITE and connected with
one if its destinations.

A more interesting issue is if Carol does not accept the INVITE, and her
UA responds with 487.  Then Proxy1 sees a 422 response from Proxy2 and a
487 from Carol.  If it returns the 487 to Alice, Alice won't update
the session timer.  RFC 3261 sectoin 16.7 item 6 says

         The proxy SHOULD
         give preference to responses that provide information affecting
         resubmission of this request, such as 401, 407, 415, 420, and
         484 if the 4xx class is chosen.

which suggests that 422 should be returned to the UAC, because the UAC
can adjust the request based on it.

Dale

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 28 May 2020 15:34:44 +0900

Hi,

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.

Regards,
Shinji

On 2020/05/27 19:16, Christer Holmberg wrote:
>          |(1) INVITE  |            |    |       |
>          |SE:1800     |            |    |       |
>          |----------->|            |    |       |
>          |            |(2) INVITE  |    |       |
>          |            |SE:1800     |    |       |
>          |            |(3) INVITE  |    |       |
>          |            |SE:1800     |    |       |
>          |            |===========>|    |       |

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 28 May 2020 15:35:19 +0900

Hi,

The cause of the issue is the 422 response and the cause of the 422 response is the SE header.
I think the simple solution is to allow the proxy to increase the value of SE-header. RFC4028 also conditionally allows the proxy to increase the SE-value.
Honestly writing, INVITE request doesn't need a SE-header, I think it's enough for UAS to copy the MSE value into SE-header of 200 response.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 28 May 2020 15:35:52 +0900

Hi,

If Bob is a call center operator, I think that's a problem for him.

If Carol responds 401, which is the "best" final response?
At least for session-timer, I think it should be handled within the early dialog as well as the pre-condition. (If we didn't have to consider backward compatibility.)

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 May 2020 09:15:49 +0000

Hi,

Note that the technical scope of 4028bis is to solve the glare issue that has been identified. Other would-be-nice-to-haves are not within the scope.

Your issue can be solved be proper configuration - there is no technical work needed.

Regards,

Christer

-----Original Message-----
From: OKUMURA Shinji <[email-masked]> 
Sent: torstai 28. toukokuuta 2020 9.35
To: [email-masked]
Cc: Christer Holmberg <[email-masked]>
Subject: Re: 4028bis: forking

Hi,

Regards,
Shinji

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 May 2020 22:30:21 -0400

OKUMURA Shinji <[email-masked]> writes:
> 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.

>> 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