view Side-By-Side changes
Network Working GroupW. O'ConnorJ. Van Dyke Internet Draft E. Burger (ed.) Document:draft-burger-sipping-netann-01.txt J. Van Dykedraft-burger-sipping-netann-03.txt A. Spitzer Category: Standards Track SnowShore Networks, Inc. Expires: May20022003 W. O'Connor November21, 20012, 2002 Basic NetworkAnnouncementsMedia Services with SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 document is the result of a chartered SIPPING work group item. 1.Abstract In SIP-basednetworks [2],networks, there is a need to provideannouncements. In some situations,basic network media services. Such services include network announcements, user interaction, conferencing, and transcoding services. These services are basic building blocks, from which onemust play the announcement without providing an answer indication.can construct interesting applications. Inothers,order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, onemust play the announcement after completing call setup. This document describes howneeds toprovidebe able to locate and invoke suchannouncementsservices in aSIP-based network. The method described here is a media server service instance. Thewell-defined manner. This document[3]describesgeneric URI'sa 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 mediaserver service instances.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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[4]. O'Connor,[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.al. Expires5/21/2002 15/2/2003 2 Network Announcements with SIP November2001 3. Overview A network announcement is the delivery2002 These services are basic in nature, are few in number, and fundamentally have not changed in 25 years ofan audio resource, such as a prompt file,enhanced telephony services. Moreover, given their elemental nature, one would not expect them toa terminal device. Therechange in the future. Announcements aretwo types of network announcements. The differentiating characteristic betweenmedia played to thetwo types is whether the network fully sets up the call before playing the announcement. The analoguser. Announcements can be static media files, media files generated in real-time, media streams generated in real-time, or combinations of thePSTN is whether answer supervision is supplied; i.e. doesabove. In some situations, one must play the announcementserverwithout providing an answer indication. In others, one must play thecall prior to delivering the announcement. Playing anannouncement after completing callsetup is straightforward. First, the requesting device issues an INVITEsetup. This document describes how totheprovide such announcements in a SIP-based network. The method described here is a media serverrequestingservice instance. Media mixing is theannouncement service. Theact of mixing different RTP streams, as described in [4]. Note that the service described here will suffice for simple mixing of mediaserver negotiatesfor a basic conferencing service. One can create a complete conferencing service using this basic building block. However, this service does not address theSDPinteresting application-level issues such as conferencing, floor control, etc. Transcoding is the act of taking an RTP stream coded with one codec andrespondsplaying it as a new RTP stream coded with another codec. For example, taking a200 OK. After receivingG.711-encoded stream and transcoding it to G.729e. In addition, theACK frommechanism described here satisfies therequesting device,needs of the hearing-impaired requirements [5] for a transcoding service. Prompt and collect is where themediaserverplaysprompts therequested promptuser for some information, as in an announcement, andissues a BYE tothen collects therequesting device.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. Mechanism Inreplicating and expanding ontheexisting telephone network, there iscontext of SIP control of media servers, we take advantage of the fact that the standard SIP URI has aneed to play announcements during call setup. That is,user part. Media servers do not have a concept of a user. Thus we use thenetwork delivers media touser address, or thecaller beforeleft-hand-side of thesetup completes. Network operators need this capability to provide informational network announcements, suchURI, 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."a service indicator. Note thatsimply redirecting the caller to a media server, withthemedia server issuing a 200 OK response,set of services isnot appropriate.small, well-defined, and well- contained. Thecall has not completed successfully. To support the appropriate paradigm,section "The User Part", Section 8 below, discusses themedia serverissuesa 100 TRYING response, followed immediately by a 183 SESSION PROGRESS responsewithSDP. This enablesusing a fixed set of user-space names. For per-service security, the media serverto send early media toMAY use any of thecaller.security protocols described in [3]. The media serversends the requested audio. After playingMAY issue 401 challenges for authentication. Burger, et. al. Expires 5/2/2003 3 Network Announcements with SIP November 2002 The media server, upon receiving theaudio,INVITE, notes themedia server issues a 487 REQUEST TERMINATED response code toservice indicator. Depending on therequesting device. Ifservice indicator, the media serverdoes not support announcements, it MUST respond withwill either honor the488 NOT ACCEPTABLE HERErequest or return a failure responsecode, as specified by [3]. If the media server supports announcements, but it cannot findcode. The service indicator is thereferenced URI, it MUST respond withconcatenation of the404 NOT FOUND response code, as specifiedservice name and an optional service instance identifier, separated by[3]. If the media server receivesanINVITE forequal sign. Per SIP, theannouncementservicewithout a "play=" parameter, itindicator is case insensitive. The service name MUSTrespond withbe from the404set alphanumeric characters plus dash (US- ASCII %2C). The service name MUST NOTFOUND response code,include an equal sign (US- ASCII %3C). The service name MAY have long- and short-forms, asthere is no default valueSIP does forthe announcement service. If there isheaders. A given service indicator MAY have anerror retrievingassociated set of parameters. Such parameters MUST follow theannouncement,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 MUSTrespond with an appropriate 4xx error code reflectingmeet theerror. O'Connor, et. al. Expires 5/21/02 2 Network Announcements withrules for a legal user part of a SIPNovember 2001 4. Announcement Service The Request URI fully describesURI. An equal sign, US-ASCII %3D, MUST separate theannouncementservicethroughindicator from theuse ofunique identifier. Note that since theuser part ofservice indicator is case insensitive, theaddress and additional URI parameters, as described in [3].service instance identifier is also case insensitive. Theuser portion ofrequesting client issues a SIP INVITE to theaddress, "annc", specifiesmedia server, specifying theannouncementrequested serviceonand any appropriate parameters. If the mediaserver. The service has several associated URI parameters that controlserver can perform thecontent and delivery ofrequested service, it does so, following theannouncement. These parameters areprocessing steps describedbelow: "play=" specifiesin theaudio resource or announcement sequence to be played. "early=" Specifies whether early media treatment is desired. "repeat=" Specifies how many timesservice definition document (see IANA Considerations, below). If the media servershould repeatcannot perform theannouncementrequested service orsequence named bydoes not recognize the"play=" parameter. "delay=" Specifies a delay interval between announcement repetitions. The delayservice indicator, it MUST respond with the response code 488 NOT ACCEPTABLE HERE. This ismeasured in milliseconds. "duration=" Specifiesappropriate, as 488 refers to a problem with themaximum durationuser part of theannouncement. TheURI. Moreover, 606 is not appropriate, as some other media serverwill discontinuemay be able to satisfy theannouncementrequest. [3] describes the 488 andend606 response codes. Some services require a unique identifier. Most services automatically create a service instance upon thecallfirst INVITE with the given identifier. However, if a service requires an existing service instance, and no such service instance exists on themaximum duration has been reached. The duration is measured in milliseconds. "locale=" Specifies the language and country variant ofmedia server, theannouncement sequence named inmedia server MUST respond with the"play=" parameter. The language is defined as a two letterresponse codeper ISO 639 [5]. The country variant404 NOT FOUND. This isalso definedappropriate asa two letter code per ISO 3166 [6]. These elements are concatenated with a single underbar (%x5F) character. "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 "play=" parameter is mandatory and 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 a "media=" parameter? The form oftheSIP Request URI for announcements is as follows. Note thatservice itself exists on thebackslash, CRLF, and spacing beforemedia server, but the"play="particular service instance does not. It isfor 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" O'Connor,as if the user was not home. Burger, et. al. Expires5/21/02 35/2/2003 4 Network Announcements with SIP November2001 5. Operation The scenarios below assume there2002 4. Announcement Service A network announcement is the delivery of an audio resource, such as aSIP Proxy, application server, or SoftSwitchprompt file, to a terminal device. There are two types of network announcements. The differentiating characteristic between thecaller and the media server. However,two types is whether theannouncement service works as described below even ifnetwork fully sets up thecaller invokescall before playing theservice directly. We chose to discussannouncement. The analog in theproxy case, as it will be the most common case. As described above, the "early=" parameter determinesPSTN is whether answer supervision is supplied; i.e. does themediaannouncement serverplaysanswer theprompt aftercallsetup or as early media. The default value for the "early=" parameter MUST BE "yes". That is, the default action is for the media serverprior toplay the prompt before establishing the call. We envision that that this service will be most commonly used for network announcements which require early media, hence that isdelivering thedefault behavior. 5.1. Established Call Prompting 5.1.1. Description The caller issuesannouncement. Playing anINVITE to the serving SIP Proxy. The SIP Proxy determines what audio prompt to play to the caller. The proxy responds toannouncement after call setup is straightforward. First, thecaller with 100 TRYING. The proxyrequesting device issues an INVITE to the mediaserver,server requesting theappropriate prompt to play coded in the play= parameter. The INVITE MUST contain the parameter "early=no" to invoke the Established Call Promptingannouncement service. The media server negotiates the SDP and responds with200 OK. The proxy sendsa 200OK toOK. After receiving thecaller. The caller then issues an ACK. The proxy then issues anACKto the media server. Withfrom thecall setup,requesting device, the media server plays the requestedprompt. When the media server completes the play of the prompt, itprompt and issues a BYE to theproxy. The proxy then issuesrequesting device. In replicating and expanding on the existing telephone network, there is aBYEneed to play announcements during call setup. That is, thecaller. O'Connor, et. al. Expires 5/21/02 4network delivers media to the caller before the setup completes. NetworkAnnouncements with SIP November 2001 5.1.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 | |----------------------->|----------------------->| | | | 5.2. Early Media Prompting 5.2.1. Description The caller issues an INVITEoperators need this capability tothe serving SIP Proxy. Normally, the SIP Proxy would complete the callprovide informational network announcements, such as "The person you are trying tothe requested destination. However, if the destinationreach isnot available,unavailable. Good Bye." or "We are sorry, but all circuits are busy. Please try your call again later. Good Bye." Note that simply redirecting theproxy will request a media server to play an audio promptcaller tothe caller. The proxy responds witha100 TRYING. The proxy issues an INVITE to themedia server,requestingwith theappropriate prompt to play.media server issuing a 200 OK response, is not appropriate. TheINVITE MUST contain the parameter "early=yes" or omitcall has not completed successfully. To support the"early=" parameter to invokeappropriate paradigm, theEarly Media Prompting service. Themedia serverresponds withissues a 100 TRYING response, followed immediately by a 183 SESSIONPROGRESS. At that point,PROGRESS response with SDP. This enables the media serversends the announcementto send early media to the caller. Thedocument [7] describesmedia server sends the183 SESSION PROGRESS result code.requested audio. After playing the audio, the media servercompletes the streaming of the prompt, it MUST sendissues a 487 REQUEST TERMINATED response code to theProxy. Note: Whenrequesting device. If theearlymediaservice is usedserver does not support announcements, it MUST respond with therequester is implicitly asking488 NOT ACCEPTABLE HERE response code. If the media serverto cancelsupports announcements, but it cannot find thetransaction as soon asreferenced 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 isplayed. Since 487no default value for the announcement service. If there isassociated withanexplicit CANCEL request it seems appropriate for this use as well. The 00 version specified 486 BUSY HERE aserror retrieving the announcement, the media server MUST respond with an appropriateresponse in this scenario. However, 486 might could potentially be mis- interpreted as a true busy by4xx error code reflecting therequester so its use has been deprecated. O'Connor,error. Burger, et. al. Expires5/21/025/2/2003 5 Network Announcements with SIP November20012002 Theproxy sendsRequest URI fully describes theappropriate error response toannouncement service through thecaller. That could be 487 or any other appropriate code reflectiveuse of thefailure situation. 5.2.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 | |----------------------->|----------------------->| | | | 6. Formal Syntaxuser part of the address and additional URI parameters. Thefollowing syntax specification usesuser portion of theaugmentedaddress, "annc", specifies the announcement service on the media server. The service has several associated URI parameters that control the content and delivery of the announcement. These parameters are described below: "play=" specifies the audio resource or announcement sequence to be played. "early=" Specifies whether early media treatment is desired. "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 [7]. The country variant is also defined as a two letter code per ISO 3166 [8]. These elements are concatenated with a single underbar (%x5F) character. "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 "play=" parameter is mandatory and 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 a "media=" parameter? The form of the SIP Request URI for announcements is as follows. Note that the backslash, CRLF, and spacing before the "play=" 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 The scenarios below assume there is a SIP Proxy, application server, or SoftSwitch 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. As described above, the "early=" parameter determines whether 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, the default action is for the media server to play the prompt before establishing the call. We envision that that this service will be most commonly used for network announcements which require early media, hence that is the default behavior. 4.2. Established Call Announcement 4.2.1. Description 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 INVITE MUST contain the parameter "early=no" to invoke the Established Call Prompting service. 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 setup, the media server plays the requested prompt. When the media server completes the play of the prompt, it issues a BYE to the proxy. The proxy then issues a BYE to the caller. Burger, et. al. 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 to the serving SIP Proxy. Normally, the SIP Proxy would complete the call to the requested destination. However, if the destination is not available, the proxy will request a media server to play an audio prompt to the caller. The proxy responds with a 100 TRYING. The proxy issues an INVITE to the media server, requesting the appropriate prompt to play. The INVITE MUST contain the parameter "early=yes" or omit the "early=" parameter to invoke the Early Media Prompting service. The media server responds with 100 TRYING followed by 183 SESSION PROGRESS. At that point, the media server sends the announcement to the caller. The document [3] 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. 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 seems appropriate for this use as well. Burger, et. al. Expires 5/2/2003 8 Network Announcements with SIP November 2002 The proxy sends the appropriate error response to the caller. That could be 487 or any other appropriate code reflective of 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 The following syntax specification uses the augmented Backus-Naur Form (BNF) as described 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 = "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) The locale-value consists of a 2 letter language code as specified in ISO 639 [7]and a 2 letter country code specified in ISO 3166 [8] separated by a single underbar (%x5Fh) 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 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 (RFC 2224) location) 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) 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, URI lists, or even VoiceXML scripts. See the Prompt and Collect Service section below for more on this topic. 5. Prompt and Collect Service This service is also known as a dialog. It establishes an aural dialog with the user. There is an implicit prompt and collect service and an explicit prompt and collect service. The implicit service leverages the fact that the prompt URI of 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 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.carrier.net;voicexml=dialog-uri A Media Server MAY accept additional SIP request URI parameters and deliver them to the VoiceXML interpreter session as session variables. 5.2. Formal Syntax for Explicit Service 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 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 the Media Server does not support the passing of keyword-value pairs to the VoiceXML interpreter session, it MUST ignore the parameters. 6. 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: Burger, et. al. Expires 5/2/2003 11 Network Announcements with SIP November 2002 sip:conf=uniqueIdentifier@mediaserver.carrier.net This 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=" portion of the user part 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. 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. 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. 6.1. Protocol Diagram This diagram shows the establishment 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 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 | | | | 200 OK |<------------------| | | |<-----------------| | | | | | | | | | | RTP w/ P1+P2+P3 | | | | |<=================>| | | | | | 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. Burger, et. al. Expires 5/2/2003 13 Network Announcements with SIP November 2002 6.2. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [9]. CONF-URL = "sip:" conf-ind "=" instance-id "@" hostport conf-ind = "conf" instance-id = token 7. Transcoding Service 7.1. Trans-Coding Overview The media server provides an interface that enables a SIP UA to request conversion 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 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 a third-party translator to communicate. In this scenario, one of the end devices would bring the media server into the call. The second scenario is one of two peered networks, each of which mandates use of different codecs for their own operational reasons. Calls that cross network boundaries require trans-coding services. In this case, the end devices will likely not be aware of the operational requirements and a proxy or application server will bring the media server into the call. The trans-coding scenarios require that the end device or application server act as a back-to-back user agent (B2BUA). This enables the entity requesting trans-coding services to coordinate SIP sessions between other end devices and the media server 7.2. Media Server Interface There are two alternative approaches to providing a trans-coding service. The first, and conceptually simplest, is a trans-coding bridge. The signaling is similar to that used in conferencing scenarios. The media server associates the input and output streams from the two endpoints using an application supplied unique identifier that the Request URI carries. This approach has the advantage that the end device does not need to determine the trans- coding parameters. One limitation of this approach is that both call legs must terminate on the same media server. The second alternative, the URI parameter method, takes advantage of the half-duplex nature of RTP 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 with SIP November 2002 between the call legs so the end device must specify the trans- coding parameters in the Request URI. An advantage to this approach is that one can use different media servers for each trans-coding path. SIP UAs that desire trans-coding services send a SIP INVITE to a 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 the bridge method, 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 the uniqueID is supplied by the end device or controlling application. SIP Call ID's 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 the Request URI with URI parameters. The URI takes the form: sip:xcod@mediaserver.provider.net;codec=g711;ptime=10 The URL parameters codec and ptime describe the desired media format for input to the trans-coder. The output format and destination IP address/port is defined by the SDP contained in the INVITE. In its response, the media server returns SDP with a single media type matching the requested input format and the IP address and port number where it will receive it. The media server terminates RTP at this address:port, trans-codes it, and resends it to the output address:port. Because the Request 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 is demand for both methods or if one will suffice. The call flows below will further illustrate the use of both methods. 7.3. Call Flows The following call flows illustrate the use of the trans-coding interfaces described above. In both scenarios, 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 to bring a media server with trans-coding capabilities into the call. Burger, et. al. Expires 5/2/2003 15 Network Announcements with SIP November 2002 7.3.1. Trans-coding bridge The following call flow depicts a trans-coding request utilizing the bridge signaling method. Caller (A) Called (B) Media Server | | | | INVITE (SDP A) | | |----------------------->| | | 100 TRYING | | |<-----------------------| INVITE sip:xcod=id (SDP B) | | |---------------------------->| | | 200 OK (SDP M1) | | |<----------------------------| | | ACK | | |---------------------------->| | |<========= RTP (B)==========>| | | INVITE sip:xcod=id (SDP A) | | |---------------------------->| | | 200 OK (SDP M2) | | 200 OK (SDP M2) |<----------------------------| |<-----------------------| | | ACK | | |----------------------->| 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) | | |----------------------->| | | 2. 100 TRYING | | |<-----------------------| 3. INVITE sip:xcod;codec=A | | |---------------------------->| (1) | | ;ptime=A (SDP B) | | | | | | 4. 200 OK (SDP M1) | | |<----------------------------| (2) | | 5. ACK | | |---------------------------->| | | | | | 6. INVITE sip:xcod;codec=B | | |---------------------------->| (3) | | ;ptime=B (SDP A) | | | | | | 7. 200 OK (SDP M2) | | 8. 200 OK (SDP M2) |<----------------------------| (4) |<-----------------------| | | 9. ACK | | |----------------------->| 10. ACK | | |---------------------------->| | | | |==================== RTP (A) ========================>|\(5) | |<==== RTP (A in B format)====|/ | | | | |===== RTP (B) ==============>|\(6) |============= RTP (B in A format) ===================>|/ | | | Ladder diagram notes: (1) Requests a session 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 that can receive media B, transcode it to media format A, and send it 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 Server loops RTP in media format A to B. (6) Media Server loops RTP in media format B to A. Note that messages 6, 7, and 10 can go to a different Media Server than 3, 4, and 5. In this case, the second Media Server will do the B 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. al. Expires 5/2/2003 20 Network Announcements with 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. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234[8]. ANNC-URL[Error! Bookmark not defined.]. XCOD-URL = "sip:"annc-indxcod-ind "=" instance-id "@" hostportannc-parameters annc-ind = "annc" annc-parameters = ";" play-param [ ";" early-param ] [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ] [ ";" locale-param ] [ ";" variable-params ] play-param = "play=" prompt-url early-paramxcod-parameters xcod-ind ="early=" ( "yes" | "no" ) delay-param = "delay=" delay-value delay-value = 1*DIGIT duration-param"xcod" instance-id ="duration=" duration-value duration-valuetoken xcod-parameters =1*DIGIT repeat-paramxcod-parameter / ";" xcod-parameters xcod-parameter ="repeat=" repeat-value O'Connor,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. 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]. 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. Expires5/21/02 65/2/2003 21 Network Announcements with SIP November2001 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)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 . 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. Thelocale-value consistsmost 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 a2 letter language code as specifiedpure matter of local convention. For example, the thesis of the informational RFC 3067 [12] 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 inISO 639 [5]anda2 letter country code specifiedclosed network, where the Application Servers and Media Servers are inISO 3166 [6] separated by a single underbar (%x5Fh) character. The definitionthe same administrative domain, this does not work across domains. This is because the client ofhostportthe media service has to know the local name for each service / domain pair. This isas specified by [2]. The syntaxparticularly 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 ofprompt-url consistsusing the user part as the service descriptor is that we can use all ofa URL schemethe standard SIP machinery, without modification. For example, Media Servers with different capabilities can SIP Register their capabilities asspecified by [9] or a special token indicatingusers. For example, aprovisioned announcement sequence. We expectmixing-only device will register theURL to be one"conf" user, while a multi-purpose Media Server will register all of thefollowing schemes. o http o ftp o file (referencingusers. Note that this is why the URI to play is alocal or nfs (RFC 2224) location) Ifparameter. Doing otherwise would overburden aprovisioned announcement sequence isnormal 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 tobe playedprovide high-available services. For example, two Media Servers can register with a SIP redirect server for thevalueannc user. If one ofprompt-url will havethefollowing form: prompt-url = "/provisioned/" announcement-id announcement-id = 1*(ALPHA | DIGIT) This document is strictly focused onMedia Servers fails, theSIP interfaceregistration will expire and all requests for the announcement serviceand as such does not detail how announcement sequences are provisoned or defined. 7.("calls to the annc user") get sent to the surviving Media Server. Burger, et. al. Expires 5/2/2003 22 Network Announcements with SIP November 2002 9. 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 a2xx result code. 8.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. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. INFORMATIVE 2Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP: Session Initiation Protocol", RFC 2543, March 1999. O'Connor, et. al. Expires 5/21/02 7 Network Announcements with SIP November 2001 3 Van Dyke, J. and Burger, E., "SIP URI Conventions for Media Servers", draft-ietf-sipping-msuri-01.txt, November 2001, work in progress. 4Bradner, 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 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 2002. INFORMATIVE 7 ISO 639, "Codes for the representation of names of languages", 1998.6NORMATIVE Burger, et. al. Expires 5/2/2003 23 Network Announcements with SIP November 2002 8 ISO 3166, "Codes for the representation of names of countries and their subdivisions", 1997.7 Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt, October 2001, work in progress. 8NORMATIVE 9 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.9NORMATIVE 10 Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1988.9.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 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 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 and variable parameters. o Added the ability to reference a provisioned announcement. o Made early media treatment the default behavior for the service. o 487 REQUEST TERMINATED replaces 486 BUSY HERE as the mediaserverĖsserverĘs final response when early media treatment is desired.10.Burger, et. al. Expires 5/2/2003 24 Network Announcements with SIP November 2002 12. Acknowledgments We would like to thank Kevin Summers and Ravindra Kabre of Sonus Networks for their constructivecomments. 11.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. 13. Author's AddressesWalter O'Connor SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone: 978/367-8411 Email: woconnor@snowshore.comEric BurgerO'Connor, et. al. Expires 5/21/02 8 Network Announcements with SIP November 2001 SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone: 978/367-8403 Email: eburger@snowshore.com(Editor) Andy Spitzer Jeff Van Dyke SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA Phone:+1 978/367-8405978/367-8400 Email: eburger@snowshore.com Email: woof@snowshore.com Email: jvandyke@snowshore.comO'Connor,Walter O'Connor Amherst, NH USA Email: woconnor@bit-net.com Burger, et. al. Expires5/21/02 95/2/2003 25 Network Announcements with SIP November20012002 Full Copyright Statement Copyright (C) The Internet Society(2001).(2001, 2002). 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. 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 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 for the RFC Editor function.O'Connor,SnowShore Networks, Inc. is a member of the Internet Society. Burger, et. al. Expires5/21/02 105/2/2003 26 ----