idnits 2.17.1 draft-burger-sipping-netann-11.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1056. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1046. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 20, 2005) is 7003 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) ** Obsolete normative reference: RFC 1521 (ref. '1') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3066 (ref. '5') (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '9') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '11') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3010 (ref. '12') (Obsoleted by RFC 3530) == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-06 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING E. Burger (Ed.) 3 Internet-Draft J. Van Dyke 4 Expires: August 24, 2005 A. Spitzer 5 Brooktrout Technology, Inc. 6 February 20, 2005 8 Basic Network Media Services with SIP 9 draft-burger-sipping-netann-11 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 24, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 In SIP-based networks, there is a need to provide basic network media 45 services. Such services include network announcements, user 46 interaction, and conferencing services. These services are basic 47 building blocks, from which one can construct interesting 48 applications. In order to have interoperability between servers 49 offering these building blocks (also known as Media Servers) and 50 application developers, one needs to be able to locate and invoke 51 such services in a well defined manner. 53 This document describes a mechanism for providing an interoperable 54 interface between Application Servers, which provide application 55 services to SIP-based networks, and Media Servers, which provide the 56 basic media processing building blocks. 58 Conventions used in this document 60 RFC2119 [2] provides the interpretations for the key words "MUST", 61 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 62 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 64 Table of Contents 66 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Announcement Service . . . . . . . . . . . . . . . . . . . . 6 69 3.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . 9 71 3.3 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Prompt and Collect Service . . . . . . . . . . . . . . . . . 11 73 4.1 Formal Syntax for Prompt and Collect Service . . . . . . . 12 74 5. Conference Service . . . . . . . . . . . . . . . . . . . . . 13 75 5.1 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . 14 76 5.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 16 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 78 7. The User Part . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Security Considerations . . . . . . . . . . . . . . . . . . 19 80 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 11.1 Normative References . . . . . . . . . . . . . . . . . . 20 84 11.2 Informative References . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 86 Intellectual Property and Copyright Statements . . . . . . . 23 88 1. Overview 90 In SIP-based media networks (RFC3261 [6]), there is a need to provide 91 basic network media services. Such services include playing 92 announcements, initiating a media mixing session (conference), and 93 prompting and collecting information with a user. 95 These services are basic in nature, are few in number, and 96 fundamentally have not changed in 25 years of enhanced telephony 97 services. Moreover, given their elemental nature, one would not 98 expect them to change in the future. 100 Multifunction media servers provide network media services to clients 101 using server protocols such as SIP, often in conjunction with markup 102 languages such as VoiceXML [15] and MSCML [16]. This document 103 describes how to identify to a multifunction media server what sort 104 of session the client is requesting, without modifying the SIP 105 protocol. 107 It is critically important to note that the mechanism described here 108 in no way modifies the SIP protocol, the meaning or definition of a 109 SIP Request URI, or does it put any restrictions, in any way, on 110 devices that do not implement this convention. 112 Announcements are media played to the user. Announcements can be 113 static media files, media files generated in real-time, media streams 114 generated in real-time, multimedia objects, or combinations of the 115 above. 117 Media mixing is the act of mixing different RTP streams, as described 118 in RFC1889 [9]. Note that the service described here suffices for 119 simple mixing of media for a basic conferencing service. This 120 service does not address enhanced conferencing services, such as 121 floor control, gain control, muting, subconferences, etc. MSCML [16] 122 addresses enhanced conferencing. However, that is beyond the scope 123 of this document. Interested readers should read 124 conferencing-framework [17] for details on the IETF SIP conferencing 125 framework. 127 Prompt and collect is where the server prompts the user for some 128 information, as in an announcement, and then collects the user's 129 response. This can be a one-step interaction, for example by playing 130 an announcement, "Please enter your pass code", followed by 131 collecting a string of digits. It can also be a more complex 132 interaction, specified, for example, by VoiceXML [15] or MSCML [16]. 134 2. Mechanism 136 In the context of SIP control of media servers, we take advantage of 137 the fact that the standard SIP URI has a user part. Multifunction 138 media servers do not have users. Thus we use the user address, or 139 the left-hand-side of the URI, as a service indicator. 141 The use of the user part of the SIP Request URI has a number of 142 useful properties: 143 o There is no change to core SIP. 144 o Only devices that choose to conform to this standard have to 145 implement it. 146 o This document only applies to multifunction SIP-controlled media 147 servers. 148 o This document has no impact on non-multifunction SIP-controlled 149 media servers. 150 o The mechanism described in this document has absolutely no impact 151 on SIP devices other than media servers. 152 The last bullet point is cruical. In particular, the user part 153 convention described here places absolutely no restrictions on any 154 SIP user agent, proxy, B2BUA, or any future device. The user parts 155 defined here only apply to multifunction media servers that chose to 156 implement the convention. With the exception of a conforming media 157 server, these user names and conventions have no impact on the user 158 part namespace. They do not restrict the use of these user names at 159 devices other than a multifunction media server. 161 Note that the set of services is small, well defined, and well 162 contained. The section The User Part (Section 7) discusses the 163 issues with using a fixed set of user-space names. 165 For per-service security, the media server SHOULD use the security 166 protocols described in RFC3261 [6]. 168 The media server MAY issue 401 challenges for authentication. The 169 media server SHOULD support the sips: scheme for the announcement 170 service. The media server MUST support the sips: scheme for the 171 dialog and conference services. The level of authentication to 172 require for each service is a matter of local policy. 174 The media server, upon receiving an INVITE, notes the service 175 indicator. Depending on the service indicator, the media server will 176 either honor the request or return a failure response code. 178 The service indicator is the concatenation of the service name and an 179 optional service instance identifier, separated by an equal sign. 181 Per RFC3261 [6], the service indicator is case insensitive. The 182 service name MUST be from the set alphanumeric characters plus dash 183 (US-ASCII %2C). The service name MUST NOT include an equal sign 184 (US-ASCII %3D). 186 The service name MAY have long- and short-forms, as SIP does for 187 headers. 189 A given service indicator MAY have an associated set of parameters. 190 Such parameters MUST follow the convention set out for SIP URI 191 parameters. That is, a semi-colon separated list of keyword=value 192 pairs. 194 Certain services may have an association with a unique service 195 instance on the media server. For example, a given media server can 196 host multiple, separate conference sessions. To identify unique 197 service instances, a unique identifier modifies the service name. 198 The unique identifier MUST meet the rules for a legal user part of a 199 SIP URI. An equal sign, US-ASCII %3D, MUST separate the service 200 indicator from the unique identifier. 202 Note that since the service indicator is case insensitive, the 203 service instance identifier is also case insensitive. 205 The requesting client issues a SIP INVITE to the media server, 206 specifying the requested service and any appropriate parameters. 208 If the media server can perform the requested service, it does so, 209 following the processing steps described in the service definition 210 document. 212 If the media server cannot perform the requested service or does not 213 recognize the service indicator, it MUST respond with the response 214 code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to 215 a problem with the user part of the URI. Moreover, 606 is not 216 appropriate, as some other media server may be able to satisfy the 217 request. RFC3261 [6] describes the 488 and 606 response codes. 219 Some services require a unique identifier. Most services 220 automatically create a service instance upon the first INVITE with 221 the given identifier. However, if a service requires an existing 222 service instance, and no such service instance exists on the media 223 server, the media server MUST respond with the response code 404 NOT 224 FOUND. This is appropriate as the service itself exists on the media 225 server, but the particular service instance does not. It is as if 226 the user was not home. 228 3. Announcement Service 230 A network announcement is the delivery of a multimedia resource, such 231 as a prompt file, to a terminal device. Note the multimedia resource 232 may be any multimedia object that the media server supports. This 233 service can play a single object with multiple streams, such as a 234 video and audio prompt. However, this service cannot play multiple 235 objects on the same SIP dialog. 237 There are two types of network announcements. The differentiating 238 characteristic between the two types is whether the network fully 239 sets up the SIP dialog before playing the announcement. The analog 240 in the PSTN is whether answer supervision is supplied; i.e. does the 241 announcement server answer the call prior to delivering the 242 announcement. 244 Playing an announcement after call setup is straightforward. First, 245 the requesting device issues an INVITE to the media server requesting 246 the announcement service. The media server negotiates the SDP and 247 responds with a 200 OK. After receiving the ACK from the requesting 248 device, the media server plays the requested object and issues a BYE 249 to the requesting device. 251 If the media server supports announcements, but it cannot find the 252 referenced URI, it MUST respond with the 404 NOT FOUND response code. 254 If the media server receives an INVITE for the announcement service 255 without a "play=" parameter, it MUST respond with the 404 NOT FOUND 256 response code, as there is no default value for the announcement 257 service. 259 If there is an error retrieving the announcement, the media server 260 MUST respond with a 404 NOT FOUND response code. In addition, the 261 media server SHOULD include a Warning header with appropriate 262 explanatory text explaining what failed. 264 The Request URI fully describes the announcement service through the 265 use of the user part of the address and additional URI parameters. 266 The user portion of the address, "annc", specifies the announcement 267 service on the media server. The service has several associated URI 268 parameters that control the content and delivery of the announcement. 269 These parameters are described below: 270 play Specifies the resource or announcement sequence to be played. 271 repeat Specifies how many times the media server should repeat the 272 announcement or sequence named by the "play=" parameter. The 273 value "forever" means the repeat should be effectively unbounded. 274 In this case, it is RECOMMENDED the media server implements some 275 local policy, such as limiting what "forever" means, to ensure 276 errant clients do not create a denial of service attack. 277 delay Specifies a delay interval between announcement repetitions. 278 The delay is measured in milliseconds. 279 duration Specifies the maximum duration of the announcement. The 280 media server will discontinue the announcement and end the call if 281 the maximum duration has been reached. The duration is measured 282 in milliseconds. 283 locale Specifies the language and optionally country variant of the 284 announcement sequence named in the "play=" parameter. RFC3066 [5] 285 specifies the locale tag. The locale tag is usually a two- or 286 three-letter code per ISO 639-1 [7]. The country variant is also 287 often a two-letter code per ISO 3166-1 [8]. These elements are 288 concatenated with a single under bar (%x5F) character, such as 289 "en_CA". If only the language is specified, such as locale=en, 290 the choice of country variant is an implementation matter. 291 Implementations SHOULD provide the best possible match between the 292 requested locale and the available languages in the event the 293 media server cannot honor the locale request precisely. For 294 example, if the request has locale=ca_FR but the media server only 295 has fr_FR available, the media server should use the fr_FR 296 variant. Implementations SHOULD provide a default locale to use 297 if no language variants are available. 298 param[n] Provides a mechanism for passing values that are to be 299 substituted into an announcement sequence. Up to 9 parameters 300 ("param1=" through "param9=") may be specified. The mechanics of 301 announcement sequences are beyond the scope of this document. 302 extension Provides a mechanism for extending the parameter set. If 303 the media server receives an extension it does not understand, it 304 MUST silently ignore the extension parameter and value. 306 The "play=" parameter is mandatory and MUST be present. All other 307 parameters are OPTIONAL. 309 NOTE: Some encodings are not self-describing. Thus the 310 implementation relies on filename extension conventions for 311 determining the media type. 313 Note that RFC3261 [6] implies that proxies are supposed to pass 314 parameters through unchanged. However, be aware that non-conforming 315 proxies may strip Request-URI parameters. That said, given the 316 likely scenarios for the mechanisms presented in this document, this 317 should not be an issue. Most likely, the proxy inserting the 318 parameters is the last proxy before the media server. If the service 319 provider deploys a proxy for load balancing or service location 320 purposes, the service provider should ensure their choice of proxy 321 preserves parameters. 323 The form of the SIP Request URI for announcements is as follows. 325 Note that the backslash, CRLF, and spacing before the "play=" in the 326 example is for readability purposes only. 328 sip:annc@ms2.example.net; \ 329 play=http://audio.example.net/allcircuitsbusy.g711 331 sip:annc@ms2.example.net; \ 332 play=file://fileserver.example.net/geminii/yourHoroscope.wav 334 3.1 Operation 336 The scenarios below assume there is a SIP Proxy, application server, 337 or media gateway controller between the caller and the media server. 338 However, the announcement service works as described below even if 339 the caller invokes the service directly. We chose to discuss the 340 proxy case, as it will be the most common case. 342 The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy 343 determines what audio prompt to play to the caller. The proxy 344 responds to the caller with 100 TRYING. 346 It is important to note that the mechanism described here in no way 347 modifies the behavior of SIP [6]. In particular, this convention 348 does not modify SDP negotiation [14]. 350 The proxy issues an INVITE to the media server, requesting the 351 appropriate prompt to play coded in the play= parameter. The media 352 server responds with 200 OK. The proxy relays the 200 OK to the 353 caller. The caller then issues an ACK. The proxy then relays the 354 ACK to the media server. 356 With the call established, the media server plays the requested 357 prompt. When the media server completes the play of the prompt, it 358 issues a BYE to the proxy. The proxy then issues a BYE to the 359 caller. 361 3.2 Protocol Diagram 363 Caller Proxy Media Server 364 | INVITE | | 365 |----------------------->| INVITE | 366 | 100 TRYING |----------------------->| 367 |<-----------------------| 200 OK | 368 | 200 OK |<-----------------------| 369 |<-----------------------| | 370 | ACK | | 371 |----------------------->| ACK | 372 | |----------------------->| 373 | | | 374 | Play Announcement (RTP) | 375 |<================================================| 376 | | | 377 | | BYE | 378 | BYE |<-----------------------| 379 |<-----------------------| | 380 | 200 OK | | 381 |----------------------->| 200 OK | 382 | |----------------------->| 383 | | | 385 3.3 Formal Syntax 387 The following syntax specification uses the augmented Backus-Naur 388 Form (BNF) as described in RFC2234 [3]. 390 ANNC-URL = sip-ind annc-ind "@" hostport 391 annc-parameters uri-parameters 393 sip-ind = "sip:" / "sips:" 394 annc-ind = "annc" 396 annc-parameters = ";" play-param [ ";" content-param ] 397 [ ";" delay-param] 398 [ ";" duration-param ] 399 [ ";" repeat-param ] 400 [ ";" locale-param ] 401 [ ";" variable-params ] 402 [ ";" extension-params ] 404 play-param = "play=" prompt-url 406 content-param = "content-type=" MIME-type 407 delay-param = "delay=" delay-value 409 delay-value = 1*DIGIT 411 duration-param = "duration=" duration-value 413 duration-value = 1*DIGIT 415 repeat-param = "repeat=" repeat-value 417 repeat-value = 1*DIGIT | "forever" 419 locale-param = "locale=" token 420 ; per RFC3066, usually 421 ; ISO639-1_ISO3166-1 422 ; e.g., en, en_US, en_UK, etc. 424 variable-params = param-name "=" variable-value 426 param-name = "param" DIGIT ; e.g., "param1" 428 variable-value = 1*(ALPHA | DIGIT) 430 extension-params = extension-param [ ";" extension-params ] 432 extension-param = token "=" token 434 "uri-parameters" is the SIP Request-URI parameter list as described 435 in RFC3261 [6]. All parameters of the Request URI are part of the 436 URI matching algorithm. 438 The MIME-type is the MIME [1] content type for the announcement, such 439 as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on. 441 To date, none of the IETF audio MIME registrations have parameters. 442 Vendor-specific registrations, such as audio/x-wav, do have 443 parameters. However, they are not strictly needed for prompt 444 fetching. 446 On the other hand, the prevalence of parameters may change in the 447 future. In addition, existing video registrations have parameters, 448 such as video/DV. To accommodate this, and retain compatibility with 449 the SIP URI structure, the MIME-type parameter separator (semicolon, 450 %3b) and value separator (equal, %d3) MUST be escaped. For example: 452 sip:annc@ms.example.net; \ 453 play=file://fs.example.net/clips/my-intro.dvi; \ 454 content-type=video/mpeg%3bencode%d3314M-25/625-50 456 The locale-value consists of a tag as specified in RFC3066 [5]. 458 The definition of hostport is as specified by RFC3261 [6]. 460 The syntax of prompt-url consists of a URL scheme as specified by 461 RFC2396 [4] or a special token indicating a provisioned announcement 462 sequence. For example, the URL scheme MAY include any of the 463 following. 464 o http/https 465 o ftp 466 o file (referencing a local or NFS (RFC3010 [12]) object) 467 o nfs (RFC2224 [10]) 469 If a provisioned announcement sequence is to be played the value of 470 prompt-url will have the following form: 472 prompt-url = "/provisioned/" announcement-id 474 announcement-id = 1*(ALPHA | DIGIT) 476 Note that the scheme "/provisioned/" was chosen because of a 477 hesitation to register a "provisioned:" URI scheme. 479 This document is strictly focused on the SIP interface for the 480 announcement service and as such does not detail how announcement 481 sequences are provisioned or defined. 483 Note that the media type of the object the prompt-url refers to can 484 be most anything, including audio file formats, text file formats, or 485 URI lists. See the Prompt and Collect Service (Section 4) section 486 for more on this topic. 488 4. Prompt and Collect Service 490 This service is also known as a voice dialog. It establishes an 491 aural dialog with the user. 493 The dialog service follows the model of the announcement service. 494 However, the service indicator is "dialog". The dialog service takes 495 a parameter, voicexml=, indicating the URI of the VoiceXML script to 496 execute. 498 sip:dialog@mediaserver.example.net; \ 499 voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml 501 A Media Server MAY accept additional SIP request URI parameters and 502 deliver them to the VoiceXML interpreter session as session 503 variables. 505 Although not good VoiceXML programming practice, VoiceXML scripts 506 might contain sensitive information, such as a user's pass code in a 507 DTMF grammar. Thus the media server MUST support the https scheme 508 for the voicexml parameter for secure fetching of scripts. Likewise, 509 dynamic grammars often do have user-identifying information. As 510 such, the VoiceXML browser implementation on the media server MUST 511 support https fetching of grammars and subsequent documents. 513 Returned information often is sensitive. For example, the 514 information could be financial information or instructions. Thus the 515 media server MUST support https posting of results. 517 4.1 Formal Syntax for Prompt and Collect Service 519 The following syntax specification uses the augmented Backus-Naur 520 Form (BNF) as described in RFC2234 [3]. 522 DIALOG-URL = sip-ind dialog-ind "@" hostport 523 dialog-parameters 525 sip-ind = "sip:" / "sips:" 526 dialog-ind = "dialog" 528 dialog-parameters = ";" dialog-param [ vxml-parameters ] 529 [ uri-parameters ] 531 dialog-param = "voicexml=" dialog-url 533 vxml-parameters = vxml-param [ vxml-parameters ] 535 vxml-param = ";" vxml-keyword "=" vxml-value 537 vxml-keyword = token 539 vxml-value = token 541 The dialog-url is the URI of the VoiceXML script. If present, other 542 parameters get passed to the VoiceXML interpreter session with the 543 assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords 544 MUST have values. 546 If there is a vxml-keyword without a corresponding vxml-value, the 547 media server MUST reject the request with a 400 BAD REQUEST response 548 code. In addition, the media server MUST state "Missing VXML Value" 549 in the reason phrase. 551 The media server presents the parameters as environment variables in 552 the connection object. Specifically, the parameter appears in the 553 connection.sip tree. 555 If the Media Server does not support the passing of keyword-value 556 pairs to the VoiceXML interpreter session, it MUST ignore the 557 parameters. 559 "uri_parameters" is the SIP Request-URI parameter list as described 560 in RFC3261 [6]. All parameters in the parameter list, whether they 561 come from uri-parameters or from vxml-keyworks, are part of the URI 562 matching algorithm. 564 5. Conference Service 566 One identifies mixing sessions through their SIP request URIs. To 567 create a mixing session, one sends an INVITE to a request URI that 568 represents the session. If the URI does not already exist on the 569 media server and the requested resources are available, the media 570 server creates a new mixing session. If there is an existing URI for 571 the session, then the media server interprets it as a request for the 572 new session to join the existing session. The form of the SIP 573 request URI for conferencing is: 575 sip:conf=uniqueIdentifier@mediaserver.example.net 577 The left-hand side of the request URI is actually the username of the 578 request in the request URI and the To header. The host portion of 579 the URI identifies a particular media server. The "conf" user name 580 conveys to the media server that this is a request for the mixing 581 service. The uniqueIdentifier can be any value that is compliant 582 with the SIP URI specification. It is the responsibility of the 583 conference control application to ensure the identifier is unique 584 within the scope of any potential conflict. 586 In the terminology of the conferencing framework 587 conferencing-framework [17], this URI convention tells the media 588 server that the application server is requesting it to act as a 589 Focus. The conf-id value identifies the particular focus instance. 591 As a focus in the conferencing framework, the media server MUST 592 support the ";isfocus" parameter in the Request URI. Note however, 593 that the presence or absence of the ";isfocus" parameter has no 594 protocol impact at the media server. 596 It is worth noting that the conference URI shared between the 597 application and media servers provides enhanced security, as the SIP 598 control interface does not have to be exposed to participants. It 599 also allows the assignment of a specific media server to be delayed 600 as long as possible, thereby simplifying resource management. 602 One can add additional legs to the conference by INVITEing them to 603 the above mentioned request URI. Per the matching rules of RFC3261 604 [6], the conf-id parameter is part of the matching string. 606 Conversely, one can remove legs by issuing a BYE in the corresponding 607 dialog. The mixing session, and thus the conference-specific request 608 URI, remains active so long as there is at least one SIP dialog 609 associated with the given request URI. 611 If the Request-URI has "conf" as the user part, but does not have a 612 conf-id parameter, the media server MUST respond with a 404 NOT 613 FOUND. 614 NOTE: The media server could create a unique conference instance 615 and return the conf-id string to the UAC if there is no conf-id 616 present. However, such an operation may have other operational 617 issues, such as permissions and billing. Thus an application 618 server or proxy is a better place to do such an operation. 619 Moreover, such action would make the media server into a 620 Conference Factory in the terminology of conference-framework 621 [17]. That is not the appropriate behavior for a media server. 623 Since some conference use cases, such as business conferencing, have 624 billing implications, the media server SHOULD authenticate the 625 application server or proxy. At a minimum, the media server MUST 626 implement sips:. 628 5.1 Protocol Diagram 630 This diagram shows the establishment of a three-way conference. This 631 section is informative. It is only one method of establishing a 632 conference. This example shows a simple back-to-back user agent. 634 The conference-framework [17] describes additional parameters and 635 behaviors of the Application Server. For example, the first INVITE 636 from P1 to the Application Server would include the ";isfocus" 637 parameter; the Application Server would act as a Conference Factory; 638 and so on. However, none of that protocol machinery has an impact on 639 the operation of the Application Server to Media Server interface, 640 which is the focus of this protocol document. 642 P1 P2 P3 Application Server Media Server 643 | | | | | 644 | INVITE sip:public-conf@as.example.net | 645 |---------------------------------->| | 646 | | | INVITE sip:conf=123@ms.example.net | 647 | | | |------------------>| 648 | | | | 200 OK | 649 | 200 OK | |<------------------| 650 |<----------------------------------| | 651 | ACK | | | | 652 |---------------------------------->| ACK | 653 | | | |------------------>| 654 | | | RTP w/ P1 | | 655 |<=====================================================>| 656 | | | | | 657 | INVITE sip:public-conf@as.example.net | 658 | |-------------------------->| | 659 | | | INVITE sip:conf=123@ms.example.net | 660 | | | |------------------>| 661 | | | | 200 OK | 662 | | 200 OK | |<------------------| 663 | |<--------------------------| | 664 | | ACK | | | 665 | |-------------------------->| ACK | 666 | | | |------------------>| 667 | | | | | 668 | | | RTP w/ P1+P2-P2 | | 669 | |<=============================================>| 670 | | | RTP w/ P1+P2-P1 | | 671 |<=====================================================>| 672 | | | | | 673 | INVITE sip:public-conf@as.example.net | 674 | | |----------------->| | 675 | | | INVITE sip:conf=123@ms.example.net | 676 | | | |------------------>| 677 | | | | 200 OK | 678 | | | 200 OK |<------------------| 679 | | |<-----------------| | 680 | | | ACK | | 681 | | |----------------->| ACK | 682 | | | |------------------>| 683 | | | | | 684 | | | RTP w/ P1+P2+P3-P3 | 685 | | |<====================================>| 686 | | | RTP w/ P1+P2+P3-P2 | 687 | |<=============================================>| 688 | | | RTP w/ P1+P2+P3-P1 | 689 |<=====================================================>| 690 | | | | | 691 | | | | | 693 Using the terminology of conference-framework [17], the Application 694 Server is the Conference Factory and the Media Server is the 695 Conference Focus. 697 Note that the above call flow does not show any 100 TRYING messages 698 that would typically flow from the Application Server to the UAC's, 699 nor does it show the ACK's from the UAC's to the Application Server 700 or from the Application Server to the Media Server. 702 Each leg can drop out either under the supervision of the UAC by the 703 UAC sending a BYE or under the supervision of the Application Server 704 by the Application Server issuing a BYE. In either case, the 705 Application Server will either issue a BYE on behalf of the UAC or 706 issue it directly to the Media Server, corresponding to the 707 respective disconnect case. 709 It is left as a trivial exercise to the reader for how the 710 Application Server can mute legs, create side conferences, and so 711 forth. 713 Note that the Application Server is a server to the participants 714 (UAC's). However, the Application Server is a client for mixing 715 services to the Media Server. 717 5.2 Formal Syntax 719 The following syntax specification uses the augmented Backus-Naur 720 Form (BNF) as described in RFC2234 [3]. 722 CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport 723 [ uri_parameters ] 725 sip-ind = "sip:" / "sips:" 727 conf-ind = "conf" 729 instance-id = token 731 "uri-parameters" is the SIP Request-URI parameter list as described 732 in RFC3261 [6]. All parameters in the parameter list are part of the 733 URI matching algorithm. 735 6. IANA Considerations 737 None. 739 7. The User Part 741 There has been considerable discussion about the wisdom of using 742 fixed user parts in a request URI. The most common objection is that 743 the user part should be opaque and a local matter. The other 744 objection is that using a fixed user part removes those specified 745 user addresses from the user address space. 747 We address the latter issue first. The common example is the 748 Postmaster address defined by RFC2821 [11]. The objection is that by 749 using the Postmaster token for something special, one removes that 750 token for anyone. Thus, the Postmaster General of the United States, 751 for example, cannot have the mail address Postmaster@usps.gov. One 752 may debate whether this is a significant limitation, however. 754 This document explicitly addresses this issue. The user names 755 described in the text, namely annc, ivr, dialog, and conf are 756 available for whatever local use a given SIP user agent or proxy 757 wishes for them. What this document does is give special meaning for 758 these user names at media servers that implement this specification. 759 If a media server choses not to implement this specification, nothing 760 breaks. If a user wishes to use one of the user names described in 761 this document at their SIP user agent, nothing breaks and their user 762 agent will work as expected. 764 The key point is, one cannot confuse the namespace at a Media Server 765 with the namespace for an organization. For example, let us take the 766 case where a network offers services for "Ann Charles". She likes to 767 use the name "annc", and thus she would like to use 768 "sip:annc@example.net". We offer there is ABSOLUTELY NO NAME 769 COLLISION WHATSOEVER. Why is this so? This is so because 770 sip:annc@example.net will resolve to the specific user at a specific 771 device for Ann. As an example, example.net's SIP Proxy Server 772 resolves sip:annc@example.net to annc@anns-phone.example.net . 773 Conversely, one directs requests for the media service annc directly 774 to the Media Server, e.g., sip:annc@ms21.ap.example.net . Moreover, 775 by definition, requests for Ann Charles, or anything other than the 776 announcement service, will NEVER be directly sent to the Media 777 Server. If that were not true, no phone in the world could use the 778 user part "eburger", as eburger is a reserved user part in the 779 Brooktrout domain. This clearly is not the case. 781 If one wishes to make their media server accessible to the global 782 Internet, but retain one of the Media Server-specific user names in 783 the domain, a SIP Proxy can easily translate whatever opaque name one 784 choses to the Media Server-specific user name. For example, if a 785 domain whishes to offer services for the above mentioned Ann Charles 786 at sip:annc@example.com, they can offer the announcement service at 787 sip:my-special-announcement-service@example.com . The former 788 address, sip:annc@example.com, would resolve to the actual device 789 where annc resides. The latter would resolve to the media server 790 announcement server address, sip:annc@mediaserver.example.com, as an 791 example. Note that this convention makes it easier to provision this 792 service. With a fixed mapping at the multifunction media server, 793 there are less provisioning data elements to get wrong. 795 Here is another way of looking at this issue. Unix reserves the 796 special user "root". Just about all Unix machines have a user root, 797 who has an address "root@a-specific-machine.example.com", where 798 "a-specific-machine" is the fully-qualified domain name (FQDN) of a 799 particular instance of a machine. There are very well-defined 800 semantics for the "root" user. 802 Even though most every Unix machine has a "root" user, often there is 803 no mapping for a "root" user in a domain, such as "root@example.com". 804 Conversely, there is no restriction on creating a MX record for 805 "root@example.com". That choice is fully up to the administrative 806 authority for the domain. 808 The "users" proposed by this document, "annc", "conf", and "dialog" 809 are all users at a Media Server, just as the "root", "bin", and 810 "nobody" users are "users" at a Unix host. 812 After much discussion, with input from the W3C URI work group, we 813 considered obfuscating the user name by prepending "__sip-" to the 814 user name. However, as explained above, this obfuscation is not 815 necessary. There is a fundamental difference between a user name at 816 a device and a user name at a MX record (SMTP) or Address-of-Record 817 (SIP). Again, there is no possibility that the name on the device 818 may "leak out" into the SIP routing network. 820 The most important thing to note about this convention is that the 821 left-hand side of the request URI is opaque to the network. The only 822 network elements that need to know about the convention are the Media 823 Server and client. Even proxies doing mapping resolution, as in the 824 example above for public announcement services, do not need to be 825 aware of the convention. The convention is purely a matter of 826 provisioning. 828 Some have proposed that such naming be a pure matter of local 829 convention. For example, the thesis of the informational RFC RFC3087 830 [13] is that you can address services using a request URI. However, 831 some have taken the examples in the document to an extreme. Namely, 832 that the only way to address services is via arbitrary, opaque, long 833 user parts. Clearyly, it is possible to provision the service names, 834 rather than fixed names. While this can work in a closed network, 835 where the Application Servers and Media Servers are in the same 836 administrative domain, this does not work across domains, such as in 837 the Internet. This is because the client of the media service has to 838 know the local name for each service / domain pair. This is 839 particularly onerous for situations where there is an ad hoc 840 relationship between the application and the media service. Without 841 a well-known relationship between service and service address, how 842 would the client locate the service? 843 One very important result of using the user part as the service 844 descriptor is that we can use all of the standard SIP machinery, 845 without modification. For example, Media Servers with different 846 capabilities can SIP Register their capabilities as users. For 847 example, a VoiceXML-only device will register the "dialog" user, 848 while a multi-purpose Media Server will register all of the users. 849 Note that this is why the URI to play is a parameter. Doing 850 otherwise would overburden a normal SIP proxy or redirect server. 851 Conversely, having the conference ID being part of the user part 852 gives an indication that requests get routed similarly (as opposed to 853 requiring a GRUU, which would restrict routing to the same device). 855 Likewise, this scheme lets us leverage the standard SIP proxy 856 behavior of using an intelligent redirect server or proxy server to 857 provide high-available services. For example, two Media Servers can 858 register with a SIP redirect server for the annc user. If one of the 859 Media Servers fails, the registration will expire and all requests 860 for the announcement service ("calls to the annc user") get sent to 861 the surviving Media Server. 863 8. Security Considerations 865 Exposing network services with well-known addresses may not be 866 desirable. The Media Server SHOULD authenticate and authorize 867 requesting endpoints per local policy. 869 Some interactions in this document result in the transfer of 870 confidential information. Moreover, many of the interactions require 871 integrity protection. Thus the Media Server MUST implement the sips: 872 scheme. In addition, application developers are RECOMMENDED to use 873 the security services offered by the Media Server to ensure the 874 integrity and confidentiality of their user's data, as appropriate. 876 Untrusted network elements could use the convention described here 877 for providing information services. Many extant billing arrangements 878 are for completed calls. Successful call completion occurs with a 879 2xx result code. This can be an issue for the early media 880 announcement service. This is one of the reasons why the early media 881 announcement service is deprecated. 883 Services such as repeating an announcement forever create the 884 possibility for denial of service attacks. The media server SHOULD 885 have local policies to deal with this, such as time-limiting how long 886 "forever" is, analyzing where multiple requests come from, 887 implementing white-lists for such a service, and so on. 889 9. Contributors 891 Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of the 892 work developing netann, in conjunction with many application 893 developers, media server manufacturers, and service providers, some 894 of whom are listed in the Acknowledgements section. All I did was do 895 the theory and write it up. That also means all of the mistakes are 896 mine, as well. 898 10. Acknowledgements 900 We would like to thank Kevin Summers and Ravindra Kabre of Sonus 901 Networks for their constructive comments, as well as Jonathan 902 Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their 903 encouragement. In addition, the discussion at the Las Vegas Interim 904 Workgroup Meeting in 2002 was invaluable for clearing up the issues 905 surrounding the left-hand-side of the request URI. Christer Holmberg 906 helped tune the language of the multimedia announcement service. 907 Orit Levin from Radvision gave a close read on the most recent 908 version of the draft document. Pete Danielsen from Lucent has 909 consistently provided excellent reviews of the many of the different 910 versions of this document. 912 Pascal Jalet provided the theoretical underpinning and David Rio 913 provided the experimental evidence for why the conference identifier 914 belongs in the user part of the request-URI. 916 I am particularly indebted to Alan Johnston for his review of this 917 document and ensuring its conformance with the SIP conference control 918 work in the IETF. 920 Mary Barnes, as usual, found the holes and showed how to fix them. 922 The authors would like to give a special thanks to Walter O'Connor 923 for doing much of the initial implementation. 925 Note that at the time of this writing, there are 7 known independent 926 server implementations that are interoperable with 23 known client 927 implementations. Our appologies if we did not count your 928 implementation. 930 11. References 932 11.1 Normative References 934 [1] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 935 Extensions) Part One: Mechanisms for Specifying and Describing 936 the Format of Internet Message Bodies", RFC 1521, September 937 1993. 939 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 940 Levels", BCP 14, RFC 2119, March 1997. 942 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 943 Specifications: ABNF", RFC 2234, November 1997. 945 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 946 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 948 [5] Alvestrand, H., "Tags for the Identification of Languages", 949 BCP 47, RFC 3066, January 2001. 951 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 952 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 953 Session Initiation Protocol", RFC 3261, June 2002. 955 [7] International Organization for Standardization, "Codes for the 956 representation of names of languages -- Part 1: Alpha-2 code", 957 ISO Standard 639-1, July 2002. 959 [8] International Organization for Standardization, "Codes for the 960 representation of names of countries and their subdivisions -- 961 Part 1: Country codes", ISO Standard 3166-1, October 1997. 963 11.2 Informative References 965 [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 966 "RTP: A Transport Protocol for Real-Time Applications", 967 RFC 1889, January 1996. 969 [10] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. 971 [11] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 972 2001. 974 [12] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 975 C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", 976 RFC 3010, December 2000. 978 [13] Campbell, B. and R. Sparks, "Control of Service Context using 979 SIP Request-URI", RFC 3087, April 2001. 981 [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 982 Session Description Protocol (SDP)", RFC 3264, June 2002. 984 [15] Burnett, D., Hunt, A., McGlashan, S., Porter, B., Lucas, B., 985 Ferrans, J., Rehor, K., Carter, J., Danielsen, P. and S. 986 Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 987 2.0", W3C REC REC-voicexml20-20040316, March 2004. 989 [16] Van Dyke, J., Burger, E., Ed. and A. Spitzer, "Media Server 990 Control Markup Language (MSCML) and Protocol", 991 Internet-Draft draft-vandyke-mscml-06, December 2004. 993 [17] Rosenberg, J., "A Framework for Conferencing with the Session 994 Initiation Protocol", 995 Internet-Draft draft-ietf-sipping-conferencing-framework-03, 996 October 2004. 998 Authors' Addresses 1000 Eric Burger 1001 Brooktrout Technology, Inc. 1002 18 Keewaydin Dr. 1003 Salem, NH 03079 1004 USA 1006 Email: eburger@brooktrout.com 1008 Jeff Van Dyke 1009 Brooktrout Technology, Inc. 1010 18 Keewaydin Dr. 1011 Salem, NH 03079 1012 USA 1014 Email: jvandyke@brooktrout.com 1016 Andy Spitzer 1017 Brooktrout Technology, Inc. 1018 18 Keewaydin Dr. 1019 Salem, NH 03079 1020 USA 1022 Email: woof@brooktrout.com 1024 Intellectual Property Statement 1026 The IETF takes no position regarding the validity or scope of any 1027 Intellectual Property Rights or other rights that might be claimed to 1028 pertain to the implementation or use of the technology described in 1029 this document or the extent to which any license under such rights 1030 might or might not be available; nor does it represent that it has 1031 made any independent effort to identify any such rights. Information 1032 on the procedures with respect to rights in RFC documents can be 1033 found in BCP 78 and BCP 79. 1035 Copies of IPR disclosures made to the IETF Secretariat and any 1036 assurances of licenses to be made available, or the result of an 1037 attempt made to obtain a general license or permission for the use of 1038 such proprietary rights by implementers or users of this 1039 specification can be obtained from the IETF on-line IPR repository at 1040 http://www.ietf.org/ipr. 1042 The IETF invites any interested party to bring to its attention any 1043 copyrights, patents or patent applications, or other proprietary 1044 rights that may cover technology that may be required to implement 1045 this standard. Please address the information to the IETF at 1046 ietf-ipr@ietf.org. 1048 Disclaimer of Validity 1050 This document and the information contained herein are provided on an 1051 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1052 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1053 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1054 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1055 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1056 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1058 Copyright Statement 1060 Copyright (C) The Internet Society (2005). This document is subject 1061 to the rights, licenses and restrictions contained in BCP 78, and 1062 except as set forth therein, the authors retain all their rights. 1064 Acknowledgment 1066 Funding for the RFC Editor function is currently provided by the 1067 Internet Society.