Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Apr 2010 19:00:44 -0400

"root" obviously.  ;)
But seriously, picking a crazy username that won't collide is not that hard.  The question is if it's the right thing to do.

Paul Kyzivat <[email-masked]> wrote:

I will grant you that having per-user policies for what to include in
OPTIONS would be possible.

But using that approach here means reserving a specific username. Which
one are we allowed to pick that won't impact somebody? (I expect there
are people out there named "ping" who might not like having their user
name preempted.)

AFAIK we have never preempted a user name, except for Anonymous, which
is only preempted in the anonymous.invalid domain. I'd much rather see a
special uri parameter to designate this behavior.

        Thanks,
        Paul

Hadriel Kaplan wrote:
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Paul Kyzivat
>> Sent: Friday, April 23, 2010 1:28 PM
>>
>> Making a decision based on the form of the R-URI presumes that non-ping
>> users of options never use an ip address as the R-URI. Requiring the
>> R-URI to be ping@ip reserves a user part, and also is just a sleazy way
>> of adding another indicator to the message to indicate its intended use.
>
> Actually in a weird way I think doing a specific username may be the right thing to do.  Think about it from an email perspective.  When you check on the status and settings of an email list using SMTP, do you (a) send a new different SMTP message type, or (b) address a normal message to the actual logical administrative code for the list?  You send a normal message to [email-masked].
>
> And logically the thing being "pinged" is a higher layer, because the response provides an administrative status as well. (even though in code one would probably do this at a low level)
>
> Put it another way: in theory you could send a SUBSCRIBE to this logical admin-UA in that proxy so that it Notifies you when it goes admin up/down.  That logical UA is a resource in the proxy, and could be addressed as such.
>
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 08:55:33 -0400

> But seriously, picking a crazy username that won't collide is not that hard.  The question is if it's the right thing to do.

I don't believe in reserving names from other people's namespaces after 
the fact, on general principles. You cannot know how they use their 
namespace. You can reduce the probability of collision by making the 
value very obscure, but then it is very obscure.

So IMO it is the wrong thing to do.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Apr 2010 12:59:39 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, April 26, 2010 8:56 AM
> 
> Hadriel Kaplan wrote:
> > "root" obviously.  ;)
> > But seriously, picking a crazy username that won't collide is not that
> hard.  The question is if it's the right thing to do.
> 

So you think it's the wrong thing to do NOT because indicating the specific resource being targeted is the wrong thing, but rather that we can't safely pick a username?? 

There are solutions to that, for example:
sip:80737871;phone-context=[email-masked];user=phone
or this:
urn:admin:ping

But we could also bite the bullet and define a namespace concept for these types of things, because ping is not the first or last time we'll need it.  For example a SUBSCRIBE to overload info, if we go that way for overload, could use such a target resource identifier concept.  As could draft-ietf-sipping-policy-package.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 13:19:38 -0400

> So you think it's the wrong thing to do NOT because indicating the specific resource being targeted is the wrong thing, but rather that we can't safely pick a username?? 

Yes. I have no problem, in principle, with having a class of "standard" 
resource names, as long as we came up with an acceptable way to define 
them without treading on anyone's toes.

> sip:80737871;phone-context=[email-masked];user=phone

Yeah, that could work, but its really ugly.

> urn:admin:ping

That could work too, but then you couldn't use the R-URI for routing, so 
you would have to include a Route header to get it where you want it.
Still, that might work.

It could even fit within the existing service URN scheme.

> But we could also bite the bullet and define a namespace concept for these types of things, because ping is not the first or last time we'll need it.  For example a SUBSCRIBE to overload info, if w…

What did you have in mind? another URI parameter? E.g.

	sip:[email-masked];namespace=sipstuff

That raises all sorts of ugly issues. I like the URN better. The URN 
mechanism defines namespaces. It won't collide with anything, and those 
that don't support it will (hopefully) just return 404 or 416. Then you 
can just be happy with the error, or simply fall back to a "normal" OPTIONS.

But there are no doubt many other ways to skin this cat.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Apr 2010 15:39:09 -0400

I don't think we should reserve a name.  Use of options "ping" should be
between two devices that have some kind of established relationship and the
"ping" address should be known only locally.

Paul

> To: Hadriel Kaplan
> Cc: Paul E. Jones; 'Michael Miller'; [email-masked]
> Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-
> 00.txt
> 
> 
> 
> Hadriel Kaplan wrote:
> > "root" obviously.  ;)
> > But seriously, picking a crazy username that won't collide is not
> that hard.  The question is if it's the right thing to do.
> 
> >> Actually in a weird way I think doing a specific username may be the
> right thing to do.  Think about it from an email perspective.  When you
> check on the status and settings of an email list using SMTP, do you
> (a) send a new different SMTP message type, or (b) address a normal
> message to the actual logical administrative code for the list?  You
> send a normal message to [email-masked].
> >>
> >> And logically the thing being "pinged" is a higher layer, because
> the response provides an administrative status as well. (even though in
> code one would probably do this at a low level)
> >>
> >> Put it another way: in theory you could send a SUBSCRIBE to this
> logical admin-UA in that proxy so that it Notifies you when it goes
> admin up/down.  That logical UA is a resource in the proxy, and could
> be addressed as such.
> >>
> >> -hadriel
> >>
> >
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2010 15:49:53 -0400

> "ping" address should be known only locally.

IIUC, you are saying that any specific options-ping behavior should be 
the result of *configuration* of the UAC and UAS. And then can I infer 
that recognition that in incoming OPIONS is a ping would be based on 
source address and/or use of a "special" address that is configured into 
the UAC rather than reserved.

Is that right?

	Thanks,
	Paul (K)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Apr 2010 21:59:53 +0200

Hi, 

>> I don't think we should reserve a name.  Use of options "ping" should 
>> be between two devices that have some kind of established relationship 
>> and the "ping" address should be known only locally.
>
>IIUC, you are saying that any specific options-ping behavior should be the result of *configuration* of the UAC and UAS. And then can I infer that recognition that in incoming OPIONS is a ping would be 
>based on source address and/or use of a "special" address that is configured into the UAC rather than reserved.

Or a URI parameter. I assume the pings will use a pre-defined route, and would not be re-targeted etc. Maybe we can also assume that they will be used between adjacent nodes.

Regards,

Christer

>> I don't believe in reserving names from other people's namespaces 
>> after the fact, on general principles. You cannot know how they use 
>> their namespace. You can reduce the probability of collision by 
>> making the value very obscure, but then it is very obscure.
>>
>>> I will grant you that having per-user policies for what to include 
>>> in OPTIONS would be possible.
>>>
>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>> On
>> Behalf
>>>>> Of Paul Kyzivat
>>>>> Making a decision based on the form of the R-URI presumes that 
>>>>> non-
>> ping
>>>>> R-URI to be ping@ip reserves a user part, and also is just a 
>>>>> sleazy
>> way
>>>>> of adding another indicator to the message to indicate its 
>>>>> intended
>> use.
>> right thing to do.  Think about it from an email perspective.  When 
>> you check on the status and settings of an email list using SMTP, do 
>> you
>> the response provides an administrative status as well. (even though 
>> in code one would probably do this at a low level)
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Apr 2010 16:17:01 -0400

Paul,

> be

I don't think behavior of OPTIONS "ping" should be unspecified (as it is
today).  I'm only saying that we should not reserve in a specification a
particular address (e.g., "sip:ping@host") to which SIP OPTIONS should be
directed.  A vendor might want to process OPTIONS "ping" messages addressed
as sip:192.168.1.10 or sip:[email-masked], and I see no reason to specify
what that is.  We might specify that either form may be used.

What I had written in the draft originally was that OPTIONS should be
addressed only as sip:hostport, but I removed that paragraph from my working
draft since I can see some value in allowing a user part in the URI.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Apr 2010 16:19:02 -0400

> Or a URI parameter. I assume the pings will use a pre-defined route,
> and would not be re-targeted etc. Maybe we can also assume that they
> will be used between adjacent nodes.

What we wrote in the draft in that regard is that SIP messages must be sent
directly to the IP address of the peer.  The intent is that these messages
are not going to be sent to any intermediaries.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2010 18:26:30 -0400

> draft since I can see some value in allowing a user part in the URI.

I think I understand, but I still not certain I do.

I think you are saying that:

- there are potentially two behaviors in response to OPTIONS:
   . the "ping" behavior, which is potentially simpler
     and more optimized
   . the "normal" (non ping) behavior, which may have extra
     detail and be bigger and/or more expensive to produce.

- that there is *some* feature of the incoming OPTIONS message
   that the recipient uses to distinguish which behavior to apply.

- that the particular feature used to make that distinction
   may vary from one UAS to another. Its the responsibility
   of the UAC (e.g. via configuration) to know what it is that
   the UAS will used to decide, and then to construct the OPTIONS
   appropriately depending on which behavior it wants.

Is that right?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 22:10:11 -0400

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2010 4:17 PM
> To: 'Paul Kyzivat'
> 

The rub with that is it doesn't remove the per-hop interop configuration that a draft such as this one is trying to remove/avoid.  I'm not saying that makes the draft useless, because at least it would avoid the response-code configuration portion - but just wondering why we can't avoid the intended target issue as well.

BTW, defining the syntax for the intent of the request can be done multiple ways, and I was only suggesting that agreeing on a specific user name would be one way.  (it's always seemed to me to be a hack that requests intended for a Proxy to process as a logical UA are not addressed to a specific logical UA/resource, but instead just inferred by the Proxy as being for it)

But there are other ways of skinning that cat.  It would be nice to agree on one way, though, to avoid more config.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 00:30:41 -0400

Paul,

>      detail and be bigger and/or more expensive to produce.

I would expect that if a device claims support for the draft we've
submitted, then it will always provide an "optimized" implementation
(whatever that means).  Likely, it will return a 200 with some fairly static
payload or another code that makes sense.

The "normal" reply would suggest the device does not support the draft,
right?  That's a case I'm not interested in what such a device would do.

I guess the question here is how we know whether an OPTIONS is for "ping" or
to query for OPTIONS.  What I suggested is that manufacturers would design
their boxes to support the draft -- and the draft tries to align with 3261.
There should be some address to which ping messages are directed, which my
preference would be the IP address of the device.  The reason for my
suggesting that is that, generally, one does not establish a session with
the IP address of an SBC :-)  That said, I can see where it might be useful
to have a [email-masked] type address for such things as IP phones or even
SBCs.  In any case, the "ping" address should be an address that the
manufacturer discloses and the peer entity should be configured to use.

>    that the recipient uses to distinguish which behavior to apply.

I'm not opposed to it, but it seems like overkill.  If one were to build an
SBC that expects to receive an OPTIONS "ping" at "sip:[email-masked]" and
the feature tag (or whatever) for "ping" is not there, do you really think
the box would behave differently?

>    appropriately depending on which behavior it wants.

If we feel that some kind of tag is necessary to identify a request as a
"ping", I would certainly not want it to vary by implementation.  However,
I'm not yet convinced we even need such a feature tag, as I think the
Request URI would suffice.

Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Apr 2010 23:55:40 -0500

> manufacturer discloses and the peer entity should be configured to  

In my experience, everybody uses IP addresses for almost everything.  
It's a mistake to assume DNS in a real-world deployment outside of the  
occasional user-configured proxy.

So if we don't want any of the behavior of OPTIONS why not just do a  
coaxial STUN request on the SIP port, as one would do for outbound?  
It's MUCH lighter weight and doesn't even need text parsing.

> the box would behave differently?

Yes. Because if it's got a reasonable SIP stack and I send it an  
OPTIONS request, I expect to see a legitimate OPTIONS response.

> Request URI would suffice.

The tag could be encoded in the R-URI, in the user-name, a parameter  
on the user-name, as a request-URI parameter, or as part of the target  
host name.

Or it could be a new header field inside the body of the request.  
That's got the best backward compatibility of any of the options  
discussed.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Apr 2010 23:59:45 -0500

On Apr 27, 2010, at 2:59 PM, Christer Holmberg wrote:

>> IIUC, you are saying that any specific options-ping behavior should  
>> be the result of *configuration* of the UAC and UAS. And then can I  
>> infer that recognition that in incoming OPIONS is a ping would be
>> based on source address and/or use of a "special" address that is  
>> configured into the UAC rather than reserved.
>

But we always have to consider (and document) that which happens if  
they are not used as expected. What happens when you ping a non- 
adjacent node? What happens when the ping is contact-routed or loose- 
routed by an intermediate proxy? I'm not saying that we need to have a  
perfect solution, but at least we need to consider and document the  
likely failures and oddities.

For example, saying "The node being pinged MUST be an adjacent node"  
is insufficient. This is a "naked requirement" -- for it to be  
respected, we need to put clothes on it. Perhaps we could add   
"because if the node is not adjacent, then the following is likely...."

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 01:00:32 -0400

Hadriel,

> The rub with that is it doesn't remove the per-hop interop
> configuration that a draft such as this one is trying to remove/avoid.
> I'm not saying that makes the draft useless, because at least it would
> avoid the response-code configuration portion - but just wondering why
> we can't avoid the intended target issue as well.

I assume you're referring to such things as performing a DNS query on a
name, discovering 4 IP addresses, and then needed to know how to address
them (if not by IP address).  In that case, yes, I can see why a defined
username or some type of "ping" tag might be necessary.

A question: why not just use the IP address and port as the "ping" address?
I'm sure there may be a few good reasons, but that seems like a logical
destination (and is the reason I proposed it in the draft).
 
> BTW, defining the syntax for the intent of the request can be done
> multiple ways, and I was only suggesting that agreeing on a specific
> user name would be one way.  (it's always seemed to me to be a hack
> that requests intended for a Proxy to process as a logical UA are not
> addressed to a specific logical UA/resource, but instead just inferred
> by the Proxy as being for it)
> 
> But there are other ways of skinning that cat.  It would be nice to
> agree on one way, though, to avoid more config.

Agree.  This is not a complex problem, so I'd like to just agree on
something and go forward.  Where's that coin?  Or do I need to roll a die?
What options do we want to consider?

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Apr 2010 09:55:09 +0200

Hi, 

>>>> be between two devices that have some kind of established 
>>>> relationship and the "ping" address should be known only locally.
>>>
>But we always have to consider (and document) that which 
>happens if they are not used as expected. What happens when 
>you ping a non- adjacent node? What happens when the ping is 
>contact-routed or loose- routed by an intermediate proxy? I'm 
>not saying that we need to have a perfect solution, but at 
>least we need to consider and document the likely failures 
>and oddities.
> 

True.

But, you could say that the Max-Forwards value MUST be 1.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Apr 2010 10:25:05 +0200

Hi, 

>>I guess the question here is how we know whether an OPTIONS is for 
>>"ping" or to query for OPTIONS.  What I suggested is that 
>>manufacturers would design their boxes to support the draft 
>>-- and the 
>>draft tries to align with 3261.
>>There should be some address to which ping messages are directed, 
>>which my preference would be the IP address of the device.  
>>The reason for my suggesting that is that, generally, one does not establish a 
>>session with the IP address of an SBC :-)  That said, I can see where 
>>it might be useful to have a [email-masked] type address for such 
>>things as IP phones or even SBCs.  In any case, the "ping" address 
>>should be an address that the manufacturer discloses and the peer 
>>entity should be configured to use.
> 
>It's a mistake to assume DNS in a real-world deployment 
>outside of the occasional user-configured proxy.
> 
>So if we don't want any of the behavior of OPTIONS why not 
>just do a coaxial STUN request on the SIP port, as one would 
>do for outbound?  

The keep-draft uses STUN. However, when you send something in-dialog, or in-registration, you have the possibility to negotiate the usage.

However, if you send something "stand alone", you don't know whether the receiver supports something. Of course, you could send ONE OPTIONS, and see from the response whether the receiver supports stun, eg using the mechanism in the keep-draft.

If you start sending STUN messages, and the receiver does not support it, it could treat the messages as crap, and in the worse case even put you on some black list :)

Regards,

Christer

> > If we feel that some kind of tag is necessary to identify a 
> request as 
> > a
> The tag could be encoded in the R-URI, in the user-name, a 
> parameter on the user-name, as a request-URI parameter, or as 
> part of the target host name.
> 
> That's got the best backward compatibility of any of the 
> options discussed.
> 
> --
> dean
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Apr 2010 10:26:44 -0400

> payload or another code that makes sense.

I can think of cases where that wouldn't be the case.
Certainly the other OPTIONS discussion is suggesting returning *more* 
information about capabilities of the addressed resource. And that might 
be expected in a box that should also be involved in pinging.

For instance a "registrar/home-proxy" box serving atlanta.com might be 
expected to respond to OPTIONS for sip:alice@atlanta with specifics 
about alice - possibly a 3xx with the registered contacts.

OTOH a neighboring "load balancer" proxy might want to be pinging that 
box, and desiring a quick response with no "capabilities".

Of course in this case the distinction could be made by the address of 
the request. But still there are two behaviors, distinguished by 
something in the request.

> right?  That's a case I'm not interested in what such a device would do.

This goes to the other discussion we  have been having about Require - 
the distinction about "supporting" a feature and "using" the feature. 
Just because the box "supports" this ping doesn't mean it should use it 
all the time.

> to query for OPTIONS. 

Yup.

> What I suggested is that manufacturers would design

Discussed above.

> There should be some address to which ping messages are directed,

So you *are* suggesting that ping behavior be selected based on the form 
of the address in the OPTIONS request.

> which my
> the IP address of an SBC :-) 

There are multiple "features" of that approach that might be the actual 
determiner of the behavior:

- there is no user part to the uri
- the domain part of the URI is an ip address rather than an FQDN
- both of the above

Trouble is: there is plenty of usage where that's a bad choice.
Its my understanding that there are quite a few "phone" type devices 
that use IP address without a user part as a contact address, and so 
receive real requests directly at such an address. An OPTIONS request to 
their registered Contact would eventually arrive to them with just the 
ip address in the R-URI, yet the expectation is that the request is not 
a ping. And at the same time, a proxy upstream from that device might 
indeed want to ping it.

> That said, I can see where it might be useful

IMO the reason we have standards is to avoid having to configure such 
things. If its worth standardizing the behavior then its worth 
standardizing how its invoked.

> I'm not opposed to it, but it seems like overkill. 

As I note above, I consider a particular address form (such as 
ip-address-only R-URI, or "ping" as the user part of the R-URI) as an 
example of a feature that might be used to select the behavior.

I think there are several alternatives:

1) OPTIONS has only one behavior.

1a) A UAC may use OPTIONS as a ping, ignoring information
     in the response that is irrelevant to it.

1b) There is a new method, different from OPTIONS
     for the ping functionality.

2) OPTIONS has two different standardized behaviors: normal & ping.

2a) A given box always implements one or the other of
     those behaviors, in all cases.

2b) A given box may implement them both. The selection
     of which behavior to use for a specific request
     is determined by some feature of the request.
     (the source address, the R-URI, a special header, ...)
     Precisely what feature causes this is unstandardized.
     The sender who cares about which behavior it gets
     must "know" how to construct the request to get
     that behavior.

2c) A given box may implement them both. The selection
     of which behavior to use for a specific request
     is standardized. (Exactly what that is is TBD.

Based on what you have said, I think you are advocating 2b.
My preference would be for 1a or 1b. I could live with 2c.
I find 2a and 2b unacceptable for reasons previously stated.

Note that 1a and 1b can be used together: a UAC that wants to ping first 
tries sending the special PING request. If that is rejected, it falls 
back to using a "normal" OPTIONS as an alternative.

	Thanks,
	Paul

> If one were to build an

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 19:55:41 -0400

Dean,

> In my experience, everybody uses IP addresses for almost everything.

I can see where this might be an issue for sending "ping" messages to
phones.

> occasional user-configured proxy.

DNS is just one way of obtaining an address.  One is not precluded from
getting the address in any way whatsoever.
 
> It's MUCH lighter weight and doesn't even need text parsing.

The purpose for a SIP OPTIONS ping is to get a response from the SIP
process, not another process on the box.  Following your argument, an ICMP
packet is even lighter :-)
 
> > SBC that expects to receive an OPTIONS "ping" at
> "sip:[email-masked]
> > " and

Yeah, ok.  Agreed.
 
> That's got the best backward compatibility of any of the options

Personally, I'd prefer to make this as simple and unobtrusive as possible.
What is the preference?  We've got too many options here.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Apr 2010 19:58:28 -0400

> Sent: Wednesday, April 28, 2010 12:31 AM
> To: 'Paul Kyzivat'
> 

Right, but when I design my box to handle it, I need to know the OPTIONS request I receive from your box expects your draft's specific semantics.  Because I still need to support my legacy OPTIONS request handling code, including for OPTIONS which were just routed through your box to me and thus are not expecting the same draft's semantics.

> the IP address of an SBC :-)  

I beg to differ - for every SBC vendor I've seen, you do establish a session (or target an OPTIONS request) to the SBC.  I'm sure there are some SBC vendors gear I haven't seen, which may act as some inline bump-in-the-wire ALG-thingy, but that's not the model "generally".  

> manufacturer discloses and the peer entity should be configured to use.

I'm getting confused - are you thinking the IP Address of the OPTIONS' request-URI would be a *different* IP Address from the one other SIP requests are sent to??  I didn't grok that from the draft at all, and it would make things very complicated.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Apr 2010 19:17:13 -0500

> packet is even lighter :-)

Right, but the coaxial-STUN is at least driven from the same port- 
listener-dispatcher as the SIP process. Remember, we're running both  
protocols on the same port, so the packets go to the same listener.  
One can envision a multithreaded model with the SIP thread has crashed  
but the listener and STUN responders linger on, but I system a more  
total faliure is likely to be the norm.

> What is the preference?  We've got too many options here.

I think the simplest thing is a new header field, coupled with an  
option-tag that could be used to indicate or require support for the  
header field. Yes, it is standards-track work, but it's not "hard"  
standards track; we know how to do these things reasonably well by  
now. An AD could bless it through the individual track using a 1 month  
IETF LC.

So for example, a new header field "Options-mode" with a value of  
"ping" means "If you support this extension, do not proxy this  
request, just send an immediate 200 OK response  and do not bother  
populating the Supported header field of the 200 OK response."  
Somebody who didn't recognize the header field would just send a  
conventional 200 OK response.

And perhaps an option tag of "optionsmodeping". That way we can add  
further options-modes, and option tags for them in the future as (and  
if) needed.

You could basically cut-and-paste the answer-mode draft and be done  
writing in an hour.

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 20:47:08 -0400

Hadriel,

> > to have a [email-masked] type address for such things as IP phones
> or
> > even
> I'm getting confused - are you thinking the IP Address of the OPTIONS'
> request-URI would be a *different* IP Address from the one other SIP
> requests are sent to??  I didn't grok that from the draft at all, and
> it would make things very complicated.

No, I certainly didn't mean to suggest there would a different IP address.

What I am referring to is the Request URI.  Previously, I was suggesting
that the request URI would be addressed to the IP address if it's a ping,
but would be addressed to a user if it wasn't.  But, you and Dean have
convinced me that that's not always a good way to differentiate an OPTIONS
"ping" from one that's an actual OPTIONS request.

So, I removed the restriction from my local draft that specified what the
Request URI looks like.  What we need to decide is exactly what we want to
have as a differentiator?  A specific request URI, a tag, a header, etc.

Having said that, I'm still favorable to sending an OPTIONS "ping" addressed
to the IP address of the device (e.g., sip:192.168.1.10).  Whether that
contains a "ping" header or tag or other is likely not going to make much
difference to an SBC that does not receive other requests addressed to that
address.  

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 21:22:41 -0400

Dean,

> conventional 200 OK response.

Not objecting to the header, but I think we would have failed in our effort
if the message might possibly be proxied.  The intent was for this to be
peer-to-peer.
 
> further options-modes, and option tags for them in the future as (and

So, you want a head like this:

  Options-Mode: ping

Or this:

  Require: optionsmodeping

> You could basically cut-and-paste the answer-mode draft and be done

Oh, I'll be happy to plagiarize your work ... but not sure exactly what you
want me to copy :-)

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Apr 2010 22:37:27 -0400

Now that we have established the goal is devising some options/headers 
to entirely change the behavior of OPTIONS, I would rather see a new 
method: PING. Given the assumptions being made I can see few if any 
downsides to this, and definite upsides.

IMO the value of using OPTIONS for ping is in those cases where the 
device being pinged doesn't know that it is being pinged.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 22:54:40 -0400

Paul,

I don't see it quite the same way.  I don't want to entirely change OPTIONS,
but I do want to define procedures that devices should follow if they
implement an OPTIONS "ping" procedure.  This is achieved with a new header
or targeting a specific address.  It also means that devices that do not
implement the resulting RFC will still function as they do today.

If we go the route of introducing a whole new method, it would be years
before it gets introduced into the market.  We still need to keep the
OPTIONS "ping" around, because that's what virtually everybody is doing.

The only thing we proposed in the initial draft was some consistency with
respect to the way responses were given, etc.  We're not calling for drastic
changes in the behavior of OPTIONS.  In fact, if a device wanted to return a
complete response with all of the features it supports, that'd be fine with
me.  When used as a "ping", it's primarily the response code the peer is
looking for.  The only negative side effect is a bit more bandwidth on the
wire, which is likely inconsequential as compared to everything else.

Paul

> Sent: Wednesday, April 28, 2010 10:37 PM
> To: Paul E. Jones
> Cc: 'Dean Willis'; 'Michael Miller'; [email-masked]; 'Hadriel Kaplan'

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Apr 2010 23:50:50 -0400

The problem is OPTIONS really is meant for getting capabilities, and although it may also be used as a ping (and often is), to use one for *only* a ping and not return capabilities is likely to cause a bunch of folks here to say "then it's not an OPTIONS".  So I think that has to be kept in to keep this method name and get anywhere.

If we did identify the target of the OPTIONS as a specific resource, like "ping@ip/host", then I would have argued we could specify that it does return capabilities but that this "ping" logical UA/resource simply has no capabilities beyond supporting the OPTIONS request.

But really if it's proxies you're talking about they generally can represent their capabilities with fairly hard-coded static strings, afaict, and obviously the system receiving the response can just ignore the capabilities returned if it doesn't care.  So I'm not sure it makes much difference, does it?

-hadriel

> Sent: Wednesday, April 28, 2010 10:55 PM
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Apr 2010 23:58:30 -0400

Hadriel,

> The problem is OPTIONS really is meant for getting capabilities, and
> although it may also be used as a ping (and often is), to use one for
> *only* a ping and not return capabilities is likely to cause a bunch of
> folks here to say "then it's not an OPTIONS".  So I think that has to
> be kept in to keep this method name and get anywhere.

We never proposed a use where capabilities are not returned.  If folks
wanted to do that, they could, but we're not prescribing different behavior
w.r.t. OPTIONS payload content.  Personally, I would reply with the same
payload, "ping" or not.
 
> If we did identify the target of the OPTIONS as a specific resource,
> like "ping@ip/host", then I would have argued we could specify that it
> does return capabilities but that this "ping" logical UA/resource
> simply has no capabilities beyond supporting the OPTIONS request.

What I really, really wanted to encourage is sending an OPTIONS message to
the IP address of the device you wish you ping and with a SIP URI of
"sip:hostport".  This does not address a "user" and therefore makes it a
little clearer that it's a device-level request.

In any case, I would still return the same payload, just because I'd likely
have it statically composed in memory and it would be trivial to return.
 
> But really if it's proxies you're talking about they generally can
> represent their capabilities with fairly hard-coded static strings,
> afaict, and obviously the system receiving the response can just ignore
> the capabilities returned if it doesn't care.  So I'm not sure it makes
> much difference, does it?

I think that's true of most devices: they can be fairly static responses.

What we were trying to do with this draft was not be disruptive to the
existing SIP spec, but to try to get OPTIONS handled in a consistent manner
when used as a "ping" mechanism.  We didn't want to call for a whole
different mode of operations, per se.

Paul
 
> > changes in the behavior of OPTIONS.  In fact, if a device wanted to
> return
> > a
> > complete response with all of the features it supports, that'd be
> fine
> > with

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Apr 2010 07:19:34 +0200

Hi,

>>The problem is OPTIONS really is meant for getting 
>>capabilities, and although it may also be used as a ping (and often is), to 
>>use one for *only* a ping and not return capabilities is likely to 
>>cause a bunch of folks here to say "then it's not an OPTIONS".  So I 
>>think that has to be kept in to keep this method name and get anywhere.
> 
>We never proposed a use where capabilities are not returned.  
>If folks wanted to do that, they could, but we're not 
>prescribing different behavior w.r.t. OPTIONS payload 
>content.  Personally, I would reply with the same payload, 
>"ping" or not.
>
>What I really, really wanted to encourage is sending an 
>OPTIONS message to the IP address of the device you wish you 
>ping and with a SIP URI of "sip:hostport".  This does not 
>address a "user" and therefore makes it a little clearer that 
>it's a device-level request.
> 
>In any case, I would still return the same payload, just 
>because I'd likely have it statically composed in memory and 
>it would be trivial to return.

The message body payload part is easy to get rid of - you just include an empty Accept header field in the OPTIONS request.

>>afaict, and obviously the system receiving the response can just 
>>ignore the capabilities returned if it doesn't care.  So 
>>I'm not sure it makes much difference, does it?
> 

I think one issue is how often you think these OPTIONS requests need to be sent. If they are not sent that often, it's probably not a problem to return what you would return in normal cases.

Regards,

Christer

> 
> What we were trying to do with this draft was not be 
> disruptive to the existing SIP spec, but to try to get 
> OPTIONS handled in a consistent manner when used as a "ping" 
> mechanism.  We didn't want to call for a whole different mode 
> of operations, per se.
> 
> Paul
>  
> > -hadriel
> > 
> > > I don't see it quite the same way.  I don't want to 
> entirely change 
> > > OPTIONS, but I do want to define procedures that devices should 
> > > follow if they implement an OPTIONS "ping" procedure.  This is 
> > > achieved with a new
> > header
> > > or targeting a specific address.  It also means that 
> devices that do
> > not
> > > before it gets introduced into the market.  We still need to keep 
> > > the OPTIONS "ping" around, because that's what virtually 
> everybody 
> > > is
> > doing.
> > >
> > > The only thing we proposed in the initial draft was some 
> consistency
> > with
> > > respect to the way responses were given, etc.  We're not 
> calling for 
> > > drastic changes in the behavior of OPTIONS.  In fact, if a device 
> > > wanted to
> > return
> > > a
> > > me.  When used as a "ping", it's primarily the response code the 
> > > peer
> > is
> > > looking for.  The only negative side effect is a bit more 
> bandwidth
> > on the

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Apr 2010 01:36:13 -0400

> Sent: Wednesday, April 28, 2010 11:59 PM
> 

Oh.  Well someone did. :)

Good, so we can move onto flipping coins to decide what syntax to use to make it clear the OPTIONS is using/expecting this draft's rules. :)

-hadriel

---

From: "Milinski, Alexander (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 29 Apr 2010 09:33:30 +0200

One moment please, before you start throwing the dice ...

Having followed the debate and looked at the draft, it still isn't clear
to me:
What is broken today that the draft indends to fix?
What are the underlying requirements for the solution?

Alex

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Hadriel Kaplan
> Sent: Thursday, April 29, 2010 7:36 AM
> To: Paul E. Jones; 'Paul Kyzivat'
> Cc: 'Michael Miller'; [email-masked]
> Subject: Re: [sipcore] FW: I-D 
> Action:draft-jones-sip-options-ping-00.txt
> 
> 
> 
> Good, so we can move onto flipping coins to decide what 
> syntax to use to make it clear the OPTIONS is using/expecting 
> this draft's rules. :)
> 
> -hadriel 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2010 10:00:19 -0400

Paul J,

I see two alternatives here, but you seem to be straddling them.

1) you can leave the behavior of OPTIONS alone.
    Document a set of practices for how a UAC can use
    OPTIONS to accomplish a ping. In this case, the
    UAS never knows whether an OPTIONS it receives
    is intended as a capability query or a ping.

    + this is relatively quick to accomplish because
      it doesn't require standards action

    + this is relatively quick to deploy, because
      only the UACs that want to ping need be updated.

    - the benefit is limited because you are stuck
      with the way OPTIONS currently works, and with
      the variations in behavior that it allows.

    - pinging this way may be more costly than
      necessary because of the extra work of applying
      policy, including capabilities, and the extra
      size of the message to carry the capabilities

2) define new standardized behavior for pinging,
    with roles for both the UAC and UAS, that is
    different from what OPTIONS does today.

    + the behavior is not constrained by the existing
      definition of OPTIONS. It can be defined
      precisely for the purpose.

    + the implementation can be optimized.
      the server can "fast path" it, and policy
      application can be simplified because little
      is disclosed.

    - it will take longer to get specified because it
      must be standards track. (Note that this will be
      pretty much the same regardless of whether it is
      defined as new optional behavior of OPTIONS, or
      as a new method.)

    - it will take longer to deploy because both
      UAC and UAS must support it.

I guess there is a possible variant on (1):
also do a *clarification* of OPTIONS behavior in cases where there is 
some ambiguity about what response code should be returned in particular 
circumstances. I would be ok with that *if* the clarification applied to 
all uses of OPTIONS. But once you start to do that you start to pick up 
the negatives of (2).

It would also be possible to do a combination of (1) and (2), where (2) 
is preferred if both UAS supports it, with fallback to (1) for those 
that don't.

What I don't see is a way to avoid standards action and yet define 
special optional behavior by the UAS that the UAC can request and know 
was provided. This seems to be what you are seeking.

	Thanks,
	Paul K

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2010 10:12:11 -0400

> The message body payload part is easy to get rid of - you just include an empty Accept header field in the OPTIONS request.

That *could* work, if the UAS understands and does it right.

I'll venture to guess that most existing implementations would either:
a) return the SDP anyway (assuming there were prepared to return it.)
b) barf and return some error code, hopefully 406

If (a) happened, you could file a complaint against the vendor of the 
UAS. But I think you could make a good case that (b) is appropriate in 
this case, as it would if you put an empty Accept in an INVITE.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Apr 2010 10:51:59 -0400

> Sent: Thursday, April 29, 2010 10:12 AM
> 
> Christer Holmberg wrote:
> 
> > The message body payload part is easy to get rid of - you just include
> an empty Accept header field in the OPTIONS request.
> 

Unfortunately I think 3261 is ambiguous for that:
   A message body MAY be sent, the type of which is determined by the
   Accept header field in the OPTIONS request (application/sdp is the
   default if the Accept header field is not present).

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 11:01:20 -0400

Christer,

> I think one issue is how often you think these OPTIONS requests need to
> be sent. If they are not sent that often, it's probably not a problem
> to return what you would return in normal cases.

I expect that to vary for a number of reasons, but I would suspect that the
more frequent they are sent, the less important the bandwidth would be.
There's no requirement to even look at the SDP, and I doubt a device sending
a "ping" packet would.

In any case, as you suggest we could get rid of it if it was important via
the Accept header.  But, that actually would mean more processing.  It's
either CPU or bandwidth :-)

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 11:11:05 -0400

Alex,

There are two objectives:
1) Legitimize the use of OPTIONS as a "ping" mechanism, since virtually
every product I've seen does that, but it's not described in any RFC
2) Try to converge on behavior that is in line with what RFC 3261 says, but
narrow the recommended response codes.  When a device cannot accept to
requests, I've seen the following response codes returned: 408, 480, 503,
505, and 600. The only thing place where I've seen implementation agreement
is returning a 200 when things are OK.

In meeting these objectives, we really, really wanted to not make any
changes to the core spec, but I have no objection to introducing a new
header, for example, to hint as to the purpose of the OPTIONS: I just don't
personally think it's that important, but others apparently do.

Paul

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Milinski, Alexander (NSN - DE/Munich)
> Sent: Thursday, April 29, 2010 3:34 AM
> To: ext Hadriel Kaplan; Paul E. Jones; Paul Kyzivat
> Cc: Michael Miller; [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Thu, 29 Apr 2010 10:11:59 -0500

[as a participant]

On 4/29/10 10:01 AM, Paul E. Jones wrote:
> There's no requirement to even look at the SDP, and I doubt a device 
> sending a "ping" packet would.

If you're trying to accomplish something orthogonal to OPTIONS (i.e, 
liveness tests), and planning to ignore the capabilities indicated by 
the responding entity, why do you want to use OPTIONS?

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Apr 2010 11:42:49 -0400

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, April 29, 2010 11:12 AM
> To: Paul E. Jones
> 

But it's _not_ really orthogonal to OPTIONS.  We're using the term "ping" here, but that's a bit misleading - the request is really being used to determine the *state* of the next-hop.  Classic "ping" is just "are you there?" - like ICMP, or a STUN or CRLF keepalive.  But this draft is also clarifying what to respond with for actual SIP processing state - admin up/down, overloaded, etc.

One could argue that the returned state is in fact a returned "capability" - the capability of the responder to handle other requests.

And 3261 pretty clearly not only allows OPTIONS to do that, but describes how it is done.  Section 11.2:
   The response to an OPTIONS is constructed using the standard rules
   for a SIP response as discussed in Section 8.2.6.  The response code
   chosen MUST be the same that would have been chosen had the request
   been an INVITE.  That is, a 200 (OK) would be returned if the UAS is
   ready to accept a call, a 486 (Busy Here) would be returned if the
   UAS is busy, etc.  This allows an OPTIONS request to be used to
   determine the basic state of a UAS, which can be an indication of
   whether the UAS will accept an INVITE request.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 13:01:25 -0400

Paul,

> I see two alternatives here, but you seem to be straddling them.

I've been accused of that before :-)
 
>     is intended as a capability query or a ping.

Yes and no.  My thought was a device that receives an OPTIONS directed to
the device (i.e., Request URI is sip:hostport), then it could assume it's
likely a "ping".
 
>       it doesn't require standards action

It is true that there is minimal work, but what we need to do is legitimize
OPTIONS for use as a "ping" method and agree on response codes.
 
>       only the UACs that want to ping need be updated.

Definitely: this is definitely not something we're suggesting to send across
the Internet.  This is a peer-to-peer relationship.
 
>       the variations in behavior that it allows.

Understood, but what is the problem with that?  Apparently, many felt it
wasn't an issue since this is widely, inconsistently deployed
 
>       size of the message to carry the capabilities

Yeah, but our intent was that this would be done over a local link and
probably only when the device is otherwise not generating traffic.  Perhaps
the thing I believe is a non-issue is the composition and processing of
those messages.  Surely folks are not going to construct that response based
on querying a bunch of configuration information upon every request.  I'd
assume the information is readily in hand and perhaps even sitting in a
buffer read to be copied as-is.
 
>     different from what OPTIONS does today.

We're not looking for something that is different, per se, but just to agree
on behavior.  This behavior is in line with what 3261 says, but let's not do
things that are all over the place.

>       precisely for the purpose.

We definitely want to constrain behavior: that's a major reason preparing
the draft.
 
>       application can be simplified because little

It could be, but what I'm having trouble with is what I would do differently
if it was a "ping" or not.  For example, if I build a GW and I received an
OPTIONS addressed to sip:192.168.1.10, I would reply the same way every
time: I'd assume it's likely a "ping".  And, that response should be a valid
OPTIONS reply regardless of whether it's a "ping" or not.  That is, no
different code path followed.  I would do the same thing if I were building
an SBC: I'd assume the message is a "ping" and comply with this spec: a
subset of what RFC 3261 describes.

If the "ping" was directed to "sip:[email-masked]", I might
return something different, since there may be capabilities associated with
a given port that is different than the GW as a whole.

>       defined as new optional behavior of OPTIONS, or

Understood, which is why I didn't really want to introduce new
functionality.  I do not object to introducing a header, for example: that
seems like a minimal and perhaps useful addition.
 
>       UAC and UAS must support it.

Exactly, which is why I think defining a whole new method like PING is out
of the question.  SIP is too old at this point to introduce such new
methods, in my opinion.  It would take years to approve and we'd have to
live with both OPTIONS and PING for 20 years.
 
> all uses of OPTIONS. But once you start to do that you start to pick up

I can't fix every problem with OPTIONS and I don't see a reason to expand
this draft beyond that.  If we were introducing new functionality, I'd
agree... but I'd prefer we didn't introduce new functionality.

> is preferred if both UAS supports it, with fallback to (1) for those

What I think we should do is more along the lines of (1), with possible
consideration of introducing a header or tag to serve as a hint as to the
purpose of the OPTIONS message.  (I know that compels you to suggest that I
might be bipolar, but I'm only trying recognize the fact that some find this
useful.  Still, I'd expect the same processing on the box.)
 
> was provided. This seems to be what you are seeking.

So, what's special?  We're constraining behavior, not expanding it.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 13:03:35 -0400

Paul,

> > The message body payload part is easy to get rid of - you just
> include an empty Accept header field in the OPTIONS request.
> 

If it didn't, wouldn't it be non-compliant with 3261?
 
> this case, as it would if you put an empty Accept in an INVITE.

Why would you argue that a device should do (b)?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 13:12:01 -0400

Adam,

> the responding entity, why do you want to use OPTIONS?

Because that's what lots of vendors have elected to do.  We submitted this
document as a reaction to the fact that it's widely, but inconsistently
implemented.  We didn't submit the document because we wanted to define a
new behavior and encourage people to adopt it.

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Apr 2010 19:43:42 +0200

Hi,

You DO insert Accept, but with no values. AFAIK, that will override any default values. 

Regards,

Christer

________________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Thursday, April 29, 2010 5:51 PM
To: Paul Kyzivat; Christer Holmberg
Cc: Paul E. Jones; 'Michael Miller'; [email-masked]
Subject: RE: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Apr 2010 21:23:16 +0200

Hi,

>personally think it's that important, but others apparently do.

In order for me to form an opinion on that, I would need to know how frequent the "pings" are expected to be sent.

OPTIONS is not the only method that is too "heavy" if sent too often. People have been using frequent re-registrations in order to do NAT keep-alives, and that's also bad. That is one reason we have defined the usage of STUN for keep-alives, because it's much more "lightweight".

So, I think it would be useful to know how often (the minimum value) these pings are expected to be sent. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2010 15:56:31 -0400

> I've been accused of that before :-)

And you're still at it here.

> the device (i.e., Request URI is sip:hostport), then it could assume it's

Note: I presented these as alternatives, but you are trying to subsume 
some of the features of (2) into (1) without also accepting the 
consequences.

Your statement here is saying that the recipient can discern a 
distinction between OPTIONS that mean ping from those that don't, based 
on the form of the R-URI.

That of course presumes that the recipient agrees that there is such a 
distinction. Since the existing definition of OPTIONS has no such 
distinction, this is an *extension* to OPTIONS, and hence achieving it 
would require standards action.

> OPTIONS for use as a "ping" method and agree on response codes.

As soon as you say that, you have said you don't want option (1). What 
you are asking for is option (2). Or *maybe* you are talking about is 
what I describe below as: "variant on (1): also do a *clarification* of 
OPTIONS behavior in cases where there is some ambiguity about what 
response code...". If that is the case, then lets discuss that one in 
all its gory details and implications.

> the Internet.  This is a peer-to-peer relationship.

I don't get your point. It has no relation to the bullet above it is 
responding to. In any case, you won't get any traction here for a 
proposal that requires matching configuration of the two "peers" in this 
ping relationship. That's entirely contrary to the point I was making - 
that the UAS need not be aware this is a ping, or event that there is 
such a thing as a ping. Rather, here "ping" is a usage of OPTIONS whose 
significance is only known to the UAC.

> wasn't an issue since this is widely, inconsistently deployed

You are also stuck with the ambiguity in what response is returned in 
various situations, as well as the possibility that undesired 
capabilities might be returned, or the the device might decide to 
forward the request. Those are all part of accepting OPTIONS for what it 
currently is.

> buffer read to be copied as-is.

If the thing you are pinging is a white box to you, then maybe you know 
all that. But in any sort of multi-vendor situation that is likely not 
to be the case.

For instance, if you send OPTIONS to a gateway, it *might* decide it 
should investigate its current resources before responding with its 
capabilities.

The boxes you are familiar may not work that way. But don't make that 
assumption about all boxes.

> things that are all over the place.

As best I can tell, you still want some options to be treated as ping, 
while allowing others to be treated as capability query and handled 
differently. That is *new standardized behavior* in my book.

Alternately, maybe you are asking for OPTIONS, on all devices in all 
circumstances, to be more deterministic than it currently is, so that it 
is more suitable for ping usage while still being simultaneously 
suitable as a capability query. This is *still* a normative change, 
though a smaller one than the other.

PLEASE clarify which of these you want.

> We definitely want to constrain behavior: that's a major reason preparing

You misunderstand me. Of course the behavior is constrained. Its just 
that there are two different behaviors:
- capability query behavior
- ping behavior

But these could be specified independently, so that a ping can have a 
more circumscribed behavior than the capability query behavior has.

> a given port that is different than the GW as a whole.

Then you are asking that the OPTIONS sent to sip:192.168.1.10 might 
produce a different result than OPTIONS sent to 
sip:[email-masked].

That is of course *permitted* under the current definition of OPTIONS. 
But it isn't *required*.

And you want there to be specific semantics to the sip:192.168.1.10 
form. In the context of your GW example that makes a certain amount of 
sense. When the target is some other sort of device, say a phone, that 
may not make much sense.

My point is that if you want to ascribe specific semantics to options 
when the host is an ip address and the user part is missing, then that 
will be a standards action to accomplish, and then you will have to wait 
while it is implemented. And, I think you may have difficulty getting 
everyone to agree.

> functionality. 

But you *do* want to introduce new functionality:

You want to specify that all those implementations that do it a way 
different than what you propose should change to do it this way. That is 
new.

> I do not object to introducing a header, for example: that

It will take no longer to introduce a PING method, and no more effort to 
implement, than to introduce a new header or a new option tag, or simply 
to document new behavior and get it approved as a *standard* and then 
get it widely implemented.

> So, what's special?  We're constraining behavior, not expanding it.

Its *harder* to get a change deployed that constrains behavior than it 
is to deploy one that expands behavior!

Constraining behavior presents backward compatibility issues to 
everybody that was doing something that used to be valid and no longer 
is. Expanding behavior presents no backward compatibility issues.

	Thanks,
	Paul K

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Apr 2010 21:54:15 +0200

Hi,

>>>That said, I can see where it might be useful to have a [email-masked] type address for such things as IP phones or
>>>even SBCs.  In any case, the "ping" address should be an address that the manufacturer discloses and the peer entity should be configured to
>>>use.
>>>

If the receiver is a proxy I don't think the IP address would work as a differentiator, because according to RFC 3261 OPTIONS requests
sent to proxies are addressed by only using the host part. So, you would use sip:192.168.1.10 also for a "normal" OPTIONS request.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2010 16:01:30 -0400

I'll be happy to be shown to be unduly pessimistic.
I agree that the empty accept ought to result in a response without a 
body. I just expect that isn't what will happen in practice.
Certainly implementations can then be called out for violation.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Apr 2010 22:13:00 +0200

Hi,

>body. I just expect that isn't what will happen in practice.

That may be true, but I don't think it should be a reason for not specifying a solution. After all, the protocol doesn't break even if the response does contain a body.

But, so far we have been mostly talking about the content of the response. However, I think the content of the request is also important.

Assume I send an OPTIONS "ping" request, and don't include any capabilities etc. Assuming there is no "ping" identifier, the receiver may actually think that I don't support any capabilities, and may use that information e.g. when making routing/forking decissions about requests.

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 19:12:16 -0400

Christer,

> OPTIONS is not the only method that is too "heavy" if sent too often.
> People have been using frequent re-registrations in order to do NAT
> keep-alives, and that's also bad. That is one reason we have defined
> the usage of STUN for keep-alives, because it's much more
> "lightweight".
> 

Since this was intended for use between two devices that have some kind of
relationship, not merely transmitted anywhere on the Internet, we
recommended that the interval be left to the administrator.

If I were implementing it, I would not even send a ping if I knew there was
activity (i.e., I would only send one when I had not seen any other SIP
message for some specified period of time .. again, configurable).

Paul