Internet DRAFT - draft-henrikson-sip-original-dialog-id
draft-henrikson-sip-original-dialog-id
Internet Draft E. Henrikson
Document: draft-henrikson-sip-original-dialog-id-02 Lucent
Expires: November 2002 Technologies
Category: Informational
May 2002
Private SIP Extension for Original Dialog Identifier
draft-henrikson-sip-original-dialog-id-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes a private extension to SIP in the form of a
P-Original-Dialog-ID header. The header is used to correlate two
different dialogs across a B2BUA that is non-transparent to
dialogs. The contents of the header identify the original dialog
(Call-id, From tag, To tag) associated with the SIP entity that
inserted the header into a request. When the same instance of the
header is received at that SIP entity in a different request, then
it is used to correlate the two different dialogs.
Table of Contents
1. Background....................................................2
2. Discussion of Mechanism.......................................3
3. Applicability Statement.......................................4
4. P-Original-Dialog-ID syntax and definition....................4
5. Usage.........................................................5
5.1 Procedures at the UA......................................5
5.2 Procedures at the Proxy...................................5
Henrikson Expires - November 2002 [Page 1]
Private SIP Extension for Original Dialog Identifier May 2002
5.3 Procedures at the Back to Back UA.........................6
5.4 Examples of Usage.........................................6
6. Security Considerations.......................................8
7. IANA Considerations...........................................8
8. Normative References..........................................8
9. Non-Normative References......................................8
Author's Addresses...............................................9
1. Background
Third Generation Partnership Project (3GPP) has selected SIP [1] as
the protocol to establish and tear down multimedia sessions in the
IP Multimedia Subsystem (IMS). A description of the IMS can be
found in 3GPP TS 23.228 [5] and 3GPP TS 24.229 [7].
3GPP has defined a mechanism by which a stateful proxy (which has
additional functions) needs to associate an INVITE request
processed earlier with the INVITE request that is being currently
processed. The association is needed by the Serving Call Session
Control Function (S-CSCF) from the 3GPP architecture to ensure
proper routing of an INVITE request with 3GPP Application Servers
(AS). A S-CSCF may be required to route an INVITE request to
multiple AS in a particular order, as indicated by subscriber
profile data, and each AS may be a B2BUA. The S-CSCF needs to keep
track of each AS contacted and know that an incoming INVITE request
is related to a previous outgoing INVITE request such that each AS
may receive the INVITE request before it is sent on towards the
intended destination. Also, there is a need for the S-CSCF to
associated the different but related dialogs for charging purposes.
When a B2BUA AS is involved, there is currently not a way to
associate the incoming INVITE request with the previously sent
INVITE request at the S-CSCF.
The S-CSCF is a SIP proxy with additional functionality as defined
in draft-garcia-sipping-3gpp-reqs [3], 3GPP TS 23.218 [6] and 3GPP
TS 24.229 [7]. The S-CSCF contacts multiple Application Servers
(AS) in a particular order when certain SIP events occur, e.g.
receiving an INVITE request. These events are also known as Service
Points of Interest (SPI). The HSS (database entity) provides the S-
CSCF with the list of events and relative priorities of the
Application Servers to contact per event (and other information).
The data from the HSS is also known as Filter Criteria.
When an event occurs that matches an SPI from the Filter Criteria,
the SIP serving proxy needs to contact each AS that is matched
before sending the message on towards the final destination. Each
AS may alter the message in some way before returning the message
to the SIP serving proxy. Since the message may have been changed
by the AS, including the components of the dialog identifier, the
Henrikson Expires - November 2002 [Page 2]
Private SIP Extension for Original Dialog Identifier May 2002
SIP serving proxy needs some way to determine that the received
message is related to the original message that it sent to the AS.
This will always be needed when an AS is acting as a B2BUA, which
starts a new dialog.
Consider the following example:
UA---P---I---S---AS---S---AS---S---AS---S---AS---S---I---P2---UA2
Every AS hop creates a new dialog -- so the above example actually
has 5 seperate dialogs.
One may consider using the Route header as a mechanism to get the
request sent back to the S-CSCF. However, Route headers don't
automatically transit an AS acting as a B2BUA. This could be
overcome by using loose-routing and application logic in the B2BUA.
But that is not the full problem to be solved. A strong correlation
of dialogs is also needed for accounting purposes to treat the
sequence of dialogs as a concatenated single dialog. A common
identification tag needs to be carried in each related dialog so
that the charging functions can associate all the dialogs.
The solution provided is to include the original dialog id in the
message sent to the AS and to have the AS return the same original
dialog id in the message sent back to the SIP serving proxy. Then
the SIP serving proxy can make the association between the two
messages and know that the incoming message is related to the
previous outgoing message, which is part of the sequence to contact
each AS that matched the Filter Criteria.
2. Discussion of Mechanism
The provided mechanism uses a private header "P-Original-Dialog-ID"
in an INVITE request forwarded from a proxy. The same mechanism may
be applied to other methods that initiate dialogs. The mechanism
only makes sense for stateful proxies that also employ some
application specific logic.
When a stateful proxy receives an INVITE that does not contain a P-
Original-Dialog-ID header, then it may choose to insert a P-
Original-Dialog-ID header into an INVITE request prior to
forwarding the request. If so, it will populate the contents with
the dialog identification fields from the received request: Call-
ID, From tag and To tag. If there was no To tag in the received
request, then a value of zero will be used for the To parameter in
the P-Original-Dialog-ID header.
When a stateful proxy receives an INVITE that already contains a P-
Original-Dialog-ID header, then it may use this information to look
Henrikson Expires - November 2002 [Page 3]
Private SIP Extension for Original Dialog Identifier May 2002
for a match with a previously handled dialog. If no match is found,
then the message is simply forwarded to the next destination. If a
match is found, then depending on the application specific logic
that may reside with the proxy, the P-Original-Dialog-ID header may
be removed from the outbound message.
3. Applicability Statement
This mechanism is suitable when a proxy forwards an initial request
for a dialog, or a standalone transaction, to an AS that may act as
a B2BUA, and the request is expected to return to the proxy with a
need to correlate the original request and the forwarded request
for the transaction or the dialog.
The P-Original-Dialog-ID header is applicable whenever the
following circumstances are met:
1. A UAC sends a REGISTER or dialog initiating request (e.g.,
INVITE) or a standalone transaction request to a proxy in
a private network.
2. The proxy in the private network that receives the request
needs to forward the request to one or more Application
Servers (AS) in a particular order.
3. One or more AS is a B2BUA and will return the modified
request back to the proxy.
4. The proxy in the private network needs to recognize that a
received, modified request is related to a previous
request.
5. Optionally, the proxy in the private network needs to
associate the different dialogs that are all related to
the original dialog for charging purposes.
4. P-Original-Dialog-ID syntax and definition
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) defined in RFC
2234 [2]. Further, the BNF definitions from RFC 3261 [1] are
inherited for the P-Original-Dialog-ID header and are not repeated
here. Implementers need to be familiar with the notation and
content of RFC 3261 [1] and RFC 2234 [2] to understand this
document.
The syntax for the P-Original-Dialog-ID header is as follows:
p-original-dialog-id = "P-Original-Dialog-ID" HCOLON
dialog-params *(SEMI dialog-params)
dialog-params = call-id / to-tag / from-tag / generic-param
call-id = "call-id" EQUAL callid
to-tag = "to-tag" EQUAL token
Henrikson Expires - November 2002 [Page 4]
Private SIP Extension for Original Dialog Identifier May 2002
from-tag = "from-tag" EQUAL token
Example:
P-Original-Dialog-ID: call-id=123@abc;to-tag=456;from-tag=789
A P-Original-Dialog-ID header may be inserted into an INVITE or
other standalone or dialog initiating request by any SIP node
traversed by that message. However, there may only be one instance
of a P-Original-Dialog-ID in a SIP message. Further, a particular
instance of P-Original-Dialog-ID shall contain exactly one of each
of the parameters: call-id, to-tag and from-tag.
The allowable usage of headers is described in Table 2 of SIP [1].
Addition of P-Original-Dialog-ID to the Table 2 in SIP [1], section
4.1 of the SIP-specific event notification [8], tables 1 and 2 in
the SIP INFO method [9], tables 1 and 2 in Reliability of
provisional responses in SIP [10], tables 1 and 2 in the SIP UPDATE
method [11], tables 1 and 2 in the SIP extension for Instant
Messaging [12] and table 1 in the SIP REFER method [13]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Original-Dialog-ID R ard - - - o o o
Header field SUB NOT PRA INF UPD MES REF
_______________________________________________________________
P-Original-Dialog-ID o - - - - o -
5. Usage
5.1 Procedures at the UA
The UAC and UAS (originating and terminating UA) behave as usual.
They are not required to understand the P-Original-Dialog-ID
header, but may retrieve the information if received.
5.2 Procedures at the Proxy
The P-Original-Dialog-ID header is treated like any other unknown
header by intermediate proxies. They simply forward it on towards
the destination.
If a proxy that supports this extension receives a dialog request
without the P-Original-Dialog-ID header, it MAY insert a P-
Original-Dialog-ID header prior to forwarding the message. The
from-tag parameter MUST be populated with the received From tag
value. The to-tag parameter MUST be populated with the received To
tag value or the value of zero if there was no To tag present. The
Henrikson Expires - November 2002 [Page 5]
Private SIP Extension for Original Dialog Identifier May 2002
call-id parameter MUST be populated with the received Call-ID
value.
If a proxy that supports this extension receives a dialog request
with the P-Original-Dialog-ID header, it MAY retrieve the
information from the header to use with application specific logic.
The proxy SHOULD retain the P-Original-Dialog-ID header in the
outbound message. If the next hop for the message is outside the
network of the proxy, then the proxy MAY remove the P-Original-
Dialog-ID header from the message.
The P-Original-Dialog-ID header carries only tag information, and
therefore does not reveal information that may affect the privacy
of the remote users; however the information contained is of no
relevance to the end UAs and therefore MAY be removed as defined
above for reasons of protocol efficiency which may be of concern in
a radio environment.
5.3 Procedures at the Back to Back UA
If a B2BUA that understands the P-Original-Dialog-ID header
receives a dialog request with the P-Original-Dialog-ID header, the
B2BUA SHOULD copy it from the receiving side UA to the sending side
UA.
5.4 Examples of Usage
We present example in the context of the scenario presented in the
Background section earlier in this document. The network diagram
is replicated below:
Scenario
UA1----P1-----AS-----P1-----P3-----UA2
This example shows the message sequence for an INVITE transaction
originating from UA1 eventually arriving at UA2. P1 is an outbound
proxy for UA1 which routes the request to an Application Server
(AS). In this case the Application Server acts as a B2BUA
independent of any knowledge of P1. AS routes the request back to
P1 using SIP routeing mechanisms that are not detailed in this
example. P1 correlates the original request with the returned
request. P1 then routes the call via P3 to UA2.
Message sequence for INVITE using P-Original-Dialog-ID:
Henrikson Expires - November 2002 [Page 6]
Private SIP Extension for Original Dialog Identifier May 2002
F1 INVITE UA1 -> P1
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
. . .
F2 INVITE P1 -> AS
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
P-Original-Dialog-ID: call-id=843817637684230@998sdasdh09;
to-tag=0;from-tag=456248
. . .
F3 INVITE AS -> P1
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP AS:5060;branch=z9hG4bKiokioukju908
To: Joe <sip:joe>
From: AS@HOMEDOMAIN <AS@HOMEDOMAIN>;tag=934871
Call-ID: 383749274837591@567ahjk8321
CSeq: 4 INVITE
Contact: <sip:UA@183.0.5.8>
P-Original-Dialog-ID: call-id=843817637684230@998sdasdh09;
to-tag=0;from-tag=456248
. . .
P1 removes the P-Original-Dialog-ID header
F5 INVITE P1 -> P3
INVITE sip:joe@UA2
Via: SIP/2.0/USP P1:5060;branch=z9hG4bKHSP10120323
Via: SIP/2.0/UDP AS:5060;branch=z9hG4bKiokioukju908
To: Joe <sip:joe@UA2>
From: AS@HOMEDOMAIN <AS@HOMEDOMAIN>;tag=934871
Call-ID: 383749274837591@567ahjk8321
CSeq: 4 INVITE
Contact: <sip:UA@183.0.5.8>
. . .
Henrikson Expires - November 2002 [Page 7]
Private SIP Extension for Original Dialog Identifier May 2002
INVITE propagates toward UA2 as usual.
6. Security Considerations
It is possible for proxies between the originating UA and the
terminating UA to modify the value of P-Original-Dialog-ID or to
insert a P-Original-Dialog-ID into a request for a dialog, e.g.
INVITE request. Therefore, an integrity protection mechanism such
as IPsec or other available mechanisms SHOULD be applied in order
to prevent such attacks.
The information contained is tag information from the original
request, and therefore knowledge of the contents of this header
does not compromise the privacy of the UA or any of the involved
proxies.
7. IANA Considerations
This document defines the SIP extension header "P-Original-Dialog-
ID" which should be included in the registry of SIP headers defined
in SIP [1]. As required by the SIP change process draft-tsvarea-
sipchange [4] the SIP extension header name "Original-Dialog-ID"
should also be registered in association with this extension.
8. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session
Initiation Protocol, RFC 3261", March 2002.
[2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax
specifications: ABNF," RFC 2234, Internet Engineering Task Force,
November 1997.
9. Non-Normative References
[3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia-
sipping-3gpp-reqs-03.txt", March 2002.
[4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange",
March 2002.
[5] 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) -
Release 5".
[6] 3GPP TS 23.218 " IP Multimedia (IM) Session Handling; IM call
model - Release 5".
Henrikson Expires - November 2002 [Page 8]
Private SIP Extension for Original Dialog Identifier May 2002
[7] 3GPP TS 24.229 "IP Multimedia Subsystem (IMS) (Stage 3) -
Release 5".
[8] A. Roach, SIP-Specific Event Notification, RFC 3265, March
2002.
[9] S. Donovan, The SIP INFO method, RFC 2976, October 2000.
[10] J. Rosenberg, H. Schulzrinne, Reliability of Provisional
Responses in SIP, RFC 3262, March 2002.
[11] J. Rosenberg, The Session Initiation Protocol UPDATE Method,
draft-ietf-sip-update-02.txt, April 2002, work in progress.
[12] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D.
Gurle, Session Initiation Protocol Extension for Instant Messaging,
draft-ietf-sip-message-04, May 2002, work in progress.
[13] R. Sparks, The REFER method, draft-sparks-sip-refer-split-
00.txt, April 2002, work in progress.
Author's Addresses
Eric Henrikson
Lucent Technologies
11601 Willows Rd
Suite 100
Redmond, WA 98052
US
Phone: +1 425 497 2442
EMail: ehenrikson@lucent.com
URI: http://www.lucent.com/
Henrikson Expires - November 2002 [Page 9]
