idnits 2.17.1 draft-ietf-lemonade-streaming-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2009) is 5442 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. 'SMIME') (Obsoleted by RFC 5751) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade N. Cook 3 Internet-Draft Cloudmark 4 Intended status: Informational June 3, 2009 5 Expires: December 5, 2009 7 Streaming Internet Messaging Attachments 8 draft-ietf-lemonade-streaming-13 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 5, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document describes a method for streaming multimedia attachments 57 received by a resource constrained and/or mobile device from an IMAP 58 server. It allows such clients, which often have limits in storage 59 space and bandwidth, to play video and audio e-mail content. 61 The document describes a profile for making use of the URLAUTH 62 authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media 63 Service (RFC 4240), and the Media Server Control Markup Language (RFC 64 5022). 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions Used in this Document . . . . . . . . . . . . . . 5 70 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 6 72 3.2. Media Server Discovery . . . . . . . . . . . . . . . . . . 8 73 3.3. Client use of GENURLAUTH Command . . . . . . . . . . . . . 10 74 3.4. Client Determination of Media Server Capabilities . . . . 12 75 3.5. Client Use of the Media Server Announcement Service . . . 12 76 3.6. Media Negotiation and Transcoding . . . . . . . . . . . . 13 77 3.7. Client Use of the Media Server MSCML IVR Service . . . . . 15 78 3.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 19 79 3.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 21 80 3.9.1. Announcement Service Protocol Diagram . . . . . . . . 21 81 3.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 21 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 6. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 28 85 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 29 86 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 30 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 93 1. Introduction 95 Email clients on resource and/or network constrained devices, such as 96 mobile phones, may have difficulties in retrieving and/or storing 97 large attachments received in a message. For example, on a poor 98 network link, the latency required to download the entire attachment 99 before displaying any of it may not be acceptable to the user. 100 Conversely, even on a high-speed network, the device may not have 101 enough storage space to secure the attachment once retrieved. 103 For certain media, such as audio and video, there is a solution: the 104 media can be streamed to the device, using protocols such as RTP 105 [RTP]. Streaming can be initiated and controlled using protocols 106 such as SIP [SIP] and particularly the media server profiles as 107 specified in RFC 4240 [NETANN] or MSCML [MSCML]. Streaming the media 108 to the device addresses both the latency issue, since the client can 109 start playing the media relatively quickly, and the storage issue, 110 since the client does not need to store the media locally. A 111 tradeoff is that the media cannot be viewed/played when the device is 112 offline. 114 Examples of the types of media that would benefit from the ability to 115 stream such media to the device include: 117 o Voice or Video mail messages received as an attachment 119 o Audio clips such as ring tones received as an attachment 121 o Video clips, such as movie trailers, received as an attachment 123 The client may wish to present the user with the ability to use 124 simple "VCR"-style controls such as pause, fast-forward and rewind. 125 In consideration of this, the document presents two alternatives for 126 streaming media - a simple mechanism which makes use of the 127 announcement service of RFC 4240, and a more complex mechanism which 128 allows VCR controls, based on MSCML (RFC 5022) [MSCML]. The choice 129 of which mechanism to use is up to the client, for example it may be 130 based on limitations of the client or the configured media server. 131 This document presents suggestions for determining which of these 132 streaming services are available. 134 2. Conventions Used in this Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 140 In examples, "C:" and "S:" indicate lines sent by the client and 141 server respectively. If a single "C:" or "S:" label applies to 142 multiple lines, then some of the line breaks between those lines are 143 for editorial clarity only and may not be part of the actual protocol 144 exchange. 146 3. Mechanism 148 3.1. Overview of Mechanism 150 The proposed mechanism for streaming media to messaging clients is a 151 profile for making use of several existing mechanisms, namely: 153 1. IMAP URLAUTH Extension URLAUTH [URLAUTH] - Providing the ability 154 to generate an IMAP URL that allows access by external entities 155 to specific message parts, e.g. an audio clip. 157 2. URLFETCH Binary Extension [URLFETCH_BINARY] - Providing the 158 ability to specify BINARY and BODYPARTSTRUCTURE arguments to the 159 URLFETCH command. 161 3. Media Server Announcement Service (RFC 4240) [NETANN] - Providing 162 the ability for a media server to stream media using a reference 163 provided by the media server client in a URL. 165 4. Media Server Interactive Voice Response (IVR) Service (RFC 5022) 166 [MSCML] - Providing the ability to stream media as above, but 167 with VCR-style controls. 169 The approach is shown in the following figure: 171 +--------------+ 172 | | 173 | Email Client |^ 174 | | \ 175 +--------------+ \ 176 ^ ^ \ 177 | \ \ (5) 178 | (1), \ \ 179 | (2) \ \ 180 | (3),\ \ 181 | (6) \ \ 182 | \ \ 183 v v v 184 +--------------+ +----------------+ 185 | | (4) | | 186 | IMAP Server |<----->| Media Server | 187 | | | | 188 +--------------+ +----------------+ 190 Figure 1 192 The proposed mechanism has the following steps: 194 1. Client determines from MIME headers of a particular message that 195 a particular message part (attachment) should be streamed to the 196 user. Note that no assumptions are made about how/when/if the 197 client contacts the user of the client about this decision. User 198 input may be required in order to initiate the proposed 199 mechanism. 201 2. Client constructs an IMAP URL referencing the message part, and 202 uses the GENURLAUTH [URLAUTH] command to generate a URLAUTH 203 authorized IMAP URL. 205 3. Client connects to a SIP Media Server using the Announcement 206 Service as specified in RFC 4240 [NETANN], or the IVR Service as 207 specified in RFC 5022 [MSCML], and passes the URLAUTH authorized 208 URL to the media server. 210 4. Media Server connects to the IMAP Server specified in the 211 referenced URL, and uses the IMAP URLFETCH [URLAUTH] command to 212 retrieve the message part. 214 5. Media server streams the retrieved message part to the client 215 using RTP [RTP]. 217 6. The media server or the client terminate the media streaming, or 218 the streaming ends naturally. The SIP session is terminated by 219 either client or server. 221 It should be noted that the proposed mechanism makes several 222 assumptions about the mobile device, as well as available network 223 services, namely: 225 o Mobile device is provisioned with, or obtains via some dynamic 226 mechanism (see Section 3.2), the location of a media server which 227 supports either RFC 4240 [NETANN] and/or RFC 5022 [MSCML]. 229 o Media Server(s) used by the mobile device support the IMAP URL 230 [IMAPURL] scheme for the announcement and/or IVR services 232 o IMAP Server used by the mobile device supports generating 233 anonymous IMAP URLs using the URLAUTH mechanism as well as the 234 IMAP URLFETCH BINARY [URLFETCH_BINARY] extension 236 3.2. Media Server Discovery 238 This section discusses possibilities for the automatic discovery of 239 suitable media servers to perform streaming operations, and provides 240 for such a mechanism using the IMAP METADATA [METADATA] extension. 242 There are two possibilities for clients with regard to determining 243 the hostname and port number information of a suitable media server: 245 1. No discovery of media servers is required: clients are configured 246 with suitable media server information in an out-of-band manner. 248 2. Discovery of media servers is required: clients use a discovery 249 mechanism to determine a suitable media server that will be used 250 for streaming multimedia message parts. 252 There are several scenarios where media server discovery would be a 253 requirement for streaming to be successful: 255 o Client is not configured with the address of any media servers. 257 o Client is configured with the address of one or more media 258 servers, but the IMAP server is configured to only accept URLFETCH 259 requests from specific media servers (for security or site policy 260 reasons), and thus streaming would fail due to the media server 261 not being able to retrieve the media from the IMAP server. 263 There is also a scenario where media server discovery would improve 264 the security of the streaming mechanism, by avoiding the use of 265 completely anonymous URLs. For example, the client could discover a 266 media server address that was an authorised user of the IMAP server 267 for streaming purposes, which would allow the client to generate a 268 URL, which was secure in that it could *only* be accessed by an 269 entity that is trusted by the IMAP Server to retrieve content. The 270 issue of trust in media servers is discussed more fully in Section 4. 272 This document describes using the IMAP METADATA [METADATA] extension, 273 via the use of a server entry that provides the contact information 274 for suitable media servers for use with the IMAP server. Media 275 Server discovery is optional: clients are free to use pre-configured 276 information about media servers, or to fall back to pre-configured 277 information if they encounter IMAP servers that do not support either 278 the METADATA extension or the proposed entry, or that do not provide 279 a value for the entry. 281 A METADATA entry with the name of "/shared/mediaServers" is used to 282 store the locations of suitable media servers known to the IMAP 283 server. The entry is formatted according to the formalSyntax 284 specified in Section 8. This consists of a tuple of a URI and 285 optional "stream" string, where the URI is surrounded by <> symbols, 286 the URI and "stream" are separated using a colon ":", and tuples are 287 separated using a ";". 289 The "stream" string (c.f. the "stream" access identifier from 290 [ACCESSID]) is used to identify media servers capable of connecting 291 to the IMAP server as users authorized to retrieve URLs constructed 292 using the "stream" access identifier. It indicates that the client 293 MUST create the content URI using the "stream" access identifier. 294 See Section 3.3 for a description of how the client should make use 295 of the access identifier when generating IMAP URLs.) 297 Example values of the /shared/mediaServers METADATA entry (N.B. Any 298 line wrapping below is for the purpose of clarity): 300 ":stream;;" 303 ";;:stream" 306 It should be noted that the URI specified in the ABNF is generic, 307 i.e. not restricted to SIP URIs; however this document only specifies 308 how to make use of SIP URIs. Additionally, the "userinfo" (known as 309 the "service indicator" in RFC 4240 and RFC 4722) component of the 310 URI is optional; if specified it gives the client additional 311 information about the media server capabilities. For example, a 312 userinfo component of "annc" indicates that the media server supports 313 RFC 4240, and "ivr" indicates support for RFC 4722. Section 3.4 314 further describes how clients should behave if the "userinfo" 315 component is not present. 317 Clients SHOULD parse the value of the /shared/mediaServers entry, and 318 contact a media server using one of the returned URIs. The servers 319 are returned in order of preference as suggested by the server, 320 however it is left to the client to decide if a different order is 321 more appropriate when selecting the media server(s) to contact, as 322 well as the selection of alternates under failure conditions. 324 Administrators configuring the values of the /shared/mediaServers 325 entry, who do not know the capabilities of the media servers being 326 configured, SHOULD NOT include a userinfo component as part of of the 327 URI, in which case the client will determine which service to use as 328 specified in Section 3.4. Note that if a media server supports 329 multiple services, a URI with the appropriate userinfo component 330 SHOULD be configured for each service. 332 Note that even though the media server address can be discovered 333 dynamically, it is assumed that the necessary security arrangements 334 between the client and the media server already exist. For example, 335 the media server could use SIP digest authentication to provide 336 access only to authenticated clients; in this case, it is assumed the 337 username and password have already been set up. Likewise, if the 338 client wants to authenticate the media server using e.g. TLS and 339 certificates, it is assumed the necessary arrangements (trust anchors 340 and so on) already exist. In some deployments, the clients and media 341 servers may even be willing to rely on the security of the underlying 342 network, and omit authentication between the client and the media 343 server entirely. See Section 4 for more details. 345 3.3. Client use of GENURLAUTH Command 347 The decision to make use of streaming services for a message part 348 will usually be predicated on the content type of the message part. 349 Using the capabilities of the IMAP FETCH command, clients determine 350 the MIME [MIME] Content-Type of particular message parts and based on 351 local policies or heuristics, decide that streaming for that message 352 part will be attempted. 354 Once the client has determined that a particular message part 355 requires streaming, the client generates an IMAP URL that refers to 356 the message part according to the method described in RFC 5092 357 [IMAPURL]. The client then begins the process of generating an 358 URLAUTH URL, by appending ";EXPIRE=" and 359 ";URLAUTH=" to the initial URL. 361 The ";EXPIRE=" parameter is optional, however it SHOULD be 362 used, since the use of anonymous URLAUTH authorized URLs is a 363 security risk (see Section 4, and doing so ensures that at some point 364 in the future, permission to access that URL will cease. IMAP server 365 implementors may choose to reject anonymous URLs that are considered 366 insecure (for example with an EXPIRE date too far in the future), as 367 a matter of local security policy. To prevent this causing 368 interoperability problems, IMAP servers that implement this profile 369 MUST NOT reject GENURLAUTH commands for anonymous URLs on the basis 370 of the EXPIRE time, if that time is equal to, or less than 1 hour in 371 the future. 373 The portion of the URLAUTH URL MUST be 'stream' (see 374 [ACCESSID]) if an out of band mechanism or the media server discovery 375 mechanism discussed in Section 3.2 specifies that the media server is 376 an authorized user of the IMAP server for the purposes of retrieving 377 content via URLFETCH. Without specific prior knowledge of such a 378 configuration (either through the discovery mechanism described in 379 this document, or by an out of band mechanism), the client SHOULD use 380 the 'stream' access identifier, which will cause streaming to fail if 381 the media server is not an authorized user of the IMAP server for the 382 purposes of streaming. 384 However, if the client wishes to take the risk associated with 385 generating a URL that can be used by any media server (see 386 Section 4), it MAY use 'anonymous' as the portion of the 387 URLAUTH URL passed to the GENURLAUTH command. For example, the 388 client may have been preconfigured with the address of media servers 389 in the local administrative domain, (thus implying a level of trust 390 in those media servers), without knowing whether those media servers 391 have a pre-existing trust relationship with the IMAP server to be 392 used (which may well be in a different administrative domain). See 393 Section 4 for a full discussion of the security issues. 395 The client uses the URL generated as a parameter to the GENAUTHURL 396 command, using the INTERNAL authorization mechanism. The URL 397 returned by a successful response to this command will then be passed 398 to the media server. If no successful response to the GENURLAUTH 399 command is received, then no further action will be possible with 400 respect to streaming media to the client. 402 Examples: 404 C: a122 UID FETCH 24356 (BODYSTRUCTURE) 405 S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" 406 S: ("CHARSET" "US-ASCII") NIL 407 S: NIL "7BIT" 1152 23)("VIDEO" "MPEG" 408 NIL NIL "BASE64" 655350)) UID 24356) 409 S: a122 OK FETCH completed. 410 C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/; 411 section=1.2;expire=2006-12-19T16:39:57-08:00; 412 urlauth=anonymous" INTERNAL 413 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/; 414 section=1.2;expire=2006-12-19T16:39:57-08:00; 415 urlauth=anonymous: 416 internal:238234982398239898a9898998798b987s87920" 417 S: a123 OK GENURLAUTH completed 419 C: a122 UID FETCH 24359 (BODYSTRUCTURE) 420 S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" 421 S: ("CHARSET" "US-ASCII") NIL 422 S: NIL "7BIT" 1152 23)("AUDIO" "G729" 423 NIL NIL "BASE64" 87256)) UID 24359) 424 S: a122 OK FETCH completed. 425 C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/; 426 section=1.3;expire=2006-12-19T16:39:57-08:00; 427 urlauth=stream" INTERNAL 428 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/; 429 section=1.3;expire=2006-12-20T18:31:45-08:00; 430 urlauth=stream: 431 internal:098230923409284092384092840293480239482" 432 S: a123 OK GENURLAUTH completed 434 3.4. Client Determination of Media Server Capabilities 436 Once an authorized IMAP URL has been generated, it is up to the 437 client to pass that URL to a suitable media server that is capable of 438 retrieving the URL via IMAP, and streaming the content to the client 439 using the RTP [RTP] protocol. 441 This section specifies the behaviour of clients that have not 442 determined, (either statically through configuration, or dynamically 443 through a discovery process as discussed in Section 3.2), the 444 capabilities of the media server with respect to the services (i.e. 445 RFC 4240 or 5022) supported by that media server. Clients that have 446 determined those capabilities should use the mechanisms described in 447 Section 3.5 or Section 3.7, as appropriate. 449 If the client supports the MSCML IVR service, then it SHOULD attempt 450 to contact the media server using the MSCML protocol by sending a SIP 451 INVITE which has the service indicator "ivr". 453 Assuming the media server responds to the INVITE without error, the 454 client can carry on using the MSCML IVR service as specified in 455 Section 3.7. If the media server responds with an error indicating 456 that the "ivr" service is not supported, then if the client supports 457 it, the client SHOULD attempt to contact the media server using the 458 Announcement Service, as described in Section 3.5. 460 The following example shows an example SIP INVITE using the "ivr" 461 service indicator: 463 C: INVITE sip:ivr@ms2.example.com SIP/2.0 464 < SIP Header fields omitted for reasons of brevity > 466 3.5. Client Use of the Media Server Announcement Service 468 Assuming the client or media server does not support use of the MSCML 469 protocol, the media server announcement service is used, as described 470 in RFC 4240 [NETANN]. This service allows the client to send a SIP 471 INVITE to a special username ('annc') at the media server (the 472 "announcement" user), supplying the URL obtained as per Section 3.3. 474 The SIP INVITE is constructed as shown in the examples below; note 475 that as per RFC 4240, the play parameter is mandatory, and specifies 476 the authorized IMAP URL to be played. 478 Examples of valid SIP INVITE URIs sent to the media server 479 announcement service: 481 C: sip:annc@ms2.example.net; 482 play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection 483 %3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3Danonymous: 484 internal:238234982398239898a9898998798b987s87920 486 C: sip:annc@ms1.example.net; 487 play=imap:%2F%2Ffred@ 488 example.com%2FINBOX%2F%3Buid%3D24359%2F%3Bsection 489 %3D1.3%3Bexpire%3D2006-12-20T18:31:45-08:00%3Burlauth%3Dstream: 490 internal:098230923409284092384092840293480239482 492 Notice that many of the characters that are used as parameters of the 493 IMAP URI are escaped, as otherwise they would change the meaning of 494 the enclosing SIP URI, by being regarded as SIP URI parameters 495 instead of IMAP URL parameters. 497 If the client receives a 200 (OK) response, the media server has 498 successfully retrieved the content from the IMAP server and the 499 negotiated RTP stream will shortly begin. 501 There are many possible response codes, however a response code of 502 404 received from the media server indicates that the content could 503 not be found or could not be retrieved for some reason. For example, 504 the media server may not support the use of IMAP URLs. At this 505 point, there are several options to the client, such as using 506 alternate media servers, or giving up in attempting to stream the 507 required message part. 509 3.6. Media Negotiation and Transcoding 511 This document uses standards and protocols from two traditionally 512 separate application areas: Mobile Email (primarily IMAP) and 513 Internet Telephony/Streaming (e.g. SIP/RTP). Since the document 514 primarily addresses enhancing the capabilities of mobile email, it is 515 felt worthwhile to give some examples of simple SIP/SDP exchanges, 516 and discussing capabilities such as media negotiation (using SDP) and 517 media transcoding. 519 In the below example, the client contacts the media server using the 520 SIP INVITE command to contact the Announcement service (see 521 Section 3.5), advertising support for a range of audio and video 522 codecs (using SDP [SDP]), and in response the media server advertises 523 only a set of audio codecs. This process is identical for the IVR 524 service, except that the IVR service does not use the SIP Request-URI 525 to indicate the content to be played; instead this is carried in a 526 subsequent SIP INFO request. 528 The client and server now know from the SDP advertised by both client 529 and server that communication must be using the subset of audio 530 codecs supported by both client and server (in the example SDP, it is 531 clear that the server does not support any video codecs). The media 532 server may perform transcoding (i.e. converting between codecs) on 533 the media received from the IMAP server in order to satisfy the 534 codecs supported by the client: for example the media server may 535 downgrade the video retrieved from the IMAP server to the audio 536 component only. 538 For clients using the Announcement service, the media server MUST 539 return an error to the INVITE if it cannot find a common codec 540 between the client, server and media, or it cannot transcode to a 541 suitable codec. Similarly, for clients using the MSCML IVR service, 542 the media server MUST return a suitable error response to the 543 request. 545 Example SIP INVITE and SDP Media Negotiation 547 C: INVITE sip:annc@ms2.example.com; 548 play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3B 549 section%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3D 550 anonymous:internal:238234982398239898a9898998798b987s87920 SIP/2.0 551 C: From: UserA 552 C: To: NetAnn 553 C: Call-ID: 8204589102@example.com 554 C: CSeq: 1 INVITE 555 C: Contact: 556 C: Content-Type: application/sdp 557 C: Content-Length: 481 558 C: 559 C: v=0 560 C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40 561 C: s=Session SDP 562 C: c=IN IP4 192.0.2.40 563 C: t=3034423619 0 564 C: m=audio 9224 RTP/AVP 0 8 3 98 101 565 C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224 566 C: a=fmtp:101 0-15 567 C: a=rtpmap:98 ilbc/8000 568 C: a=rtpmap:101 telephone-event/8000 569 C: a=recvonly 570 C: m=video 9226 RTP/AVP 105 34 120 571 C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226 572 C: a=fmtp:105 profile=3;level=20 573 C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120 574 C: a=rtpmap:105 h263-2000/90000 575 C: a=rtpmap:120 h263/90000 576 C: a=recvonly 578 S: SIP/2.0 200 OK 579 S: From: UserA 580 S: To: NetAnn 581 S: Call-ID: 8204589102@example.com 582 S: CSeq: 1 INVITE 583 S: Contact: 584 S: Content-Type: application/sdp 585 S: Content-Length: 317 586 S: 587 S: v=0 588 S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41 589 S: s=Session SDP 590 S: c=IN IP4 192.0.2.41 591 S: t=3034423619 0 592 S: m=audio 17684 RTP/AVP 0 8 3 18 98 101 593 S: a=rtpmap:0 PCMU/8000 594 S: a=rtpmap:8 PCMA/8000 595 S: a=rtpmap:3 GSM/8000 596 S: a=rtpmap:18 G729/8000 597 S: a=fmtp:18 annexb=no 598 S: a=rtpmap:98 iLBC/8000 599 S: a=rtpmap:101 telephone-event/8000 600 S: a=fmtp:101 0-16 602 C: ACK sip:netann@192.0.2.41 SIP/2.0 603 C: From: UserA 604 C: To: NetAnn 605 C: Call-ID: 8204589102@example.com 606 C: CSeq: 1 ACK 607 C: Content-Length: 0 609 3.7. Client Use of the Media Server MSCML IVR Service 611 Once the client has determined that the media server supports the IVR 612 service, it is up to the client to generate a suitable MSCML request 613 to initiate streaming of the required media. 615 When using the IVR service, the initial SIP invite is used only to 616 establish that the media server supports the MSCML IVR service, and 617 to negotiate suitable media codecs. Once the initial SIP INVITE and 618 response to that INVITE have been completed successfully, the client 619 must generate a SIP INFO request with MSCML in the body of the 620 request to initiate streaming. 622 The request is used, as this allows the use of DTMF 623 digits to control playback of the media, such as fast-forward or 624 rewind. 626 Since the playcollect request is used purely for its VCR 627 capabilities, there is no need for the media server to perform DTMF 628 collection, therefore the playcollect attributes "firstdigittimer", 629 "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms", 630 which will have the effect of causing digit collection to cease 631 immediately after the media has finished playing. 633 The "ffkey" and "rwkey" attributes of are used to 634 control fast forward and rewind behaviour, with the "skipinterval" 635 attribute being used to control the 'speed' of these actions. 637 The tag is used to specify the media to be played, and 638 SHOULD have a single