Subject: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Oct 2014 11:23:09 -0500

As Shinji pointed out, the whole reason we have immediate NOTIFY in 
subscription
dialogs is that only one of the 200 OKs to a forked SUBSCRIBE will ever 
make it
back to the subscriber. Trying to carry any information, like the proposed
Refer-Events-At, in the response to a REFER that might fork is going to 
have
the same problem.

A big "Thank You" to everyone who brainstormed possible ways we might do 
things
differently. (I'll summarize and expand on what was discussed before the 
message
is over).

After kicking this around for awhile, I think the right thing to do with 
this
realization is acknowledge the limitation in the mechanism, rather than try
to change the mechanism to avoid it.

My proposal will be to add text to the draft noting that if a REFER 
forks, and
is accepted by more than one recipient, the UA sending the REFER will 
only learn
the Refer-Events-At URI from one of those recipients, and which one is 
out of its
control. So, the extension should only be used when that's ok for the 
application
sending the REFER. That is, either there is enough information to know 
that the
REFER will only be accepted in one place (as is the case if it is sent 
in-dialog,
or Target-Dialog is provided in an out-of-dialog request), or the 
application
doesn't care about tracking the resulting state if the request is accepted
in more than one place. If things would go wrong if the REFER were accepted
in more than one place and the referrer didn't learn about each of them, 
then
the application must not use this extension (falling back into a 
6665-subscription
creating REFER instead).

I know that as engineers, we find this kind of shortcoming distateful.
But, pragmatically, there isn't a strong demand for solving the general 
problem.

If I'm wrong about that, and we decide we must figure out how to get 
information
back from every place a forked REFER is accepted, I see three basic paths
to choose from (based on the recent conversations, and some really old 
ones -
remember HERFP - this is like that, only harder). Again, this is talking 
only
about cases where the REFER might fork - we'll deal with in-dialog or other
non-forking cases separately.

1) Modify proxy behavior to aggregate the responses. As pointed out on 
the list
already, this really a non-starter - it means the proxy will have to hold
the first 200 in case others arrive, forcing it into the bad places of long
non-invite transactions as detailed in RFC4320 and RFC4321.

2) Send an out-of-dialog request from each accepting endpoint back in the
other direction.  We'd have to work through making sure the request would
get back to the right place (probably using GRUUs). We'd have to choose
or define a method (NOTIFY has been suggested, and the "must be in a dialog"
problems with that pointed out. INFO has the same problem. We could abuse
MESSAGE, but it's probably better just to define a new method if we decide
to go down this path.

3) Solve the problem with dialogs. Probably by starting with a new INVITE
that negotiates no (or baseline held) media.  Wherever that INVITE is
accepted, you end up with separate dialogs.  A separate REFER could then
be sent within each dialog, and would be guaranteed to be accepted in only
one place. This would mean defining behavior for that INVITE (probably
involving a Require extension), and detailing when that INVITE dialog
would shut down.

Does anyone see any other class of alternatives?

Again, my recommendation is that we don't pursue _any_ of them, and
go with the recognize-and-restrict approach I suggest at the beginning
of this message.

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Oct 2014 16:56:40 +0000

Hi,

+1 for "don't pursue _any_ of them".

Nothing prevents people from doing 3), but it's nothing we need to describe or mandate. I think it would be restrictive, as there is no guarantee that a REFER and INVITE would get forked to the same destinations, and we would never reach a destination that supports REFER, but does not support INVITE.

Regards,

Christer 

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 21 October 2014 19:23
To: [email-masked]
Subject: [sipcore] Dealing with the possibility of accepting multiple forked REFER requests

As Shinji pointed out, the whole reason we have immediate NOTIFY in subscription dialogs is that only one of the 200 OKs to a forked SUBSCRIBE will ever make it back to the subscriber. Trying to carry any information, like the proposed Refer-Events-At, in the response to a REFER that might fork is going to have the same problem.

A big "Thank You" to everyone who brainstormed possible ways we might do things differently. (I'll summarize and expand on what was discussed before the message is over).

After kicking this around for awhile, I think the right thing to do with this realization is acknowledge the limitation in the mechanism, rather than try to change the mechanism to avoid it.

My proposal will be to add text to the draft noting that if a REFER forks, and is accepted by more than one recipient, the UA sending the REFER will only learn the Refer-Events-At URI from one of those recipients, and which one is out of its control. So, the extension should only be used when that's ok for the application sending the REFER. That is, either there is enough information to know that the REFER will only be accepted in one place (as is the case if it is sent in-dialog, or Target-Dialog is provided in an out-of-dialog request), or the application doesn't care about tracking the resulting state if the request is accepted in more than one place. If things would go wrong if the REFER were accepted in more than one place and the referrer didn't learn about each of them, then the application must not use this extension (falling back into a 6665-subscription creating REFER instead).

I know that as engineers, we find this kind of shortcoming distateful.
But, pragmatically, there isn't a strong demand for solving the general problem.

If I'm wrong about that, and we decide we must figure out how to get information back from every place a forked REFER is accepted, I see three basic paths to choose from (based on the recent conversations, and some really old ones - remember HERFP - this is like that, only harder). Again, this is talking only about cases where the REFER might fork - we'll deal with in-dialog or other non-forking cases separately.

1) Modify proxy behavior to aggregate the responses. As pointed out on the list already, this really a non-starter - it means the proxy will have to hold the first 200 in case others arrive, forcing it into the bad places of long non-invite transactions as detailed in RFC4320 and RFC4321.

2) Send an out-of-dialog request from each accepting endpoint back in the other direction.  We'd have to work through making sure the request would get back to the right place (probably using GRUUs). We'd have to choose or define a method (NOTIFY has been suggested, and the "must be in a dialog"
problems with that pointed out. INFO has the same problem. We could abuse MESSAGE, but it's probably better just to define a new method if we decide to go down this path.

3) Solve the problem with dialogs. Probably by starting with a new INVITE that negotiates no (or baseline held) media.  Wherever that INVITE is accepted, you end up with separate dialogs.  A separate REFER could then be sent within each dialog, and would be guaranteed to be accepted in only one place. This would mean defining behavior for that INVITE (probably involving a Require extension), and detailing when that INVITE dialog would shut down.

Again, my recommendation is that we don't pursue _any_ of them, and go with the recognize-and-restrict approach I suggest at the beginning of this message.

RjS

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Oct 2014 12:04:33 -0500

> But, pragmatically, there isn't a strong demand for solving the 

Agreed on both counts.

> go with the recognize-and-restrict approach I suggest at the beginning

I agree with this approach. All three proposals are more complicated 
than the root problem we're trying to solve (unwanted NOTIFY messages); 
and, in fact, (2) is basically a proposal to send NOTIFY messages as 
part of an attempt to not send NOTIFY messages.

So, to be clear: I agree that we should document and accept the 
limitation imposed by forking in this scenario, but not add any 
mechanism to mitigate it.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2014 13:20:50 -0400

[as individual]

> go with the recognize-and-restrict approach I suggest at the beginning

I agree.

I'll also mention that one of the reasons people want this solution is 
that they want a solution that doesn't require the use of GRUUs. So 
solutions that themselves require GRUU are non-starters.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 23 Oct 2014 17:31:19 +0900

Hi,

thank you for an attentive summary.
I agree your recognize-and-restrict approach.

Shinji