Subject: [Sipping] Another proposal for Network Initiated Call Release - Correlation of Dialogs

From: Mayer Georg ICM N PG SP ST SN 1 <[email-masked]>
Date: Sat, 17 Nov 2001 10:40:26 +0100

Hello SIPPING group,

as we had already a lot of discussion around the network initiated call
release issue, I would like to provide again some ideas for that purpose.
The whole thing is outlined in the below message which I sent to the SIP
group today. Please feel free to comment on the subject.

Thanks and keep on signaling!
Georg

Hello SIP Group,

following some internal and SIPPING list discussions I started working on a
possible extension for SIP which allows to correlate two dialogs (of
whatever type) for the sake of communication between entities which act as a
proxy for an end-to-end dialog and which additionally need to exchange
signaling related to the end-to-end dialog amongst each other. Additionally
the proposed solution also would allow to initiate the session tear down
from the network. 

Below please find some outline of the requirements and the proposed
solution. This text was written in a way that it might be used as some kind
of abstract or introduction to a new Internet Draft. I would be happy if the
SIP experts would indicate to me whether there is an interest in the below
outlined solution and in which way the proposal can be improved further.
Please feel free to send me any comment or further proposal. 

Please also treat the network initiated tear down proposal as an addition to
the main (correlation) proposal - the correlation mechanism on its own
(without the network initiated tear down option) can be achieved on its own.

Thank you for your cooperation. Keep on signaling!
Georg

Dialog Correlation - the CORRELATE method

The Session Initiation Protocol (SIP) enables two user agents to communicate
via a signalling connection (dialog). This dialog between the user agents is
identified by the combination of a globally unique Call-ID, a To and a From
header, wherby these two headers need to carry a tag, which is also mandated
to be globally unique. The individual requests that are sent between the
users carry a monotonously increasing value, the so-called CSeq. 
   
   Although all SIP signalling messages for one specific dialog can be
forced to follow a specific route which involves one or more proxies, the
proxies can neither send messages directly to one or both of the user agents
nor can they communicate amongst each other on the same dialog. For the
purpose of such a communication, additional dialogs need to be established,
which cannot be correlated to each other.
   
   Certain applications require the communication of proxies with one or
both user agents or with other proxies on existing dialogs. An example for
such an application is e.g. a billing server which gets information from
another application server that offers certain services to the user. In
order to charge the user requested services not only to the user but also to
relate it to the specific dialog, the billing server needs to get additional
information from the application server. Furthermore the billing server
might want to inform the user about the already collected amount of charges
directly during the dialog (Advice of Charge). 
   
   This document introduces a mechanism that allows any entity (user agent
or proxy) which is involved in a SIP dialog (the so-called base-dialog) to
establish a second SIP signalling session (the so-called auxiliary-dialog)
to any other entity which is involved in the same base-dialog and to
correlate the auxiliary-dialog to the base-dialog. Correlation in the sense
of this specification means that entities that receive messages on the
auxiliary-dialog shall treat these messages as if they were received on the
base-dialog. However, the messages of the auxiliary-dialog shall not be sent
to any entity that is not on the signaling route of the auxiliary-dialog
(which might be different from the singaling route of the base-dialog). 
   
   This correlation mechanism also allows the correlation of two dialogs
which are established between the same user agents. 
   
   This correlation mechanism also allows the correlation of two dialogs of
different nature, e.g. a dialog established by an INVITE method and another
one which was established by a SUBSCRIBE method.
   
   In order to correlate a new auxiliary-dialog to an already existing
base-dialog the Correlate-To, Correlat-From and Correlate-Call-ID headers
are defined in this document. They hold the information of the To, From and
Call-ID headers which uniquely identify the base-dialog. These three headers
can be used in any SIP request.
   
   In order to correlate two already existing dialogs this document defines
the CORRELATE method. The CORRELATE method can be sent at any time during
the life-time of a dialog and carries (besides other basic SIP headers) the
Correlate-To, Correlate-From and Correlate-Call-ID headers. The dialog on
which the CORRELATE method is sent is the auxiliary-dialog. The dialog which
is identified by the Correlate-To, Correalte-From and Correlate-Call-ID
headers is the base-dialog. 
   
   In order to immediately establish an auxiliary-dialog the CORRELATE
method can be used as a initial SIP request, which establishes a new dialog.
In this case, the CORRELATE method may carry an Expires header. The
auxiliary-dialog is released when the base-dialog is released. If an Expires
header was placed into the initial CORRELATE request and the value of the
Expires header expires before the base-dialog is released, then the
auxiliary-dialog shall immediately be released. An auxiliary-dialog MUST NOT
persist longer then a base-dialog. 
   
   For special applications the CORRELATE method can carry an additional
Correlate-Method header. In this case the CORRELATE method shall be
interpreted by the receiving entities as if the method indicated in the
Correlate-Method header was received on the base-dialog. 
   
   A special application example is the network initiated call release
scenario. If a network entity (proxy) sees the need to tear down an existing
dialog between two user agents and this specific proxy is on the route of
this dialog, then it can use the CORRELATE method for this purpose. It can
send a CORRELATE method to both user agents. The Correlate-Method header
shall indicate a "BYE" message. All entities along the route of the dialog
shall regard this message as if they received a BYE message on the dialog
which is identified by the Correlate-To, Correlate-From and
Correlate-Call-ID headers in the CORRELATE message.

_______________________________________________________
Georg Mayer - Siemens AG
Information and Communication Mobile
ICM N PG SP ST SN1
Hofmannstr. 51, 81359 Munich, Germany
Fon: +49-89-722-33114
Fax: +49-89-722-62250
Mobile: +49-172-5371233
Email: [email-masked]

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP