idnits 2.17.1 draft-ietf-lemonade-streaming-10.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 (March 10, 2009) is 5498 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 3851 (ref. 'SMIME') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4566 (ref. 'SDP') (Obsoleted by RFC 8866) == Outdated reference: A later version (-02) exists of draft-ncook-urlauth-accessid-01 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 March 10, 2009 5 Expires: September 11, 2009 7 Streaming Internet Messaging Attachments 8 draft-ietf-lemonade-streaming-10 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 September 11, 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 . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 20 80 3.9.1. Announcement Service Protocol Diagram . . . . . . . . 21 81 3.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 21 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 84 6. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 27 85 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 28 86 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 87 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 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 3.3. Client use of GENURLAUTH Command 334 The decision to make use of streaming services for a message part 335 will usually be predicated on the content type of the message part. 336 Using the capabilities of the IMAP FETCH command, clients determine 337 the MIME [MIME] Content-Type of particular message parts and based on 338 local policies or heuristics, decide that streaming for that message 339 part will be attempted. 341 Once the client has determined that a particular message part 342 requires streaming, the client generates an IMAP URL that refers to 343 the message part according to the method described in RFC 5092 344 [IMAPURL]. The client then begins the process of generating an 345 URLAUTH URL, by appending ";EXPIRE=" and 346 ";URLAUTH=" to the initial URL. 348 The ";EXPIRE=" parameter is optional, however it SHOULD be 349 used, since the use of anonymous URLAUTH authorized URLs is a 350 security risk (see Section 4, and doing so ensures that at some point 351 in the future, permission to access that URL will cease. IMAP server 352 implementors may choose to reject anonymous URLs that are considered 353 insecure (for example with an EXPIRE date too far in the future), as 354 a matter of local security policy. To prevent this causing 355 interoperability problems, IMAP servers that implement this profile 356 MUST NOT reject GENURLAUTH commands for anonymous URLs on the basis 357 of the EXPIRE time, if that time is equal to, or less than 1 hour in 358 the future. 360 The portion of the URLAUTH URL MUST be 'stream' (see 361 [ACCESSID]) if an out of band mechanism or the media server discovery 362 mechanism discussed in Section 3.2 specifies that the media server is 363 an authorized user of the IMAP server for the purposes of retrieving 364 content via URLFETCH. Without specific prior knowledge of such a 365 configuration (either through the discovery mechanism described in 366 this document, or by an out of band mechanism), the client SHOULD use 367 the 'stream' access identifier, which will cause streaming to fail if 368 the media server is not an authorized user of the IMAP server for the 369 purposes of streaming. 371 However, if the client wishes to take the risk associated with 372 generating a URL that can be used by any media server (see 373 Section 4), it MAY use 'anonymous' as the portion of the 374 URLAUTH URL passed to the GENURLAUTH command. For example, the 375 client may have been preconfigured with the address of media servers 376 in the local administrative domain, (thus implying a level of trust 377 in those media servers), without knowing whether those media servers 378 have a pre-existing trust relationship with the IMAP server to be 379 used (which may well be in a different administrative domain). See 380 Section 4 for a full discussion of the security issues. 382 The client uses the URL generated as a parameter to the GENAUTHURL 383 command, using the INTERNAL authorization mechanism. The URL 384 returned by a successful response to this command will then be passed 385 to the media server. If no successful response to the GENURLAUTH 386 command is received, then no further action will be possible with 387 respect to streaming media to the client. 389 Examples: 391 C: a122 UID FETCH 24356 (BODYSTRUCTURE) 392 S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" 393 S: ("CHARSET" "US-ASCII") NIL 394 S: NIL "7BIT" 1152 23)("VIDEO" "MPEG" 395 NIL NIL "BASE64" 655350)) UID 24356) 396 S: a122 OK FETCH completed. 397 C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/; 398 section=1.2;expire=2006-12-19T16:39:57-08:00; 399 urlauth=anonymous" INTERNAL 400 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/; 401 section=1.2;expire=2006-12-19T16:39:57-08:00; 402 urlauth=anonymous: 403 internal:238234982398239898a9898998798b987s87920" 404 S: a123 OK GENURLAUTH completed 406 C: a122 UID FETCH 24359 (BODYSTRUCTURE) 407 S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" 408 S: ("CHARSET" "US-ASCII") NIL 409 S: NIL "7BIT" 1152 23)("AUDIO" "G729" 410 NIL NIL "BASE64" 87256)) UID 24359) 411 S: a122 OK FETCH completed. 412 C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/; 413 section=1.3;expire=2006-12-19T16:39:57-08:00; 414 urlauth=stream" INTERNAL 415 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/; 416 section=1.3;expire=2006-12-20T18:31:45-08:00; 417 urlauth=stream: 418 internal:098230923409284092384092840293480239482" 419 S: a123 OK GENURLAUTH completed 421 3.4. Client Determination of Media Server Capabilities 423 Once an authorized IMAP URL has been generated, it is up to the 424 client to pass that URL to a suitable media server that is capable of 425 retrieving the URL via IMAP, and streaming the content to the client 426 using the RTP [RTP] protocol. 428 This section specifies the behaviour of clients that have not 429 determined, (either statically through configuration, or dynamically 430 through a discovery process as discussed in Section 3.2), the 431 capabilities of the media server with respect to the services (i.e. 432 RFC 4240 or 5022) supported by that media server. Clients that have 433 determined those capabilities should use the mechanisms described in 434 Section 3.5 or Section 3.7, as appropriate. 436 If the client supports the MSCML IVR service, then it SHOULD attempt 437 to contact the media server using the MSCML protocol by sending a SIP 438 INVITE which has the service indicator "ivr". Due to issues 439 described in Section 4, the client SHOULD use a suitable end-to-end 440 encryption method, such as S/MIME [SMIME], as described in the SIP 441 Specification [SIP]. 443 Assuming the media server responds to the INVITE without error, the 444 client can carry on using the MSCML IVR service as specified in 445 Section 3.7. If the media server responds with an error indicating 446 that the "ivr" service is not supported, then if the client supports 447 it, the client SHOULD attempt to contact the media server using the 448 Announcement Service, as described in Section 3.5. 450 The following example shows an example SIP INVITE using the "ivr" 451 service indicator: 453 C: INVITE sip:ivr@ms2.example.com SIP/2.0 454 < SIP Header fields omitted for reasons of brevity > 456 3.5. Client Use of the Media Server Announcement Service 458 Assuming the client or media server does not support use of the MSCML 459 protocol, the media server announcement service is used, as described 460 in RFC 4240 [NETANN]. This service allows the client to send a SIP 461 INVITE to a special username ('annc') at the media server (the 462 "announcement" user), supplying the URL obtained as per Section 3.3. 464 The SIP INVITE is constructed as shown in the examples below; note 465 that as per RFC 4240, the play parameter is mandatory, and specifies 466 the authorized IMAP URL to be played. 468 Examples of valid SIP INVITE URIs sent to the media server 469 announcement service: 471 C: sip:annc@ms2.example.net; 472 play=imap://joe@example.com/INBOX/%3Buid=24356/%3Bsection=1.2%3B 473 expire=2006-12-19T16:39:57-08:00%3Burlauth=anonymous: 474 internal:238234982398239898a9898998798b987s87920 475 C: sip:annc@ms1.example.net; 476 play=imap://fred@example.com/INBOX/%3Buid=24359/%3Bsection=1.3%3B 477 expire=2006-12-20T18:31:45-08:00%3Burlauth=stream: 478 internal:098230923409284092384092840293480239482 480 Notice that the ; characters that are used as parameters of the IMAP 481 URI are escaped as %3B, as otherwise they would change the meaning of 482 the enclosing SIP URI, by being regarded as SIP URI parameters 483 instead of IMAP URL parameters. 485 If the client receives a 200 (OK) response, the media server has 486 successfully retrieved the content from the IMAP server and the 487 negotiated RTP stream will shortly begin. 489 There are many possible response codes, however a response code of 490 404 received from the media server indicates that the content could 491 not be found or could not be retrieved for some reason. For example, 492 the media server may not support the use of IMAP URLs. At this 493 point, there are several options to the client, such as using 494 alternate media servers, or giving up in attempting to stream the 495 required message part. 497 3.6. Media Negotiation and Transcoding 499 This document uses standards and protocols from two traditionally 500 separate application areas: Mobile Email (primarily IMAP) and 501 Internet Telephony/Streaming (e.g. SIP/RTP). Since the document 502 primarily addresses enhancing the capabilities of mobile email, it is 503 felt worthwhile to give some examples of simple SIP/SDP exchanges, 504 and discussing capabilities such as media negotiation (using SDP) and 505 media transcoding. 507 In the below example, the client contacts the media server using the 508 SIP INVITE command to contact the Announcement service (see 509 Section 3.5), advertising support for a range of audio and video 510 codecs (using SDP [SDP]), and in response the media server advertises 511 only a set of audio codecs. This process is identical for the IVR 512 service, except that the IVR service does not use the SIP Request-URI 513 to indicate the content to be played; instead this is carried in a 514 subsequent SIP INFO request. 516 The client and server now know from the SDP advertised by both client 517 and server that communication must be using the subset of audio 518 codecs supported by both client and server (in the example SDP, it is 519 clear that the server does not support any video codecs). The media 520 server may perform transcoding (i.e. converting between codecs) on 521 the media received from the IMAP server in order to satisfy the 522 codecs supported by the client: for example the media server may 523 downgrade the video retrieved from the IMAP server to the audio 524 component only. 526 For clients using the Announcement service, the media server MUST 527 return an error to the INVITE if it cannot find a common codec 528 between the client, server and media, and it cannot transcode to a 529 suitable codec. Similarly, for clients using the MSCML IVR service, 530 the media server MUST return a suitable error response to the 531 request. 533 Example SIP INVITE and SDP Media Negotiation 535 C: INVITE sip:annc@ms2.example.com; 536 play=imap://joe@example.com/INBOX/%3Buid=24356/%3Bsection=1.2%3B 537 expire=2006-12-19T16:39:57-08:00%3Burlauth=anonymous: 538 internal:238234982398239898a9898998798b987s87920 SIP/2.0 539 C: From: UserA 540 C: To: NetAnn 541 C: Call-ID: 8204589102@example.com 542 C: CSeq: 1 INVITE 543 C: Contact: 544 C: Content-Type: application/sdp 545 C: Content-Length: 481 546 C: 547 C: v=0 548 C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40 549 C: s=Session SDP 550 C: c=IN IP4 192.0.2.40 551 C: t=3034423619 0 552 C: m=audio 9224 RTP/AVP 0 8 3 98 101 553 C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224 554 C: a=fmtp:101 0-15 555 C: a=rtpmap:98 ilbc/8000 556 C: a=rtpmap:101 telephone-event/8000 557 C: a=recvonly 558 C: m=video 9226 RTP/AVP 105 34 120 559 C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226 560 C: a=fmtp:105 profile=3;level=20 561 C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120 562 C: a=rtpmap:105 h263-2000/90000 563 C: a=rtpmap:120 h263/90000 564 C: a=recvonly 566 S: SIP/2.0 200 OK 567 S: From: UserA 568 S: To: NetAnn 569 S: Call-ID: 8204589102@example.com 570 S: CSeq: 1 INVITE 571 S: Contact: 572 S: Content-Type: application/sdp 573 S: Content-Length: 317 574 S: 575 S: v=0 576 S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41 577 S: s=Session SDP 578 S: c=IN IP4 192.0.2.41 579 S: t=3034423619 0 580 S: m=audio 17684 RTP/AVP 0 8 3 18 98 101 581 S: a=rtpmap:0 PCMU/8000 582 S: a=rtpmap:8 PCMA/8000 583 S: a=rtpmap:3 GSM/8000 584 S: a=rtpmap:18 G729/8000 585 S: a=fmtp:18 annexb=no 586 S: a=rtpmap:98 iLBC/8000 587 S: a=rtpmap:101 telephone-event/8000 588 S: a=fmtp:101 0-16 590 C: ACK sip:netann@192.0.2.41 SIP/2.0 591 C: From: UserA 592 C: To: NetAnn 593 C: Call-ID: 8204589102@example.com 594 C: CSeq: 1 ACK 595 C: Content-Length: 0 597 3.7. Client Use of the Media Server MSCML IVR Service 599 Once the client has determined that the media server supports the IVR 600 service, it is up to the client to generate a suitable MSCML request 601 to initiate streaming of the required media. 603 When using the IVR service, the initial SIP invite is used only to 604 establish that the media server supports the MSCML IVR service, and 605 to negotiate suitable media codecs. Once the initial SIP INVITE and 606 response to that INVITE have been completed successfully, the client 607 must generate a SIP INFO request with MSCML in the body of the 608 request to initiate streaming. 610 The request is used, as this allows the use of DTMF 611 digits to control playback of the media, such as fast-forward or 612 rewind. 614 Since the playcollect request is used purely for its VCR 615 capabilities, there is no need for the media server to perform DTMF 616 collection, therefore the playcollect attributes "firstdigittimer", 617 "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms", 618 which will have the effect of causing digit collection to cease 619 immediately after the media has finished playing. 621 The "ffkey" and "rwkey" attributes of are used to 622 control fast forward and rewind behaviour, with the "skipinterval" 623 attribute being used to control the 'speed' of these actions. 625 The tag is used to specify the media to be played, and 626 SHOULD have a single