view Side-By-Side changes

Network Working Group


SIPPING                                                      J. Van Dyke 
Internet Draft
Internet-Draft                                           E. Burger (ed.) 
Document: draft-burger-sipping-netann-03.txt (Ed.)
Expires: July 28, 2003                                        A. Spitzer 
Category: Standards Track
                                                SnowShore Networks, Inc. 
Expires: May
                                                        January 27, 2003                                            W. O'Connor 
                                                        November 2, 2002


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1]. 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.

   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 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 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 July 28, 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, conferencing, and transcoding 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



Van Dyke, et al.         Expires July 28, 2003                  [Page 1]


Internet-Draft             SIP Media Services               January 2003


   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, et. al.            Expires 5/2/2003                          1 

                    Network Announcements with SIP       November 2002 
 
 
   Table of Contents 
    
   1. Conventions used in this document..............................2 
   2. Overview.......................................................2 
   3. Mechanism......................................................3 
   4. Announcement Service...........................................5 
     4.1. Operation..................................................7 
     4.2. Established Call Announcement..............................7 
          4.2.1. Description.........................................7 
          4.2.2. Protocol Diagram....................................8 
     4.3. Early Media Announcement...................................8 
          4.3.1. Description.........................................8 
          4.3.2. Protocol Diagram....................................9 
     4.4. Formal Syntax..............................................9 
   5. Prompt and Collect Service....................................10 
     5.1. Explicit Service..........................................11 
     5.2. Formal Syntax for Explicit Service........................11 
   6. Conference Service............................................11 
     6.1. Protocol Diagram..........................................12 
     6.2. Formal Syntax.............................................14 
   7. Transcoding Service...........................................14 
     7.1. Trans-Coding Overview.....................................14 
     7.2. Media Server Interface....................................14 
     7.3. Call Flows................................................15 
          7.3.1. Trans-coding bridge................................16 
          7.3.2. URI Parameter Method...............................16 
          7.3.3. Message Flow.......................................18 
     7.4. Formal Syntax.............................................21 
   8. The User Part.................................................21 
   9. Security Considerations.......................................23 
   10. References...................................................23 
   11. Changes......................................................24 
     11.1. Changes Made in Version 02...............................24 
     11.2. Changes Made in Version 01...............................24 
   12. Acknowledgments..............................................25 
   13. Author's Addresses...........................................25 
    
    
1.

Conventions used in this document 
    
   The

   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 are to be interpreted as described in RFC-2119 [2]. 
    
    
2. Overview 
    
   In SIP-based media networks [3], there is a need to provide basic 
   network media services.  Such services include playing 
   announcements, initiating a media mixing session (conference), 
   transcoding a stream, and prompting and collecting information with 
   a user. 
    
  
Burger, et. al.            Expires 5/2/2003                          2 

                    Network Announcements with SIP       November 2002 
 
 
   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, or combinations document.

Table of the above. 
    
   In some situations, one must play the announcement without providing 
   an answer indication.  In others, one must play the announcement 
   after completing call setup.  This document describes how to provide 
   such announcements in a SIP-based network.  The method described 
   here is a media server service instance. 
    
   Media mixing is the act of mixing different RTP streams, as 
   described in [4].  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 conferencing, floor control, etc. 
    
   Transcoding is the act of taking an RTP stream coded with one codec 
   and playing it as a new RTP stream coded with another codec.  For 
   example, taking a G.711-encoded stream and transcoding it to G.729e.  
   In addition, the mechanism described here satisfies the needs of the 
   hearing-impaired requirements [5] for a transcoding service. 
    
   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 passcode", followed by 
   collecting a string of digits.  It can also be a more complex 
   interaction, specified, for example, by VoiceXML [6]. 
    
    
3. Contents

   1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   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 a concept of a user.  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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Announcement Service . . . . . . . . . . . . . . . . . . . .  6
   3.1   Operation  . . . . . . . . . . . . . . . . . . . . . . . . .  8 below, 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 [3]. 
    
   The media server MAY issue 401 challenges for authentication. 
    

  
Burger, et. al.            Expires 5/2/2003                          3 

                    Network Announcements with SIP       November 2002 
 
 
   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 SIP, 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
   3.2   Established Call Announcement  . . . . . . . . . . . . . . .  8
   3.2.1 Description  . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . .  9
   3.3   Early Media Announcement . . . . . . . . . . . . . . . . . .  9
   3.3.1 Description  . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.3.2 Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . 10
   3.4   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . 10
   4.    Prompt and Collect Service . . . . . . . . . . . . . . . . . 13
   4.1   Formal Syntax 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 Prompt 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 (see Collect Service . . . . . . . . 13
   5.    Conference Service . . . . . . . . . . . . . . . . . . . . . 15
   5.1   Protocol Diagram . . . . . . . . . . . . . . . . . . . . . . 15
   5.2   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . 17
   6.    The User Part  . . . . . . . . . . . . . . . . . . . . . . . 18
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 20
   8.    IANA Considerations, below). 
    
   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.  [3] 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, et. Considerations  . . . . . . . . . . . . . . . . . . . . 21
   9.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
         Normative References . . . . . . . . . . . . . . . . . . . . 23
         Informative References . . . . . . . . . . . . . . . . . . . 24
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24
         Intellectual Property and Copyright Statements . . . . . . . 26















Van Dyke, et al.         Expires 5/2/2003                          4 

                    Network Announcements with July 28, 2003                  [Page 2]


Internet-Draft             SIP       November 2002 
 
 
    
4. Announcement Service 
 
   A network announcement is the delivery of an audio resource, such as 
   a prompt file, to a terminal device. 
    
   There are two types of network announcements.  The differentiating 
   characteristic between the two types is whether the network fully 
   sets up the call 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 prompt 
   and issues a BYE to the requesting device. 
    
   In replicating and expanding on the existing telephone network, 
   there is a need to play announcements during call setup.  That is, 
   the network delivers media to the caller before the setup completes.  
   Network operators need 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 Media Services               January 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 server, mixing session (conference), and
   prompting and collecting information with the 
   media server issuing a 200 OK response, is user.

   These services are basic in nature, are few in number, and
   fundamentally have not appropriate.  The 
   call has changed in 25 years of enhanced telephony
   services.  Moreover, given their elemental nature, one would not completed successfully.  To support the appropriate 
   paradigm, the media server issues a 100 TRYING response, followed 
   immediately by a 183 SESSION PROGRESS response with SDP.  This 
   enables the media server
   expect them to send early change in the future.

   Announcements are media played to the caller.  The user.  Announcements can be
   static media server sends the requested audio.  After playing the audio, 
   the files, media server issues a 487 REQUEST TERMINATED response code to 
   the requesting device. 
    
   If the files generated in real-time, media server does not support announcements, it MUST respond 
   with streams
   generated in real-time, or combinations of the 488 NOT ACCEPTABLE HERE response code. 
    
   If above.

   In some situations, one must play the media server supports announcements, but it cannot find announcement without providing
   an answer indication.  In others, one must play the 
   referenced URI, it MUST respond with announcement
   after completing call setup.  This document describes how to provide
   such announcements in a SIP-based network.

   Media mixing is the 404 NOT FOUND response 
   code. 
    
   If act of mixing different RTP streams, as described
   in RFC1889 [8].  Note that the service described here will suffice
   for simple mixing of media server receives an INVITE for the announcement service 
   without a "play=" parameter, it MUST respond with basic conferencing service.  One can
   create a complete conferencing service using this basic building
   block.  However, this service does not address the 404 NOT FOUND 
   response code, interesting
   application-level issues such as there is no default value floor control for the announcement 
   service. 
    
   If there conferencing, etc.

   Prompt and collect is an error retrieving the announcement, where the media server 
   MUST respond with prompts the user for some
   information, as in an appropriate 4xx error code reflecting announcement, and then collects the 
   error. 
  
Burger, et. 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 [9] or MSCML [10].

















Van Dyke, et al.         Expires 5/2/2003                          5 

                    Network Announcements with July 28, 2003                  [Page 3]


Internet-Draft             SIP       November 2002 
 
 
    
   The Request URI fully describes the announcement service through Media Services               January 2003


2. Mechanism

   In the 
   use context of the user part SIP control of media servers, we take advantage of
   the address and additional fact that the standard SIP URI parameters.  
   The has a user portion part.  Media servers do
   not have a concept of a user.  Thus we use the user address, "annc", specifies or the announcement 
   service on
   left-hand-side of the media server.  The URI, as a service has several associated URI 
   parameters indicator.

   Note that control the content and delivery set of services is small, well defined, and well
   contained.  The section The User Part (Section 6) discusses the 
   announcement.  These parameters are described below: 
    
   "play=" specifies
   issues with using a fixed set of user-space names.

   For per-service security, the audio resource or announcement sequence to be 
   played. 
    
   "early=" Specifies whether early media treatment is desired. 
    
   "repeat=" Specifies how many times server MAY use any of the
   security protocols described in RFC3261 [2].

   The media server should repeat MAY issue 401 challenges for authentication.

   The media server, upon receiving the announcement or sequence named by INVITE, notes the "play=" parameter. 
    
   "delay=" Specifies a delay interval between announcement 
   repetitions.  The delay is measured in milliseconds. 
    
   "duration=" Specifies service
   indicator.  Depending on the maximum duration of service indicator, the announcement.  The media server will discontinue the announcement and end the call if
   either honor the maximum duration has been reached. request or return a failure response code.

   The duration service indicator is measured in 
   milliseconds. 
    
   "locale=" Specifies the language and country variant concatenation of the 
   announcement sequence named in service name and an
   optional service instance identifier, separated by an equal sign.

   Per RFC3261 [2], the "play=" parameter.  The language service indicator is defined as a two letter code per ISO 639 [7]. case insensitive.  The country 
   variant is also defined
   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 a two letter code per ISO 3166 [8].  
   These elements are concatenated with a single underbar (%x5F) 
   character. 
    
   "param[n]=" Provides a mechanism SIP does for passing values that are to be 
   substituted into
   headers.

   A given service indicator MAY have an announcement sequence.  Up to 9 associated set of parameters.
   Such parameters 
   ("param1=" through "param9=") MUST follow the convention set out for SIP URI
   parameters.  That is, a semi-colon separated list of keyword=values.

   Certain services may be specified. 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 "play=" parameter is mandatory and unique identifier MUST be present.  All other 
   parameters are OPTIONAL. 
         
   NOTE: Some encodings are not self-describing.  Should we specify 
   something like content-type?  Alternatively, how about meet the rules for a "media=" 
   parameter? 
    
   The form legal user part of the a
   SIP Request URI for announcements is as follows. URI.  An equal sign, US-ASCII %3D, MUST separate the service
   indicator from the unique identifier.

   Note that since the backslash, CRLF, and spacing before service indicator is case insensitive, the "play="
   service instance identifier is for 
   readability purposes only. 
    
        sip:annc@ms2.carrier.net; \ 
          play="http://audio.carrier.net/allcircuitsbusy.g711"; \ 
            early=yes 
        sip:annc@ms2.carrier.net; \ 
          
   play="file://fileserver.carrier.net/geminii/yourHoroscope.wav" 
    
  
Burger, et. al.            Expires 5/2/2003                          6 

                    Network Announcements with SIP       November 2002 
 
 
4.1. Operation also case insensitive.

   The scenarios below assume there is requesting client issues a SIP Proxy, application INVITE to the media server, 
   or SoftSwitch between
   specifying the caller requested service and any appropriate parameters.



Van Dyke, et al.         Expires July 28, 2003                  [Page 4]


Internet-Draft             SIP Media Services               January 2003


   If the media server.  However, server can perform the requested service, it does so,
   following the processing steps described in the 
   announcement service works definition
   document (see IANA Considerations (Section 8)).

   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 described below even if 488 refers to
   a problem with the caller 
   invokes 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 directly.  We chose to discuss instance upon the proxy case, 
   as it will be first INVITE with
   the most common case. 
    
   As described above, given identifier.  However, if a service requires an existing
   service instance, and no such service instance exists on the "early=" parameter determines whether media
   server, the media server plays the prompt after call setup or as early media.  
   The default value for the "early=" parameter MUST BE "yes".  That 
   is, respond with the default action response code 404 NOT
   FOUND.  This is for appropriate as the media server to play service itself exists on the prompt 
   before establishing media
   server, but the call.  We envision that that this particular service 
   will be most commonly used for network announcements which require 
   early media, hence that instance does not.  It is as if
   the default behavior. 
    
4.2. Established Call user was not home.
































Van Dyke, et al.         Expires July 28, 2003                  [Page 5]


Internet-Draft             SIP Media Services               January 2003


3. Announcement 
    
4.2.1. Description 
    
   The caller issues an INVITE to Service

   A network announcement is the serving SIP Proxy.  The SIP Proxy 
   determines what delivery of an audio resource, such as
   a prompt file, to play to the caller. a terminal device.

   There are two types of network announcements.  The proxy 
   responds to differentiating
   characteristic between the caller with 100 TRYING. two types is whether the network fully
   sets up the SIP dialog before playing the announcement.  The proxy issues an INVITE to analog
   in the media server, requesting PSTN is whether answer supervision is supplied; i.e.  does the 
   appropriate prompt
   announcement server answer the call prior to play coded in delivering the play= parameter.  The INVITE 
   MUST contain
   announcement.

   Playing an announcement after call setup is straightforward.  First,
   the parameter "early=no" requesting device issues an INVITE to invoke the Established Call 
   Prompting media server requesting
   the announcement service.  The media server negotiates the SDP and
   responds with 200 OK.  The 
   proxy sends a 200 OK to OK.  After receiving the caller.  The caller then issues an ACK.  
   The proxy then issues an ACK to the media server. 
    
   With from the call setup, requesting
   device, the media server plays the requested prompt.  
   When the media server completes the play of the prompt, it prompt and issues a BYE
   to the proxy.  The proxy then issues requesting device.

   In replicating and expanding on the existing telephone network, there
   is a BYE need to play announcements during call setup.  That is, the caller.  



















  
Burger, et. al.            Expires 5/2/2003                          7 

                    Network Announcements with SIP       November 2002 
 
 
4.2.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              | 
     |----------------------->|----------------------->| 
     |                        |                        | 
    
    
4.3. Early Media Announcement 
    
4.3.1. Description 
    
   The caller issues an INVITE
   network delivers media to the serving SIP Proxy.  Normally, the 
   SIP Proxy would complete caller before the call setup completes.
   Network operators need 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 requested destination.  
   However, if caller to a media server, with the destination
   media server issuing a 200 OK response, is not available, appropriate.  The call
   has not completed successfully.  To support the proxy will request 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 play an audio prompt send early media to the caller.  The proxy 
   responds with a 100 TRYING. 
    
   The proxy media server sends the
   requested audio.  After playing the audio, the media server issues an INVITE a
   487 REQUEST TERMINATED response code to the media server, requesting device.

   If the 
   appropriate prompt to play.  The INVITE media server does not support announcements, it MUST contain the parameter 
   "early=yes" or omit respond
   with the "early=" parameter to invoke 488 NOT ACCEPTABLE HERE response code.

   If the Early Media 
   Prompting service.  The media server responds supports announcements, but it cannot find the
   referenced URI, it MUST respond with 100 TRYING 
   followed by 183 SESSION PROGRESS.  At that point, the 404 NOT FOUND response code.

   If the media server 
   sends receives an INVITE for the announcement to service
   without a "play=" parameter, it MUST respond with the caller.  The document [3] describes 404 NOT FOUND
   response code, as there is no default value for the 183 SESSION PROGRESS result code. 
    
   As stated above, if announcement
   service.

   If there is an error retrieving the announcement, the media server



Van Dyke, et al.         Expires July 28, 2003                  [Page 6]


Internet-Draft             SIP Media Server cannot fetch Services               January 2003


   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 in fully describes the 
   "play=" parameter, announcement service through the
   use of the user part of the address and additional URI parameters.
   The user portion of the Media Server will reply with a 404 NOT FOUND.  
   Otherwise, after address, "annc", specifies the announcement
   service on the media server completes server.  The service has several associated URI
   parameters that control the streaming content and delivery of the 
   prompt, it MUST send a 487 REQUEST TERMINATED to the Proxy.   
    
   Note: When announcement.
   These parameters are described below:

   play Specifies the audio resource or announcement sequence to be
      played.

   early Specifies whether early media service is used the requester treatment is 
   implicitly asking desired.

   repeat Specifies how many times the media server to cancel should repeat the transaction as soon 
   as
      announcement or sequence named by the "play=" parameter.

   delay Specifies a delay interval between announcement repetitions.
      The delay is played.  Since 487 is associated with an 
   explicit CANCEL request it seems appropriate for this use as well.   
    

  
Burger, et. al.            Expires 5/2/2003                          8 

                    Network Announcements with SIP       November 2002 measured in milliseconds.

   duration Specifies the maximum duration of the announcement.  The proxy sends
      media server will discontinue the appropriate error response to announcement and end the caller.  That 
   could be 487 or any other appropriate code reflective of call if
      the failure 
   situation.  
    
4.3.2. Protocol Diagram 
    
   Caller                   Proxy                 Media Server 
     |   INVITE               |                        | 
     |----------------------->|   INVITE               | 
     |   100 TRYING           |----------------------->| 
     |<-----------------------|   100 TRYING           | 
     |                        |<-----------------------| 
     |                        |   183 SESSION PROGRESS | 
     |   183 SESSION PROGRESS |<-----------------------| 
     |<-----------------------|                        | 
     |                        |                        | 
     |              Play Announcement (RTP)            | 
     |<================================================| 
     |                        | 487 REQUEST TERMINATED | 
     | 487 REQUEST TERMINATED |<-----------------------| 
     |<-----------------------|                        | 
     |   ACK                  |    ACK                 | 
     |----------------------->|----------------------->| 
     |                        |                        | 
    
    
4.4. Formal Syntax maximum duration has been reached.  The following syntax specification uses duration is measured
      in milliseconds.

   locale Specifies the augmented Backus-Naur 
   Form (BNF) as described language and country variant of the announcement
      sequence named in RFC-2234 [9]. 
    
   ANNC-URL        = "sip:" annc-ind "@" hostport 
                       annc-parameters 
    
   annc-ind        = "annc" 
    
   annc-parameters = ";" play-param [ ";" early-param ] 
        [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ] 
        [ ";" locale-param ] [ ";" variable-params ] 
    
   play-param      = the "play=" prompt-url 
    
   early-param     = "early=" ( "yes" | "no" ) 
    
   delay-param     = "delay=" delay-value 
    
   delay-value     = 1*DIGIT 
    
   duration-param  = "duration=" duration-value 
    
   duration-value  = 1*DIGIT  
    
   repeat-param    = "repeat=" repeat-value 
  
Burger, et. al.            Expires 5/2/2003                          9 

                    Network Announcements with SIP       November 2002 
 
 
    
   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" 
    
   variable-value  = 1*(ALPHA | DIGIT) parameter.  The locale-value consists of language is defined
      as a 2 two letter language code as specified 
   in per ISO 639 [7]and 639-1 [3].  The country variant is
      also defined as a 2 two letter country code specified in per ISO 3166 [8] 
   separated by 3166-1 [4].  These
      elements are concatenated with a single underbar (%x5Fh) (%x5F) character. 
    
   The definition of hostport is as specified by [3]. 
    
   The syntax of prompt-url consists of a URL scheme as specified by 
   [10] or a special token indicating

   param[n] Provides a provisioned mechanism for passing values that are to be
      substituted into an announcement sequence.  We expect the URL  Up to 9 parameters
      ("param1=" through "param9=") may be one 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.  The current
   implementation relies on filename extension conventions for
   determining the media type.







Van Dyke, et al.         Expires July 28, 2003                  [Page 7]


Internet-Draft             SIP Media Services               January 2003


    The form of the following schemes. 
      o http 
      o ftp 
      o file (referencing a local or nfs (RFC 2224) location) 
       
   If a provisioned announcement sequence SIP Request URI for announcements is to be played as follows.
   Note that the value of 
   prompt-url will have backslash, CRLF, and spacing before the following form: 
   prompt-url      = "/provisioned/" announcement-id 
    
   announcement-id = 1*(ALPHA | DIGIT) 
    
   This document is strictly focused on "play=" in the SIP interface
   example is for readability purposes only.

        sip:annc@ms2.example.net; \
          play="http://audio.example.net/allcircuitsbusy.g711"; \
            early=yes

        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 
   announcement service caller and as such does not detail how announcement 
   sequences are provisioned or defined. 
    
   Note that the media type of server.
   However, the object announcement service works as described below even if
   the prompt-url refers caller invokes the service directly.  We chose to can discuss the
   proxy case, as it will be the most anything, including audio file formats, text file formats, 
   URI lists, common case.

   As described above, the "early=" parameter determines whether the
   media server plays the prompt after call setup or even VoiceXML scripts.  See as early media.
   The default value for the Prompt and Collect 
   Service section below "early=" parameter MUST BE "yes".  That is,
   the default action is for more on the media server to play the prompt before
   establishing the call.  We envision that that this topic. 
    
    
5. Prompt and Collect Service 
    
   This service will be
   most commonly used for network announcements which require early
   media, hence that is also known as a dialog.  It establishes an aural 
   dialog with the user. 
    
   There is an implicit prompt and collect service and default behavior.

3.2 Established Call Announcement

3.2.1 Description

   The caller issues an explicit INVITE to the serving SIP Proxy.  The SIP Proxy
   determines what audio prompt and collect service. to play to the caller.  The implicit service leverages proxy
   responds to the fact 
   that caller with 100 TRYING.

   The proxy issues an INVITE to the media server, requesting the
   appropriate prompt URI of to play coded in the play= parameter for the annc service can 
   be any media type.  The explicit service allows for more flexibility 
   in script management. 
    
  
Burger, et. al.            Expires 5/2/2003                         10 

                    Network Announcements with SIP       November 2002 
 
 
    
5.1. Explicit Service parameter.  The dialog service follows INVITE
   MUST contain the model of parameter "early=no" to invoke the announcement Established Call
   Prompting service.  
   However, the service indicator is "dialog".  The dialog service 
   takes media server responds with 200 OK.  The proxy
   sends a parameter, voicexml=, indicating the URI of the VoiceXML 
   script to execute. 
    
        sip:dialog@mediaserver.carrier.net;voicexml=dialog-uri 
    
   A Media Server MAY accept additional SIP request URI parameters and 
   deliver them 200 OK to the VoiceXML interpreter session as session 
   variables. 
    
5.2. Formal Syntax for Explicit Service caller.  The following syntax specification uses the augmented Backus-Naur 
   Form (BNF) as described in RFC-2234 [9]. 
    
   CONF-URL          = "sip:" dialog-ind "@" hostport 
                          dialog-parameters 
     
   dialog-ind        = "dialog" 
    
   dialog-parameters = ";" dialog-param [ vxml-parameters ] 
    
   dialog-param      = "dialog=" dialog-url 
    
   vxml-parameters   = vxml-param [ vxml-parameters ] 
    
   vxml-param        = ";" vxml-keyword "=" vxml-value caller then issues an ACK.  The dialog-url is the URI of the VoiceXML script.  If present, other 
   parameters get passed
   proxy then issues an ACK to the VoiceXML interpreter session with media server.

   With the 
   assigned vxml-keyword vxml-value pairs.  Note that all vxml-keywords 
   MUST have values. 
    
   If call setup, the Media Server does not support media server plays the requested prompt.
   When the passing media server completes the play of keyword-value 
   pairs to the VoiceXML interpreter session, prompt, it MUST ignore issues a
   BYE to the 
   parameters. 
    
    
6. Conference Service 
    
   One identifies mixing sessions through their SIP request URIs.  To 
   create proxy.  The proxy then issues a mixing session, one sends BYE to the caller.





Van Dyke, et al.         Expires July 28, 2003                  [Page 8]


Internet-Draft             SIP Media Services               January 2003


3.2.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 Early Media Announcement

3.3.1 Description

   The caller issues an INVITE to a request URI that 
   represents the session.  If serving SIP Proxy.  Normally, the URI does not already exist on
   SIP Proxy would complete the 
   media server and call to the requested resources are destination.
   However, if the destination is not available, the proxy will request
   a media server creates a new mixing session.  If there is to play an existing URI 
   for audio prompt to the session, then caller.  The proxy
   responds with a 100 TRYING.

   The proxy issues an INVITE to the media server interprets it as a request 
   for server, requesting the new session
   appropriate prompt to join play.  The INVITE MAY contain the existing session. parameter
   "early=yes" or omit the "early=" parameter to invoke the Early Media
   Prompting service.  The form of media server responds with 100 TRYING
   followed by 183 SESSION PROGRESS.  At that point, the media server
   sends the 
   SIP request URI for conferencing is: 
  
Burger, et. al.            Expires 5/2/2003                         11 

                    Network Announcements with SIP       November 2002 
 
 
    
        sip:conf=uniqueIdentifier@mediaserver.carrier.net 
    
   This is actually announcement to the username of caller.  RFC3261 [2] describes the request in 183
   SESSION PROGRESS result code.

   As stated above, if the Media Server cannot fetch the request URI and in the To header.  The host portion of
   "play=" parameter, the URI identifies Media Server will reply with a particular 
   media server.  The "conf=" portion 404 NOT FOUND,
   possibly with an explanation of the user part conveys to failure in the Warning: header.
   Otherwise, after 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 completes the responsibility streaming of the conference control 
   application
   prompt, it MUST send a 487 REQUEST TERMINATED to ensure the identifier is unique within the scope of 
   any potential conflict. 
    
   It is worth noting that the conference URI shared between Proxy.




Van Dyke, et al.         Expires July 28, 2003                  [Page 9]


Internet-Draft             SIP Media Services               January 2003


   Note: When the 
   application and early media provides enhanced security, as service is used the SIP control 
   interface does not have to be exposed to participants.  It also 
   allows requester is
   implicitly asking the assignment of a specific media server to be delayed cancel the transaction as 
   long soon
   as possible, thereby simplifying resource management. 
    
   One can add additional legs to the conference by INVITEing them to 
   the above mentioned request URI.  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 announcement is played.  Since 487 is at least one SIP dialog associated with the given an
   explicit CANCEL request 
   URI. 
    
6.1. Protocol Diagram 
    
   This diagram shows it is appropriate for this use as well.

   The proxy sends the establishment appropriate error response to the caller.  That
   could be 487 or any other appropriate code reflective of a three-way conference.  
   This section is informative. 
    























  
Burger, et. al.            Expires 5/2/2003                         12 

                    Network Announcements with SIP       November 2002 
 
 
    P1       P2        P3         Application Server the failure
   situation.

3.3.2 Protocol Diagram

   Caller                   Proxy                 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     |                   | 
     |       |        |<====================================>| 
     |       |        |                  |                   | 
     |   INVITE sip:public-conf@as.c.net  |               |                        |       |        |----------------->|
     |----------------------->|   INVITE sip:conf=123@ms.c.net 
     |       |        |                  |------------------>| 
     |       |               |
     | 200 OK   100 TRYING           |----------------------->|
     |<-----------------------|   100 TRYING           |
     |                        |<-----------------------|
     |                        | 200 OK           |<------------------|   183 SESSION PROGRESS |
     |        |<-----------------|   183 SESSION PROGRESS |<-----------------------|
     |<-----------------------|                        |
     |                        |                        |
     |              Play Announcement (RTP)            |
     |<================================================|
     |                        | 487 REQUEST TERMINATED |
     |  RTP w/ P1+P2+P3 487 REQUEST TERMINATED |<-----------------------|
     |<-----------------------|                        |
     |   ACK                  |    ACK                 |                  |<=================>|
     |----------------------->|----------------------->|
     |                        |                        |



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 [ ";" early-param ]
                                    [ ";" content-param ]
                                    [ ";" delay-param]
                                    [ ";" duration-param ]
                                    [ ";" repeat-param ]
                                    [ ";" locale-param ]



Van Dyke, et al.         Expires July 28, 2003                 [Page 10]


Internet-Draft             SIP Media Services               January 2003


                                    [ ";" variable-params ]

   play-param      = "play=" prompt-url

   early-param     = "early=" ( "yes" | "no" )

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

   delay-param     = "delay=" delay-value

   delay-value     = 1*DIGIT

   duration-param  = "duration=" duration-value

   duration-value  = 1*DIGIT

   repeat-param    = "repeat=" repeat-value

   repeat-value    = 1*DIGIT

   locale-param    = "locale=" locale-value

   locale-value    = 2ALPHA %x5F 2ALPHA

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

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

   variable-value  = 1*(ALPHA | 
    
   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 DIGIT)

   The MIME-type is the Media Server. 
    
   Each leg can drop out either under MIME [6] content type for the supervision announcement, such
   as audio/basic, audio/G729, audio/mpeg, video/mpeg, and so on.

   To date, none of the UAC by 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 
   UAC sending a BYE or under other hand, the supervision prevalence of parameters may change in the Application Server 
   by the Application Server issuing a BYE.
   future.  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 addition, existing video registrations have parameters,
   such as a trivial exercise to the reader for how the 
   Application Server can mute legs, create side conferences, video/DV.  To accommodate this, 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 retain compatibility with
   the Media Server. 
    
    
  
Burger, et. SIP URI structure, the MIME-type parameter separator (semicolon,
   %3b) and value separator (equal, %d3) MUST be escaped.








Van Dyke, et al.         Expires 5/2/2003                         13 

                    Network Announcements with July 28, 2003                 [Page 11]


Internet-Draft             SIP       November 2002 
 
 
6.2. Formal Syntax Media Services               January 2003


   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 following syntax specification uses the augmented Backus-Naur 
   Form (BNF) locale-value consists of a 2-letter language code as described specified in RFC-2234 [9]. 
    
   CONF-URL        = "sip:" conf-ind "=" instance-id "@"
   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 
    
   conf-ind        = "conf" 
    
   instance-id     = token 
    
    
7. Transcoding Service 
    
7.1. Trans-Coding Overview is as specified by RFC3261 [2].

   The media server provides an interface that enables a SIP UA to 
   request conversion syntax of prompt-url consists of RTP media from one form to another.  It relies 
   on the sending/receiving UA or on a SIP proxy or application server 
   to determine when trans-coding services are needed and to coordinate 
   the signaling with the media server and other SIP endpoints. 
    
   SIP UAs URL scheme as specified by
   RFC2396 [7] or applications may require trans-coding services in at 
   least two scenarios.  The first occurs when two end devices do not 
   share a common codec and therefore need special token indicating a third-party translator provisioned announcement
   sequence.  We expect the URL to 
   communicate.  In this scenario, be one of the end devices would bring 
   the media server into the call.  The second scenario following schemes.

   o  http

   o  ftp

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

   o  nfs (RFC2224 [12])

   If a provisioned announcement sequence is one of two 
   peered networks, each of which mandates use to be played the value of different codecs for 
   their own operational reasons.  Calls
   prompt-url will have the following form:

   prompt-url      = "/provisioned/" announcement-id

   announcement-id = 1*(ALPHA | DIGIT)

   Note that cross network boundaries 
   require trans-coding services.  In this case, the end devices will 
   likely not be aware 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 operational requirements
   announcement service and a proxy as such does not detail how announcement
   sequences are provisioned or 
   application server will bring defined.

   Note that the media server into type of the call. 
    
   The trans-coding scenarios require that object the end device prompt-url refers to can
   be most anything, including audio file formats, text file formats, or 
   application server act as a back-to-back user agent (B2BUA).  This 
   enables
   URI lists.  See the entity requesting trans-coding services to coordinate 
   SIP sessions between other end devices Prompt and the media server 
    
7.2. Collect Service (Section 4) section
   for more on this topic.









Van Dyke, et al.         Expires July 28, 2003                 [Page 12]


Internet-Draft             SIP Media Server Interface 
    
   There are two alternative approaches to providing a trans-coding 
   service.  The first, Services               January 2003


4. Prompt and conceptually simplest, Collect Service

   This service is also known as a trans-coding 
   bridge.  The signaling is similar to that used in conferencing 
   scenarios. voice dialog.  It establishes an
   aural dialog with the user.

    The media server associates dialog service follows the input and output streams 
   from model of the two endpoints using an application supplied unique 
   identifier that announcement service.
   However, the Request URI carries.  This approach has service indicator is "dialog".  The dialog service takes
   a parameter, voicexml=, indicating the 
   advantage that URI of the end device does not need 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 determine the trans-
   coding parameters.  One limitation of this approach is that both 
   call legs must terminate on VoiceXML interpreter session as session
   variables.

4.1 Formal Syntax for Prompt and Collect Service

    The following syntax specification uses the same media server. 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 second alternative, dialog-url is the URI parameter method, takes advantage of the half-duplex nature of RTP VoiceXML script.  If present, other
   parameters get passed to set up two, completely separate, 
   trans-coding paths between the callers.  There is no association 
  
Burger, et. al.            Expires 5/2/2003                         14 

                    Network Announcements VoiceXML interpreter session with SIP       November 2002 
 
 
   between the call legs so the end device must specify
   assigned vxml-keyword vxml-value pairs.  Note that all vxml-keywords
   MUST have values.  The media server presents the trans-
   coding parameters as
   environment variables in the Request URI.  An advantage 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 this approach 
   is that one can use different media servers for each trans-coding 
   path. the VoiceXML interpreter session, it MUST ignore the



Van Dyke, et al.         Expires July 28, 2003                 [Page 13]


Internet-Draft             SIP UAs that desire trans-coding services send a Media Services               January 2003


   parameters.


















































Van Dyke, et al.         Expires July 28, 2003                 [Page 14]


Internet-Draft             SIP Media Services               January 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 request URI that has a user part, which begins with "xcod".  This 
   conveys to the media server that trans-coding services are 
   requested.  The remainder of the URI format is dependent upon 
   whether the bridge or URI parameter method is desired. 
   For
   represents the bridge method, session.  If the Request URI must contain a unique 
   identifier that associates both call legs.  The URI takes the form: 
    
        sip:xcod=uiqueID@mediaserver.provider.net 
    
   where does not already exist on the uniqueID is supplied by
   media server and the end device or controlling 
   application.  SIP Call ID's requested resources are globally unique so the Call ID for 
   the first leg could potentially be used for this parameter. 
    
   Since there is no association between the call legs in the URI 
   parameter case, no unique identifier is needed.  However, the trans-
   coding parameters must be specified explicitly in available, the Request URI 
   with URI parameters.  The media
   server creates a new mixing session.  If there is an existing URI takes for
   the form: 
    
        sip:xcod@mediaserver.provider.net;codec=g711;ptime=10 
    
   The URL parameters codec and ptime describe session, then the desired media format server interprets it as a request for input the
   new session to join the trans-coder. existing session.  The output format and destination IP 
   address/port form of the SIP
   request URI for conferencing is:

   sip:conf=uniqueIdentifier@mediaserver.example.net

   The left-hand side of the request URI is defined by actually the SDP contained username of the
   request in the INVITE.  In its 
   response, request URI and the media server returns SDP with To header.  The host portion of
   the URI identifies a single particular media type 
   matching server.  The "conf=" portion of
   the requested input format and user part conveys to the IP address and port 
   number where it will receive it.  The media server terminates RTP at that this address:port, trans-codes it,  and resends it to is a request for
   the output 
   address:port. 
    
   Because mixing service.  The uniqueIdentifier can be any value that is
   compliant with the Request SIP URI signatures are different, a media server 
   could support both trans-coding interfaces simultaneously.  Further 
   discussions with customers and industry partners are needed to 
   determine if there specification.  It is demand for both methods or if one will 
   suffice. 
    
   The call flows below will further illustrate the use responsibility
   of both 
   methods. 
    
7.3. Call Flows 
    
   The following call flows illustrate the use conference control application to ensure the identifier is
   unique within the scope of any potential conflict.

   It is worth noting that the trans-coding 
   interfaces described above.  In both scenarios, conference URI shared between the
   application and media provides enhanced security, as the end device 
   receives a SIP INVITE containing SDP that it cannot support.  Rather 
   than returning a 4XX class response, it uses third-party call control methods
   interface does not have to bring 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.  Conversely, one can remove legs by
   issuing a media server with trans-coding 
   capabilities into BYE in the call. 
    
  
Burger, et. al.            Expires 5/2/2003                         15 

                    Network Announcements with SIP       November 2002 
 
 
7.3.1. Trans-coding bridge corresponding dialog.  The following call flow depicts a trans-coding 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 utilizing
   URI.

5.1 Protocol Diagram

    This diagram shows the 
   bridge signaling method. 
    
   Caller (A)               Called (B) establishment of a three-way conference.
   This section is informative.

    P1       P2        P3         Application Server     Media Server
     |       |        |                  |    INVITE (SDP A)                   |
     | 
      |----------------------->|  INVITE sip:public-conf@as.c.net  |                   |    100 TRYING
     |---------------------------------->| INVITE sip:conf=123@ms.c.net
     |       | 
      |<-----------------------| INVITE sip:xcod=id (SDP B)        |                  |------------------>|
     |       |                        |---------------------------->|        |                  | 200 OK (SDP M1)            |
     |                        |<----------------------------|  200 OK        |                  |<------------------|
     |<----------------------------------|                   | ACK



Van Dyke, et al.         Expires July 28, 2003                 [Page 15]


Internet-Draft             SIP Media Services               January 2003


     |       |                        |---------------------------->|        |                        |<========= RTP (B)==========>| w/ P1        |                   | INVITE sip:xcod=id (SDP A)
     |<=====================================================>|
     |       |                        |---------------------------->|        |                  | 200 OK (SDP M2)                   |
     |    200 OK (SDP M2)     |<----------------------------| 
      |<-----------------------|  INVITE sip:public-conf@as.c.net  |                   |    ACK
     |       |-------------------------->| INVITE sip:conf=123@ms.c.net
     | 
      |----------------------->| ACK       |        |                        |---------------------------->| 
      |<=================== RTP (A) * ======================>| 
    
    
   * The Media Server implicitly transcodes between the associated 
   legs.  At this point, the Media Server bridges the two legs. 
    
    
7.3.2. URI Parameter Method 
    
   The following depicts a trans-coding call-flow using the URI 
   parameter method. 
    
















  
Burger, et. al.            Expires 5/2/2003                         16 

                    Network Announcements with SIP       November 2002 
 
 
   Caller (A)               Called (B)                 Media Server                  |------------------>|
     |       |        |                  |  1. INVITE (SDP A) 200 OK            |
     | 
      |----------------------->|       | 200 OK |  2.  100 TRYING                  |<------------------|
     |       |<--------------------------|                   | 
      |<-----------------------| 3. INVITE sip:xcod;codec=A
     |       |                        |---------------------------->| (1)        |                  |           ;ptime=A (SDP B)                   |
     |       |        | RTP w/ P1+P2-P2  |                   |
     | 4. 200 OK (SDP M1)       |<=============================================>|
     |       |                        |<----------------------------| (2)        | RTP w/ P1+P2-P1  | 5. ACK                   |
     |<=====================================================>|
     |                        |---------------------------->|       |        |                  |                   |
     | 6.  INVITE sip:xcod;codec=B sip:public-conf@as.c.net  |                   |                        |---------------------------->| (3)
     |       |           ;ptime=B (SDP A)        |----------------->| INVITE sip:conf=123@ms.c.net
     |       |        |                  |------------------>|
     |       |        |                  | 7. 200 OK (SDP M2)            |
     |  8.       |        | 200 OK (SDP M2)   |<----------------------------| (4) 
      |<-----------------------|           |<------------------|
     |       |  9.  ACK        |<-----------------|                   |
     |       | 
      |----------------------->| 10. ACK        |                  |                        |---------------------------->|                   |
     |       | 
      |==================== RTP (A) ========================>|\(5)        |                        |<==== RTP (A in B format)====|/ w/ P1+P2+P3-P3                   |
     |       |        |<====================================>|
     |       |        |                        |===== RTP (B) ==============>|\(6) 
      |============= w/ P1+P2+P3-P2                   |
     |       |<=============================================>|
     |       |        | RTP (B in A format) ===================>|/ w/ P1+P2+P3-P1                   |
     |<=====================================================>|
     |       |        | 
    
   Ladder diagram notes: 
   (1)  Requests a session                  |                   |
     |       |        |                  |                   |

   Note that can receive media A, transcode it to 
        media format B, and send it to B's IP address:port as described 
        in SDP B. 
   (2)  Contains SDP with address:port for caller (A) to send to. 
   (3)  Requests a session session the above call flow does not show any 100 TRYING messages
   that can receive media B, transcode 
        it would typically flow from the Application Server to media format A, and send the UAC's,
   nor does it show the ACK's from the UAC's to A's IP address:port as 
        described in SDP A. 
   (4)  Contains SDP with address:port for caller (B) to send to. 
   (5)  Media the Application Server loops RTP in media format A to B. 
   (6)  Media
   or from the Application Server loops RTP in media format B to A. 
    
   Note that messages 6, 7, and 10 the Media Server.

   Each leg can go to drop out either under the supervision of the UAC by the
   UAC sending a different Media BYE or under the supervision of the Application Server 
   than 3, 4, and 5.
   by the Application Server issuing a BYE.  In this either case, the second Media
   Application Server will do either issue a BYE on behalf of the 
   B UAC or
   issue it directly to A transcoding.  
    
    




  
Burger, et. al.            Expires 5/2/2003                         17 

                    Network Announcements with SIP       November 2002 
 
 
7.3.3. Message Flow 
    
   Message 1 
    
   INVITE sip:callee@company2.com SIP/2.0 
   Via: SIP/2.0/UDP a.company1.com 
   From: sip:caller@company1.com 
   To: sip:callee@company2.com 
   Call-ID: 125@1.2.3.4 
   CSeq: 1 INVITE 
   Contact: sip:caller@a.company1.com 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP A> 
    
    
    
   Message 2 
    
   SIP/2.0 100 Trying 
   Via: SIP/2.0/UDP a.company1.com 
   From: sip:caller@company1.com 
   To: sip:callee@company2.com;tag=8abj8gh 
   Call-ID: 125@1.2.3.4 
   CSeq: 1 INVITE 
    
    
    
   Message 3 
    
   INVITE sip:xcod@mediaserver.carrier.net;codec=A;ptime=A SIP/2.0 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=A;ptime=A 
   Call-ID: 234@5.6.7.8 
   CSeq: 1 INVITE 
   Contact: sip:callee@b.company2.com 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP B> 
    
    
    








  
Burger, et. al.            Expires 5/2/2003                         18 

                    Network Announcements with SIP       November 2002 
 
 
   Message 4 
    
   SIP/2.0 200 OK 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=A;ptime=A;tag=9ab6g2 
   Call-ID: 234@5.6.7.8 
   CSeq: 1 INVITE 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP M1> 
    
    
    
   Message 5 
    
   ACK sip:xcod@mediaserver.carrier.net;codec=A;ptime=A SIP/2.0 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=A;ptime=A;tag=9ab6g2 
   Call-ID: 234@5.6.7.8 
   CSeq: 1 ACK 
    
    
    
   Message 6 
    
   INVITE sip:xcod@mediaserver.carrier.net;codec=B;ptime=B SIP/2.0 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=B;ptime=B 
   Call-ID: 678@5.6.7.8 
   CSeq: 1 INVITE 
   Contact: sip:callee@b.company2.com 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP A> 
    
    
    











  
Burger, et. al.            Expires 5/2/2003                         19 

                    Network Announcements with SIP       November 2002 
 
 
   Message 7 
    
   SIP/2.0 200 OK 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=B;ptime=B;tag=7ab7gh 
   Call-ID: 678@5.6.7.8 
   CSeq: 1 INVITE 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP M2> 
    
    
   Message 8 
    
   SIP/2.0 200 OK 
   Via: SIP/2.0/UDP a.company1.com 
   From: sip:caller@company1.com 
   To: sip:callee@company2.com;tag=8abj8gh 
   Call-ID: 125@1.2.3.4 
   CSeq: 1 INVITE 
   Contact: sip:caller@a.company1.com 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP M1> 
    
    
    
   Message 9 
    
   ACK sip:callee@company2.com SIP/2.0 
   Via: SIP/2.0/UDP a.company1.com 
   From: sip:callee@company2.com 
   To: sip:callee@company2.com;tag=8abj8gh 
   Call-ID: 125@1.2.3.4 
   CSeq: 1 ACK 
   Message 7 
   SIP/2.0 200 OK 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=B;ptime=B;tag=7ab7gh 
   Call-ID: 678@5.6.7.8 
   CSeq: 1 INVITE 
   Content-Type: application/sdp 
   Content-Length: XX 
    
   <SDP M2> 
    
    


  
Burger, et. 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



Van Dyke, et al.         Expires 5/2/2003                         20 

                    Network Announcements with July 28, 2003                 [Page 16]


Internet-Draft             SIP       November 2002 
 
 
   Message 10 
    
   ACK sip:xcod@mediaserver.carrier.net;codec=B;ptime=B SIP/2.0 
   Via: SIP/2.0/UDP b.company2.com 
   From: sip:callee@company2.com 
   To: sip:xcod@mediaserver.carrier.net;codec=B;ptime=B;tag=7ab7gh 
   Call-ID: 678@5.6.7.8 
   CSeq: 1 ACK 
    
    
    
7.4. Media Services               January 2003


   (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 RFC-2234 [Error! Bookmark not defined.]. 
    
   XCOD-URL RFC2234 [5].

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

   conf-ind        = "xcod" "conf"

   instance-id     = token 
    
   xcod-parameters = xcod-parameter / ";" xcod-parameters 
    
   xcod-parameter = codec-param / ptime-param 
    
   Where codec-param is one of the RTP codec labels [verify source and 
   input cross reference] and ptime-param is the packet time, in 
   milliseconds. 
    
    
8.






































Van Dyke, et al.         Expires July 28, 2003                 [Page 17]


Internet-Draft             SIP Media Services               January 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 RFC 2821 [11]. RFC2821 [13].  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. 
    
  
Burger, et. al.            Expires 5/2/2003                         21 

                    Network Announcements with SIP       November 2002

   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
   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 RFC 3067 
   [12] RFC3087
   [14] 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



Van Dyke, et al.         Expires July 28, 2003                 [Page 18]


Internet-Draft             SIP Media Services               January 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, et.





























Van Dyke, et al.         Expires 5/2/2003                         22 

                    Network Announcements with July 28, 2003                 [Page 19]


Internet-Draft             SIP       November 2002 
 
 
9. Media Services               January 2003


7. 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, and service providers should plan their network service
   offerings accordingly.

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






































Van Dyke, et al.         Expires July 28, 2003                 [Page 20]


Internet-Draft             SIP Media Services               January 2003


8. IANA Considerations

   Because of great consternation about whether or not there would be a
   generic application name space, it was decided that we would not
   establish an IANA registry.














































Van Dyke, et al.         Expires July 28, 2003                 [Page 21]


Internet-Draft             SIP Media Services               January 2003


9. 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 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.  Pete Danielson from Lucent
   provided an excellent review of the -00 draft.

   The authors would like to give a special thanks to Walter O'Connor
   for doing most of the implementations.







































Van Dyke, et al.         Expires July 28, 2003                 [Page 22]


Internet-Draft             SIP Media Services               January 2003


Normative References 
    
 
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
      INFORMATIVE 
    
   2

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997. 
      NORMATIVE 
    
   3  J. Rosenberg, et. al., "SIP: Session Initiation Protocol", RFC 
      3261, June 2002. 
      NORMATIVE 
    
   4  H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A 
      Transport Protocol for Real-Time Applications", RFC 1889, January 
      1996. 
      NORMATIVE 
    
   5  Charlton, N., et. al., "User Requirements for the 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 (SIP) in support of deaf, hard of hearing and 
      speech-impaired individuals", draft-ietf-sipping-deaf-req-03.txt, 
      April 2002, work in progress. 
      INFORMATIVE 
     
   6  McGlashan, S., et. al., "Voice Extensible Markup Language 
      (VoiceXML) Version 2.0", http://www.w3.org/TR/voicexml20/, April Protocol", RFC 3261, June 2002. 
      INFORMATIVE 
    
   7  ISO 639,

   [3]  ISO, "Codes for the representation of names of languages", 
      1998. 
      NORMATIVE 
    
 


  
Burger, et. al.            Expires 5/2/2003                         23 

                    Network Announcements with SIP       November 2002 
 
 
 
   8 languages -- Part
        1: Alpha-2 code", ISO 3166, 639-1, July 2002.

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

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

   [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., R. and L. Masinter, L., "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 
      1988. 
      NORMATIVE 
 
   11 Klensin, J. (ed.), "Simple Mail Transfer Protocol", RFC 2821, 
      April 2001. 
      INFORMATIVE 
    
   12 Campbell, B. and Sparks, R., "Control of Service Context using 1998.

























Van Dyke, et al.         Expires July 28, 2003                 [Page 23]


Internet-Draft             SIP Request-URI", RFC 3087, April 2001. 
      INFORMATIVE 
    
    
11. Changes 
   <This section will be removed before final submission> 
    
11.1. Changes Made in Version 03 
    
   Removed Implicit Service. 
    
   Separated Normative and Media Services               January 2003


Informative references. 
    
11.2. Changes Made in Version 02 
    
   Removed implicit play= operation in section 5.1. 
    
11.3. Changes Made in Version 01 
    
   This document underwent significant updating as a result of the Las 
   Vegas Interim Workgroup Meeting. 
    
   For the Announcement Service description: 
      o Added duration, repeat, delay, locale References

   [8]   Schulzrinne, H., Casner, S., Frederick, R. and variable parameters. 
      o Added the ability to reference a provisioned announcement. 
      o Made early media treatment the default behavior V. Jacobson,
         "RTP: A Transport Protocol for the 
        service. 
      o 487 REQUEST TERMINATED replaces 486 BUSY HERE as the media 
        serverĘs final response when early media treatment is desired. Real-Time Applications", RFC
         1889, January 1996.

   [9]   World Wide Web Consortium, "Voice Extensible Markup Language
         (VoiceXML) Version 2.0", W3C Working Draft , April 2002,
         <http://www.w3.org/TR/voicexml20/>.

   [10]  Burger, et. al.            Expires 5/2/2003                         24 

                    Network Announcements with SIP E., Van Dyke, J. and A. Spitzer, "SnowShore Media
         Server Control Markup Language and Protocol",
         draft-vandyke-mscml-00 (work in progress), November 2002 
 
 
12. Acknowledgments 
    
   We would like to thank Kevin Summers 2002.

   [11]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
         C., Eisler, M. and Ravindra Kabre of Sonus 
   Networks for their constructive comments, as well as Jonathan 
   Rosenberg D. Noveck, "NFS version 4 Protocol", RFC
         3010, December 2000.

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

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

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

   [15]  Charlton, N., Gasson, M., Gybels, G., Spanner, M. and Tim Melanchuk A. van
         Wijk, "User Requirements for their encouragement.  
   In addition, the discussion at the Las Vegas Interim Workgroup 
   Meeting Session Initiation Protocol
         (SIP) in 2002 was invaluable for clearing up the issues 
   surrounding the left-hand-side Support of the request URI. 
    
    
13. Author's Deaf, Hard of Hearing and Speech-impaired
         Individuals", RFC 3351, August 2002.


Authors' Addresses 
    
   Eric Burger (Editor) 
   Andy Spitzer

   Jeff Van Dyke
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA 
    
   Phone: 978/367-8400 
   Email: eburger@snowshore.com 
   Email: woof@snowshore.com 
   Email:

   EMail: jvandyke@snowshore.com 
    
    
   Walter O'Connor 
   Amherst, NH










Van Dyke, et al.         Expires July 28, 2003                 [Page 24]


Internet-Draft             SIP Media Services               January 2003


   Eric Burger
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA 
    
   Email: woconnor@bit-net.com  
    
    




















  
Burger, et.

   EMail: e.burger@ieee.org


   Andy Spitzer
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

   EMail: woof@snowshore.com



































Van Dyke, et al.         Expires 5/2/2003                         25 

                    Network Announcements with July 28, 2003                 [Page 25]


Internet-Draft             SIP       November 2002 Media Services               January 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 (2001, 2002). (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 assigns. 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



Van Dyke, et al.         Expires July 28, 2003                 [Page 26]


Internet-Draft             SIP Media Services               January 2003


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


Acknowledgement 
    
   The Internet Society currently provides funding

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

   SnowShore Networks, Inc. is a member of the Internet Society. 
    
    















  
Burger, et.








































Van Dyke, et al.         Expires 5/2/2003                         26 July 28, 2003                 [Page 27]




----