Subject: Re: [Insipid] Requirement for Intermediaries to Update Session ID for other parties

From: Brett Tate <[email-masked]>
Date: Tue, 7 Jun 2016 12:41:58 -0400

Hi,

> There are several references in the draft that indicate
> an Intermediary SHOULD update endpoints involved in a
> session if the session ID on one call leg changes, but
> it does not require it. Is there any reason why we should
> not change these to a MUST so that Intermediaries are
> required to update the Session ID for any participant it
> knows is out of sync?
>
> If there are good reasons for leaving as a SHOULD,
> I’d like to hear them.

The following are a few thoughts on the topic.

1) A proxy can't really do it.

2) I assume proxy B2BUA's that only initiate BYE's would not want to do it
except when sending BYE.

3) Because it causes extra traffic and potential for glare, the
administrator might not want the extra messaging to occur solely to update
the UUID.

4) The request might not reach the device that the intermediary is
attempting to update.  Thus, it could be completely useless extra traffic.

5) Methods that the intermediary is willing to use for the update might not
be within the received Allow header.

6) It can cause the intermediary to be part of an infinite change loop
unless use re-INVITE without offer.

7) The intermediary might not have auth credentials to allow the change to
be successful.

8) Because of race conditions and other things, the intermediary initiated
messaging intended to correct the UUID could cause other locations to switch
to an incorrect value.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Tue, 7 Jun 2016 19:20:09 +0000

Brett,

Thanks for the reply. I have some comments / questions inline. I’m not trying to be argumentative in my comments - I really just want to make sure we have a strong argument for SHOULD so really just want to make sure these reasons are valid.

> 1) A proxy can't really do it.

Would a proxy ever do anything that would require it do to it? A proxy will just be forwarding messages back and forth for the most part.

> 2) I assume proxy B2BUA's that only initiate BYE's would not want to do it

Why would they “not want to”?

> administrator might not want the extra messaging to occur solely to update

The potential for glare is a potentially good argument, but is “extra messaging” really an issue?

> attempting to update.  Thus, it could be completely useless extra traffic.

This doesn’t seem like a good reason not to try to update.

> be within the received Allow header.

This is a good one, although I would think re-INVITE is always available (or whatever is being used for session refresh), so is there really ever a case where there is no way to do it? I noticed you said “willing to use” which I’m sure you did intentionally. That doesn’t mean there is no way, but if there was a requirement, then they would have to.

> unless use re-INVITE without offer.

Simplest way to update would be whatever message is being used for session refresh. That should not cause problems.

> 7) The intermediary might not have auth credentials to allow the change to

How would this happen?

> messaging intended to correct the UUID could cause other locations to switch

Why would this happen?