[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                    Ping Pan (Columbia U)
INTERNET DRAFT                          Henning Schulzrinne (Columbia U)
                                                       Pat Calhoun (Sun)
                                                            31 July 1998




           DIAMETER: Policy and Accounting Extension for SIP
                     draft-pan-diameter-sip-00.txt




Status of This Memo

   This document is an Internet-Draft.  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 not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the internet-drafts
   Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   This document describes a policy and accounting information exchange
   mechanism between a DIAMETER policy server and a SIP proxy server.
   A DIAMETER server is responsible for maintaining a user policy and
   accounting database and a means to update it.  A SIP proxy server
   needs to be able to contact a DIAMETER server during multimedia
   session setup and tear-down time to perform admission control and
   accounting tasks.

   To provide proper service guarantees to the sessions that are
   established with SIP, DIAMETER servers are also responsible for
   providing an interface to the network resource management database.
   However, this is beyond the scope of this document.






Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page i]


Internet Draft                 DIAMETER-SIP                 31 July 1998


   The objective of the mechanism is 1) accuracy, 2) flexibility, and 3)
   simplicity.  The protocol does not make any assumptions about policy
   algorithms at DIAMETER servers and implementation details at SIP
   servers.















































Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page ii]


Internet Draft                 DIAMETER-SIP                 31 July 1998




                                Contents



Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        3

 3. Description of Operation                                           3
     3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . .    3
     3.2. Initialization Operation  . . . . . . . . . . . . . . . .    4
     3.3. Caller Detailed Operation . . . . . . . . . . . . . . . .    4
     3.4. Callee Detailed Operation . . . . . . . . . . . . . . . .    5
     3.5. Server Considerations . . . . . . . . . . . . . . . . . .    5

 4. AVP Formats                                                        5
     4.1. Device-Reboot-Indication AVP extension  . . . . . . . . .    6
     4.2. DIAMETER-Command AVP extension  . . . . . . . . . . . . .    7
     4.3. DIAMETER Error-Code AVP extension . . . . . . . . . . . .    7
     4.4. SIP Specific AVP's  . . . . . . . . . . . . . . . . . . .    7
           4.4.1. SIP-Sequence AVP  . . . . . . . . . . . . . . . .    8
           4.4.2. SIP-Call-ID AVP . . . . . . . . . . . . . . . . .    9
           4.4.3. SIP-To AVP  . . . . . . . . . . . . . . . . . . .   10
           4.4.4. SIP-From AVP  . . . . . . . . . . . . . . . . . .   11
           4.4.5. SIP-Entire-Msg AVP  . . . . . . . . . . . . . . .   11

 5. Command Format                                                    12
     5.1. SIP Admission Control Commands  . . . . . . . . . . . . .   12
     5.2. SIP Accounting Commands . . . . . . . . . . . . . . . . .   13
     5.3. SIP Termination Commands  . . . . . . . . . . . . . . . .   14















Calhoun, Schulzrinne, Pan      Expires 31 December 1998       [Page iii]


Internet Draft                 DIAMETER-SIP                 31 July 1998


1. Introduction

   DIAMETER [ZPC98] is a proposed successor to RADIUS [RRSW97].
   It defines a base protocol [RC98] for policy information to be
   exchanged among policy-enable entities.  It is designed as a common
   platform for several Internet services, such as AAA (Authentication,
   Authorization i and Accounting), network-edge resource management and
   VPN (Virtual Private Network).

   SIP [HSS98] (Session Initiation Protocol) is designed to allow
   network users to establish and control multimedia sessions over the
   Internet.  A SIP session can be an IP telephone call.  However, user
   accounting, policy and billing systems are beyond scope of SIP, and
   must be in place in order to provide telephony service in commercial
   networks.

   This document describes a policy/accounting mechanism that can
   interface between SIP proxy servers and policy servers to provide
   admission control and to update and maintain user data for accounting
   purposes.  Figure-1 illustrates the proposed model.


                                 +------------+
                                 |   Policy   |
                                 |   Server   |
                                 +------------+
                                       /|\
                                        |
                                        |    DIAMETER messages
                                        |
                                       \|/
                               +-----------------+
                               | Diameter Client |
  +--------+  SIP messages     |                 |     SIP Messages
  |   SIP  | ================> |   (SIP Proxy)   | ====================>
  | client |                   |                 |
  +--------+                   |                 |
                               +-----------------+

                     Figure-1: A model for SIP/DIAMETER interface.



   The proposal is designed based on the following assumptions:

    1. A policy server is the central decision entity.  The clients
       (that is, SIP proxy servers) should always forward the
       information to the server.  However this does not preclude



Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 1]


Internet Draft                 DIAMETER-SIP                 31 July 1998


       a client from maintaining a policy information cache for
       performance optimization purposes.

    2. A policy server maintains a policy and accounting database for
       all users within an administrative domain, and a means to update
       it.

    3. The extension relies on the base protocol to provide massaging
       reliability.  A DIAMETER server and a DIAMETER client, therefore,
       have no need to implement other reliable message delivery
       mechanisms.

   SIP is a out-band signaling protocol, and the actual voice data may
   use a different route than the path that SIP messages traverse.
   For IP telephony, voice data is transmitted in the form of RTP
   [SCFJ96].  To ensure voice data being delivered properly, users can
   make the use of end-to-end resource reservation protocols to set up
   reserved "flows".  Another alternative is to mark the packet header
   as "premium service" [ZJN97] so that they can be delivered with low
   delay and rate guarantees inside the network.  Both approaches imply
   that the network-edge routers may need to interface with policy
   servers to manage link resources.  However, the detailed mapping and
   management between IP telephone sessions and link resource management
   requires further investigation, and are beyond the scope of this
   document at this point.

   In addition, the proposed extension does not perform policy and
   accounting processing itself.  It is therefore important to remember:

    1. The protocol does NOT make any assumptions about the algorithm
       of the policy server, but is based on the server returning a
       "decision" in response to a policy request.

    2. The protocol does NOT make any assumptions about the
       implementation details of the SIP proxy server.  However, when
       a policy event takes place, a SIP proxy must send all relevant
       information to a server for policy evaluation.

    3. The communication mechanism among policy servers is NOT in the
       scope of this document.

    4. To provide IP telephone service, it may require some level
       interaction between the policy server at the caller-side and
       the one at the callee-side.  However, such interaction requires
       further investigation and is not included in this document.






Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 2]


Internet Draft                 DIAMETER-SIP                 31 July 1998


2. Terminology

    -  Caller:  The device that initiating a session invitation.
       Through out the draft, we assume a caller is a SIP proxy server
       that sets up sessions for telephone users at a source network.

    -  Callee:  The device that a caller is trying to invite to a
       session.  We assume a callee is a SIP proxy server that manage
       sessions for telephone users at a remote network.

    -  Policy Server:  A host or router that stores policy rules, and is
       capable to communicate with its clients via DIAMETER protocol.

    -  Client:  A SIP proxy server that interface with a "trusted"
       policy server to perform policy and accounting checking, and some
       level of admission control.  A client is a SIP caller, or a SIP
       callee, or both.

    -  Policy Event:  The event that takes place at a client and
       requires policy checking.  Such event could be the reception of a
       SIP INVITE, ACK, CANCEL, or BYE message.

    -  Policy Event Message:  The message that triggers a policy event
       at a client.

    -  AVP: The DIAMETER protocol consists of a header followed by
       objects.  Each object is encapsulated in a header known as an
       Attribute-Value-Pair.


3. Description of Operation

3.1. Outline

   DIAMETER client (in this case, SIP Proxy Server) and policy server
   exchange DIAMETER messages to open and confirm a client-server
   connection at boot-up time.  The initial data between a policy server
   and a client are device availability, client/server identification
   and the level of supported features.  The information is encoded in
   standard DIAMETER Device-Reboot-Indication and Host-IP-Address AVP's.

   Both client and policy servers must support DIAMETER SIP extension.
   In case a client going down, the server must download known client
   configuration to the client after reboot.

   A client queries its policy server when a SIP policy event occurs.  A
   policy event could be due to the arrival of a SIP INVITE, ACK, CANCEL




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 3]


Internet Draft                 DIAMETER-SIP                 31 July 1998


   or BYE message.  SIP OPTION and REGISTER messages will not trigger
   policy events.

   When the server receives a query, it performs policy checking,
   admission control and accounting.  If the server needs to inform
   the results of the policy checking to a client, it can send a reply
   message to the client.

   A client, by default, has one primary and several alternative
   servers.  In case of primary server failure, the client can try to
   open a new DIAMETER connection with one of its alternative servers.
   After the new connection is established, the client must notify the
   server of all its pending policy requests.

   A policy server can asynchronously download policy decisions to a
   client.  In turn, the policy decisions may trigger SIP messages to be
   generated at the client to re-direct or cease existing sessions.

   Optionally, a client can cache all or a part of the policy decisions
   locally.  In this case, a server must asynchronously download the
   decision information to the client.  However, the server must be
   responsible for updating any decision change to the client.


3.2. Initialization Operation

   At the boot-up time, servers and clients inform each other about
   the features that need to be supported.  As a part of the feature
   discovery process, the DIAMETER Device-Reboot-Indication AVP must
   contain the feature number that has been assigned to the SIP/DIAMETER
   extension.  For a client that has multiple servers, it must exchange
   feature information with all its servers at initialization time.


3.3. Caller Detailed Operation

   When a caller (a SIP proxy server) is being notified to set up a call
   for a user, it first initiates a DIAMETER request command to its
   policy server with all the information about the user.  The server,
   in turn, checks the request against the admission control policy
   database, and returns the findings in a DIAMETER response message.
   If the response is OK, the caller will sends a SIP INVITE message to
   the callee.

   If the callee accepts the call, it replies a SIP 200 (SUCCESS) signal
   to the caller.  Upon reception, the caller confirms the call by
   sending back a SIP ACK message.  At the same time, the call must also




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 4]


Internet Draft                 DIAMETER-SIP                 31 July 1998


   send a notification to the server to start the accounting process.
   The notification is in DIAMETER request message format.

   When a caller receives a call termination notification from the user,
   or a SIP BYE message from the callee, it informs the policy server to
   stop the accounting.

   When a caller sends a SIP CANCEL message to cancel a pending request,
   it must also inform the policy server.


3.4. Callee Detailed Operation

   After a callee receives a INVITE message, it initiates a SIP request
   command to the server for policy checking.  If the server replies a
   denial response, the callee will reject the session invitation by
   sending a SIP 4XX (Error) signal to the caller.  The original INIVITE
   message MUST be dropped at the callee.  If the server permits the
   invitation, the callee needs to relay the INIVITE message to the
   destination user, or (as a proxy) to directly reply a SIP 200 signal
   to the caller.

   A SIP caller always sends a SIP ACK message to the callee to confirm
   the establishment of a session.  When an ACK message being received,
   the callee MUST send a SIP request message to the policy server to
   start the accounting process.

   When the callee decides to terminate the call, or a BYE message is
   sent by the caller, the callee MUST send a SIP request message to the
   server to stop the accounting process.

   After the callee receives a SIP CANCEL, it needs to inform the policy
   server to remove the pending requests.


3.5. Server Considerations

   DIAMETER/SIP policy servers may or may not support SIP protocol.  As
   a result, clients have the option to either 1) send the entire SIP
   message to the servers, or 2) parse the SIP message first and send
   pre-defined SIP AVP's to the servers.


4. AVP Formats

   Each DIAMETER message consists of multiple AVP's, that are 32-bit
   aligned, with the following format:




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 5]


Internet Draft                 DIAMETER-SIP                 31 July 1998



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                       (AVP contents)                         //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      Identifies the AVP; values of this field are defined below.

   AVP Length

      A 16-bit field containing the total object length in bytes.
      Must always be a multiple of 4, and at least 8.

   AVP Flags

      0x01:                  Mandatory-Support
      0x02:                  SS-Encrypted-Data
      0x03:                  PK-Encrypted-Data
      0x04:                  Vendor-Specific-AVP



   Readers can refer [RC98] for detailed DIAMETER base protocol
   information.


4.1. Device-Reboot-Indication AVP extension

   Clients and servers send the Device-Reboot-Indication messages at
   initialization or reboot time.  The message originator must include
   all supported extensions within the message.  The responder must
   include all supported extensions as long as they were present within
   the request message.

   The DIAMETER SIP extension uses Extension Id 6.

   The Extension Id may also be used in Device-Feature-Request,
   Device-Feature-Response and Extension-Id AVP's.




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 6]


Internet Draft                 DIAMETER-SIP                 31 July 1998


4.2. DIAMETER-Command AVP extension

   The Command AVP must be the first AVP following the DIAMETER
   header.  There must only be one Command AVP per message.  The command
   information is in the AVP's Command Code field.  The message format
   can be found in [RC98].

   This document defines the following DIAMETER Command Codes.  All
   DIAMETER implementations supporting this extension MUST support all
   of the following:


      Command Name                 Command Code
      --------------------------------------------
      SIP-Admission-Request           600
      SIP-Admission-Response          601
      SIP-Accounting-Request          602
      SIP-Accounting-Response         603
      SIP-Termination-Request         604
      SIP-Termination-Response        605




4.3. DIAMETER Error-Code AVP extension

   The Error-Code AVP contains the explicit message error code.  Note:
   the Error-Code AVP must be coupled with the Result-Code AVP which
   consists of DIAMETER_SEE_ERROR_CODE information.

   The extension defines the following additional error code for SIP
   operation:


      0x6001:               Missing Call-ID in the request
      0x6002:               Missing To in the request message
      0x6003:               Missing From in the request message

      0x6010:               Prohibited Caller
      0x6011:               Prohibited Callee




4.4. SIP Specific AVP's

   This section defines the extension specific AVP's.




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 7]


Internet Draft                 DIAMETER-SIP                 31 July 1998


   The following are the mandatory AVP's which must be recognized by all
   DIAMETER implementations supporting this extension.


      Attribute Name          AVP Code
      -----------------------------------
      SIP-Sequence              600
      SIP-Call-ID               601
      SIP-To                    602
      SIP-From                  603



   The following is an optional AVP.


      Attribute Name          AVP Code
      -----------------------------------
      SIP-Entire-Msg            604




4.4.1. SIP-Sequence AVP

   Each SIP-Request or SIP-Response MUST accompany with a sequence
   number.  When a DIAMETER device receives a request, it checks the
   received sequence number against the sequence number in the last
   transmitted SIP-Request of the same SIP session.  If they are not
   equal, the response is ignored.

   The AVP may be replaced by a DIAMETER global sequence number AVP in
   the future.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 8]


Internet Draft                 DIAMETER-SIP                 31 July 1998


      SIP-Sequence:  600

   AVP Length:

      The length of this attribute MUST be 12.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   Sequence Number:

     A number between 0xff to 0xffffffff




4.4.2. SIP-Call-ID AVP

   SIP uses Call-ID to identify a particular call session between two
   users.  DIAMETER servers can use Call-ID's to keep track of all
   on-going calls for billing and accounting purposes.  The SIP-Call-ID
   AVP has the following format:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                      SIP Call-ID                             //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      SIP-Call-ID:  601

   AVP Length:

      The length of this attribute depends on the size of SIP Call-ID.

   AVP Flags




Calhoun, Schulzrinne, Pan       Expires 31 December 1998        [Page 9]


Internet Draft                 DIAMETER-SIP                 31 July 1998


      The AVP Flags field MUST have bit one (Mandatory Support) set.

   SIP Call-ID:

     A copy of the original SIP Call-ID data.




4.4.3. SIP-To AVP

   This identifies the invited user of the session.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                      SIP TO URL                              //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      SIP-TO-ID:  602

   AVP Length:

      The length of this attribute depends on the size of SIP TO URL.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   SIP Call-ID:

     A copy of the original SIP URL for the invited user.









Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 10]


Internet Draft                 DIAMETER-SIP                 31 July 1998


4.4.4. SIP-From AVP

   This AVP identifies the invitation initiator ID in SIP URL format.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                    SIP FROM URL                              //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      SIP-FROM-ID:  603

   AVP Length:

      The length of this attribute depends on the size of SIP FROM URL.

   AVP Flags

      The AVP Flags field MUST have bit one (Mandatory Support) set.

   SIP Call-ID:

     A copy of the invitation initiator's SIP URL.




4.4.5. SIP-Entire-Msg AVP

   The AVP encapsulates an entire SIP message.  In order to ease the
   processing overhead at clients, and to provide adequate information,
   a SIP request message may send the entire SIP message to the server
   for parsing and processing.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 11]


Internet Draft                 DIAMETER-SIP                 31 July 1998


       |                           AVP Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          AVP Length           |  AVP Flags  |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                      SIP Message                              //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Code

      SIP-Entire-Msg:  604

   AVP Length:

      The length of this attribute depends on the size of SIP message.

   AVP Flags

      The AVP Flags field MUST not have bit one (Mandatory Support) set.

   SIP Message:

     A copy of the original SIP message.




5. Command Format

5.1. SIP Admission Control Commands

   During SIP call setup time, a SIP caller sends an admission control
   request to the DIAMETER server before sending a SIP INVITE message.
   At callee's side, it sends an admission control request to the
   DIAMETER server after receiving a SIP INVITE message.

   The format of the request message is the following:


<Admission Control Request> ::= <DIAMETER Header>
                                <Command AVP>
                                <Host-IP-Address>
                                <SIP-Sequence>
                                <SIP-Call-ID>
                                <SIP-To>
                                <SIP-From>



Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 12]


Internet Draft                 DIAMETER-SIP                 31 July 1998


                                [<SIP-Entire-Msg>]
                                <Timestamp AVP>
                                <Initialization-Vector AVP>
                                {<Integrity-Check-Vector AVP> ||
                                 <Digital-Signature AVP> }




   The Host-IP-Address AVP contains the client's IP address.

   The server bases on the request to conduct admission control for the
   session, and reply a response back to the client in the following
   format:


<Admission Control Response> ::= <DIAMETER Header>
                                <Command AVP>
                                <Host-IP-Address>
                                <Result-Code>
                                [<Error-Code>]
                                <SIP-Sequence>
                                <SIP-Call-ID>
                                [<SIP-To>]
                                [<SIP-From>]
                                <Timestamp AVP>
                                <Initialization-Vector AVP>
                                {<Integrity-Check-Vector AVP> ||
                                 <Digital-Signature AVP> }



   The Host-IP-Address AVP contains the server's identification.  If the
   server does not admit the call session, it must reply an Error-Code
   AVP to identify the rejection reason.  SIP client and server, by
   default, use SIP Call-ID to represent a call session.  However an
   implementation may use SIP To and From to manage call sessions in
   their database, so the response may need to consist of SIP-To and
   SIP-From AVP's.


5.2. SIP Accounting Commands

   After a SIP call session being established, the clients need to send
   an account request command to the servers to start up the accounting
   process.  The message format is:





Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 13]


Internet Draft                 DIAMETER-SIP                 31 July 1998


<Accounting Request> ::= <DIAMETER Header>
                         <Command AVP>
                         <Host-IP-Address>
                         <Timestamp>
                         <SIP-Sequence>
                         <SIP-Call-ID>
                         <SIP-To>
                         <SIP-From>
                         [<SIP-Entire-Msg>]
                         <Timestamp AVP>
                         <Initialization-Vector AVP>
                         {<Integrity-Check-Vector AVP> ||
                          <Digital-Signature AVP> }



   The Timestamp AVP contains the timing information at client.  Servers
   must base on this information to keep the duration of call sessions.

   The servers must reply an accounting response back to the clients.


<Accounting Response> ::= <DIAMETER Header>
                          <Command AVP>
                          <Host-IP-Address>
                          <SIP-Sequence>
                          <Result-Code>
                          [<Error-Code>]
                          <SIP-Call-ID>
                          [<SIP-To>]
                          [<SIP-From>]
                          <Timestamp AVP>
                          <Initialization-Vector AVP>
                          {<Integrity-Check-Vector AVP> ||
                           <Digital-Signature AVP> }




   If the server cannot process an accounting request, it must reply an
   Error-Code AVP to identify the error condition.


5.3. SIP Termination Commands

   A SIP Termination request may come from either client-side or
   server-side.  At a client, when it receives a hang-up signal from
   end users, or a SIP BYE message, or a SIP CANCEL message (for callee



Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 14]


Internet Draft                 DIAMETER-SIP                 31 July 1998


   only), it must inform the server to stop the accounting process.  Due
   to user policy, the server can send a termination request to the
   client to stop an on-going call.  In turn, the client must send a SIP
   BYE to the other party to cease a call.

   A termination request has the following format:


<Termination Request> ::= <DIAMETER Header>
                          <Command AVP>
                          <Host-IP-Address>
                          <SIP-Sequence>
                          <SIP-Call-ID>
                          <SIP-To>
                          <SIP-From>
                          <Timestamp AVP>
                          <Initialization-Vector AVP>
                          {<Integrity-Check-Vector AVP> ||
                           <Digital-Signature AVP> }



   When a DIAMETER receives a termination request, it must reply:


<Termination Response> ::= <DIAMETER Header>
                           <Command AVP>
                           <Host-IP-Address>
                           <Result-Code>
                           [<Error-Code>]
                           <SIP-Sequence>
                           <SIP-Call-ID>
                           [<SIP-To>]
                           [<SIP-From>]
                           <Timestamp AVP>
                           <Initialization-Vector AVP>
                           {<Integrity-Check-Vector AVP> ||
                            <Digital-Signature AVP> }




References

   [HSS98]  M. Handley, H. Schulzrinne, and E. Schooler.  SIP: session
            initiation protocol.  Internet Draft, Internet Engineering
            Task Force, May 1998.  Work in progress.




Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 15]


Internet Draft                 DIAMETER-SIP                 31 July 1998


   [RC98]   A. Rubens and P. Calhoun.  DIAMETER base protocol.  Internet
            Draft, Internet Engineering Task Force, July 1998.  Work in
            progress.

   [RRSW97] C. Rigney, A. Rubens, W. Simpson, and S. Willens.  Remote
            authentication dial in user service (RADIUS).  RFC 2138,
            Internet Engineering Task Force, April 1997.

   [SCFJ96] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson.
            RTP: a transport protocol for real-time applications.  RFC
            1889, Internet Engineering Task Force, January 1996.

   [ZJN97]  L. Zhang, V. Jacobson, and K. Nichols.  A two-bit
            differentiated services architecture for the internet.
            Internet Draft, Internet Engineering Task Force, December
            1997.  Work in progress.

   [ZPC98]  G. Zorn, P. Pan, and P. Calhoun.  DIAMETER framework
            document.  Internet Draft, Internet Engineering Task Force,
            August 1998.  Work in progress.





Authors' Address


 Ping Pan
 Dept. of Electrical Engineering
 Columbia University
 1214 Amsterdam Avenue
 New York, NY 10027
 USA
 Email:  pan@ctr.columbia.edu

 Henning Schulzrinne
 Dept. of Computer Science
 Columbia University
 1214 Amsterdam Avenue
 New York, NY 10027
 USA
 Phone: 1-212-939-7042
 Email:  schulzrinne@cs.columbia.edu

 Pat Calhoun
 Technology Development
 Sun Microsystems, Inc.



Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 16]


Internet Draft                 DIAMETER-SIP                 31 July 1998


 15 Network Circle
 Menlo Park, California, 94025
 USA
 Phone:  1-650-786-7733
 Email:  pcalhoun@eng.sun.com














































Calhoun, Schulzrinne, Pan       Expires 31 December 1998       [Page 17]