draft-ietf-sipcore-originating-cdiv-parameter-00.txt   draft-ietf-sipcore-originating-cdiv-parameter-01.txt 
SIPCORE Working Group M. Mohali SIPCORE Working Group M. Mohali
Internet-Draft Orange Internet-Draft Orange
Updates: 5502 (if approved) May 15, 2017 Updates: 5502 (if approved) September 27, 2017
Intended status: Informational Intended status: Informational
Expires: November 16, 2017 Expires: March 31, 2018
A P-Served-User Header Field Parameter for Originating CDIV session case A P-Served-User Header Field Parameter for Originating CDIV session case
in Session Initiation Protocol (SIP) in Session Initiation Protocol (SIP)
draft-ietf-sipcore-originating-cdiv-parameter-00 draft-ietf-sipcore-originating-cdiv-parameter-01
Abstract Abstract
This specification defines a new parameter of the P-Served-User This specification defines a new parameter of the P-Served-User
header field in the Session Initiation Protocol (SIP). This new header field in the Session Initiation Protocol (SIP). This new
"orig-cdiv" parameter defines the session case used by a proxy when "orig-cdiv" parameter defines the session case used by a proxy when
handling an originating session after Call Diversion (CDIV) services handling an originating session after Call Diversion (CDIV) services
has been invoked for the served user. The P-Served-User header field has been invoked for the served user. The P-Served-User header field
is defined in RFC5502 to convey the identity of the served user and is defined in RFC5502 to convey the identity of the served user and
the session case that applies to this particular communication the session case that applies to this particular communication
skipping to change at page 1, line 35 skipping to change at page 1, line 35
were missing in RFC5502. were missing in RFC5502.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 16, 2017. This Internet-Draft will expire on March 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Proxy behavior and parameter handling . . . . . . . . . . . . 4 2. Proxy behavior and parameter handling . . . . . . . . . . . . 4
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Call diversion and privacy . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
1.1. General 1.1. General
The P-Served-User header field was defined in [RFC5502] to address an The P-Served-User header field was defined in [RFC5502] to address an
issue that was found in the 3rd Generation Partnership Project (3GPP) issue that was found in the 3rd Generation Partnership Project (3GPP)
IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session
Control Function) and an AS (Application Server) on the ISC (IMS Control Function) and an AS (Application Server) on the ISC (IMS
Service Control) interface. For more information on the IMS, a Service Control) interface. For more information on the IMS, a
detailed description can be found in [TS.3GPP.24.229]. detailed description can be found in [TS.3GPP.24.229].
This header field conveys the identity of the served user, his/her The P-Served-User header field conveys the identity of the served
registration state and the session case that applies to this user, his/her registration state and the session case that applies to
particular communication session and application invocation. this particular communication session and application invocation.
[RFC5502] defines the originating and terminating session cases for a [RFC5502] defines the originating and terminating session cases for a
registered or unregistered user. This document extends the P-Served- registered or unregistered user. This document extends the P-Served-
User header field to include the session case for a forwarded leg User header field to include the session case for a forwarded leg
when a call diversion service (CDIV) has been invoked and if an when a call diversion service (CDIV) has been invoked and if an
originating service of the diverting user has to be triggered. originating service of the diverting user has to be triggered.
The sessioncase-param parameter of the P-Served-User header field is The sessioncase-param parameter of the P-Served-User header field is
extended with the "orig-cdiv" parameter for this "originating after extended with the "orig-cdiv" parameter for this "originating after
CDIV" session case. CDIV" session case.
skipping to change at page 3, line 19 skipping to change at page 3, line 25
The following section defines usage of the "orig-cdiv" parameter of The following section defines usage of the "orig-cdiv" parameter of
P-Served-User header field, Section 2 specifies the proxy behavior P-Served-User header field, Section 2 specifies the proxy behavior
for handling the new header field parameter, and Section 3 discusses for handling the new header field parameter, and Section 3 discusses
the applicability and scope of this new header field parameter. the applicability and scope of this new header field parameter.
Section 4 describes the syntax and correct the syntax of [RFC5502], Section 4 describes the syntax and correct the syntax of [RFC5502],
Section 5 registers the P-Served-User header field parameters with Section 5 registers the P-Served-User header field parameters with
IANA, and Section 6 discusses the security properties of the IANA, and Section 6 discusses the security properties of the
environment where this new header field parameter is intended to be environment where this new header field parameter is intended to be
used. used.
1.2. Use Case 1.2. Basic Use Case
In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF)
is a SIP proxy that serves as a registrar and handles originating and is a SIP proxy that serves as a registrar and handles originating and
terminating session states for users allocated to it. This means terminating session states for users allocated to it. This means
that any call that is originated by a specific user or any call that that any call that is originated by a specific user or any call that
is terminated to that specific user will pass through the S-CSCF that is terminated to that specific user will pass through the S-CSCF that
is allocated to that user. is allocated to that user.
At the moment that an S-CSCF is allocated for a specific user, the At the moment that an S-CSCF is allocated for a specific user, the
user profile is downloaded to the S-CSCF from the HSS (Home user profile is downloaded from the HSS (Home Subscriber Server) to
Subscriber Server), see [TS.3GPP.29.228]. this S-CSCF, see [TS.3GPP.29.228]. The user profile contains the
list of actions to be taken by the S-CSCF for the served user
depending on the session direction (originating or terminating) and
the user state (registered or not) in the IMS network. With this
user profile, the S-CSCF determines the current case and apply the
corresponding actions such as forward the request to an AS. At its
turn, the AS has to go through a similar process of determining who
is the current served user, what is his/her "registration state" and
on which "session case" is the session. [RFC5502] defines all those
parameters and in particular the originating and terminating session
cases.
To be able to determine which responsibilities the S-CSCF and the In basic call scenarios, the is no particular issue for the S-CSCF
Application Server have to perform and on which user's behalf, it is and AS to know which scenario needs to be realized but in case of
necessary to know who is the current served user, what is his/her call diversion services for which the session is re-targeted, the
"registration state" and on which "session case" is the session. session cases defined in [RFC5502] poses some limitations as
[RFC5502] defines all those parameters and in particular the described in the following section.
originating and terminating session cases.
In the case of a call diversion service, the received request is 1.3. Problem Statement
first considered as a terminating session case and the terminating
filter criteria configured in the S-CSCF are performed. Receiving In case of a call diversion service, the received request is first
the call initiation request, the Application Server is able to considered as a terminating session case and the terminating filter
determine the served user and the session case (here "term") from the criteria configured in the S-CSCF are performed. Receiving the call
received P-Served-User header field content and to execute initiation request, the Application Server is able to determine the
terminating services. When the call diversion service is executed served user and the session case (here "term") from the received P-
(as a terminating service), the Application Server changes the target Served-User header field content and to execute terminating services.
(Request-URI) of the session and a new call leg is created. This new When the call diversion service is executed (as a terminating
call leg could be considered as an originating call leg from the service), the Application Server changes the target (Request-URI) of
diverting user but this is not the case. Indeed, the originating the session and a new call leg is created. This new call leg could
user remains the same and some of the diverting user's originating be considered as an originating call leg from the diverting user but
services should not be triggered as if it was an originating call. this is not the case. Indeed, the originating user remains the same
For instance, the originating user identity should not be restricted and some of the diverting user's originating services should not be
because the diverting user has a privacy service for his/her own triggered as if it was an originating call. For instance, the
identity. The privacy of the diverting user should apply to originating user identity should not be restricted because the
information related to this user (eg. in the Histroy-Info header diverting user has a privacy service for his/her own identity. The
field). In the same manner, some specific services will need to be privacy of the diverting user should apply to information related to
specifically triggered on the outgoing leg after a call diversion. this user (eg. in the Histroy-Info header field). In the same
Without a dedicated session case for originating after CDIV, there is manner, some specific services will need to be specifically triggered
no possiblity for a proxy to trigger an originating service for the on the outgoing leg after a call diversion. Without a dedicated
diverting user or for an Application Server to execute the procedures session case for originating after CDIV, there is no possiblity for a
for this particular session case. proxy to trigger an originating service for the diverting user or for
an Application Server to execute the procedures for this particular
session case.
For this use case, this document creates a new parameter for the For this use case, this document creates a new parameter for the
originating after CDIV session case to be embedded in the P-Served- originating after CDIV session case to be embedded in the P-Served-
User header field. User header field.
2. Proxy behavior and parameter handling 2. Proxy behavior and parameter handling
The "orig-cdiv" header field parameter can be used inside a trust The "orig-cdiv" header field parameter can be used inside a trust
domain of the P-Served-User header field by proxies that are domain of the P-Served-User header field by proxies that are
processing call diversion services. The following section processing call diversion services. The following section
skipping to change at page 7, line 37 skipping to change at page 8, line 5
Values" sub-registry as per the registry created by [RFC3968]: Values" sub-registry as per the registry created by [RFC3968]:
Header Field Parameter Name Predefined Values Reference Header Field Parameter Name Predefined Values Reference
-------------- ---------------- ----------------- ----------------- -------------- ---------------- ----------------- -----------------
P-Served-User sescase Yes [RFC5502][RFCXXXX] P-Served-User sescase Yes [RFC5502][RFCXXXX]
P-Served-User regstate Yes [RFC5502][RFCXXXX] P-Served-User regstate Yes [RFC5502][RFCXXXX]
P-Served-User orig-cdiv No [RFCXXXX] P-Served-User orig-cdiv No [RFCXXXX]
Note to RFC Editor: Please replace XXXX with the RFC number of this document. Note to RFC Editor: Please replace XXXX with the RFC number of this document.
6. Security Considerations 6. Call Flow Examples
6.1. Call diversion case
The following call flow shows a session establishement for Alice
calls Bob which has a call diversion when busy towards Carol.
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| INVITE F4 | |
| |-------------------------------->| |
| | 486 F5 | |
| |<--------------------------------| |
| | 486 F6 | | |
| |--------------->| | |
| | INVITE F7 | | |
| |<---------------| | |
| | INVITE F8 | | |
| |--------------->| | |
| | INVITE F9 | | |
| |<---------------| INVITE F10 |
| |------------------------------------------------->|
| | | | |
| | | | 180 F11 |
| | | 180 F12 |<---------------|
| | 180 F13 |<---------------| |
| 180 F14 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F4 INVITE S-CSCF-B -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B
486 BUSY
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>;tag=es43sd
F7 INVITE AS-B -> S-CSCF-B
INVITE sip:Carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F8 INVITE S-CSCF-B -> AS-B
INVITE sip:Carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F9 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F10 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Figure 1: P-Served-User during call diversion service
6.2. Call diversion and privacy
The following call flow shows a call diversion use case for which
Alice has no identity restriction service and Bob has an
unconditional call diversion service towards Carol and an identity
presentation restriction service.
proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | |
| INVITE F1 | | | |
|--------------->| INVITE F2 | | |
| |--------------->| | |
| | INVITE F3 | | |
| |<---------------| | |
| | INVITE F4 | | |
| |--------------->| | |
| | INVITE F5 | | |
| |<---------------| INVITE F6 | |
| |------------------------------------------------->|
| | | | |
| | | | 180 F7 |
| | | 180 F8 |<---------------|
| | 180 F9 |<---------------| |
| 180 F10 |<---------------| | |
|<---------------| | | |
| | | | |
F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Supported: histinfo
F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
F3 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F4 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F5 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
F6 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com>
History-Info:
<sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1
<sip:carol@192.0.2.7>;index=1.1.1;rc=1.1
Figure 2: P-Served-User when privacy requested
7. Security Considerations
The security considerations in [RFC5502] apply. The security considerations in [RFC5502] apply.
As the "orig-cdiv" parameter of P-Served-User header field can be As the "orig-cdiv" parameter of P-Served-User header field can be
used to trigger applications, it is important to ensure that the used to trigger applications, it is important to ensure that the
parameter has not been added to the SIP message by an unauthorized parameter has not been added to the SIP message by an unauthorized
SIP entity. SIP entity.
7. Acknowledgments 8. Acknowledgments
The author wishes to thank the 3GPP community for providing guidance, The author wishes to thank the 3GPP community for providing guidance,
input, and comments on the document. Thanks also to Dale Worley for input, and comments on the document. Thanks also to Dale Worley for
his careful review of the document. his careful review of the document. A special thanks to Christer
Holmberg.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
DOI 10.17487/RFC3968, December 2004, DOI 10.17487/RFC3968, December 2004,
<http://www.rfc-editor.org/info/rfc3968>. <https://www.rfc-editor.org/info/rfc3968>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
C. Holmberg, "An Extension to the Session Initiation C. Holmberg, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 7044, Protocol (SIP) for Request History Information", RFC 7044,
DOI 10.17487/RFC7044, February 2014, DOI 10.17487/RFC7044, February 2014,
<http://www.rfc-editor.org/info/rfc7044>. <https://www.rfc-editor.org/info/rfc7044>.
8.2. Informative References 9.2. Informative References
[RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header
(P-Header) for the 3GPP IP Multimedia (IM) Core Network (P-Header) for the 3GPP IP Multimedia (IM) Core Network
(CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April
2009, <http://www.rfc-editor.org/info/rfc5502>. 2009, <https://www.rfc-editor.org/info/rfc5502>.
[TS.3GPP.24.229] [TS.3GPP.24.229]
3GPP, "IP multimedia call control protocol based on 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Session Initiation Protocol (SIP) and Session Description
Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. Protocol (SDP);Stage 3", 3GPP TS 24.229 v11.
[TS.3GPP.29.228] [TS.3GPP.29.228]
3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
Signalling flows and message contents", 3GPP TS 29.228 Signalling flows and message contents", 3GPP TS 29.228
v11. v11.
 End of changes. 25 change blocks. 
60 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/