Subject: [sipcore] OPTIONS: How to solve the forking problem?

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Feb 2010 12:28:23 +0100

Hi,

Some input regarding the OPTIONS issue.

BACKGROUND:
============

One of the main problems with OPTIONS is forking. In case the request is forked, the UAC will only receive the capabilities of one device/UAS (which UAS depends on which 200 OK reaches the forking proxy first).

OPTIONS works fine in HTTP, where we don't have forking and an HTTP URI always identify uniquely a specific resource or a specific server.

But, if I address the request to an AOR (which points to a domain, not to a specific device) I might want to receive capabilities of all the UAS associated with that AOR/domain.

First, do we agree that is a valid usage to address OPTIONS to an AOR?

OR, do we think that OPTIONS should only be addressed to specific devices (section 11 of 3261 talks about devices), in which case I guess we don't need to do anything - at least not as far as forking is concerned.

The rest of this e-mail is based on the assumption that we DO want to be able to address OPTIONS to an AOR.

ABSTRACT:
=========

I have put together 3 alternative solutions on how the problem could be fixed. The first alternative is based on a UAS change, while the second and third alternatives are based on a model where the registrar (forking proxy) sends a response "on behalf" of the UAS(s).

The 4th alternative is of course that we do nothing, but based on previous discussions it does seem that some people are interested in doing something about OPTIONS.

ALTERNATIVE 1:
=============

In this alternative the UAS(s) send a provisional response, including the capabilities, to the OPTIONS request. The registrar will (hopefully) forward all the provisional responses towards the UAC.

Pros/cons:
----------------

+ The major advantage of this mechanism is that it allows the UAC to get the capabilities of all UAS(s) associated with the AOR.
+ No impacts on registrar

- Does not work with deployed Uas
- Would the provisional response need to be PRACKed?

What to do:
-----------------

This alternative would most likely require an RFC: either an extension with an associated option-tag, or an update to 3261.

ALTERNATIVE 2:
=============

In this alternative the registrar never forks the OPTIONS request towards the UAS(s). Instead, it sends a response on behalf of the UASs, based on the information is has about the UAS(s), based on registration information (feature tags etc) etc.

The first question is whether 3261 already allows this:

When a UAC sends an OPTIONS request addressed to an AOR, I expect to get capabilities associated with that AOR (which points to a domain, not to a specific device). Currently, in case of forking, I will only get the capabilities from one device/UAS associated with that domain.

But, if the registrar sends the OPTIONS response, it can provide capabilities of all registered UAS(s) associated with the AOR/domain.

So, so far I don't think 3261 forbids this kind of behavior (in fact, I think this kind of behavior actually better implements what is described in 3261...)

Now, the best way to return the capabilities would probably be by using a message body, e.g. a multipart with sipfrag body parts (each sipfrag body part representing a UAS).

But, RFC3261 says that a proxy does not insert a message body in the OPTIONS response, and that is probably ok in most cases when the proxy returns its owns capabilities. But, when the proxy replies on behalf of the UAS(s), I see no reason why it should not be allowed to include a body. The UAC will get the capabilities of the UAS(s), and that is what matters.

Pros/cons:
----------------

+ The major advantage of this mechanism is that it allows the UAC to get the capabilities of all UAS(s) associated with the AOR.
+ In my personal opinion this does not require any changes in RFC3261

- The set of capabilities per UAS is limited to what the registrar knows about the UAS (based on registration information, and/or by provisioning), so SDP information would probably be left out. The mechanism might still be good enough for many scenarios, though.

What to do:
-----------------

If we think RFC3261 allows this, the question is whether we consider it so crystal clear that nothing needs to be specified, or whether it would be a good idea to put together a BCP type-of document describing it.

Or, do people think that this is NOT allowed behavior?

ALTERNATIVE 3:
=============

The idea is similar to Alternative 1, but in this case the registrar would fork the OPTIONS request towards the UAS(s), then "COLLECT" the responses, and finally send a single response which contains the capabilities of all UAS(s) towards the UAC.

Prox/Cons:
----------------

+ The major advantage of this mechanism is that it allows the UAC to get the capabilities of all UAS(s).
+ The UAC will get more or less the same set of capabilities for an UAS, as if the UAS would have sent the response directly to the UAC.

- I guess most people would consider the forking proxy acting as a B2BUA in this case, since it does not follow the 3261 rules about forwarding (or discarding) 200 OK responses immediately when received.

What to do:
-----------------

If we think this is a good solution, could it be described in a BCP? I guess we would not update 3261 to describe this behavior?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Feb 2010 14:59:20 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 19 February 2010 11:28
> To: SIPCORE
> Subject: [sipcore] OPTIONS: How to solve the forking problem?
> 
> Hi,
>  
> One of the main problems with OPTIONS is forking. In case the 
> request is forked, the UAC will only receive the capabilities 
> of one device/UAS (which UAS depends on which 200 OK reaches 
> the forking proxy first).
>  
> OPTIONS works fine in HTTP, where we don't have forking and 
> an HTTP URI always identify uniquely a specific resource or a 
> specific server. 
>  
> But, if I address the request to an AOR (which points to a 
> domain, not to a specific device) I might want to receive 
> capabilities of all the UAS associated with that AOR/domain. 
>  
> OR, do we think that OPTIONS should only be addressed to 
> specific devices (section 11 of 3261 talks about devices), in 
> which case I guess we don't need to do anything - at least 
> not as far as forking is concerned.
>  
> The rest of this e-mail is based on the assumption that we DO 
> want to be able to address OPTIONS to an AOR.
>  
>  
> ABSTRACT:
> =========
>  
> I have put together 3 alternative solutions on how the 
> problem could be fixed. The first alternative is based on a 
> UAS change, while the second and third alternatives are based 
> on a model where the registrar (forking proxy) sends a 
> response "on behalf" of the UAS(s).
>  
> The 4th alternative is of course that we do nothing, but 
> based on previous discussions it does seem that some people 
> are interested in doing something about OPTIONS.
>  
>  
> ALTERNATIVE 1:
> =============
>  
> In this alternative the UAS(s) send a provisional response, 
> including the capabilities, to the OPTIONS request. The 
> registrar will (hopefully) forward all the provisional 
> responses towards the UAC.
>  
> Pros/cons:
> ----------------
>  
> + The major advantage of this mechanism is that it allows the 
> UAC to get the capabilities of all UAS(s) associated with the AOR.
[JRE] I hope this Alternative 1 is not meant to be serious. This would be contrary to the RFC3261 recommendation "UASs SHOULD NOT issue a provisional response for a non-INVITE request". I wonder how many SIP stacks would handle this. Also, having sent a provisional response, the UAS needs to send a final response, so how would this interact?

>  
> What to do:
> -----------------
>  
> This alternative would most likely require an RFC: either an 
> extension with an associated option-tag, or an update to 3261.
>  
>  
>  
> ALTERNATIVE 2:
> =============
>  
> In this alternative the registrar never forks the OPTIONS 
> request towards the UAS(s). Instead, it sends a response on 
> behalf of the UASs, based on the information is has about the 
> UAS(s), based on registration information (feature tags etc) etc.
>  
> When a UAC sends an OPTIONS request addressed to an AOR, I 
> expect to get capabilities associated with that AOR (which 
> points to a domain, not to a specific device). Currently, in 
> case of forking, I will only get the capabilities from one 
> device/UAS associated with that domain.
>  
> But, if the registrar sends the OPTIONS response, it can 
> provide capabilities of all registered UAS(s) associated with 
> the AOR/domain.
>  
> So, so far I don't think 3261 forbids this kind of behavior 
> (in fact, I think this kind of behavior actually better 
> implements what is described in 3261...)
>  
>  
> Now, the best way to return the capabilities would probably 
> be by using a message body, e.g. a multipart with sipfrag 
> body parts (each sipfrag body part representing a UAS).
[JRE] And that sipfrag body part would need to contain an SDP body part to represent the SDP capabilities of the UAS? This would make responses potentially very large, posing a problem for UDP. It is probably a more extreme example than anything we have had before of a response being VERY MUCH larger than a request.

>  
> But, RFC3261 says that a proxy does not insert a message body 
> in the OPTIONS response, and that is probably ok in most 
> cases when the proxy returns its owns capabilities. But, when 
> the proxy replies on behalf of the UAS(s), I see no reason 
> why it should not be allowed to include a body. The UAC will 
> get the capabilities of the UAS(s), and that is what matters.
[JRE] In this case what you call the proxy is the UAS w.r.t. this particular transaction, so it can include a body.

>  
> Pros/cons:
> ----------------
>  
> + The major advantage of this mechanism is that it allows the 
> UAC to get the capabilities of all UAS(s) associated with the AOR.
[JRE] I am not sure what it needs this for, but we have the reg-event package to identify all registered Uas, and then OPTIONS could be directed at each in turn.

> - The set of capabilities per UAS is limited to what the 
> registrar knows about the UAS (based on registration 
> information, and/or by provisioning), so SDP information 
> would probably be left out. The mechanism might still be good 
> enough for many scenarios, though.
>  
> What to do:
> -----------------
>  
> If we think RFC3261 allows this, the question is whether we 
> consider it so crystal clear that nothing needs to be 
> specified, or whether it would be a good idea to put together 
> a BCP type-of document describing it.
>  
[JRE] Even if allowed, I think we might need some specification of the sipfrag part of it, and I am concerned about the response size. But I am not convinced there is a requirement to be able to use OPTIONS to get information about multiple UAs at once.

>  
>  
>  
>  
> ALTERNATIVE 3:
> =============
>  
> The idea is similar to Alternative 1, but in this case the 
> registrar would fork the OPTIONS request towards the UAS(s), 
> then "COLLECT" the responses, and finally send a single 
> response which contains the capabilities of all UAS(s) 
> towards the UAC.
[JRE] Again using sipfrags?

>  
> Prox/Cons:
> ----------------
>  
> + The major advantage of this mechanism is that it allows the 
> UAC to get the capabilities of all UAS(s).
> + The UAC will get more or less the same set of capabilities 
> for an UAS, as if the UAS would have sent the response 
> directly to the UAC.
>  
> - I guess most people would consider the forking proxy acting 
> as a B2BUA in this case, since it does not follow the 3261 
> rules about forwarding (or discarding) 200 OK responses 
> immediately when received.
>  
> What to do:
> -----------------
>  
> If we think this is a good solution, could it be described in 
> a BCP? I guess we would not update 3261 to describe this behavior?
[JRE] Again we would need to specify the sipfrag bits of it, and I would be concerned about the response size.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2010 09:22:37 -0500

I pretty much agree with John.

IMO there is no point in doing anything unless there is also work to 
clarify what the response *means* in a way that is operationally useful.

Even when there is only one UA and the OPTIONS request is getting to it, 
the result isn't especially useful, except as a "ping" because:

- nominally the response code is supposed to be the same as
   it would be for an INVITE. I guess that means you should get
   a 486 response if the UA is on a call and would reject another.
   But what if the UA *never* accepts INVITES - only SUBSCRIBE?
   Should you get 405?

- If the UA can in principle support a lot of things, but not
   all in the same call, there is no well defined way to reflect that.

I would like to see a set of use cases for how people would like to use 
OPTIONS where this enhancement is needed.

	Thanks,
	Paul

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Feb 2010 15:36:45 +0100

Hi John,

Thanks for your reply!

Regarding the size of the response, for alternative 2 I don't think it will be an issue. Because, since the forking proxy does not communicate with the UAS(s), the response will not contain that much information about each UAS. For example, there will most likely be no SDP, since UAs don't register SDP information to the registrar. So, in case the forking proxy only returns the registered feature tags, there would only be a one or a few header fields per UAS.

Maybe we wouldn't even need a sipfrag in that case. The details will have to be worked out, once/if we agree to study a specific alternative more in detail.

In alternative 3 the size would be bigger - at least if the forking proxy returns everything it get from the UAS(s). One solution here could be that an OPTIONS addressed to an AOR only returns a limited set of capabilites - perhaps only the GRUU for each UAS. Then the UAC can send OPTIONS directly to each UAS, in order to retrieve all capabilities.

Last, alternative 1 was meant to be serious, but the response you gave is more or less what I expected :)

Regards,

Christer

________________________________________
From: Elwell, John [[email-masked]]
Sent: Friday, February 19, 2010 3:59 PM
To: Christer Holmberg; SIPCORE
Subject: RE: OPTIONS: How to solve the forking problem?

John

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Feb 2010 08:37:02 -0600

I'm a bit confused. On the rather remote chance that you want to poll 
all of the UAs associated with an AOR, you can subscribe to the AOR's 
reg event state; collect the GRUUs; and then send an OPTIONS to each UA 
in turn.

But what's the real use case here? I can't imagine anything you can do 
with this information that doesn't work better with callerprefs.

/a

On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote:
> Even when there is only one UA and the OPTIONS request is getting to 
> it, the result isn't especially useful, except as a "ping" because:
>
> I would like to see a set of use cases for how people would like to 
> use OPTIONS where this enhancement is needed.
>
>     Thanks,
>     Paul
>
> Elwell, John wrote:
>>
>>
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Christer Holmberg
>>> request is forked, the UAC will only receive the capabilities of one 
>>> device/UAS (which UAS depends on which 200 OK reaches the forking 
>>> proxy first).
>>>
>>> OPTIONS works fine in HTTP, where we don't have forking and an HTTP 
>>> URI always identify uniquely a specific resource or a specific server.
>>> But, if I address the request to an AOR (which points to a domain, 
>>> not to a specific device) I might want to receive capabilities of 
>>> all the UAS associated with that AOR/domain.
>>> OR, do we think that OPTIONS should only be addressed to specific 
>>> devices (section 11 of 3261 talks about devices), in which case I 
>>> guess we don't need to do anything - at least not as far as forking 
>>> is concerned.
>>>
>>> I have put together 3 alternative solutions on how the problem could 
>>> be fixed. The first alternative is based on a UAS change, while the 
>>> second and third alternatives are based on a model where the 
>>> registrar (forking proxy) sends a response "on behalf" of the UAS(s).
>>>
>>> The 4th alternative is of course that we do nothing, but based on 
>>> previous discussions it does seem that some people are interested in 
>>> doing something about OPTIONS.
>>>
>>>
>>> ALTERNATIVE 1:
>>> =============
>>>
>>> including the capabilities, to the OPTIONS request. The registrar 
>>> will (hopefully) forward all the provisional responses towards the UAC.
>>>
>>> Pros/cons:
>>> ----------------
>>>
>>> + The major advantage of this mechanism is that it allows the UAC to 
>>> get the capabilities of all UAS(s) associated with the AOR.
>> [JRE] I hope this Alternative 1 is not meant to be serious. This 
>> would be contrary to the RFC3261 recommendation "UASs SHOULD NOT 
>> issue a provisional response for a non-INVITE request". I wonder how 
>> many SIP stacks would handle this. Also, having sent a provisional 
>> response, the UAS needs to send a final response, so how would this 
>> interact?
>>
>>>
>>> What to do:
>>> -----------------
>>>
>>> In this alternative the registrar never forks the OPTIONS request 
>>> towards the UAS(s). Instead, it sends a response on behalf of the 
>>> UASs, based on the information is has about the UAS(s), based on 
>>> registration information (feature tags etc) etc.
>>>
>>> When a UAC sends an OPTIONS request addressed to an AOR, I expect to 
>>> get capabilities associated with that AOR (which points to a domain, 
>>> not to a specific device). Currently, in case of forking, I will 
>>> only get the capabilities from one device/UAS associated with that 
>>> domain.
>>>
>>> But, if the registrar sends the OPTIONS response, it can provide 
>>> capabilities of all registered UAS(s) associated with the AOR/domain.
>>>
>>> So, so far I don't think 3261 forbids this kind of behavior (in 
>>> fact, I think this kind of behavior actually better implements what 
>>> is described in 3261...)
>>>
>>>
>>> Now, the best way to return the capabilities would probably be by 
>>> using a message body, e.g. a multipart with sipfrag body parts (each 
>>> sipfrag body part representing a UAS).
>> [JRE] And that sipfrag body part would need to contain an SDP body 
>> part to represent the SDP capabilities of the UAS? This would make 
>> responses potentially very large, posing a problem for UDP. It is 
>> probably a more extreme example than anything we have had before of a 
>> response being VERY MUCH larger than a request.
>>
>>>
>>> But, RFC3261 says that a proxy does not insert a message body in the 
>>> OPTIONS response, and that is probably ok in most cases when the 
>>> proxy returns its owns capabilities. But, when the proxy replies on 
>>> behalf of the UAS(s), I see no reason why it should not be allowed 
>>> to include a body. The UAC will get the capabilities of the UAS(s), 
>>> and that is what matters.
>> [JRE] In this case what you call the proxy is the UAS w.r.t. this 
>> particular transaction, so it can include a body.
>>
>>>
>>> Pros/cons:
>>> ----------------
>>>
>>> + The major advantage of this mechanism is that it allows the UAC to 
>>> get the capabilities of all UAS(s) associated with the AOR.
>> [JRE] I am not sure what it needs this for, but we have the reg-event 
>> package to identify all registered Uas, and then OPTIONS could be 
>> directed at each in turn.
>>
>>> - The set of capabilities per UAS is limited to what the registrar 
>>> knows about the UAS (based on registration information, and/or by 
>>> provisioning), so SDP information would probably be left out. The 
>>> mechanism might still be good enough for many scenarios, though.
>>>
>>> What to do:
>>> -----------------
>>>
>>> If we think RFC3261 allows this, the question is whether we consider 
>>> it so crystal clear that nothing needs to be specified, or whether 
>>> it would be a good idea to put together a BCP type-of document 
>>> describing it.
>>>
>> [JRE] Even if allowed, I think we might need some specification of 
>> the sipfrag part of it, and I am concerned about the response size. 
>> But I am not convinced there is a requirement to be able to use 
>> OPTIONS to get information about multiple UAs at once.
>>
>>>
>>>
>>>
>>>
>>> ALTERNATIVE 3:
>>> =============
>>>
>>> The idea is similar to Alternative 1, but in this case the registrar 
>>> would fork the OPTIONS request towards the UAS(s), then "COLLECT" 
>>> the responses, and finally send a single response which contains the 
>>> capabilities of all UAS(s) towards the UAC.
>>> + The UAC will get more or less the same set of capabilities for an 
>>> UAS, as if the UAS would have sent the response directly to the UAC.
>>>
>>> - I guess most people would consider the forking proxy acting as a 
>>> B2BUA in this case, since it does not follow the 3261 rules about 
>>> forwarding (or discarding) 200 OK responses immediately when received.
>>>
>>> What to do:
>>> -----------------
>>>
>>> If we think this is a good solution, could it be described in a BCP? 
>>> I guess we would not update 3261 to describe this behavior?
>> [JRE] Again we would need to specify the sipfrag bits of it, and I 
>> would be concerned about the response size.
>>
>> John

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Feb 2010 08:44:51 -0600

> Last, alternative 1 was meant to be serious, but the response you gave is more or less what I expected :)

It's worse than John points out -- Robert recently reminded me that 
RFC4320 outlaws this behavior altogether:

    An SIP element MUST NOT send any provisional response with a Status-
    Code other than 100 to a non-INVITE request.

/a

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 19 Feb 2010 10:51:46 -0500

On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:
> One of the main problems with OPTIONS is forking. In case the request
> is forked, the UAC will only receive the capabilities of one

I would use:

        OPTIONS sip:[email-masked] SIP/2.0
        Request-Disposition:  no-cancel, parallel
        
This seems to be specified in RFC 3841 to give the results you want,
although I don't expect many proxies to support it.  I've written a
discussion of this approach in
http://tools.ietf.org/id/draft-worley-sipping-forking-03.txt in regard
to SUBSCRIBE, PUBLISH, and some other cases.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2010 12:29:12 -0500

Dale,

I don't see how that can work. Once the first 200 is forwarded by the 
proxy it isn't supposed to send any more. Even if it did, the UAC would 
stop looking for responses after it got the first final one.

	Thanks,
	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 20 Feb 2010 20:06:40 -0600

------- Original message -------
> From: Christer Holmberg <[email-masked]>
> Sent: 19.2.'10,  5:28
> One of the main problems with OPTIONS is forking. In case the request is 
> forked, the UAC will only receive the capabilities of one device/UAS 
> (which UAS depends on which 200 OK reaches the forking proxy first).

How about the proxy that would fork instead responds with a 302 that 
includes in Contact an enumeration of the GRUUs for the Contacts of the 
AOR. The UAC then iterates across the GRUU set with OPTIONS, thereby 
discovering the capabilities of each registered Contact, without the 
privacy risks of revealing the Contacts associated with the AOR.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Feb 2010 15:02:52 -0500

Dean,

This seems like the best answer I have heard so far.

	Thanks,
	Paul

Dean Willis wrote:
> Dean _______________________________________________
> sipcore mailing list
> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2010 21:08:11 +0100

Hi,
 
>It's worse than John points out -- Robert recently reminded me that RFC4320 outlaws this 
>behavior altogether:
>
>

Yes, so that RFC would also require an update.

So, I think we can drop alternative 1 :)

(Initially I was also thinking about an alternative where all 200 OK responses are forwarded towards the UAC, but since we don't send ACK for OPTIONS it would not really work from a transaction statemachhine point of view, because when would you cease the re-transmission of OPTIONS?)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2010 21:28:25 +0100

Hi Paul,

>IMO there is no point in doing anything unless there is also work to clarify what the 
>response *means* in a way that is operationally useful.

I agree with you 100%..

The issue you raise is the other issue related to OPTIONS. Unfortunaly I didn't have time to send out an e-mail about that.

And, the what-does-it-mean issue needs to be solved no matter what we do with the forking issue, so I guess I should have sent out an e-mail about that first (I guess my thinking was that if the 2nd forking alternative is already allowed, we wouldn't need to spend so much time discussng that).

>Even when there is only one UA and the OPTIONS request is getting to it, the result isn't 
>especially useful, except as a "ping" because:
>

When the OPTIONS text was written, we didn't have SUBSCRIBE, so we need to agree whether we should be talking about "returning the capabilities at this moment", instead of "what would the INVITE response be at this moment".

So, yes, that is one issue.

>   all in the same call, there is no well defined way to reflect that.

True. I would assume that it should be made clear that OPTIONS is about returning capabilities in general, and that there is no guarantee that everything will be available for a particutlar 
call. 

Another issue is related to the usage of feature tags. RFC 3841 says that a UAS can perform feature tag matching when receiving a request, and reject a request if it doesn't support required feature tags. I guess that is fine for INVITE, but do we want to have that kind of behavior for OPTIONS also?

>I would like to see a set of use cases for how people would like to use OPTIONS where this 
>enhancement is needed.

I will talk about that in the forking issue thread.

So, talking about the specific what-does-it-mean issue: do people have an interest in trying to solve that?

Thanks!

Regards,

Christer

Elwell, John wrote:
>> not to a specific device) I might want to receive capabilities of all 
>> the UAS associated with that AOR/domain.
>>  
>> In this alternative the UAS(s) send a provisional response, including 
>> the capabilities, to the OPTIONS request. The registrar will 
>> (hopefully) forward all the provisional responses towards the UAC.
>>  
>> Pros/cons:
>> ----------------
>>  
>> not to a specific device). Currently, in case of forking, I will only 
>> get the capabilities from one device/UAS associated with that domain.
>>  
>> So, so far I don't think 3261 forbids this kind of behavior (in fact, 
>> I think this kind of behavior actually better implements what is 
>> described in 3261...)
>>  
>>  
>> behalf of the UAS(s), I see no reason why it should not be allowed to 
>> include a body. The UAC will get the capabilities of the UAS(s), and 
>> that is what matters.
>> it so crystal clear that nothing needs to be specified, or whether it 
>> would be a good idea to put together a BCP type-of document 
>> describing it.
>>  
>> would fork the OPTIONS request towards the UAS(s), then "COLLECT" the 
>> responses, and finally send a single response which contains the 
>> for an UAS, as if the UAS would have sent the response directly to 
>> the UAC.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2010 21:31:58 +0100

Hi Dale,

I am not sure I understand how your example would solve it.

My understanding of 3261 is that the forking proxy will discard all but the first non-INVITE 200 OK.

Are you saying that "no-cancel" overrides that, or did I missunderstand something?

Regards,

Christer

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: 19. helmikuuta 2010 17:52
To: Christer Holmberg
Cc: SIPCORE
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

I would use:

This seems to be specified in RFC 3841 to give the results you want, although I don't expect many proxies to support it.  I've written a discussion of this approach in http://tools.ietf.org/id/draft-worley-sipping-forking-03.txt in regard to SUBSCRIBE, PUBLISH, and some other cases.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2010 21:45:21 +0100

Hi Dean, 

>>device/UAS (which UAS depends on which 200 OK reaches the forking proxy first).
>
>How about the proxy that would fork instead responds with a 302 that includes in Contact an 
>enumeration of the GRUUs for the Contacts of the AOR. The UAC then iterates across the GRUU 
>set with OPTIONS, thereby discovering the capabilities of each registered Contact, without 
>the privacy risks of revealing the Contacts associated with the AOR.

Very interesting idea, and I for sure will add that as an alternative.

I guess we could discuss whether it still would be possible for the forking proxy to also include, in addtition to the GRUUs, the registered feature tags for the UASs, in which case it would be very similar to alternative 2 (the differences being that you use another response code and include the information in a header instead of the message body).

That information may be enough in many cases, and even if the UAC needs more information the information may help to decide to which UASs it sends subsequent OPTIONS request in order to retrieve more information (SDP, Contact etc). 

For example, if the UAC is interested in video capabilities it would be able to send OPTIONS only to those UASs that have registered support of video.

Thanks!

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2010 21:50:53 +0100

I was missing the typical Dean Willis metaphor, though :) 

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 21. helmikuuta 2010 22:03
To: Dean Willis
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

Dean,

	Thanks,
	Paul

Dean Willis wrote:
> includes in Contact an enumeration of the GRUUs for the Contacts of 
> the AOR. The UAC then iterates across the GRUU set with OPTIONS, 
> thereby discovering the capabilities of each registered Contact, 
> without the privacy risks of revealing the Contacts associated with the AOR.
> 
> --

---

From: [email-masked]
Date: Mon, 22 Feb 2010 09:10:16 +0800

+1

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-02-22 04:02

收件人
Dean Willis <[email-masked]>
抄送
[email-masked]
主题
Re: [sipcore] OPTIONS: How to solve the forking problem?

Dean,

                 Thanks,
                 Paul

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 06:10:21 +0100

Hi, 

>I'm a bit confused. On the rather remote chance that you want to poll all of the UAs 
>associated with an AOR,

I am not sure I agree on the "remote chance" thing. From my personal experience, people are more interested in all UASs behind an AOR, in order to set feature tag values etc accordingly when later esttablishing a session.

>you can subscribe to the AOR's reg event state; collect the GRUUs; and then send an OPTIONS 
>to each UA in turn.

Sure, you can do that. 

The idea behind the proposal, however, is that you would at least be able to get SOME information (even if only the gruus of the UASs, per Dean's proposal) using a single request.

Then, if you need additional information (SDP etc), sending individual OPTIONS might be the best solution. But, the information you got in the first response might help you to decided to which UASs you are going to send individual OPTIONS.

>But what's the real use case here? I can't imagine anything you can do with this information 
>that doesn't work better with callerprefs.

One of the use-cases I have in mind is actually to enable better use of callerprefs.

For example, assume that Alice wants to make a call, and her first option is to reach UAS devices that support video. So, she wants to use callerprefs to require video support. However, if no UAS support video, the call may get rejected.

Alice could of course send a request which does not require video, but then the call might be answered by a phone which doesn't support it, even if another phone would have supported it.

In addition, if all the non-video phones also get the request it might mean more early dialogs etc, that at least on wireless accesses can create a number of resource issues. 

Sure, you can BYE unwanted early dialogs, but why create them in the first place?

A similar example (which is also described in RFC3261, I believe) is when Alice wants to use an exension using the Require header, and wants to make sure that there are UASs supporting the extension.

So, in general I don't think the use-case is very different usages of OPTIONS, but it would allow users to get at least some capabilities of all users behind an AOR using a single request.

Regards,

Christer

On 2/19/10 08:22, Feb 19, Paul Kyzivat wrote:
>>> + In my personal opinion this does not require any changes in 
>>> + RFC3261
>>>
>>> get the capabilities of all UAS(s).

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 08:25:06 -0500

For the "prefer video" option you mention,
you can use callerprefs specifically to express that, so that devices 
with video capabilities are tried first, and others as a fallback.
Look at the callerprefs usecases RFC.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 22 Feb 2010 12:33:14 -0500

On Fri, 2010-02-19 at 12:28 +0100, Christer Holmberg wrote:
> But, if I address the request to an AOR (which points to a domain, not
> to a specific device) I might want to receive capabilities of all the
> UAS associated with that AOR/domain. 

There is an ambiguity regarding what UAs you want to query.  Do you want
to query the UAs registered to the AOR in question, or do you want to
query the UAs that an INVITE sent to the AOR would reach?

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 22 Feb 2010 12:36:56 -0500

> missunderstand something?

My understanding is that the *intended (but poorly documented) meaning*
of "Request-Disposition: no-cancel" is to request that the proxy forward
all 2xx responses upstream, in much the way that it ordinarily would for
INVITEs.  Otherwise, why would the proxy not cancel other forks when it
receives a 2xx?

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 18:48:35 +0100

Hi Dale, 

>There is an ambiguity regarding what UAs you want to query.  Do you want to query the UAs 
>registered to the AOR in question, or do you want to query the UAs that an INVITE sent to the 
>AOR would reach?

I want to query the UAs registered to the AOR.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 12:54:06 -0500

> query the UAs that an INVITE sent to the AOR would reach?

Or do you want to query the server responsible for the AOR itself?
(I.e. the proxy.)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 18:56:03 +0100

Hi Dale,

I think "no-cancel" is not applicable to OPTIONS, because:

1. OPTIONS are not cancelled by the forking proxy in the first place.

2. OPTIONS responses are re-transmitted when a re-transmission of the request is received. For how long would the UAC keep re-transmitting the OPTIONS request? How does it know that there will be no more 200 OKs?

Regards,

Christer 

-----Original Message-----
From: Dale Worley [mailto:[email-masked]] 
Sent: 22. helmikuuta 2010 19:37
To: Christer Holmberg
Cc: SIPCORE
Subject: RE: [sipcore] OPTIONS: How to solve the forking problem?

> missunderstand something?

My understanding is that the *intended (but poorly documented) meaning* of "Request-Disposition: no-cancel" is to request that the proxy forward all 2xx responses upstream, in much the way that it ordinarily would for INVITEs.  Otherwise, why would the proxy not cancel other forks when it receives a 2xx?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 13:07:35 -0500

None of this matters, because for non-invite transactions the UAC's 
state machine is going to be done when the first final response is 
received. It isn't going to be prepared to handle other 200 responses to 
the same transaction.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 19:14:21 +0100

Hi, 

>> There is an ambiguity regarding what UAs you want to query.  Do you 
>> want to query the UAs registered to the AOR in question, or do you 
>> want to query the UAs that an INVITE sent to the AOR would reach?
>

If the server responses on behalf of the server it can of course also include its own capabilities.

But, a server that only sends back its capabilities might use a 200 instead of 302 (if we would move forward with that solution for AOR query).

But, those things would need to be studied and clarified.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 19:15:36 +0100

Agree.

Christer 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 22. helmikuuta 2010 20:08
To: Christer Holmberg
Cc: 'Dale Worley'; SIPCORE
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

None of this matters, because for non-invite transactions the UAC's state machine is going to be done when the first final response is received. It isn't going to be prepared to handle other 200 responses to the same transaction.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 19:30:30 +0100

Hi,

>For the "prefer video" option you mention, you can use callerprefs specifically to express 
>that, so that devices with video capabilities are tried first, and others as a fallback.

Sure, there are cases where it will work, e.g. if you don't require certains extensions and you don't want the message to look differen if it will reach a "non-video" device.

Regards,

Christer

Christer Holmberg wrote:
>> all of the UAs associated with an AOR,
> 
>> you can subscribe to the AOR's reg event state; collect the GRUUs; 
>> and then send an OPTIONS to each UA in turn.
> 
> Sure, you can do that. 
> 
>> But what's the real use case here? I can't imagine anything you can 
>> do with this information that doesn't work better with callerprefs.
> 
>>>> request is forked, the UAC will only receive the capabilities of 
>>>> one device/UAS (which UAS depends on which 200 OK reaches the 
>>>> forking proxy first).
>>>>
>>>> I have put together 3 alternative solutions on how the problem 
>>>> could be fixed. The first alternative is based on a UAS change, 
>>>> while the second and third alternatives are based on a model where 
>>>> the registrar (forking proxy) sends a response "on behalf" of the UAS(s).
>>>>
>>>> previous discussions it does seem that some people are interested 
>>>> in doing something about OPTIONS.
>>>>
>>>>
>>>> ALTERNATIVE 1:
>>>> =============
>>>>
>>>> + The major advantage of this mechanism is that it allows the UAC 
>>>> + to
>>>> When a UAC sends an OPTIONS request addressed to an AOR, I expect 
>>>> to get capabilities associated with that AOR (which points to a 
>>>> domain, not to a specific device). Currently, in case of forking, I 
>>>> will only get the capabilities from one device/UAS associated with 
>>>> that domain.
>>>>
>>>> using a message body, e.g. a multipart with sipfrag body parts 
>>>> (each sipfrag body part representing a UAS).
>>> probably a more extreme example than anything we have had before of 
>>> a response being VERY MUCH larger than a request.
>>>
>>>> But, RFC3261 says that a proxy does not insert a message body in 
>>>> the OPTIONS response, and that is probably ok in most cases when 
>>>> the proxy returns its owns capabilities. But, when the proxy 
>>>> replies on behalf of the UAS(s), I see no reason why it should not 
>>>> be allowed to include a body. The UAC will get the capabilities of 
>>>> the UAS(s), and that is what matters.
>>>> + The major advantage of this mechanism is that it allows the UAC 
>>>> + to
>>> [JRE] I am not sure what it needs this for, but we have the 
>>> reg-event package to identify all registered Uas, and then OPTIONS 
>>> could be directed at each in turn.
>>>
>>>> consider it so crystal clear that nothing needs to be specified, or 
>>>> whether it would be a good idea to put together a BCP type-of 
>>>> document describing it.
>>>>
>>>> registrar would fork the OPTIONS request towards the UAS(s), then "COLLECT"
>>>> the responses, and finally send a single response which contains 
>>>> the capabilities of all UAS(s) towards the UAC.
>>>> + The major advantage of this mechanism is that it allows the UAC 
>>>> + to

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 22 Feb 2010 20:57:15 +0200

> Or do you want to query the server responsible for the AOR itself?
I tend to agree with Paul,

RFC3261 section 11:

    The target of the OPTIONS request is identified by the Request-URI,
    which could identify another UA or a SIP server.

moreover 3261 defines:

    Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
    that points to a domain with a location service that can map
    the URI to another URI where the user might be available.

so "in theory" a SIP OPTIONS request to an AoR should be interpreted as
a request to a SIP Proxy/Server that is authoritative for that AoR,
and then the response should be... without any body...

/Sal

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Feb 2010 20:03:37 +0100

If you would follow that logic no request would ever reach a UA.

BR,
/Hans Erik van Elburg

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 14:08:55 -0500

> Sure, there are cases where it will work, e.g. if you don't require certains extensions and you don't want the message to look differen if it will reach a "non-video" device.

While its an incredible pain, you can specify fairly sophisticated 
selection criteria. IMO the most fundamental issue with this approach is 
you are never certain if your *preferences* will be honored, whether 
this is because of conflicting policies, or because the devices just 
don't support the processing of callerprefs.

I recognize that there is a lot more certainty when the caller can 
examine all the possibilities and make its own decisions. But this is 
also fundamentally limited, because the called user may well be 
unwilling to share with you the information you need to make your 
decision. (I quite likely will not let unknown callers know how many UAs 
of which types I have connected, or what algorithms I might use to 
decide to route your call to one of them or to VM.)

One answer is for the caller to first try presence. If it can get info 
via presence, then it can make its own decision based on that. If not, 
It can try using callerprefs and hope for the best.

You can view OPTIONS as a poor man's version of one-shot presence. 
Rather than fix it, maybe we should be trying to work our some 
recommendations for providing presence information to unknown subscribers.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 22 Feb 2010 21:16:22 +0200

not really, the problem is only with OPTIONS requests:

    The SIP method OPTIONS allows a UA to query another UA or a proxy
    server as to its capabilities.

so when you address the request to an AoR ... there is a clear ambiguity 
on what you are really requesting.

even if "historically" the usage is that you want to query the UAs than 
an INVITE sent to the AoR would reach,

/Sal

On 02/22/2010 09:03 PM, Hans Erik van Elburg wrote:
> On Mon, Feb 22, 2010 at 7:57 PM, Salvatore Loreto 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Feb 2010 20:23:23 +0100

The sentence "The target of the OPTIONS request is identified by the
Request-URI, which could identify another UA or a SIP server." does not
imply that you can only adress AOR's.

If a Request-URI happen to contain a proxy servers address, then the request
will be targeted at the proxy server and not at a UA. If it contains an AOR
then it is adressed at whatever entities the location server lookup function
resolves to (this may even be recursive).

/Hans Erik van Elburg

On Mon, Feb 22, 2010 at 8:16 PM, Salvatore Loreto <
[email-masked]> wrote:

> so when you address the request to an AoR ... there is a clear ambiguity on
> what you are really requesting.
>
> even if "historically" the usage is that you want to query the UAs than an
> INVITE sent to the AoR would reach,
>
> /Sal
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 22 Feb 2010 21:30:42 +0200

On 02/22/2010 09:23 PM, Hans Erik van Elburg wrote:
> Request-URI, which could identify another UA or a SIP server." does 
> not imply that you can only adress AOR's.
>
> If a Request-URI happen to contain a proxy servers address, then the 
> request will be targeted at the proxy server and not at a UA. If it 
> contains an AOR then it is adressed at whatever entities the location 
> server lookup function resolves to (this may even be recursive).

it could be a possibility
but I do still think 3261 is unclear here.

/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 14:34:59 -0500

> server lookup function resolves to (this may even be recursive).

When a request is addressed to sip:[email-masked], it eventually 
lands on a server that is responsible for atlanta.org. Where it goes 
from there is up to that server. Often its a proxy with a registrar, and 
it forks based on registered contacts. But that is certainly not 
required behavior, and often its more subtle than that. (Look at IMS.)

For instance, its pretty common for the proxy to note that the request 
is a SUBSCRIBE, and then at the event package name, and select a 
particular server to route to. It can of course also to decide to route 
certain requests to "itself" as a UA for processing it provides.

When it gets OPTIONS, it could have special routing rules for that. 
Routing the way it would an INVITE is at best an INVITE-centric view of 
the world. And even that doesn't do anything very useful if there are 
multiple contacts registered.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> 
> On Mon, Feb 22, 2010 at 8:16 PM, Salvatore Loreto 
>     so when you address the request to an AoR ... there is a clear
>     ambiguity on what you are really requesting.
> 
>     even if "historically" the usage is that you want to query the UAs
>     than an INVITE sent to the AoR would reach,
> 
>     /Sal
> 
> 
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Feb 2010 20:38:03 +0100

I think that you are saying here that the location server lookup function
may have other ways of determining the next target then based on
registration alone. but it is not contradicting.

/Hans Erik van Elburg

On Mon, Feb 22, 2010 at 8:34 PM, Paul Kyzivat <[email-masked]> wrote:

>> request will be targeted at the proxy server and not at a UA. If it contains
>> an AOR then it is adressed at whatever entities the location server lookup
>> function resolves to (this may even be recursive).
>>
>
> When a request is addressed to sip:[email-masked]<[email-masked]>,
> it eventually lands on a server that is responsible for atlanta.org. Where
> it goes from there is up to that server. Often its a proxy with a registrar,
> and it forks based on registered contacts. But that is certainly not
> For instance, its pretty common for the proxy to note that the request is a
> SUBSCRIBE, and then at the event package name, and select a particular
> server to route to. It can of course also to decide to route certain
> requests to "itself" as a UA for processing it provides.
>
> When it gets OPTIONS, it could have special routing rules for that. Routing
> the way it would an INVITE is at best an INVITE-centric view of the world.
> And even that doesn't do anything very useful if there are multiple contacts
> registered.
>
>        Thanks,
>        Paul
>
>  /Hans Erik van Elburg
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>>>>> domain, not

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 20:38:16 +0100

Hi,

I don't think I am "disagreeing" with Paul.

Also, if the response from the server will contain only a limited set of UAS information we may not need a body.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: 22. helmikuuta 2010 20:57
To: [email-masked]; Paul Kyzivat; Dale Worley
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

Dale Worley wrote:

RFC3261 section 11:

moreover 3261 defines:

/Sal

---

From: Alan Johnston <[email-masked]>
Date: Mon, 22 Feb 2010 14:17:01 -0600

Christer,

See below.

- Alan -

> Also, if the response from the server will contain only a limited set of UAS information we may not need a body.

I can tell you this was not the intent of this text.  It is correct that
a proxy authoritative for a domain can apply any policy to any request
directed at an AoR in that domain.  However, for a proxy to answer an
OPTIONS on behalf of a user/UA would be very surprising to me, and I
don't think RFC 3261 implies this.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Feb 2010 02:07:34 +0100

Hi Alan, 

>I can tell you this was not the intent of this text.  It is correct that a proxy 
>authoritative for a domain can apply any policy to any request directed at an AoR in that 
>domain.  However, for a proxy to answer an OPTIONS on behalf of a user/UA would be very 
>surprising to me, and I don't think RFC 3261 implies this.

I agree that the RFC does not talk about answering on behalf of UAs. 

The question is whether we COULD allow the proxy to answer on behalf of the UASs. I don't it breaks anything. We do need to take message size into consideration, and for that reason one idea is that the reponse from the proxy would contain very limited set of UAS information (in order to get the full set of information (SDP etc) the UAC will have to send an OPTIONS addressed to a specific UAS).

Regards,

Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 23 Feb 2010 09:57:05 +0100

Agreed. Of course a proxy equiped with such policy can do that. It is kind
of a domain specific service.
For that you do not have to bend the interpretation of the original RFC3261
text.

If you use the 302 approach proposed by Dean, then do you need to do
anything specification wise?

/Hans Erik van Elburg

On Tue, Feb 23, 2010 at 2:07 AM, Christer Holmberg <
[email-masked]> wrote:

> The question is whether we COULD allow the proxy to answer on behalf of the
> UASs. I don't it breaks anything. We do need to take message size into
> consideration, and for that reason one idea is that the reponse from the
> proxy would contain very limited set of UAS information (in order to get the
> full set of information (SDP etc) the UAC will have to send an OPTIONS
> addressed to a specific UAS).
>
> Regards,
>
> Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2010 09:27:01 -0500

Hans Erik van Elburg wrote:
> Agreed. Of course a proxy equiped with such policy can do that. It is 
> kind of a domain specific service.
> For that you do not have to bend the interpretation of the original 
> RFC3261 text.
> 

No. Its entirely above board.

Having the proxy respond on behalf of the endpoints may or may not be 
entirely conforming, depending on how it responds. E.g. if it attempts 
to include a multipart with multiple SDP bodies then it may be 
technically conforming, but will confuse most UACs.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> 
> On Tue, Feb 23, 2010 at 2:07 AM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> 
>     Hi Alan,
> 
>     The question is whether we COULD allow the proxy to answer on behalf
>     of the UASs. I don't it breaks anything. We do need to take message
>     size into consideration, and for that reason one idea is that the
>     reponse from the proxy would contain very limited set of UAS
>     information (in order to get the full set of information (SDP etc)
>     the UAC will have to send an OPTIONS addressed to a specific UAS).
> 
>     Regards,
> 
>     Christer
> 
> ------------------------------------------------------------------------
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Feb 2010 10:00:52 -0600

On 2/23/10 08:27, Feb 23, Paul Kyzivat wrote:
> entirely conforming, depending on how it responds.

That's not how I read Dean's proposal. The "Proxy/Registrar" isn't 
responding on behalf of the UAs. It's letting the UAC know where to find 
all the registered UAs.

What I see Dean proposing is something like this:

         Dean    Registrar  Adam 1    Adam 2    Adam 3
           |         |         |         |         |
           |OPTIONS  |         |         |         |
           |-------->|         |         |         |
           |         |         |         |         |
           |302      |         |         |         |
           |Contact: sip:adam1.example.com         |
           |Contact: sip:adam2.example.com         |
           |Contact: sip:adam3.example.com         |
           |<--------|         |         |         |
           |         |         |         |         |
           |OPTIONS  |         |         |         |
           |------------------>|         |         |
           |200      |         |         |         |
           |<------------------|         |         |
           |         |         |         |         |
           |OPTIONS  |         |         |         |
           |---------------------------->|         |
           |200      |         |         |         |
           |<----------------------------|         |
           |         |         |         |         |
           |OPTIONS  |         |         |         |
           |-------------------------------------->|
           |200      |         |         |         |
           |<--------------------------------------|

Perfectly above board, normal handling. Keep in mind that the Registrar 
can stay in the path by returning GRUUs instead of contacts that go 
directly to the UAs. It all works just fine either way.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Feb 2010 10:06:43 -0600

On 2/23/10 10:00, Feb 23, Adam Roach wrote:
>>> Agreed. Of course a proxy equiped with such policy can do that. It 
>>> is kind of a domain specific service.
> responding on behalf of the UAs. It's letting the UAC know where to 
> find all the registered UAs.

Whoops, sorry. I got the threads crossed.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Feb 2010 11:11:20 -0500

Adam,

Maybe the thread has branched too much to follow.

I was contrasting two things, one by Dean and the other by Christer.
I agree with you re Dean's.

The alternative proposal was for the "proxy" to answer on behalf of the 
registered endpoints, with an aggregate response. Exactly what that 
aggregate response would look like is not clear. At one point I had 
suggested that the "proxy" could send its own OPTIONS requests to the 
endpoints. If so, and if their responses contained SDP, then an 
aggregate response might require a multipart.

The Dean suggestion is by far the better one.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 08:36:29 +0100

Hi,

Unless someone objects, I think we can drop the alternative where the proxy would include SDP  for the UASs, because that could cause message size issues etc... If an UAC wants to get such information, it needs to send an OPTIONS request addressed to the actual UAS.

Dean suggested that the proxy returns the gruus of the UASs. But, as I said earlier, I still think we should consider whether the proxy could return the registered feature tags of the UASs, together with the gruus, since the proxy has that information. 

In fact, I believe that could help getting people to implement callerprefs (and gruu), because it would be a use-case where it is really good to do so.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 23. helmikuuta 2010 18:11
To: Adam Roach
Cc: [email-masked]
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

Adam,

The alternative proposal was for the "proxy" to answer on behalf of the registered endpoints, with an aggregate response. Exactly what that aggregate response would look like is not clear. At one point I had suggested that the "proxy" could send its own OPTIONS requests to the endpoints. If so, and if their responses contained SDP, then an aggregate response might require a multipart.

	Thanks,
	Paul

Adam Roach wrote:
> Perfectly above board, normal handling. Keep in mind that the 
> Registrar can stay in the path by returning GRUUs instead of contacts 
> that go directly to the UAs. It all works just fine either way.
> 
> /a
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 08:55:00 +0100

Hi, 

>>>For the "prefer video" option you mention, you can use callerprefs 
>>>specifically to express that, so that devices with video capabilities are tried first, and 
>>>others as a fallback.
>> 
>>Sure, there are cases where it will work, e.g. if you don't require certains extensions and 
>>you don't want the message to look differen if it will reach a "non-video" device.
>
>While its an incredible pain, you can specify fairly sophisticated selection criteria. IMO 
>the most fundamental issue with this approach is you are never certain if your *preferences* 
>will be honored, whether this is because of conflicting policies, or because the devices just 
>I recognize that there is a lot more certainty when the caller can examine all the 
>possibilities and make its own decisions. But this is also fundamentally limited, because the 
>called user may well be unwilling to share with you the information you need to make your 
>decision. (I quite likely will not let unknown callers know how many UAs of which types I 
>have connected, or what algorithms I might use to decide to route your call to one of them or 
>to VM.)

True. And, I don't think we should mandate what information the proxy returns. It could be based on whatever policies.

For example, if the proxy does not want to return the number of UAs, it could simply e.g return the registered feature tags, but not per UAS. That would at least let the UAC know what type of features are supported, eventhough not which UAS support what.

>Rather than fix it, maybe we should be trying to work our some recommendations for providing 
>presence information to unknown subscribers.

One could do that, but I think that the OPTIONS fix we've been discussing would still be sufficient in many cases.

Regards,

Christer

> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> Christer Holmberg wrote:
>> Hi,
>>
>>> I'm a bit confused. On the rather remote chance that you want to 
>>> poll all of the UAs associated with an AOR,
>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>> On Behalf Of Christer Holmberg
>>>>> OPTIONS works fine in HTTP, where we don't have forking and an 
>>>>> HTTP URI always identify uniquely a specific resource or a specific server.
>>>>> guess we don't need to do anything - at least not as far as 
>>>>> forking is concerned.
>>>>>
>>>> issue a provisional response for a non-INVITE request". I wonder 
>>>> how many SIP stacks would handle this. Also, having sent a 
>>>> provisional response, the UAS needs to send a final response, so 
>>>> how would this interact?
>>>>
>>>>> What to do:
>>>>> -----------------
>>>>>
>>>>> domain, not to a specific device). Currently, in case of forking, 
>>>>> I will only get the capabilities from one device/UAS associated 
>>>>> with that domain.
>>>>>
>>>>> fact, I think this kind of behavior actually better implements 
>>>>> what is described in 3261...)
>>>>>
>>>>>
>>>>> consider it so crystal clear that nothing needs to be specified, 
>>>>> or whether it would be a good idea to put together a BCP type-of 
>>>>> document describing it.
>>>>>
>>>>> + The UAC will get more or less the same set of capabilities for 
>>>>> + an

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2010 09:54:20 -0500

It is already permissible for a proxy to do as you suggest - return a 
300 with multiple contacts, and include the feature tags that were 
provided at registration.

The question would be whether to somehow make this mandatory.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 23 Feb 2010 13:38:28 -0500

> I want to query the UAs registered to the AOR.

In which case, you don't want to send a request "to" the AOR, as it may
well get forwarded to various other places.  What you really want is the
reg event package for the AOR, and then you can query the registered
contacts.

That appears to be insecure, but your intention is to get information
about the capabilities of every registered contact, and any method that
lets you do so pretty much tells what the contacts are.  (And if it
doesn't directly, properly constructed INVITEs that reach exactly one
contact will eventually reveal the contact addresses of all of them.)

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 23 Feb 2010 13:42:58 -0500

> received. It isn't going to be prepared to handle other 200 responses to 

If "Request-Disposition: no-cancel" is to have any sensible effect, it
means that "stray" 200 responses will be forwarded upstream, as they
would for an INVITE.  RFC 3841 is explicit that Request-Disposition can
be used on non-INVITE requests.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 19:48:22 +0100

Hi, 

>It is already permissible for a proxy to do as you suggest - return a 300 with multiple 
>contacts, and include the feature tags that were provided at registration.
>

That is one option.

I have also been thinking about an alternative whether the proxy could make the decission whether to send a 300 response, or fork the OPTIONS towards the UAS(s), based on the 
information received in the OPTIONS request.

But, I will indicate that as a separate issue.

Regards,

Christer

Christer Holmberg wrote:
> Behalf Of Paul Kyzivat
>>>> If you use the 302 approach proposed by Dean, then do you need to 
>>>> do anything specification wise?
>>> Having the proxy respond on behalf of the endpoints may or may not 
>>> be entirely conforming, depending on how it responds.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 19:53:00 +0100

Hi Dale, 

>> received. It isn't going to be prepared to handle other 200 responses 
>> to the same transaction.
>
>If "Request-Disposition: no-cancel" is to have any sensible effect, it means that "stray" 200 
>responses will be forwarded upstream, as they would for an INVITE.  RFC 3841 is explicit that 
>Request-Disposition can be used on non-INVITE requests.

Just because the header field is applicable, it doesn't mean all parameters are :)

But, as I asked earlier: when would the UAC cease the re-transmission of the OPTIONS request (or, any request for which no ACK is to be sent)?

Regards,

Chris

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 20:06:39 +0100

Hi, 

>In which case, you don't want to send a request "to" the AOR, as it may well get forwarded to 
>various other places.  What you really want is the reg event package for the AOR, and then 
>you can query the registered contacts.

Sure, if you don't care about call setup times, number of messages etc :)

>That appears to be insecure, but your intention is to get information about the capabilities 
>of every registered contact, and any method that lets you do so pretty much tells what the 
>contacts are.  (And if it doesn't directly, properly constructed INVITEs that reach exactly 
>one contact will eventually reveal the contact addresses of all of them.)

If we are going to document (e.g. in a BCP) different ways of retrieving the capabilities I guess this mechanism could also be docuumented. I guess there is currently nothing which prevents it?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 22:58:10 +0100

Of course, if the contacts in the 300 response contains feature tags, the UAC needs to remove those before sending an OPTIONS request addressed to the contact.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 24. helmikuuta 2010 20:48
To: 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

Hi, 

>300 with multiple contacts, and include the feature tags that were provided at registration.
>

That is one option.

I have also been thinking about an alternative whether the proxy could make the decission whether to send a 300 response, or fork the OPTIONS towards the UAS(s), based on the information received in the OPTIONS request.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2010 17:16:33 -0500

> Of course, if the contacts in the 300 response contains feature tags, the UAC needs to remove those before sending an OPTIONS request addressed to the contact.

Of course. Its only the URI from the Contact header that is used in the 
request. The feature tags are header params, not URI params, so they 
will be left behind when extracting the URI.

	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 23:22:26 +0100

True. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 25. helmikuuta 2010 0:17
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] OPTIONS: How to solve the forking problem?

> Of course, if the contacts in the 300 response contains feature tags, the UAC needs to remove those before sending an OPTIONS request addressed to the contact.

Of course. Its only the URI from the Contact header that is used in the request. The feature tags are header params, not URI params, so they will be left behind when extracting the URI.

	Paul

>>> Registrar can stay in the path by returning GRUUs instead of 
>>> contacts that go directly to the UAs. It all works just fine either way.
>>>
>>> /a
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 23:45:41 +0100

Hi,

I am trying to collect issues which are unclear regarding OPTIONS.

Some issues a described below, but if you are aware of others please let me know.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21. helmikuuta 2010 22:28
To: 'Paul Kyzivat'; Elwell, John
Cc: SIPCORE
Subject: [sipcore] OPTIONS: What does it mean? ( was: OPTIONS: How to solve the forking problem?)

Hi Paul,

I agree with you 100%..

>   all in the same call, there is no well defined way to reflect that.

True. I would assume that it should be made clear that OPTIONS is about returning capabilities in general, and that there is no guarantee that everything will be available for a particutlar call. 

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2010 17:55:13 -0500

> Another issue is related to the usage of feature tags. RFC 3841 says that a UAS can perform feature tag matching when receiving a request, and reject a request if it doesn't support required featur…

I don't see an issue here. The callerprefs stuff is independent of 
method. If you don't want callerprefs applied to your OPTIONS request, 
don't put any callerprefs into the OPTIONS message. If they are present, 
then I would expect them to be honored to the same extent (optional) 
that they are ever honored.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2010 18:03:10 -0500

> Some issues a described below, but if you are aware of others please let me know.

Another one I have encountered:

What is behavior of OPTIONS when sent "in-dialog".

3261 (I forget where) states that OPTIONS in dialog should be treated 
the same as out of dialog. But does it really mean that? And to what extent?

The place I encountered it was people who wanted to use OPTIONS in 
dialog to test the liveness of the other end. In particular they wanted 
to test if the dialog was still live, as well as the path in general. 
(Of course they could have used something like UPDATE, but that isn't 
always supported, while OPTIONS is.)

So, if an OPTIONS is received, and it has a to-tag, is it treated as an 
in-dialog request at least to the extent of returning a 481 if there is 
no matching dialog? Or is it really treated as an out-of-dialog request 
such that even with no matching dialog it gets a 200 response?

I *think* it should get a 481 in this case if there is no matching 
dialog. But I think this is currently ambiguous.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2010 01:34:00 +0100

Hi, 

>>Another issue is related to the usage of feature tags. RFC 3841 says that a UAS can perform 
>>feature tag matching when receiving a request, and reject a request if it doesn't support 
>>required feature tags. I guess that is fine for INVITE, but do we want to have that kind of 
>>behavior for OPTIONS also?
>
>I don't see an issue here. The callerprefs stuff is independent of method. If you don't want >callerprefs applied to your OPTIONS request, don't put any callerprefs into the OPTIONS 
>message. If they are present, then I would expect them to be honored to the same extent 
>(optional) that they are ever honored.

Sounds ok.

Of course, when the UAC indicates which feature tags IT supports it has to included them in the Contact header, and not in Accept-Contact, but I assume that is obvious.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2010 01:38:25 +0100

Hi, 

>3261 (I forget where) states that OPTIONS in dialog should be treated the same as out of 
>dialog. But does it really mean that? And to what extent?
>
>The place I encountered it was people who wanted to use OPTIONS in dialog to test the 
>liveness of the other end. In particular they wanted to test if the dialog was still live, as 
>well as the path in general. 
>(Of course they could have used something like UPDATE, but that isn't always supported, while 
>OPTIONS is.)
>
>So, if an OPTIONS is received, and it has a to-tag, is it treated as an in-dialog request at 
>least to the extent of returning a 481 if there is no matching dialog? Or is it really 
>treated as an out-of-dialog request such that even with no matching dialog it gets a 200 
>response?
>
>I *think* it should get a 481 in this case if there is no matching dialog. But I think this 
>is currently ambiguous.

I also think 481 should be sent. Sending an in-dialog request on a non-existing dialog is a core protocol error, and I don't think specific methods should be allowed to "override" that rule.

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Thu, 25 Feb 2010 04:56:14 -0800

> > I *think* it should get a 481 in this case if there is no 
> > matching dialog. But I think this is currently ambiguous.
> 
> I also think 481 should be sent. Sending an in-dialog request 
> on a non-existing dialog is a core protocol error, and I don't 
> think specific methods should be allowed to "override" that rule.

Concerning returning 481 response for OPTIONS, the ambiguity has multiple parts since per rfc5057 OPTIONS is not part of a dialog usage.

1) When SHOULD (or MUST) it be sent: never, no dialog, no invite dialog usage, or no subscribe dialog usage?

2) What does it mean: no dialog, no invite dialog usage, or no subscribe dialog usage?

The following is a link to a 2008 thread concerning the topic:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019279.html

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2010 10:18:35 -0500

> be used on non-INVITE requests.

That's fine. But it does no good if the extra responses are not expected 
upstream and are discarded. Once the transaction state machine is torn 
down there is no mechanism for dealing with additional responses. The 
mechanisms for that only exist for INVITE.

If we want that to work there is other stuff that must be updated.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2010 11:53:03 -0500

Brett,

Yes, there are many subtleties to this.

I think some of the people who have asked me about this wanted to use 
this as an INVITE-dialog-usage status tester that is a little lighter 
weight than reinvite. But of course since it isn't part of the 
invite-dialog-usage its always possible that it might succeed because 
the *dialog* was still there even though the invite-dialog-usage is not.
(Most people don't make the distinction, and often they are synonymous, 
but there are always those corner cases.)

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Thu, 25 Feb 2010 10:08:37 -0800

Hi Paul,

> I think some of the people who have asked me about this wanted 
> to use this as an INVITE-dialog-usage status tester that is a 
> little lighter weight than reinvite. 

Yes; and some people in 2000 wanted to do the same.  As far as I know, the idea was rejected.

Some aspects are discussed within the following threads:

http://www.ietf.org/mail-archive/web/sip/current/msg06338.html 

> But of course since it isn't part of the invite-dialog-usage 
> its always possible that it might succeed because the *dialog* 
> was still there even though the invite-dialog-usage is not.

Depending upon interpretation of the following, the *dialog* doesn't necessarily need to exist.

RFC 3261 section 12.2.2:
"If the UAS wishes to reject the request because it does not wish
to recreate the dialog, it MUST respond to the request with a
481(Call/Transaction Does Not Exist) status code and pass that to
the server transaction.

Requests that do not change in any way the state of a dialog may be
received within a dialog (for example, an OPTIONS request).  They
are processed as if they had been received outside the dialog."

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 25 Feb 2010 19:52:36 +0100

> Logically, one can not receive a request on a dialog if the dialog does not
exist. As the last sentence refers back to the sentence before it, it says
that:
"Requests that do not change in any way the state of a dialog may be
received within a dialog are processed as if they had been received outside
the dialog."

It talks a about requests received in a dialog, the processing comes second.

Therefore I don't think that the processing bit overrides the rule that a
"UAS that does not want to recreate a dialog for a request received in a
dialog that currently does not exist MUST respond with a 481".

But I agree that it is utterly confusing.

/Hans Erik

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2010 20:20:53 +0100

Hi, 

>>would for an INVITE.  RFC 3841 is explicit that Request-Disposition 
>>can be used on non-INVITE requests.
>
>That's fine. But it does no good if the extra responses are not expected upstream and are 
>discarded. Once the transaction state machine is torn down there is no mechanism for dealing 
>with additional responses. The mechanisms for that only exist for INVITE.
>

Is that really something people would want to do???

I was initially thinking about that option myself, but dropped it because I thought it would be even more controversial (it most likely would require some acknowledgement for the response) than defining provisional resposnes for OPTIONS :)

Regards,

Christer
	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2010 14:47:20 -0500

> I was initially thinking about that option myself, but dropped it because I thought it would be even more controversial (it most likely would require some acknowledgement for the response) than def…

IMO we don't want to go there.

I was just refuting what I think was an implicit assumption by Dale that 
it ought to work now.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2010 14:55:03 -0500

> Yes; and some people in 2000 wanted to do the same.  As far as I know, the idea was rejected.

I didn't intend to imply that I *agreed* with this usage.
Its just that people still think its a good thing to do.
Its part of the confusion/ambiguity about OPTIONS.

> are processed as if they had been received outside the dialog."

Right.

*If* the OPTIONS has a to-tag, and there is no matching dialog there are 
several things that might happen:
- it might be rejected with a 481
- it might succeed because it is treated as if received outside a dialog
- it might cause the dialog to be recreated, and then succeed within it
   In the latter case, presumably the dialog would then end, because
   there are no dialog usages.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2010 21:34:34 +0100

Hi, 

>>> weight than reinvite.
>> But of course since it isn't part of the invite-dialog-usage its 
>> always possible that it might succeed because the *dialog* was still 
>> there even though the invite-dialog-usage is not.
> 
> "If the UAS wishes to reject the request because it does not wish to 
> recreate the dialog, it MUST respond to the request with a 
> 481(Call/Transaction Does Not Exist) status code and pass that to the 
> server transaction.
> 
> received within a dialog (for example, an OPTIONS request).  They are 
> processed as if they had been received outside the dialog."
>
>Right.
>
>*If* the OPTIONS has a to-tag, and there is no matching dialog there are several things that 
>might happen:

Is that really true? As I read it, the text above says that a request received within an existing dialog may be treated as if it would have been received outside the dialog. But, we are now talking about a non-existing dialog which the OPTIONS claims to belong to.

>   there are no dialog usages.

And, this will of course depend on whether the UAS still has any knowledge about the dialog.

Personally I think this alternative is rather strange, and I've never heard about it being used. But, I agree that the text seems to allow it.

Regards,

Christer