[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4240

SIPPING                                                        E. Burger
Internet-Draft                                  SnowShore Networks, Inc.
Expires: December 29, 2003                                 June 30, 2003


                 Basic Network Media Services with SIP
                     draft-burger-sipping-netann-06

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 29, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   In SIP-based networks, there is a need to provide basic network media
   services.  Such services include network announcements, user
   interaction, and conferencing services.  These services are basic
   building blocks, from which one can construct interesting
   applications.  In order to have interoperability between servers
   offering these building blocks (also known as Media Servers) and
   application developers, one needs to be able to locate and invoke
   such services in a well-defined manner.

   This document describes a mechanism for providing an interoperable
   protocol interface between Application Servers, which provide
   application services to SIP-based networks, and Media Servers, which
   provide the basic media processing building blocks.



Burger                 Expires December 29, 2003                [Page 1]

Internet-Draft             SIP Media Services                  June 2003


Conventions used in this document

   RFC2119 [1] provides the interpretations for the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.

   Note that the words "must" and "should" appear in the section Early
   Media Announcement (Section 7).  In that section, these key words do
   NOT carry the strength described in RFC2119. That section is
   informative only.

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Announcement Service . . . . . . . . . . . . . . . . . . . . .  6
   3.1 Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2 Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.3 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . .  8
   3.4 Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Prompt and Collect Service . . . . . . . . . . . . . . . . . . 12
   4.1 Formal Syntax for Prompt and Collect Service . . . . . . . . . 12
   5.  Conference Service . . . . . . . . . . . . . . . . . . . . . . 14
   5.1 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . . 15
   5.2 Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  The User Part  . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Early Media Announcement . . . . . . . . . . . . . . . . . . . 19
   7.1 IMPORTANT NOTICE . . . . . . . . . . . . . . . . . . . . . . . 19
   7.2 Description  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.3 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
       Normative References . . . . . . . . . . . . . . . . . . . . . 25
       Informative References . . . . . . . . . . . . . . . . . . . . 26
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27
       Intellectual Property and Copyright Statements . . . . . . . . 28














Burger                 Expires December 29, 2003                [Page 2]

Internet-Draft             SIP Media Services                  June 2003


1. Overview

   In SIP-based media networks (RFC3261 [2]), there is a need to provide
   basic network media services.  Such services include playing
   announcements, initiating a media mixing session (conference), and
   prompting and collecting information with a user.

   These services are basic in nature, are few in number, and
   fundamentally have not changed in 25 years of enhanced telephony
   services.  Moreover, given their elemental nature, one would not
   expect them to change in the future.

   Announcements are media played to the user.  Announcements can be
   static media files, media files generated in real-time, media streams
   generated in real-time, multimedia objects, or combinations of the
   above.

   Media mixing is the act of mixing different RTP streams, as described
   in RFC1889 [9]. Note that the service described here will suffice for
   simple mixing of media for a basic conferencing service.  One can
   create a complete conferencing service using this basic building
   block.  However, this service does not address the interesting
   application-level issues such as floor control for conferencing, etc.
   MSCML [10] addresses this need.  However, that is beyond the scope of
   this document.  Interested readers should read conferencing-framework
   [11] for details on the IETF SIP conferencing framework.

   Prompt and collect is where the server prompts the user for some
   information, as in an announcement, and then collects the user's
   response.  This can be a one-step interaction, for example by playing
   an announcement, "Please enter your pass code", followed by
   collecting a string of digits.  It can also be a more complex
   interaction, specified, for example, by VoiceXML [12] or MSCML [10].


















Burger                 Expires December 29, 2003                [Page 3]

Internet-Draft             SIP Media Services                  June 2003


2. Mechanism

   In the context of SIP control of media servers, we take advantage of
   the fact that the standard SIP URI has a user part.  Media servers do
   not have users. Thus we use the user address, or the left-hand-side
   of the URI, as a service indicator.

   Note that the set of services is small, well defined, and well
   contained.  The section The User Part (Section 6) discusses the
   issues with using a fixed set of user-space names.

   For per-service security, the media server MAY use any of the
   security protocols described in RFC3261 [2].

   The media server MAY issue 401 challenges for authentication.

   The media server, upon receiving the INVITE, notes the service
   indicator.  Depending on the service indicator, the media server will
   either honor the request or return a failure response code.

   The service indicator is the concatenation of the service name and an
   optional service instance identifier, separated by an equal sign.

   Per RFC3261 [2], the service indicator is case insensitive.  The
   service name MUST be from the set alphanumeric characters plus dash
   (US-ASCII %2C).  The service name MUST NOT include an equal sign
   (US-ASCII %3C).

   The service name MAY have long- and short-forms, as SIP does for
   headers.

   A given service indicator MAY have an associated set of parameters.
   Such parameters MUST follow the convention set out for SIP URI
   parameters.  That is, a semi-colon separated list of keyword=values.

   Certain services may have an association with a unique service
   instance on the media server.  For example, a given media server can
   host multiple, separate conference sessions.  To identify unique
   service instances, a unique identifier modifies the service name.
   The unique identifier MUST meet the rules for a legal user part of a
   SIP URI.  An equal sign, US-ASCII %3D, MUST separate the service
   indicator from the unique identifier.

   Note that since the service indicator is case insensitive, the
   service instance identifier is also case insensitive.

   The requesting client issues a SIP INVITE to the media server,
   specifying the requested service and any appropriate parameters.



Burger                 Expires December 29, 2003                [Page 4]

Internet-Draft             SIP Media Services                  June 2003


   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.  RFC3261 [2] describes the 488 and 606 response codes.

   Some services require a unique identifier.  Most services
   automatically create a service instance upon the first INVITE with
   the given identifier.  However, if a service requires an existing
   service instance, and no such service instance exists on the media
   server, the media server MUST respond with the response code 404 NOT
   FOUND.  This is appropriate as the service itself exists on the media
   server, but the particular service instance does not. It is as if the
   user was not home.
































Burger                 Expires December 29, 2003                [Page 5]

Internet-Draft             SIP Media Services                  June 2003


3. Announcement Service

   A network announcement is the delivery of an 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 PSTN is whether answer supervision is supplied; i.e. does the
   announcement server answer the call prior to delivering the
   announcement.

   Playing an announcement after call setup is straightforward.  First,
   the requesting device issues an INVITE to the media server requesting
   the announcement service.  The media server negotiates the SDP and
   responds with a 200 OK.  After receiving the ACK from the requesting
   device, the media server plays the requested object and issues a BYE
   to the requesting device.

   The operation for playing an announcement before the SIP dialog is
   fully established, as early media, is discouraged.  The section Early
   Media Announcement (Section 7) describes a method that works for such
   operations.  Note, however, that section is informative in nature.

   If the media server supports announcements, but it cannot find the
   referenced URI, it MUST respond with the 404 NOT FOUND response code.

   If the media server receives an INVITE for the announcement service
   without a "play=" parameter, it MUST respond with the 404 NOT FOUND
   response code, as there is no default value for the announcement
   service.

   If there is an error retrieving the announcement, the media server
   MUST respond with a 404 NOT FOUND response code.  In addition, the
   media server SHOULD include a Warning header with appropriate
   explanatory text explaining what failed.

   The Request URI fully describes the announcement service through the
   use of the user part of the address and additional URI parameters.
   The user portion of the address, "annc", specifies the announcement
   service on the media server.  The service has several associated URI
   parameters that control the content and delivery of the announcement.
   These parameters are described below:




Burger                 Expires December 29, 2003                [Page 6]

Internet-Draft             SIP Media Services                  June 2003


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

   delay Specifies a delay interval between announcement repetitions.
      The delay is measured in milliseconds.

   duration Specifies the maximum duration of the announcement.  The
      media server will discontinue the announcement and end the call if
      the maximum duration has been reached.  The duration is measured
      in milliseconds.

   locale Specifies the language and country variant of the announcement
      sequence named in the "play=" parameter.  The language is defined
      as a two-letter code per ISO 639-1 [3]. The country variant is
      also defined as a two-letter code per ISO 3166-1 [4].  These
      elements are concatenated with a single underbar (%x5F) character.
      The mechanics of announcement sequences are beyond the scope of
      this document.

   param[n] Provides a mechanism for passing values that are to be
      substituted into an announcement sequence.  Up to 9 parameters
      ("param1=" through "param9=") may be specified. The mechanics of
      announcement sequences are beyond the scope of this document.

   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 RFC3261 [2] implies that proxies are supposed to pass
   parameters through unchanged. However, be aware that non-conforming
   proxies may strip Request-URI parameters.  That said, given 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 their choice of proxy
   will preserve the parameters.

   The form of the SIP Request URI for announcements is as follows. Note
   that the backslash, CRLF, and spacing before the "play=" in the
   example is for readability purposes only.

        sip:annc@ms2.example.net; \



Burger                 Expires December 29, 2003                [Page 7]

Internet-Draft             SIP Media Services                  June 2003


          play="http://audio.example.net/allcircuitsbusy.g711"

        sip:annc@ms2.example.net; \
          play="file://fileserver.example.net/geminii/yourHoroscope.wav"


3.1 Operation

   The scenarios below assume there is a SIP Proxy, application server,
   or media gateway controller between the caller and the media server.
   However, the announcement service works as described below even if
   the caller invokes the service directly.  We chose to discuss the
   proxy case, as it will be the most common case.

3.2 Operation

   The caller issues an INVITE to the serving SIP Proxy.  The SIP Proxy
   determines what audio prompt to play to the caller.  The proxy
   responds to the caller with 100 TRYING.

   The proxy issues an INVITE to the media server, requesting the
   appropriate prompt to play coded in the play= parameter. The media
   server responds with 200 OK.  The proxy sends a 200 OK to the caller.
   The caller then issues an ACK.  The proxy then issues an 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.

3.3 Protocol Diagram

   Caller                   Proxy                 Media Server
     |   INVITE               |                        |
     |----------------------->|   INVITE               |
     |   100 TRYING           |----------------------->|
     |<-----------------------|   200 OK               |
     |   200 OK               |<-----------------------|
     |<-----------------------|                        |
     |   ACK                  |                        |
     |----------------------->|   ACK                  |
     |                        |----------------------->|
     |                        |                        |
     |              Play Announcement (RTP)            |
     |<================================================|
     |                        |                        |
     |                        |   BYE                  |



Burger                 Expires December 29, 2003                [Page 8]

Internet-Draft             SIP Media Services                  June 2003


     |   BYE                  |<-----------------------|
     |<-----------------------|                        |
     |   200 OK               |    200 OK              |
     |----------------------->|----------------------->|
     |                        |                        |


3.4 Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC2234 [5].

   ANNC-URL        = "sip:" annc-ind "@" hostport
                       annc-parameters

   annc-ind        = "annc"

   annc-parameters = ";" play-param [ ";" content-param ]
                                    [ ";" delay-param]
                                    [ ";" duration-param ]
                                    [ ";" repeat-param ]
                                    [ ";" locale-param ]
                                    [ ";" variable-params ]

   play-param      = "play=" prompt-url

   content-param   = "content-type=" MIME-type

   delay-param     = "delay=" delay-value

   delay-value     = 1*DIGIT

   duration-param  = "duration=" duration-value

   duration-value  = 1*DIGIT

   repeat-param    = "repeat=" repeat-value

   repeat-value    = 1*DIGIT

   locale-param    = "locale=" locale-value

   locale-value    = 2ALPHA %x5F 2ALPHA

   variable-params = param-name "=" variable-value

   param-name      = "param" DIGIT ; e.g., "param1"




Burger                 Expires December 29, 2003                [Page 9]

Internet-Draft             SIP Media Services                  June 2003


   variable-value  = 1*(ALPHA | DIGIT)

   The MIME-type is the MIME [6] content type for the announcement, such
   as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.

   To date, none of the IETF audio MIME registrations have parameters.
   Vendor-specific registrations, such as audio/x-wav, do have
   parameters.  However, they are not strictly needed for prompt
   fetching.

   On the other hand, the prevalence of parameters may change in the
   future.  In addition, existing video registrations have parameters,
   such as 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 2-letter language code as specified in
   ISO 639-1 [3] and a 2-letter country code specified in ISO 3166-1 [4]
   separated by a single underbar (%x5Fh) character.

   The definition of hostport is as specified by RFC3261 [2].

   The syntax of prompt-url consists of a URL scheme as specified by
   RFC2396 [7] or a special token indicating a provisioned announcement
   sequence. We expect the URL to be one of the following schemes.

   o  http

   o  ftp

   o  file (referencing a local or NFS (RFC3010 [13])

   o  nfs (RFC2224 [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



Burger                 Expires December 29, 2003               [Page 10]

Internet-Draft             SIP Media Services                  June 2003


   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.









































Burger                 Expires December 29, 2003               [Page 11]

Internet-Draft             SIP Media Services                  June 2003


4. Prompt and Collect Service

   This service is also known as a voice dialog.  It establishes an
   aural dialog with the user.

   The dialog service follows the model of the announcement service.
   However, the service indicator is "dialog".  The dialog service takes
   a parameter, voicexml=, indicating the URI of the VoiceXML script to
   execute.

        sip:dialog@mediaserver.example.net; \
            voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml

   A Media Server MAY accept additional SIP request URI parameters and
   deliver them to the VoiceXML interpreter session as session
   variables.

4.1 Formal Syntax for Prompt and Collect Service

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC2234 [5].

   DIALOG-URL        = "sip:" dialog-ind "@" hostport
                          dialog-parameters

   dialog-ind        = "dialog"

   dialog-parameters = ";" dialog-param [ vxml-parameters ]

   dialog-param      = "voicexml=" dialog-url

   vxml-parameters   = vxml-param [ vxml-parameters ]

   vxml-param        = ";" vxml-keyword "=" vxml-value

   vxml-keyword      = token

   vxml-value        = token

   The dialog-url is the URI of the VoiceXML script.  If present, other
   parameters get passed to the VoiceXML interpreter session with the
   assigned vxml-keyword vxml-value pairs.  Note that all vxml-keywords
   MUST have values.

   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.



Burger                 Expires December 29, 2003               [Page 12]

Internet-Draft             SIP Media Services                  June 2003


   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.












































Burger                 Expires December 29, 2003               [Page 13]

Internet-Draft             SIP Media Services                  June 2003


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
   conferencing-framework [11], this URI convention tells the media
   server that the application server is requesting it to act as a
   Focus.  The conf-id value identifies the particular focus instance.

   It is worth noting that the conference URI shared between the
   application and media provides enhanced security, as the SIP control
   interface does not have to be exposed to participants. It also allows
   the assignment of a specific media server to be delayed as long as
   possible, thereby simplifying resource management.

   One can add additional legs to the conference by INVITEing them to
   the above mentioned request URI.  Per the matching rules of RFC3261
   [2], the conf-id parameter is part of the matching string.

   Conversely, one can remove legs by issuing a BYE in the corresponding
   dialog.  The mixing session, and thus the conference-specific request
   URI, remains active so long as there is at least one SIP dialog
   associated with the given request URI.

   If the Request-URI has "conf" as the user part, but does not have a
   conf-id parameter, the media server responds with a 404 NOT FOUND.

      NOTE: The media server could create a unique conference instance
      and return the conf-id string to the UAC if there is no conf-id
      present.  However, such an operation may have other operational



Burger                 Expires December 29, 2003               [Page 14]

Internet-Draft             SIP Media Services                  June 2003


      issues, such as permissions and billing.  Thus an application
      server or proxy is a better place to do such an operation.
      Moreover, such action would make the media server into a
      Conference Factory in the terminology of conference-framework
      [11].  That is not the appropriate behavior for a media server.


5.1 Protocol Diagram

   This diagram shows the establishment of a three-way conference. This
   section is informative.

    P1       P2        P3         Application Server     Media Server
     |       |        |                  |                   |
     |  INVITE sip:public-conf@as.c.net  |                   |
     |---------------------------------->| INVITE sip:conf=123@ms.c.net
     |       |        |                  |------------------>|
     |       |        |                  | 200 OK            |
     |  200 OK        |                  |<------------------|
     |<----------------------------------|                   |
     |       |        | RTP w/ P1        |                   |
     |<=====================================================>|
     |       |        |                  |                   |
     |  INVITE sip:public-conf@as.c.net  |                   |
     |       |-------------------------->| INVITE sip:conf=123@ms.c.net
     |       |        |                  |------------------>|
     |       |        |                  | 200 OK            |
     |       | 200 OK |                  |<------------------|
     |       |<--------------------------|                   |
     |       |        |                  |                   |
     |       |        | RTP w/ P1+P2-P2  |                   |
     |       |<=============================================>|
     |       |        | RTP w/ P1+P2-P1  |                   |
     |<=====================================================>|
     |       |        |                  |                   |
     |  INVITE sip:public-conf@as.c.net  |                   |
     |       |        |----------------->| INVITE sip:conf=123@ms.c.net
     |       |        |                  |------------------>|
     |       |        |                  | 200 OK            |
     |       |        | 200 OK           |<------------------|
     |       |        |<-----------------|                   |
     |       |        |                  |                   |
     |       |        | RTP w/ P1+P2+P3-P3                   |
     |       |        |<====================================>|
     |       |        | RTP w/ P1+P2+P3-P2                   |
     |       |<=============================================>|
     |       |        | RTP w/ P1+P2+P3-P1                   |
     |<=====================================================>|



Burger                 Expires December 29, 2003               [Page 15]

Internet-Draft             SIP Media Services                  June 2003


     |       |        |                  |                   |
     |       |        |                  |                   |

   Using the terminology of conference-framework [11], the Application
   Server is the Conference Factory and the Media Server is the
   Conference Focus.

   Note that the above call flow does not show any 100 TRYING messages
   that would typically flow from the Application Server to the UAC's,
   nor does it show the ACK's from the UAC's to the Application Server
   or from the Application Server to the Media Server.

   Each leg can drop out either under the supervision of the UAC by the
   UAC sending a BYE or under the supervision of the Application Server
   by the Application Server issuing a BYE. In either case, the
   Application Server will either issue a BYE on behalf of the UAC or
   issue it directly to the Media Server, corresponding to the
   respective disconnect case.

   It is left as a trivial exercise to the reader for how the
   Application Server can mute legs, create side conferences, and so
   forth.

   Note that the Application Server is a server to the participants
   (UAC's).  However, the Application Server is a client for mixing
   services to the Media Server.

5.2 Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC2234 [5].

   CONF-URL        = "sip:" conf-ind "=" instance-id "@" hostport

   conf-ind        = "conf"

   instance-id     = token

   The SIP-PARAM-LIST is the SIP Request-URI parameter list as described
   in RFC3261 [2].  Note that all of the parameters in the parameter
   list are part of the URI matching algorithm.










Burger                 Expires December 29, 2003               [Page 16]

Internet-Draft             SIP Media Services                  June 2003


6. The User Part

   There has been considerable debate about the wisdom of using fixed
   user parts in a request URI.  The most common objection is that the
   user part should be opaque and a local matter.  The other objection
   is that using a fixed user part removes those specified user
   addresses from the user address space.

   We will address the latter issue first.  The common example is the
   Postmaster address defined by RFC2821 [15]. The objection is that by
   using the Postmaster token for something special, one removes that
   token for anyone.  Thus, the Postmaster General of the United States,
   for example, cannot have the mail address Postmaster@usps.gov.  One
   may debate whether this is a significant limitation, however.

   One may point out that "annc", for example, has the potential for
   more conflict than Postmaster.  This is true.  However, one cannot
   confuse the namespace at a Media Server with the namespace for an
   organization.

   For example, let us take the case where a network offers services for
   "Ann Charles".  She likes to use the name "annc", and thus she would
   like to use "sip:annc@provider.net".  We offer that there is
   ABSOLUTELY NO NAME COLLISION WHATSOEVER.  Why is this so?  This is so
   because sip:annc@provider.net will resolve to the specific user at a
   specific device for Ann.  As an example, provider.net's SIP Proxy
   Server can resolve sip:annc@provider.net to
   annc@anns-phone.provider.net .  One directs requests for the media
   service annc directly to the Media Server, e.g.,
   sip:annc@ms21.ap.provider.net .  Moreover, by definition, Ann
   Charles, or anything other than the announcement service, will NEVER
   be directly on 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 SnowShore domain.

   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.

   Some have proposed that such naming be a pure matter of local
   convention. For example, the thesis of the informational RFC3087 [16]
   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.  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



Burger                 Expires December 29, 2003               [Page 17]

Internet-Draft             SIP Media Services                  June 2003


   domain, this does not work across domains.  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 mixing-only device will register the "conf" 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.  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") get sent to the
   surviving Media Server.





























Burger                 Expires December 29, 2003               [Page 18]

Internet-Draft             SIP Media Services                  June 2003


7. Early Media Announcement

7.1 IMPORTANT NOTICE

   This section is entirely informative.  It does not define any
   particular standards-track protocol or best practice.

   This section describes one implementation of an early media
   announcement service.  There are many issues surrounding early media.
   Thus this document does not advocate the use of such a facility.

   This document includes this description of an early media
   announcement service purely to document one use of an early media
   call flow.

   All of the MUST and SHOULD language is likewise historical and NOT
   part of the normative definition described in this document.

7.2 Description

   In some situations, one would like to play an announcement without
   providing an answer indication. One need for this is to replicate and
   expand upon the existing telephone network.  Network operators
   require this capability to provide informational network
   announcements, such as "The person you are trying to reach is
   unavailable.  Good Bye." or "We are sorry, but all circuits are busy.
   Please try your call again later.  Good Bye."

   Note that simply redirecting the caller to a media server, with the
   media server issuing a 200 OK response, may not be appropriate.  The
   call request itself has not completed successfully.  Likewise, if a
   proxy record-routes the request, the proxy will still forward a 200
   OK response from the media server.

   Another alternative would be to use a back-to-back user agent
   (B2BUA).  The B2BUA would perform the early media signaling to the
   UAC, while doing a normal, complete SIP dialog with the media
   server.  That unquestionably makes the media server signaling easier.
   However, the signaling between the B2BUA would be identical to that
   described below. Moreover, many network operators would rather deploy
   SIP Proxies and not B2BUAs.

   To support the appropriate paradigm, the media server issues a 100
   TRYING response, followed immediately by a 183 SESSION PROGRESS
   response with SDP. This enables the media server to send early media
   to the caller.

   The request to the media server should include the 100rel extension



Burger                 Expires December 29, 2003               [Page 19]

Internet-Draft             SIP Media Services                  June 2003


   header RFC3262 [8]. This ensures the media server reliably delivers
   its SDP to the caller.

   At this point, the media server sends the requested audio.

   After playing the audio, the media server issues a 487 REQUEST
   CANCELED response code to the requesting device.

   NOTE:  487 conforms to RFC2543 [17]. However, it is not strictly the
   correct response code per RFC3261 [2].  The concept is that the media
   server is responding to an implicit CANCEL.  This works for most
   devices, as per RFC3261, a 4xx result code means the request was
   terminated.  Unfortunately, there are non-conforming devices that do
   not terminate a session, even if they receive a 4xx result code.  Be
   aware of that if you wish to implement this, non-normative, section
   of this document.

   If the media server does not support announcements, it MUST respond
   with the 488 NOT ACCEPTABLE HERE response code.

   The INVITE to the media server contains the parameter "early=yes" to
   invoke the Early Media Prompting service.  The media server responds
   with 100 TRYING followed by 183 SESSION PROGRESS.  Assuming the
   initial invite included the 100rel extension header RFC3262 [8],
   which this document RECOMMENDS, the media server waits for the
   acknowledgement of the 183 (PRACK).  At that point, the media server
   sends the announcement to the caller.

   The procedures in RFC3262 [8] describe what to do if the PRACK is
   late or does not arrive. In addition, RFC3262 [8] describes
   provisional offer/answer SDP negotiation. RFC3261 [2] describes the
   183 SESSION PROGRESS result code.

   As stated above, if the Media Server cannot fetch the URI in the
   "play=" parameter, the Media Server will reply with a 404 NOT FOUND,
   possibly with an explanation of the failure in the Warning: header.
   Otherwise, after the media server completes the streaming of the
   prompt, it must send a 487 REQUEST TERMINATED to the Proxy.

   Note: When the early media service is used the requester is
   implicitly asking the media server to cancel the transaction as soon
   as the announcement is played.  Since 487 is associated with an
   explicit CANCEL request it is appropriate for this use as well.

   The proxy sends the appropriate error response to the caller. That
   could be 487 or any other appropriate code reflective of the failure
   situation.




Burger                 Expires December 29, 2003               [Page 20]

Internet-Draft             SIP Media Services                  June 2003


   Note that this document does not define the behavior of an early
   media put on hold.

7.3 Protocol Diagram

   Caller                   Proxy                 Media Server
     |   INVITE               |                        |
     |----------------------->|   INVITE               |
     |   100 TRYING           |----------------------->|
     |<-----------------------|   100 TRYING           |
     |                        |<-----------------------|
     |                        |   183 SESSION PROGRESS |
     |   183 SESSION PROGRESS |<-----------------------|
     |<-----------------------|                        |
     |   PRACK                |                        |  *
     |----------------------->|   PRACK                |  *
     |                        |----------------------->|  *
     |                        |   200 OK               |  *
     |   200 OK               |<-----------------------|  *
     |<-----------------------|                        |  *
     |                        |                        |
     |              Play Announcement (RTP)            |
     |<================================================|
     |                        | 487 REQUEST TERMINATED |
     | 487 REQUEST TERMINATED |<-----------------------|
     |<-----------------------|                        |
     |   ACK                  |    ACK                 |
     |----------------------->|----------------------->|
     |                        |                        |

         * If the UAC requests or supports 100rel in the
           initial INVITE.



















Burger                 Expires December 29, 2003               [Page 21]

Internet-Draft             SIP Media Services                  June 2003


8. Security Considerations

   Untrusted network elements could use the protocol described here for
   providing information services.  Many extant billing arrangements are
   for completed calls.  Successful call completion occurs with a 2xx
   result code.  This can be an issue for the early media announcement
   service.  This is one of the many reasons why the early media
   announcement service is depreciated.

   Exposing network services with well-known addresses may not be
   desirable.  In this case, the Media Server should offer local policy,
   e.g., only accept requests from authorized clients.  Barring that,
   one can use a SIP Proxy to enforce the local policy.






































Burger                 Expires December 29, 2003               [Page 22]

Internet-Draft             SIP Media Services                  June 2003


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.











































Burger                 Expires December 29, 2003               [Page 23]

Internet-Draft             SIP Media Services                  June 2003


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 draft document. Pete Danielsen from Lucent has
   consistently provided excellent reviews of the many of the different
   versions of this document.

   Pascal Jalet provided the theoretical underpinning and David Rio
   provided the experimental evidence for why the conference identifer
   belongs in the user part of the 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.

   The authors would like to give a special thanks to Walter O'Connor
   for doing much of the initial implementation.



























Burger                 Expires December 29, 2003               [Page 24]

Internet-Draft             SIP Media Services                  June 2003


Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [3]  ISO, "Codes for the representation of names of languages -- Part
        1: Alpha-2 code", ISO 639-1, July 2002.

   [4]  ISO, "Codes for the representation of names of countries and
        their subdivisions -- Part 1: Country codes", ISO 3166-1,
        October 1997.

   [5]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [6]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
        Extensions) Part One: Mechanisms for Specifying and Describing
        the Format of Internet Message Bodies", RFC 1521, September
        1993.

   [7]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [8]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
        Responses in Session Initiation Protocol (SIP)", RFC 3262, June
        2002.





















Burger                 Expires December 29, 2003               [Page 25]

Internet-Draft             SIP Media Services                  June 2003


Informative References

   [9]   Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", RFC
         1889, January 1996.

   [10]  Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media
         Server Control Markup Language and Protocol",
         draft-vandyke-mscml-00 (work in progress), November 2002.

   [11]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-00 (work in
         progress), May 2003.

   [12]  World Wide Web Consortium, "Voice Extensible Markup Language
         (VoiceXML) Version 2.0", W3C Candidate Recommendation ,
         February 2003, <http://www.w3.org/TR/2003/
         CR-voicexml20-20030220/>.

   [13]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
         C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
         3010, December 2000.

   [14]  Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.

   [15]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
         2001.

   [16]  Campbell, B. and R. Sparks, "Control of Service Context using
         SIP Request-URI", RFC 3087, April 2001.

   [17]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
         "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [18]  Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van
         Wijk, "User Requirements for the Session Initiation Protocol
         (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
         Individuals", RFC 3351, August 2002.












Burger                 Expires December 29, 2003               [Page 26]

Internet-Draft             SIP Media Services                  June 2003


Author's Address

   Eric Burger
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

   EMail: e.burger@ieee.org










































Burger                 Expires December 29, 2003               [Page 27]

Internet-Draft             SIP Media Services                  June 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Burger                 Expires December 29, 2003               [Page 28]

Internet-Draft             SIP Media Services                  June 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Burger                 Expires December 29, 2003               [Page 29]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/