On 11/01/2010 05:24 PM, Vic Jolin wrote:
That's interesting, can you tell me more about that draft?
Hello
I have attached the draft.
There are 2 setups for using end-to-end OPTIONS ping
1. In Dialog... if one of the endpoints is a B2BUA, it can send at
specific interval in-dialog OPTIONS ping (OPTIONS request, increasing
cseq) to the other endpoint. Most well-behaved UAS will respond with a
481 if the dialog not longer exists as per RFC 3261 .
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.
Other error conditions are on a 408 , 404 etc (as any in-dialog request
is not guaranteed to succeed).
This is already used some production environments.
2. Out of dialog. A proxy keeps sending OPTIONS request (no dialog
involved here) to one of the UA as long as one of these 2 conditions exist:
a. the dialog has not ended via a method specific mean (BYE for INVITE etc)
b. a 408 (or other error codes) was received when generating a BYE.
These where the big two points of the draft.
Marius
On Mon, Nov 1, 2010 at 11:18 PM, marius zbihlei
marius.zbih...@1and1.ro mailto:marius.zbih...@1and1.ro wrote:
On 11/01/2010 05:13 PM, Vic Jolin wrote:
Hi,
Just want to ask what is the best way to check if calls are
still active especially when we are not handling media?
Thanks
Hello
There is SST (Sip Session Timers RFC 4028), which is implemented
in the SST module, but at least 1 UA must know the extension. Also
I have been working on a IETF draft to use end-to-end OPTIONS
ping to determine the operational status of a UA.(it works well
with B2BUA, relatively well with stateful proxies). If you are
interested I can talk more about the draft and how I propose using
OPTIONS requests for this.(no changes on UAs are necessary)
Marius.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Network Working Group M. Zbihlei
Internet-Draft 1and1 Internet AG
Expires: February 2, 2011August 2010
Draft-mzbihlei-end-to-end-OPTIONS-ping-01
Abstract
For VoIP providers, a common problem is related with finding the
state of a dialog in certain error conditions that are caused by
network problems, User Agent(UA) crashes etc. This document
describes a procedure for using the Session Initiation Protocol (SIP)
OPTIONS method in order to allow a SIP entity to discover the status
of a UA and decide the state of the dialog.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress.
This Internet-Draft will expire on February 2, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zbihlei Expires February 2, 2011[Page 1]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
1. Introduction
Given the multitude of parties involved in a SIP Call, a common
problem for providers is determining the status of the caller/callee
during a dialog. There are methods for making SIP enabled networks
robust and efficient by providing redundancy at hardware or service
level, but this is not the case for most UAs. Hardware problems,
software crashes, power failures are factors in the way a UA behaves,
affecting
