idnits 2.17.1 draft-ietf-mmusic-fid-03.txt: -(427): 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 12 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 83: '...entification tag MUST be unique within...' RFC 2119 keyword, line 104: '... RECOMMENDED to use other session de...' RFC 2119 keyword, line 107: '... There MAY be several "a=group" line...' RFC 2119 keyword, line 110: '...sion description MUST be simply ignore...' RFC 2119 keyword, line 116: '... semantics MUST be synchronized. Syn...' (9 more instances...) 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 (January 2002) is 8130 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 574 looks like a reference -- Missing reference section? '2' on line 577 looks like a reference -- Missing reference section? '3' on line 580 looks like a reference -- Missing reference section? '4' on line 584 looks like a reference -- Missing reference section? '5' on line 590 looks like a reference -- Missing reference section? '6' on line 594 looks like a reference -- Missing reference section? '7' on line 597 looks like a reference -- Missing reference section? '8' on line 601 looks like a reference -- Missing reference section? '9' on line 605 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 11 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 July 2001 7 Expires January 2002 8 10 Grouping of media lines in SDP 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 two SDP attributes: "group" and "mid". They 34 allow to group together several "m" lines for two different 35 purposes: for lip synchronization and for receiving media from a 36 single flow (several media streams), encoded in different formats 37 during a particular session, in different ports and host interfaces. 39 Camarillo/Holler/Eriksson 1 40 Grouping of media lines in SDP 42 TABLE OF CONTENTS 44 1 Terminology................................................2 45 2 Media stream identification attribute......................2 46 3 Group attribute............................................2 47 4 Lip Synchronization (LS)...................................3 48 5 Flow Identification (FID)..................................3 49 5.1 SIP and cellular access....................................4 50 5.2 DTMF tones.................................................4 51 5.3 Media flow definition......................................5 52 5.4 FID semantics..............................................5 53 5.4.1 Interactions of "group" with other media level attributes..6 54 5.4.2 Media in parallel..........................................7 55 5.4.3 DTMF tones encoded as telephony events.....................8 56 6 Usage of the "group" attribute in SIP......................8 57 6.1 Media alignment............................................9 58 6.2 Mid value in responses.....................................9 59 6.3 Group value in responses...................................9 60 6.4 Backward compatibility....................................10 61 6.4.1 Client does not support "group"...........................11 62 6.4.2 Server does not support "group"...........................11 63 7 Acknoledgements...........................................11 64 8 References................................................11 65 9 Authors� Addresses........................................12 67 1 Terminology 69 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 70 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 71 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] 72 and indicate requirement levels for compliant implementations. 74 2. Media stream identification attribute 76 A new "media stream identification" media attribute is defined. It 77 is used for identifying media streams within a session description. 78 Its formatting in SDP [2] is described by the following BNF: 80 mid-attribute = "a=mid:" identification-tag 81 identification-tag = token 83 The identification tag MUST be unique within the SDP session 84 description. 86 3. Group attribute 88 A new "group" session level attribute is defined. It is used for 89 grouping together different media streams. Its formatting in SDP is 90 described by the following BNF: 92 Camarillo/Holler/Eriksson 2 93 Grouping of media lines in SDP 95 group-attribute = "a=group:" semantics 96 2*(space identification-tag) 97 semantics = "LS" | "FID" 99 This document defines two standard semantics: LS (Lip 100 Synchronization) and FID (Flow Identification). If in the future it 101 was needed to standardize further semantics they would need to be 102 defined in a standards track document. However, defining new 103 semantics apart from LS and FID is discouraged. Instead, it is 104 RECOMMENDED to use other session description mechanisms such as 105 SDPng [3]. 107 There MAY be several "a=group" lines in a session description. 109 "a=group" lines that contain identification-tags that are not 110 present in the session description MUST be simply ignored. The 111 application acts as if the "a=group" line did not exist. 113 4. Lip Synchronization (LS) 115 The play out of media streams that are grouped together using LS 116 semantics MUST be synchronized. Synchronization is typically 117 performed using RTCP, which provides enough information to map time 118 stamps from the different streams into a wall clock. 120 The following example shows a session description where the audio 121 and the video stream have to be synchronized. 123 v=0 124 o=Laura 289083124 289083124 IN IP4 first.example.com 125 t=0 0 126 c=IN IP4 131.160.1.112 127 a=group:LS 1 2 128 m=audio 30000 RTP/AVP 0 129 a=mid:1 130 m=video 30002 RTP/AVP 31 131 a=mid:2 132 m=audio 30004 RTP/AVP 0 133 a=mid:3 135 Note that although the third media stream is not present in the 136 group line it still contains an mid attribute (mid:3). All the "m" 137 lines of a session description that uses "group" MUST be identified 138 with an "mid" attribute regardless of whether they appear or not in 139 the group line(s). 141 5. Flow Identification (FID) 143 An "m" line in an SDP session description defines a media stream. 144 However, SDP does not define what a media stream is. To find the 146 Camarillo/Holler/Eriksson 3 147 Grouping of media lines in SDP 149 definition of a media stream we have to go to the RTSP 150 specification. The RTSP RFC [4] defines a media stream as "a single 151 media instance, e.g., an audio stream or a video stream as well as a 152 single whiteboard or shared application group. When using RTP, a 153 stream consists of all RTP and RTCP packets created by a source 154 within an RTP session". 156 This definition assumes that a single audio (or video) stream maps 157 into an RTP session. To find the definition of an RTP session we go 158 to the RTP specification. The RTP RFC [5] defines an RTP session as 159 follows: "For each participant, the session is defined by a 160 particular pair of destination transport addresses (one network 161 address plus a port pair for RTP and RTCP)". 163 While the previous definitions cover the most common cases, there 164 are situations where a single media instance, (e.g., an audio stream 165 or a video stream) is sent using more than one RTP session. Two 166 examples (among many others) of this kind of situation are cellular 167 systems using SIP [6] and systems receiving DTMF tones on a 168 different host than the voice. 170 5.1 SIP and cellular access 172 Systems using a cellular access and SIP as a signalling protocol 173 need to receive media over the air. During a session the media can 174 be encoded using different codecs. The encoded media has to traverse 175 the radio interface. The radio interface is generally characterized 176 by being bit error prone and associated with relatively high packet 177 transfer delays. In addition, radio interface resources in a 178 cellular environment are scarce and thus expensive, which calls for 179 special measures in providing a highly efficient transport [7]. In 180 order to get an appropriate speech quality in combination with an 181 efficient transport, precise knowledge of codec properties are 182 required so that a proper radio bearer for the RTP session can be 183 configured before transferring the media. These radio bearers are 184 dedicated bearers per media type, i.e. codec. 186 Cellular systems typically configure different radio bearers on 187 different port numbers. Therefore, incoming media has to have 188 different destination port numbers for the different possible codecs 189 in order to be routed properly to the correct radio bearer. Thus, 190 this is an example in which several RTP sessions are used to carry a 191 single media instance (the encoded speech from the sender). 193 5.2 DTMF tones 195 Some voice sessions include DTMF tones. Sometimes the voice handling 196 is performed by a different host than the DTMF handling. [8] 197 contains several examples of how application servers in the network 198 gather DTMF tones for the user while the user receives the encoded 199 speech on his user agent. In this situations it is necessary to 200 establish two RTP sessions: one for the voice and the other for the 202 Camarillo/Holler/Eriksson 4 203 Grouping of media lines in SDP 205 DTMF tones. Both RTP sessions are logically part of the same media 206 instance. 208 5.3 Media flow definition 210 The previous examples show that the definition of a media stream in 211 [4] do not cover some scenarios. It cannot be assumed that a single 212 media instance maps into a single RTP session. Therefore, we 213 introduce the definition of a media flow: 215 Media flow consists of a single media instance, e.g., an audio 216 stream or a video stream as well as a single whiteboard or shared 217 application group. When using RTP, a media flow comprises one or 218 more RTP sessions. 220 For instance, in a two party call where the voice exchanged can be 221 encoded using GSM or PCM, the receiver wants to receive GSM on a 222 port number and PCM on a different port number. Two RTP sessions 223 will be established, one carrying GSM and the other carrying PCM. 225 At any particular moment just one codec is in use. Therefore, at any 226 moment one of the RTP sessions will not transport any voice. Here 227 the systems are dealing with a single media flow, but two RTP 228 sessions. 230 5.4 FID semantics 232 Several "m" lines grouped together using FID semantics form a media 233 flow. A media agent handling a media flow that comprises several "m" 234 lines sends media to different destinations (IP address/port number) 235 depending on the codec used at any moment. 237 For instance, a SIP user agent receives an INVITE with the following 238 body: 240 v=0 241 o=Laura 289083124 289083124 IN IP4 second.example.com 242 t=0 0 243 c=IN IP4 131.160.1.112 244 a=group:FID 1 2 245 m=audio 30000 RTP/AVP 3 246 a=rtpmap:3 GSM/8000 247 a=mid:1 248 m=audio 30002 RTP/AVP 97 249 a=rtpmap:97 AMR/8000 250 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change- 251 neighbor; maxframes=1 252 a=mid:2 254 This would be the SDP sent by a terminal using a cellular access. 255 The terminal supports GSM on port 30000 and AMR on port 30002. When 256 the remote party sends GSM it will send RTP packets to port number 257 30000. When AMR is the codec chosen, packets will be sent to port 259 Camarillo/Holler/Eriksson 5 260 Grouping of media lines in SDP 262 30002. Note that the remote party can switch between both codecs 263 dynamically in the middle of the session. 265 In the previous example a system receives media on the same IP 266 address on different port numbers. The following example shows how a 267 system can receive different codecs on different IP addresses. 269 v=0 270 o=Laura 289083124 289083124 IN IP4 third.example.com 271 t=0 0 272 c=IN IP4 131.160.1.112 273 a=group:FID 1 2 274 m=audio 20000 RTP/AVP 0 275 c=IN IP4 131.160.1.111 276 a=rtpmap:0 PCMU/8000 277 a=mid:1 278 m=audio 30002 RTP/AVP 97 279 a=rtpmap:97 AMR/8000 280 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; mode-change- 281 neighbor; maxframes=1 282 a=mid:2 284 The cellular terminal of this example only supports the AMR codec. 285 However, many current IP phones only support PCM (payload 0). In 286 order to be able to interoperate with them, the cellular terminal 287 uses a transcoder whose IP address is 131.160.1.111. The cellular 288 terminal includes in its SDP support for PCM at that IP address. 289 Remote systems will send AMR directly to the terminal but PCM will 290 be sent to the transcoder. The transcoder will be configured (using 291 whatever method) to convert the incoming PCM audio to AMR and send 292 it to the terminal. 294 5.4.1 Interactions of "group" with other media level attributes 296 Media level attributes affect a media stream defined by an "m" line. 297 The presence of "group" does not modify this behavior. 299 This property can be used for different purposes. The example below 300 shows one possible use of this. A SIP user agent receives an INVITE 301 with the following body: 303 v=0 304 o=Laura 289083124 289083124 IN IP4 forth.example.com 305 t=0 0 306 c=IN IP4 131.160.1.112 307 a=group:FID 1 2 308 m=audio 30000 RTP/AVP 0 309 a=mid:1 310 m=audio 30002 RTP/AVP 8 311 a=recvonly 312 a=mid:2 314 Camarillo/Holler/Eriksson 6 315 Grouping of media lines in SDP 317 The media agent knows that at a certain moment it can send either 318 PCM u-law to port number 30000 or PCM A-law to port number 30002. 319 However, the media agent also knows that the other end will only 320 send PCM u-law (payload 0). 322 Note that the "group" attribute used with FID semantics allows to 323 express uni-directional codecs for a bi-directional media flow, as 324 it is shown in the example above. 326 5.4.2 Media in parallel 328 It can happen that different "m" lines grouped together using FID 329 semantics contain the same codec. The SDP below shows one example of 330 this situation: 332 v=0 333 o=Laura 289083124 289083124 IN IP4 fifth.example.com 334 t=0 0 335 c=IN IP4 131.160.1.112 336 a=groupe:FID 1 2 3 337 m=audio 30000 RTP/AVP 0 338 a=mid:1 339 m=audio 30002 RTP/AVP 8 340 a=mid:2 341 m=audio 20000 RTP/AVP 0 8 342 c=IN IP4 131.160.1.111 343 a=recvonly 344 a=mid:3 346 If several "m" lines contain the codec used at a certain point of 347 time media MUST be sent to different destinations in parallel. 349 At a particular point of time, if the media agent is sending PCM u- 350 law (payload 0) it sends RTP packets to 131.160.1.112 on port 30000 351 and to 131.160.1.111 on port 20000 (first and third "m" lines). If 352 it is sending PCM A-law (payload 8) it sends RTP packets to 353 131.160.1.112 on port 30002 and to 131.160.1.111 on port 20000 354 (second and third "m" lines). 356 The system that generated the SDP above supports PCM u-law on port 357 30000 and PCM A-law on port 30002. Besides, it uses an application 358 server whose IP address is 131.160.1.111 that records all the 359 conversation. That is why the application server always receives a 360 copy of the audio stream regardless of the codec being used at any 361 given moment (it receives both u-law and A-law). 363 Note that if several "m" lines grouped together using FID semantics 364 contain the same codec the media agent MUST send media over several 365 RTP sessions at the same time. 367 Camarillo/Holler/Eriksson 7 368 Grouping of media lines in SDP 370 5.4.3 DTMF tones encoded as telephony events 372 DTMF tones can be transmitted using a regular voice codec or can be 373 transmitted as telephony events. The RTP payload for DTMF tones 374 treated as telephone events is described in RFC 2833 [9]. Below 375 there is an example of an SDP session description using FID 376 semantics and this payload type. 378 v=0 379 o=Laura 289083124 289083124 IN IP4 sixth.example.com 380 t=0 0 381 c=IN IP4 131.160.1.112 382 a=group:FID 1 2 383 m=audio 30000 RTP/AVP 0 384 a=mid:1 385 m=audio 20000 RTP/AVP 97 386 c=IN IP4 131.160.1.111 387 a=rtpmap:97 telephone-events 388 a=mid:2 390 The remote party would send PCM encoded voice (payload 0) to 391 131.160.1.112 and DTMF tones encoded as telephony events to 392 131.160.1.111. Note that only voice or DTMF is sent at a particular 393 point of time. When DTMF tones are sent the first media stream does 394 not carry any data and when voice is sent there is no data in the 395 second media stream. FID semantics provide different destinations 396 for alternative codecs. 398 Some systems implement the RTP payload defined in RFC 2833, but when 399 they send DTMF tones they do not mute the voice channel. Therefore, 400 effectively they are sending two copies of the same DTMF tone: 401 encoded as voice and encoded as a telephony event. When the receiver 402 gets both copies it typically uses the telephony event rather than 403 the tone encoded as voice. FID semantics MUST NOT be used in this 404 context to group both media streams since such a system is not using 405 alternative codecs but rather different parallel encodings for the 406 same information. 408 6. Usage of the "group" attribute in SIP 410 SDP descriptions are used by several different protocols, SIP among 411 them. We include a section about SIP because the "group" attribute 412 will most likely be used mainly by SIP systems. 414 SIP [6] is an application layer protocol for establishing, 415 terminating and modifying multimedia sessions. SIP carries session 416 descriptions in the bodies of the SIP messages but is independent 417 from the protocol used for describing sessions. SDP [2] is one of 418 the protocols that can be used for this purpose. 420 Camarillo/Holler/Eriksson 8 421 Grouping of media lines in SDP 423 6.1 Media alignment 425 Appendix B of [6] describes the usage of SDP in relation to SIP. It 426 states: "The caller and callee align their media description so that 427 the nth media stream ("m=" line) in the caller�s session description 428 corresponds to the nth media stream in the callee�s description." 430 The presence of the "group" attribute in an SDP session description 431 does not modify this behavior. 433 Since the "mid" attribute provides a means to label "m" lines it 434 would be possible to perform media alignment using "mid" labels 435 rather than matching nth "m" lines. However this would not bring any 436 gain and would add complexity to implementations. Therefore SIP 437 systems MUST perform media alignment matching nth lines regardless 438 of the presence of the "group" or "mid" attributes. 440 6.2 Mid value in responses 442 The "mid" attribute is an identifier for a particular media stream. 443 Therefore, the "mid" value in the response MUST be the same as the 444 "mid" value in the request. Besides, subsequent requests such as re- 445 INVITEs MUST use the same "mid" value for the already existing media 446 streams. 448 6.3 Group value in responses 450 The "group" attribute in a response will typically be the same as 451 the one received in the request. However, there are situations when 452 both are different. In these situations the "group" value to be used 453 in the session is the one present in the response. 455 Note the "group value in the response" really refers to the 456 "group" value in the last SDP exchanged between both parties. 457 That is, if in the establishment of a particular session 458 (INVITE-200 OK-ACK) SDPs are present in the 200 OK and in the 459 ACK (not in the INVITE), the "group" value to be used during 460 the session will be the one in the ACK. 462 The example below shows how the callee refuses a media stream 463 offered by the caller setting its port number to zero. The "mid" 464 value corresponding to that media stream is removed from the "group" 465 value in the response. 467 SDP in the INVITE from caller to callee: 469 v=0 470 o=Laura 289083124 289083124 IN IP4 seventh.example.com 471 t=0 0 472 c=IN IP4 131.160.1.112 473 a=group:FID 1 2 3 474 m=audio 30000 RTP/AVP 0 475 a=mid:1 477 Camarillo/Holler/Eriksson 9 478 Grouping of media lines in SDP 480 m=audio 30002 RTP/AVP 8 481 a=mid:2 482 m=audio 30004 RTP/AVP 3 483 a=mid:3 485 SDP in the INVITE from callee to caller: 487 v=0 488 o=Bob 289083125 289083125 IN IP4 fifth.example.com 489 t=0 0 490 c=IN IP4 131.160.1.113 491 a=group:FID 1 3 492 m=audio 20000 RTP/AVP 0 493 a=mid:1 494 m=audio 0 RTP/AVP 8 495 a=mid:2 496 m=audio 20002 RTP/AVP 3 497 a=mid:3 499 Note that although the media stream was refused the "mid" value was 500 still included. 502 6.4 Backward compatibility 504 An application that wants to be compliant to this specification MUST 505 support both "group" and "mid". Supporting just one of them would be 506 useless. 508 A SIP entity that receives a request that contains "group" and "mid" 509 attributes, understands them and it is willing to use the grouping 510 semantics offered returns a response that also contains "group" and 511 "mid" attributes. This way, the client that issued the request knows 512 that the server understood this extension. 514 Note that grouping of m lines is always requested by the issuer of 515 the request (the client), never by the issuer of the response (the 516 server). Since there is no response to a response in SIP, a server 517 that requested grouping in a response would not know whether the 518 "group" attribute was accepted by the client or not. A server that 519 wants to group media lines should issue another request after having 520 responded to the first one (a re-INVITE for instance). 522 This document does not define any SIP "Require" header. Therefore, 523 if one of the SIP user agents does not understand the "group" 524 attribute the standard SDP fall back mechanism is used. 526 A client that does not want to perform grouping of media lines in a 527 session SHOULD NOT add "mid" lines either. The presence of "mid" 528 lines would not be of any use for the server. Even if the server can 529 see that the client supported "mid" (and obviously "group" also) it 530 would be impossible to know which particular semantics are supported 531 (LS or/and FID). 533 Camarillo/Holler/Eriksson 10 534 Grouping of media lines in SDP 536 6.4.1 Client does not support "group" 538 This situation does not represent a problem because grouping 539 requests is always performed by clients, not by servers. If the 540 client does not support "group" this attribute will just not be 541 used. 543 6.4.2 Server does not support "group" 545 The server will ignore the "group" attribute, since it does not 546 understand it (it will also ignore the "mid" attribute). For LS 547 semantics, the server might decide to perform or to not perform 548 synchronization between media streams. 550 For FID semantics, the server will consider that the session 551 comprises several media streams. 553 Different implementations would behave in different ways. 555 In the case of audio and different "m" lines for different codecs an 556 implementation might decide to act as a mixer with the different 557 incoming RTP sessions, which is the correct behavior. 559 An implementation might also decide to refuse the request (e.g. 488 560 Not acceptable here or 606 Not Acceptable) because it contains 561 several "m" lines. In this case, the server does not support the 562 type of session that the caller wanted to establish. In case the 563 client is willing to establish a simpler session anyway, he should 564 re-try the request without "group" attribute and only one "m" line 565 per flow. 567 7. Acknowledgments 569 The authors would like to thank Jonathan Rosenberg, Adam Roach and 570 Orit Levin for their feedback on this document. 572 8. References 574 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 575 Levels", RFC 2119, IETF; March 1997. 577 [2] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC 578 2327, IETF; April 1998. 580 [3] D. Kutscher/J. Ott/C. Bormann, "Session Description and 581 Capability Negotiation", draft-ietf-mmusic-sdpng-00.txt, IETF; April 582 2001. Work in progress. 584 [4] H. Schulzrinne/A. Rao/R. Lanphier, "Real Time Streaming Protocol 585 (RTSP)", RFC 2326, IETF; April 1998. 587 Camarillo/Holler/Eriksson 11 588 Grouping of media lines in SDP 590 [5] H. Schulzrinne/S. Casner/R. Frederick/V. Jacobson, "RTP: A 591 Transport Protocol for Real-Time Applications", RFC 1889, IETF; 592 January 1996. 594 [6] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 595 Session Initiation Protocol", RFC 2543, IETF; Mach 1999. 597 [7] L. Westberg/M. Lindqvist, "Realtime Traffic over Cellular Access 598 Networks", draft-westberg-realtime-cellular-04.txt, IETF; June 2001. 599 Work in progress. 601 [8] J. Rosenberg/P.Mataga/H.Schulzrinne, "An Application Server 602 Component Architecture for SIP", draft-rosenberg-sip-app-components- 603 00.txt, IETF; November 2000. Work in progress. 605 [9] H. Schulzrinne/S. Petrack, "RTP Payload for DTMF Digits, 606 Telephony Tones and Telephony Signals", RFC 2833, IETF; May 2000. 608 9. Authors� Addresses 610 Gonzalo Camarillo 611 Ericsson 612 Advanced Signalling Research Lab. 613 FIN-02420 Jorvas 614 Finland 615 Phone: +358 9 299 3371 616 Fax: +358 9 299 3052 617 Email: Gonzalo.Camarillo@ericsson.com 619 Jan Holler 620 Ericsson Research 621 S-16480 Stockholm 622 Sweden 623 Phone: +46 8 58532845 624 Fax: +46 8 4047020 625 Email: Jan.Holler@era.ericsson.se 627 Goran AP Eriksson 628 Ericsson Research 629 S-16480 Stockholm 630 Sweden 631 Phone: +46 8 58531762 632 Fax: +46 8 4047020 633 Email: Goran.AP.Eriksson@era.ericsson.se 635 Camarillo/Holler/Eriksson 12