Re: [sip-ops] [dispatch] [Sip-implementors] SIP OPTIONS "ping"

[Michael Miller <[e-mail]>]

The end the end OPTIONS ping sounds like a great ideal, but does this change this doc from more of a informational/best practice to some thing that would require a change to SIP (like a header or something). 

I'm new to this

Michael L. Miller
Sent from my Mobile Device

On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" <[e-mail]> wrote:

> Marius,
> 
> There is another important consideration to give to this.  The OPTIONS
> "ping" we described was intended to be between a device and its next hop.
> What you would actually want is an OPTIONS that goes end-to-end.
> 
> I think both need clarification, but I'm now thinking that perhaps we ought
> to document these separately.  Of course, I'd be happy to work with you on
> both.
> 
> Paul
> 
>> -----Original Message-----
>> From: marius zbihlei [mailto:[e-mail]]
>> Sent: Monday, August 16, 2010 10:04 AM
>> To: Paul E. Jones
>> Cc: [e-mail]; [e-mail]; 'Gonzalo
>> Salgueiro'; 'Hadriel Kaplan'; [e-mail]
>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping"
>> 
>> Paul E. Jones wrote:
>>> Marius,
>>> 
>>> It is certainly true that we were focused entirely on out-of-dialog
>>> OPTIONS messages when we wrote the draft.  I'm certainly not opposed
>>> to also including in-dialog OPTIONS exchanges if it fit smoothly within
>> the draft.
>>> Alternatively, we could create two drafts.
>>> 
>>> Would you like to draft some initial text for in-dialog and see if it
>>> makes sense to include it in this same draft or a separate one?  If in
>>> the same draft, then perhaps in-dialog and OOD would be two separate
>> sections?
>>> 
>>> Paul
>>> 
>>> 
>> Hello again,
>> 
>> I would gladly draft some initial text around this idea, but I am a little
>> torn apart between what I expect from the draft(and current
>> implementations) and what previous standards say.
>> 
>> Quote from RFC 3261
>> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a
>> dialog may be received within a dialog (for example, an OPTIONS request).
>> They are processed as if they had been received outside the dialog."
>> 
>> Along with other texts[1], this means that in-dialog OPTIONS requests
>> should be treated as OOD(also the thread I have linked seems to suggest
>> that). But I know for certain that lots of implementors do return a 481,
>> and several services rely on that error code to check if a dialog is still
>> running. I know about SIP Session Timers but using OPTIONS ping like
>> this(to discover if a dialog has finished) has some benefits(like the
>> proxy being able to terminate a call , which is not possible using SST
>> [2]), and more and more this looks like a "de facto" behavior.
>> 
>> With this in mind, I have to ask the question: Should we allow (or
>> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog
>> does not exits)(this is what I personally want and many implementors
>> already do), or should we respond with a 200 OK regardless if the dialog
>> exists or not?!
>> 
>> Thank you in advance for answering this.
>> 
>> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only
>> those failures discussed in Section 5.1 and Section 5.2 that destroy
>> entire dialogs will have any effect on the usages sharing the dialog with
>> a failed OPTIONS request."
>> 
>> This in fact might prove usefull, as a failed in-dialog OPTIONS request
>> will guaranty that the dialog will not be destroyed
>> 
>> [2] http://www.rfc-editor.org/rfc/rfc4028.txt
>> 8.3. Session Expiration
>> 
>> When the current time equals or passes the session expiration for a
>> session, the proxy MAY remove associated call state, and MAY free any
>> resources associated with the call. Unlike the UA, it MUST NOT send a BYE.
>>>> -----Original Message-----
>>>> From: marius zbihlei [mailto:[e-mail]]
>>>> Sent: Monday, August 16, 2010 6:00 AM
>>>> To: Paul E. Jones
>>>> Cc: [e-mail]; [e-mail]; Gonzalo
>>>> Salgueiro; Hadriel Kaplan
>>>> Subject: Re: [Sip-implementors] SIP OPTIONS "ping"
>>>> 
>>>> 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?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> Hello,
>>>> 
>>>> I have read the draft and as far I can tell it addresses OPTIONS
>>>> outside a dialog. I know that this has already been discussed on this
>>>> mailing list[1], but there still are many vendors/SIP implementors
>>>> that use a in- dialog OPTIONS to figure out if a dialog is still
>>>> running(if not the UAS "will" respond with a 481- Call does not
>>>> exist). By reading the comments and the RFC I know this is wrong(a
>>>> UAS might return a 200 OK even if the dialog does not exist), but I
>>>> think this enters into the "3) Forget about the draft and let every
>>>> SIP device do it the way they want, throwing hope of consistency out
>> the window " category.
>>>> 
>>>> My first reaction is also to address this topic in the draft. What do
>>>> you think?
>>>> 
>>>> Marius
>>>> 
>>>> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-
>>>> May/019278.html
>>>> 
>>>>> 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-implementors mailing list
>>>>> [e-mail]
>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch