idnits 2.17.1 draft-ietf-mmusic-fid-01.txt: -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '... the media agent MUST send media over ...' RFC 2119 keyword, line 246: '...he fid attribute MUST add it to any SD...' 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 (October 2001) is 8228 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 285 looks like a reference -- Missing reference section? '2' on line 288 looks like a reference -- Missing reference section? '3' on line 292 looks like a reference -- Missing reference section? '4' on line 295 looks like a reference -- Missing reference section? '5' on line 299 looks like a reference -- Missing reference section? '6' on line 303 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gonzalo Camarillo 3 Internet draft Jan Holler 4 Goran AP Eriksson 5 Ericsson 6 April 2001 7 Expires October 2001 8 10 The SDP fid attribute 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines an SDP media attribute. The use of this 34 attribute allows receiving media from a single flow (several media 35 streams), encoded in different formats during a particular session, 36 in different ports and host interfaces. 38 Camarillo/Holler/Eriksson 1 39 The SDP fid attribute 41 TABLE OF CONTENTS 43 1 Motivation...................................................2 44 1.1 SIP and cellular access......................................2 45 1.2 DTMF tones...................................................3 46 2 Media flow definition........................................3 47 3 Flow identification attribute................................3 48 4 Semantics of the fid attribute...............................4 49 4.1 Interactions with other media level attributes...............4 50 5 Usage of the fid attribute in SIP............................5 51 5.1 Backward compatibility.......................................5 52 5.2 Caller does not support fid..................................5 53 5.3 Callee does not support fid..................................5 54 6 Acknoledgements..............................................6 55 7 References...................................................6 56 8 Authors� Addresses...........................................6 58 1. Motivation 60 The RTSP RFC [1] defines a media stream as "a single media instance, 61 e.g., an audio stream or a video stream as well as a single 62 whiteboard or shared application group. When using RTP, a stream 63 consists of all RTP and RTCP packets created by a source within an 64 RTP session". 66 This definition assumes that a single audio (or video) stream maps 67 into an RTP session. The RTP RFC [2] defines an RTP session as 68 follows: "For each participant, the session is defined by a 69 particular pair of destination transport addresses (one network 70 address plus a port pair for RTP and RTCP)". 72 However, there are situations where a single media instance, (e.g., 73 an audio stream or a video stream) is sent using more than one RTP 74 session. Two examples (among many others) of this kind of situation 75 are cellular systems using SIP [3] and systems receiving DTMF tones 76 on a different host than the voice. 78 1.1 SIP and cellular access 80 Systems using a cellular access and SIP as a signalling protocol 81 need to receive media over the air. During a session the media can 82 be encoded using different codecs. The encoded media has to traverse 83 the radio interface. The radio interface is generally characterized 84 by being bit error prone and associated with relatively high packet 85 transfer delays. In addition, radio interface resources in a 86 cellular environment are scarce and thus expensive, which calls for 87 special measures in providing a highly efficient transport [4]. In 88 order to get an appropriate speech quality in combination with an 89 efficient transport, precise knowledge of codec properties are 90 required so that a proper radio bearer for the RTP session can be 92 Camarillo/Holler/Eriksson 2 93 The SDP fid attribute 95 configured before transferring the media. These radio bearers are 96 dedicated bearers per media type, i.e. codec. 98 Cellular systems typically configure different radio bearers on 99 different port numbers. Therefore, incoming media has to have 100 different destination port numbers for the different possible codecs 101 in order to be routed properly to the correct radio bearer. Thus, 102 this is an example in which several RTP sessions are used to carry a 103 single media instance (the encoded speech from the sender). 105 1.2 DTMF tones 107 Some voice sessions include DTMF tones. Sometimes the voice handling 108 is performed by a different host than the DTMF handling. [5] 109 contains several examples of how application servers in the network 110 gather DTMF tones for the user while the user receives the encoded 111 speech on his user agent. In this situations it is necessary to 112 establish two RTP sessions: one for the voice and the other for the 113 DTMF tones. Both RTP sessions are logically part of the same media 114 instance. 116 2. Media flow definition 118 The previous examples show that the definition of a media stream in 119 [1] has to be updated. It cannot be assumed that a single media 120 instance maps into a single RTP session. Therefore, we introduce the 121 definition of a media flow: 123 Media flow consists of a single media instance, e.g., an audio 124 stream or a video stream as well as a single whiteboard or shared 125 application group. When using RTP, a media flow comprises one or 126 more RTP sessions. 128 For instance, in a two party call where the voice exchanged can be 129 encoded using GSM or PCM, the receiver wants to receive GSM on a 130 port number and PCM on a different port number. Two RTP sessions 131 will be established, one carrying GSM and the other carrying PCM. 133 At any particular moment just one codec is in use. Therefore, at any 134 moment one of the RTP sessions will not transport any voice. Here 135 the systems are dealing with a single media flow, but two RTP 136 sessions. 138 3. Flow identification attribute 140 An RTP session is described in SDP [6] using an "m" line. When a 141 media flow comprises more than one RTP session, we need a way to 142 associate several "m" lines together into a media flow. 144 A new "flow identification" media attribute is defined. It is used 145 for identifying media flows within a session. Its formatting in SDP 146 is described by the following BNF: 148 Camarillo/Holler/Eriksson 3 149 The SDP fid attribute 151 fid-attribute = "a=fid:" identification-tag 152 identification-tag = token 154 The identification tag is unique within the SDP session description. 156 Syntactically fid is a media-level attribute. It provides 157 information about a media stream defined by an "m" line. 158 Semantically fid would be defined as a session-level attribute since 159 it provides flow hierarchy inside a session description. 161 4. Semantics of the fid attribute 163 A media agent handling a media flow that comprises several "m" lines 164 sends media to different destinations (IP address/port number) 165 depending on the codec used at any moment. If several "m" lines 166 contain the codec used media is sent to different destinations in 167 parallel. 169 For instance, a SIP user agent receives an INVITE with the following 170 body: 172 v=0 173 o=Laura 289083124 289083124 IN IP4 second.example.com 174 t=0 0 175 c=IN IP4 131.160.1.112 176 m=audio 30000 RTP/AVP 0 177 a=fid:1 178 m=audio 30002 RTP/AVP 8 179 a=fid:1 180 m=audio 30004 RTP/AVP 0 8 181 a=fid:1 183 At a particular point of time, if the media agent is sending PCM u- 184 law (payload 0) it sends RTP packets to ports 30000 and 30004 (first 185 and third "m" lines). If it is sending PCM A-law (payload 8) it 186 sends RTP packets to ports 30002 and 30004 (second and third "m" 187 lines). 189 Note that if several "m" lines with the same fid value contain the 190 same codec the media agent MUST send media over several RTP sessions 191 at the same time. 193 4.1 Interactions with other media level attributes 195 Media level attributes affect a media stream defined by an "m" line. 196 The presence of fid does not modify this behavior. 198 For instance, a SIP user agent receives an INVITE with the following 199 body: 201 v=0 202 o=Laura 289083124 289083124 IN IP4 second.example.com 203 t=0 0 205 Camarillo/Holler/Eriksson 4 206 The SDP fid attribute 208 c=IN IP4 131.160.1.112 209 m=audio 30000 RTP/AVP 0 210 a=fid:1 211 m=audio 30002 RTP/AVP 8 212 a=recvonly 213 a=fid:1 215 The media agent knows that at a certain moment it can send either 216 PCM u-law to port number 30000 or PCM A-law to port number 30002. 217 However, the media agent also knows that the other end will only 218 send PCM u-law (payload 0). 220 Note that the fid attribute allows to express uni-directional codecs 221 for a bi-directional media flow, as it is shown in the example 222 above. 224 5. Usage of the fid attribute in SIP 226 SIP [3] is an application layer protocol for establishing, 227 terminating and modifying multimedia sessions. SIP carries session 228 descriptions in the bodies of the SIP messages but is independent 229 from the protocol used for describing sessions. SDP [6] is one of 230 the protocols that can be used for this purpose. 232 Appendix B of [3] describes the usage of SDP in relation to SIP. It 233 states: "The caller and callee align their media description so that 234 the nth media stream ("m=" line) in the caller�s session description 235 corresponds to the nth media stream in the callee�s description." 237 The presence of the fid attribute in an SDP session description does 238 not modify this behavior. 240 5.1 Backward compatibility 242 This document does not define any SIP "Require" header. Therefore, 243 if one of the SIP user agents does not understand the fid attribute 244 the standard SDP fall back mechanism is used. 246 A system that understands the fid attribute MUST add it to any SDP 247 session description that it generates. 249 5.2 Caller does not support fid 251 This situation does not represent a problem. The SDP in the INVITE 252 will not contain any fid attribute. The callee knows that the caller 253 does not support fid. 255 5.3 Callee does not support fid 257 The callee will ignore the fid attribute, since it does not 258 understand it. It will consider that the session comprises several 259 media streams. 261 Camarillo/Holler/Eriksson 5 262 The SDP fid attribute 264 Different implementations would behave in different ways. 266 In the case of audio and different "m" lines for different codecs an 267 implementation might decide to act as a mixer with the different 268 incoming RTP sessions, which is the correct behavior. 270 An implementation might also decide to refuse the request (e.g. 488 271 Not acceptable here or 606 Not Acceptable) because it contains 272 several "m" lines. In this case, the callee does not support the 273 type of session that the caller wanted to establish. In case the 274 caller is willing to establish a simpler session anyway, he should 275 re-try the request without the fid attribute and only one "m" line 276 per flow. 278 6. Acknowledgments 280 The authors would like to thank Jonathan Rosenberg and Adam Roach 281 for their feedback on this document. 283 7. References 285 [1] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol 286 (RTSP)", RFC 2326, IETF; April 1998. 288 [2] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A 289 Transport Protocol for Real-Time Applications", RFC 1889, IETF; 290 January 1996. 292 [3] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 293 Session Initiation Protocol", RFC 2543, IETF; Mach 1999. 295 [4] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access 296 Networks", draft-westberg-realtime-cellular-03.txt, IETF; November 297 2000. Work in progress. 299 [5] J. Rosemberg/P.Mataga/H.Schulzrinne, "An Applcation Server 300 Component Architecture for SIP", draft-rosenberg-sip-app-components- 301 00.txt, IETF; November 2000. Work in progress. 303 [6] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC 304 2327, IETF; April 1998. 306 8. Authors� Addresses 308 Gonzalo Camarillo 309 Ericsson 310 Advanced Signalling Research Lab. 311 FIN-02420 Jorvas 312 Finland 313 Phone: +358 9 299 3371 314 Fax: +358 9 299 3052 315 Email: Gonzalo.Camarillo@ericsson.com 317 Camarillo/Holler/Eriksson 6 318 The SDP fid attribute 320 Jan Holler 321 Ericsson Research 322 S-16480 Stockholm 323 Sweden 324 Phone: +46 8 58532845 325 Fax: +46 8 4047020 326 Email: Jan.Holler@era.ericsson.se 328 Goran AP Eriksson 329 Ericsson Research 330 S-16480 Stockholm 331 Sweden 332 Phone: +46 8 58531762 333 Fax: +46 8 4047020 334 Email: Goran.AP.Eriksson@era.ericsson.se 336 Camarillo/Holler/Eriksson 7