Subject: [sipcore] OPTIONS 3xx: To fork or not to fork?

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Mar 2010 23:09:18 +0100

Hi,

Moving forward the the OPTIONS 3xx solution, one issue (raised by Paul, I think) is how a registrar, responsible for an AOR, makes a decission whether to send a 3xx response to a received OPTIONS request addressed for that AOR, or whether to fork the request towards the registered UAS(s).

Alternative 1:    The decission is based on local policy (by operators and/or other SDOs)

Alternative 2:    The registrar always sends a 3xx response.

Alternative 3:    The decission is based on some information contained in the OPTIONS request.

Again, we cannot do very much about existing deployments, but at least we would be able to provide clear guidelines for future implementations/specifications.

Regards,

Christer

NOTE: The issue only applies when the request is addressed to an AOR, and received by a registrar responseible for that AOR. In all other cases I assume the request will be forwarded by the proxy.

---

From: Adam Roach <[email-masked]>
Date: Mon, 01 Mar 2010 17:06:18 -0600

I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases 
that a proxy/registrar might fork an inbound request.

/a

On 3/1/10 16:09, Mar 1, Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2010 18:08:17 -0500

Unless we make some radical change in philosophy, the "proxy" has 
ultimate discretion here, though I think we could produce a BCP on it.

There is already a header that can be used to indicate your preference:

Request-Disposition: proxy
or
Request-Disposition: redirect

But it is still up to the proxy to honor it or not.

My recommendation for a BCP would be:
- honor Request-Disposition if present. Else
- return 3xx if there is more than one contact
- either 3xx or forward is ok if there is only one contact

This has to be discretionary because some may not want to return the 
registered contact to the caller. (Certainly *some* contact will have to 
be returned to the caller for an INVITE to succeed, but it might not be 
the registered contact. It might be a temp gruu, or something from an 
SBC, ...) And of course no contact has to be returned if the called UA 
rejects the request. And none need be returned for an OPTIONS either.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 06:52:07 +0100

Hi, 

>I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases that a proxy/registrar might fork an inbound request.

Just to clarify, I guess you don't include dialog establsihment requests (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if addressed to the AOR for which the registrar is responseible.

Regards,

Christer

> > Moving forward the the OPTIONS 3xx solution, one issue 
> (raised by Paul, I think) is how a registrar, responsible for 
> an AOR, makes a decission whether to send a 3xx response to a 
> received OPTIONS request addressed for that AOR, or whether 
> to fork the request towards the registered UAS(s).
> >
> > Alternative 3:    The decission is based on some 
> information contained in the OPTIONS request.
> >
> > Again, we cannot do very much about existing deployments, 
> but at least we would be able to provide clear guidelines for 
> future implementations/specifications.
> >
> > Regards,
> >
> > Christer
> >
> > NOTE: The issue only applies when the request is addressed 
> to an AOR, and received by a registrar responseible for that 
> AOR. In all other cases I assume the request will be 
> forwarded by the proxy.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 06:57:31 +0100

Hi, 

>Unless we make some radical change in philosophy, the "proxy" 
>has ultimate discretion here, though I think we could produce 
>a BCP on it.
> 

True. But, having clear guidelines will at least ensure (hopefully) that all have a common understanding on how to do it - whether they choose to implement/honor it or not.

>This has to be discretionary because some may not want to 
>return the registered contact to the caller. (Certainly 
>*some* contact will have to be returned to the caller for an 
>INVITE to succeed, but it might not be the registered 
>contact. It might be a temp gruu, or something from an SBC, 
>...)
>
>And of course no contact has to be returned if the 
>called UA rejects the request. And none need be returned for 
>an OPTIONS either.

If the proxy does not want to return a contact (other than its own perhaps), I guess it should not send a 3xx in the first place. In that case a 200 OK might be better?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 08:25:39 -0600

> Just to clarify, I guess you don't include dialog establsihment requests (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if addressed to the AOR for which the registrar is response…

Nope -- I mean INVITE and SUBSCRIBE as well. It's somewhat orthogonal to 
the discussion at hand, but it solves the HERFP problem in the general 
case, and it solves it perfectly.

/a

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 02 Mar 2010 08:58:37 -0600

------- Original message -------
> From: Paul Kyzivat <[email-masked]>
  What hapened to a 3xx with temp-gruus instead of contacts?

--
Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 2 Mar 2010 16:01:51 +0100

You mean bypassing all the RFC3261 forking logic in the proxy responsible
for the domain and pushing back that burden to the UAC?

/Hans Erik van Elburg

On Tue, Mar 2, 2010 at 3:25 PM, Adam Roach <[email-masked]> wrote:

>> Just to clarify, I guess you don't include dialog establsihment requests
>> (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if
>> addressed to the AOR for which the registrar is responseible.
>>
>>
>
> the discussion at hand, but it solves the HERFP problem in the general case,
> and it solves it perfectly.
>
> /a
>

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 02 Mar 2010 09:09:43 -0600

------- Original message -------
> From: Christer Holmberg <[email-masked]>
>

I think he really meant ALL REQUESTS. Replace forked-up behavior with more 
predictable redirection. When you really need downstream-node forking, you 
probably need to do it in a B28UA to handle all the possible responses, 
including media-path responses. Look at how Google Voice handles forking 
for an example. We have known for years that forking does not play well 
with PSTN gateways and early media, but have persistently failed to deal 
with that problem.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 10:26:58 -0500

>  What hapened to a 3xx with temp-gruus instead of contacts?

AFAIK it would be inappropriate for the proxy to select and return 
gruus, especially temp gruus in a 3xx. I think the UAS would have to do 
that. While the proxy could choose the perm gruu, its a policy decision 
to use the perm/temp gruu, and normally I think it would be the UAS that 
would make that decision.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 09:40:21 -0600

On 3/2/10 09:26, Mar 2, Paul Kyzivat wrote:
> gruus, especially temp gruus in a 3xx. I think the UAS would have to 
> do that. While the proxy could choose the perm gruu, its a policy 
> decision to use the perm/temp gruu, and normally I think it would be 
> the UAS that would make that decision.

I'm not sure why -- in this context, it's just an opaque cookie that the 
proxy/registrar minted for this one-time use and handed out.

I don't think people are proposing that this be a temp-gruu that the 
proxy actually issued to the terminal, so the terminal's policy about 
what to do with the temp-gruus it receives is maintained.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 11:00:28 -0500

> what to do with the temp-gruus it receives is maintained.

Oh, then you are postulating a new mechanism, similar to the temp gruu 
mechanism, but with (presumably) different value.

Certainly such is possible. We just haven't defined any such mechanism 
yet. I was going to say that it wouldn't even need to be standardized. 
But gruus tend to break a lot of other things unless special account is 
taken of them. So it probably does need to be specified.

This is likely a long road to go down, so we should only start down it 
if we are prepared for such a long journey.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 13:47:36 -0600

On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote:
> You mean bypassing all the RFC3261 forking logic in the proxy 
> responsible for the domain and pushing back that burden to the UAC?

Burden?

The client already has logic to handle this. Servers can throw 300-class 
responses back for INVITEs whenever they want. So the development cost 
is already built into every SIP terminal in the world. There is no 
additional software burden.

In terms of CPU burden... An average large network server has to handle 
several thousand or several tens of thousands of transactions per 
second. Your average terminal probably has to handle several dozen a 
day. Let's aim high and ballpark it around 0.001 transactions per second.

You honestly think that moving some small portion of processing from the 
thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the 
wrong direction?

Or it could be that I completely missed your point, since both of these 
interpretations of "burden" make your assertion nonsense. Would you like 
to clarify your statement?

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 21:40:37 +0100

Hi, 

>>I'm not sure why -- in this context, it's just an opaque cookie that 
>>the proxy/registrar minted for this one-time use and handed out.
>> 
>Oh, then you are postulating a new mechanism, similar to the temp gruu mechanism, but with (presumably) different value.
>
>Certainly such is possible. We just haven't defined any such mechanism yet. I was going to say that it wouldn't even need to be standardized. 
>But gruus tend to break a lot of other things unless special account is taken of them. So it probably does need to be specified.
>
>This is likely a long road to go down, so we should only start down it if we are prepared for such a long journey.

I think we shall start from the fact that the registrar returns a Contact header field for the UAS(s) in the 3xx response.

Then, if the registrar includes the actual UAS contact information, or something else, could be a policy decission. It is not really bound to the 3xx mechanism itself - as long as the UAC can use whatever was returned to contact the UAS(s).

Regarding the usage of gruus, I don't see any problem/risk in returning the perm-gruu, but agin, that could be a policy decission.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 15:55:48 -0500

Christer,

I agree - its mostly policy.

If somebody referenced the AoR, then it seems like it ought to be ok to 
return the public gruu, since that doesn't disclose anything the caller 
didn't already know. However that may not be true if the call was 
forwarded. E.g.

Alice calls Bob, who forwards the call to Carol.
However, Bob may not want Alice to know it was forwarded to Carol, or 
Carol might be willing to take the call for Bob, but doesn't want her 
AoR disclosed to Alice.

If this were an INVITE reaching Carol's phone, it could use a temp gruu 
to hide identity. The proxy for Carol could perhaps do that on her 
behalf based on policy, but there might need to be new gruu-like 
mechanisms to do so.

Nevertheless, I think we can simply specify that the 3xx contain 
contacts that reference each candidate UA.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 21:57:28 +0100

Hi, 

>>>I would like to see #2 as a BCP. Not just for OPTIONS, but for all 
>>>cases  that a proxy/registrar might fork an inbound request.
>>
>>Just to clarify, I guess you don't include dialog establsihment 
>>requests (INVITE, SUBSCRIBE)? They should always be forwarded/forked 
>>even if addressed to the AOR for which the registrar is responseible.
>
>I think he really meant ALL REQUESTS. Replace forked-up behavior with more predictable redirection. When you really need downstream-node forking, you probably need to do it in a B28UA to handle all the 
>possible responses, including media-path responses. Look at how Google Voice handles forking for an example. We have known for years that forking does not play well with PSTN gateways and early media, 
>but have persistently failed to deal with that problem.

I think serial forking can normally be handled pretty well, when it comes to early media etc.

The problem is generally parallel forking.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 22:10:26 +0100

Hi,

It sure is an interesting idea. But, apart from the fact that it would give the UAC total control on which UAS(s) to contact, when and in which order to contact them, would it bring much advantage from using parallel forking, perhaps together with feature tags in order to "control" the forking? 

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 2. maaliskuuta 2010 21:48
To: Hans Erik van Elburg
Cc: Christer Holmberg; SIPCORE
Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork?

Burden?

The client already has logic to handle this. Servers can throw 300-class responses back for INVITEs whenever they want. So the development cost is already built into every SIP terminal in the world. There is no additional software burden.

In terms of CPU burden... An average large network server has to handle several thousand or several tens of thousands of transactions per second. Your average terminal probably has to handle several dozen a day. Let's aim high and ballpark it around 0.001 transactions per second.

You honestly think that moving some small portion of processing from the thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong direction?

Or it could be that I completely missed your point, since both of these interpretations of "burden" make your assertion nonsense. Would you like to clarify your statement?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 16:29:39 -0500

> It sure is an interesting idea. But, apart from the fact that it would give the UAC total control on which UAS(s) to contact, when and in which order to contact them, would it bring much advantage…

It provides the UAC with the opportunity for a richer UI with more 
control for the end user. And it provides a way to do parallel forking 
without the early media issues.

In a way its also a "poor man's presence".

But as long as it isn't mandatory, UACs will still have to deal with all 
the troublesome forking issues too.

It might be better to really use presence instead. The big problem I see 
with that is that typically people will only provide presence data to a 
limited number of their buddies, whereas you potentially want this for 
all callers. That could perhaps be dealt with by giving the presence 
server a "public presence" policy for what you are willing to disclose 
to anybody, and perhaps couple that with a restriction to just polling 
rather than a long term subscription.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 22:34:26 +0100

Hi, 

>>It sure is an interesting idea. But, apart from the fact that it would give the UAC total control on which UAS(s) to contact, when and in which order to contact them, would it bring much advantage from 
>>using parallel forking, perhaps together with feature tags in order to "control" the forking? 
>
>It provides the UAC with the opportunity for a richer UI with more control for the end user. And it provides a way to do parallel forking without the early media issues.

Perhaps, but then you will also need to take charging/serivce aspects etc into account. Without a correlation mechanism, I guess all these "parallel forks" from the UAC would be seen as separate calls.

>But as long as it isn't mandatory, UACs will still have to deal with all the troublesome forking issues too.

Again, I think using serial forking would solve lots of problems :)

>It might be better to really use presence instead. The big problem I see with that is that typically people will only provide presence data to a limited number of their buddies, whereas you potentially 
>want this for all callers. That could perhaps be dealt with by giving the presence server a "public presence" policy for what you are willing to disclose to anybody, and perhaps couple that with a 
>restriction to just polling rather than a long term subscription.

Would presence work with PSTN gateways?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 17:00:51 -0500

> Perhaps, but then you will also need to take charging/serivce aspects etc into account. Without a correlation mechanism, I guess all these "parallel forks" from the UAC would be seen as separate ca…

Yes. But it doesn't change the reality of the situation. Assuming only 
one of the forks answers, the others are just "failed" call attempts 
that AFAIK are not normally charged.

> Again, I think using serial forking would solve lots of problems :)

Sure, but its not always what you want.
Its quite reasonable that you would want your office phone and your cell 
phone to ring in parallel so you are perceived as being equally 
responsive regardless of where you are.

> Would presence work with PSTN gateways?

In principle a PSTN gateway could support presence subscriptions (easier 
if they are just polling calls). But in the end it doesn't have much 
information to offer. Typically there won't be multiple contacts.

So failing to support presence in this case just means falling back to a 
basic call.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 2 Mar 2010 23:47:45 +0100

Burden as in handling the forking process. Didn't ment to overload that with
lots of negative meaning.

I thought the first part was more interesting. Where every forking proxy
becomes a redirect server.

There are also other consequences, where youre home proxy will always have
the same way of handling youre contacts q-values. UAC's come in a lot of
different flavors, they will all behave slightly different and most probably
some will misbehave. So the UAS's owner loose some predictability about how
incoming calls will be handled. No consistent experience, hard to explain.

Also users will want to have services or policies be executed on their
behalf on their home proxy, how does such approach impact that.

Does such model mean anything to call setup delays, considering lets say
scenarios where there are several intermediary proxies interconnecting some
corporate voip clouds.

Where the 3xx approach is very elegant in some cases, to say as a general
BCP that any forking proxy should send 3xx also for INVITEs in any forking
case seems in that respect over the top.

/Hans Erik van Elburg

On Tue, Mar 2, 2010 at 8:47 PM, Adam Roach <[email-masked]> wrote:

> responses back for INVITEs whenever they want. So the development cost is
> already built into every SIP terminal in the world. There is no additional
> software burden.
>
> several thousand or several tens of thousands of transactions per second.
> Your average terminal probably has to handle several dozen a day. Let's aim
> high and ballpark it around 0.001 transactions per second.
>
> thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong
> direction?
>
> interpretations of "burden" make your assertion nonsense. Would you like to
> clarify your statement?
>
> /a
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 06:52:07 +0100

Hi,

>Yes. But it doesn't change the reality of the situation. Assuming only one of the forks answers, the others are just "failed" call attempt that AFAIK are not normally charged.

True. But, there could be network services etc which are triggered for each INVITE, which might not be the desired behavior, etc etc etc. I am just saying the potential impacts would need to be studied.

One could say that all this is already allowed, but I doubt many (if any) UACs would start sending multiple new INVITEs if it received a 3xx response to the previous INVITE.

>responsive regardless of where you are.

Sure. It would be good if the forking proxy, in the case of parallel forking, could tell the UAS(s) to not send early media.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 01:11:01 -0600

On Mar 2, 2010, at 1:47 PM, Adam Roach wrote:

> The client already has logic to handle this. Servers can throw 300- 
> class responses back for INVITEs whenever they want. So the  
> development cost is already built into every SIP terminal in the  
> world. There is no additional software burden.
>
> In terms of CPU burden... An average large network server has to  
> handle several thousand or several tens of thousands of transactions  
> per second. Your average terminal probably has to handle several  
> dozen a day. Let's aim high and ballpark it around 0.001  
> transactions per second.
>
> You honestly think that moving some small portion of processing from  
> the thing doing 10,000 TPS to the thing doing 0.001 TPS is going in  
> the wrong direction?
>
> Or it could be that I completely missed your point, since both of  
> these interpretations of "burden" make your assertion nonsense.  
> Would you like to clarify your statement?
>

Well, somebody has to deal with the burden of resolving all those  
early-media streams and figuring out which one to render to the user.  
This is a hard problem, so whoever gets doing it is going to have to  
devote some resources to doing it right. On the other hand, it's  
arguably impossible for a proxy to do it right, so giving the  
additional state to the UAC needed for it to come up with a reasonable  
solution might not be an unreasonable burden.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 01:16:28 -0600

On Mar 2, 2010, at 3:10 PM, Christer Holmberg wrote:

>
> Hi,
>
> It sure is an interesting idea. But, apart from the fact that it  
> would give the UAC total control on which UAS(s) to contact, when  
> and in which order to contact them, would it bring much advantage  
> from using parallel forking, perhaps together with feature tags in  
> order to "control" the forking?

Since it gives the UAC a separate O/A cycle for each media set, it at  
least makes it possible for the UA to correlate received media with a  
specific UAS. This would appear to make automated handling of the  
media channels in the UAC much more feasible; for example, the UAC  
respond with media saying "Press 1 if you're REALLY answering this  
call", then only connect the media flow to the user if a "1" is heard  
in response. This is what everything that parallel-forks through PSTN  
gateways pretty much has to do to work right.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 01:18:56 -0600

On Mar 2, 2010, at 3:34 PM, Christer Holmberg wrote:

>>> from
>> control for the end user. And it provides a way to do parallel  
>> forking without the early media issues.
>
> Perhaps, but then you will also need to take charging/serivce  
> aspects etc into account. Without a correlation mechanism, I guess  
> all these "parallel forks" from the UAC would be seen as separate  
> calls.

They are, aren't they? If the carrier chooses not to bill for them  
separately, that's up to the carrier.

>> But as long as it isn't mandatory, UACs will still have to deal  
>> with all the troublesome forking issues too.
>

Explain how serial forking resolves the "PSTN-fork that went to voice  
mail" scenario?

>> It might be better to really use presence instead. The big problem  
>> I see with that is that typically people will only provide presence  
>> data to a limited number of their buddies, whereas you potentially
>> want this for all callers. That could perhaps be dealt with by  
>> giving the presence server a "public presence" policy for what you  
>> are willing to disclose to anybody, and perhaps couple that with a

Nope.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 01:22:22 -0600

On Mar 2, 2010, at 4:00 PM, Paul Kyzivat wrote:

>>>> from using parallel forking, perhaps together with feature tags  
>>>> in order to "control" the forking?
> Yes. But it doesn't change the reality of the situation. Assuming  
> only one of the forks answers, the others are just "failed" call  
> attempts that AFAIK are not normally charged.

But what happens when multiple of them are "answered", either with  
early media or a real session?

> In principle a PSTN gateway could support presence subscriptions  
> (easier if they are just polling calls). But in the end it doesn't  
> have much information to offer. Typically there won't be multiple  
> contacts.

One of my inbound phone numbers forks to as many as 6 different phone  
numbers. All of those phone numbers have their own voice mail system,  
but if the incoming call is not answered by "a human", the system is  
smart enough to route the call to a special voice-mail system for the  
DID number. There have been systems with this functionality for years;  
it just doesn't work with proxy-forking in SIP.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 01:24:58 -0600

On Mar 2, 2010, at 4:47 PM, Hans Erik van Elburg wrote:

> Burden as in handling the forking process. Didn't ment to overload  
> that with lots of negative meaning.
>
> I thought the first part was more interesting. Where every forking  
> proxy becomes a redirect server.
>
> There are also other consequences, where youre home proxy will  
> always have the same way of handling youre contacts q-values. UAC's  
> come in a lot of different flavors, they will all behave slightly  
> different and most probably some will misbehave. So the UAS's owner  
> loose some predictability about how incoming calls will be handled.  
> No consistent experience, hard to explain.
>
> Also users will want to have services or policies be executed on  
> their behalf on their home proxy, how does such approach impact that.

Then the home proxy has to act as  a B2BUA and do the expansion into  
multiple connected calls itself.

>
> Does such model mean anything to call setup delays, considering lets  
> say scenarios where there are several intermediary proxies  
> interconnecting some corporate voip clouds.
>
> Where the 3xx approach is very elegant in some cases, to say as a  
> general BCP that any forking proxy should send 3xx also for INVITEs  
> in any forking case seems in that respect over the top.

There are non-gateway scenarios where parallel forking actually works.  
We don't find them very often.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 09:05:30 +0100

Hi,

I've changed the subject.

>>It sure is an interesting idea. But, apart from the fact that it would 
>>give the UAC total control on which UAS(s) to contact, when and in 
>>which order to contact them, would it bring much advantage 
>>from using parallel forking, perhaps together with feature tags in order to 
>>"control" the forking?
> 
>Since it gives the UAC a separate O/A cycle for each media 
>set, it at least makes it possible for the UA to correlate 
>received media with a specific UAS. This would appear to make 
>automated handling of the media channels in the UAC much more 
>feasible; for example, the UAC respond with media saying 
>"Press 1 if you're REALLY answering this call", then only 
>connect the media flow to the user if a "1" is heard in 
>response. This is what everything that parallel-forks through 
>PSTN gateways pretty much has to do to work right.

I think that such call selection can also be done by an B2BUA in the network.

Keep in mind that even if only one specific media stream is played to the user behind the UAC, the fact that multiple media streams are sent towards the UAC can cause resource issues. So, in my opinion the best thing is to try to only send the media stream towards the UAC that will be played to the user.

>>Perhaps, but then you will also need to take charging/serivce aspects 
>>etc into account. Without a correlation mechanism, I guess all these 
>>"parallel forks" from the UAC would be seen as separate calls.
>
>They are, aren't they? If the carrier chooses not to bill for them separately, that's up to the carrier.

Yes, but how does the carrier do that?

Also, applying the same service (e.g. some kind of anouncement) to all those "calls" is not very optimized usage of service resources.

>Explain how serial forking resolves the "PSTN-fork that went to voice mail" scenario?

Could you explain that scenario? :)

One would also need to take into account the trust issue related with INVITE 3xx. What if the new INVITE is sent to some expensive service number? Yes, in some phones you may allow the user to actually decided whether to trigger a new INVITE, but it won't always work.

Regards,

Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 3 Mar 2010 09:42:55 +0100

Forking in essence  is a service provided by a downstream proxy (serving
domein B.com) to a user that has multiple devices registered to this proxy.
This service (served to him by his own domain) will allow him to receive
calls at any of his devices.

To push the responsibility for providing  this service of a B.com user to
another domain lets say A.com, is to say the least problematic. Even if it
solves some issues like those related to early media and HERFP, it
introduces lots of other issues.

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Mar 2010 10:37:08 +0100

Serial forking with early media depends on support for PRACK and UPDATE, which are not mandatory items for UAs and therefore will not always be available.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 02 March 2010 20:57
> To: 'Dean Willis'
> Cc: [email-masked]
> >I think he really meant ALL REQUESTS. Replace forked-up 
> behavior with more predictable redirection. When you really 
> need downstream-node forking, you probably need to do it in a 
> B28UA to handle all the 
> >possible responses, including media-path responses. Look at 
> how Google Voice handles forking for an example. We have 
> known for years that forking does not play well with PSTN 
> gateways and early media,

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Mar 2010 10:40:51 +0100

I would like to expand on this issue a little. Suppose I have at my home proxy a policy whereby calls go to B1 and B2 in parallel, and after T seconds of no answer calls instead go to B3 (voicemail, perhaps). There is no way that the proxy could convey that policy in a 3xx response to the UAC. To make this policy (or similar policies) work, the proxy would need to manufacturer temporary contact URIs that map to B1 and B2 and send these back in a 302. It would then need to hope that the UAC does indeed establish new requests in parallel to the two temporary contacts for B1 and B2. The proxy would need to treat the two requests as related and if both are unanswered after T seconds, reject one with a 4xx and the other with a 302 (this time with a third temporary contact URI mapped to B3). So policy CAN be met by the proxy, although with dependence on the UAC doing the right thing.

Elsewhere in this thread, somebody mentioned charging. The fact is that calls might cross a domain that charges (e.g., for international calls via a server provider into an enterprise that has a proxy that makes use of 302 responses to achieve forking). Since only one of the calls should normally be answered (or if a second is answered it should be cleared very quickly), charging based on duration after answer should not be a big issue. However, if a domain charges for call establishment attempts, it could be a problem. In this example, the domain handling the international leg would not be aware that the multiple calls are really part of the same call. I don't know whether this is an issue in practice or not.

John

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 03 March 2010 07:25
> To: Hans Erik van Elburg
> Cc: SIPCORE

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 11:51:08 +0100

Hi,

>Serial forking with early media depends on support for PRACK 
>and UPDATE, which are not mandatory items for UAs and 
>therefore will not always be available.

Well, that depends on how it is implemented, and if you want to give the UAC control of the early media.

But, even if the UAC is not able to control early media, serial forking will at least ensure a single early media stream at a certain time.

Regards,

Christer

> > behavior with more predictable redirection. When you really need 
> > downstream-node forking, you probably need to do it in a B28UA to 
> > handle all the
> > how Google Voice handles forking for an example. We have known for 
> > years that forking does not play well with PSTN gateways and early 
> > media,

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 11:56:37 +0100

Hi,

>I would like to expand on this issue a little. Suppose I have 
>at my home proxy a policy whereby calls go to B1 and B2 in 
>parallel, and after T seconds of no answer calls instead go 
>to B3 (voicemail, perhaps). There is no way that the proxy 
>could convey that policy in a 3xx response to the UAC. To 
>make this policy (or similar policies) work, the proxy would 
>need to manufacturer temporary contact URIs that map to B1 
>and B2 and send these back in a 302. It would then need to 
>hope that the UAC does indeed establish new requests in 
>parallel to the two temporary contacts for B1 and B2. The 
>proxy would need to treat the two requests as related and if 
>both are unanswered after T seconds, reject one with a 4xx 
>and the other with a 302 (this time with a third temporary 
>contact URI mapped to B3). So policy CAN be met by the proxy, 
>although with dependence on the UAC doing the right thing.
> 
>Elsewhere in this thread, somebody mentioned charging. The 
>fact is that calls might cross a domain that charges (e.g., 
>for international calls via a server provider into an 
>enterprise that has a proxy that makes use of 302 responses 
>to achieve forking). Since only one of the calls should 
>normally be answered (or if a second is answered it should be 
>cleared very quickly), charging based on duration after 
>answer should not be a big issue. However, if a domain 
>charges for call establishment attempts, it could be a 
>problem. In this example, the domain handling the 
>international leg would not be aware that the multiple calls 
>are really part of the same call. I don't know whether this 
>is an issue in practice or not.

I am the one who mentioned charging.

Maybe charging as such is not a big problem. I am more concerned about how network services are affected.

In your example above, where B1 sends 4xx and B2 sends 302, the forking proxy needs to know that the calls are related. Maybe some correlation header field can be used for that, or maybe it can somehow be embedded into the temporary contact URI, but the correlation still needs to be there.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Mar 2010 12:49:54 -0500

Hans Erik van Elburg wrote:
> domein B.com) to a user that has multiple devices registered to this 
> proxy. This service (served to him by his own domain) will allow him to 
> receive calls at any of his devices.
> 
> To push the responsibility for providing  this service of a B.com user 
> to another domain lets say A.com, is to say the least problematic. Even 
> if it solves some issues like those related to early media and HERFP, it 

Forking downstream doesn't relieve the upstream device of burden, it 
simply makes it be a different burden.

If the downstream server wants to take this on, a B2BUA could be a 
better choice.

And regardless of whether user B views this as a service to him, user A 
may also regard it as a service to him to see the multiple contacts and 
be able to choose among them.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 3 Mar 2010 19:06:11 +0100

Demonstrating the point that a simple BCP saying "though shalt always send
3xx in all INVITE forking cases" is not appropriate.

More inline...

/Hans Erik van Elburg

On Wed, Mar 3, 2010 at 6:49 PM, Paul Kyzivat <[email-masked]> wrote:

> Forking downstream doesn't relieve the upstream device of burden, it simply
> makes it be a different burden.
>
> Agree.

> If the downstream server wants to take this on, a B2BUA could be a better
> choice.
>
> Maybe.

> And regardless of whether user B views this as a service to him, user A may
> also regard it as a service to him to see the multiple contacts and be able
> to choose among them.
>
> Well it is hard to see how B's forking proxy's behaviour for INVITEs can be
seen as a service to A. Also INVITE does not express A's wish to see B's
contacts, but a wish of A's UA to establish a session with whatever UA that
B registered.

Of course A may want to know B's multiple contacts, but if you phrase it
like that it is indeed more of a presence use case and you would not use
INVITE for that.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 21:03:00 +0100

Hi,

I am not sure a BCP can say "SHALL" about anything...

Also, I don't think we could mandate such behavior. Too many things would get messed up.

Do I see "SIP 3.0" on Dean's lips? ;)

Regards,

Christer

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: 3. maaliskuuta 2010 20:06
To: Paul Kyzivat
Cc: Christer Holmberg; SIPCORE
Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?]

Demonstrating the point that a simple BCP saying "though shalt always send 3xx in all INVITE forking cases" is not appropriate.

More inline...

/Hans Erik van Elburg

On Wed, Mar 3, 2010 at 6:49 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Hans Erik van Elburg wrote:
Forking in essence  is a service provided by a downstream proxy (serving domein B.com) to a user that has multiple devices registered to this proxy. This service (served to him by his own domain) will allow him to receive calls at any of his devices.

To push the responsibility for providing  this service of a B.com user to another domain lets say A.com, is to say the least problematic. Even if it solves some issues like those related to early media and HERFP, it introduces lots of other issues.

Forking downstream doesn't relieve the upstream device of burden, it simply makes it be a different burden.

Agree.

If the downstream server wants to take this on, a B2BUA could be a better choice.

Maybe.

And regardless of whether user B views this as a service to him, user A may also regard it as a service to him to see the multiple contacts and be able to choose among them.

Well it is hard to see how B's forking proxy's behaviour for INVITEs can be seen as a service to A. Also INVITE does not express A's wish to see B's contacts, but a wish of A's UA to establish a session with whatever UA that B registered.

Of course A may want to know B's multiple contacts, but if you phrase it like that it is indeed more of a presence use case and you would not use INVITE for that.

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 10:51:37 -0600

On Mar 3, 2010, at 2:42 AM, Hans Erik van Elburg wrote:

> Forking in essence  is a service provided by a downstream proxy  
> (serving domein B.com) to a user that has multiple devices  
> registered to this proxy. This service (served to him by his own  
> domain) will allow him to receive calls at any of his devices.

That's how it works in theory. In practice, it doesn't work all that  
well, as some of user B's devices are going to be either PSTN phones,  
or nodes that implement their own voicemail service. In other words,  
they're going to send back a media flow, either before or after a 200  
OK. A forking proxy cannot reconcile this; it requires a UA, either a  
B2BUA as Christer suggests, or all the way back to the originating  
user. And if the media streams are a result of a forking proxy, then  
the UA lacks sufficient information for sorting it out.

In other words, either fork in a B2BUA and be prepared to deal with  
the media, or send a 3XX.

>
> To push the responsibility for providing  this service of a B.com  
> user to another domain lets say A.com, is to say the least  
> problematic. Even if it solves some issues like those related to  
> early media and HERFP, it introduces lots of other issues.

However, those other issues are arguably tractable, in that at least  
the UA now has the information needed to do something intelligent  
rather than just failing. And "just failing" is what happens now to  
forked calls where multiple legs have early or late media.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 10:52:38 -0600

On Mar 3, 2010, at 3:37 AM, Elwell, John wrote:

> Serial forking with early media depends on support for PRACK and  
> UPDATE, which are not mandatory items for UAs and therefore will not  
> always be available.
>

As always, I think early media was just a really bad idea. But we  
always dance away from trying to fix the problem.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 10:59:14 -0600

On Mar 3, 2010, at 3:40 AM, Elwell, John wrote:

> I would like to expand on this issue a little. Suppose I have at my  
> home proxy a policy whereby calls go to B1 and B2 in parallel, and  
> after T seconds of no answer calls instead go to B3 (voicemail,  
> perhaps). There is no way that the proxy could convey that policy in  
> a 3xx response to the UAC. To make this policy (or similar policies)  
> work, the proxy would need to manufacturer temporary contact URIs  
> that map to B1 and B2 and send these back in a 302. It would then  
> need to hope that the UAC does indeed establish new requests in  
> parallel to the two temporary contacts for B1 and B2. The proxy  
> would need to treat the two requests as related and if both are  
> unanswered after T seconds, reject one with a 4xx and the other with  
> a 302 (this time with a third temporary contact URI mapped to B3).  
> So policy CAN be met by the proxy, although with dependence on the  
> UAC doing the right thing.

So here, we either need your home proxy to be a home B2BUA (After all,  
what happens when B1 and B2 both send back early media, or both get  
answered by a bot?), OR we need a richer 302 response that conveys  
"Try these two destinations in parallel, and if neither replies in X  
seconds, try this third destination).

Either is tractable. Admittedly, the second requires extending the  
specification of a 302 response, but we have the capacity to do this.  
A few standardized parameters would work fine, with no backward  
compatibility issues for  older nodes that don't understand the  
parameters. Much could be done with q-values.

>
> Elsewhere in this thread, somebody mentioned charging. The fact is  
> that calls might cross a domain that charges (e.g., for  
> international calls via a server provider into an enterprise that  
> has a proxy that makes use of 302 responses to achieve forking).  
> Since only one of the calls should normally be answered (or if a  
> second is answered it should be cleared very quickly), charging  
> based on duration after answer should not be a big issue. However,  
> if a domain charges for call establishment attempts, it could be a  
> problem. In this example, the domain handling the international leg  
> would not be aware that the multiple calls are really part of the  
> same call. I don't know whether this is an issue in practice or not.

The real question is "who gets charged, and are they surprised by it?"

If the "home proxy" is forwarding the call to a toll destination, then  
either the "home proxy" needs to get charged for the toll (making it  
more B2BUA is), or the originating user needs to get charged for it,  
in which case the originating user needs to know about the toll  
destination (requiring a 302).

Having your home proxy do conventional SIP forking just doesn't work  
here.

--
Dean

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 4 Mar 2010 12:04:22 -0500

emphatic +1 to Dean's wise comment

G

On Mar 4, 2010, at 11:52 AM, Dean Willis wrote:

> As always, I think early media was just a really bad idea. But we always dance away from trying to fix the problem.
> 
> --
> Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Mar 2010 12:50:22 -0500

inline

Dean Willis wrote:
>> perhaps). There is no way that the proxy could convey that policy in a 
>> 3xx response to the UAC. To make this policy (or similar policies) 
>> work, the proxy would need to manufacturer temporary contact URIs that 
>> map to B1 and B2 and send these back in a 302. It would then need to 
>> hope that the UAC does indeed establish new requests in parallel to 
>> the two temporary contacts for B1 and B2. The proxy would need to 
>> treat the two requests as related and if both are unanswered after T 
>> seconds, reject one with a 4xx and the other with a 302 (this time 
>> with a third temporary contact URI mapped to B3). So policy CAN be met 
>> by the proxy, although with dependence on the UAC doing the right thing.
> 
> answered by a bot?), OR we need a richer 302 response that conveys "Try 
> these two destinations in parallel, and if neither replies in X seconds, 
> try this third destination).
> 
> specification of a 302 response, but we have the capacity to do this. A 
> few standardized parameters would work fine, with no backward 

This capability is (arguably) already there:

provide two contacts with equal q-values, and the third with a smaller 
q-value.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Mar 2010 09:00:56 +0100

Hi,

Paul suggested that a UAC would use the Request-Disposition header to indicate whether forking proxy should proxy (using the "proxy" R-D value) the OPTIONS request, or send a 3xx response (using the "redirect" R-D value).

Now, assuming "redirect" is used, the question is:

If the request also contains an Accept-Contact/Reject-Contact header field, would the proxy in the 3xx response only include contacts which matches the A-C/R-C criterias (in the same way as the proxy would only fork towards UAS(s) that matches the criterias)?

I can't find any text in 3841 whichs indicates that A-C is not applicable when "R-D:redirect" is used.

I think that would be a good feature.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Mar 2010 08:11:46 -0500

Yes, I would certainly expect that A-C would apply to selecting the 
contacts returned in the 3xx response.

	Thanks,
	Paul