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.
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.
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.
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 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.
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
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.
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.
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.
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