From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4240.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc4240.txt (limited to 'doc/rfc/rfc4240.txt') diff --git a/doc/rfc/rfc4240.txt b/doc/rfc/rfc4240.txt new file mode 100644 index 0000000..6c02ec9 --- /dev/null +++ b/doc/rfc/rfc4240.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group E. Burger, Ed. +Request for Comments: 4240 J. Van Dyke +Category: Informational A. Spitzer + Brooktrout Technology, Inc. + December 2005 + + + Basic Network Media Services with SIP + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +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 interoperable + interface between Application Servers, which provide application + services to SIP-based networks, and Media Servers, which provide the + basic media processing building blocks. + + + + + + + + + + + + + + + + + +Burger, et al. Informational [Page 1] + +RFC 4240 SIP Media Services December 2005 + + +Table of Contents + + 1. Overview ........................................................2 + 1.1. Conventions Used in This Document ..........................3 + 2. Mechanism .......................................................3 + 3. Announcement Service ............................................5 + 3.1. Operation ..................................................8 + 3.2. Protocol Diagram ...........................................9 + 3.3. Formal Syntax ..............................................9 + 4. Prompt and Collect Service .....................................11 + 4.1. Formal Syntax for Prompt and Collect Service ..............12 + 5. Conference Service .............................................13 + 5.1. Protocol Diagram ..........................................14 + 5.2. Formal Syntax .............................................16 + 6. IANA Considerations ............................................17 + 7. The User Part ..................................................17 + 8. Security Considerations ........................................20 + 9. Contributors ...................................................20 + 10. Acknowledgements ..............................................20 + 11. References ....................................................21 + 11.1. Normative References .....................................21 + 11.2. Informative References ...................................22 + +1. Overview + + In SIP-based media networks (RFC 3261 [10]), 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. + + Multifunction media servers provide network media services to clients + using server protocols such as SIP, often in conjunction with markup + languages such as VoiceXML [20] and MSCML [21]. This document + describes how to identify to a multifunction media server what sort + of session the client is requesting, without modifying the SIP + protocol. + + It is critically important to note that the mechanism described here + in no way modifies the SIP protocol, the meaning, or definition of a + SIP Request URI, or does it put any restrictions, in any way, on + devices that do not implement this convention. + + + + + +Burger, et al. Informational [Page 2] + +RFC 4240 SIP Media Services December 2005 + + + 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. + + Media mixing is the act of mixing different RTP streams, as described + in RFC 3550 [13]. Note that the service described here suffices for + simple mixing of media for a basic conferencing service. This + service does not address enhanced conferencing services, such as + floor control, gain control, muting, subconferences, etc. MSCML [21] + addresses enhanced conferencing. However, that is beyond the scope + of this document. Interested readers should read conferencing- + framework [22] 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 [20] or MSCML [21]. + +1.1. Conventions Used in This Document + + RFC 2119 [6] the interpretations for the key words "MUST", "MUST + NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", + "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. + +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. Multifunction + media servers do not have users. Thus we use the user address, or + the left-hand-side of the URI, as a service indicator. + + The use of the user part of the SIP Request URI has a number of + useful properties: + + o There is no change to core SIP. + o Only devices that choose to conform to this standard have to + implement it. + o This document only applies to multifunction SIP-controlled media + servers. + o This document has no impact on non-multifunction SIP-controlled + media servers. + o The mechanism described in this document has absolutely no impact + on SIP devices other than media servers. + + + + + +Burger, et al. Informational [Page 3] + +RFC 4240 SIP Media Services December 2005 + + + The last bullet point is crucial. In particular, the user part + convention described here places absolutely no restrictions on any + SIP user agent, proxy, back-to-back user agent (B2BUA), or any future + device. The user parts defined here only apply to multifunction + media servers that chose to implement the convention. With the + exception of a conforming media server, these user names and + conventions have no impact on the user part namespace. They do not + restrict the use of these user names at devices other than a + multifunction media server. + + Note that the set of services is small, well defined, and well + contained. The section The User Part (Section 7) discusses the + issues with using a fixed set of user-space names. + + For per-service security, the media server SHOULD use the security + protocols described in RFC 3261 [10]. + + The media server MAY issue 401 challenges for authentication. The + media server SHOULD support the sips: scheme for the announcement + service. The media server MUST support the sips: scheme for the + dialog and conference services. The level of authentication to + require for each service is a matter of local policy. + + The media server, upon receiving an 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 RFC 3261 [10], 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 %3D). + + 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=value + pairs. + + 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. + + + + +Burger, et al. Informational [Page 4] + +RFC 4240 SIP Media Services December 2005 + + + 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. + + If the media server can perform the requested service, it does so, + following the processing steps described in the service definition + 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. RFC 3261 [10] 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. + +3. Announcement Service + + A network announcement is the delivery of a multimedia 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 Public Switched Telephone Network (PSTN) is whether answer + supervision is supplied (i.e., does the announcement server answer + the call prior to delivering the announcement?). + + + + + + +Burger, et al. Informational [Page 5] + +RFC 4240 SIP Media Services December 2005 + + + 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 requested object and issues a BYE + to the requesting device. + + If the media server supports announcements, but it cannot find the + referenced URI, it MUST respond with the 404 response code and SHOULD + send the reason phrase "Announcement content not found". + + If the media server receives an INVITE for the announcement service + without a "play=" parameter, it MUST respond with the response code + 400 and SHOULD send the reason phrase "Mandatory play parameter + missing". + + If there is an error retrieving the announcement, the media server + MUST respond with a 400 response code and SHOULD send the reason + phrase "Announcement content could not be retrieved". 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: + + play + Specifies the resource or announcement sequence to be played. + + repeat + Specifies how many times the media server should repeat the + announcement or sequence named by the "play=" parameter. The + value "forever" means the repeat should be effectively unbounded. + In this case, it is RECOMMENDED the media server implements some + local policy, such as limiting what "forever" means, to ensure + errant clients do not create a denial of service attack. + + 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 + + + +Burger, et al. Informational [Page 6] + +RFC 4240 SIP Media Services December 2005 + + + maximum duration has been reached. The duration is measured in + milliseconds. + + locale + Specifies the language and optionally country variant of the + announcement sequence named in the "play=" parameter. RFC 3066 + [9] specifies the locale tag. The locale tag is usually a two- or + three-letter code per ISO 639-1 [11]. The country variant is also + often a two-letter code per ISO 3166-1 [12]. These elements are + concatenated with a single under bar (%x5F) character, such as + "en_CA". If only the language is specified, such as locale=en, + the choice of country variant is an implementation matter. + Implementations SHOULD provide the best possible match between the + requested locale and the available languages in the event the + media server cannot honor the locale request precisely. For + example, if the request has locale=ca_FR, but the media server + only has fr_FR available, the media server should use the fr_FR + variant. Implementations SHOULD provide a default locale to use + if no language variants are available. + + 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. + + extension + Provides a mechanism for extending the parameter set. If the + media server receives an extension it does not understand, it MUST + silently ignore the extension parameter and value. + + The "play=" parameter is mandatory and MUST be present. All other + parameters are OPTIONAL. + + NOTE: Some encodings are not self-describing. Thus, the + implementation relies on filename extension conventions for + determining the media type. + + Note that RFC 3261 [10] 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 the + likely scenarios for the 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 that its choice of proxy + preserves parameters. + + + + +Burger, et al. Informational [Page 7] + +RFC 4240 SIP Media Services December 2005 + + + 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 + + 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. + + 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. + + It is important to note that the mechanism described here in no way + modifies the behavior of SIP [10]. In particular, this convention + does not modify SDP negotiation [18]. + + The proxy issues an INVITE to the media server, requesting the + appropriate prompt to play coded in the play= parameter. The media + server responds with 200 OK. The proxy relays the 200 OK to the + caller. The caller then issues an ACK. The proxy then relays the + ACK to the media server. + + With the call 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. + + + + + + + + + + + + + + + +Burger, et al. Informational [Page 8] + +RFC 4240 SIP Media Services December 2005 + + +3.2. Protocol Diagram + + Caller Proxy Media Server + | INVITE | | + |----------------------->| INVITE | + | 100 TRYING |----------------------->| + |<-----------------------| 200 OK | + | 200 OK |<-----------------------| + |<-----------------------| | + | ACK | | + |----------------------->| ACK | + | |----------------------->| + | | | + | Play Announcement (RTP) | + |<================================================| + | | | + | | BYE | + | BYE |<-----------------------| + |<-----------------------| | + | 200 OK | | + |----------------------->| 200 OK | + | |----------------------->| + | | | + +3.3. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in RFC 4234 [7]. + + ANNC-URL = sip-ind annc-ind "@" hostport + annc-parameters uri-parameters + + sip-ind = "sip:" / "sips:" + annc-ind = "annc" + + annc-parameters = ";" play-param [ ";" content-param ] + [ ";" delay-param] + [ ";" duration-param ] + [ ";" repeat-param ] + [ ";" locale-param ] + [ ";" variable-params ] + [ ";" extension-params ] + + play-param = "play=" prompt-url + + content-param = "content-type=" MIME-type + + delay-param = "delay=" delay-value + + + +Burger, et al. Informational [Page 9] + +RFC 4240 SIP Media Services December 2005 + + + delay-value = 1*DIGIT + + duration-param = "duration=" duration-value + + duration-value = 1*DIGIT + + repeat-param = "repeat=" repeat-value + + repeat-value = 1*DIGIT / "forever" + + locale-param = "locale=" token + ; per RFC 3066, usually + ; ISO639-1_ISO3166-1 + ; e.g., en, en_US, en_UK, etc. + + variable-params = param-name "=" variable-value + + param-name = "param" DIGIT ; e.g., "param1" + + variable-value = 1*(ALPHA / DIGIT) + + extension-params = extension-param [ ";" extension-params ] + + extension-param = token "=" token + + "uri-parameters" is the SIP Request-URI parameter list as described + in RFC 3261 [10]. All parameters of the Request URI are part of the + URI matching algorithm. + + The MIME-type is the MIME [1] [2] [3] [4] [5] content type for the + announcement, such as audio/basic, audio/G729, audio/mpeg, + video/mpeg, and so on. + + A number of MIME registrations, which could be used here, have + parameters, for instance, video/DV. To accommodate this, and retain + compatibility with the SIP URI structure, the MIME-type parameter + separator (semicolon, %3b) and value separator (equal, %d3) MUST be + 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 a tag as specified in RFC 3066 [9]. + + The definition of hostport is as specified by RFC 3261 [10]. + + + + + +Burger, et al. Informational [Page 10] + +RFC 4240 SIP Media Services December 2005 + + + The syntax of prompt-url consists of a URL scheme as specified by RFC + 3986 [8] or a special token indicating a provisioned announcement + sequence. For example, the URL scheme MAY include any of the + following. + + o http/https + o ftp + o file (referencing a local or NFS (RFC 3530 [16]) object) + o nfs (RFC 2224 [14]) + + If a provisioned announcement sequence is to be played, the value of + prompt-url will have the following form: + + prompt-url = "/provisioned/" announcement-id + + announcement-id = 1*(ALPHA / DIGIT) + + Note that the scheme "/provisioned/" was chosen because of a + hesitation to register a "provisioned:" URI scheme. + + This document is strictly focused on the SIP interface for the + announcement service and, as such, does not detail how announcement + sequences are provisioned or defined. + + Note that the media 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. + +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. + + Although not good VoiceXML programming practice, VoiceXML scripts + might contain sensitive information, such as a user's pass code in a + + + +Burger, et al. Informational [Page 11] + +RFC 4240 SIP Media Services December 2005 + + + DTMF grammar. Thus, the media server MUST support the https scheme + for the voicexml parameter for secure fetching of scripts. Likewise, + dynamic grammars often do have user-identifying information. As + such, the VoiceXML browser implementation on the media server MUST + support https fetching of grammars and subsequent documents. + + Returned information often is sensitive. For example, the + information could be financial information or instructions. Thus, + the media server MUST support https posting of results. + +4.1. Formal Syntax for Prompt and Collect Service + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in RFC 4234 [7]. + + DIALOG-URL = sip-ind dialog-ind "@" hostport + dialog-parameters + + sip-ind = "sip:" / "sips:" + dialog-ind = "dialog" + + dialog-parameters = ";" dialog-param [ vxml-parameters ] + [ uri-parameters ] + + dialog-param = "voicexml=" vxml-url + + vxml-parameters = vxml-param [ vxml-parameters ] + + vxml-param = ";" vxml-keyword "=" vxml-value + + vxml-keyword = token + + vxml-value = token + + The vxml-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. + + If there is a vxml-keyword without a corresponding 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" + in the reason phrase. + + The media server presents the parameters as environment variables in + the connection object. Specifically, the parameter appears in the + connection.sip tree. + + + + +Burger, et al. Informational [Page 12] + +RFC 4240 SIP Media Services December 2005 + + + If the Media Server does not support the passing of keyword-value + pairs to the VoiceXML interpreter session, it MUST ignore the + parameters. + + "uri-parameters" is the SIP Request-URI parameter list as described + in RFC 3261 [10]. All parameters in the parameter list, whether they + come from uri-parameters or from vxml-keyworks, are part of the URI + matching algorithm. + +5. Conference Service + + One 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=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 uniqueIdentifier can 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. + + In the terminology of the conferencing framework [22], 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. + + As a focus in the conferencing framework, the media server MUST + support the ";isfocus" parameter in the Request URI. Note, however, + that the presence or absence of the ";isfocus" parameter has no + protocol impact at the media server. + + It is worth noting that the conference URI shared between the + application and media servers 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. + + + + + +Burger, et al. Informational [Page 13] + +RFC 4240 SIP Media Services December 2005 + + + One can add additional legs to the conference by INVITEing them to + the above-mentioned request URI. Per the matching rules of RFC 3261 + [10], 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 MUST respond with a 404 NOT + FOUND. + + NOTE: The media server could create a unique conference instance + and return the conf-id string to the User Agent Clinet (UAC) if + there is no conf-id present. However, such an operation may have + other operational issues, such as permissions and billing. Thus + an application server or proxy is a better place to do such an + operation. Moreover, such action would make the media server into + a Conference Factory in the terminology of conference-framework + [22]. That is not the appropriate behavior for a media server. + + Since some conference use cases, such as business conferencing, have + billing implications, the media server SHOULD authenticate the + application server or proxy. At a minimum, the media server MUST + implement sips:. + +5.1. Protocol Diagram + + This diagram shows the establishment of a three-way conference. This + section is informative. It is only one method of establishing a + conference. This example shows a simple back-to-back user agent. + + The conference-framework [22] describes additional parameters and + behaviors of the Application Server. For example, the first INVITE + from P1 to the Application Server would include the ";isfocus" + parameter; the Application Server would act as a Conference Factory; + and so on. However, none of that protocol machinery has an impact on + the operation of the Application Server to Media Server interface, + which is the focus of this protocol document. + + + + + + + + + + + +Burger, et al. Informational [Page 14] + +RFC 4240 SIP Media Services December 2005 + + + P1 P2 P3 Application Server Media Server + | | | | | + | INVITE sip:public-conf@as.example.net | + |---------------------------------->| | + | | | INVITE sip:conf=123@ms.example.net | + | | | |------------------>| + | | | | 200 OK | + | 200 OK | |<------------------| + |<----------------------------------| | + | ACK | | | | + |---------------------------------->| ACK | + | | | |------------------>| + | | | RTP w/ P1 | | + |<=====================================================>| + | | | | | + | INVITE sip:public-conf@as.example.net | + | |-------------------------->| | + | | | INVITE sip:conf=123@ms.example.net | + | | | |------------------>| + | | | | 200 OK | + | | 200 OK | |<------------------| + | |<--------------------------| | + | | ACK | | | + | |-------------------------->| ACK | + | | | |------------------>| + | | | | | + | | | RTP w/ P1+P2-P2 | | + | |<=============================================>| + | | | RTP w/ P1+P2-P1 | | + |<=====================================================>| + | | | | | + | INVITE sip:public-conf@as.example.net | + | | |----------------->| | + | | | INVITE sip:conf=123@ms.example.net | + | | | |------------------>| + | | | | 200 OK | + | | | 200 OK |<------------------| + | | |<-----------------| | + | | | ACK | | + | | |----------------->| ACK | + | | | |------------------>| + | | | | | + | | | RTP w/ P1+P2+P3-P3 | + | | |<====================================>| + | | | RTP w/ P1+P2+P3-P2 | + | |<=============================================>| + | | | RTP w/ P1+P2+P3-P1 | + |<=====================================================>| + + + +Burger, et al. Informational [Page 15] + +RFC 4240 SIP Media Services December 2005 + + + | | | | | + | | | | | + + Using the terminology of conference-framework [22], 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 messages + that would typically flow from the Application Server to the UACs; + nor does it show the ACKs from the UACs 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 + (UACs). 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 RFC 4234 [7]. + + CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport + [ uri-parameters ] + + sip-ind = "sip:" / "sips:" + + conf-ind = "conf" + + instance-id = token + + "uri-parameters" is the SIP Request-URI parameter list as described + in RFC 3261 [10]. All parameters in the parameter list are part of + the URI matching algorithm. + + + + + + + +Burger, et al. Informational [Page 16] + +RFC 4240 SIP Media Services December 2005 + + +6. IANA Considerations + + The IANA has registered the following parameters in the SIP/SIPS URI + Parameters registry, following the specification required policy of + RFC 3969 [19]: + + Parameter Name Predefined Values Reference + -------------- ----------------- --------- + play no RFC 4240 + repeat no RFC 4240 + delay no RFC 4240 + duration no RFC 4240 + locale no RFC 4240 + param[n] no RFC 4240 + extension no RFC 4240 + +7. The User Part + + There has been considerable discussion 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 address the latter issue first. The common example is the + Postmaster address defined by RFC 2821 [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. + However, one may debate whether this is a significant limitation. + + This document explicitly addresses this issue. The user names + described in the text (namely annc, ivr, dialog, and conf) are + available for whatever local use a given SIP user agent or proxy + wishes for them. What this document does is give special meaning for + these user names at media servers that implement this specification. + If a media server chooses not to implement this specification, + nothing breaks. If a user wishes to use one of the user names + described in this document at their SIP user agent, nothing breaks + and their user agent will work as expected. + + The key point is, 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@example.net". We offer there is ABSOLUTELY NO NAME + COLLISION WHATSOEVER. Why is this so? This is so because + sip:annc@example.net will resolve to the specific user at a specific + + + +Burger, et al. Informational [Page 17] + +RFC 4240 SIP Media Services December 2005 + + + device for Ann. As an example, example.net's SIP Proxy Server + resolves sip:annc@example.net to annc@anns-phone.example.net. + Conversely, one directs requests for the media service annc directly + to the Media Server, e.g., sip:annc@ms21.ap.example.net. Moreover, + by definition, requests for Ann Charles, or anything other than the + announcement service, will NEVER be directly sent to the Media + Server. If that were not true, no phone in the world could use the + user part "eburger", as eburger is a reserved user part in the + Brooktrout domain. Clearly, this is not the case. + + If one wishes to make their media server accessible to the global + Internet, but retain one of the Media Server-specific user names in + the domain, a SIP Proxy can easily translate whatever opaque name one + chooses to the Media Server-specific user name. For example, if a + domain wishes to offer services for the above mentioned Ann Charles + at sip:annc@example.com, they can offer the announcement service at + sip:my-special-announcement-service@example.com. The former address, + sip:annc@example.com, would resolve to the actual device where annc + resides. The latter would resolve to the media server announcement + server address, sip:annc@mediaserver.example.com, as an example. + Note that this convention makes it easier to provision this service. + With a fixed mapping at the multifunction media server, there are + less provisioning data elements to get wrong. + + Here is another way of looking at this issue. Unix reserves the + special user "root". Just about all Unix machines have a user root, + who has an address "root@a-specific-machine.example.com", where + "a-specific-machine" is the fully-qualified domain name (FQDN) of a + particular instance of a machine. There are very well-defined + semantics for the "root" user. + + Even though most every Unix machine has a "root" user, often there is + no mapping for a "root" user in a domain, such as "root@example.com". + Conversely, there is no restriction on creating an MX record for + "root@example.com". That choice is fully up to the administrative + authority for the domain. + + The "users" proposed by this document, "annc", "conf", and "dialog" + are all users at a Media Server, just as the "root", "bin", and + "nobody" users are "users" at a Unix host. + + After much discussion, with input from the W3C URI work group, we + considered obfuscating the user name by prepending "__sip-" to the + user name. However, as explained above, this obfuscation is not + necessary. There is a fundamental difference between a user name at + a device and a user name at an MX record (SMTP) or Address-of-Record + (SIP). Again, there is no possibility that the name on the device + may "leak out" into the SIP routing network. + + + +Burger, et al. Informational [Page 18] + +RFC 4240 SIP Media Services December 2005 + + + The most important thing to note about this convention is that the + left-hand side of the request URI is opaque to the network. The only + network elements that need to know about the convention are the Media + Server and client. Even proxies doing mapping resolution, as in the + example above for public announcement services, do not need to be + aware of the convention. The convention is purely a matter of + provisioning. + + Some have proposed that such naming be a pure matter of local + convention. For example, the thesis of the informational RFC RFC + 3087 [17] is that you can address services using a request URI. + However, some have taken the examples in the document to an extreme. + Namely, that the only way to address services is via arbitrary, + opaque, long user parts. Clearly, it is possible to provision the + service names, rather than fixed names. While this can work in a + closed network, where the Application Servers and Media Servers are + in the same administrative domain, this does not work across domains, + such as in the Internet. This is because the client of the media + service has to know the local name for each service / domain pair. + This is particularly onerous for situations where there is an ad hoc + relationship between the application and the media service. Without + a well-known relationship between service and service address, how + would the client locate the service? + + One very important result of using the user part as the service + descriptor is that we can use all of the standard SIP machinery, + without modification. For example, Media Servers with different + capabilities can SIP Register their capabilities as users. For + example, a VoiceXML-only device will register the "dialog" user, + while a multi-purpose Media Server will register all of the users. + Note that this is why the URI to play is a parameter. Doing + otherwise would overburden a normal SIP proxy or redirect server. + Conversely, having the conference ID be part of the user part gives + an indication that requests get routed similarly (as opposed to + requiring a Globally Routable User Agent URI (GRUU), which would + restrict routing to the same device). + + 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 Media Servers can + register with a SIP redirect server for the annc user. If one of the + Media Servers fails, the registration will expire and all requests + for the announcement service ("calls to the annc user") will get sent + to the surviving Media Server. + + + + + + + +Burger, et al. Informational [Page 19] + +RFC 4240 SIP Media Services December 2005 + + +8. Security Considerations + + Exposing network services with well-known addresses may not be + desirable. The Media Server SHOULD authenticate and authorize + requesting endpoints per local policy. + + Some interactions in this document result in the transfer of + confidential information. Moreover, many of the interactions require + integrity protection. Thus, the Media Server MUST implement the + sips: scheme. In addition, application developers are RECOMMENDED to + use the security services offered by the Media Server to ensure the + integrity and confidentiality of their user's data, as appropriate. + + Untrusted network elements could use the convention 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 + announcement service. This is one of the reasons why the early media + announcement service is deprecated. + + Services such as repeating an announcement forever create the + possibility for denial of service attacks. The media server SHOULD + have local policies to deal with this, such as time-limiting how long + "forever" is, analyzing where multiple requests come from, + implementing white-lists for such a service, and so on. + +9. Contributors + + Jeff Van Dyke and Andy Spitzer of SnowShore did just about all of the + work developing netann, in conjunction with many application + developers, media server manufacturers, and service providers, some + of whom are listed in the Acknowledgements section. All I did was do + the theory and write it up. That also means all of the mistakes are + mine, as well. + +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 the request 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 of the document. Pete Danielsen from Lucent has consistently + provided excellent reviews of the many different versions of this + document. + + + +Burger, et al. Informational [Page 20] + +RFC 4240 SIP Media Services December 2005 + + + Pascal Jalet provided the theoretical underpinning and David Rio + provided the experimental evidence for why the conference identifier + belongs in the user part of the request-URI. + + I am particularly indebted to Alan Johnston for his review of this + document and ensuring its conformance with the SIP conference control + work in the IETF. + + Mary Barnes, as usual, found the holes and showed how to fix them. + + The authors would like to give a special thanks to Walter O'Connor + for doing much of the initial implementation. + + Note that at the time of this writing, there are 7 known independent + server implementations that are interoperable with 23 known client + implementations. Our apologies if we did not count your + implementation. + +11. References + +11.1. Normative References + + [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part + Three: Message Header Extensions for Non-ASCII Text", RFC 2047, + November 1996. + + [4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet + Mail Extensions (MIME) Part Four: Registration Procedures", + BCP 13, RFC 2048, November 1996. + + [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, November 1996. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + + + +Burger, et al. Informational [Page 21] + +RFC 4240 SIP Media Services December 2005 + + + [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, + January 2005. + + [9] Alvestrand, H., "Tags for the Identification of Languages", + BCP 47, RFC 3066, January 2001. + + [10] 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. + + [11] International Organization for Standardization, "Codes for the + representation of names of languages -- Part 1: Alpha-2 code", + ISO Standard 639-1, July 2002. + + [12] International Organization for Standardization, "Codes for the + representation of names of countries and their subdivisions -- + Part 1: Country codes", ISO Standard 3166-1, October 1997. + +11.2. Informative References + + [13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + + [14] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. + + [15] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [16] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, + C., Eisler, M., and D. Noveck, "Network File System (NFS) + version 4 Protocol", RFC 3530, April 2003. + + [17] Campbell, B. and R. Sparks, "Control of Service Context using + SIP Request-URI", RFC 3087, April 2001. + + [18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [19] Camarillo, G., "The Internet Assigned Number Authority (IANA) + Uniform Resource Identifier (URI) Parameter Registry for the + Session Initiation Protocol (SIP)", BCP 99, RFC 3969, + December 2004. + + + + + + + +Burger, et al. Informational [Page 22] + +RFC 4240 SIP Media Services December 2005 + + + [20] Burnett, D., Hunt, A., McGlashan, S., Porter, B., Lucas, B., + Ferrans, J., Rehor, K., Carter, J., Danielsen, P., and S. + Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version + 2.0", W3C REC REC-voicexml20-20040316, March 2004. + + [21] Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media Server + Control Markup Language (MSCML) and Protocol", Work in + Progress, December 2004. + + [22] Rosenberg, J., "A Framework for Conferencing with the Session + Initiation Protocol", Work in Progress, October 2004. + +Authors' Addresses + + Eric Burger + Brooktrout Technology, Inc. + 18 Keewaydin Dr. + Salem, NH 03079 + USA + + EMail: eburger@brooktrout.com + + + Jeff Van Dyke + Brooktrout Technology, Inc. + 18 Keewaydin Dr. + Salem, NH 03079 + USA + + EMail: jvandyke@brooktrout.com + + + Andy Spitzer + Brooktrout Technology, Inc. + 18 Keewaydin Dr. + Salem, NH 03079 + USA + + EMail: woof@brooktrout.com + + + + + + + + + + + + +Burger, et al. Informational [Page 23] + +RFC 4240 SIP Media Services December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Burger, et al. Informational [Page 24] + -- cgit v1.2.3