draft-ietf-sipping-transc-framework-03.txt   draft-ietf-sipping-transc-framework-04.txt 
SIPPING Working Group G. Camarillo SIPPING Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: May 30, 2006 November 26, 2005 Expires: November 19, 2006 May 18, 2006
Framework for Transcoding with the Session Initiation Protocol (SIP) Framework for Transcoding with the Session Initiation Protocol (SIP)
draft-ietf-sipping-transc-framework-03.txt draft-ietf-sipping-transc-framework-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 32
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2006. This Internet-Draft will expire on November 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines a framework for transcoding with SIP. This This document defines a framework for transcoding with SIP. This
framework includes how to discover the need of transcoding services framework includes how to discover the need for transcoding services
in a session and how to invoke those transcoding services. Two in a session and how to invoke those transcoding services. Two
models for transcoding services invocation are discussed: the models for transcoding services invocation are discussed: the
conference bridge model and the third party call control model. Both conference bridge model and the third party call control model. Both
models meet the requirements for SIP regarding transcoding services models meet the requirements for SIP regarding transcoding services
invocation to support deaf, hard of hearing, and speech-impaired invocation to support deaf, hard of hearing, and speech-impaired
individuals. individuals.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discovery of the Need for Transcoding Services . . . . . . . . 3 2. Discovery of the Need for Transcoding Services . . . . . . . . 3
3. Transcoding Services Invocation . . . . . . . . . . . . . . . 4 3. Transcoding Services Invocation . . . . . . . . . . . . . . . 4
3.1. Third Party Call Control Transcoding Model . . . . . . . . 5 3.1. Third Party Call Control Transcoding Model . . . . . . . . 5
3.2. Conference Bridge Transcoding Model . . . . . . . . . . . 6 3.2. Conference Bridge Transcoding Model . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informational References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
Two user agents involved in a SIP [3] dialog may find it impossible Two user agents involved in a SIP [3] dialog may find it impossible
to establish a media session due to a variety of incompatibilities. to establish a media session due to a variety of incompatibilities.
Assuming that both user agents understand the same session Assuming that both user agents understand the same session
description format (e.g., SDP [12]), incompatibilities can be found description format (e.g., SDP [12]), incompatibilities can be found
at the user agent level and at the user level. At the user agent at the user agent level and at the user level. At the user agent
skipping to change at page 3, line 36 skipping to change at page 3, line 36
Furthermore, although this framework focuses on transcoding, the Furthermore, although this framework focuses on transcoding, the
mechanisms described are applicable to media manipulation in mechanisms described are applicable to media manipulation in
general. It would be possible to use them, for example, to invoke general. It would be possible to use them, for example, to invoke
a server that simply increased the volume of an audio stream. a server that simply increased the volume of an audio stream.
This document does not describe media server discovery. That is an This document does not describe media server discovery. That is an
orthogonal problem that one can address using user agent provisioning orthogonal problem that one can address using user agent provisioning
or other methods. or other methods.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
deals with the discovery of the need of transcoding services for a deals with the discovery of the need for transcoding services for a
particular session. Section 3 introduces the third party call particular session. Section 3 introduces the third party call
control and conference bridge transcoding invocation models, which control and conference bridge transcoding invocation models, which
are further described in Section 3.1 and Section 3.2 respectively. are further described in Section 3.1 and Section 3.2 respectively.
Both models meet the requirements regarding transcoding services Both models meet the requirements regarding transcoding services
invocation in RFC3351 [6] to support deaf, hard of hearing, and invocation in RFC3351 [6] to support deaf, hard of hearing, and
speech-impaired individuals. speech-impaired individuals.
2. Discovery of the Need for Transcoding Services 2. Discovery of the Need for Transcoding Services
According to the one-party consent model defined in RFC 3238 [2], According to the one-party consent model defined in RFC 3238 [2],
skipping to change at page 4, line 29 skipping to change at page 4, line 29
services before making sure that the answerer does not support the services before making sure that the answerer does not support the
capabilities needed for the session. Making wrong assumptions about capabilities needed for the session. Making wrong assumptions about
the answerer's capabilities can lead to situations where two the answerer's capabilities can lead to situations where two
transcoders are introduced (one by the offerer and one by the transcoders are introduced (one by the offerer and one by the
answerer) in a session that would not need any transcoding services answerer) in a session that would not need any transcoding services
at all. at all.
An example of the situation above is a call between two GSM phones An example of the situation above is a call between two GSM phones
(without using transcoding-free operation). Both phones use a GSM (without using transcoding-free operation). Both phones use a GSM
codec, but the speech is converted from GSM to PCM by the codec, but the speech is converted from GSM to PCM by the
originating MSC and from PCM back to GSM by the terminating MSC. originating MSC (Mobile Switching Center) and from PCM back to GSM
by the terminating MSC.
Note that transcoding services can be symmetric (e.g., speech-to-text Note that transcoding services can be symmetric (e.g., speech-to-text
plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text
transcoding for a hearing-impaired user that can talk). transcoding for a hearing-impaired user that can talk).
3. Transcoding Services Invocation 3. Transcoding Services Invocation
Once the need for transcoding for a particular session has been Once the need for transcoding for a particular session has been
identified as described in Section 2, one of the user agents needs to identified as described in Section 2, one of the user agents needs to
invoke transcoding services. invoke transcoding services.
skipping to change at page 6, line 13 skipping to change at page 6, line 14
direction and a different one for the receiving direction of the same direction and a different one for the receiving direction of the same
stream. stream.
Invoking a transcoder in the middle of an ongoing session is also Invoking a transcoder in the middle of an ongoing session is also
quite simple. This is useful when session changes occur (e.g., an quite simple. This is useful when session changes occur (e.g., an
audio session is upgraded to an audio/video session) and the end- audio session is upgraded to an audio/video session) and the end-
points cannot cope with the changes (e.g., they had common audio points cannot cope with the changes (e.g., they had common audio
codecs but no common video codecs). codecs but no common video codecs).
The privacy level that is achieved using 3pcc is high, since the The privacy level that is achieved using 3pcc is high, since the
transcoder does no see the signalling between both end-points. In transcoder does not see the signalling between both end-points. In
this model, the transcoder only has access to the information that is this model, the transcoder only has access to the information that is
strictly needed to perform its function. strictly needed to perform its function.
3.2. Conference Bridge Transcoding Model 3.2. Conference Bridge Transcoding Model
In a centralized conference, there are a number of media streams In a centralized conference, there are a number of media streams
between the conference server and each participant of a conference. between the conference server and each participant of a conference.
For a given media type (e.g., audio) the conference server sends, For a given media type (e.g., audio) the conference server sends,
over each individual stream, the media received over the rest of the over each individual stream, the media received over the rest of the
streams, typically performing some mixing. If the capabilities of streams, typically performing some mixing. If the capabilities of
skipping to change at page 8, line 7 skipping to change at page 8, line 7
3pcc model, of course, need to use the conference bridge model. 3pcc model, of course, need to use the conference bridge model.
4. Security Considerations 4. Security Considerations
The specifications of the 3pcc and the conferencing transcoding The specifications of the 3pcc and the conferencing transcoding
models discuss security issues directly related to the implementation models discuss security issues directly related to the implementation
of those models. Additionally, there are some considerations that of those models. Additionally, there are some considerations that
apply to transcoding in general. apply to transcoding in general.
In a session, a transcoder has access to at least some of the media In a session, a transcoder has access to at least some of the media
exchanged between the end points. In order to avoid rogue exchanged between the endpoints. In order to avoid rogue transcoders
transcoders getting access to those media, it is recommended that end getting access to those media, it is recommended that endpoints
points authenticate the transcoder. TLS [1] and S/MIME [8] can be authenticate the transcoder. TLS [1] and S/MIME [8] can be used for
used for this purpose. this purpose.
To achieve a higher degree of privacy, end points following the 3pcc To achieve a higher degree of privacy, end points following the 3pcc
transcoding model can use one transcoder in one direction and a transcoding model can use one transcoder in one direction and a
different one in the other direction. This way, no single transcoder different one in the other direction. This way, no single transcoder
has access to all the media exchanged between the end points. has access to all the media exchanged between the end points.
The fact that transcoders need to access media exchanged between the
endpoints implies that endpoints cannot use end-to-end media security
mechanisms. Media encryption would not allow the transcoder to
access the media and media integrity protection would not allow the
transcoder to modify the media (which is obviously necessary to
perform the transcoding function). Nevertheless, endpoints can still
use media security between the transcoder and themselves.
5. IANA Considerations 5. IANA Considerations
This document does not contain any IANA actions. This document does not contain any IANA actions.
6. Contributors 6. Contributors
This document is the result of discussions amongst the conferencing This document is the result of discussions amongst the conferencing
design team. The members of this team include Eric Burger, Henning design team. The members of this team include Eric Burger, Henning
Schulzrinne and Arnoud van Wijk. Schulzrinne and Arnoud van Wijk.
skipping to change at page 9, line 27 skipping to change at page 9, line 35
[9] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [9] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[10] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, [10] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk,
"Transcoding Services Invocation in the Session Initiation "Transcoding Services Invocation in the Session Initiation
Protocol (SIP) Using Third Party Call Control (3pcc)", Protocol (SIP) Using Third Party Call Control (3pcc)",
RFC 4117, June 2005. RFC 4117, June 2005.
[11] Camarillo, G., "The Session Initiation Protocol (SIP) [11] Camarillo, G., "The Session Initiation Protocol (SIP)
Conference Bridge Transcoding Model", Conference Bridge Transcoding Model",
draft-ietf-sipping-transc-conf-00 (work in progress), draft-ietf-sipping-transc-conf-02 (work in progress),
June 2005. January 2006.
7.2. Informational References 7.2. Informative References
[12] Handley, M., "SDP: Session Description Protocol", [12] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005. draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
Author's Address Author's Address
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
skipping to change at page 11, line 41 skipping to change at page 11, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 16 change blocks. 
19 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/