Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
RFC 4117
Document | Type | RFC - Informational (June 2005; Errata) | |
---|---|---|---|
Authors | Henning Schulzrinne , Gonzalo Camarillo , Arnoud Van Wijk , Eric Burger | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4117 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | rohan@cisco.com, dean.willis@softarmor.com |
Network Working Group G. Camarillo Request for Comments: 4117 Ericsson Category: Informational E. Burger Brooktrout H. Schulzrinne Columbia University A. van Wijk Viataal June 2005 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. Table of Contents 1. Introduction ....................................................2 2. General Overview ................................................2 3. Third Party Call Control Flows ..................................2 3.1. Terminology ................................................3 3.2. Callee's Invocation ........................................3 3.3. Caller's Invocation ........................................8 3.4. Receiving the Original Stream ..............................8 3.5. Transcoding Services in Parallel ..........................10 3.6. Multiple Transcoding Services in Series ...................14 4. Security Considerations ........................................16 5. Normative References ...........................................17 6. Informative References .........................................17 Camarillo, et al. Informational [Page 1] RFC 4117 3pcc Transcoding in SIP June 2005 1. Introduction The framework for transcoding with SIP [4] describes how two SIP [1] UAs (User Agents) can discover incompatibilities that prevent them from establishing a session (e.g., lack of support for a common codec or common media type). When such incompatibilities are found, the UAs need to invoke transcoding services to successfully establish the session. 3pcc (third party call control) [2] is one way to perform such invocation. 2. General Overview In the 3pcc model for transcoding invocation, a transcoding server that provides a particular transcoding service (e.g., speech-to-text) is identified by a URI. A UA that wishes to invoke that service sends an INVITE request to that URI establishing a number of media streams. The way the transcoder manipulates and manages the contents of those media streams (e.g., the text received over the text stream is transformed into speech and sent over the audio stream) is service specific. All the call flows in this document use SDP. The same call flows could be used with another session description protocol that provides similar session description capabilities. 3. Third Party Call Control Flows Given two UAs (A and B) and a transcoding server (T), the invocation of a transcoding service consists of establishing two sessions; A-T and T-B. How these sessions are established depends on which party, the caller (A) or the callee (B), invokes the transcoding services. Section 3.2 deals with callee invocation and Section 3.3 deals with caller invocation. In all our 3pcc flows we have followed the general principle that a 200 (OK) response from the transcoding service has to be received before contacting the callee. This tries to ensure that the transcoding service will be available when the callee accepts the session. Still, the transcoding service does not know the exact type of transcoding it will be performing until the callee accepts the session. So, there is always the chance of failing to provide transcoding services after the callee has accepted the session. A system with more stringent requirements could use preconditions to avoid this situation. When preconditions are used, the callee is not alerted until everything is ready for the session. Camarillo, et al. Informational [Page 2] RFC 4117 3pcc Transcoding in SIP June 2005 3.1. Terminology All the flows in this document follow the naming convention below:Show full document text