idnits 2.17.1 draft-ietf-sipping-transc-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 379. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 21, 2005) is 6996 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) ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3351 (ref. '4') ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-transc-3pcc (ref. '7') == Outdated reference: A later version (-05) exists of draft-ietf-sipping-uri-list-conferencing-01 -- Possible downref: Normative reference to a draft: ref. '8' -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '9') (Obsoleted by RFC 4566) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: August 22, 2005 February 21, 2005 6 Conference Establishment Using Request-Contained Lists in the Session 7 Initiation Protocol (SIP) 8 draft-ietf-sipping-transc-framework-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document defines a framework for transcoding with SIP. This 44 framework includes how to discover the need of transcoding services 45 in a session and how to invoke those transcoding services. Two 46 models for transcoding services invocation are discussed: the 47 conference bridge model and the third party call control model. Both 48 models meet the requirements for SIP regarding transcoding services 49 invocation to support deaf, hard of hearing, and speech-impaired 50 individuals. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Discovery of the Need for Transcoding Services . . . . . . . . 3 56 3. Transcoding Services Invocation . . . . . . . . . . . . . . . 4 57 3.1 Third Party Call Control Transcoding Model . . . . . . . . 5 58 3.2 Conference Bridge Transcoding Model . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 64 7.2 Informational References . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . 10 68 1. Introduction 70 Two user agents involved in a SIP [2] dialog may find it impossible 71 to establish a media session due to a variety of incompatibilities. 72 Assuming that both user agents understand the same session 73 description format (e.g., SDP [9]), incompatibilities can be found at 74 the user agent level and at the user level. At the user agent level, 75 both terminals may not support any common codec or may not support 76 common media types (e.g., a text-only terminal and an audio-only 77 terminal). At the user level, a deaf person will not understand 78 anything said over an audio stream. 80 In order to make communications possible in the presence of 81 incompatibilities, user agents need to introduce intermediaries that 82 provide transcoding services to a session. From the SIP point of 83 view, the introduction of a transcoder is done in the same way to 84 resolve both user level and user agent level incompatibilities. So, 85 the invocation mechanisms described in this document are generally 86 applicable to any type of incompatibility related to how the 87 information that needs to be communicated is encoded. 89 Furthermore, although this framework focuses on transcoding, the 90 mechanisms described are applicable to media manipulation in 91 general. It would be possible to use them, for example, to invoke 92 a server that simply increased the volume of an audio stream. 94 This document does not describe media server discovery. That is an 95 orthogonal problem that one can address using user agent provisioning 96 or other methods. 98 The remainder of this document is organized as follows. Section 2 99 deals with the discovery of the need of transcoding services for a 100 particular session. Section 3 introduces the third party call 101 control and conference bridge transcoding invocation models, which 102 are further described in Section 3.1 and Section 3.2 respectively. 103 Both models meet the requirements regarding transcoding services 104 invocation in RFC3351 [4] to support deaf, hard of hearing and 105 speech-impaired individuals. 107 2. Discovery of the Need for Transcoding Services 109 According to the one-party consent model defined in RFC 3238 [1] , 110 services that involve media manipulation invocation are best invoked 111 by one of the end-points involved in the communication, as opposed to 112 being invoked by an intermediary in the network. Following this 113 principle, one of the end-points should be the one detecting that 114 transcoding is needed for a particular session. 116 In order to decide whether or not transcoding is needed, a user agent 117 needs to know the capabilities of the remote user agent. A user 118 agent acting as an offerer typically obtains this knowledge by 119 downloading a presence document that includes media capabilities 120 (e.g., Bob is available on a terminal that only supports audio) or by 121 getting an SDP description of media capabilities as defined in RFC 122 3264 [3]. 124 Presence documents are typically received in a NOTIFY request as a 125 result of a subscription. SDP media capabilities descriptions are 126 typically received in a 200 (OK) response to an OPTIONS request or in 127 a 488 (Not Acceptable Here) response to an INVITE. 129 It is recommended that an offerer does not invoke transcoding 130 services before making sure that the answerer does not support the 131 capabilities needed for the session. Making wrong assumptions about 132 the answerer's capabilities can lead to situations where two 133 transcoders are introduced (one by the offerer and one by the 134 answerer) in a session that would not need any transcoding services 135 at all. 137 An example of the situation above is a call between two GSM phones 138 (without using transcoding-free operation). Both phones use a GSM 139 codec, but the speech is converted from GSM to PCM by the 140 originating MSC and from PCM back to GSM by the terminating MSC. 142 Note that transcoding services can be symmetric (e.g., speech-to-text 143 plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text 144 transcoding for a hearing impaired user that can talk). 146 3. Transcoding Services Invocation 148 Once the need for transcoding for a particular session has been 149 identified as described in Section 2, one of the user agents needs to 150 invoke transcoding services. 152 As we said earlier, transcoder location is outside the scope of this 153 document. So, we assume that the user agent invoking transcoding 154 services knows the URI of a server that provides them. 156 Invoking transcoding services from a server (T) for a session between 157 two user agents (A and B) involves establishing two media sessions; 158 one between A and T and another between T and B. How to invoke T's 159 services (i.e., how to establish both A-T and T-B sessions) depends 160 on how we model the transcoding service. We have considered two 161 models for invoking a transcoding service. The first is to use third 162 party call control [5], also referred to as 3pcc. The second is to 163 use a (dial-in and dial-out) conference bridge that negotiates the 164 appropriate media parameters on each individual leg (i.e., A-T and 165 T-B). 167 Section 3.1 analyzes the applicability of the third party call 168 control model and Section 3.2 analyzes the applicability of the 169 conference bridge transcoding invocation model. 171 3.1 Third Party Call Control Transcoding Model 173 In the 3pcc transcoding model, defined in [7], the user agent 174 invoking the transcoding service has a signalling relationship with 175 the transcoder and another signalling relationship with the remote 176 user agent. There is no signalling relationship between the 177 transcoder and the remote user agent, as shown in Figure 1. 179 +-------+ 180 | | 181 | T |** 182 | | ** 183 +-------+ ** 184 ^ * ** 185 | * ** 186 | * ** 187 SIP * ** 188 | * ** 189 | * ** 190 v * ** 191 +-------+ +-------+ 192 | | | | 193 | A |<-----SIP----->| B | 194 | | | | 195 +-------+ +-------+ 197 <-SIP-> Signalling 198 ******* Media 200 Figure 1: Third party call control model 202 This model is suitable for advanced end points that are able to 203 perform third party call control. It allows end-points to invoke 204 transcoding services on a stream basis. That is, the media streams 205 that need transcoding are routed through the transcoder while the 206 streams that do not need it are sent directly between the end points. 207 This model also allows to invoke one transcoder for the sending 208 direction and a different one for the receiving direction of the same 209 stream. 211 Invoking a transcoder in the middle of an ongoing session is also 212 quite simple. This is useful when session changes occur (e.g., an 213 audio session is upgraded to an audio/video session) and the end- 214 points cannot cope with the changes (e.g., they had common audio 215 codecs but no common video codecs). 217 The privacy level that is achieved using 3pcc is high, since the 218 transcoder does no see the signalling between both end-points. In 219 this model, the transcoder only has access to the information that is 220 strictly needed to perform its function. 222 3.2 Conference Bridge Transcoding Model 224 OPEN ISSUE: this section outlines how to use the URI-list 225 mechanism for INVITEs specified in [8] to invoke a transcoder. 226 Some people think that having an even simpler mechanism to perform 227 transcoding invocation would be useful. We need to decide whether 228 we are happy with the current solution or we want to use a 229 different mechanism. 231 In a centralized conference, there are a number of media streams 232 between the conference server and each participant of a conference. 233 For a given media type (e.g., audio) the conference server sends, 234 over each individual stream, the media received over the rest of the 235 streams, typically performing some mixing. If the capabilities of 236 all the end-points participating in the conference are not the same, 237 the conference server may have to send audio to different 238 participants using different audio codecs. 240 Consequently, we can model a transcoding service as a two-party 241 conference server that may change not only the codec in use, but also 242 the format of the media (e.g., audio to text). 244 Using this model, T behaves as a B2BUA and the whole A-T-B session is 245 established as described in [draft-camarillo-sipping-transc-b2bua]. 246 Figure 2 shows the signalling relationships between the end-points 247 and the transcoder. 249 +-------+ 250 | |** 251 | T | ** 252 | |\ ** 253 +-------+ \\ ** 254 ^ * \\ ** 255 | * \\ ** 256 | * SIP ** 257 SIP * \\ ** 258 | * \\ ** 259 | * \\ ** 260 v * \ ** 261 +-------+ +-------+ 262 | | | | 263 | A | | B | 264 | | | | 265 +-------+ +-------+ 267 <-SIP-> Signalling 268 ******* Media 270 Figure 2: Conference bridge model 272 In the conferencing bridge model, the end-point invoking the 273 transcoder is generally involved in less signalling exchanges than in 274 the 3pcc model. This may be an important feature for end-poing using 275 low bandwidth or high-delay access links (e.g., some wireless 276 accesses). 278 On the other hand, this model is less flexible than the 3pcc model. 279 It is not possible to use different transcoders for different streams 280 or for different directions of a stream. 282 Invoking a transcoder in the middle of an ongoing session or changing 283 from one transcoder to another requires the remote end-point to 284 support the Replaces [6] extension. At present, not many user agents 285 support it. 287 Simple end-points that cannot perform 3pcc and thus cannot use the 288 3pcc model, of course, need to use the conference bridge model. 290 4. Security Considerations 292 TBD. 294 5. IANA Considerations 296 This document does not contain any IANA actions. 298 6. Contributors 300 This document is the result of discussions amongst the conferencing 301 design team. The members of this team include Eric Burger, Henning 302 Schulzrinne and Arnoud van Wijk. 304 7. References 306 7.1 Normative References 308 [1] Floyd, S. and L. Daigle, "IAB Architectural and Policy 309 Considerations for Open Pluggable Edge Services", RFC 3238, 310 January 2002. 312 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 313 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 314 Session Initiation Protocol", RFC 3261, June 2002. 316 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 317 Session Description Protocol (SDP)", RFC 3264, June 2002. 319 [4] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van 320 Wijk, "User Requirements for the Session Initiation Protocol 321 (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired 322 Individuals", RFC 3351, August 2002. 324 [5] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 325 "Best Current Practices for Third Party Call Control (3pcc) in 326 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 327 2004. 329 [6] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation 330 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 332 [7] Camarillo, G., "Transcoding Services Invocation in the Session 333 Initiation Protocol (SIP) Using Third Party Call Control 334 (3pcc)", draft-ietf-sipping-transc-3pcc-02 (work in progress), 335 September 2004. 337 [8] Camarillo, G. and A. Johnston, "Conference Establishment Using 338 Request-Contained Lists in the Session Initiation Protocol 339 (SIP)", draft-ietf-sipping-uri-list-conferencing-01 (work in 340 progress), October 2004. 342 7.2 Informational References 344 [9] Handley, M. and V. Jacobson, "SDP: Session Description 345 Protocol", RFC 2327, April 1998. 347 Author's Address 349 Gonzalo Camarillo 350 Ericsson 351 Hirsalantie 11 352 Jorvas 02420 353 Finland 355 EMail: Gonzalo.Camarillo@ericsson.com 357 Intellectual Property Statement 359 The IETF takes no position regarding the validity or scope of any 360 Intellectual Property Rights or other rights that might be claimed to 361 pertain to the implementation or use of the technology described in 362 this document or the extent to which any license under such rights 363 might or might not be available; nor does it represent that it has 364 made any independent effort to identify any such rights. Information 365 on the procedures with respect to rights in RFC documents can be 366 found in BCP 78 and BCP 79. 368 Copies of IPR disclosures made to the IETF Secretariat and any 369 assurances of licenses to be made available, or the result of an 370 attempt made to obtain a general license or permission for the use of 371 such proprietary rights by implementers or users of this 372 specification can be obtained from the IETF on-line IPR repository at 373 http://www.ietf.org/ipr. 375 The IETF invites any interested party to bring to its attention any 376 copyrights, patents or patent applications, or other proprietary 377 rights that may cover technology that may be required to implement 378 this standard. Please address the information to the IETF at 379 ietf-ipr@ietf.org. 381 Disclaimer of Validity 383 This document and the information contained herein are provided on an 384 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 385 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 386 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 387 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 388 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 389 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 391 Copyright Statement 393 Copyright (C) The Internet Society (2005). This document is subject 394 to the rights, licenses and restrictions contained in BCP 78, and 395 except as set forth therein, the authors retain all their rights. 397 Acknowledgment 399 Funding for the RFC Editor function is currently provided by the 400 Internet Society.