Subject: [sipcore] draft-jones-sip-options-ping-01

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 5 May 2010 00:49:02 -0400

Folks,

I posted a revised version of the OPTIONS "ping" draft with changes as per
our discussions.  One change I made was that I re-instated the paragraph
related to addressing, saying OPTIONS "should" be addressed to sip:hostport.
I'm still willing to consider removing that entirely if that's preferred,
but I recall that Hadriel preferred to have something that one could
generally assume to be the proper address.  As a means of querying UAS
status, I think that's a reasonable choice.

Anyway, I welcome comments on the draft.

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 May 2010 07:20:19 +0200

Hi,

As said earlier, 3261 already says that OPTIONS addressed to proxies are to use sip:hostport, so I don't think we need to say anything about that.

Regards,

Christer 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: 5. toukokuuta 2010 7:49
> To: [email-masked]
> Subject: [sipcore] draft-jones-sip-options-ping-01
> 
> Folks,
> 
> I posted a revised version of the OPTIONS "ping" draft with 
> changes as per our discussions.  One change I made was that I 
> re-instated the paragraph related to addressing, saying 
> OPTIONS "should" be addressed to sip:hostport.
> I'm still willing to consider removing that entirely if 
> that's preferred, but I recall that Hadriel preferred to have 
> something that one could generally assume to be the proper 
> address.  As a means of querying UAS status, I think that's a 
> reasonable choice.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 5 May 2010 22:08:28 -0400

Christer - 

I think we are in agreement here. Do you think the language should be revised to something stronger (i.e. MUST) in regards to using that address form when sending an OPTIONS to a proxy? Or do you think it should stay as is?

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 May 2010 07:33:37 +0200

Hi, 

>I think we are in agreement here. Do you think the language 
>should be revised to something stronger (i.e. MUST) in 
>regards to using that address form when sending an OPTIONS to 
>a proxy? Or do you think it should stay as is?

Similar to comments that have been given for INFO, we should not "duplicate" MUST/SHALL/SHOULD/etc that are already in RFC3261.

We can say something: "The addressing of OPTIONS requests to a proxy is described in section X in RFC 3261"

...or something like that.

Regards,

Christer

> > As said earlier, 3261 already says that OPTIONS addressed 
> to proxies are to use sip:hostport, so I don't think we need 
> to say anything about that.
> > 
> > Regards,
> > 
> > Christer
> > 
> >> I posted a revised version of the OPTIONS "ping" draft 
> with changes 
> >> as per our discussions.  One change I made was that I 
> re-instated the 
> >> paragraph related to addressing, saying OPTIONS "should" 
> be addressed 
> >> to sip:hostport.
> >> I'm still willing to consider removing that entirely if that's 
> >> preferred, but I recall that Hadriel preferred to have 
> something that 
> >> one could generally assume to be the proper address.  As a 
> means of 
> >> querying UAS status, I think that's a reasonable choice.
> >>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 May 2010 01:40:46 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Wednesday, May 05, 2010 1:20 AM
> 
> As said earlier, 3261 already says that OPTIONS addressed to proxies are
> to use sip:hostport, so I don't think we need to say anything about that.

But this is *not* to a proxy, or at least not always to a proxy.  The draft is for it between UA's as well (B2BUA's to be precise, but UA's nonetheless).

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 May 2010 08:22:05 +0200

Hi, 

>>As said earlier, 3261 already says that OPTIONS addressed to proxies 
>>are to use sip:hostport, so I don't think we need to say anything about that.
> 
>But this is *not* to a proxy, or at least not always to a 
>proxy.  The draft is for it between UA's as well (B2BUA's to 
>be precise, but UA's nonetheless).

True, I was also talking about proxies.

But, I believe 3261 also says that OPTIONS addresses to UAs are using the hostpart. Would need to double check, though.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 May 2010 02:46:48 -0400

I don't think so - it was ambiguous for that.  It only said this in section 11:
   The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.  If the OPTIONS is
   addressed to a proxy server, the Request-URI is set without a user
   part, similar to the way a Request-URI is set for a REGISTER request.

It didn't explicitly say how to address a UA instance, only a proxy. (of course how one knows a priori that the next-hop is a proxy vs. a b2bua is beyond me)  

But it doesn't really matter.  In practice, historically even using sip:hostport has had problems, especially if the next-hop is an SBC.  Because an SBC doesn't know if the OPTIONS request is really for itself, vs. for an authoritative proxy for the domain, behind it - if it knew the OPTIONS was for a ping, it would know it's for itself; but if it's for capabilities then it was always a guess as to whom it's for; and of course the OPTIONS doesn't say which it is so it's always a guess.  So people set max-forwards to either 0 or 1 to avoid it going further, and that caused other issues (like getting a 483 instead of a 200, and incrementing loop-detection counters).

So today you have a bunch of configuration you may need to set, and to set it you need to know what the next-hop or previous-hop expects.  So it's error-prone, tedious, and not fun.

-hadriel

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 2:22 AM
> >
> But, I believe 3261 also says that OPTIONS addresses to UAs are using the
> hostpart. Would need to double check, though.
> 
> Regards,
> 
> Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 May 2010 08:57:20 -0400

If you dig into it, the notion of "addressing OPTIONS to a proxy" is not 
a meaningful concept, so defining rules for how to do it is meaningless.

This is because "proxy" is a *role* a server takes on, not a particular 
type of server. The same box may sometimes act like a proxy, and 
sometimes ack like something else. And by definition, when a box 
generates its own response to an incoming OPTIONS request, it is acting 
as a UAS.

The situation that is most proxy-like in this regard is when a request 
arrives, isn't addressed to the receiving server, and max-forwards is 
zero. If it returns 200 response in such a case, then I suppose we can 
conclude that it was at least a middle-box, though it might still 
normally act as a B2BUA rather than a proxy. In any case, in this 
situation, the request is by definition not addressed to this box, so 
imposing requirements on the form of the R-URI would be silly.

So fundamentally we need to just be talking about what it means to 
address a specific server, without regard to what sort of server it 
might be. And IMO that simply means using a URI with a domain that 
server "is responsible for". All URIs with that domain are in some sense 
addressed to that box, regardless of user part. At that point it is up 
to that box to interpret the user part as it sees fit. Some user parts 
may be treated by it as identifiers of certain resources within the box. 
Others might be treated as requiring retargeting. Note that even a URI 
with *no* user part could be treated as requiring retargeting. (E.g. the 
box might be a load balancer.)

	Thanks,
	Paul

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 6 May 2010 12:07:03 -0400

Christer,

Sounds good.  How is this?

    The OPTIONS message SHOULD be addressed to a peer SIP entity using
    a SIP URI of the form "sip:hostport" (see Section 25.1 of RFC 3261
    for definitions).  For example, "sip:192.168.1.5" is preferred, whereas
    "sip:[email-masked]" is not preferred for the purpose of this memo.
    The request URI required when addressing a proxy is described in
    Section 11 of RFC 3261.

Paul

> Sent: Thursday, May 06, 2010 1:34 AM
> To: Gonzalo Salgueiro
> Cc: Paul E. Jones; [email-masked]
> Subject: RE: [sipcore] draft-jones-sip-options-ping-01
> 
> 
> Hi,
> 
> Similar to comments that have been given for INFO, we should not
> "duplicate" MUST/SHALL/SHOULD/etc that are already in RFC3261.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 11:30:33 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 8:57 AM
> To: Hadriel Kaplan
> 

Agreed.

> box might be a load balancer.)

I'm not exactly clear on what you're proposing.  

If you're proposing the request be set to "sip:domain.com" or "sip:192.1.2.3", that hasn't worked in practice and probably can't without an indicator the OPTIONS is for status/ping.  

If you're proposing to use "sip:[email-masked]" or "sip:[email-masked]", that's what I was originally proposing, except I was proposing "special-user" be a well-known reserved name.

But on thinking about it more I concurred with your original proposal several emails ago, to just have a new SIP Header to indicate the OPTIONS is for the status/ping. (or we could make it a more generic header which says something like "this is for the system's administrative process", so we could use it in SUBSCRIBEs, for example)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 12:57:39 -0400

At end...

> But on thinking about it more I concurred with your original proposal several emails ago, to just have a new SIP Header to indicate the OPTIONS is for the status/ping. (or we could make it a more g…

Sorry, I guess my comment left things dangling.

My point was that there currently is no consistent and well known way of 
identifying "the box". There isn't even a *notion* of addressing "the 
box", as distinct from any of the resources it manages.

One answer is that if you want to ping something, you need to find 
something to ping that has the properties you want, and that will be 
identified by *some* URI, but not the same one for every box, and maybe 
none for some boxes. So you need to find out by provisioning what it is 
that you should address your pings to.

I don't find that answer very satisfying.

Alternately, we have to come up with a unique way of addressing the ping 
to something with the appropriate properties, without appropriating a 
username value that some might object to.

I *guess* we could pick some obscure value for the user name for this 
purpose. But I hate appropriating special values out of someone else's 
namespace. Rather I think we should use some namespace that we control.

I see several possibilities:
- a new header indicating that this (OPTIONS) request has a
   special meaning

- a special URI parameter indicating that this request is addressed
   to a special function rather than to the normal resource
   associated with the URI

- a new request type (e.g. PING) in which case we get to specify
   all the semantics

I can find no particular benefit to the URI parameter over the header 
parameter, and it raises various other questions I'd just as soon avoid 
going into.

I have some fondness for a new method, but find the new header on 
OPTIONS to be roughly as good, and more people seem to like it, so I'm 
ok with that.

I do however appreciate the points that Cullen has raised, and would 
like to see them addressed before we go much further with this.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 May 2010 11:53:06 -0400

> Sent: Friday, May 07, 2010 12:58 PM
> 

Me neither.

> like to see them addressed before we go much further with this.

Although I agree that the overload-chartered work is meant to improve things from the on/off flapping model we have today, I don't see how that invalidates the need or value of clearing up OPTIONS.  In some ways it's orthogonal, because the addressing problem still exists for OPTIONS regardless.

For sake of argument, ignore the "ping" aspect of OPTIONS.  Let's just say you wanted to send an OPTIONS to a SIP device (proxy, B2BUA, or UA) to learn its capabilities - the *system's* capabilities, not a particular user instance in it.  How would you do that?  In practice today: through manual configuration.  So let's say we went and created a draft to fix that, by using a new header.  In that same draft, we re-iterated or clarified what the responses to such a query would mean.  In effect, that's Paul's draft.

Furthermore, if we cleared up how OPTIONS can be addressed, one could use an OPTIONS to exchange the new overload info.  And likewise, a SUBSCRIBE for overload info has the same issues OPTIONS does in terms of addressing.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 10:17:20 -0400

Inline...

> For sake of argument, ignore the "ping" aspect of OPTIONS.  Let's just say you wanted to send an OPTIONS to a SIP device (proxy, B2BUA, or UA) to learn its capabilities - the *system's* capabilitie…

My counter-argument here is that the "system capabilities of a box" 
isn't necessarily a well defined concept. There may just be a 
multiplexer, based on the user part of the uri, to a variety of software 
agents. So no matter what you address the request to you are actually 
getting the status of one software agent or another, not of the box as a 
whole.

I interpret 3261 as saying the those elements "responsible for a domain" 
are the masters of the URIs that are valid in that domain. Others, that 
are not responsible for the domain, have no business "fabricating" a URI 
by pasting together a user part of their choice with the domain name. 
Instead they should be using addresses that are "given to them" directly 
or indirectly by an "agent" of the domain.

There is one case I know of where that is formally not the case. It is 
when using REGISTER, where a sip URI without user part is the R-URI. 
That is a restriction for domains that support REGISTER, and potentially 
may apply only to REGISTER.

Of course, this philosophy is violated all over the place. It can be 
justified in some cases as a matter that in some cases knowledge of the 
policy of a particular domain may extend to elements beyond those 
"responsible for the domain". But that still doesn't justify making such 
assumptions about a domain you have no special information about.

(And of course you an violate this is you are prepared for the 
consequences. If I didn't know Hadriel's sip URI, I might just try a 
variety of user parts in sip:[email-masked] it hopes of guessing it.)

I think it is a big philosophical step to say that there is a reserved 
sip uri that will be serviced by *something* that can speak for the box 
as a whole.

> Furthermore, if we cleared up how OPTIONS can be addressed, one could use an OPTIONS to exchange the new overload info.  And likewise, a SUBSCRIBE for overload info has the same issues OPTIONS does…

I wonder if that doesn't have some of the same issues - that a box may 
server as a multiplexer for a number of software agents. Much or all of 
the "overload" attributes may be attributable to those software agents, 
not to the box in general. I can certainly imagine architectures where 
requests to sip:[email-masked] is overloaded, while requests to 
sip:[email-masked] is not overloaded.

But I haven't been party to the overload work, so I don't know what the 
thinking is like in that regard.

To me this seems like a reason to include the ping clarification (at 
least with respect "addressing the box") into the overload work. And to 
a certain extent that may also be true for the question of inconsistent 
responses to conditions, since the inconsistent responses of concern are 
all (I think) related to overload and up/down type conditions.

	Thanks,
	Paul

---

From: "Roy, Radhika R Dr CIV USA USAMC" <[email-masked]>
Date: Mon, 10 May 2010 10:37:31 -0400

Hi, Paul K.

Does it not mean that the very concept of Box is misleading?

In summary, does it not mean that we should rather keep our focus on "Agent" as a point of basic reference that controls Domain?

Best regards,
Radhika

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
Date: Monday, May 10, 2010 10:17
Subject: Re: [sipcore] draft-jones-sip-options-ping-01
To: Hadriel Kaplan <[email-masked]>
Cc: "Paul E. Jones" <[email-masked]>, "[email-masked]" <[email-masked]>

> >> I do however appreciate the points that Cullen has raised, and 
> would>> like to see them addressed before we go much further with 
> this.> 
> > Although I agree that the overload-chartered work is meant to 
> improve things from the on/off flapping model we have today, I 
> don't see how that invalidates the need or value of clearing up 
> OPTIONS. In some ways it's orthogonal, because the addressing 
> problem still exists for OPTIONS regardless.
> > 
> > For sake of argument, ignore the "ping" aspect of OPTIONS. 
> Let's just say you wanted to send an OPTIONS to a SIP device 
> (proxy, B2BUA, or UA) to learn its capabilities - the *system's* 
> capabilities, not a particular user instance in it. How would you 
> do that? In practice today: through manual configuration. So 
> let's say we went and created a draft to fix that, by using a new 
> header. In that same draft, we re-iterated or clarified what the 
> responses to such a query would mean. In effect, that's Paul's draft.
> 
> > Furthermore, if we cleared up how OPTIONS can be addressed, one 
> could use an OPTIONS to exchange the new overload info. And 
> likewise, a SUBSCRIBE for overload info has the same issues 
> OPTIONS does in terms of addressing.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 10 May 2010 15:26:50 -0400

Radhika, Paul,

I agree that the concept of a "box" is vague.  There is, though, an
addressable user agent to which we can send an OPTIONS message to query for
its operational status.  Within the subject draft, that's what we propose to
do.

Perhaps even using the word "propose" is not accurate, as this draft was
written in response to what clearly appears to be behavior already widely
implemented.  Unfortunately, it's not consistently implemented.  For
example, some devices return a 486, 503, or even 600 when they wish to
report that they're in an state where they cannot accept new dialogs.

I believe work on overload is important, but the purpose of overload is
rather different than sending an OPTIONS to a user agent to determine its
operational state.  The work on "keep" is also important, but the focus of
this draft is not to maintain open pinholes through a firewall.

The scope of the subject draft is purposely narrow.  Arguably, it's not
needed since RFC 3261 already defines these procedures.  Our assertion,
though, is that RFC 3261 does not go far enough in providing clarity so as
to ensure that the response to an OPTIONS "ping" is meaningful.  Perhaps
this draft doesn't, either, but recognize that this is just a draft and
we're prepared to make changes to improve clarity.

Paul

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Roy, Radhika R Dr CIV USA USAMC
> Sent: Monday, May 10, 2010 10:38 AM
> To: Paul Kyzivat
> Cc: Paul E. Jones; [email-masked]; Hadriel Kaplan
> In summary, does it not mean that we should rather keep our focus on
> "Agent" as a point of basic reference that controls Domain?
> 
> Best regards,
> Radhika
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 15:49:13 -0400

Paul E. Jones wrote:
> operational state. 

I'm still struggling to understand the difference.
With overload control the sender is trying to avoid sending to a box 
that is "overloaded". In the extreme, and overloaded box is pretty 
similar to a "down" box. We also want to avoid sending messages to a 
"down" box.

And overload status may come in degrees. So when given a choice, the 
sender may choose to send to the "least loaded" box.

So using OPTIONS to determine this sort of thing is pretty closely 
aligned with overload control. What are the other uses of OPTIONS ping 
that are *not* in this category?

> The work on "keep" is also important, but the focus of

At this point I think several people seem to have somewhat different 
conceptions of what is missing and what is needed. There may indeed be a 
need here. It just seems like so far we have a solution proposed while 
we as yet don't have clarity on what it is the solution *to*.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 17:09:57 -0400

> Does it not mean that the very concept of Box is misleading?

There is nothing wrong with the "concept" of a box.
Its just that we have no sip artifacts that correlate to a box in a 
consistent way across implementations.

> In summary, does it not mean that we should rather keep our focus on "Agent" as a point of basic reference that controls Domain?

My use of "agent" was informal. We probably have similar problems 
defining it.

IIUC, the goal in all of this is to provide information via one request 
to some sip URI that is useful for predicting future behavior for some 
set of sip methods sent to some set of sip URIs.

The trick is identifying the mapping between the set of things you are 
interested in predicting the behavior of and the address you send the 
query to.

To get very far with this I think it will be necessary to restrict the 
architectures it applies to. Maybe there is some set of assumptions that 
are valid across a broad range of interesting implementations, or not. 
That may become apparent by trying to get agreement on what those 
assumptions are.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 10 May 2010 17:25:34 -0400

Paul,

> similar to a "down" box. We also want to avoid sending messages to a

The OPTIONS method is not used only to determine is a user agent is
overloaded.  This is just one example we've discussed.

We're not proposing to make fine-grained routing decisions based over the
results of an OPTIONS response, though it certainly has some utility for
helping to facilitate traffic.  Not all devices need the same level of
granularity and responsiveness as what might be provided via overload.  Even
so, a service provider would likely appreciate knowing a box is currently in
a maintenance state so as to not waste time directing traffic to a
known-down device.

A 503 could tell the administrator that there is an issue and that code
would also be used when an administrator takes a box down for maintenance
(as per 3261).  Most certainly, a 500 likely would mean there is a problem
that needs immediate attention.  So, it has management value.

The OPTIONS "ping" could be used to check the status of an IP phone or ATA
device, neither of which are likely to implement the overload spec.
 
A service provider may not be very interested to know whether a small
business SBC is overloaded or not, but it might want to know whether it's
responsive in the least and what status it is reporting presently.  Even in
cases where two peer SBCs might want to know overload information, that does
not eliminate the desire for an administrative device to also want to
collect status information.  Managed service providers would likely want to
keep close tabs on the current state of a PBX or SBC, but that information
may or may not be collected by an SBC.

> sender may choose to send to the "least loaded" box.

Yeah, and that's not what we're trying to address.
 
> that are *not* in this category?

See above.
 
> we as yet don't have clarity on what it is the solution *to*.

For a variety of reasons (as mentioned above), there is a desire to learn
the operational status of a given user agent.  The method through which one
accomplishes this task is by sending an OPTIONS message as per RFC 3261.
This will report whether the device is operational (200) or overloaded or
down for maintenance (503).  In practice, though, we see lots of response
codes returned, just for these two basic states.

Since there are so many varied implementations all over the map, a desire
was expressed to be able to differentiate an OPTIONS "ping" from an OPTIONS
intended to query device capabilities.  Personally, I would make no
distinction in my code, but the fact is that we're dealing with an aging
protocol with a lot of legacy implementations we need to consider.
Therefore, I conceded on the request to make a distinction by including a
header (of some sort) to indicate that the message is a "ping".  For those
who do wish to implement two code paths in order to support different
behavior, they could use that header to do that.  On that point, I don't
really care so much: I'd encourage a single behavior, but I'm not going to
argue with folks who clearly see value in having something to use as a
differentiator: if they see a need, then one likely exists.

The bottom line is that we're not trying to define anything not already
defined in RFC 3261.  What we are trying to do is improve upon that text by
recommending response codes and clarifying the fact that OPTIONS may be used
for this purpose.  If we do not move forward with this draft, then we just
live with the varied implementations.  I do not think the work on overload
will likely eliminate use of the OPTIONS "ping" for the aforementioned use
cases, so we'll continue to see varying behavior.

Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 May 2010 17:19:23 -0500

> its operational status.  Within the subject draft, that's what we propose to

The problem is that sip"[email-masked]", "sip:[email-masked]",
"sip:[email-masked]", and "sip:[email-masked]" might actually be
four different SIP user agent instances, using four different software
stacks, all being demuxed by an independent proxy module running on port
5060 of "192.168.3.1", which might also be a UA for
"sip:[email-masked]" (or something entirely different), meaning that
it too isn't "just a proxy".

Which piece of software did you want to have answer the "ping" and how
is this not somehow different real behavior from what RFC 3261 says?

We can certainly alter the behavior of OPTIONS using option-tags and
headers. But this doesn't make it "automatically work" when the
recipient doesn't understand the extension. Rather, it makes the request
automatically (and detectably) fail, so that the UAC sending the OPTIONS
request can fall back to sending an old-fashioned OPTIONS if it wants to.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 18:33:33 -0400

> overloaded.  This is just one example we've discussed.

I think you are viewing "overload" more narrowly than I am.

> a maintenance state so as to not waste time directing traffic to a

A box in maintenance state is effectively "down" if it won't accept 
additional calls. Though this may be subtle if it will still accept some 
class of requests, such as those that are in-dialog, while rejecting others.

But "wasting time" directing traffic to known-down devices is, AFAIK, a 
valid subject for overload control, since it loads the network and the 
sending device.

Maybe it is not part of the currently planned work on overload control.
But if not, then I would argue that we should consider broadening the 
charter of that WG, rather than inventing an entirely separate solution 
to another aspect of the same problem space.

> that needs immediate attention.  So, it has management value.

A 500 has essentially no predictive value about how other requests will 
be processed in the future.

> device, neither of which are likely to implement the overload spec.

What would be the purpose of obtaining this information?
This is one of the primary uses for OPTIONS as it is defined in 3261. 
Its is expected to return the same result as an INVITE would. There are 
many reasons why that doesn't mean as much as it might seem, but I don't 
think we need a lot of clarification for that usage.

It might be more complicated if you don't send the OPTIONS to the same 
address as you would send an INVITE. That is because there is probably 
no particularly good answer in that case - at least without being much 
more precise about the intended use of the result.

Even dumb devices probably should implement some limited form of 
overload control, once that is defined. At least enough to protect the 
network.

> business SBC is overloaded or not,

It *ought* to be, of it isn't providing very good service.
And ignoring this and as a result reaching congestion collapse isn't 
good for it even if it doesn't care about the PBX.

> but it might want to know whether it's
> responsive in the least and what status it is reporting presently. 

Why would it want to know one and not the other?
If it doesn't care about overload control, wouldn't most likely not care 
whether the device is up either? If its not doing overload control, then 
the most interesting statistic is likely to be the number of calls 
delivered successfully, vs. the number that failed due to lack of 
response by the pbx.

Sure, it might want this information just because it is "curious". But 
we are going to have a hard time refining the definitions of these 
various "states" without some notion of how they are to be used.

> Even in

All of the above cases you are mentioning are of interest *before* 
nailing down the mechanism to address them.

> the operational status of a given user agent. 

I do believe there are a number of good reasons to want to know 
"operational status". I think most of them have to do with wanting to 
predict certain aspects of future behavior. But the devil is in the 
details: what aspects of future behavior do you wish to predict? What 
information would be useful for making that prediction? And who has that 
information?

The response code to an OPTIONS request will have some limited 
predictive value. Will refining the way options responses are made 
improve that predictive value?

Will it provide predictive value that is needed and not already 
available? Maybe, but I don't really know. Only if we know what kinds of 
predictions are to be made will we be able to determine that. And that 
is exactly the info that I am not seeing so far.

	Thanks,
	Paul K

> The method through which one

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 10 May 2010 20:28:07 -0400

Dean,

> it too isn't "just a proxy".

What I proposed was sip:hostport.  I understand that there may be a wide
variation of things done in practice, but one ought to be able to expect
some predictable behavior when sending an OPTIONS to 192.168.1.10 addressed
to sip:192.168.1.10.
 
> is this not somehow different real behavior from what RFC 3261 says?

Whatever software should respond to sip:192.168.1.10.  I'm not proposing any
behavior that is different than RFC 3261, though I am recommending the
preferred form of addressing and response value.
 
> request can fall back to sending an old-fashioned OPTIONS if it wants

I never proposed a different behavior, though some did.  In that case, we
could insert headers as you proposed, perhaps a header in the request and
response.  There were valid reasons for doing that with which I'll not
argue.

I recognize that it would take time be implemented widely, but I also don't
see that as an issue.  Remember, I'm proposing the use of this "ping"
between two devices that have some general knowledge of each other.  I would
not expect this to be sent out over the Internet.  Rather, it would be used
between a management system and devices it manages or between two SBCs, etc.
So, the scope is relatively narrow as compared to the interoperability
requirements of sending an INVITE out over the Internet.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 00:14:13 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 6:19 PM
> To: Paul E. Jones
> Cc: 'Roy, Radhika R Dr CIV USA USAMC'; 'Paul Kyzivat'; [email-masked];
> 

Right now, Paul is only stipulating what 3261 says, because he's proposing using "sip:hostport" and wants to query the logical "proxy" role of the next-hop.

RFC 3261 section 11 says:

> request can fall back to sending an old-fashioned OPTIONS if it wants to.

Paul's current draft proposes that we formulate the OPTIONS as per RFC 3261, such that it would be interpreted as "an old-fashioned" OPTIONS.

Some of us (maybe only me) feel there should be something different about this particular OPTIONS, because we'd like to know the OPTIONS we received, or the response to one we sent, is actually following the draft's clarifications for response codes.  It doesn't *have* to do that - the whole thing could be based purely on configuration; but it would be *nice* to make this thing automatic by the existence of a header field.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 00:55:06 -0400

OPTIONS already exists.  It is widely deployed.  It is widely deployed as a way to query system status. (Arguably more so for that than for query of actual extensions/sdp/etc.)  RFC 3261 specifically described this use-case for OPTIONS.  In practice, though, it has interop issues.  The interop issues mostly revolve around response codes and target addressing.  Today, those interop issues are resolved by manual configuration.  Paul is trying to alleviate those interop issues by recommending a particular configuration, which follows rfc3261's language.  One could almost call it a BCP. (except the term "BCP" means something different in IETF than normal nomenclature)

So he submitted a draft to do that.  The response he gets is "we're working on an overload control mechanism and this thing has a bit of that... so no, we can't clean this up".

It's like you guys are saying "Oh your arm hurts when you lift stuff?  Well we could fix that, but we're working on giving you a new hand, and that holds the things you lift, so stop using your arm while we go design this new hand for it... oh and make sure you tell the hand designers about this arm problem...".   No?

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 11 May 2010 00:08:19 -0500

Hadriel Kaplan wrote:

>> We can certainly alter the behavior of OPTIONS using option-tags
>> and headers. But this doesn't make it "automatically work" when the
>>  recipient doesn't understand the extension. Rather, it makes the
>> request automatically (and detectably) fail, so that the UAC
>> sending the OPTIONS request can fall back to sending an
>> old-fashioned OPTIONS if it wants to.
> 
> Paul's current draft proposes that we formulate the OPTIONS as per
> RFC 3261, such that it would be interpreted as "an old-fashioned"
> OPTIONS.

If it's also being responded too as an old-fashioned OPTIONS and is
consistent with the content-rules of an old-fashioned OPTIONS and is
subject to the proxy-rules of an old-fashioned OPTIONS and is in fact,
in no way distinguishable from an old-fashioned OPTIONS, then you're
right and no extension is needed.

> Some of us (maybe only me) feel there should be something different
> about this particular OPTIONS, because we'd like to know the OPTIONS
> we received, or the response to one we sent, is actually following
> the draft's clarifications for response codes.  It doesn't *have* to
> do that - the whole thing could be based purely on configuration; but
> it would be *nice* to make this thing automatic by the existence of a
> header field.

Perhaps something that clarified the use cases for OPTIONS in general,
including targeting the request to a given node, preventing proxying of
the request using max-forwards, and clarifying the response codes for
different situations would be useful. Why just document the ping case?

And I'm still fuzzy on why you need to be able to differentiate a "ping
OPTIONS" from a "regular" OPTIONS. The use cases for doing this that
I've heard so far seem to require an extension.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 09:41:02 -0400

> It's like you guys are saying "Oh your arm hurts when you lift stuff?  Well we could fix that, but we're working on giving you a new hand, and that holds the things you lift, so stop using your arm…

Well, I guess the problem is that I am not getting answers to questions 
about *why* the options is being used - what one intends to accomplish 
with the answer. All I'm getting is "the answers that I get are 
inconsistent for my purposes". And so I am making my own assumptions 
about why, that are conflated with the overload work.

The fact is, there are many possible reasons to use OPTIONS. I suspect 
that the reason there are different responses to similar situations is 
at least in part because the person deciding what response to give made 
the decision based on his/her notion of what the response would be used for.

As I said yesterday, ISTM that one of the primary reasons for sending 
OPTIONS is so that the response to it can be used to make predictions 
about how future requests sent to related addresses will fare.

I could say more, but in the interest of reaching some level of common 
understanding, I won't. Instead, I'll just ask: is that the primary goal 
here?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 11:34:08 -0400

> Sent: Tuesday, May 11, 2010 9:41 AM
> To: Hadriel Kaplan
> 

For me it is.  I do also have a need to actually learn what the next-hop's supported extensions are (and I do mean "box-level" ones), but that's not the main driver use-case for me at this instant in time.  

So for me, the main use-case for sending OPTIONS right now is to learn the capability of the next-hop to process messages.  Load-related state, admin state, and actual transport layer reachability as well.  That's what many/most people have been doing with OPTIONS for the past many years, after all.  Paul J's not proposing to change that - just to clarify what 3261 says about it, so we don't have to do as much configuration to continue doing it.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 11:53:26 -0400

> Sent: Tuesday, May 11, 2010 1:08 AM
> To: Hadriel Kaplan
 
> I've heard so far seem to require an extension.

Basically because different vendors use different response codes and process the request slightly differently, but all are legal per 3261.  For example, let's say vendor X sends this OPTIONS per 3261, and expects a 503 to mean admin-down.  But some vendor Y responds to it with a 500 to mean admin-down.

Vendor Y is not going to change its default behavior, because they're deployed doing it that way and it's working.  So they need something in the request to tell them "this request is per draft foo, so use the specific response codes per draft foo".  Likewise, vendor X needs to know the responder did draft foo, so it doesn't apply its legacy default behavior (whatever that is) but follows draft foo instead.

So we could put some new param in the request's Via (like ";foo"), and have the responder set it to something (like ";foo=yes").  Or we could do it with a Header.  Either way, if the responder does not do foo both sides will just do their legacy default logic.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 13:50:54 -0400

[Changing the subject line]

Hadriel Kaplan wrote:
> For me it is.  
> I do also have a need to actually learn what the next-hop's 
> supported extensions are (and I do mean "box-level" ones), 
> but that's not the main driver use-case for me at this instant in time.  

Well, I would put that into somewhat the same bucket:
You are looking to predict which options will be supported for requests 
you might send in the future.

You seem to be making an assumption that extension support is uniquely 
defined at the "box-level". I don't think its proper to assume that in 
general, for a variety of reasons. For instance, a B2BUA may choose not 
to admit to support for an extension in the context of a dialog unless 
the "other leg" supports that extension.

This goes double for other "attributes" that may be reported by OPTIONS, 
such as: event packages, mime types, media formats, even methods.

(For the latter, what is a B2BUA supposed to do if it understands some 
method, but the other "side" doesn't?)

> So for me, the main use-case for sending OPTIONS right now is to 
> learn the capability of the next-hop to process messages.  

You mean the dynamic, current "capacity" to process messages, not the 
theoretical "ability" to do so when resources are available? Or do you 
mean both?

Do you mean:
- the theoretical "ability" to do so when resources are available,
- the "capacity" to do so given current load and resource availability,
- the "willingness" to do so, at this time, for this requestor?

> Load-related state, admin state, and actual transport layer 
> reachability as well.  
> That's what many/most people have been doing with OPTIONS for 
> the past many years, after all. 

I expect that people have had one, or more, of the meanings I list above 
in mind, perhaps without realizing that they are different. I'm willing 
to bet not everyone will agree its the same one of the above. OPTIONS, 
as currently defined, cannot provide all three answers. Nor will 
tightening up the specs change that, though doing so might make it do a 
better job of *one* of those.

So one thing we might do is narrow down which (possibly more than one) 
of those we want answers to. (I expect there will be desire for all three.)

Then, lets talk about what range of things a given response applies to:

Suppose I send OPTIONS to
- sip:198.51.100.101:5060
Does the response I get apply also to
- sip:198.51.100.101:5061,
- sip:[email-masked]:5060,
- sip:[email-masked]:5060,
- sips:[email-masked]:5061
- sip:example.com	(maps to 198.51.100.101)
- sip:pbx1.example.com	(also maps to 198.51.100.101)

It *might*, or it might not.

Paul J assumes that sip:<ip-address> is "special", in that it applies to 
the "box", whereas sip:<name>@<ip-address> might return something else.
And that might make sense for a proxy, or a proxy/registrar.

But for a "phone" sip:198.51.100.101:5060 might just denote the "primary 
line", while sip:[email-masked]:5060 may denote the "secondary line". 
And then the answer for one might have little predictive value over 
requests to the other. E.g. an OPTIONS to one might return 486 because 
the phone is busy, while an OPTIONS to the other might return 200.

For a gateway, there may well be DSP resources required to establish a 
call, and how much, or what type may depend on the codecs used in the 
call. So an answer to OPTIONS won't be valuable in predicting if a 
particular call can succeed.

So, I think we need to get specific about what we want to predict before 
deciding how to request the info to base those predictions on.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 14:40:57 -0400

> Of Paul Kyzivat
> Sent: Tuesday, May 11, 2010 1:51 PM
> 
> >
> > For me it is.

Yup, I know that quite well, and have made that argument before in IETF. :)

When I said "box-level", I meant capabilities *of* the B2BUA, at least with respect to me.  Not of any other "side", but of "my side".  In practice, there is a set of capabilities that could be indicated, and are.  Some of them would be quite useful, and really only apply on a per-hop basis anyway.  It's not everything, which makes it dangerous (and why I'm not suggesting doing it right now), but that's for a later time.

> method, but the other "side" doesn't?)

If it accepts the method on my "side", it accepts the method.  If the other side doesn't, then it will reject it when I send it.  Those two cases are not mutually inconsistent.  The B2BUA can make a routing decision which of many "sides" to send the request to, but it really does accept it and I really should send it to find out - as opposed to when it does not accept it on my side and there's no point ever sending it such a method.  

> theoretical "ability" to do so when resources are available? Or do you

Current.

> - the "willingness" to do so, at this time, for this requestor?

If you mean "for this requestor" to mean for the same hop (as opposed to for the same source Contact URI), then I'd argue the second and third are effectively the same thing, in practice.  I believe that has even come up in the overload discussions a long time ago, and I think there was agreement they are effectively the same thing, logically.  Just because a next-hop tells me it can't do any more, but tells someone else something different, doesn't matter to my local processing of future requests to it.

> better job of *one* of those.

In every case I have seen this used for in deployment, as far as I can tell they have actually meant the same thing.

> - sip:pbx1.example.com	(also maps to 198.51.100.101)

YES.  If the responder understands the Header, then it's reporting a system-level capability. (luckily you forgot about anycasting ;)

> the phone is busy, while an OPTIONS to the other might return 200.

Hence the need/desire for a Header.

> particular call can succeed.

That's OK.  A "box-wide" semantic is a superset.  If you can handle ANY more calls (from that previous hop), then "box-wide" you can handle more calls.  That doesn't mean you can't reject future calls due to unavailable resources such as DSPs.  If you can NOT handle any more "box-wide", for example due to CPU, then the number of DSP resources you have really doesn't matter.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 May 2010 15:14:59 -0600

On May 10, 2010, at 10:55 PM, Hadriel Kaplan wrote:

>  Paul is trying to alleviate those interop issues by recommending a particular configuration, which follows rfc3261's language.  One could almost call it a BCP. (except the term "BCP" means something different in IETF than normal nomenclature)
> 

Really? I did not get that out of the draft. If you mean that the drafts thinks it is OK to a SIP URI that has a host portion with no user name, well I took that as fairly obvious that was OK in 3261.  Section 11 explicitly discusses it.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 17:30:13 -0400

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 5:15 PM
> To: Hadriel Kaplan
> 
> >  Paul is trying to alleviate those interop issues by recommending a
> particular configuration, which follows rfc3261's language.  One could
> almost call it a BCP. (except the term "BCP" means something different in
> IETF than normal nomenclature)
> > So he submitted a draft to do that.  The response he gets is "we're
> working on an overload control mechanism and this thing has a bit of
> that... so no, we can't clean this up".
> 
> Really? I did not get that out of the draft. If you mean that the drafts
> thinks it is OK to a SIP URI that has a host portion with no user name,
> well I took that as fairly obvious that was OK in 3261.  Section 11
> explicitly discusses it.

Right, but it wasn't clear enough to make it usable without configuration in many cases.  First, because if you send it to a proxy or b2bua between you and the Registrar, it's not distinguishable from an OPTIONS targeted to the Registrar, so some proxies/b2buas will forward it to the registrar.  If you set a max-forwards of 0 to stop that, you'll get a 483 from some proxies/b2buas instead of a OPTIONS-based response.  That's legit too, since 3261 only said:
   Alternatively, a server receiving an OPTIONS request with a Max-
   Forwards header field value of 0 MAY respond to the request
   regardless of the Request-URI.

Then there's the response status code itself and clarifying section 11.2.

So afaict Paul's draft is trying to clear up 3261's language to be explicit and avoid the manual configuration for these types of issues.  (though I may be reading more into it than is there, or than Paul intends)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 20:39:42 -0400

This is fragmenting into multiple issues that ought to be discussed 
separately. But I want to go home so I'm not splitting it up.

inline...

> If it accepts the method on my "side", it accepts the method.  If the other side doesn't, then it will reject it when I send it.  Those two cases are not mutually inconsistent.  The B2BUA can make…

Lets use MESSAGE for discussion. You would report MESSAGE in an Accept 
header. Then later you receive MESSAGE, forward it to the "other side", 
and get back a 405, including a list of methods that are supported, not 
including MESSAGE. Do you pass that Accept on? Or alter it to indicate 
that you *do* support MESSAGE even though you are rejecting it with a 405?

There is no way to win here. You must be inconsistent at some point. So 
the result of the OPTIONS wrt Accept cannot be trusted to predict future 
behavior. The same is true for most of the other things reported in 
OPTIONS - its really hard to say much about how relevant they are for 
predicting future behavior.

To do better, I think it is necessary to either:
- specify in the query the context of the question, or
- return a complex document that describes what is supported under
   a variety of circumstances.

I doubt we want the latter (at least I don't).

Specifying the context for which you want an answer is also pretty 
difficult to do, given the number of different contexts that are 
possible. Maybe its possible to do a few interesting ones.

One is to send an OPTIONS to a URL and get an answer that pertains to 
*that* URL, while not necessarily pertaining to any other URL. AFAIK 
that is, more or less, what the current definition of OPTIONS does. You 
might choose to extrapolate the results for that URL to other URLs, but 
that may or may not produce correct results. Of course this is also 
limited, in that it only reports the results for OPTIONS. It has no way 
to customize the results for other methods. (For instance, some MIME 
types are likely to be acceptable only in the context of certain 
methods. Application/SDP may not be acceptable for MESSAGE.)

To get beyond the answer for one URL, we need a way to indicate we want 
an answer for a class of URLs, maybe all of them. Some seem to think 
that a URL with no user part is an indicator for this. I think that is 
probably a sensible meaning for some servers, but not all of them. IMO 
there is no good value you can pick to put in the user part of the R-URI 
to indicate this. But perhaps it could be indicated via some new header. 
If this is the desire, and single answers are desired, then some 
accuracy must be given up. Presumably the answer must be the union of 
the answers for all the URIs it applies to. So for any particular URI 
the answer might be less.

Also, there is the distinction between what might be available on a good 
day, vs. what the server is currently capable of, vs. what it is 
*willing* to do. Again, I don't see how any one answer is the right one 
for this. (E.g. the server is heavily loaded. It is capable of accepting 
*some* requests, but is only willing to accept requests from privileged 
callers. Or, it is in shutting-down mode. It has plenty of resources, 
but is only willing to accept in-dialog requests.)

Again, I think to get at this will require an indicator in the request 
of which sort of answer you want. Unless we can agree the answer is 
always and only about *capability*, and never about policy.

Bottom line here: I think there needs to be a selector, or selectors, 
for which kind of answer is desired.

>> theoretical "ability" to do so when resources are available? Or do you

Sorry - I botched my message that you are replying to. I wrote the 
above, then the list immediately below to replace that.

> If you mean "for this requestor" to mean for the same hop (as opposed to for the same source Contact URI), then I'd argue the second and third are effectively the same thing, in practice.  I believ…

I meant whatever the server would use as input to any policy decisions 
it might make. That might mean the sender of the message (top Via 
value), the originator of the request, whatever.

For instance, administrative shutdown would be a policy that determines 
willingness to handle requests. (At least until the listeners are 
stopped.) It might apply to certain links, which is what you are getting 
at. It might also apply to certain request originators, or to in-dialog 
vs. out-of-dialog requests, etc. It might also apply to certain R-URIs.

Policies to throttle load before overload occurs could also fall into 
this category of "willingness".

The specified expectation that an OPTIONS should return 486 if the 
device (a phone presumably) is on a call also falls into this "policy" 
category, since it could alternatively hang up the existing call or put 
it on hold to accept the new call.

I can see utility in getting theoretical capability as well: it would be 
nice to be able to determine which if any of your devices could support 
video, even if currently busy. I might then choose to wait till the 
video phone is free rather than calling now on the audio phone. (But of 
course this is better done with presence.)

But, if the majority of people can agree on a single context in which 
they want an answer, then perhaps we can simply have a single indicator 
that says we want that, rather than whatever it is that OPTIONS 
otherwise returns.

> In every case I have seen this used for in deployment, as far as I can tell they have actually meant the same thing.

To be fair, ACME has a particular perspective. SBCs talk to a certain 
class of equipment. I doubt you have need to interface directly to 
phones. But others do use OPTIONS to phones.

> YES.  If the responder understands the Header, then it's reporting a system-level capability. (luckily you forgot about anycasting ;)

I slipped some ringers in there for you. :-)

There is no guarantee that two ports for the same ip address are served 
by the same "server". They may be served by separate processes with 
independent resources. Statistically there is probably a good chance 
that 5060 and 5061 are served by the same server. But once you get past 
that, then what?

I didn't put in multi-homing situations, or IPv6/IPv6 cases, but they 
apply too. For all of these I can't see a good alternative to assuming 
they are distinct and asking on each, or *configuring* the cases when 
you *know* they are the same.

And I still disagree with assuming they are the same when the user part 
varies, unless we add something to the message to indicate that is what 
is desired. But even an indicator won't deal with the port issue, or 
with multihoming, since you can't know if the device speaks for the 
others. OR, the response could be altered to indicate all the different 
addresses is applies to.

> That's OK.  A "box-wide" semantic is a superset.  If you can handle ANY more calls (from that previous hop), then "box-wide" you can handle more calls.  That doesn't mean you can't reject future ca…

That is a possible interpretation.

If some (expensive) codecs are disabled during peak load, should that be 
reflected in the response?

What if some destinations are currently unreachable? Should OPTIONS for 
a particular address reflect that? (E.g. only +1... calls are currently 
operational because the international trunk is down. Should OPTIONS to 
sip:+44... return 480 or 200?)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 22:39:00 -0400

> Sent: Tuesday, May 11, 2010 8:40 PM
> To: Hadriel Kaplan
> 
> Hadriel Kaplan wrote:
> >
> > If it accepts the method on my "side", it accepts the method.  If the
> other side doesn't, then it will reject it when I send it.  Those two
> cases are not mutually inconsistent.  The B2BUA can make a routing
> decision which of many "sides" to send the request to, but it really does
> accept it and I really should send it to find out - as opposed to when it
> does not accept it on my side and there's no point ever sending it such a
> method.
> 

I think you're missing my point - when you send a request to user1@foo what you get back is about user1@foo.  So if you get back an Accept without MESSAGE, you may be able to know something about user1@foo, but NOTHING about user2@foo.  There is no inconsistency there.

But as I said in the previous email with regards to what could reasonably be learned from the response: "It's not everything, which makes it dangerous (and why I'm not suggesting doing it right now), but that's for a later time."  Allowed methods, for example, is probably a borderline one.  But most of the capabilities which I would want such a thing for would really be proxy type of capabilities: things like keepalives, sigcomp, secagree, and some transport/connection things which should arguably be in DNS SRV's but are basically always manually provisioned today.

> the answer might be less.

Exactly - when you send it to a URL, the result is about the URL; and currently lots of devices do assume no user part is effectively all of them (of that particular URL), and I have been agreeing that a Header is a fine way to make it unambiguous for that case.  I don't think anyone has objected to that, including Paul J.

> for which kind of answer is desired.

I don't think so.  Not in practice.  There is no real difference to the requestor whether the responder won't accept new requests because it's overloaded, shutting down, or just doesn't like you.  The resulting effect on the requestor is the same.  And at the end of the day, that's the important piece for interoperability: what the requestor should do given a response, not why the responder sent the response.

For the "privileged callers" case, if by "privileged callers" you mean specific calls from the same hop, then the responder really does accept requests, just not all requests, and should say it does accept requests - but that's *OK*, it's not _broken_ to not be able to signal every possible policy rule to previous hops.  It may not be optimal in some folks' minds, but it's not broken.  Same goes for the other "policy" cases you had in your email (I've removed them to reduce the size of this email).

> > In every case I have seen this used for in deployment, as far as I can
> tell they have actually meant the same thing.
> 

Actually over half of our SBC's talk to phones direct. (I count an MTA/IAD/Terminal as a phone - basically anything that Registers and represents a single user I consider a "phone")  But you're right SBCs don't generally send OPTIONS to phones unless something else sends it through the SBC to reach them, and I don't see that happening very much.  I usually see OPTIONS coming from phones to the SBC, or between an SBC and its next/previous-hop servers.

> > YES.  If the responder understands the Header, then it's reporting a
> system-level capability. (luckily you forgot about anycasting ;)
> 

Oops, missed the port numbers being different.  Right, those are different, because they're a different URL hostport.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 May 2010 22:41:57 -0600

Hmm, I'm still confused what the problem is that causes me to want to send an options to say my outbound proxy but if my outbound proxy/sbc/b2bua is configured to be outbound.example.com and my AOR it [email-masked], it seems pretty clear that I send it to sip:outbound.example.com if that's where I want it to go. 

> So afaict Paul's draft is trying to clear up 3261's language to be explicit and avoid the manual configuration for these types of issues.  (though I may be reading more into it than is there, or th…

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Wed, 12 May 2010 16:13:40 -0400

There is some predictive value of a blanket OPTIONS test, probably more than people realize.

In SIP, there can be multiple ways to accomplish a task.  Especially when propprietary extensions may be present, the theoretically correct way to handle the situation is to try the methods in order of decreasing preference until you discover a method that is supported:  Try A, if that fails, try B, if that fails, try C.  In practice, you'd like to know if the next-hop element doesn't support method A, so you can avoid the overhead of trying it on future calls.

In the case of proprietary extensions (which method A is likely to be), a single OPTIONs request can tell you if the element has never heard of the extension.  Because of downstream elements, you may still have to fall back to methods B and C at times, but there is a significant savings if you can detect the cases where the next-hop element cannot process method A *at all*.

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 May 2010 12:54:47 -0500

> predicting future behavior.

This gets right at the aspect of option-tags that people seem to keep
getting confused on.

OPTIONS responses and option-tags DO NOT assert (or require) anything
about "willingness" or "authorization". They assert only capability.

You can be capable of understanding a MESSAGE request without being
willing to accept one from a given party (or, in the case of a B2BUA, TO
a given party).

We keep falling back into trying to use optionality to predict or
mandate outcome. We MUST NOT do this -- the mechanism just doesn't work
this way. At best, optionality in SIP is a way of predicting
understanding, not behavior.

Consider the difference between Bob approaching Alice and saying "Would
you understand what I was asking if I asked you to go home with me?" vs.
Bob asking Alice "Will you go home with me?"

The first is an optionality discussion; the second is a request for a
specific extension.

--
Dean

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 13:20:02 -0500

[as a participant]

> Bob asking Alice "Will you go home with me?"

I nominate this for the award of "most illustrative analogy ever applied 
to SIP."

:-)

/a

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 13 May 2010 13:32:00 -0500

> I nominate this for the award of "most illustrative analogy ever applied

Oddly enough, about 30 seconds ago I sent a message to DISPATCH about
Bob chatting up Alice. Precognition, I guess.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org