SIP Working Group                                           W. Marshall
Internet Draft                                                     AT&T
Document: <draft-ietf-sip-call-auth-04.txt>
Category: Informational                                 K. Ramakrishnan
                                                     TeraOptic Networks

                                                              E. Miller
                                                                Terayon

                                                             G. Russell
                                                              CableLabs

                                                               B. Beser
                                                       Juniper Networks

                                                            M. Mannette
                                                        K. Steinbrenner
                                                                   3Com

                                                                D. Oran
                                                           F. Andreasen
                                                                  Cisco

                                                             J. Pickens
                                                                  Com21

                                                            P. Lalwaney
                                                                  Nokia

                                                             J. Fellows
                                               Copper Mountain Networks

                                                               D. Evans
                                                 D. R. Evans Consulting

                                                               K. Kelly
                                                               NetSpeak

                                                         February, 2002


                   SIP Extensions for Media Authorization


Status of this Memo

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


   SIP Working Group      Informational - Expires 8/31/02               1

                SIP Extensions for Media Authorization   February 2002

   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.

. Abstract

   This document describes the need for QoS and media authorization and
   defines a SIP extension that can be used to integrate QoS admission
   control with call signaling and help guard against denial of service
   attacks. The use of this extension is only applicable in administrative
   domains, or among federations of administrative domains with previously
   agreed-upon policies, where both the SIP proxy authorizing the QoS, and
   the policy control of the underlying network providing the QoS belong to
   that administrative domain or federation of domains.

. Scope of Applicability

   This document defines a SIP extension that can be used to integrate QoS
   admission control with call signaling and help guard against denial of
   service attacks. The use of this extension is only applicable in
   administrative domains, or among federations of administrative domains
   with previously agreed-upon policies, where both the SIP proxy
   authorizing the QoS, and the policy control of the underlying network
   providing the QoS belong to that administrative domain or federation of
   domains. Furthermore, the mechanism is generally incompatible with end-
   to-end encryption of message bodies that describe media sessions.

   This is in contrast with general Internet principles which separate data
   transport from applications, and the solution described in this document
   is thus not applicable to the Internet at large. Despite these
   limitations, there are sufficiently useful specialized deployments that
   meet the assumptions described above, and can accept the limitations that
   result, to warrant publication of this mechanism.  An example deployment
   would be a closed network which emulates a traditional circuit switched
   telephone network.

. 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 [2].

. Background and Motivation

   Current IP telephony systems assume a perfect world in which there is
   either unlimited amount of bandwidth or network layer Quality of Service
   (QoS) is provided without any kind of policy control. However the reality
   is that end-to-end bandwidth is not unlimited and uncontrolled access to
   QoS in general is unlikely. The primary reason for this is that QoS

    SIP Working Group     Informational - Expires 8/31/02               2

                SIP Extensions for Media Authorization   February 2002

   provides preferential treatment of one flow at the expense of another.
   Consequently, it is important to have policy control over whether a given
   flow should have access to QoS. This will not only enable fairness in
   general, but can also prevent denial of service attacks.

   In this document, we are concerned with providing QoS for media streams
   established via the Session Initiation Protocol (SIP) [3]. We assume an
   architecture that integrates call signaling with media authorization as
   illustrated in the Figure below. The solid lines (A and B) show
   interfaces whereas the dotted line (C) illustrates the QoS enabled media
   flow:


                               +---------+
                               |  Proxy  |
                    +--------->|         |
                    |          +---------+
                    |               ^
                  A)|            B) |
                    |              { }
                    |               |
                    |               v
                    v           +------+
                +------+   C)   | Edge |
                |  UA  |........|router|......
                +------+        +------+


                         Figure 1 - Basic Architecture


   In this architecture, we assume an untrusted SIP UA connected to a QoS
   enabled network with an edge router acting as a Policy Enforcement Point
   (PEP) [4]. We furthermore assume that a SIP UA, that wishes to obtain
   QoS, initiates sessions through a proxy which can interface with the QoS
   policy control for the data network being used. We will refer to such a
   proxy as a QoS enabled proxy. We assume that the SIP UA needs to present
   an authorization token to the network in order to obtain Quality of
   Service (C). The SIP UA obtains this authorization token via SIP (A) from
   the QoS enabled proxy by means of an extension SIP header defined in this
   document. The proxy in turn communicates either directly with the edge
   router or with a Policy Decision Point (PDP - not shown) [4] in order to
   obtain a suitable authorization token for the UA.

   Examples of access data networks where such a QoS enabled proxy could be
   used include DOCSIS based cable networks and 3rd generation (3G) wireless
   networks.

. Overview

   A session, that needs to obtain QoS for the media streams in accordance
   with our basic architecture described above is performed as follows.



    SIP Working Group     Informational - Expires 8/31/02               3

                SIP Extensions for Media Authorization   February 2002

   The SIP UA sends an INVITE to the QoS enabled proxy which for each
   resulting dialog includes a media authorization token in all unreliable
   provisional responses (except 100), the first reliable 1xx or 2xx
   response, and all retransmissions of that reliable response for the
   dialog. When the UA requests QoS, it includes the media authorization
   token with the resource reservation.

   A SIP UA may also receive an INVITE from its QoS enabled proxy which
   includes a media authorization token. In that case, when the UA requests
   QoS, it includes the media authorization token with the resource
   reservation.

. Changes to SIP to Support Media Authorization

   This document defines a private SIP header extension to support a media
   authorization scheme. In this architecture a QoS enabled SIP proxy
   supplies the UA with an authorization token which is to be used in QoS
   requests. The extension defined allows network QoS resources to be
   authorized by the QoS enabled SIP proxy.

6.1 SIP Header Extension

   A new P-Media-Authorization general header field is defined. The Media-
   Auth header field contains a media authorization token which is to be
   included in subsequent resource reservations for the media flows
   associated with the session. The media authorization token is used for
   authorizing QoS for the media stream(s). The P-Media-Authorization header
   field is described by the following ABNF [5]:

        P-Media-Authorization           = "P-Media-Authorization" ":"
                                                P-Media-Authorization-Token

        P-Media-Authorization-Token     = 1*HEXDIG


   Table 1 below is an extension of tables 2 and 3 in [5] for the new header
   field defined here:

                            Where  proxy  ACK  BYE  CAN  INV  OPT  REG
    P-Media-Authorization            ad    -    -    -    o    -    -

                      Table 1: Summary of header fields.

   The P-Media-Authorization header field can be used with the INVITE method
   as well as any response to it.

6.2 SIP Procedures

   This section defines the SIP [3] procedures for usage in media
   authorization compatible systems from the point of view of authorizing
   QoS.




    SIP Working Group     Informational - Expires 8/31/02               4

                SIP Extensions for Media Authorization   February 2002

6.2.1. User Agent Client (UAC)

   The initial SIP INVITE message, mid-call messages that result in network
   QoS resource changes, and mid-call changes in call destination should be
   authorized. These SIP messages are sent through the QoS enabled proxies
   to receive this authorization. In order to authorize QoS, the QoS enabled
   SIP proxy MAY need to inspect message bodies that describe the media
   streams, e.g. SDP, and hence such message bodies SHOULD NOT be encrypted
   end-to-end.

   The P-Media-Authorization-Token, which is contained in the P-Media-
   Authorization header, is included for each dialog in all unreliable
   provisional responses (except 100), the first reliable 1xx or 2xx
   response, and all retransmissions of that reliable response for the
   dialog sent by the QoS enabled SIP proxy to the UAC.

   The UAC SHOULD use all the P-Media-Authorization-Token(s) from the most
   recent request/response that contained the P-Media-Authorization header
   when requesting QoS for the associated media stream(s). This applies both
   to the initial and subsequent refresh reservation messages. The UAC
   converts the string of hex digits into binary, and utilizes the result as
   a Policy-Element as defined in RFC 2750 [6] (including Length and P-
   Type). This Policy-Element would typically contain the authorizing entity
   and credentials, and be used in an RSVP request for media data stream QoS
   resources.

6.2.2. User Agent Server (UAS)

   The User Agent Server receives the P-Media-Authorization-Token in an
   INVITE (or other) message from the QoS enabled SIP proxy. If the response
   contains a message body that describes media streams for which the UA
   desires QoS, said message body SHOULD NOT be end-to-end encrypted.

   The UAS SHOULD use all the P-Media-Authorization-Token(s) from the most
   recent request/response that contained the P-Media-Authorization header
   when requesting QoS for the associated media stream(s). This applies both
   to the initial and subsequent refresh reservation messages. The UAS
   converts the string of hex digits into binary, and utilizes the result as
   a Policy-Element as defined in RFC 2750 [6] (including Length and P-
   Type). This Policy-Element would typically contain the authorizing entity
   and credentials, and be used in an RSVP request for media data stream
   resources.

6.2.3. Originating Proxy (OP)

   When the originating QoS enabled proxy (OP) receives an INVITE (or other)
   message from the UAC, the proxy authenticates the caller, and verifies
   that the caller is authorized to receive QoS.

   In cooperation with an originating Policy Decision Point (PDP-o), the OP
   obtains and/or generates a media authorization token that contains
   sufficient information for the UAC to get the authorized QoS for the
   media streams. The media authorization token is formatted as a Policy-
   Element, as defined in RFC 2750 [6], and then converted to a string of

    SIP Working Group     Informational - Expires 8/31/02               5

                SIP Extensions for Media Authorization   February 2002

   hex digits to form a P-Media-Authorization-Token. The proxy MAY inspect
   message bodies that describe the media streams, e.g. SDP, in both
   requests and responses in order to decide what QoS to authorize.

   For each dialog that results from the INVITE (or other) message received
   from the UAC, the originating proxy MUST add a P-Media-Authorization
   header with the P-Media-Authorization-Token in all unreliable provisional
   responses (except 100), the first reliable 1xx or 2xx response, and all
   retransmissions of that reliable response the proxy sends to the UAC, if
   that response may result in network QoS changes. A response with an SDP
   may result in such changes.

6.2.4. Destination Proxy (DP)

   The Destination QoS Enabled Proxy (DP) verifies that the called party is
   authorized to receive QoS.

   In cooperation with a terminating Policy Decision Point (PDP-t), the DP
   obtains and/or generates a media authorization token that contains
   sufficient information for the UAS to get the authorized QoS for the
   media streams.  The media authorization token is formatted as a Policy-
   Element, as defined in RFC 2750 [6], and then converted to a string of
   hex digits to form a P-Media-Authorization-Token. The proxy MAY inspect
   message bodies that describe the media streams, e.g. SDP, in both
   requests and responses in order to decide what QoS to authorize.

   The Destination Proxy MUST add the P-Media-Authorization header with the
   P-Media-Authorization-Token in the INVITE (or other) request that it
   sends to the UAS, if that message may result in network QoS changes. A
   message with an SDP body may result in such changes.

. Examples

7.1. Requesting Bandwidth via RSVP messaging

   Below we provide an example for how the P-Media-Authorization header
   field can be used in conjunction with the Resource Reservation Protocol
   (RSVP) [7]. The example assumes that resource management is integrated
   with SIP signaling and therefore utilizes the 183 Session Progress
   provisional response, which contains an SDP description of the media
   flow.

7.1.1. User Agent Client Side

   Figure 2 presents a high-level overview of a basic call flow with media
   authorization from the viewpoint of the UAC. Some policy interactions
   have been omitted for brevity.

   When a user goes off-hook and dials a telephone number, the UAC collects
   the dialed digits and sends the initial (1)INVITE message to the
   originating SIP proxy.

   The originating SIP proxy (OP) authenticates the user/UAC and forwards
   the (2)INVITE message to the proper SIP proxy.

    SIP Working Group     Informational - Expires 8/31/02               6

                SIP Extensions for Media Authorization   February 2002


   Assuming the call is not forwarded, the terminating end-point sends a
   (3)183 response to the initial INVITE via OP. Included in this response
   is an indication of the negotiated bandwidth requirement for the
   connection (in the form of an SDP description [8]).

   When OP receives the (3)183, it has sufficient information regarding the
   end-points, bandwidth and characteristics of the media exchange. It
   initiates a Policy-Setup message to PDP-o, (4)AuthProfile.

   The PDP-o stores the authorized media description in its local store,
   generates an authorization token that points to this description, and
   returns the authorization token to the OP, (5)AuthToken.

   UAC         ER-o            PDP-o           OP
   |(1)Invite   |               |               | Client Authentication
   |------------------------------------------->| and Call Authorization
   |            |               |               | (2)Invite
   |            |               |               |-------------->
   |            |               |               | (3)180/3
   |            |               |(4)AuthProfile |<--------------
   |            |               |<--------------|
   |            |               |(5)AuthToken   |
   |            |               |-------------->| Auth. Token put into
   |            |               |(6)180/3       | P-Media-Authorization
   |<-------------------------------------------| header extension.
   |Copies the RSVP policy object               |
   |from the P-Media-Authorization              |
   |(7)RSVP-PATH                |               |
   |----------->| (8)REQ        |               |
   |            |-------------->| Using the Auth-Token and Authorized
   |            |       (9)DEC  | Profile that is set by the SIP Proxy
   |            |<--------------| the PDP makes the decision
   |            |               |               |(10)RSVP-PATH
   |            |------------------------------------------------>
   |            |               |               |(11)RSVP-PATH
   |<--------------------------------------------------------------
   |Copies the RSVP policy object               |
   |from the P-Media-Authorization              |
   |(12)RSVP-RESV               |               |
   |----------->|   (13)REQ     |               |
   |            |-------------->| Using the Auth-Token and Authorized
   |            |   (14)DEC     | Profile that is set by the SIP Proxy
   |            |<--------------| the PDP makes the decision
   |            |               |               |(15)RSVP-RESV
   |            |--------------------------------------------------->
   |            |               |               |(16)RSVP-RESV
   |<----------------------------------------------------------------
   |            |               |               |

               Figure 2 - Media Authorization with RSVP (UAC)




    SIP Working Group     Informational - Expires 8/31/02               7

                SIP Extensions for Media Authorization   February 2002

   The OP includes the authorization token in the P-Media-Authorization
   header extension of the (6)183 message.

   Upon receipt of the (6)183 message, the UAC stores the media
   authorization token from the P-Media-Authorization header.

   Before sending any media, the UAC requests QoS by sending an (7)RSVP-PATH
   message which includes the previously stored P-Media-Authorization-Token
   as a Policy-Element.

   ER-o, upon reception of the (7)RSVP-PATH message checks the authorization
   through a PDP-o COPS message exchange, (8)REQ. PDP-o checks the
   authorization using the stored authorized media description that was
   linked to the authorization token it returned to OP. If authorization is
   successful, PDP-o returns an "install" Decision, (9)DEC.

   ER-o checks the admissibility for the request and if admission succeeds,
   it forwards the (10)RSVP-PATH message.

   Once UAC receives the (11)RSVP-PATH message from UAS it sends the
   (12)RSVP-RESV message to reserve the network resources.

   ER-o, upon receiving the (12)RSVP-RESV message checks the authorization
   through a PDP-o COPS message exchange, (13)REQ. PDP-o checks the
   authorization using the stored authorized media description that was
   linked to the authorization token it returned to OP. If authorization is
   successful PDP-o returns an "install" Decision, (14)DEC.

   ER-o checks the admissibility for the request and if admission succeeds,
   it forwards the (15)RSVP-RESV message.

   Upon receiving the (16)RSVP-RESV message, network resources have been
   reserved in both directions.

7.1.2. User Agent Server Side

   Figure 3 presents a high-level overview of a call flow with media
   authorization from the viewpoint of the UAS. Some policy interactions
   have been omitted for brevity.

   Since the destination SIP proxy (DP) has sufficient information regarding
   the endpoints, bandwidth and characteristics of the media exchange, it
   initiates a Policy-Setup message to the terminating Policy Decision Point
   (PDP-t) on receipt of the (1)INVITE.











    SIP Working Group     Informational - Expires 8/31/02               8

                SIP Extensions for Media Authorization   February 2002

   UAS         ER-t           PDP-t            DP
    |           |               |               | (1)Invite
    |           |               |               |<--------------
    |           |               |               | Proxy Authentication
    |           |               | (2)AuthProfile| and Call Authorization
    |           |               |<--------------|
    |           |               |  (3)AuthToken |
    |           |               |-------------->| Auth. Token put into
    |           |               |  (4)Invite    | P-Media-Authorization
    |<------------------------------------------| header extension
    |  (5)180/3 |               |               |
    |------------------------------------------>| (6)180/3
    |Copies the RSVP policy object              |-------------->
    |from the P-Media-Authorization             |
    |(7)RSVP-PATH               |               |
    |---------->| (8)REQ        |               |
    |           |-------------->| Using the Auth-Token and Authorized
    |           |       (9)DEC  | Profile that is set by the SIP Proxy
    |           |<--------------| the PDP makes the decision
    |           |               |               |(10)RSVP-PATH
    |           |-------------------------------------------------->
    |           |               |               |(11)RSVP-PATH
    |<--------------------------------------------------------------
    |Copies the RSVP policy object              |
    |from the P-Media-Authorization             |
    | (12)RSVP-RESV             |               |
    |---------->|               |               |
    |           | (13)REQ       |               |
    |           |-------------->| Using the Auth-Token and Authorized
    |           |       (14)DEC | Profile that is set by the SIP Proxy
    |           |<--------------| the PDP makes the decision
    |           |               |               |(15)RSVP-RESV
    |           |--------------------------------------------------->
    |           |               |               |(16)RSVP-RESV
    |<---------------------------------------------------------------
    |           |               |               |

                Figure 3 - Media Authorization with RSVP (UAS)


   PDP-t stores the authorized media description in its local store,
   generates an authorization token that points to this description, and
   returns the authorization token to DP. The token is placed in the
   (4)INVITE message and forwarded to the UAS.

   Assuming that the call is not forwarded, the UAS sends a (5)183 response
   to the initial INVITE message, which is forwarded back to UAC. At the
   same time, the UAS sends an (7)RSVP-PATH message which includes the
   previously stored P-Media-Authorization-Token as a Policy-Element.

   ER-t, upon receiving the (7)RSVP-PATH message checks the authorization
   through a PDP-t COPS message exchange. PDP-t checks the authorization
   using the stored authorized media description that was linked to the


    SIP Working Group     Informational - Expires 8/31/02               9

                SIP Extensions for Media Authorization   February 2002

   authorization token it returned to DP. If authorization is successful
   PDP-t returns an "install" Decision, (9)DEC.

   ER-t checks the admissibility for the call and if admission succeeds, it
   forwards the (10)RSVP-PATH message.

   Once the UAS receives the (11)RSVP-PATH message, it sends (12)RSVP-RESV
   message to reserve the network resources.

   ER-t, upon reception of the (12)RSVP-RESV message, checks the
   authorization through a PDP-t COPS message exchange. PDP-t checks the
   authorization using the stored authorized media description that was
   linked to the authorization token that it returned to DP. If
   authorization is successful PDP-t returns an "install" Decision, (14)DEC.

   ER-t checks the admissibility for the call and if admission succeeds, it
   forwards the (15)RSVP-RESV message.

   Upon receiving the (16)RSVP-RESV message, network resources have been
   reserved in both directions.

. Advantages of the Proposed Approach

   The use of media authorization makes it possible to control the usage of
   network resources. This in turn makes IP Telephony more robust against
   denial of service attacks and various kinds of service frauds. By using
   the authorization capability, the number of flows, and the amount of
   network resources reserved can be controlled thereby making the IP
   Telephony system dependable in the presence of scarce resources.

. Security Considerations

   Media authorization tokens sent in the P-Media-Authorization header from
   a QoS enabled proxy to a UA MUST be protected from eavesdropping and
   tampering. This can for example be done through a mechanism such as IPSec
   or TLS. However, this will only provide hop-by-hop security. If there is
   one or more intermediaries, e.g. proxies, between the UA and the QoS
   enabled proxy, these intermediaries will have access to the P-Media-
   Authorization header field value thereby compromising confidentiality and
   integrity. This will enable both theft-of-service and denial-of-service
   attacks against the UA. Consequently, the P-Media-Authorization header
   field MUST NOT be available to any untrusted intermediary in clear or
   without integrity protection. There is currently no mechanism defined in
   SIP that would satisfy these requirements. Until such a mechanism
   exists, proxies MUST NOT send P-Media-Authorization headers through
   untrusted intermediaries.

   QoS enabled proxies may need to inspect message bodies describing media
   streams, e.g. SDP. Consequently, such message bodies SHOULD NOT be
   encrypted. This will in turn prevent end-to-end confidentiality of said
   message bodies which lowers the overall security possible.




    SIP Working Group     Informational - Expires 8/31/02               10

                SIP Extensions for Media Authorization   February 2002

. IANA Considerations

   This document defines a new private SIP header for media authorization
   which is "P-Media-Authorization".

. Notice Regarding Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this document.
   For more information consult the online list of claimed rights.

. References

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

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

   3  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson,
      J., Sparks, R., Handley, M., E. Schooler, "SIP: Session Initiation
      Protocol", Work in Progress, February 21, 2002.

   4  Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-
      based Admission Control", RFC 2753, January 2000.

   5  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon
      Internet Ltd., November 1997.

   6  Herzog, S., RSVP Extensions for Policy Control, RFC 2750, January
      2000.

   7  Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC
      2210, September 1997.

   8  Handley, M., Jacobson, V., "SDP: Session Description Protocol", RFC
      2327, April, 1998.

. Acknowledgments

   The Distributed Call Signaling work in the PacketCable project is
   the work of a large number of people, representing many different
   companies.  The authors would like to recognize and thank the
   following for their assistance: John Wheeler, Motorola; David
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,
   Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin,
   Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks;
   Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho,
   Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-
   Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent
   Cable Communications. Dean Willis provided valuable feedback as
   well.


    SIP Working Group     Informational - Expires 8/31/02               11

                SIP Extensions for Media Authorization   February 2002


. Authors' Addresses

   Bill Marshall
   AT&T
   Florham Park, NJ  07932
   Email: wtm@research.att.com

   K. K. Ramakrishnan
   TeraOptic Networks
   Summit, NJ  07901
   Email: kk@teraoptic.com

   Ed Miller
   Terayon
   Louisville, CO  80027
   Email: edward.miller@terayon.com

   Glenn Russell
   CableLabs
   Louisville, CO  80027
   Email: G.Russell@Cablelabs.com

   Burcak Beser
   Juniper Networks
   Sunnyvale, CA
   Email: burcak@juniper.net

   Mike Mannette
   3Com
   Rolling Meadows, IL  60008
   Email: Michael_Mannette@3com.com

   Kurt Steinbrenner
   3Com
   Rolling Meadows, IL  60008
   Email: Kurt_Steinbrenner@3com.com

   Dave Oran
   Cisco
   Acton, MA  01720
   Email: oran@cisco.com

   Flemming Andreasen
   Cisco
   Edison, NJ
   Email: fandreas@cisco.com

   John Pickens
   Com21
   San Jose, CA
   Email: jpickens@com21.com


    SIP Working Group      Informational - Expires 8/31/02          12


                SIP Extensions for Media Authorization   February 2002


   Poornima Lalwaney
   Nokia
   San Diego, CA  92121
   Email: poornima.lalwaney@nokia.com

   Jon Fellows
   Copper Mountain Networks
   San Diego, CA  92121
   Email: jfellows@coppermountain.com

   Doc Evans
   D. R. Evans Consulting
   Boulder, CO  80303
   Email: n7dr@arrl.net

   Keith Kelly
   NetSpeak
   Boca Raton, FL  33587
   Email: keith@netspeak.com


































    SIP Working Group      Informational - Expires 8/31/02          13


                SIP Extensions for Media Authorization   February 2002



Full Copyright Statement

   "Copyright (C) The Internet Society (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."





























    SIP Working Group      Informational - Expires 8/31/02          14