idnits 2.17.1 draft-boulton-media-server-control-00.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. ** 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. 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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 29, 2005) is 6869 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) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-06 -- Obsolete informational reference (is this intentional?): RFC 3525 (ref. '7') (Obsoleted by RFC 5125) == Outdated reference: A later version (-01) exists of draft-even-media-server-req-00 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-24 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft Ubiquity Software Corporation 4 Expires: December 31, 2005 T. Melanchuk 5 Convedia 6 June 29, 2005 8 Media Server Request Protocol 9 draft-boulton-media-server-control-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 31, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a protocol for application deployment where 43 the application logic and media processing are distributed. The 44 framework uses the Session Initiation Protocol (SIP) to establish an 45 application-level control mechanism between Application Servers and 46 Media Servers. 48 The motivation for this protocol is to provide an interface suitable 49 to meet the requirements of a distributed, centralized conference 50 system, as defined by the XCON work group of the IETF. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . 4 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Locating Media Server Resources . . . . . . . . . . . . . . 9 58 5. Controlling UAC Behavior - Control Channel Setup . . . . . . 9 59 6. Media Server UAS Behavior - Control Channel Setup . . . . . 10 60 7. Media Dialog Operation . . . . . . . . . . . . . . . . . . . 11 61 8. Control Command Construction . . . . . . . . . . . . . . . . 11 62 9. Media Control Elements . . . . . . . . . . . . . . . . . . . 11 63 10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 11. Network Address Translator(NAT) . . . . . . . . . . . . . . 12 65 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 13. Security Considerations . . . . . . . . . . . . . . . . . . 12 67 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 68 14.1 IANA Registration of the 'mscs' Option Tag . . . . . . . 12 69 14.2 SDP Transport Protocol . . . . . . . . . . . . . . . . . 12 70 14.2.1 TCP/MSCS . . . . . . . . . . . . . . . . . . . . . . 12 71 14.2.2 TCP/TLS/MSCS . . . . . . . . . . . . . . . . . . . . 12 72 14.3 SDP Attribute Names . . . . . . . . . . . . . . . . . . 12 73 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 74 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 16.1 Normative References . . . . . . . . . . . . . . . . . . 12 76 16.2 Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 78 Intellectual Property and Copyright Statements . . . . . . . 15 80 1. Introduction 82 Applications are often developed using an architecture where the 83 application logic and media processing are distributed. Commonly, 84 the application logic runs on "application servers" whilst the media 85 processing runs on "media servers". This document focuses on the 86 protocol between the application server and media server. A detailed 87 set of requirements for Media Server Control can be found in the 88 'Requirements for a Media Server Control Protocol' document[9] 90 Currently the document describes the model for media server control. 91 Subsequent versions will build on the model and address the specific 92 application requirements from [9] 94 While the primary motivation for the work is to meet the XCON 95 requirements, there are many other application scenarios that require 96 media processing services within a SIP centric network. Application 97 developers want to continue to leverage SIP for establishing and 98 managing media sessions, while only adding the protocol machinery 99 necessary to allow application control of media server operation. 101 Current IETF transport device control protocols, such as megaco [7], 102 while excellent for controlling media gateways which bridge separate 103 networks are troublesome for supporting media-rich applications in 104 SIP networks as they duplicate many of the functions inherent in SIP. 105 Rather than relying on single protocol session establishment, 106 application developers need to translate between two separate 107 mechanisms. 109 Application servers traditionally use SIP third party call control 110 RFC 3725 [12] to establish media sessions from SIP user agents to a 111 media server. SIP, as defined in RFC 3261 [2], also provides the 112 ideal rendezvous mechanism for establishing and maintaining control 113 connections to Media Server components. The control connections can 114 then be used to exchange explicit command/response interactions that 115 allow for media control and associated command response results. 117 At first glance, it may appear that the session establishment 118 procedures here look similar to MRCPv2 [6]. Like MRCPv2, the 119 protocol described here uses SIP for resource location, leverages SIP 120 for availability and redundancy, can tap into caller preferences 121 [14], and, as this document will describe below, establish an 122 application channel for the exchange of media processing commands. 124 However, the protocol entities of MRCPv2 and the protocol described 125 herein are entirely different. Moreover, it is highly unlikely for a 126 MRCPv2 server to implement the primitives described in this document. 127 Likewise, it is exceedingly unlikely for a server implementing this 128 protocol to implement speech services such as speech recognition, 129 speaker identification, or text-to-speech. 131 We could institute a complex capabilities negotiation mechanism and a 132 large set of non-overlapping, optional methods. However, it is much 133 cleaner to simply use the proven MRCPv2 session establishment model 134 with a wire protocol that is appropriate for the task at hand. 136 2. Conventions and Terminology 138 In this document, BCP 14/RFC 2119 [1] defines the key words "MUST", 139 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 140 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In 141 addition, BCP 15 indicates requirement levels for compliant 142 implementations. 144 The following additional terms are defined for use in this document: 145 B2BUA : A B2BUA is a Back-to-Back SIP User Agent. 146 Media Server : A Media Server is an entity that performs media 147 processing on behalf of a requesting agent or Media Control 148 Client. In particular, a Media Server offers mixing, 149 announcement, tone detection and generation, and object play and 150 record services. The Media Server has a direct RTP [15] 151 relationship with the source or sink of the media flow. 152 Media Control Client : A Media Control Client is an entity that 153 requests media processing from a Media Server. Note that the 154 Media Control Client may not have any media capabilities 155 whatsoever. For example, the Media Control Client may be an 156 Application Server (B2BUA) or other endpoint requesting 157 manipulation of a third-party's media stream. In the document, we 158 often refer to this entity simply as "the Client". 160 3. Overview 162 This document details mechanisms for establishing, using, and 163 terminating a reliable channel using SIP for the purpose of 164 controlling a Media Server. The following text provides a non- 165 normative overview of the mechanisms used. Detailed, normative 166 guidelines are provided later in the document. 168 Media control channels are negotiated using standard SIP mechanisms 169 that would be used in a similar manner to creating a voice session. 170 Figure 1 illustrates a simplified view of the proposed mechanism. It 171 highlights a separation of the SIP signaling traffic and the 172 associated control channel that is established as a result of the SIP 173 interactions. 175 The use of SIP for the specified mechanism provides many inherent 176 capabilities which include:- 177 o Service location - Use SIP Proxies or Back-to-Back User Agents for 178 discovering Media Servers. 179 o Security mechanisms - Leverage established security mechanisms 180 such as TLS and Client Authentication. 181 o Connection Maintenance - The ability to re-negotiate a connection, 182 ensure it is active, audit parameters, etc. 183 o Media Agnostic - Generic protocol allows for easy extension. 185 As mentioned in the previous list, one of the main benefits of using 186 SIP as the session control protocol is the 'Service Location' 187 facilities provided. This applies at both a routing level where RFC 188 3263 [4] provides the physical location of devices and at the Service 189 level using Caller Preferences[13] and Callee Capabilities[14]. The 190 ability to select a Media Server based on Service level capabilities 191 is extremely powerful when considering a distributed, clustered 192 architecture containing varying services (e.g. Voice, Video, IM). 193 More detail on locating Media Server resources using these techniques 194 is outlined in Section 5 of this document. 196 +---------------SIP Traffic---------------+ 197 | | 198 v v 199 +-----+ +--+--+ 200 | SIP | | SIP | 201 |Stack| |Stack| 202 +---+-----+---+ +---+-----+---+ 203 | Media | | Media | 204 | Control |<-----Control Channel----->| Server | 205 | Client | | | 206 +-------------+ +-------------+ 208 Figure 1: Basic Architecture 210 The example from Figure 1 conveys a 1:1 connection between the Media 211 Control Client and the Media Server. It is be possible, if required, 212 for multiple connections using separate SIP dialogs to be established 213 between the Media Control Client and the Media Server entities. Any 214 of the connections created between the two entities can then be used 215 for Media Server control interactions. The control connections are 216 agnostic to the overlying media sessions and specific session 217 information is incorporated in the control interaction commands 218 represented using the defined XML schema (as defined in Section 10). 219 The ability to have multiple connections allows for stronger 220 redundancy and the ability to manage high volumes of traffic in busy 221 systems. 223 [Editors Note: Still under discussion. How does an app server know, 224 when there are multiple media servers, which specific MS has any 225 given media session? Next version of the draft will discuss the 226 correlation procedures. The App server needs a control channel with 227 the media server and needs to know which channel to use once the 228 media session has been established. Sounds like a GRUU usage? 230 Consider the following simple example for session establishment 231 between a Client and a Media Server (Note: Some lines in the examples 232 are removed for clarity and brevity). 234 The Client constructs and sends a SIP INVITE request to the Media 235 Server. The request contains the option tag 'mscs' in a SIP 236 'Require' header for the purpose of forcing the use of mechanism 237 described in this document. The SDP payload includes the required 238 information for control channel negotiation. The COMEDIA [8] 239 specification for setting up and maintaining reliable connections is 240 used (more detail available in later sections). 242 Client Sends to Media Server: 244 INVITE sip:Media-Server@example.com SIP/2.0 245 To: 246 From: ;tag=64823746 247 Require: mscs 248 Call-ID: 7823987HJHG6 249 Content-Type: application/sdp 251 v=0 252 o=originator 2890844526 2890842808 IN IP4 controller.example,com 253 s=- 254 c=IN IP4 controller.example.com 255 m=application 7575 TCP/MSCS 256 a=setup:active 257 a=connection:new 259 On receiving the INVITE requests, the Media Server supporting this 260 mechanism generates a 200 OK response containing appropriate SDP. 262 Media Server Sends to Client: 264 SIP/2.0 200 OK 265 To: ;tag=28943879 266 From: ;tag=64823746 267 Call-ID: 7823987HJHG6 268 Content-Type: application/sdp 270 v=0 271 o=originator 2890844526 2890842808 IN IP4 controller.example,com 272 s=- 273 c=IN IP4 mserver.example.com 274 m=application 7563 TCP/MSCS 275 a=setup:passive 276 a=connection:new 278 The Client receives the SIP 200 OK response and extracts the relevant 279 information. It creates an outgoing (as specified by the SDP 280 'setup:' attribute) TCP connection to the Media server. The 281 connection address (taken from 'c=') and port (taken from 'm=')are 282 used to identify the remote part in the new connection. 284 Once established, the newly created connection can be used to 285 exchange Media Server control language requests and responses. As 286 well, after the control channel has been setup, media sessions can be 287 established using standard SIP third party call control. 289 [Editors Note: See previous note:this is where we may need to mention 290 how an App Server knows which Media Server is responsible for any 291 given media session.] 293 Figure 4 provides a simplified view of a User Agent involved with the 294 proposed architecture. (1) in brackets represents the SIP dialog and 295 dedicated control channel previously described in this overview 296 section. 298 +---------Control SIP Dialog(1)-----------+ 299 | | 300 v v 301 +-----+ +--+--+ 302 +------(2)--------->| SIP |----------------(2)--------------->| SIP | 303 | |Stack| |Stack| 304 | +---+-----+---+ +---+-----+---+ 305 | | Media | | | 306 | | Control |<--Control Channel(1)----->| | 307 | | Client | | Media | 308 | +-------------+ | Server | 309 +--+--+ | | 310 |User | | | 311 |Agent|<============================RTP(2)==================>| | 312 +-----+ +-------------+ 314 Figure 4: Participant Architecture 316 (2) from Figure 4 represents the User Agent SIP dialog interactions 317 and associated media flow. A User Agent would create a SIP dialog 318 with the Media Control Client entity. The Media Control Client 319 entity will also create a related dialog to the Media Server (B2BUA 320 type functionality). Using the interaction illustrated by (2), the 321 User Agent is able to negotiate media capabilities using standard SIP 322 mechanisms as defined in RFC 3261 [2] and RFC 3264 [5] with the Media 323 Server. The Media Control Client will maintain relevant, unique, 324 information associated with the User Agent media dialog. This is 325 achieved using a concatenation of the dialog identifiers (SIP From- 326 tag + SIP To-tag + Call-ID as defined in RFC 3261 [2] - [TBD and 327 defined in later section]. Both Media Server and the Control Client 328 carry out this process when a SIP media dialog from a User Agent is 329 successful. The token produced from this concatenation process is 330 then used by the Control Client and Media Server to directly identify 331 a SIP dialog when Media Control commands using the XML defined in 332 Section 10 and Section 9 are passed between the two entities. 334 If not present in the SDP received by the Media Control Client from 335 the User Agent(2), a media label SDP attribute which is defined in 336 [11] MAY be inserted for every media description (identified as m= 337 line as defined in [10]). This provides flexibility for the Media 338 Control Client as it can generate Media Server controls that specify 339 a particular Media stream (between User Agent and Media Server) 340 within a SIP media dialog. If a Media label is not included in the 341 Media Control XML command it applies to all media associated with the 342 dialog. 344 [Editors Note: TODO - Overview of Conference instance + control 345 commands.] 347 4. Locating Media Server Resources 349 Section will describe mechanisms for locating a Media server. 351 5. Controlling UAC Behavior - Control Channel Setup 353 On creating a new SIP INVITE request, a UAC can insist on using the 354 mechanisms defined in this document. This is achieved by inserting a 355 SIP Require header containing the option tag 'mscs'. A SIP Require 356 header with the value 'mscs' SHOULD NOT be present in any other SIP 357 request type, although extensions to SIP MAY allow its usage with 358 other request methods. 360 If on creating a new SIP INVITE request, a UAC does not want to 361 insist on the usage of the mechanisms defined in this document but 362 merely that it supports them, a SIP Supported header MUST be included 363 in the request with the option tag 'mscs'. 365 If a reliable response is received (as defined RFC 3261 [2] and RFC 366 3262 [3]) that contains a SIP Require header containing the option 367 tag 'mscs', the mechanisms defined in this document are applicable to 368 the newly created dialog. 370 Before the UAC can send a request, it MUST include a valid session 371 description using the Session Description Protocol defined in . The 372 following information defines the composition of some specific 373 elements of the SDP payload that MUST be adhered to for compliancy to 374 this specification. 376 The Connection Data line in the SDP payload is constructed as 377 specified in [10]: 379 c= 381 The first sub-field, , MUST equal the value "IN". The 382 second sub-field, , MUST equal either "IP4" or "IP6". The 383 third sub-field for Connection Data is . This 384 supplies a representation of the SDP originators address e.g. dns/IP 385 representation. The address will be the network address used for 386 connections in this specification. 388 Example: 390 c=IN IP4 controller.example.com 392 The SDP MUST contain a corresponding Media Description entry for 393 compliance to this specification: 395 m= 397 The first "sub-field" MUST equal the value "application". 398 The second sub-field MUST represent a port on which the 399 constructing client can receive an incoming connection if required. 400 The port is used in combination with the address specified in the 401 'Connection Data line defined previously to supply connection 402 details. If the constructing client can not receive incoming 403 connections it MUST still enter a valid port range entry. The use of 404 the port value '0' has the same meaning as defined in the SDP 405 specification[10]. The third sub-field, , MUST equal the 406 value "TCP/MSCS" as defined in Section 14.2.2 of this document. 408 [Editors note: Need to cover other protocols so not TCP specific] 410 The SDP MUST also contain a number of SDP media attributes(a=), that 411 are specifically defined in the COMEDIA specification. The 412 attributes provide connection negotiation and maintenance parameters. 413 A client conforming to this specification SHOULD support all the 414 possible values defined for media attributes from the COMEDIA [8] 415 specification. It is RECOMMENDED that a Controlling UAC initiate a 416 connection to a Media Server but a Media Server MAY negotiate and 417 initiate a connection using COMEDIA, if network topology prohibits 418 initiating connections in a certain direction. An example of the 419 attributes might be: 421 a=setup:active 422 a=connection:new 424 This example demonstrates a new connection that will be initiated 425 from the owner of the SDP payload. The connection details are 426 contained in the SDP answer received from the UAS. A full example of 427 an SDP payload compliant to this specification can be viewed in 428 Section 3. Once the SDP has been constructed along with the 429 remainder of the SIP INVITE request (as defined in RFC 3261 [2]), it 430 can be sent to the appropriate location. 432 6. Media Server UAS Behavior - Control Channel Setup 434 On receiving a SIP INVITE request, a Media Server(UAS) inspects the 435 message for indications of support for the mechanisms defined in this 436 specification. This is achieved through the presence of the SIP 437 Supported and Require headers containing the option tag 'mscs'. If 438 the Media Server wishes to construct a reliable response that conveys 439 support for the extension, it should follow the mechanisms defined in 440 RFC 3261 [2] for responding to SIP supported and Require headers. If 441 support is conveyed in a reliable SIP provisional response, the 442 mechanisms in RFC 3263 [4] MUST also be used. 444 When constructing a SIP success response, the SDP payload MUST be 445 constructed using the semantics(Connection, Media and attribute) 446 defined in Section 5 using valid local settings and also with full 447 compliance to the COMEDIA[8] specification. For example, the SDP 448 attributes included in the answer constructed for the example offer 449 provided in Section 5 would look as illustrated below: 451 a=setup:passive 452 a=connection:new 454 Once the SIP success response has been constructed, it is sent using 455 standard SIP mechanisms. Depending on the contents of the SDP 456 payloads that were negotiated using the Offer/Answer exchange, a 457 reliable connection will be established between the Controlling UAC 458 and Media server UAS entities. The connection is now available to 459 exchange XML commands, as defined in Section 9 and Section 10 of this 460 document. 462 7. Media Dialog Operation 464 This section will describe in more detail the SIP interactions 465 between User Agents-->Control client-->Media Server. 467 8. Control Command Construction 469 This section focuses on the construction of control commands that 470 that are defined in the XML schemas provided later in this draft. It 471 is expected that the draft might split dialog commands away from 472 conference commands. This will enable simple implementations to just 473 do IVR and advanced to implement conference control and IVR. 475 9. Media Control Elements 477 Included as a placeholder for Element definitions 479 10. XML Schema 481 Included as a placeholder for XML schema definition 483 11. Network Address Translator(NAT) 485 This section will look at geographically distributed systems where 486 NAT traversal might be an issue. It will look at both the SIP media 487 dialog traversal and the control channel traversal. 489 12. Examples 491 13. Security Considerations 493 Security Considerations to be included in later versions of this 494 document. 496 14. IANA Considerations 498 14.1 IANA Registration of the 'mscs' Option Tag 500 14.2 SDP Transport Protocol 502 14.2.1 TCP/MSCS 504 14.2.2 TCP/TLS/MSCS 506 14.3 SDP Attribute Names 508 15. Acknowledgments 510 The authors would like to thank Ian Evans and Michael Bardzinski of 511 Ubiquity Software for useful review and input to this work. Eric 512 Burger contributed to the early phases of this work. 514 16. References 516 16.1 Normative References 518 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 519 Levels", BCP 14, RFC 2119, March 1997. 521 16.2 Informative References 523 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 524 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 525 Session Initiation Protocol", RFC 3261, June 2002. 527 [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 528 Responses in Session Initiation Protocol (SIP)", RFC 3262, 529 June 2002. 531 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 532 (SIP): Locating SIP Servers", RFC 3263, June 2002. 534 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 535 Session Description Protocol (SDP)", RFC 3264, June 2002. 537 [6] Shanmugham, S., "Media Resource Control Protocol Version 538 2(MRCPv2)", draft-ietf-speechsc-mrcpv2-06 (work in progress), 539 February 2005. 541 [7] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway 542 Control Protocol Version 1", RFC 3525, June 2003. 544 [8] Yon, D., "Connection-Oriented Media Transport in the Session 545 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 546 (work in progress), November 2004. 548 [9] Even, R., "Requirements for a media server control protocol", 549 draft-even-media-server-req-00 (work in progress), 550 January 2005. 552 [10] Handley, M., "SDP: Session Description Protocol", 553 draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. 555 [11] Levin, O. and G. Camarillo, "The SDP (Session Description 556 Protocol) Label Attribute", 557 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 558 January 2005. 560 [12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 561 "Best Current Practices for Third Party Call Control (3pcc) in 562 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 563 April 2004. 565 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 566 User Agent Capabilities in the Session Initiation Protocol 567 (SIP)", RFC 3840, August 2004. 569 [14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 570 Preferences for the Session Initiation Protocol (SIP)", 571 RFC 3841, August 2004. 573 [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 574 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 575 RFC 3550, July 2003. 577 Authors' Addresses 579 Chris Boulton 580 Ubiquity Software Corporation 581 Building 3 582 Wern Fawr Lane 583 St Mellons 584 Cardiff, South Wales CF3 5EA 586 Email: cboulton@ubiquitysoftware.com 588 Tim Melanchuk 589 Convedia 590 4190 Still Creek Drive, Suite 300 591 Vancouver, BC V5C 6C6 592 Canada 594 Email: timm@convedia.com 596 Intellectual Property Statement 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Disclaimer of Validity 622 This document and the information contained herein are provided on an 623 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 624 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 625 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 626 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 627 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Copyright Statement 632 Copyright (C) The Internet Society (2005). This document is subject 633 to the rights, licenses and restrictions contained in BCP 78, and 634 except as set forth therein, the authors retain all their rights. 636 Acknowledgment 638 Funding for the RFC Editor function is currently provided by the 639 Internet Society.