idnits 2.17.1 draft-pan-diameter-sip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 279: '... message MUST be dropped at the call...' RFC 2119 keyword, line 286: '... the callee MUST send a SIP request ...' RFC 2119 keyword, line 290: '...ller, the callee MUST send a SIP reque...' RFC 2119 keyword, line 360: '...orting this extension MUST support all...' RFC 2119 keyword, line 410: '... or SIP-Response MUST accompany with a...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The AVP Flags field MUST not have bit one (Mandatory Support) set. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 July 1998) is 9401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'HSS98' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC98' ** Obsolete normative reference: RFC 2138 (ref. 'RRSW97') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1889 (ref. 'SCFJ96') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. 'ZJN97' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZPC98' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Ping Pan (Columbia U) 2 INTERNET DRAFT Henning Schulzrinne (Columbia U) 3 Pat Calhoun (Sun) 4 31 July 1998 6 DIAMETER: Policy and Accounting Extension for SIP 7 draft-pan-diameter-sip-00.txt 9 Status of This Memo 11 This document is an Internet-Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as 19 reference material, or to cite them other than as a ``working draft'' 20 or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the internet-drafts 24 Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 This document describes a policy and accounting information exchange 31 mechanism between a DIAMETER policy server and a SIP proxy server. 32 A DIAMETER server is responsible for maintaining a user policy and 33 accounting database and a means to update it. A SIP proxy server 34 needs to be able to contact a DIAMETER server during multimedia 35 session setup and tear-down time to perform admission control and 36 accounting tasks. 38 To provide proper service guarantees to the sessions that are 39 established with SIP, DIAMETER servers are also responsible for 40 providing an interface to the network resource management database. 41 However, this is beyond the scope of this document. 43 The objective of the mechanism is 1) accuracy, 2) flexibility, and 3) 44 simplicity. The protocol does not make any assumptions about policy 45 algorithms at DIAMETER servers and implementation details at SIP 46 servers. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. Terminology 3 58 3. Description of Operation 3 59 3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Initialization Operation . . . . . . . . . . . . . . . . 4 61 3.3. Caller Detailed Operation . . . . . . . . . . . . . . . . 4 62 3.4. Callee Detailed Operation . . . . . . . . . . . . . . . . 5 63 3.5. Server Considerations . . . . . . . . . . . . . . . . . . 5 65 4. AVP Formats 5 66 4.1. Device-Reboot-Indication AVP extension . . . . . . . . . 6 67 4.2. DIAMETER-Command AVP extension . . . . . . . . . . . . . 7 68 4.3. DIAMETER Error-Code AVP extension . . . . . . . . . . . . 7 69 4.4. SIP Specific AVP's . . . . . . . . . . . . . . . . . . . 7 70 4.4.1. SIP-Sequence AVP . . . . . . . . . . . . . . . . 8 71 4.4.2. SIP-Call-ID AVP . . . . . . . . . . . . . . . . . 9 72 4.4.3. SIP-To AVP . . . . . . . . . . . . . . . . . . . 10 73 4.4.4. SIP-From AVP . . . . . . . . . . . . . . . . . . 11 74 4.4.5. SIP-Entire-Msg AVP . . . . . . . . . . . . . . . 11 76 5. Command Format 12 77 5.1. SIP Admission Control Commands . . . . . . . . . . . . . 12 78 5.2. SIP Accounting Commands . . . . . . . . . . . . . . . . . 13 79 5.3. SIP Termination Commands . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 DIAMETER [ZPC98] is a proposed successor to RADIUS [RRSW97]. 84 It defines a base protocol [RC98] for policy information to be 85 exchanged among policy-enable entities. It is designed as a common 86 platform for several Internet services, such as AAA (Authentication, 87 Authorization i and Accounting), network-edge resource management and 88 VPN (Virtual Private Network). 90 SIP [HSS98] (Session Initiation Protocol) is designed to allow 91 network users to establish and control multimedia sessions over the 92 Internet. A SIP session can be an IP telephone call. However, user 93 accounting, policy and billing systems are beyond scope of SIP, and 94 must be in place in order to provide telephony service in commercial 95 networks. 97 This document describes a policy/accounting mechanism that can 98 interface between SIP proxy servers and policy servers to provide 99 admission control and to update and maintain user data for accounting 100 purposes. Figure-1 illustrates the proposed model. 102 +------------+ 103 | Policy | 104 | Server | 105 +------------+ 106 /|\ 107 | 108 | DIAMETER messages 109 | 110 \|/ 111 +-----------------+ 112 | Diameter Client | 113 +--------+ SIP messages | | SIP Messages 114 | SIP | ================> | (SIP Proxy) | ====================> 115 | client | | | 116 +--------+ | | 117 +-----------------+ 119 Figure-1: A model for SIP/DIAMETER interface. 121 The proposal is designed based on the following assumptions: 123 1. A policy server is the central decision entity. The clients 124 (that is, SIP proxy servers) should always forward the 125 information to the server. However this does not preclude 126 a client from maintaining a policy information cache for 127 performance optimization purposes. 129 2. A policy server maintains a policy and accounting database for 130 all users within an administrative domain, and a means to update 131 it. 133 3. The extension relies on the base protocol to provide massaging 134 reliability. A DIAMETER server and a DIAMETER client, therefore, 135 have no need to implement other reliable message delivery 136 mechanisms. 138 SIP is a out-band signaling protocol, and the actual voice data may 139 use a different route than the path that SIP messages traverse. 140 For IP telephony, voice data is transmitted in the form of RTP 141 [SCFJ96]. To ensure voice data being delivered properly, users can 142 make the use of end-to-end resource reservation protocols to set up 143 reserved "flows". Another alternative is to mark the packet header 144 as "premium service" [ZJN97] so that they can be delivered with low 145 delay and rate guarantees inside the network. Both approaches imply 146 that the network-edge routers may need to interface with policy 147 servers to manage link resources. However, the detailed mapping and 148 management between IP telephone sessions and link resource management 149 requires further investigation, and are beyond the scope of this 150 document at this point. 152 In addition, the proposed extension does not perform policy and 153 accounting processing itself. It is therefore important to remember: 155 1. The protocol does NOT make any assumptions about the algorithm 156 of the policy server, but is based on the server returning a 157 "decision" in response to a policy request. 159 2. The protocol does NOT make any assumptions about the 160 implementation details of the SIP proxy server. However, when 161 a policy event takes place, a SIP proxy must send all relevant 162 information to a server for policy evaluation. 164 3. The communication mechanism among policy servers is NOT in the 165 scope of this document. 167 4. To provide IP telephone service, it may require some level 168 interaction between the policy server at the caller-side and 169 the one at the callee-side. However, such interaction requires 170 further investigation and is not included in this document. 172 2. Terminology 174 - Caller: The device that initiating a session invitation. 175 Through out the draft, we assume a caller is a SIP proxy server 176 that sets up sessions for telephone users at a source network. 178 - Callee: The device that a caller is trying to invite to a 179 session. We assume a callee is a SIP proxy server that manage 180 sessions for telephone users at a remote network. 182 - Policy Server: A host or router that stores policy rules, and is 183 capable to communicate with its clients via DIAMETER protocol. 185 - Client: A SIP proxy server that interface with a "trusted" 186 policy server to perform policy and accounting checking, and some 187 level of admission control. A client is a SIP caller, or a SIP 188 callee, or both. 190 - Policy Event: The event that takes place at a client and 191 requires policy checking. Such event could be the reception of a 192 SIP INVITE, ACK, CANCEL, or BYE message. 194 - Policy Event Message: The message that triggers a policy event 195 at a client. 197 - AVP: The DIAMETER protocol consists of a header followed by 198 objects. Each object is encapsulated in a header known as an 199 Attribute-Value-Pair. 201 3. Description of Operation 203 3.1. Outline 205 DIAMETER client (in this case, SIP Proxy Server) and policy server 206 exchange DIAMETER messages to open and confirm a client-server 207 connection at boot-up time. The initial data between a policy server 208 and a client are device availability, client/server identification 209 and the level of supported features. The information is encoded in 210 standard DIAMETER Device-Reboot-Indication and Host-IP-Address AVP's. 212 Both client and policy servers must support DIAMETER SIP extension. 213 In case a client going down, the server must download known client 214 configuration to the client after reboot. 216 A client queries its policy server when a SIP policy event occurs. A 217 policy event could be due to the arrival of a SIP INVITE, ACK, CANCEL 218 or BYE message. SIP OPTION and REGISTER messages will not trigger 219 policy events. 221 When the server receives a query, it performs policy checking, 222 admission control and accounting. If the server needs to inform 223 the results of the policy checking to a client, it can send a reply 224 message to the client. 226 A client, by default, has one primary and several alternative 227 servers. In case of primary server failure, the client can try to 228 open a new DIAMETER connection with one of its alternative servers. 229 After the new connection is established, the client must notify the 230 server of all its pending policy requests. 232 A policy server can asynchronously download policy decisions to a 233 client. In turn, the policy decisions may trigger SIP messages to be 234 generated at the client to re-direct or cease existing sessions. 236 Optionally, a client can cache all or a part of the policy decisions 237 locally. In this case, a server must asynchronously download the 238 decision information to the client. However, the server must be 239 responsible for updating any decision change to the client. 241 3.2. Initialization Operation 243 At the boot-up time, servers and clients inform each other about 244 the features that need to be supported. As a part of the feature 245 discovery process, the DIAMETER Device-Reboot-Indication AVP must 246 contain the feature number that has been assigned to the SIP/DIAMETER 247 extension. For a client that has multiple servers, it must exchange 248 feature information with all its servers at initialization time. 250 3.3. Caller Detailed Operation 252 When a caller (a SIP proxy server) is being notified to set up a call 253 for a user, it first initiates a DIAMETER request command to its 254 policy server with all the information about the user. The server, 255 in turn, checks the request against the admission control policy 256 database, and returns the findings in a DIAMETER response message. 257 If the response is OK, the caller will sends a SIP INVITE message to 258 the callee. 260 If the callee accepts the call, it replies a SIP 200 (SUCCESS) signal 261 to the caller. Upon reception, the caller confirms the call by 262 sending back a SIP ACK message. At the same time, the call must also 263 send a notification to the server to start the accounting process. 264 The notification is in DIAMETER request message format. 266 When a caller receives a call termination notification from the user, 267 or a SIP BYE message from the callee, it informs the policy server to 268 stop the accounting. 270 When a caller sends a SIP CANCEL message to cancel a pending request, 271 it must also inform the policy server. 273 3.4. Callee Detailed Operation 275 After a callee receives a INVITE message, it initiates a SIP request 276 command to the server for policy checking. If the server replies a 277 denial response, the callee will reject the session invitation by 278 sending a SIP 4XX (Error) signal to the caller. The original INIVITE 279 message MUST be dropped at the callee. If the server permits the 280 invitation, the callee needs to relay the INIVITE message to the 281 destination user, or (as a proxy) to directly reply a SIP 200 signal 282 to the caller. 284 A SIP caller always sends a SIP ACK message to the callee to confirm 285 the establishment of a session. When an ACK message being received, 286 the callee MUST send a SIP request message to the policy server to 287 start the accounting process. 289 When the callee decides to terminate the call, or a BYE message is 290 sent by the caller, the callee MUST send a SIP request message to the 291 server to stop the accounting process. 293 After the callee receives a SIP CANCEL, it needs to inform the policy 294 server to remove the pending requests. 296 3.5. Server Considerations 298 DIAMETER/SIP policy servers may or may not support SIP protocol. As 299 a result, clients have the option to either 1) send the entire SIP 300 message to the servers, or 2) parse the SIP message first and send 301 pre-defined SIP AVP's to the servers. 303 4. AVP Formats 305 Each DIAMETER message consists of multiple AVP's, that are 32-bit 306 aligned, with the following format: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | AVP Code | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | AVP Length | AVP Flags | Reserved | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 // (AVP contents) // 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Code 322 Identifies the AVP; values of this field are defined below. 324 AVP Length 326 A 16-bit field containing the total object length in bytes. 327 Must always be a multiple of 4, and at least 8. 329 AVP Flags 331 0x01: Mandatory-Support 332 0x02: SS-Encrypted-Data 333 0x03: PK-Encrypted-Data 334 0x04: Vendor-Specific-AVP 336 Readers can refer [RC98] for detailed DIAMETER base protocol 337 information. 339 4.1. Device-Reboot-Indication AVP extension 341 Clients and servers send the Device-Reboot-Indication messages at 342 initialization or reboot time. The message originator must include 343 all supported extensions within the message. The responder must 344 include all supported extensions as long as they were present within 345 the request message. 347 The DIAMETER SIP extension uses Extension Id 6. 349 The Extension Id may also be used in Device-Feature-Request, 350 Device-Feature-Response and Extension-Id AVP's. 352 4.2. DIAMETER-Command AVP extension 354 The Command AVP must be the first AVP following the DIAMETER 355 header. There must only be one Command AVP per message. The command 356 information is in the AVP's Command Code field. The message format 357 can be found in [RC98]. 359 This document defines the following DIAMETER Command Codes. All 360 DIAMETER implementations supporting this extension MUST support all 361 of the following: 363 Command Name Command Code 364 -------------------------------------------- 365 SIP-Admission-Request 600 366 SIP-Admission-Response 601 367 SIP-Accounting-Request 602 368 SIP-Accounting-Response 603 369 SIP-Termination-Request 604 370 SIP-Termination-Response 605 372 4.3. DIAMETER Error-Code AVP extension 374 The Error-Code AVP contains the explicit message error code. Note: 375 the Error-Code AVP must be coupled with the Result-Code AVP which 376 consists of DIAMETER_SEE_ERROR_CODE information. 378 The extension defines the following additional error code for SIP 379 operation: 381 0x6001: Missing Call-ID in the request 382 0x6002: Missing To in the request message 383 0x6003: Missing From in the request message 385 0x6010: Prohibited Caller 386 0x6011: Prohibited Callee 388 4.4. SIP Specific AVP's 390 This section defines the extension specific AVP's. 392 The following are the mandatory AVP's which must be recognized by all 393 DIAMETER implementations supporting this extension. 395 Attribute Name AVP Code 396 ----------------------------------- 397 SIP-Sequence 600 398 SIP-Call-ID 601 399 SIP-To 602 400 SIP-From 603 402 The following is an optional AVP. 404 Attribute Name AVP Code 405 ----------------------------------- 406 SIP-Entire-Msg 604 408 4.4.1. SIP-Sequence AVP 410 Each SIP-Request or SIP-Response MUST accompany with a sequence 411 number. When a DIAMETER device receives a request, it checks the 412 received sequence number against the sequence number in the last 413 transmitted SIP-Request of the same SIP session. If they are not 414 equal, the response is ignored. 416 The AVP may be replaced by a DIAMETER global sequence number AVP in 417 the future. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | AVP Code | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | AVP Length | AVP Flags | Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Sequence Number | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Code 430 SIP-Sequence: 600 432 AVP Length: 434 The length of this attribute MUST be 12. 436 AVP Flags 438 The AVP Flags field MUST have bit one (Mandatory Support) set. 440 Sequence Number: 442 A number between 0xff to 0xffffffff 444 4.4.2. SIP-Call-ID AVP 446 SIP uses Call-ID to identify a particular call session between two 447 users. DIAMETER servers can use Call-ID's to keep track of all 448 on-going calls for billing and accounting purposes. The SIP-Call-ID 449 AVP has the following format: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | AVP Code | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | AVP Length | AVP Flags | Reserved | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 // SIP Call-ID // 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Code 465 SIP-Call-ID: 601 467 AVP Length: 469 The length of this attribute depends on the size of SIP Call-ID. 471 AVP Flags 472 The AVP Flags field MUST have bit one (Mandatory Support) set. 474 SIP Call-ID: 476 A copy of the original SIP Call-ID data. 478 4.4.3. SIP-To AVP 480 This identifies the invited user of the session. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | AVP Code | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | AVP Length | AVP Flags | Reserved | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 // SIP TO URL // 491 | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Code 496 SIP-TO-ID: 602 498 AVP Length: 500 The length of this attribute depends on the size of SIP TO URL. 502 AVP Flags 504 The AVP Flags field MUST have bit one (Mandatory Support) set. 506 SIP Call-ID: 508 A copy of the original SIP URL for the invited user. 510 4.4.4. SIP-From AVP 512 This AVP identifies the invitation initiator ID in SIP URL format. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | AVP Code | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | AVP Length | AVP Flags | Reserved | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 // SIP FROM URL // 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Code 528 SIP-FROM-ID: 603 530 AVP Length: 532 The length of this attribute depends on the size of SIP FROM URL. 534 AVP Flags 536 The AVP Flags field MUST have bit one (Mandatory Support) set. 538 SIP Call-ID: 540 A copy of the invitation initiator's SIP URL. 542 4.4.5. SIP-Entire-Msg AVP 544 The AVP encapsulates an entire SIP message. In order to ease the 545 processing overhead at clients, and to provide adequate information, 546 a SIP request message may send the entire SIP message to the server 547 for parsing and processing. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | AVP Code | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | AVP Length | AVP Flags | Reserved | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 // SIP Message // 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Code 563 SIP-Entire-Msg: 604 565 AVP Length: 567 The length of this attribute depends on the size of SIP message. 569 AVP Flags 571 The AVP Flags field MUST not have bit one (Mandatory Support) set. 573 SIP Message: 575 A copy of the original SIP message. 577 5. Command Format 579 5.1. SIP Admission Control Commands 581 During SIP call setup time, a SIP caller sends an admission control 582 request to the DIAMETER server before sending a SIP INVITE message. 583 At callee's side, it sends an admission control request to the 584 DIAMETER server after receiving a SIP INVITE message. 586 The format of the request message is the following: 588 ::= 589 590 591 592 593 594 596 [] 597 598 599 { || 600 } 602 The Host-IP-Address AVP contains the client's IP address. 604 The server bases on the request to conduct admission control for the 605 session, and reply a response back to the client in the following 606 format: 608 ::= 609 610 611 612 [] 613 614 615 [] 616 [] 617 618 619 { || 620 } 622 The Host-IP-Address AVP contains the server's identification. If the 623 server does not admit the call session, it must reply an Error-Code 624 AVP to identify the rejection reason. SIP client and server, by 625 default, use SIP Call-ID to represent a call session. However an 626 implementation may use SIP To and From to manage call sessions in 627 their database, so the response may need to consist of SIP-To and 628 SIP-From AVP's. 630 5.2. SIP Accounting Commands 632 After a SIP call session being established, the clients need to send 633 an account request command to the servers to start up the accounting 634 process. The message format is: 636 ::= 637 638 639 640 641 642 643 644 [] 645 646 647 { || 648 } 650 The Timestamp AVP contains the timing information at client. Servers 651 must base on this information to keep the duration of call sessions. 653 The servers must reply an accounting response back to the clients. 655 ::= 656 657 658 659 660 [] 661 662 [] 663 [] 664 665 666 { || 667 } 669 If the server cannot process an accounting request, it must reply an 670 Error-Code AVP to identify the error condition. 672 5.3. SIP Termination Commands 674 A SIP Termination request may come from either client-side or 675 server-side. At a client, when it receives a hang-up signal from 676 end users, or a SIP BYE message, or a SIP CANCEL message (for callee 677 only), it must inform the server to stop the accounting process. Due 678 to user policy, the server can send a termination request to the 679 client to stop an on-going call. In turn, the client must send a SIP 680 BYE to the other party to cease a call. 682 A termination request has the following format: 684 ::= 685 686 687 688 689 690 691 692 693 { || 694 } 696 When a DIAMETER receives a termination request, it must reply: 698 ::= 699 700 701 702 [] 703 704 705 [] 706 [] 707 708 709 { || 710 } 712 References 714 [HSS98] M. Handley, H. Schulzrinne, and E. Schooler. SIP: session 715 initiation protocol. Internet Draft, Internet Engineering 716 Task Force, May 1998. Work in progress. 718 [RC98] A. Rubens and P. Calhoun. DIAMETER base protocol. Internet 719 Draft, Internet Engineering Task Force, July 1998. Work in 720 progress. 722 [RRSW97] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 723 authentication dial in user service (RADIUS). RFC 2138, 724 Internet Engineering Task Force, April 1997. 726 [SCFJ96] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. 727 RTP: a transport protocol for real-time applications. RFC 728 1889, Internet Engineering Task Force, January 1996. 730 [ZJN97] L. Zhang, V. Jacobson, and K. Nichols. A two-bit 731 differentiated services architecture for the internet. 732 Internet Draft, Internet Engineering Task Force, December 733 1997. Work in progress. 735 [ZPC98] G. Zorn, P. Pan, and P. Calhoun. DIAMETER framework 736 document. Internet Draft, Internet Engineering Task Force, 737 August 1998. Work in progress. 739 Authors' Address 741 Ping Pan 742 Dept. of Electrical Engineering 743 Columbia University 744 1214 Amsterdam Avenue 745 New York, NY 10027 746 USA 747 Email: pan@ctr.columbia.edu 749 Henning Schulzrinne 750 Dept. of Computer Science 751 Columbia University 752 1214 Amsterdam Avenue 753 New York, NY 10027 754 USA 755 Phone: 1-212-939-7042 756 Email: schulzrinne@cs.columbia.edu 758 Pat Calhoun 759 Technology Development 760 Sun Microsystems, Inc. 762 15 Network Circle 763 Menlo Park, California, 94025 764 USA 765 Phone: 1-650-786-7733 766 Email: pcalhoun@eng.sun.com