view Side-By-Side changes
SIPPINGJ. Van Dyke Internet-DraftE. Burger(Ed.) Expires: September 1, 2003 A. SpitzerInternet-Draft SnowShore Networks, Inc.March 3,Expires: December 29, 2003 June 30, 2003 Basic Network Media Services with SIPdraft-burger-sipping-netann-05draft-burger-sipping-netann-06 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onSeptember 1,December 29, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well-defined manner. This document describes a mechanism for providing an interoperableVan Dyke, et al. Expires September 1, 2003 [Page 1] Internet-Draft SIP Media Services March 2003protocol interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. Burger Expires December 29, 2003 [Page 1] Internet-Draft SIP Media Services June 2003 Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. Note that the words "must" and "should" appear in the section Early Media Announcement (Section 7). In that section, these key words do NOT carry the strength described in RFC2119. That section is informative only. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Announcement Service . . . . . . . . . . . . . . . . . . . . . 6 3.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2Established Call Announcement . . . . . . . . . . . . .Operation . .8 3.2.1 Description. . . . . . . . . . . . . . . . . . . . . . . . 83.2.23.3 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . .9 3.3 Early Media Announcement . .. 8 3.4 Formal Syntax . . . . . . . . . . . . . . .9 3.3.1 Description. . . . . . . . . 9 4. Prompt and Collect Service . . . . . . . . . . . . . . .9 3.3.2 Protocol Diagram. . . 12 4.1 Formal Syntax for Prompt and Collect Service . . . . . . . . . 12 5. Conference Service . . . . . . . . . .11 3.4 Formal Syntax. . . . . . . . . . . . 14 5.1 Protocol Diagram . . . . . . . . . . .11 4. Prompt and Collect Service. . . . . . . . . . . . 15 5.2 Formal Syntax . . . . .14 4.1 Formal Syntax for Prompt and Collect Service. . . . . . . .14 5. Conference Service. . . . . . . . . . . 16 6. The User Part . . . . . . . . . .16 5.1 Protocol Diagram. . . . . . . . . . . . . . 17 7. Early Media Announcement . . . . . . . .17 5.2 Formal Syntax. . . . . . . . . . . 19 7.1 IMPORTANT NOTICE . . . . . . . . . . . .18 6. Media Server Response Codes. . . . . . . . . . . 19 7.2 Description . . . . .19 6.1 409 REQUEST REJECTED. . . . . . . . . . . . . . . . . . . . 197. The User Part7.3 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . .2021 8.Special Note for SIP Proxies and Redirect ServersSecurity Considerations . . . . .22 9. Security Considerations. . . . . . . . . . . . . . 22 9. Contributors . . . .23 10. IANA Considerations. . . . . . . . . . . . . . . . . . . .24 11.. 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .25. 24 Normative References . . . . . . . . . . . . . . . . . . . .26. 25 Informative References . . . . . . . . . . . . . . . . . . .27 Authors' Addresses. 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . .29 Van Dyke, et al.. 28 Burger ExpiresSeptember 1,December 29, 2003 [Page 2] Internet-Draft SIP Media ServicesMarchJune 2003 1. Overview In SIP-based media networks (RFC3261 [2]), there is a need to provide basic network media services. Such services include playing announcements, initiating a media mixing session (conference), and prompting and collecting information with a user. These services are basic in nature, are few in number, and fundamentally have not changed in 25 years of enhanced telephony services. Moreover, given their elemental nature, one would not expect them to change in the future. Announcements are media played to the user. Announcements can be static media files, media files generated in real-time, media streams generated in real-time, multimedia objects, or combinations of the above.In some situations, one must playMedia mixing is theannouncement without providing an answer indication. In others, one must play the announcement after completing call setup. This document describes how to provide such announcements in a SIP-based network. Media mixing is the act of mixing different RTP streams, as described in RFC1889 [9]. Note thatact of mixing different RTP streams, as described in RFC1889 [9]. Note that the service described here will suffice for simple mixing of media for a basic conferencing service. One can create a complete conferencing service using this basic building block. However, this service does not address the interesting application-level issues such as floor control for conferencing, etc. MSCML [10] addresses this need. However, that is beyond the scope of this document. Interested readers should read conferencing-framework [11] for details on the IETF SIP conferencing framework. Prompt and collect is where the server prompts the user for some information, as in an announcement, and then collects the user's response. This can be a one-step interaction, for example by playing an announcement, "Please enter your pass code", followed by collecting a string of digits. It can also be a more complex interaction, specified, for example, by VoiceXML[10][12] or MSCML[11]. Van Dyke, et al.[10]. Burger ExpiresSeptember 1,December 29, 2003 [Page 3] Internet-Draft SIP Media ServicesMarchJune 2003 2. Mechanism In the context of SIP control of media servers, we take advantage of the fact that the standard SIP URI has a user part. Media servers do not havea concept of a user.users. Thus we use the user address, or the left-hand-side of the URI, as a service indicator. Note that the set of services is small, well defined, and well contained. The section The User Part (Section7)6) discusses the issues with using a fixed set of user-space names. For per-service security, the media server MAY use any of the security protocols described in RFC3261 [2]. The media server MAY issue 401 challenges for authentication. The media server, upon receiving the INVITE, notes the service indicator. Depending on the service indicator, the media server will either honor the request or return a failure response code. The service indicator is the concatenation of the service name and an optional service instance identifier, separated by an equal sign. Per RFC3261 [2], the service indicator is case insensitive. The service name MUST be from the set alphanumeric characters plus dash (US-ASCII %2C). The service name MUST NOT include an equal sign (US-ASCII %3C). The service name MAY have long- and short-forms, as SIP does for headers. A given service indicator MAY have an associated set of parameters. Such parameters MUST follow the convention set out for SIP URI parameters. That is, a semi-colon separated list of keyword=values. Certain services may have an association with a unique service instance on the media server. For example, a given media server can host multiple, separate conference sessions. To identify unique service instances, a unique identifier modifies the service name. The unique identifier MUST meet the rules for a legal user part of a SIP URI. An equal sign, US-ASCII %3D, MUST separate the service indicator from the unique identifier. Note that since the service indicator is case insensitive, the service instance identifier is also case insensitive. The requesting client issues a SIP INVITE to the media server, specifying the requested service and any appropriate parameters.Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page 4] Internet-Draft SIP Media ServicesMarchJune 2003 If the media server can perform the requested service, it does so, following the processing steps described in the service definitiondocument (see IANA Considerations (Section 10)).document. If the media server cannot perform the requested service or does not recognize the service indicator, it MUST respond with the response code 488 NOT ACCEPTABLE HERE. This is appropriate, as 488 refers to a problem with the user part of the URI. Moreover, 606 is not appropriate, as some other media server may be able to satisfy the request. RFC3261 [2] describes the 488 and 606 response codes. Some services require a unique identifier. Most services automatically create a service instance upon the first INVITE with the given identifier. However, if a service requires an existing service instance, and no such service instance exists on the media server, the media server MUST respond with the response code 404 NOT FOUND. This is appropriate as the service itself exists on the media server, but the particular service instance does not. It is as if the user was not home.Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page 5] Internet-Draft SIP Media ServicesMarchJune 2003 3. Announcement Service A network announcement is the delivery of anaudiomultimedia resource, such as a prompt file, to a terminal device. Note the multimedia resource may be any multimedia object that the media server supports. This service can play a single object with multiple streams, such as a video and audio prompt. However, this service cannot play multiple objects on the same SIP dialog. There are two types of network announcements. The differentiating characteristic between the two types is whether the network fully sets up the SIP dialog before playing the announcement. The analog in the PSTN is whether answer supervision is supplied; i.e. does the announcement server answer the call prior to delivering the announcement. Playing an announcement after call setup is straightforward. First, the requesting device issues an INVITE to the media server requesting the announcement service. The media server negotiates the SDP and responds with a 200 OK. After receiving the ACK from the requesting device, the media server plays the requestedpromptobject and issues a BYE to the requesting device.In replicating and expanding onThe operation for playing an announcement before theexisting telephone network, thereSIP dialog is fully established, as early media, is discouraged. The section Early Media Announcement (Section 7) describes aneed to play announcements during call setup. That is,method that works for such operations. Note, however, that section is informative in nature. If thenetwork deliversmediato the caller before the setup completes. Network operators need this capability to provide informational networkserver supports announcements,such as "The person you are trying to reach is unavailable. Good Bye." or "We are sorry,butall circuits are busy. Please try your call again later. Good Bye." Note that simply redirectingit cannot find thecaller to a media server,referenced URI, it MUST respond with the 404 NOT FOUND response code. If the media serverissuing a 200 OK response, is not appropriate. The call request itself has not completed successfully. To support the appropriate paradigm, the media server issues a 100 TRYING response, followed immediately by a 183 SESSION PROGRESS response with SDP. This enables the media server to send early media to the caller. The request to the media server SHOULD include the 100rel extension header RFC3262 [3]. This ensures the media server reliably delivers its SDP to the caller. At this point, the media server sends the requested audio. After playing the audio, the media server issues a 409 REQUEST REJECTED response code to the requesting device. See section Section 6.1 on the 409 result code, below. If the media server does not support announcements, it MUST respond with the 488 NOT ACCEPTABLE HERE response code. If the media server supports announcements, but it cannot find the Van Dyke, et al. Expires September 1, 2003 [Page 6] Internet-Draft SIP Media Services March 2003 referenced URI, it MUST respond with the 404 NOT FOUND response code. If the media server receives an INVITE for the announcement service withoutreceives an INVITE for the announcement service without a "play=" parameter, it MUST respond with the 404 NOT FOUND response code, as there is no default value for the announcement service. If there is an error retrieving the announcement, the media server MUST respond with a 404 NOT FOUND response code. In addition, the media server SHOULD include a Warning header with appropriate explanatory text explaining what failed. The Request URI fully describes the announcement service through the use of the user part of the address and additional URI parameters. The user portion of the address, "annc", specifies the announcement service on the media server. The service has several associated URI parameters that control the content and delivery of the announcement. These parameters are described below: Burger Expires December 29, 2003 [Page 6] Internet-Draft SIP Media Services June 2003 play Specifies theaudioresource or announcement sequence to be played.early Specifies whether early media treatment is desired.repeat Specifies how many times the media server should repeat the announcement or sequence named by the "play=" parameter. delay Specifies a delay interval between announcement repetitions. The delay is measured in milliseconds. duration Specifies the maximum duration of the announcement. The media server will discontinue the announcement and end the call if the maximum duration has been reached. The duration is measured in milliseconds. locale Specifies the language and country variant of the announcement sequence named in the "play=" parameter. The language is defined as atwo lettertwo-letter code per ISO 639-1[4].[3]. The country variant is also defined as atwo lettertwo-letter code per ISO 3166-1[5].[4]. These elements are concatenated with a single underbar (%x5F) character. The mechanics of announcement sequences are beyond the scope of this document. param[n] Provides a mechanism for passing values that are to be substituted into an announcement sequence. Up to 9 parameters ("param1=" through "param9=") may be specified. The mechanics of announcement sequences are beyond the scope of this document.Van Dyke, et al. Expires September 1, 2003 [Page 7] Internet-Draft SIP Media Services March 2003The "play=" parameter is mandatory and MUST be present. All other parameters are OPTIONAL. NOTE: Some encodings are not self-describing.The currentThus the implementation relies on filename extension conventions for determining the media type.The form of the SIP Request URI for announcements is as follows.Note that RFC3261 [2] implies that proxies are supposed to pass parameters through unchanged. However, be aware that non-conforming proxies may strip Request-URI parameters. That said, given thebackslash, CRLF, and spacing beforelikely scenarios for the"play="mechanisms presented in this document, this should not be an issue. Most likely, the proxy inserting the parameters is the last proxy before the media server. If the service provider deploys a proxy for load balancing or service location purposes, the service provider should ensure their choice of proxy will preserve the parameters. The form of the SIP Request URI for announcements is as follows. Note that the backslash, CRLF, and spacing before the "play=" in the example is for readability purposes only. sip:annc@ms2.example.net; \play="http://audio.example.net/allcircuitsbusy.g711"; \ early=yesBurger Expires December 29, 2003 [Page 7] Internet-Draft SIP Media Services June 2003 play="http://audio.example.net/allcircuitsbusy.g711" sip:annc@ms2.example.net; \ play="file://fileserver.example.net/geminii/yourHoroscope.wav" 3.1 Operation The scenarios below assume there is a SIP Proxy, application server, or media gateway controller between the caller and the media server. However, the announcement service works as described below even if the caller invokes the service directly. We chose to discuss the proxy case, as it will be the most common case.As described above, the "early=" parameter determines whether the media server plays the prompt after call setup or as early media. The default value for the "early=" parameter MUST BE "yes". That is, the default action is for the media server to play the prompt before establishing the call. We envision that that this service will be most commonly used for network announcements which require early media, hence that is the default behavior.3.2Established Call Announcement 3.2.1 DescriptionOperation The caller issues an INVITE to the serving SIP Proxy. The SIP Proxy determines what audio prompt to play to the caller. The proxy responds to the caller with 100 TRYING. The proxy issues an INVITE to the media server, requesting the appropriate prompt to play coded in the play= parameter. TheINVITE MUST contain the parameter "early=no" to invoke the Established Call Prompting service. Themedia server responds with 200 OK. The proxy sends a 200 OK to the caller. The caller then issues an ACK. TheVan Dyke, et al. Expires September 1, 2003 [Page 8] Internet-Draft SIP Media Services March 2003proxy then issues an ACK to the media server. With the callsetup,established, the media server plays the requested prompt. When the media server completes the play of the prompt, it issues a BYE to the proxy. The proxy then issues a BYE to the caller.3.2.23.3 Protocol Diagram Caller Proxy Media Server | INVITE | | |----------------------->| INVITE | | 100 TRYING |----------------------->| |<-----------------------| 200 OK | | 200 OK |<-----------------------| |<-----------------------| | | ACK | | |----------------------->| ACK | | |----------------------->| | | | | Play Announcement (RTP) | |<================================================| | | | | | BYE | Burger Expires December 29, 2003 [Page 8] Internet-Draft SIP Media Services June 2003 | BYE |<-----------------------| |<-----------------------| | | 200 OK | 200 OK | |----------------------->|----------------------->| | | |3.3 Early Media Announcement 3.3.1 Description The caller issues an INVITE to the serving SIP Proxy. Normally, the SIP Proxy would complete the call to the requested destination. However, if the destination is not available, the proxy will request a media server to play an audio prompt to the caller. The proxy responds with a 100 TRYING. The proxy issues an INVITE to the media server, requesting the appropriate prompt to play.3.4 Formal Syntax TheINVITE MAY contain the parameter "early=yes" or omitfollowing syntax specification uses the"early=" parameter to invoke the Early Media Prompting service. The media server responds with 100 TRYING followed by 183 SESSION PROGRESS. Assuming the initial invite included the 100rel extension header RFC3262 [3], which this document RECOMMENDS, the media server waits for the acknowledgement of the 183 (PRACK). At that point, the media server sends the announcement to Van Dyke, et al.augmented Backus-Naur Form (BNF) as described in RFC2234 [5]. ANNC-URL = "sip:" annc-ind "@" hostport annc-parameters annc-ind = "annc" annc-parameters = ";" play-param [ ";" content-param ] [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ] [ ";" locale-param ] [ ";" variable-params ] play-param = "play=" prompt-url content-param = "content-type=" MIME-type delay-param = "delay=" delay-value delay-value = 1*DIGIT duration-param = "duration=" duration-value duration-value = 1*DIGIT repeat-param = "repeat=" repeat-value repeat-value = 1*DIGIT locale-param = "locale=" locale-value locale-value = 2ALPHA %x5F 2ALPHA variable-params = param-name "=" variable-value param-name = "param" DIGIT ; e.g., "param1" Burger ExpiresSeptember 1,December 29, 2003 [Page 9] Internet-Draft SIP Media ServicesMarchJune 2003the caller.variable-value = 1*(ALPHA | DIGIT) Theprocedures in RFC3262 [3] describe what to do if the PRACKMIME-type islate or does not arrive. In addition, RFC3262 [3] describes provisional offer/answer SDP negotiation. RFC3261 [2] describesthe183 SESSION PROGRESS result code. As stated above, ifMIME [6] content type for theMedia Server cannot fetchannouncement, such as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on. To date, none of theURI inIETF audio MIME registrations have parameters. Vendor-specific registrations, such as audio/x-wav, do have parameters. However, they are not strictly needed for prompt fetching. On the"play=" parameter,other hand, theMedia Server will reply with a 404 NOT FOUND, possibly with an explanationprevalence ofthe failureparameters may change in theWarning: header. Otherwise, after the media server completesfuture. In addition, existing video registrations have parameters, such as video/DV. To accommodate this, and retain compatibility with thestreaming ofSIP URI structure, theprompt, itMIME-type parameter separator (semicolon, %3b) and value separator (equal, %d3) MUSTsendbe escaped. For example: sip:annc@ms.example.net; \ play=file://fs.example.net/clips/my-intro.dvi; \ content-type=video/mpeg%3bencode%d3314M-25/625-50 The locale-value consists of a487 REQUEST TERMINATED to the Proxy. Note: When the early media service is used the requester is implicitly asking the media server to cancel the transaction as soon2-letter language code asthe announcement is played. Since 487 is associated with an explicit CANCEL request itspecified in ISO 639-1 [3] and a 2-letter country code specified in ISO 3166-1 [4] separated by a single underbar (%x5Fh) character. The definition of hostport isappropriate for this useaswell.specified by RFC3261 [2]. Theproxy sendssyntax of prompt-url consists of a URL scheme as specified by RFC2396 [7] or a special token indicating a provisioned announcement sequence. We expect theappropriate error responseURL tothe caller. That couldbe487one of the following schemes. o http o ftp o file (referencing a local orany other appropriate code reflectiveNFS (RFC3010 [13]) o nfs (RFC2224 [14]) If a provisioned announcement sequence is to be played the value of prompt-url will have thefailure situation. Van Dyke, et al.following form: prompt-url = "/provisioned/" announcement-id announcement-id = 1*(ALPHA | DIGIT) Note that the scheme "/provisioned/" was chosen because of a Burger ExpiresSeptember 1,December 29, 2003 [Page 10] Internet-Draft SIP Media ServicesMarchJune 20033.3.2 Protocol Diagram Caller Proxy Media Server | INVITE | | |----------------------->| INVITE | | 100 TRYING |----------------------->| |<-----------------------| 100 TRYING | | |<-----------------------| | | 183 SESSION PROGRESS | | 183 SESSION PROGRESS |<-----------------------| |<-----------------------| | | PRACK | | * |----------------------->| PRACK | * | |----------------------->| | | | | Play Announcement (RTP) | |<================================================| | | 487 REQUEST TERMINATED | | 487 REQUEST TERMINATED |<-----------------------| |<-----------------------| | | ACK | ACK | |----------------------->|----------------------->| | | | * Ifhesitation to register a "provisioned:" URI scheme. This document is strictly focused on theUAC requestsSIP interface for the announcement service and as such does not detail how announcement sequences are provisioned orsupports 100rel indefined. Note that theinitial INVITE. 3.4media type of the object the prompt-url refers to can be most anything, including audio file formats, text file formats, or URI lists. See the Prompt and Collect Service (Section 4) section for more on this topic. Burger Expires December 29, 2003 [Page 11] Internet-Draft SIP Media Services June 2003 4. Prompt and Collect Service This service is also known as a voice dialog. It establishes an aural dialog with the user. The dialog service follows the model of the announcement service. However, the service indicator is "dialog". The dialog service takes a parameter, voicexml=, indicating the URI of the VoiceXML script to execute. sip:dialog@mediaserver.example.net; \ voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml A Media Server MAY accept additional SIP request URI parameters and deliver them to the VoiceXML interpreter session as session variables. 4.1 Formal Syntax for Prompt and Collect Service The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC2234[6]. ANNC-URL[5]. DIALOG-URL = "sip:"annc-inddialog-ind "@" hostportannc-parameters annc-inddialog-parameters dialog-ind ="annc" annc-parameters"dialog" dialog-parameters = ";"play-param [ ";" early-param ] [ ";" content-param ] [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ] [ ";" locale-param ]dialog-param [";" variable-paramsvxml-parameters ]play-param = "play=" prompt-url Van Dyke, et al. Expires September 1, 2003 [Page 11] Internet-Draft SIP Media Services March 2003 early-param = "early=" ( "yes" | "no" ) content-param = "content-type=" MIME-type delay-param = "delay=" delay-value delay-value = 1*DIGIT duration-param = "duration=" duration-value duration-value = 1*DIGIT repeat-param = "repeat=" repeat-value repeat-value = 1*DIGIT locale-paramdialog-param ="locale=" locale-value locale-value"voicexml=" dialog-url vxml-parameters =2ALPHA %x5F 2ALPHA variable-paramsvxml-param [ vxml-parameters ] vxml-param =param-name";" vxml-keyword "="variable-value param-namevxml-value vxml-keyword ="param" DIGIT ; e.g "param1" variable-valuetoken vxml-value =1*(ALPHA | DIGIT)token TheMIME-typedialog-url is theMIME [7] content type for the announcement, such as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on. To date, noneURI of theIETF audio MIME registrations have parameters. Vendor-specific registrations, such as audio/x-wav, do have parameters. However, they are not strictly needed for prompt fetching. On theVoiceXML script. If present, otherhand, the prevalence ofparametersmay change inget passed to thefuture. In addition, existing video registrations have parameters, such as video/DV. To accommodate this, and retain compatibilityVoiceXML interpreter session with theSIP URI structure, the MIME-type parameter separator (semicolon, %3b) and value separator (equal, %d3)assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords MUSTbe escaped. For example: sip:annc@ms.example.net; \ play=file://fs.example.net/clips/my-intro.dvi; \ content-type=video/mpeg%3bencode%d3314M-25/625-50 The locale-value consists ofhave values. If there is a2-letter language code as specified in ISO 639-1 [4] andvxml-keyword without a2-letter country code specifiedcorresponding vxml-value, the media server MUST reject the request with a 400 BAD REQUEST response code. In addition, the media server MUST state "Missing VXML Value" inISO 3166-1 [5] Van Dyke, et al.the reason phrase. Burger ExpiresSeptember 1,December 29, 2003 [Page 12] Internet-Draft SIP Media ServicesMarchJune 2003separated by a single underbar (%x5Fh) character. The definition of hostport is as specified by RFC3261 [2].Thesyntax of prompt-url consists of a URL scheme as specified by RFC2396 [8] or a special token indicating a provisioned announcement sequence. We expect the URL to be one of the following schemes. o http o ftp o file (referencing a local or NFS (RFC3010 [12]) o nfs (RFC2224 [13]) If a provisioned announcement sequence is to be playedmedia server presents thevalue of prompt-url will haveparameters as environment variables in thefollowing form: prompt-url = "/provisioned/" announcement-id announcement-id = 1*(ALPHA | DIGIT) Note thatconnection object. Specifically, thescheme "/provisioned/" was chosen because of a hesitation to register a "provisioned:" URI scheme. This document is strictly focused onparameter appears in theSIP interface forconnection.sip tree. If theannouncement service and as suchMedia Server does notdetail how announcement sequences are provisioned or defined. Note thatsupport themedia typepassing ofthe object the prompt-url referskeyword-value pairs tocan be most anything, including audio file formats, text file formats, or URI lists. SeethePrompt and Collect Service (Section 4) section for more on this topic. Van Dyke, et al.VoiceXML interpreter session, it MUST ignore the parameters. Burger ExpiresSeptember 1,December 29, 2003 [Page 13] Internet-Draft SIP Media ServicesMarchJune 20034. Prompt and Collect5. Conference ServiceThis service is also known as a voice dialog. It establishes an aural dialog with the user. The dialog service follows the model of the announcement service. However, the service indicator is "dialog". The dialog service takes a parameter, voicexml=, indicating the URI of the VoiceXML script to execute. sip:dialog@mediaserver.example.net; \ voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml A Media Server MAY accept additional SIP request URI parameters and deliver them to the VoiceXML interpreter session as session variables. 4.1 Formal Syntax for Prompt and Collect Service The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC2234 [6]. DIALOG-URL = "sip:" dialog-ind "@" hostport dialog-parameters dialog-ind = "dialog" dialog-parameters = ";" dialog-param [ vxml-parameters ] dialog-param = "voicexml=" dialog-url vxml-parameters = vxml-param [ vxml-parameters ] vxml-param = ";" vxml-keyword "=" vxml-value vxml-keyword = token vxml-value = token The dialog-url is the URI of the VoiceXML script. If present, other parameters get passed to the VoiceXML interpreter session with the assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords MUST have values. The media server presents the parameters as environment variables in the connection object. Specifically, the parameter appears in the connection.sip tree. If the Media Server does not support the passing of keyword-value pairs to the VoiceXML interpreter session, it MUST ignore the Van Dyke, et al. Expires September 1, 2003 [Page 14] Internet-Draft SIP Media Services March 2003 parameters. Van Dyke, et al. Expires September 1, 2003 [Page 15] Internet-Draft SIP Media Services March 2003 5. Conference Service One identifies mixing sessions through their SIP request URIs. To createOne identifies mixing sessions through their SIP request URIs. To create a mixing session, one sends an INVITE to a request URI that represents the session. If the URI does not already exist on the media server and the requested resources are available, the media server creates a new mixing session. If there is an existing URI for the session, then the media server interprets it as a request for the new session to join the existing session. The form of the SIP request URI for conferencing is:sip:conf@mediaserver.example.net;conf-id=uniqueIdentifiersip:conf=uniqueIdentifier@mediaserver.example.net The left-hand side of the request URI is actually the username of the request in the request URI and the To header. The host portion of the URI identifies a particular media server. The "conf" user name conveys to the media server that this is a request for the mixing service. The uniqueIdentifierparametercan be any value that is compliant with the SIP URI specification. It is the responsibility of the conference control application to ensure the identifier is unique within the scope of any potential conflict.It is worth noting thatIn theconference URI shared betweenterminology of theapplicationconferencing framework conferencing-framework [11], this URI convention tells the media server that the application server is requesting it to act as a Focus. The conf-id value identifies the particular focus instance. It is worth noting that the conference URI shared between the application and media provides enhanced security, as the SIP control interface does not have to be exposed to participants. It also allows the assignment of a specific media server to be delayed as long as possible, thereby simplifying resource management. One can add additional legs to the conference by INVITEing them to the above mentioned request URI. Per the matching rules of RFC3261 [2], the conf-id parameter is part of the matching string. Conversely, one can remove legs by issuing a BYE in the corresponding dialog. The mixing session, and thus the conference-specific request URI, remains active so long as there is at least one SIP dialog associated with the given request URI. If the Request-URI has "conf" as the user part, but does not have a conf-id parameter, the media server responds with a 404 NOT FOUND. NOTE: The media server could create a unique conference instance and return the conf-id string to the UAC if there is no conf-id present. However, such an operation may have other operational Burger Expires December 29, 2003 [Page 14] Internet-Draft SIP Media Services June 2003 issues, such as permissions and billing. Thus an application server or proxy is a better place to do such an operation.Van Dyke, et al. Expires September 1, 2003 [Page 16] Internet-Draft SIP Media Services March 2003Moreover, such action would make the media server into a Conference Factory in the terminology of conference-framework [11]. That is not the appropriate behavior for a media server. 5.1 Protocol Diagram This diagram shows the establishment of a three-way conference. This section is informative. P1 P2 P3 Application Server Media Server | | | | | | INVITE sip:public-conf@as.c.net | | |---------------------------------->| INVITEsip:conf@ms.c.net \ | | | | ;conf-id=123sip:conf=123@ms.c.net | | | |------------------>| | | | | 200 OK | | 200 OK | |<------------------| |<----------------------------------| | | | | RTP w/ P1 | | |<=====================================================>| | | | | | | INVITE sip:public-conf@as.c.net | | | |-------------------------->| INVITEsip:conf@ms.c.net \ | | | | ;conf-id=123sip:conf=123@ms.c.net | | | |------------------>| | | | | 200 OK | | | 200 OK | |<------------------| | |<--------------------------| | | | | | | | | | RTP w/ P1+P2-P2 | | | |<=============================================>| | | | RTP w/ P1+P2-P1 | | |<=====================================================>| | | | | | | INVITE sip:public-conf@as.c.net | | | | |----------------->| INVITEsip:conf@ms.c.net \ | | | | ;conf-id=123sip:conf=123@ms.c.net | | | |------------------>| | | | | 200 OK | | | | 200 OK |<------------------| | | |<-----------------| | | | | | | | | | RTP w/ P1+P2+P3-P3 | | | |<====================================>| | | | RTP w/ P1+P2+P3-P2 | | |<=============================================>| | | | RTP w/ P1+P2+P3-P1 | |<=====================================================>| Burger Expires December 29, 2003 [Page 15] Internet-Draft SIP Media Services June 2003 | | | | | | | | | | Using the terminology of conference-framework [11], the Application Server is the Conference Factory and the Media Server is the Conference Focus. Note that the above call flow does not show any 100 TRYING messagesVan Dyke, et al. Expires September 1, 2003 [Page 17] Internet-Draft SIP Media Services March 2003that would typically flow from the Application Server to theUAC's, nor does it show the ACK's from the UAC'sUAC's, nor does it show the ACK's from the UAC's to the Application Server or from the Application Server to the Media Server. Each leg can drop out either under the supervision of the UAC by the UAC sending a BYE or under the supervision of the Application Server by the Application Server issuing a BYE. In either case, the Application Server will either issue a BYE on behalf of the UAC or issue it directly to the Media Server, corresponding to the respective disconnect case. It is left as a trivial exercise to the reader for how the Application Server can mute legs, create side conferences, and so forth. Note that the Application Server is a server to the participants (UAC's). However, the Application Server is a client for mixing services to the Media Server. 5.2 Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC2234 [5]. CONF-URL = "sip:" conf-ind "=" instance-id "@" hostport conf-ind = "conf" instance-id = token The SIP-PARAM-LIST is the SIP Request-URI parameter list as described in RFC3261 [2]. Note that all of the parameters in the parameter list are part of the URI matching algorithm. Burger Expires December 29, 2003 [Page 16] Internet-Draft SIP Media Services June 2003 6. The User Part There has been considerable debate about the wisdom of using fixed user parts in a request URI. The most common objection is that the user part should be opaque and a local matter. The other objection is that using a fixed user part removes those specified user addresses from the user address space. We will address the latter issue first. The common example is the Postmaster address defined by RFC2821 [15]. The objection is that by using the Postmaster token for something special, one removes that token for anyone. Thus, the Postmaster General of the United States, for example, cannot have the mail address Postmaster@usps.gov. One may debate whether this is a significant limitation, however. One may point out that "annc", for example, has the potential for more conflict than Postmaster. This is true. However, one cannot confuse the namespace at a Media Server with the namespace for an organization. For example, let us take the case where a network offers services for "Ann Charles". She likes to use the name "annc", and thus she would like to use "sip:annc@provider.net". We offer that there is ABSOLUTELY NO NAME COLLISION WHATSOEVER. Why is this so? This is so because sip:annc@provider.net will resolve to the specific user at a specific device for Ann. As an example, provider.net's SIP Proxy Server can resolve sip:annc@provider.net to annc@anns-phone.provider.net . One directs requests for the media service annc directly to theApplication ServerMedia Server, e.g., sip:annc@ms21.ap.provider.net . Moreover, by definition, Ann Charles, orfromanything other than theApplication Server toannouncement service, will NEVER be directly on the Media Server.Each leg can drop out either underIf that were not true, no phone in thesupervisionworld could use the user part "eburger", as eburger is a reserved user part in the SnowShore domain. The most important thing to note about this convention is that the left-hand side of theUAC byrequest URI is opaque to theUAC sendingnetwork. The only network elements that need to know about the convention are the Media Server and client. Some have proposed that such naming be aBYE or underpure matter of local convention. For example, thesupervisionthesis of theApplication Server byinformational RFC3087 [16] is that you can address services using a request URI. However, some have taken theApplication Server issuingexamples in the document to an extreme. Namely, that the only way to address services is via arbitrary, opaque, long user parts. It is possible to provision the service names, rather than fixed names. While this can work in aBYE. In either case,closed network, where the ApplicationServer will either issue a BYE on behalf ofServers and Media Servers are in the same administrative Burger Expires December 29, 2003 [Page 17] Internet-Draft SIP Media Services June 2003 domain, this does not work across domains. This is because theUAC or issue it directly toclient of theMedia Server, correspondingmedia service has to know therespective disconnect case. Itlocal name for each service / domain pair. This isleft as a trivial exercise to the readerparticularly onerous forhowsituations where there is an ad hoc relationship between theApplication Server can mute legs, create side conferences,application andso forth. Note thattheApplication Server ismedia service. Without aserver to the participants (UAC's). However,well-known relationship between service and service address, how would theApplication Server is aclientfor mixing services tolocate theMedia Server. 5.2 Formal Syntax The following syntax specification usesservice? One very important result of using theaugmented Backus-Naur Form (BNF)user part asdescribed in RFC2234 [6]. CONF-URL = "sip:" conf-ind "@" hostport param-list conf-ind = "conf" param-list = SIP-PARAM-LIST ";" "conf-id" "=" instance-id instance-id = token The SIP-PARAM-LIST istheSIP Request-URI parameter list as described in RFC3261 [2]. Noteservice descriptor is that we can use all of theparameters instandard SIP machinery, without modification. For example, Media Servers with different capabilities can SIP Register their capabilities as users. For example, a mixing-only device will register theparameter list are part"conf" user, while a multi-purpose Media Server will register all of the users. Note that this is why the URImatching algorithm. Van Dyke, et al. Expires September 1, 2003 [Page 18] Internet-Draftto play is a parameter. Doing otherwise would overburden a normal SIP proxy or redirect server. Likewise, this scheme lets us leverage the standard SIP proxy behavior of using an intelligent redirect server or proxy server to provide high-available services. For example, two MediaServices March 2003 6. Media Server Response Codes There isServers can register with aneedSIP redirect server fora response code to indicate to a UAC thattheUAS has terminated a request before session establishment (200 OK). A UAS that sends this result code is effectively sending a CANCEL request toannc user. If one of theUAC. 6.1 409 REQUEST REJECTED The UAS has, for whatever reason, rejectedMedia Servers fails, therequest. Use casesregistration will expire and all requests forthis result code include the user attheUAS explicitly rejecting the request (e.g., releasingannouncement service ("calls to thecall before answering) orannc user") get sent toterminate a session that occurs beforethesession is fully established. Van Dyke, et al.surviving Media Server. Burger ExpiresSeptember 1,December 29, 2003 [Page19]18] Internet-Draft SIP Media ServicesMarchJune 2003 7.The User PartEarly Media Announcement 7.1 IMPORTANT NOTICE This section is entirely informative. It does not define any particular standards-track protocol or best practice. This section describes one implementation of an early media announcement service. Therehas been considerable debate aboutare many issues surrounding early media. Thus this document does not advocate thewisdomuse ofusing fixed user parts insuch arequest URI. The most common objection is thatfacility. This document includes this description of an early media announcement service purely to document one use of an early media call flow. All of theuser part should be opaqueMUST anda local matter. The other objection is that using a fixed user part removes those specified user addresses from the user address space. We will address the latter issue first. The common example is the Postmaster address defined by RFC2821 [14]. The objectionSHOULD language isthat by using the Postmaster token for something special, one removes that token for anyone. Thus, the Postmaster Generallikewise historical and NOT part of theUnited States, for example, cannot have the mail address Postmaster@usps.gov. One may debate whethernormative definition described in thisis a significant limitation, however.document. 7.2 Description In some situations, one would like to play an announcement without providing an answer indication. Onemay point out that "annc",need forexample, hasthis is to replicate and expand upon thepotential for more conflict than Postmaster. Thisexisting telephone network. Network operators require this capability to provide informational network announcements, such as "The person you are trying to reach istrue. However, one cannot confuseunavailable. Good Bye." or "We are sorry, but all circuits are busy. Please try your call again later. Good Bye." Note that simply redirecting thenamespace atcaller to aMedia Servermedia server, with thenamespace for an organization. For example, let us takemedia server issuing a 200 OK response, may not be appropriate. The call request itself has not completed successfully. Likewise, if a proxy record-routes thecase whererequest, the proxy will still forward anetwork offers services for "Ann Charles". She likes to use200 OK response from thename "annc", and thus shemedia server. Another alternative wouldlikebe to use"sip:annc@provider.net". We offer that there is ABSOLUTELY NO NAME COLLISION WHATSOEVER. Why is this so? This is so because sip:annc@provider.net will resolvea back-to-back user agent (B2BUA). The B2BUA would perform the early media signaling to thespecific user atUAC, while doing aspecific device for Ann. As an example, provider.net'snormal, complete SIPProxy Server can resolve sip:annc@provider.net to annc@anns-phone.provider.net . One directs requests fordialog with the mediaservice annc directly to the Media Server, e.g., sip:annc@ms21.ap.provider.net . Moreover, by definition, Ann Charles, or anything other thanserver. That unquestionably makes theannouncement service, will NEVER be directly onmedia server signaling easier. However, theMedia Server. Ifsignaling between the B2BUA would be identical to thatweredescribed below. Moreover, many network operators would rather deploy SIP Proxies and nottrue, no phone inB2BUAs. To support theworld could useappropriate paradigm, theuser part "eburger", as eburger ismedia server issues areserved user part in100 TRYING response, followed immediately by a 183 SESSION PROGRESS response with SDP. This enables theSnowShore domain. The most important thingmedia server tonote about this convention is that the left-hand side of the request URI is opaquesend early media to thenetwork.caller. Theonly network elements that needrequest toknow abouttheconvention aremedia server should include the 100rel extension Burger Expires December 29, 2003 [Page 19] Internet-Draft SIP MediaServer and client. Some have proposed that such naming be a pure matter of local convention. For example,Services June 2003 header RFC3262 [8]. This ensures thethesis ofmedia server reliably delivers its SDP to theinformational RFC3087 [15] is that you can address services using a request URI. However, some have takencaller. At this point, theexamples inmedia server sends thedocumentrequested audio. After playing the audio, the media server issues a 487 REQUEST CANCELED response code toan extreme. Namely, thattheonly wayrequesting device. NOTE: 487 conforms toaddress servicesRFC2543 [17]. However, it isvia arbitrary, opaque, long user parts. Itnot strictly the correct response code per RFC3261 [2]. The concept ispossible to provisionthat theservice names, rather than fixed names. While this can work inmedia server is responding to an implicit CANCEL. This works for most devices, as per RFC3261, aclosed network, where4xx result code means theApplication Servers and Media Serversrequest was terminated. Unfortunately, there arein the same administrative Van Dyke, et al. Expires September 1, 2003 [Page 20] Internet-Draft SIP Media Services March 2003 domain,non-conforming devices that do not terminate a session, even if they receive a 4xx result code. Be aware of that if you wish to implement this, non-normative, section of this document. If the media server does notwork across domains. This is becausesupport announcements, it MUST respond with theclient of488 NOT ACCEPTABLE HERE response code. The INVITE to the mediaservice hasserver contains the parameter "early=yes" toknowinvoke thelocal name for each service / domain pair. This is particularly onerous for situations where there is an ad hoc relationship betweenEarly Media Prompting service. The media server responds with 100 TRYING followed by 183 SESSION PROGRESS. Assuming theapplication andinitial invite included themedia service. Without a well-known relationship between service and service address, how would100rel extension header RFC3262 [8], which this document RECOMMENDS, theclient locatemedia server waits for theservice? One very important resultacknowledgement ofusingtheuser part as183 (PRACK). At that point, theservice descriptormedia server sends the announcement to the caller. The procedures in RFC3262 [8] describe what to do if the PRACK isthat we can use all oflate or does not arrive. In addition, RFC3262 [8] describes provisional offer/answer SDP negotiation. RFC3261 [2] describes thestandard SIP machinery, without modification. For example, Media Servers with different capabilities can SIP Register their capabilities as users. For example, a mixing-only device will register183 SESSION PROGRESS result code. As stated above, if the"conf" user, while a multi-purposeMedia Serverwill register all of the users. Note that this is whycannot fetch the URIto play is a parameter. Doing otherwise would overburden a normal SIP proxy or redirect server. Likewise, this scheme lets us leveragein the "play=" parameter, thestandard SIP proxy behavior of using an intelligent redirect server or proxy server to provide high-available services. For example, twoMediaServers can registerServer will reply with aSIP redirect404 NOT FOUND, possibly with an explanation of the failure in the Warning: header. Otherwise, after the media serverforcompletes theannc user. If onestreaming of theMedia Servers fails,prompt, it must send a 487 REQUEST TERMINATED to theregistration will expire and all requests forProxy. Note: When theannouncementearly media service("calls to the annc user") get sent tois used thesurviving Media Server. Van Dyke, et al. Expires September 1, 2003 [Page 21] Internet-Draft SIP Media Services March 2003 8. Special Note for SIP Proxies and Redirect Servers Note that proxies must be very careful withrequester is implicitly asking the"conf" user. In particular, a SIP proxy or redirectmedia serverMUST match at least the conf-id parameter before calculating wheretoredirectcancel therequest to. Bytransaction as soon as theSIP Request-URI matching rules in RFC3261 [2], a SIP entity will considerannouncement is played. Since 487 is associated with an explicit CANCEL request it is appropriate for this use as well. The proxy sends theconf-id parameterappropriate error response to the caller. That could bepart487 or any other appropriate code reflective of theRequest-URI, and thus will send identical Request-URI requests to the same UAS.failure situation. Burger Expires December 29, 2003 [Page 20] Internet-Draft SIP Media Services June 2003 Note thatinthis document does not define thecasebehavior ofa deficient SIP proxyan early media put on hold. 7.3 Protocol Diagram Caller Proxy Media Server | INVITE | | |----------------------->| INVITE | | 100 TRYING |----------------------->| |<-----------------------| 100 TRYING | | |<-----------------------| | | 183 SESSION PROGRESS | | 183 SESSION PROGRESS |<-----------------------| |<-----------------------| | | PRACK | | * |----------------------->| PRACK | * | |----------------------->| * | | 200 OK | * | 200 OK |<-----------------------| * |<-----------------------| | * | | | | Play Announcement (RTP) | |<================================================| | | 487 REQUEST TERMINATED | | 487 REQUEST TERMINATED |<-----------------------| |<-----------------------| | | ACK | ACK | |----------------------->|----------------------->| | | | * If the UAC requests orredirect server, one may usesupports 100rel in thenow depreciated "conf=uniqueId" user name. Van Dyke, et al.initial INVITE. Burger ExpiresSeptember 1,December 29, 2003 [Page22]21] Internet-Draft SIP Media ServicesMarchJune 20039.8. Security Considerations Untrusted network elements could use the protocol described here for providing information services. Many extant billing arrangements are for completed calls. Successful call completion occurs with a 2xx result code. This can be an issue for the early media announcementservice, and service providers should plan their networkservice. This is one of the many reasons why the early media announcement serviceofferings accordingly.is depreciated. Exposing network services with well-known addresses may not be desirable. In this case, the Media Server should offer local policy, e.g., only accept requests from authorized clients. Barring that, one can use a SIP Proxy to enforce the local policy.Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page23]22] Internet-Draft SIP Media ServicesMarchJune 200310. IANA Considerations This document defines a new result code for SIP. Per9. Contributors Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of theIANA Considerations sectionwork developing netann, in conjunction with many application developers, media server manufacturers, and service providers, some ofRFC3261 Section 27.4 [2], this document makeswhom are listed in thefollowing entry intoAcknowledgements section. All I did was do theresponse-code sub-registrytheory and write it up. That also means all ofhttp://www.iana.org/assignments/sip-parameters. Type: Request Failure 4xx NUMBER Default Reason Phrase RFC 409 REQUEST REJECTED [RFCXXXX] Van Dyke, et al.the mistakes are mine, as well. Burger ExpiresSeptember 1,December 29, 2003 [Page24]23] Internet-Draft SIP Media ServicesMarchJune 200311.10. Acknowledgements We would like to thank Kevin Summers and Ravindra Kabre of Sonus Networks for their constructive comments, as well as Jonathan Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their encouragement. In addition, the discussion at the Las Vegas Interim Workgroup Meeting in 2002 was invaluable for clearing up the issues surrounding the left-hand-side of therequest URI. Garland Sharrattrequest URI. Christer Holmberg helped tune the language of the multimedia announcement service. Orit Levin from Radvision gave a close read on the most recent version ofConvedia first proposed using a parameter fortheconference ID.draft document. Pete Danielsen from Lucent has consistently providedanexcellentreviewreviews of the many of the different versions of this document. Pascal Jalet provided the theoretical underpinning and David Rio provided the experimental evidence for why the conference identifer belongs in the user part of the-00request-URI. I am particularly indebted to Alan Johnston for his review of this document and-04 drafts.ensuring its conformance with the SIP conference control work in the IETF. The authors would like to give a special thanks to Walter O'Connor for doing much of the initial implementation.Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page25]24] Internet-Draft SIP Media ServicesMarchJune 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3]Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [4]ISO, "Codes for the representation of names of languages -- Part 1: Alpha-2 code", ISO 639-1, July 2002.[5][4] ISO, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1, October 1997.[6][5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.[7][6] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993.[8][7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.Van Dyke, et al.[8] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. Burger ExpiresSeptember 1,December 29, 2003 [Page26]25] Internet-Draft SIP Media ServicesMarchJune 2003 Informative References [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [10]World Wide Web Consortium, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Candidate Recommendation , February 2003, <http://www.w3.org/TR/2003/ CR-voicexml20-20030220/>. [11]Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media Server Control Markup Language and Protocol", draft-vandyke-mscml-00 (work in progress), November 2002. [11] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-00 (work in progress), May 2003. [12] World Wide Web Consortium, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Candidate Recommendation , February 2003, <http://www.w3.org/TR/2003/ CR-voicexml20-20030220/>. [13] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000.[13][14] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.[14][15] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.[15][16] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.[16][17] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [18] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.Authors' Addresses Jeff Van Dyke SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA EMail: jvandyke@snowshore.com Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page27]26] Internet-Draft SIP Media ServicesMarchJune 2003 Author's Address Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA EMail: e.burger@ieee.orgAndy Spitzer SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA EMail: woof@snowshore.com Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page28]27] Internet-Draft SIP Media ServicesMarchJune 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONVan Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page29]28] Internet-Draft SIP Media ServicesMarchJune 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementAcknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.Van Dyke, et al.Burger ExpiresSeptember 1,December 29, 2003 [Page30]29] ----