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]