idnits 2.17.1 draft-ietf-sipping-transc-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 6, 2004) is 7378 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 290 looks like a reference -- Missing reference section? '2' on line 295 looks like a reference -- Missing reference section? '3' on line 300 looks like a reference -- Missing reference section? '4' on line 304 looks like a reference -- Missing reference section? '5' on line 308 looks like a reference -- Missing reference section? '6' on line 313 looks like a reference -- Missing reference section? '7' on line 318 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo 4 Ericsson 5 draft-ietf-sipping-transc-framework-00.txt 6 February 6, 2004 7 Expires: August, 2004 9 Framework for Transcoding with the Session Initiation Protocol 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document defines a framework for transcoding with SIP. This 35 framework includes how to discover the need of transcoding services 36 in a session and how to invoke those transcoding services. Two models 37 for transcoding services invocation are discussed; the conference 38 bridge model and the third party call control model. Both models meet 39 the requirements for SIP regarding transcoding services invocation to 40 support deaf, hard of hearing and speech-impaired individuals. 42 Table of Contents 44 1 Introduction ........................................ 3 45 2 Discovery of the Need for Transcoding Services ...... 3 46 3 Transcoding Services Invocation ..................... 4 47 3.1 Third Party Call Control Transcoding Model .......... 5 48 3.2 Conference Bridge Transcoding Model ................. 5 49 4 Security Considerations ............................. 8 50 5 Contributors ........................................ 8 51 6 Authors' Addresses .................................. 8 52 7 Bibliography ........................................ 8 54 1 Introduction 56 Two user agents involved in a SIP [1] dialog may find it impossible 57 to establish a media session due to a variety of incompatibilities. 58 Assuming that both user agents understand the same session 59 description format (e.g., SDP), incompatibilities can be found at the 60 user agent level and at the user level. At the user agent level, both 61 terminals may not support any common codec or may not support common 62 media types (e.g., a text-only terminal and an audio-only terminal). 63 At the user level, a deaf person will not understand anything said 64 over an audio stream. 66 In order to make communications possible in the presence of 67 incompatibilities, user agents need to introduce intermediaries that 68 provide transcoding services to a session. From the SIP point of 69 view, the introduction of a transcoder is done in the same way to 70 resolve both user level and user agent level incompatibilities. So, 71 the invocation mechanisms described in this document are generally 72 applicable to any type of incompatibility related to how the 73 information that needs to be communicated is encoded. 75 Furthermore, although this framework focuses on 76 transcoding, the mechanisms described are applicable to 77 media manipulation in general. It would be possible to use 78 them, for example, to invoke a server that simply increased 79 the volume of an audio stream. 81 This document does not describe media server discovery. That is an 82 orthogonal problem that one can address using user agent provisioning 83 or other methods. 85 The remainder of this document is organized as follows. Section 2 86 deals with the discovery of the need of transcoding services for a 87 particular session. Section 3.2 introduces the conference bridge 88 transcoding invocation model, and Section 3.1 introduces the third 89 party call control model. Both models meet the requirements regarding 90 transcoding services invocation in RFC3351 [2] to support deaf, hard 91 of hearing and speech-impaired individuals. 93 2 Discovery of the Need for Transcoding Services 95 According to the one-party consent model defined in RFC 3238 [3], 96 services that involve media manipulation invocation are best invoked 97 by one of the end-points involved in the communication, as opposed to 98 being invoked by an intermediary in the network. Following this 99 principle, one of the end-points should be the one detecting that 100 transcoding is needed for a particular session. 102 In order to decide whether or not transcoding is needed, a user agent 103 needs to know the capabilities of the remote user agent. A user agent 104 acting as an offerer typically obtains this knowledge by downloading 105 a presence document that includes media capabilities (e.g., Bob is 106 available on a terminal that only supports audio) or by getting an 107 SDP description of media capabilities as defined in RFC 3264 [4]. 109 Presence documents are typically received in a NOTIFY request as a 110 result of a subscription. SDP media capabilities descriptions are 111 typically received in a 200 (OK) response to an OPTIONS request or in 112 a 488 (Not Acceptable Here) response to an INVITE. 114 It is recommended that an offerer does not invoke transcoding 115 services before making sure that the answerer does not support the 116 capabilities needed for the session. Making wrong assumptions about 117 the answerer's capabilities can lead to situations where two 118 transcoders are introduced (one by the offerer and one by the 119 answerer) in a session that would not need any transcoding services 120 at all. 122 An example of the situation above is a call between two GSM 123 phones (without using transcoding-free operation). Both 124 phones use a GSM codec, but the speech is converted from 125 GSM to PCM by the originating MSC and from PCM back to GSM 126 by the terminating MSC. 128 Note that transcoding services can be symmetric (e.g., speech-to-text 129 plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text 130 transcoding for a hearing impaired user that can talk). 132 3 Transcoding Services Invocation 134 Once the need for transcoding for a particular session has been 135 identified as described in Section 2, one of the user agents needs to 136 invoke transcoding services. 138 As we said earlier, transcoder location is outside the scope of this 139 document. So, we assume that the user agent invoking transcoding 140 services knows the URI of a server that provides them. 142 Invoking transcoding services from a server (T) for a session between 143 two user agents (A and B) involves establishing two media sessions; 144 one between A and T and another between T and B. How to invoke T's 145 services (i.e., how to establish both A-T and T-B sessions) depends 146 on how we model the transcoding service. We have considered two 147 models for invoking a transcoding service. The first is to use third 148 party call control [5], also referred to as 3pcc. The second is to 149 use a (dial-in and dial-out) conference bridge that negotiates the 150 appropriate media parameters on each individual leg (i.e., A-T and 151 T-B). 153 Section 3.1 analyzes the applicability of the third party call 154 control model and Section 3.2 analyzes the applicability of the 155 conference bridge transcoding invocation model. 157 3.1 Third Party Call Control Transcoding Model 159 In the 3pcc transcoding model, defined in (draft-ietf-sipping- 160 transc-3pcc), the user agent invoking the transcoding service has a 161 signalling relationship with the transcoder and another signalling 162 relationship with the remote user agent. There is no signalling 163 relationship between the transcoder and the remote user agent, as 164 shown in Figure 1. 166 This model is suitable for advanced end points that are able to 167 perform third party call control. It allows end-points to invoke 168 transcoding services on a stream basis. That is, the media streams 169 that need transcoding are routed through the transcoder while the 170 streams that do not need it are sent directly between the end points. 171 This model also allows to invoke one transcoder for the sending 172 direction and a different one for the receiving direction of the same 173 stream. 175 Invoking a transcoder in the middle of an ongoing session is also 176 quite simple. This is useful when session changes occur (e.g., an 177 audio session is upgraded to an audio/video session) and the end- 178 points cannot cope with the changes (e.g., they had common audio 179 codecs but no common video codecs). 181 The privacy level that is achieved using 3pcc is high, since the 182 transcoder does no see the signalling between both end-points. In 183 this model, the transcoder only has access to the information that is 184 strictly needed to perform its function. 186 3.2 Conference Bridge Transcoding Model 188 In a centralized conference, there are a number of media streams 189 between the conference server and each participant of a conference. 190 For a given media type (e.g., audio) the conference server sends, 191 over each individual stream, the media received over the rest of the 192 streams, typically performing some mixing. If the capabilities of all 193 the end-points participating in the conference are not the same, the 194 conference server may have to send audio to different participants 195 using different audio codecs. 197 +-------+ 198 | | 199 | T |** 200 | | ** 201 +-------+ ** 202 ^ * ** 203 | * ** 204 | * ** 205 SIP * ** 206 | * ** 207 | * ** 208 v * ** 209 +-------+ +-------+ 210 | | | | 211 | A |<-----SIP----->| B | 212 | | | | 213 +-------+ +-------+ 215 <-SIP-> Signalling 216 ******* Media 218 Figure 1: Third Party Call Control Model 220 Consequently, we can model a transcoding service as a two-party 221 conference server that may change not only the codec in use, but also 222 the format of the media (e.g., audio to text). 224 Using this model, T behaves as a B2BUA and the whole A-T-B session is 225 established as described in [6]. Figure 2 shows the signalling 226 relationships between the end-points and the transcoder. 228 In the conferencing bridge model, the end-point invoking the 229 transcoder is generally involved in less signalling exchanges than in 230 the 3pcc model. This may be an important feature for end-poing using 231 low bandwidth or high-delay access links (e.g., some wireless 232 +-------+ 233 | |** 234 | T | ** 235 | |\ ** 236 +-------+ \\ ** 237 ^ * \\ ** 238 | * \\ ** 239 | * SIP ** 240 SIP * \\ ** 241 | * \\ ** 242 | * \\ ** 243 v * \ ** 244 +-------+ +-------+ 245 | | | | 246 | A | | B | 247 | | | | 248 +-------+ +-------+ 250 <-SIP-> Signalling 251 ******* Media 253 Figure 2: Conference Bridge Control Model 255 accesses). 257 On the other hand, this model is less flexible than the 3pcc model. 258 It is not possible to use different transcoders for different streams 259 or for different directions of a stream. 261 Invoking a transcoder in the middle of an ongoing session or changing 262 from one transcoder to another requires the remote end-point to 263 support the Replaces [7] extension. At present, not many user agents 264 support it. 266 Simple end-points that cannot perform 3pcc and thus cannot use the 267 3pcc model, of course, need to use the conference bridge model. 269 4 Security Considerations 271 This document does not introduce any new security considerations. 273 5 Contributors 275 This document is the result of discussions amongst the conferencing 276 design team. The members of this team include Eric Burger, Henning 277 Schulzrinne and Arnoud van Wijk. 279 6 Authors' Addresses 281 Gonzalo Camarillo 282 Ericsson 283 Advanced Signalling Research Lab. 284 FIN-02420 Jorvas 285 Finland 286 electronic mail: Gonzalo.Camarillo@ericsson.com 288 7 Bibliography 290 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 291 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 292 initiation protocol," RFC 3261, Internet Engineering Task Force, June 293 2002. 295 [2] N. Charlton, M. Gasson, G. Gybels, M. Spanner, and A. van Wijk, 296 "User requirements for the session initiation protocol (SIP) in 297 support of deaf, hard of hearing and speech-impaired individuals," 298 RFC 3351, Internet Engineering Task Force, Aug. 2002. 300 [3] S. Floyd and L. Daigle, "IAB architectural and policy 301 considerations for open pluggable edge services," RFC 3238, Internet 302 Engineering Task Force, Jan. 2002. 304 [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 305 session description protocol (SDP)," RFC 3264, Internet Engineering 306 Task Force, June 2002. 308 [5] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, 309 "Best current practices for third party call control in the session 310 initiation protocol," Internet Draft draft-ietf-sipping-3pcc-06, 311 Internet Engineering Task Force, Jan. 2004. Work in progress. 313 [6] G. Camarillo, "The session initiation protocol conference bridge 314 transcoding model," Internet Draft draft-camarillo-sipping-transc- 315 b2bua-00, Internet Engineering Task Force, Aug. 2003. Work in 316 progress. 318 [7] B. Biggs, R. W. Dean, and R. Mahy, "The session inititation 319 protocol (SIP) Engineering Task Force, Aug. 2003. Work in progress. 321 The IETF takes no position regarding the validity or scope of any 322 intellectual property or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; neither does it represent that it 326 has made any effort to identify any such rights. Information on the 327 IETF's procedures with respect to rights in standards-track and 328 standards-related documentation can be found in BCP-11. Copies of 329 claims of rights made available for publication and any assurances of 330 licenses to be made available, or the result of an attempt made to 331 obtain a general license or permission for the use of such 332 proprietary rights by implementors or users of this specification can 333 be obtained from the IETF Secretariat. 335 The IETF invites any interested party to bring to its attention any 336 copyrights, patents or patent applications, or other proprietary 337 rights which may cover technology that may be required to practice 338 this standard. Please address the information to the IETF Executive 339 Director. 341 Full Copyright Statement 343 Copyright (c) The Internet Society (2004). All Rights Reserved. 345 This document and translations of it may be copied and furnished to 346 others, and derivative works that comment on or otherwise explain it 347 or assist in its implementation may be prepared, copied, published 348 and distributed, in whole or in part, without restriction of any 349 kind, provided that the above copyright notice and this paragraph are 350 included on all such copies and derivative works. However, this 351 document itself may not be modified in any way, such as by removing 352 the copyright notice or references to the Internet Society or other 353 Internet organizations, except as needed for the purpose of 354 developing Internet standards in which case the procedures for 355 copyrights defined in the Internet Standards process must be 356 followed, or as required to translate it into languages other than 357 English. 359 The limited permissions granted above are perpetual and will not be 360 revoked by the Internet Society or its successors or assigns. 362 This document and the information contained herein is provided on an 363 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 364 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 365 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 366 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 367 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.