RFC 4240
Basic Network Media Services with SIP
Basic Network Media Services with SIP 🎀
Okay bestie, this is RFC 4240 💖 It was written by E. Burger (Ed.), J. Van Dyke, and A. Spitzer, all from Brooktrout Technology, Inc., and it's dated December 2005. Its category is Informational, so it's giving "useful info for the Internet community" and is not an Internet standard 🧚 The title block doesn't list any RFC it obsoletes or updates, so it's just vibing on its own 🦋
Network Working Group, if you're wondering, is the group that handled it 💅
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 💜
So in SIP-based networks, we really need basic network media services 📞 Think network announcements, user interaction, and conferencing. These are the building blocks you can mix together to make cute applications 🧱 For servers offering these blocks (called Media Servers) and the app developers using them to actually work together, you need a clear, well-defined way to find and call these services 🤝
This document describes a mechanism for an interoperable interface between Application Servers, which give application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. It's giving "two different systems, one clean handshake" 🫶
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 ...................................221. Overview 🌸
In SIP-based media networks (RFC 3261 [10]), there is a real need to provide basic network media services. We're talking about playing announcements, starting a media mixing session (a conference), and prompting a user and collecting what they type or say 🎙️
These services are basic in nature, there are only a few of them, and they've basically stayed the same for 25 years of enhanced telephony services 🕰️ Honestly, since they're so elemental, you wouldn't expect them to change in the future either 💅
Multifunction media servers give network media services to clients using server protocols such as SIP, often together with markup languages like VoiceXML [20] and MSCML [21]. This document explains how to tell a multifunction media server what kind of session the client wants, without modifying the SIP protocol ✨
It's 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. Nobody else's life gets harder 🙈
Announcements are media played to the user. They 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]. The service described here is enough for simple mixing of media for a basic conferencing service. It does not cover enhanced conferencing features like floor control, gain control, muting, subconferences, etc. 🙅♀️ MSCML [21] handles enhanced conferencing, but that's beyond the scope of this document. If you want the big-picture IETF SIP conferencing stuff, check out conferencing-framework [22] 📚
Prompt and collect is where the server prompts the user for some information, just like an announcement, and then collects the user's response 🔢 This can be a simple one-step thing, for example playing an announcement, "Please enter your pass code", and then collecting a string of digits. It can also be a more complex interaction, specified by something like 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. Those capitalised words are the ones with the special meanings, so keep an eye out for them 👀
2. Mechanism 🦋
In SIP control of media servers, we take advantage of the fact that the standard SIP URI has a user part. Multifunction media servers don't have users, though. So we use the user address, the left-hand side of the URI, as a service indicator 🎯
The use of the user part of the SIP Request URI has a bunch of useful properties:
- There is no change to core SIP. ✨
- Only devices that choose to conform to this standard have to implement it. 🙋♀️
- This document only applies to multifunction SIP-controlled media servers.
- This document has no impact on non-multifunction SIP-controlled media servers.
- The mechanism described in this document has absolutely no impact on SIP devices other than media servers. 💅
The last bullet point is crucial 🔥 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. Except for a conforming media server, these user names and conventions have no impact on the user part namespace. They don't restrict the use of these user names at devices other than a multifunction media server 🫶
The set of services is small, well defined, and well contained 📦 The section The User Part (Section 7) talks about the issues with using a fixed set of user-space names, so go check that out later 👑
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. How much 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). Yes, that's strict, and it's also how you keep things from getting messy 💀
The service name MAY have long- and short-forms, the same way SIP does for headers 🌈
A given service indicator MAY have an associated set of parameters. Those parameters MUST follow the convention set out for SIP URI parameters. That means a semi-colon separated list of keyword=value pairs 🍓
Certain services may be tied to a unique service instance on the media server. For example, one 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 🧩 Since the service indicator is case insensitive, the service instance identifier is also case insensitive, so no cap, it's consistent all the way down 🔁
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 doesn't recognise the service indicator, it MUST respond with the response code 488 NOT ACCEPTABLE HERE. This is the right move, because 488 is about a problem with the user part of the URI. 606 is not appropriate, since some other media server might be able to handle the request 🙅♀️ RFC 3261 [10] describes the 488 and 606 response codes, so read that if you want the full tea ☕
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 instance exists on the media server, the media server MUST respond with the response code 404 NOT FOUND 🙈 This makes sense because the service itself exists on the media server, but that particular instance doesn't. It's giving "the user wasn't home" energy 🏠
3. Announcement Service ✨
okay so a network announcement is basically when a multimedia resource (like a prompt file) gets delivered to a terminal device 🎀 and the resource can be pretty much any multimedia object the media server supports 💅 This service can play one object that has multiple streams, like a video plus audio prompt 🎶 BUT it cannot play multiple objects on the same SIP dialog, so don't even try 🙅♀️
There are two types of network announcements, and the main difference is whether the network has fully set up the SIP dialog before the announcement starts 👀 In PSTN terms, this is basically asking whether answer supervision is supplied (aka, does the announcement server pick up the call before it plays the announcement?) 📞
Playing an announcement after call setup is super straightforward 🦋 The requesting device sends an INVITE to the media server asking for the announcement service. The media server negotiates the SDP and sends back a 200 OK. Once it gets the ACK from the requesting device, it plays the requested object and then sends a BYE to the requesting device. Easy peasy 🫶
Now for the error vibes 😭 If the media server supports announcements but can't find the referenced URI, it MUST respond with the 404 response code, and it SHOULD send the reason phrase "Announcement content not found". 💀
If the media server gets an INVITE for the announcement service with no play= parameter, it MUST respond with the response code 400, and it SHOULD send the reason phrase "Mandatory play parameter missing". Not it. 🙈
If there's an error retrieving the announcement, the media server MUST respond with a 400 response code, and it SHOULD send the reason phrase "Announcement content could not be retrieved". On top of that, the media server SHOULD include a Warning header with appropriate explanatory text about what failed 🌸
The Request URI fully describes the announcement service through the user part of the address plus some additional URI parameters ✨ The user portion, "annc", specifies the announcement service on the media server, and the service has several associated URI parameters that control the content and delivery of the announcement 🧚
Here's the parameter lineup 👑
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 theplay=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, so that errant clients can't create a denial of service attack. 🚨delay: Specifies a delay interval between announcement repetitions, 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. This is also measured in milliseconds 🛑locale: Specifies the language and optionally the country variant of the announcement sequence named in theplay=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 get concatenated with a single under bar (%x5F) character, such as"en_CA". If only the language is specified, such aslocale=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 if the media server can't honor the locale request precisely. For example, if the request haslocale=ca_FRbut 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 get 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.
Quick heads up, 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 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 🫧
The form of the SIP Request URI for announcements looks like this. The backslash, CRLF, and spacing before the "play=" in the examples are just for readability 📖
sip:annc@ms2.example.net; \
play=http://audio.example.net/allcircuitsbusy.g711
sip:annc@ms2.example.net; \
play=file://fileserver.example.net//geminii/yourHoroscope.wav3.1. Operation
The scenarios below assume there's a SIP Proxy, application server, or media gateway controller between the caller and the media server 🎀 BUT the announcement service still works the same way if the caller invokes the service directly. We chose to talk about the proxy case because it'll be the most common one 💅
The caller sends an INVITE to the serving SIP Proxy. The SIP Proxy figures out what audio prompt to play to the caller, and it replies to the caller with 100 TRYING 🦋
It's 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]. No messing with the core protocol, bestie 🙅♀️
The proxy sends an INVITE to the media server, requesting the appropriate prompt coded in the play= parameter. The media server responds with 200 OK, and the proxy relays that 200 OK to the caller. The caller then sends an ACK, and the proxy relays the ACK to the media server 🫶
With the call established, the media server plays the requested prompt. When it finishes, it sends a BYE to the proxy, and then the proxy sends a BYE to the caller 👋
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]. Let's get into the grammar 🤓
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
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 🎞️
Some MIME registrations have parameters, like video/DV, which is where things get spicy 🌶️ To accommodate this and keep 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-50The locale-value consists of a tag as specified in RFC 3066 [9] 🌈
The definition of hostport is as specified by RFC 3261 [10] 💜
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:
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 ✨
okay so this one is also called a voice dialog 🎙️ and it's all about having an aural dialog with the user. it's giving "talk to the caller," and honestly it's iconic 💅
The dialog service follows the model of the announcement service. The difference is the service indicator, which is dialog 🫶 The dialog service takes a parameter, voicexml=, that points at the URI of the VoiceXML script to run:
sip:dialog@mediaserver.example.net; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxmlA Media Server MAY accept additional SIP request URI parameters and deliver them to the VoiceXML interpreter session as session variables 🧚
ngl this next part is the serious bit 😭 Putting stuff like a user's pass code in a DTMF grammar is not good VoiceXML practice, but scripts might still do it, and that is so not it. So the media server MUST support the https scheme for the voicexml parameter, so scripts get fetched securely 🔒 Dynamic grammars often carry user-identifying info too, so the VoiceXML browser implementation on the media server MUST support https fetching of grammars and subsequent documents. Main character energy for privacy 👑
Returned info is also very often sensitive, think financial info or instructions 💸 So the media server MUST support https posting of results. No exceptions, bestie 🫶
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 = tokenThe vxml-url is the URI of the VoiceXML script. If it's present, other parameters get passed to the VoiceXML interpreter session as the assigned vxml-keyword vxml-value pairs. Note that all vxml-keywords MUST have values, no empty vibes allowed 🙅♀️
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. On top of that, 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 🌳
If the Media Server does not support passing 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 that list, whether they come from uri-parameters or from vxml-keyworks, are part of the URI matching algorithm 🦋
5. Conference Service
okay conference time 🎀 One identifies mixing sessions through their SIP request URIs. To create a mixing session, you send an INVITE to a request URI that represents the session. If the URI doesn't already exist on the media server and the requested resources are available, the media server creates a new mixing session. If there's already an existing URI for the session, the media server treats it as a request for the new session to join the existing one. The form of the SIP request URI for conferencing is:
sip:conf=uniqueIdentifier@mediaserver.example.netThe 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 identifies a particular media server. The "conf" user name tells 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's the responsibility of the conference control application to make sure 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's worth noting that the conference URI shared between the application and media servers provides enhanced security, since the SIP control interface doesn't have to be exposed to participants 🔒 It also lets the assignment of a specific media server be delayed as long as possible, which simplifies resource management. Iykyk 🧠
One can add more legs to the conference by INVITEing them to the request URI above. 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 therefore the conference-specific request URI, stays active as 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 doesn't 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's only one method of establishing a conference, and 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 affects the operation of the Application Server to Media Server interface, which is the focus of this protocol document 🦋
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 |
|<=====================================================>|
| | | | |
| | | | |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 call flow above doesn't show any 100 TRYING messages that would typically flow from the Application Server to the UACs. It also doesn't 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, depending on the respective disconnect case 👋
It is left as a trivial exercise to the reader 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. Both roles at once, that's a whole main character arc 👑
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 🦋
6. IANA Considerations ✨
okay so IANA has registered some parameters in the SIP/SIPS URI Parameters registry 📋 under the specification required policy of RFC 3969 [19] 💅 and here's the whole list, no cap:
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 42407. The User Part 🎀
okay bestie, there's been a LOT of debate about whether it's smart to use fixed user parts in a request URI 🤔 the big objection is that the user part should be opaque and a local matter, and the other one is that using a fixed user part removes those user addresses from the user address space 😤
let's tackle the second one first 💜 the classic example is the Postmaster address from RFC 2821 [15]. the complaint is that if you use the Postmaster token for something special, you've taken that token away from everyone. so the Postmaster General of the United States literally cannot have Postmaster@usps.gov 📭 honestly though, people can argue about whether that's a big deal or not.
this doc is totally upfront about this issue 🫶 the user names in the text (annc, ivr, dialog, and conf) are free for whatever local use a SIP user agent or proxy wants to give them. what this doc does is give them special meaning at media servers that implement this spec ✨ if a media server doesn't implement it, nothing breaks 🙌 and if a user wants to use one of these names at their SIP user agent, nothing breaks and their user agent works exactly as expected 💖
the big takeaway is that you can't mix up the namespace at a Media Server with the namespace for an organization 🧚 like, say a network offers services for "Ann Charles" and she likes the name "annc", so she'd want sip:annc@example.net. we're claiming there is ABSOLUTELY NO NAME COLLISION WHATSOEVER 🙈 why? because sip:annc@example.net resolves to the specific user at a specific device for Ann 📱 example.net's SIP Proxy Server resolves sip:annc@example.net to annc@anns-phone.example.net. meanwhile, requests for the media service annc get pointed directly at the Media Server, like sip:annc@ms21.ap.example.net 🎯 and by definition, requests for Ann Charles, or anything that isn't the announcement service, will NEVER be sent directly to the Media Server 🚫 if that weren't true, no phone in the world could use the user part "eburger", since eburger is a reserved user part in the Brooktrout domain 😭 and clearly, that's not the case, so we're good.
if someone wants their media server reachable on the global Internet but still wants to keep one of the Media Server-specific user names in the domain, a SIP Proxy can easily map whatever opaque name they pick to the Media Server-specific user name 🔄 for example, if a domain wants to offer services for the Ann Charles example at sip:annc@example.com, they can offer the announcement service at sip:my-special-announcement-service@example.com 🎀 the first address, sip:annc@example.com, resolves to the actual device where annc lives. the second one resolves to the media server announcement server address, which in this example is sip:annc@mediaserver.example.com 🌸 this also makes provisioning way easier, because with a fixed mapping at the multifunction media server, there are fewer provisioning data elements to mess up 💅
here's another way to think about it 🦋 Unix reserves the special user "root". basically every Unix machine has a root user, with an address like root@a-specific-machine.example.com, where "a-specific-machine" is the fully-qualified domain name (FQDN) of a particular machine 🖥️ and "root" has super well-defined semantics.
even though almost every Unix machine has a "root" user, there's often no mapping for "root" in a domain like root@example.com 🙈 but there's also no restriction on making an MX record for root@example.com. that choice is totally up to the administrative authority for the domain 👑
so the "users" this doc proposes, "annc", "conf", and "dialog", are all users at a Media Server, the same way "root", "bin", and "nobody" are users at a Unix host 💜
after a lot of discussion, and with input from the W3C URI work group, we considered hiding the user name by adding a "__sip-" prefix 🤔 but as explained above, that obfuscation isn't necessary. there's 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's no way the name on the device can "leak out" into the SIP routing network 🛡️
the most important thing 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 the client. even proxies doing mapping resolution, like in the public announcement service example above, don't need to be aware of it. the convention is purely a matter of provisioning 📝
some people have suggested that naming should 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 💅 but some folks took the examples in that document to an extreme, namely that the only way to address services is with arbitrary, opaque, long user parts 😵 it's definitely possible to provision service names instead of fixed names. that can work in a closed network where the Application Servers and Media Servers are in the same administrative domain, but it doesn't work across domains like the Internet 🌐 the reason is that the client of the media service has to know the local name for each service/domain pair. that's especially painful when the application and media service have an ad hoc relationship. without a well-known relationship between service and service address, how would the client even find the service? 🔍
one really important result of using the user part as the service descriptor is that we can use all the standard SIP machinery, without changing anything ⚡ for example, Media Servers with different capabilities can SIP Register their capabilities as users. a VoiceXML-only device registers the "dialog" user, while a multi-purpose Media Server registers all of the users 🧚 this is also why the URI to play is a parameter. doing it otherwise would overburden a normal SIP proxy or redirect server 🙅♀️ and having the conference ID be part of the user part signals that requests get routed similarly, as opposed to needing a Globally Routable User Agent URI (GRUU), which would restrict routing to the same device 🎯
this scheme also lets us use the standard SIP proxy behavior of 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 them fails, the registration expires and all requests for the announcement service ("calls to the annc user") get sent to the surviving Media Server 💖
8. Security Considerations 🔐
okay this one is SERIOUS, bestie 😤 exposing network services at well-known addresses might not be desirable. the Media Server SHOULD authenticate and authorize requesting endpoints per local policy 🛡️
some interactions in this document transfer confidential information 🤫 and a lot of them need integrity protection too. so the Media Server MUST implement the sips: scheme 🔒 on top of that, application developers are RECOMMENDED to use the security services the Media Server offers to protect the integrity and confidentiality of their users' data, as appropriate 💜
untrusted network elements could use this convention to provide information services 😬 lots of existing billing arrangements are for completed calls, and a successful call completion is signaled by a 2xx result code 💸 this can be a problem for the early media announcement service, which is one of the reasons the early media announcement service is deprecated 💀
services like repeating an announcement forever open the door to denial of service attacks 🚨 the media server SHOULD have local policies to handle this, like 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 🛠️ they worked with lots of application developers, media server manufacturers, and service providers, some of whom are listed in the Acknowledgements section ✨ the author's contribution was the theory and the write-up 📝 which also means any mistakes are theirs too 🙈
10. Acknowledgements 💐
we'd love to thank Kevin Summers and Ravindra Kabre of Sonus Networks for their constructive comments 🌟 and Jonathan Rosenberg of Dynamicsoft and Tim Melanchuk of Convedia for their encouragement 🥰 the discussion at the Las Vegas Interim Workgroup Meeting in 2002 was invaluable for clearing up the issues around 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 👀 and Pete Danielsen from Lucent has consistently given excellent reviews of the many versions of this document 🙌
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'm particularly indebted to Alan Johnston for his review of this document and for making sure it conforms 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 🎉 sorry in advance if we didn't count your implementation 🥺
11. References 📚
11.1. Normative References 📚
okay bestie, here's the must-read shelf 🫶 these are the docs this one leans on hard:
[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.
[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 🌸
these ones are the extra reading 💜 great for going deeper, not required to get the core vibe:
[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.
[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
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. 🫶✨
📦 where this page comes from
- ietf: rfc4240 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms