dispatch G. Camarillo
Internet-Draft J. Maenpaa
Intended status: Standards Track Ericsson
Expires: September 10, 2010 G. Yang
ZTE
March 9, 2010
Media State under Preconditions in the Session Initiation Protocol (SIP)
draft-camarillo-dispatch-precons-00.txt
Abstract
In this document, we describe how a UAS (User Agent Server) involved
in a session modification can explicitly signal the point where the
new session parameters start being used. Explicitly signalling such
a change in the session parameters can be useful so that network
intermediaries such as B2BUAs (Back-to-back User Agents) have a clear
picture of the session's state at every point.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on September 10, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Camarillo, et al. Expires September 10, 2010 [Page 1]
Internet-Draft Media State under Preconditions March 2010
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Starting Using the Media Parameters Subject to
Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Tradeoff between Being Bandwidth Efficient and Having
Explicit Signalling . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Camarillo, et al. Expires September 10, 2010 [Page 2]
Internet-Draft Media State under Preconditions March 2010
1. Introduction
The preconditions mechanism in SIP [RFC3261], as specified in RFC
3312 [RFC3312] and RFC 4032 [RFC4032], was designed to allow UAs to
reach a common view on the state of the preconditions for a media
session. The UAs perform offer/answer exchanges updating each other
on the status of their preconditions so that session establishment
(in the case of an initial INVITE request) or session modification
(in the case of a re-INVITE) can proceed. Once all mandatory
preconditions are met, the UAS can proceed with the session
establishment or the session modification.
2. Starting Using the Media Parameters Subject to Preconditions
Preconditions are stream specific. That is, they apply to the media
parameters to be used in a media stream. When the mandatory
preconditions for a media stream are met, the UAs can start using the
media parameters that were subject to the preconditions.
However, the fact that the UAs can start using the new media
parameters does not mean that they need to start using them
immediately. When preconditions are used, the UAS decides when to
start using them. During a session establishment, the UAS can wait
for using the media parameters until the callee starts being alerted
or until the callee accepts the session. During a session
modification, the UAS can wait until the callee accepts the changes
to the session.
The preconditions specifications do not mandate UAs to perform a new
offer/answer exchange when the new media parameters start being used.
The UAS starts using them and the UAC discovers that the new media
parameters are in use at the media level. In a session modification,
the UAC stops using the old media parameters at that point.
Discovering when the new media parameters start being used at the
media level saves an additional offer/answer exchange. However,
network intermediaries such as B2BUAs will not know what the current
state of the media session is. Therefore, UASs in environments where
intermediaries that require knowledge of the current media state of
the session may be present should consider performing such additional
offer/answer exchanges. The examples in the following section
illustrate this point.
Note that ICE faced the same issue when it was being designed. ICE
was originally designed in a similar way as the preconditions
mechanism. That is, endpoints were supposed to agree on the
addresses to use for the session at the media level. ICE was
Camarillo, et al. Expires September 10, 2010 [Page 3]
Internet-Draft Media State under Preconditions March 2010
eventually redesigned in order to have more explicit signalling
(i.e., offer/answer exchanges) about what addresses were being used
at the media level.
Camarillo, et al. Expires September 10, 2010 [Page 4]
Internet-Draft Media State under Preconditions March 2010
3. Examples
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<------(5) 183 Session Progress SDP4--------|
| *** *** |
|--*R*-----------(6) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(7) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(8) UPDATE SDP5--------------->|
| |
|<--------(9) 200 OK (UPDATE) SDP6-----------|
| |
|<-----------(10) UPDATE SDP7----------------|
| |
|--------(11) 200 OK (UPDATE) SDP8---------->|
| |
| |
|<-----------(12) UPDATE SDP9----------------|
| |
|--------(13) 200 OK (UPDATE) SDP10--------->|
| |
|<-----------(14) 200 OK (INVITE)------------|
| |
|------------------(15) ACK----------------->|
| |
Camarillo, et al. Expires September 10, 2010 [Page 5]
Internet-Draft Media State under Preconditions March 2010
Acceptance of a video stream by the user
The UAs perform an offer/answer exchange to establish an audio only
session:
SDP1:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
SDP2:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
At a later point, the UAC sends a re-INVITE (4) in order to change
the IP address where it receives the audio stream to a new IP address
and add a video stream to the session. Both media streams are
subject to preconditions.
SDP3:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP4
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.5
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
When the UAC finishes resource reservations in its 'send' direction,
it sends an UPDATE request (8) indicating so.
Camarillo, et al. Expires September 10, 2010 [Page 6]
Internet-Draft Media State under Preconditions March 2010
SDP5:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
In its response to the UPDATE request (9), the UAS indicates that all
preconditions for both media streams are met.
SDP6
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.5
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
The UAS is configured to automatically accept changes in IP
addresses. Therefore, it starts using the new remote IP address for
the audio stream. In order to explicitly signal this at the SIP
level, the UAS sends an UPDATE request (10) removing the
preconditions from the audio stream. This indicates that the audio
stream is now in use.
SDP7
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.5
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
SDP8:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
When the callee finally accepts the addition of the video stream, the
UAS sends an UPDATE request (12) indicating that the video stream is
Camarillo, et al. Expires September 10, 2010 [Page 7]
Internet-Draft Media State under Preconditions March 2010
now in use.
SDP9
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.5
SDP10:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
4. Tradeoff between Being Bandwidth Efficient and Having Explicit
Signalling
In order to have explicit SIP signalling about the media-level state,
UAs need to perform more offer/answer exchanges. Those offer/answer
exchanges consume bandwidth. For instance, in the previous example,
the price to pay for having explicit SIP signalling was the last two
UPDATE transactions. UAs should consider this tradeoff when deciding
how to behave in a particular network setting.
5. Security Considerations
This document does not introduce any new security issues. Security
issues related to preconditions are discussed in RFC 3312 [RFC3312]
and RFC 4032 [RFC4032].
6. IANA Considerations
There are no IANA actions associated with this document.
7. Acknowledgements
Paul Kyzivat, Christer Holmberg, and Yang Gao provided useful ideas
on the topics discussed in this document.
8. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Camarillo, et al. Expires September 10, 2010 [Page 8]
Internet-Draft Media State under Preconditions March 2010
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session
Initiation Protocol (SIP) Preconditions Framework",
RFC 4032, March 2005.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Jouni Maenpaa
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Jouni.Maenpaa@ericsson.com
Gao Yang
ZTE
China
Email: gao.yang2@zte.com.cn
Camarillo, et al. Expires September 10, 2010 [Page 9]