Subject: Re: [dispatch] SIP OPTIONS "ping"

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 27 Sep 2010 10:22:30 -0400

Folks,

I just wanted to bring this draft to everyone's attention again.  What
should we do with it?  Should we modify this to be informational or pursue a
standards track draft?  Several have expressed an interest in seeing this go
forward in some form to help ensure better interoperability, but the list
has been fairly silent.

Here's the draft:
http://tools.ietf.org/html/draft-jones-sip-options-ping

Thanks,
Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul E. Jones
> Sent: Friday, August 13, 2010 12:37 AM
> To: 'Cullen Jennings'; [email-masked]
> Cc: [email-masked]; 'Hadriel Kaplan'
> Subject: Re: [sip-ops] SIP OPTIONS "ping"
> 
> Cullen,
> 
> Thanks for the suggestion.
> 
> All,
> 
> Please see the note below.  We're seeking advice on how to proceed with
> the subject draft.
> 
> Paul
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:[email-masked]]
> > Sent: Thursday, August 12, 2010 11:44 PM
> > To: Paul E. Jones
> > Cc: [email-masked]; Hadriel Kaplan
> > Subject: Re: [sip-ops] SIP OPTIONS "ping"
> >
> >
> > I think you discuss how to move forward with this draft on dispatch
> > mailing list given that's the point of that list is help with problems
> > like this.
> >
> > On Aug 11, 2010, at 22:14 , Paul E. Jones wrote:
> >
> > > Folks,
> > >
> > > Gonzalo and I produced an Internet Draft aiming at trying to bring
> > > some
> > consistency to the way in which SIP user agents implement an OPTIONS
> > "ping" procedure.  It seems that a very large number of vendors do
> > this, but unfortunately, there seems to be little consistency.
> > >
> > > Initially, we positioned the document as a standards track RFC,
> > > since
> > this essentially builds on RFC 3261.  However, there was some pushback
> > from folks in the IETF for a variety of reasons, not the least of
> > which is the fact that there is no working group chartered to do the
> > work.  We don't feel this one draft warrants the creation of a working
> group.
> > >
> > > So, we've got three options we can consider:
> > > 1)      Forge ahead outside of a working group
> > > 2)      Change the status of the draft to Informational
> > > 3)      Forget about the draft and let every SIP device do it the way
> > they want, throwing hope of consistency out the window
> > >
> > > (Yeah, you can tell I prefer not to go for the third option.)
> > >
> > > In any case, I'd like to get feedback from the on the SIP operators
> > > and
> > SIP implementers lists.  Do you think it's worth trying to address
> > this issue?  If so, which option do you think we should pursue?
> > >
> > > Note that we're certainly open to feedback on the draft.  I'd prefer
> > > it
> > to have a few more "MUST" statements in the text, rather than "SHOULD".
> > But, we need to find that right balance:
> > > http://tools.ietf.org/html/draft-jones-sip-options-ping
> > >
> > > Paul
> > >
> > > _______________________________________________
> > > sip-ops mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/sip-ops
> >
> >
> > Cullen Jennings
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> >
> 
> 
> _______________________________________________
> sip-ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-ops

---

From: Marius Zbihlei <[email-masked]>
Date: Mon, 27 Sep 2010 17:23:50 +0200

Hello,

I have some observations:

1.What happens if the sender never receives a reply (locally generated 408) because the endpoint is down? Shouldn't this be treated as a 503?(I presume the OPTION is sent stateful )
2.As a minimum time interval in section 7, I recommend 32 seconds (or 64*T1) as to ensure a transaction times out before a retry.... 

Marius
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul E. Jones [[email-masked]]
Sent: Monday, September 27, 2010 4:22 PM
To: 'Cullen Jennings'; [email-masked]
Cc: [email-masked]; 'Hadriel Kaplan'
Subject: Re: [dispatch] SIP OPTIONS "ping"

Folks,

Here's the draft:

Thanks,
Paul

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 28 Sep 2010 22:31:22 -0400

Marius,

To answer your questions:

1) Yes, I believe that's a reasonable thing to do.  As for state, since this
is a simple next-hop message, why introduce state?
2) Retry times are tough to prescribe, since different networks have very
different requirements.  Some of the timers in SIP are out of this world,
really: a normal user would hang up the phone well before the time the
timers are expire.  The use of OPTIONS as prescribed in this document may
need to have faster response times than 32s.  Personally, I'd rather leave
this one open for the administrator to specify, but if the group would like
to nail down a recommended default, I can do that.

I'm collecting a number of comments on this draft, but what I really would
like to know right away is "what shall we do with it"?  Do we want to pursue
publishing this as an informational document or a standards track RFC?

Paul

> From: Marius Zbihlei [mailto:[email-masked]]
> Sent: Monday, September 27, 2010 11:24 AM
> To: Paul E. Jones; 'Cullen Jennings'; [email-masked]
> Subject: RE: [dispatch] SIP OPTIONS "ping"
> 
> Hello,
> 
> 1.What happens if the sender never receives a reply (locally generated
> 408) because the endpoint is down? Shouldn't this be treated as a 503?(I
> presume the OPTION is sent stateful ) 2.As a minimum time interval in
> section 7, I recommend 32 seconds (or 64*T1) as to ensure a transaction
> times out before a retry....
> 
> 
> Marius
> should we do with it?  Should we modify this to be informational or pursue
> a standards track draft?  Several have expressed an interest in seeing
> this go forward in some form to help ensure better interoperability, but
> the list has been fairly silent.
> 
> Here's the draft:
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Paul E. Jones
> > Please see the note below.  We're seeking advice on how to proceed
> > with the subject draft.
> >
> > Paul
> >
> > > mailing list given that's the point of that list is help with
> > > problems like this.
> > >
> > > this essentially builds on RFC 3261.  However, there was some
> > > pushback from folks in the IETF for a variety of reasons, not the
> > > least of which is the fact that there is no working group chartered
> > > to do the work.  We don't feel this one draft warrants the creation
> > > of a working
> > group.
> > > >
> > > > In any case, I'd like to get feedback from the on the SIP
> > > > operators and
> > > > Note that we're certainly open to feedback on the draft.  I'd
> > > > prefer it

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2010 08:29:04 -0400

> 1.What happens if the sender never receives a reply (locally generated 408) because the endpoint is down? Shouldn't this be treated as a 503?(I presume the OPTION is sent stateful )

I don't understand what you are asking.

If you send a request (any request, not just OPTIONS), and no reply is 
received, your stack is expected to give you an indication comparable to 
a 408 response. Are you asking what you should do if your stack doesn't 
do that?

And in any case, a 408 is a 408, not a 503. Timeouts can happen for many 
reasons unrelated to overload of the UAS.

	Thanks,
	Paul

---

From: Marius Zbihlei <[email-masked]>
Date: Wed, 29 Sep 2010 15:57:41 +0200

Hello,

To put it simply, what happens if the OPTION request is responded with a 408(generated locally)... In my opinion we should treat it as a 503, but I see that you think it should be treated differently.

Marius
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Wednesday, September 29, 2010 2:29 PM
To: [email-masked]
Subject: Re: [dispatch] SIP OPTIONS "ping"

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2010 11:50:48 -0400

> To put it simply, what happens if the OPTION request is responded with a 408(generated locally)... In my opinion we should treat it as a 503, but I see that you think it should be treated different…

I am not an expert on the sip protocol state machines, timers, etc.
For that you want Robert Sparks.

But I'm quite sure 3261 has different rules for handling 408 and 503, so 
saying "treat 408 like 503" raises a red flag to me. If you are talking 
about doing something differently for 408 than 3261 says, then you are 
proposing a real revision to 3261.

If you are talking about what tactics to use within the specs, that is 
fair game.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 18:06:56 +0200

Paul,

To answer your inital question, yes! We should pursue publishing this document, preferably as a standards track one. There are too many proprietary variants of this in the field today...

Bruno

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Paul E. Jones
> Envoyé : mercredi 29 septembre 2010 04:31
> À : 'Marius Zbihlei'; [email-masked]
> Cc : 'Hadriel Kaplan'
> Objet : Re: [dispatch] SIP OPTIONS "ping"
> 
> Marius,
> 
> 1) Yes, I believe that's a reasonable thing to do.  As for 
> state, since this is a simple next-hop message, why introduce state?
> 2) Retry times are tough to prescribe, since different 
> networks have very different requirements.  Some of the 
> timers in SIP are out of this world,
> really: a normal user would hang up the phone well before the 
> time the timers are expire.  The use of OPTIONS as prescribed 
> in this document may need to have faster response times than 
> 32s.  Personally, I'd rather leave this one open for the 
> administrator to specify, but if the group would like to nail 
> down a recommended default, I can do that.
> 
> I'm collecting a number of comments on this draft, but what I 
> really would like to know right away is "what shall we do 
> with it"?  Do we want to pursue publishing this as an 
> informational document or a standards track RFC?
> 
> Paul
> 
> > 408) because the endpoint is down? Shouldn't this be treated as a 
> > 503?(I presume the OPTION is sent stateful ) 2.As a minimum time 
> > interval in section 7, I recommend 32 seconds (or 64*T1) as 
> to ensure 
> > a transaction times out before a retry....
> > 
> > 
> > Marius
> > From: [email-masked] [[email-masked]] 
> On Behalf 
> > Of Paul E. Jones [[email-masked]]
> > should we do with it?  Should we modify this to be informational or 
> > pursue a standards track draft?  Several have expressed an 
> interest in 
> > seeing this go forward in some form to help ensure better 
> > interoperability, but the list has been fairly silent.
> > 
> > Here's the draft:
> > > > I think you discuss how to move forward with this draft on 
> > > > dispatch mailing list given that's the point of that 
> list is help 
> > > > with problems like this.
> > > >
> > > > > Gonzalo and I produced an Internet Draft aiming at trying to 
> > > > > bring some
> > > > consistency to the way in which SIP user agents implement an 
> > > > OPTIONS "ping" procedure.  It seems that a very large number of 
> > > > vendors do this, but unfortunately, there seems to be 
> little consistency.
> > > > >
> > > > least of which is the fact that there is no working group 
> > > > chartered to do the work.  We don't feel this one draft 
> warrants 
> > > > the creation of a working
> > > group.
> > > > >
> > > > > 3)      Forget about the draft and let every SIP 
> device do it the
> > way

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 30 Sep 2010 06:07:10 +0530

Marius,
 
Adding to Paul comments, I'm looking for the reason why the next hop (proxy) will respond with 408 in case Max forward is set to 1 in OPTIONS as mentioned in Sec 5.1 of this draft.
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
Sent: Wed 9/29/2010 9:20 PM
To: Marius Zbihlei
Cc: [email-masked]
Subject: Re: [dispatch] SIP OPTIONS "ping"

        Thanks,
        Paul

---

From: marius zbihlei <[email-masked]>
Date: Thu, 30 Sep 2010 15:45:45 +0300

On 09/30/2010 03:37 AM, Parthasarathi R (partr) wrote:
> Marius,
> Adding to Paul comments, I'm looking for the reason why the next hop 
> (proxy) will respond with 408 in case Max forward is set to 1 in 
> OPTIONS as mentioned in Sec 5.1 of this draft.
> Thanks
> Partha
>

Hello,

I was referring to a locally generated 408 (by the TM layer of the 
originating SIP Entity). This will mean that a answer from the queried 
entity was not received in 64*T1. For someone implementing a setup as 
described in  this memo, I think the local 408 or the 503 can have the 
same meaning i.e. the endpoint is not able to respond to sip requests.

Marius
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Paul Kyzivat (pkyzivat)
> *Sent:* Wed 9/29/2010 9:20 PM
> *To:* Marius Zbihlei
> *Cc:* [email-masked]
> *Subject:* Re: [dispatch] SIP OPTIONS "ping"
>
>
>
> > To put it simply, what happens if the OPTION request is responded 
> with a 408(generated locally)... In my opinion we should treat it as a 
> 503, but I see that you think it should be treated differently.
>
> > From: [email-masked] [[email-masked]] On 
> Behalf Of Paul Kyzivat [[email-masked]]
> >> 1.What happens if the sender never receives a reply (locally 
> generated 408) because the endpoint is down? Shouldn't this be treated 
> as a 503?(I presume the OPTION is sent stateful )
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Sep 2010 11:20:23 -0400

> same meaning i.e. the endpoint is not able to respond to sip requests.

If you get a 503, then you know that the message reached as far as the 
sender of the 503.

If you infer a 408, then you know very little. There might have been a 
temporary glitch in the network, while the target system itself is fine.

You may use similar tactics for these things, but they are not the *same*.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 1 Oct 2010 00:52:08 +0530

Marius,
 
I agree with Paul for 408 behavior in the transaction layer.
 
I'm seeing OPTIONS Ping as an application on top of transaction layer. In case of transaction timeout, this application infers that the next hop is not reachable at this moment and start its other actions based on the implemantation. For example: new INVITE will not be forwarded when the transaction timeout for OPTIONS ping till the next OPTIONS ping is suceeded. Having said that Transaction timeout has to be considered as 408 in the transaction layer. Hope this clarifies. 
 
Thanks
Partha

From: Paul Kyzivat (pkyzivat)
Sent: Thu 9/30/2010 8:50 PM
To: marius zbihlei
Cc: Parthasarathi R (partr); [email-masked]
Subject: Re: [dispatch] SIP OPTIONS "ping"

        Thanks,
        Paul