RFC 4740
Diameter Session Initiation Protocol (SIP) Application
RFC 4740: Diameter Session Initiation Protocol (SIP) Application ✨
okay bestie, this is the RFC that tells Diameter servers how to help SIP servers with authentication, authorization, and user profiles 💅 It's a Standards Track document, so it's an official Internet protocol spec, not a vibe.
Here's the title block tea 🫖 It's from the Network Working Group and is RFC 4740. It's dated November 2006. Main editor is M. Garcia-Martin, Ed. from Nokia, with M. Belinchon, M. Pallares-Lopez, and C. Canales-Valenzuela from Ericsson, and K. Tammi from Nokia. The title block doesn't say it obsoletes or updates any other RFC 🦋
Status of This Memo
okay so this part is the legal-ish bit 🧚 It says this document is an Internet standards track protocol for the Internet community, and it wants people to talk about it and suggest improvements. If you want the current standardization state, check the "Internet Official Protocol Standards" (STD 1). And distribution is unlimited, so share it with everyone 🌸
Copyright Notice
Copyright (C) The IETF Trust (2006). Yep, that's it 💜
Abstract
so the whole point of this doc is the Diameter Session Initiation Protocol (SIP) application ✨ It's a Diameter application that lets a Diameter client ask for authentication and authorization info. It's meant to be used with SIP, and it sets up a Diameter client sitting right next to a SIP server. That lets the SIP server ask the Diameter server to authenticate users and approve their use of SIP resources. main character energy 👑
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Definitions .....................................................5
4. Acronyms ........................................................6
5. Applicability Statement .........................................6
6. Overview of Operation ...........................................7
6.1. General Architecture .......................................7
6.2. Diameter Server Authenticates the User .....................9
6.3. Delegating Final Authentication Check to the SIP Server ...12
6.4. SIP Server Requests Authentication and Authorization ......15
6.5. Locating the Recipient of the SIP Request .................16
6.6. Update of the User Profile ................................17
6.7. SIP Soft State Termination ................................18
6.8. Diameter Server Discovery .................................19
7. Advertising Application Support ................................21
8. Diameter SIP Application Command Codes .........................22
8.1. User-Authorization-Request (UAR) Command ..................22
8.2. User-Authorization-Answer (UAA) Command ...................23
8.3. Server-Assignment-Request (SAR) Command ...................27
8.4. Server-Assignment-Answer (SAA) Command ....................29
8.5. Location-Info-Request (LIR) Command .......................33
8.6. Location-Info-Answer (LIA) Command ........................33
8.7. Multimedia-Auth-Request (MAR) Command .....................35
8.8. Multimedia-Auth-Answer (MAA) Command ......................36
8.9. Registration-Termination-Request (RTR) Command ............39
8.10. Registration-Termination-Answer (RTA) Command ............39
8.11. Push-Profile-Request (PPR) Command .......................41
8.12. Push-Profile-Answer (PPA) Command ........................42
9. Diameter SIP Application AVPs ..................................44
9.1. SIP-Accounting-Information AVP ............................46
9.1.1. SIP-Accounting-Server-URI AVP ......................47
9.1.2. SIP-Credit-Control-Server-URI AVP ..................47
9.2. SIP-Server-URI AVP ........................................47
9.3. SIP-Server-Capabilities AVP ...............................47
9.3.1. SIP-Mandatory-Capability AVP .......................48
9.3.2. SIP-Optional-Capability AVP ........................48
9.4. SIP-Server-Assignment-Type AVP ............................48
9.5. SIP-Auth-Data-Item AVP ....................................50
9.5.1. SIP-Authentication-Scheme AVP ......................50
9.5.2. SIP-Item-Number AVP ................................51
9.5.3. SIP-Authenticate AVP ...............................51
9.5.4. SIP-Authorization AVP ..............................52
9.5.5. SIP-Authentication-Info AVP ........................52
9.5.6. Digest AVPs ........................................53
9.6. SIP-Number-Auth-Items AVP .................................55
9.7. SIP-Deregistration-Reason AVP .............................55
9.7.1. SIP-Reason-Code AVP ................................55
9.7.2. SIP-Reason-Info AVP ................................56
9.8. SIP-AOR AVP ...............................................56
9.9. SIP-Visited-Network-Id AVP ................................56
9.10. SIP-User-Authorization-Type AVP ..........................56
9.11. SIP-Supported-User-Data-Type AVP .........................57
9.12. SIP-User-Data AVP ........................................57
9.12.1. SIP-User-Data-Type AVP ............................58
9.12.2. SIP-User-Data-Contents AVP ........................58
9.13. SIP-User-Data-Already-Available AVP ......................58
9.14. SIP-Method AVP ...........................................59
10. New Values for Existing AVPs ..................................59
10.1. Extension to the Result-Code AVP Values ..................59
10.1.1. Success Result-Code AVP Values ....................59
10.1.2. Transient Failures Result-Code AVP Values .........60
10.1.3. Permanent Failures Result-Code AVP Values .........60
11. Authentication Details ........................................61
12. Migration from RADIUS .........................................63
12.1. Gateway from RADIUS Client to Diameter Server ............63
12.2. Gateway from Diameter Client to RADIUS Server ............63
12.3. Known Limitations ........................................64
13. IANA Considerations ...........................................64
13.1. Application Identifier ...................................64
13.2. Command Codes ............................................65
13.3. AVP Codes ................................................65
13.4. Additional Values for the Result-Code AVP Value ..........65
13.5. Creation of the SIP-Server-Assignment-Type
Section in the AAA .......................................66
13.6. Creation of the SIP-Authentication-Scheme Section
in the AAA ...............................................66
13.7. Creation of the SIP-Reason-Code Section in the
AAA Registry .............................................66
13.8. Creation of the SIP-User-Authorization-Type
Section in the AAA .......................................66
13.9. Creation of the SIP-User-Data-Already-Available
Section in the ...........................................66
14. Security Considerations .......................................67
14.1. Final Authentication Check in the Diameter
Client/SIP Server ........................................67
15. Contributors ..................................................68
16. Acknowledgements ..............................................68
17. References ....................................................68
17.1. Normative References .....................................68
17.2. Informative References ...................................691. Introduction ✨
okay so this section is the "what is this even" intro 🦋 The doc specifies the Diameter SIP application, which lets a Diameter client ask a Diameter server for authentication and authorization info for SIP-based IP multimedia services (see [RFC3261] about SIP) 💖 It also does extra stuff, like downloading or receiving updated user profiles, and some basic routing so a SIP server can find another SIP server that's assigned to the user 🧚
Here's the setup 🌸 The SIP server (like a SIP proxy, registrar, redirect server, or similar) and the Diameter client are co-located on the same node. That way the SIP server can receive and process SIP requests and responses. The SIP server then leans on the Authentication, Authorization, and Accounting (AAA) infrastructure to check SIP requests and approve use of SIP services 💅
This doc gives Diameter procedures for certain required functionality. That covers when SIP starts and ends multimedia sessions, and also when SIP is used for other stuff that isn't session-related 🎀 It does not mandate any particular mapping of SIP procedures to Diameter SIP application procedures, and it doesn't mandate a specific order of events between SIP and Diameter either. It just shows useful examples of how SIP and the Diameter SIP application work together 🫶
This application doesn't need, and isn't related to, the other authentication services from the Diameter Mobile IPv4 [RFC4004] or Diameter Network Access Server [RFC4005] applications 🙈
It's loosely related to the Diameter credit-control application [RFC4006]. Both are independent, but the Diameter SIP application can hand out the addresses of credit-control servers that run the Diameter credit-control application [RFC4006] ✨
Here's where to find the rest:
- Section 5 covers the assumptions and configurations this doc relies on 🌈
- Section 6 has informative descriptions of the Diameter SIP application commands and responses, plus guidance on how they link to SIP procedures 🧚
- Section 7 is where advertisement of this application is specified 📣
- Section 8 is the normative description of all the new Diameter commands defined here 👑
- Section 9 describes all the new AVPs 💜
- Section 10 covers the new values added to the Result-Code AVP 🍓
- Section 11 has extra info about authentication 🔥
This application extends the Result-Code Attribute-Value-Pair (AVP) with some new values. More on that in Section 10 💅
2. Terminology
okay this is the key-word section and it's lowkey important 🙈 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14, RFC 2119 [RFC2119]. They show requirement levels for compliant implementations, so read them carefully, bestie 💖
Heads up: these key words are the official spec-speak for how strict each rule is, so don't treat them like casual vibes ✨
3. Definitions ✨
okay so first things first, we need to be on the same page about the words 💅 For this doc:
Node: an addressable device attached to a computer network that implements SIP functionality, Diameter functionality, or a combination of both. 🦋
Next, these ones come from RFC 3261 [RFC3261] Section 6, and they apply here too 🧚
- Address-of-Record (AOR)
- Outbound proxy
- Proxy
- Registrar
- Server (SIP server)
- User Agent (UA)
- User Agent Client (UAC)
- User Agent Server (UAS)
And then these are from RFC 3588 [RFC3588] Section 1.3, also applying here 💖
- Authorization
- Authentication
- Attribute-Value Pair (AVP)
- Diameter Client
- Diameter Server
- Home Realm
- Redirect Agent
- User
4. Acronyms 💜
the acronym list is giving alphabet soup, so here it is in its own little box 🍓
AKA: Authentication and Key Agreement
LIR: Location-Info-Request
LIA: Location-Info-Answer
MAR: Multimedia-Auth-Request
MAA: Multimedia-Auth-Answer
PPR: Push-Profile-Request
PPA: Push-Profile-Answer
RTR: Registration-Termination-Request
RTA: Registration-Termination-Answer
SAR: Server-Assignment-Request
SAA: Server-Assignment-Answer
SL: Subscriber Locator
UAR: User-Authorization-Request
UAA: User-Authorization-Answer5. Applicability Statement 🎀
okay so this doc assumes a general setup where a Home Realm is made up of one or more nodes that do Diameter or SIP stuff 🌈 Users send SIP requests to get at SIP resources. For each user, the Home Realm has to authenticate and authorize their use of those resources, and/or work out the route to the right node. We assume the database holding the user's data lives outside the SIP node that needs the authorization. Data for different users can live on different nodes in the Home Realm, but all the data for one particular user is kept in a single node ✨
Note: Central to the architecture is the fact that the user data is stored in a single point in the network. This restriction does not mandate a particular implementation, e.g., it is possible to implement clusters of databases operating in mirror mode to provide redundancy. The property required by this specification is that the user data the Diameter server has access to is stored safely in what is seen, from the external point of view, as a single user database.
This doc allows a few different Home Realm setups 🦋 In one of them, a SIP server (a proxy, a registrar, etc.) gets assigned to a user so it can trigger and run services for them. That assignment can happen dynamically, e.g., when the user registers on the network. This setup needs a SIP server, usually sitting at the edge of the network, that can assign another SIP server to the user and that also routes SIP requests and responses toward that assigned server. Both SIP server nodes implement a Diameter client 🫶
In another setup, the address of a SIP outbound proxy is configured into the SIP User Agent (by means outside the scope of this specification) 💅 The outbound Diameter client in that SIP outbound proxy node authenticates the user, requests authorization for SIP requests, and does accounting activities.
6. Overview of Operation 🌸
this section is just an informative tour of how the Diameter SIP application can work together with SIP 🧚 It's not meant to mandate any specific usage of the Diameter SIP application, and it doesn't mandate a specific mapping between SIP and Diameter messages either. We've got a collection of examples showing how the required AAA functionality can be achieved alongside SIP ✨
6.1. General Architecture 🍓
the Diameter SIP application can be used in a SIP environment where you need an interface to a AAA infrastructure to authenticate and authorize the use of SIP resources 💖 It supports SIP User Agents and proxies that implement and use HTTP Digest authentication [RFC2617], which is the authentication mechanism mandated by SIP [RFC3261]. The application is extensible, so if the need comes up, it can be extended to support other authentication mechanisms or extensions to HTTP Digest authentication when they show up 🦋
This application gives limited support for accounting services, like this: the Diameter server can provide the addresses of accounting severs to the Diameter client. Figure 1 below gives a general overview of how the SIP architecture plugs into the AAA architecture 👑
Okay so according to Figure 1, there are one or more SIP User Agents (UAs) that start or end SIP traffic through one or more SIP servers. Both SIP servers implement a Diameter client that supports the Diameter application described in this specification 💜
+--------+
UAR/UAA +--->|Diameter|<----+ PPR/PPA
LIR/LIA | | server | | MAR/MAA
| +--------+ | SAR/SAA
| | RTR/RTA
| |
v v
+------+ SIP +--------+ SIP +--------+ SIP +------+
| SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP |
| UA | |server 1| |server 2| | UA |
+------+ +--------+ +--------+ +------+
^ ^
UAR/UAA | |
LIR/LIA | | MAR/MAA
| +--------+ | SAR/SAA
+--->|Diameter|<----+
| SL |
+--------+
Figure 1: Architecture of the Diameter application for SIPIn Figure 1, SIP server 1 sends different Diameter commands and gets different responses than SIP server 2 does 🙈 That's because SIP server 1 sits at the edge of a network, and its main job is to locate SIP server 2. SIP server 2 is the one requesting and receiving authentication and authorization data from the Diameter server, and it's not at the edge of the network 🔥
This Diameter application assumes all the data for a given user is stored in a single Diameter server 🌷 For redundancy, several Diameter servers can be configured in a redundancy fashion, in which case all of them keep the data synchronized and operate externally as a single Diameter server ✨
Looking at SIP server 1 in Figure 1, the Diameter SIP application supports a farm of these servers, usually set up through one or more DNS records that point to several hosts (this is a typical configuration in common SIP deployments) 💅 There's no requirement for these kinds of servers to keep any state related to the Diameter SIP application 🫶
The Diameter SIP application also supports a feature that lets an administrative domain provide a collection of SIP servers 2 (as per Figure 1) 🌈 Once the user registers for the first time, one of these SIP servers gets selected, and all the SIP requests related to that user get processed by the same SIP server 🦋
The Diameter Subscriber Locator (SL) is there to find the Diameter server that holds the user-related data. Its functionality is based on the Diameter redirect mechanism and is further described in Section 6.8 🧚
It should be noted that this document does not mandate any particular SIP/AAA architecture 💖 However, the Diameter SIP application provides the functionality needed to accommodate all the different architectures where SIP and Diameter are used 👑
The following subsections provide an informative overview of the Diameter SIP application, its commands, and a possible interaction with SIP signaling 🎀
6.2. Diameter Server Authenticates the User ✨
okay so this is the generic way to authenticate users, and it's giving main character energy 💅 Picture an administrative network where the Diameter server is the one checking SIP user requests. This could be a medium-size network with a Diameter server keeping user records and authenticating SIP requests before a certain transaction goes through 🎀 We picked a SIP REGISTER request for the example, but honestly the SIP server could ask for authentication on any other SIP request too 🦋
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. SIP 401 (Unauthorized) |
8. SIP 401 (Unauth.) |<--------------------------------------|
<--------------------| | |
9. SIP REGISTER | | |
-------------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. MAR |
| |<------------------|
| | 14. MAA |
| |------------------>|
| 15. SIP 200 (OK) |
16. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | 17. SAR |
| |<------------------|
| | 18. SAA |
| |------------------>|
| | |
Figure 2: Authentication performed in the Diameter serverso per Figure 2 ✨, a SIP User Agent Client (UAC) sends a SIP REGISTER request (step 1) to SIP server 1, which is the one that catches it. In this picture, SIP server 1 sits at the edge of the administrative home domain 🏠 Next, the Diameter client in SIP server 1 hits up its Diameter server with a Diameter User-Authorization-Request (UAR) message (step 2). It's basically asking "is this user allowed to get service, and if so, which local SIP server can handle them?" 🫶 The Diameter server replies with a Diameter User-Authorization-Answer (UAA) message (step 3), and that answer lists the capabilities SIP server 1 can use to pick a good SIP server (SIP server 2), and/or a SIP or SIPS URI pointing at SIP server 2. iconic ✨
SIP server 1 then forwards the SIP REGISTER request (step 4) to the appropriate SIP server, which is SIP server 2 🦋 The Diameter client in SIP server 2 asks the Diameter server to authenticate the user by sending a Diameter Multimedia-Auth-Request (MAR) message (step 5). This request also lets the Diameter server know the SIP or SIPS URI of SIP server 2, so later requests from the same user get sent back to that same SIP server 2. Very organised, very cute 🎀 The Diameter server answers with a Diameter Multimedia-Auth-Answer (MAA) message (step 6), and its Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH. On top of that, the Diameter server makes a nonce and puts a challenge in the MAA message 🔐 SIP server 2 takes that challenge and maps it into the WWW-Authenticate header of the SIP 401 (Unauthorized) response (step 7). That response goes back to SIP server 1 and then to the SIP UAC (step 8). ngl this is a lot of hops but it's giving teamwork 🧚
Now the user tries again. SIP server 1 gets a next SIP REGISTER request that has the user credentials in it (step 9) 💜 Here's the lowkey iconic bit: SIP server 1 does not need to keep any state, and there's no guarantee the request lands on the same SIP server 1 again. There could honestly be a whole farm of SIP servers 1 running in a redundant setup 🌈 The Diameter client in SIP server 1 contacts the Diameter server with another UAR message (step 10) to find out which SIP server got allocated to the user. The Diameter server sends back the SIP or SIPS URI of SIP server 2 in a UAA message (step 11).
Then SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step 12). SIP server 2 pulls the credentials out of that SIP REGISTER request, and the Diameter client in SIP server 2 sends them in a MAR message (step 13) to the Diameter server. At this point the Diameter server is able to authenticate the user, and if it works, it returns a MAA message (step 14) with the Result-Code AVP set to DIAMETER_SUCCESS ✅ 👑
SIP server 2 then generates a SIP 200 (OK) response (step 15), which gets forwarded to SIP server 1 and eventually lands with the SIP UAC (step 16). Okay, the user is in 🥳
Last bit, and it's optional-vibes but still important 🙈 If the Diameter client in SIP server 2 wants to download the user profile information, or it's required to store the address of the SIP server in the Diameter server, then it sends a Diameter SAR message (step 17) to the Diameter server. The Diameter server replies with a Diameter SAA message (step 18) that contains the requested user profile information and the acknowledgement that the SIP server address was stored 🍓 These actions are needed when the SIP server has to retrieve a user profile to provide services to the served user, or when the SIP server keeps a state for the user, so the Diameter server needs to store the SIP server's address. periodt 💅✨
6.3. Delegating Final Authentication Check to the SIP Server ✨
okay so bestie, picture an operator with a HUGE pile of installed SIP servers 🖥️💖 they wanna cut down on how many round-trips happen between the Diameter client and the Diameter server. so this section gives us a mechanism where the Diameter server hands the final authentication check off to the SIP server, which literally saves a whole round-trip 🎀 the security side of this is covered in Section 14.1, and you need to read it, no skipping 🫶
ALSO, this scenario is NOT it when the Diameter server is set up to use the session MD5 (MD5-sess) algorithm 🙅♀️ bc the Diameter server needs the client nonce to compute H(A1) before it sends that to the Diameter client, and the client nonce might not be around yet at that point 😭 it's giving "not yet, babe" energy 💀
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. MAR |
| |<------------------|
| | 6. MAA |
| |------------------>|
| 7. SIP 401 (Unauthorized) |
8. SIP 401 (Unauth.) |<--------------------------------------|
<--------------------| | |
9. SIP REGISTER | | |
-------------------->| 10. UAR | |
|------------------>| |
| 11. UAA | |
|<------------------| |
| 12. SIP REGISTER |
|-------------------------------------->|
| | 13. SAR |
| |<------------------|
| | 14. SAA |
| |------------------>|
| 15. SIP 200 (OK) |
16. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | |
Figure 3: Delegation of authentication to the SIP serverso Figure 3 shows a SIP server getting dynamically allocated to serve a SIP User Agent, with the Diameter server backing it up 🦋 this is the kind of setup you'd see in certain architectures, like the 3rd Generation Partnership Project (3GPP) IP Multimedia Core Network Subsystem 🌈
here's the tea, step by step 🍓
- Step 1: SIP server 1 gets a SIP REGISTER request whose target is the home network domain. in Figure 3, SIP server 1 sits at the edge of the administrative home domain 🏠
- Step 2: the Diameter client in SIP server 1 asks the Diameter server for permission to keep going by sending a Diameter
User-Authorization-Request(UAR) message. this message carries, among other Attribute-Value-Pairs (AVPs), the SIP Address-Of-Record (AOR) from the SIP REGISTER request 💅 - Step 3: the Diameter server checks the SIP AOR. if it's a valid defined user in the home network, the registration is allowed to proceed ✨ the Diameter server replies with a Diameter
User-Authorization-Answer(UAA) message, which tells the Diameter client/SIP server about the outcome of the user authorization. if it worked, theUAAcan point to a local SIP server (SIP server 2 in Figure 3) and/or a list of capabilities SIP server 1 can use to pick a good SIP server 2 🎀 - Step 4: once authorization succeeds, SIP server 1 forwards the SIP REGISTER request to the right SIP server (SIP server 2) 🚀
- Step 5: the Diameter client in SIP server 2 asks for authentication parameters by sending a Diameter
Multimedia-Auth-Request(MAR) message to the Diameter server. this request also tells the Diameter server the SIP or SIPS URI of SIP server 2, so future requests from the same user get sent back to that same SIP server 2 🧚 - Step 6: the Diameter server answers with a Diameter
Multimedia-Auth-Answer(MAA) message. it includes a nonce plus all the other params needed for the user's authentication algorithm. one of those is aDigest-HA1AVP holding H(A1) (as defined in RFC 2617 [RFC2617]), which lets the Diameter client work out the expected response. then the Diameter client can compare that expected response with the response to the challenge sent from the SIP UA 🔥 and here's a fun detail: if theDigest-HA1AVP is missing from theMAA, that means authentication and authorization happen in the Diameter server instead, like in the scenario from Section 6.2 🙈 - Step 7: SIP server 2 builds a SIP 401 (Unauthorized) response based on the challenge in the
MAAmessage. it includes the authentication material the SIP User Agent Client (UAC) needs to add the right credentials 💜 - Step 8: SIP server 1 forwards that SIP response to the SIP UAC 🌸
now the next part is so good 😭 SIP server 1 receives the next SIP REGISTER request, the one with the user credentials (step 9). SIP server 1 doesn't keep any state, and there's no guarantee the request lands on the same SIP server 1 again. so the Diameter client in SIP server 1 pings the Diameter server again with a UAR message (step 10) to figure out which SIP server is assigned to the user. the Diameter server sends the SIP or SIPS URI of SIP server 2 back in a UAA message (step 11) 🦋
- Step 12: SIP server 1 forwards the SIP REGISTER request to SIP server 2. SIP server 2 checks the credentials by comparing the response from the SIP UA with the expected response it calculated itself, using the H(A1) it got from the Diameter server 🔐
- Step 13: if the credentials are valid, SIP server 2 sends a Diameter
Server-Assignment-Request(SAR) message. this asks the Diameter server to confirm the authentication is complete and to confirm the SIP or SIPS URI of the SIP server currently serving the user. theSARalso asks the Diameter server to send the user profile over to the SIP server 🫶 - Step 14: the Diameter server replies with a Diameter
Server-Assignment-Answer(SAA) message. if theResult-CodeAVP value doesn't tell SIP server 2 about an error, theSAAcan carry zero or moreSIP-User-DataAVPs with the info SIP server 2 needs to serve the user 👑 - Step 15: SIP server 2 generates a SIP 200 (OK) response, which gets forwarded to SIP server 1 and then all the way to the SIP UAC (step 16) 🎉
6.4. SIP Server Requests Authentication and Authorization 💖
Figure 4 is a typical scenario where a stateless SIP proxy asks a Diameter server for authentication info and authorization, so it can provide SIP routing services to a SIP User Agent 🧚♀️ the SIP proxy server might be set up as an outbound SIP proxy, which means every request the SIP UA starts goes through the proxy first 🌈
so, in Figure 4, a SIP User Agent sends a SIP request to its outbound SIP proxy server. in this case it's a SIP INVITE request (step 1), but it could be any other SIP request 🎀 we're assuming this request has no credentials in it yet. the outbound SIP proxy server needs to authenticate and authorize the proxy services it offers the user 💅
- Step 2: the Diameter client in the SIP server sends a Multimedia-Auth-Request (MAR) message to the Diameter server ✨
- Step 3: the Diameter server generates a nonce and sends a Multimedia-Auth-Answer (MAA) message. this includes the nonce and the rest of the data the SIP server needs to challenge the user, typically with HTTP Digest Authentication, which the MAA message indicates 🔥
- Step 4: the SIP server uses that data to create a SIP 407 (Proxy Authentication Required) response with a challenge in it 💜
- Step 5: the SIP UA builds a new INVITE request that contains the credentials 🙌
- Step 6: the Diameter client in the SIP server sends those credentials to the Diameter server in a new Diameter MAR message 🔐
- Step 7: the Diameter server validates the credentials and authorizes the SIP transaction in a Diameter MAA message 🦋
- Step 8: the SIP server forwards the SIP INVITE request to its destination, following regular SIP procedures 🚀
- Step 9: eventually the session setup gets confirmed with a SIP 200 (OK) response, which is forwarded to the SIP UA (step 10) 🎉 and that's it, the session setup is complete!! 👑
+--------+ +--------+
|Diameter| | SIP |
| server | | server |
+--------+ +--------+
| |
| |
1. SIP INVITE |
----------------------------------->|
| 2. MAR |
|<------------------|
| 3. MAA |
|------------------>|
| |
4. SIP 407 (Proxy |
Authentication Required) |
<-----------------------------------|
| |
5. SIP INVITE |
----------------------------------->|
| 6. MAR |
|<------------------|
| 7. MAA |
|------------------>| 8. SIP INVITE
| |---------------->
| | 9. SIP 200 (OK)
10. SIP 200 (OK) |<----------------
<-----------------------------------|
| |
Figure 4: SIP server requests authorization6.5. Locating the Recipient of the SIP Request 💌
okay so picture this: SIP server 1 is set up as a SIP edge proxy, basically the bouncer at the edge of a network 💅 It gets a SIP INVITE (step 1), but it needs to find SIP server 2, the one actually serving the recipient 👀 So the Diameter client in SIP server 1 sends a Diameter Location-Info-Request (LIR) message (step 2) to the Diameter server. The Diameter server replies with a Diameter Location-Info-Answer (LIA) message (step 3) that contains the SIP or SIPS URI of SIP server 2. Then SIP server 1 forwards the SIP INVITE to SIP server 2 (step 4), and SIP server 2 eventually passes it along to the right UAS (step 5). ✨
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
-------------->| 2. LIR | |
|---------------->| |
| 3. LIA | |
|<----------------| |
| 4. SIP INVITE |
|--------------------------------->|
| | | 5. SIP INVITE
| | |-------------->
| | |
| | |
Figure 5: Locating the SIP server of the recipientthe example is a SIP INVITE hitting the LIR, but honestly any SIP request other than REGISTER (think SUBSCRIBE, OPTIONS, etc.) triggers the same Diameter message 🦋 (A SIP REGISTER request will trigger a Diameter UAR message instead, as shown in Figure 2 and Figure 3.)
this also works if an outbound SIP server doesn't care about authenticating the user but still has to find another SIP server to route outbound SIP requests. In that case, the outbound SIP server gets mapped to SIP server 1 as shown in Figure 5. 🌸
6.6. Update of the User Profile 🧚
okay this one is so cute: the Diameter SIP application lets a Diameter server asynchronously download a user profile to a SIP server whenever that profile gets updated 💖 It must be noted that the Diameter server also attaches the user profile to the Diameter Server-Assignment-Answer (SAA) message. That's fine for most daily situations, but sometimes the administrator wants to update or modify a user's profile, like when new services become available to them 🎀 That can involve stuff outside the scope of this spec, such as human intervention in the Diameter server. In that case, the Diameter server can push the new user profile into the SIP server allocated to the user. 👑
here's how it goes down (see Figure 6). When the user profile changes, the Diameter server sends a Diameter Push-Profile-Request (PPR) message (step 1) to the Diameter client in the SIP server allocated to that user (SIP server 2 in the examples). The PPR message contains one or more SIP-User-Data AVPs, a User-Name AVP, and zero or more SIP-AOR AVPs. Then the Diameter client in SIP server 2 acknowledges the PPR by sending a Diameter Push-Profile-Answer (PPA) message (step 2) back to the Diameter server. 💅
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
+--------+ +--------+
| |
| 1. PPR |
|------------------>|
| |
| 2. PPA |
|<------------------|
| |
Figure 6: Diameter server pushes an update of the user profile6.7. SIP Soft State Termination 🌈
okay so SIP can create soft states in SIP nodes based on stuff like SIP registrations or SIP event subscriptions 🦋 These states get refreshed periodically, and they cease to exist if nobody refreshes them. An administrative action can also terminate a SIP soft state, or the SIP UA can explicitly terminate one itself. ✨
the Diameter base protocol gives you a way to create and delete states in Diameter nodes, and those are called Diameter user sessions 🍓 The Diameter server decides whether to use a Diameter user session to map to a SIP soft state. If it does, terminating a Diameter user session means terminating the matching SIP soft state (like a registration or event subscription), and vice versa. If the Diameter server doesn't use Diameter user sessions, this Diameter SIP application offers specific commands to manage the SIP soft states instead. Implementations compliant with this specification MUST support both mechanisms of session management. 🔥
we support termination started by either the Diameter client or the Diameter server 🫶 Depending on whether Diameter sessions are used, terminating a SIP soft state can happen in one of these ways:
- When the Diameter client (SIP proxy) wants to terminate the SIP soft state and Diameter user sessions are not maintained (i.e., the Auth-Session-State AVP has been previously set to NO_STATE_MAINTAINED), the Diameter client MUST send a Server-Assignment-Request (SAR) message with the SIP-Server-Assignment-Type AVP (Section 9.4) set to any of the deregistration values: TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, USER_DEREGISTRATION_STORE_SERVER_NAME, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA.
- When the Diameter client (SIP proxy) wants to terminate the SIP soft state and Diameter user sessions are maintained (i.e., the Auth-Session-State AVP has been previously set to STATE_MAINTAINED), the Diameter client MUST send a Session-Termination-Request (STR) message as per regular procedures according to RFC 3588 [RFC3588].
- When the Diameter server wants to terminate the SIP soft state and Diameter user sessions are not maintained (i.e., the Auth-Session-State AVP has been previously set to NO_STATE_MAINTAINED), the Diameter server MUST send a Registration-Termination-Request (RTR) message (see Section 8.9).
- When the Diameter server wants to terminate the SIP soft state and Diameter user sessions are maintained (i.e., the Auth-Session-State AVP has been previously set to STATE_MAINTAINED), the Diameter server MUST send an Abort-Session-Request (ASR) message as per regular procedures according to RFC 3588 [RFC3588]. 💜
6.8. Diameter Server Discovery 🧭
okay so the big architecture assumption here is that ALL the data about a user lives in one single Diameter server 💅 and no, that does NOT make it a single point of failure, even though everyone assumes it does 🙅♀️ the idea is that Diameter servers get set up redundantly so one going down doesn't take everybody with it 🫶
now, in big networks with SO many users, you might need to scale out and run more Diameter servers 📈 each user's data still sits in one server (usually a redundant pair or group), but different users can live on different servers 🌸
this scales beautifully, BUT it creates a new puzzle 🧩 given a user's SIP AOR, how do you figure out WHICH Diameter server is holding that user's data? 😭 we borrow inspiration from the Diameter redirection mechanism in RFC 3588 [RFC3588] ✨ so the architecture gets a new Diameter node, which this document calls the Diameter Subscriber Locator (SL) 🦋 the Diameter SL holds a database or routing tables that map SIP AORs to Diameter server URIs. a Diameter server URI points at the actual server holding everything for a given SIP AOR, and therefore for the user who owns that AOR 💖
the Diameter SL acts kind of like a Diameter Redirect Agent, sending requests where they need to go (like handing back the redirection URI in the answer) 🎀 and it can redirect ALL the requests for a user by setting the Redirect-Host-Usage AVP to the value ALL_USER, as specified in RFC 3588 [RFC3588] 💅
the Diameter SL can be replicated across different nodes in the network for scalability and redundancy 🌈 the database or routing tables have to be consistent across every one of those SLs, so that equal Diameter requests get equal Diameter answers, no matter which SL handles the request 🫶 no drama, no mixed signals 💜
+--------+ +--------+ +--------+ +--------+
| SIP | |Diameter| |Diameter| | SIP |
|server 1| |SL red. | |server 1| |server 2|
+--------+ +--------+ +--------+ +--------+
| | | |
1. SIP INVITE| | | |
------------>| 2. LIR | | |
|---------->| | |
| 3. LIA | | |
|<----------| | |
| 4. LIR | |
|---------------------->| |
| 5. LIA | |
|<----------------------| |
| 6. SIP INVITE | |
|----------------------------------->| 7. SIP INVITE
| | | | ------------->
| | | |
Figure 7: Locating a Diameter server. SL redirecting requestsokay so Figure 7 shows a Diameter SL doing its redirect thing 👑 SIP server 1 gets an INVITE (step 1) aimed (in the SIP Request-URI) at a user that the Diameter client in SIP server 1 has NO routing info for 😳 basically, that client doesn't know the URI of Diameter server 1 yet 🙈 so it sends a Diameter LIR message (step 2) to any of the Diameter SLs configured in the network 📨 the addresses of those SLs are assumed to be pre-provisioned in the Diameter client 🧚
the SL looks at the SIP-AOR AVP and its own routing tables and figures out which Diameter server holds that user's info 🔍 then it builds a Diameter LIA message (step 3) with a Result-Code AVP set to DIAMETER_REDIRECT_INDICATION and one Redirect-Host AVP, whose value is the URI of the Diameter server storing that user's information 🦋 next, the Diameter client in SIP server 1 builds a brand new LIR message (step 4) addressed to the Diameter server named in that Redirect-Host AVP 💜 and the rest of the procedure goes exactly as described in the earlier sections ✨
7. Advertising Application Support 📣
okay so Diameter implementations that conform to this spec MUST advertise their support 🫶 they do that by including an Auth-Application-Id AVP in the Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) commands, following the Diameter base protocol in RFC 3588 [RFC3588] 💅 and that Auth-Application-Id AVP MUST be set to the value of this Diameter SIP application (Section 13.1 has the actual value IANA allocated) 🔥
8. Diameter SIP Application Command Codes 🎀
all the Diameter implementations conforming to this spec MUST implement and support the commands listed in Table 1 💖 here's the whole list:
+-------------------------------------+-------+------+--------------+
| Command Name | Abbr. | Code | Reference |
+-------------------------------------+-------+------+--------------+
| User-Authorization-Request | UAR | 283 | Section 8.1 |
| User-Authorization-Answer | UAA | 283 | Section 8.2 |
| Server-Assignment-Request | SAR | 284 | Section 8.3 |
| Server-Assignment-Answer | SAA | 284 | Section 8.4 |
| Location-Info-Request | LIR | 285 | Section 8.5 |
| Location-Info-Answer | LIA | 285 | Section 8.6 |
| Multimedia-Auth-Request | MAR | 286 | Section 8.7 |
| Multimedia-Auth-Answer | MAA | 286 | Section 8.8 |
| Registration-Termination-Request | RTR | 287 | Section 8.9 |
| Registration-Termination-Answer | RTA | 287 | Section 8.10 |
| Push-Profile-Request | PPR | 288 | Section 8.11 |
| Push-Profile-Answer | PPA | 288 | Section 8.12 |
+-------------------------------------+-------+------+--------------+
Table 1: Defined command codesthe sections that define each command include its Message Format 📝 and those formats follow Section 3.2 of RFC 3588 [RFC3588] 🌸
8.1. User-Authorization-Request (UAR) Command 🔑
okay the User-Authorization-Request (UAR) is identified by Command-Code 283 with the Command Flags' 'R' bit set 🦋 the Diameter client in a SIP server sends it to the Diameter server to ask for authorization for the SIP User Agent to route a SIP REGISTER request 📨 a REGISTER request implicitly carries permission to bind an AOR to a contact address, so the Diameter client uses the UAR as a FIRST authorization request to the Diameter server to authorize that registration 🫶 for example, the Diameter server can check that the AOR is a legit user of the realm ✅
the Diameter client in the SIP server asks for authorization for one of the possible values defined in the SIP-User-Authorization-Type AVP (Section 9.10) 💅
the user name used to authenticate the user rides along in a User-Name AVP (defined in the Diameter base protocol, RFC 3588 [RFC3588]) 🎀 where that authentication user name shows up in the SIP REGISTER request depends on the authentication mechanism 🤔 when it's HTTP Digest as defined in RFC 2617 [RFC2617], the user name is in the "username" directive of the SIP Authorization header field value 🔐 and this Diameter SIP application ONLY supports HTTP Digest authentication in SIP for now, so other authentication mechanisms are not currently supported 🙅♀️
the SIP or SIPS URI being registered goes in the SIP-AOR AVP (Section 9.8) 💖 usually that URI is in the To header field value of the SIP REGISTER request that kicked off the Diameter UAR message 🧚
the SIP-Visited-Network-Id AVP says which network is providing SIP services (like SIP proxy functionality or any other kind of service) to the SIP User Agent 🌈
the Message Format of the UAR command looks like this 👇
<UAR> ::= < Diameter Header: 283, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-AOR }
[ Destination-Host ]
[ User-Name ]
[ SIP-Visited-Network-Id ]
[ SIP-User-Authorization-Type ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.2. User-Authorization-Answer (UAA) Command 💅
okay so the UAA is the reply to a UAR 💖 It's identified by Command-Code set to 283, with the Command Flags' 'R' bit cleared (that's how you know it's an answer and not a request 🙈). The Diameter server sends it back after getting a previously received User-Authorization-Request (UAR) command, and it tells the client how the registration authorization went 🎀. Bonus: it can also hand over a set of SIP capabilities so the Diameter client can pick a SIP proxy for the AOR being registered ✨
In addition to the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1. 🌸
Whenever the Diameter server fails to process the Diameter UAR message, it MUST stop processing and return the relevant error in the Diameter UAA message 😭 When the process succeeds, the Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter UAA message 👑
If the Diameter server needs a User-Name AVP value to process the Diameter UAR request, but the UAR message didn't include a User-Name AVP value, the Diameter server MUST set the Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return it in a Diameter UAA message. When the SIP server gets a UAA with that value, it typically asks for authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy Authentication Required) response back to the originator 🔐
When the authorization procedure succeeds, the Diameter server constructs a User-Authorization-Answer (UAA) message that MUST include (1) the address of the SIP server already assigned to the user name, (2) the capabilities needed by the SIP server (Diameter client) to select another SIP server for the user, or (3) a combination of the previous two options 🦋
If the Diameter server already knows about a SIP server allocated to the user, the Diameter UAA message contains the address of that SIP server 🧚
The Diameter UAA message contains the capabilities required by a SIP server to trigger and execute services. It is required that these capabilities are present in the Diameter UAA message, because the Diameter client (in the SIP server) might allocate a different SIP server to trigger and execute services for that particular user 🌈
If a User-Name AVP is present in the Diameter UAR message, then the Diameter server MUST verify the existence of the user in the realm, i.e., the User-Name AVP value is a valid user within that realm 🕵️ If the Diameter server doesn't recognize the user name in the User-Name AVP, it MUST build a Diameter User-Authorization-Answer (UAA) message and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN 💀
If a User-Name AVP is present in the Diameter UAR message, then the Diameter server MUST authorize that the User-Name AVP value is able to register the SIP or SIPS URI included in the SIP-AOR AVP. If this authorization fails, the Diameter server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter User-Authorization-Answer (UAA) message 🙅♀️
Note: Correlation between User-Name and SIP-AOR AVP values is required in order to avoid registration of a SIP-AOR allocated to another user. This one is a big deal, bestie 🚨
If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message, and the SIP-User-Authorization-Type AVP value received in the UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES, then the Diameter server SHOULD verify whether the user is allowed to roam into the network specified in the SIP-Visited-Network-Id AVP. If the user is not allowed to roam into that network, the Diameter AAA server MUST set the Result-Code AVP value in the Diameter UAA message to DIAMETER_ERROR_ROAMING_NOT_ALLOWED ✈️
If the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES, then the Diameter server SHOULD verify whether the SIP-AOR AVP value is authorized to register in the Home Realm. Where the SIP AOR is not authorized to register in the Home Realm, the Diameter server MUST set the Result-Code AVP to DIAMETER_AUTHORIZATION_REJECTED and send it in a Diameter UAA message 🚫
When the SIP-User-Authorization-Type AVP is not present in the Diameter UAR message, or when it is present and its value is set to REGISTRATION, then:
- If the Diameter server isn't aware of any previous registration of the user name (including registrations of other SIP AORs allocated to the same user name), then the Diameter server doesn't know of any SIP server allocated to the user. In this case, the Diameter server MUST set the Result-Code AVP value to
DIAMETER_FIRST_REGISTRATIONin the Diameter UAA message, and the Diameter server SHOULD include the required SIP server capabilities in the SIP-Server-Capabilities AVP value in the Diameter UAA message. The SIP-Server-Capabilities AVP helps the Diameter client (SIP server) select an appropriate SIP server for the user, according to the required capabilities 🥰 - In some cases, the Diameter server is aware of a previously assigned SIP server for the same or different SIP AORs allocated to the same user name. In these cases, re-assignment of a new SIP server may or may not be needed, depending on the capabilities of the SIP server. The Diameter server MUST always include the allocated SIP server URI in the SIP-Server-URI AVP of the UAA message. If the Diameter server does not return the SIP capabilities, the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to
DIAMETER_SUBSEQUENT_REGISTRATION. Otherwise (i.e., if the Diameter server includes a SIP-Server-Capabilities AVP), then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message toDIAMETER_SERVER_SELECTION. Then the Diameter client determines, based on the received information, whether it needs to select a new SIP server 🔄
When the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to REGISTRATION&CAPABILITIES, then Diameter Server MUST return the list of capabilities in the SIP-Server-Capabilities AVP value of the Diameter UAA message, it MUST set the Result-Code to DIAMETER_SUCCESS, and it MUST NOT return a SIP-Server-URI AVP. The SIP-Server-Capabilities AVP lets the SIP server (Diameter client) select another appropriate SIP server for invoking and executing services for the user, depending on the required capabilities. The Diameter server MAY leave the list of capabilities empty to indicate that any SIP server can be selected 🌟
When the SIP-User-Authorization-Type AVP value received in the Diameter UAR message is set to DEREGISTRATION, then:
- If the Diameter server is aware of a SIP server assigned to the SIP AOR under deregistration, the Diameter server MUST set the Result-Code AVP to
DIAMETER_SUCCESSand MUST set the SIP-Server-URI AVP value to the known SIP server, and return them in the Diameter UAA message 👋 - If the Diameter server is not aware of a SIP server assigned to the SIP AOR under deregistration, then the Diameter server MUST set the Result-Code AVP in the Diameter UAA message to
DIAMETER_ERROR_IDENTITY_NOT_REGISTERED🥺
The Message Format of the UAA command looks like this, bestie 🧾
<UAA> ::= < Diameter Header: 283, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-URI ]
[ SIP-Server-Capabilities ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.3. Server-Assignment-Request (SAR) Command ✨
okay so the SAR command is the one with Command-Code set to 284 and the R bit in the Command Flags set 💅. A Diameter client in a SIP server sends it to the Diameter server to say the authentication process is done, and to ask the Diameter server to store the URI of the SIP server that's currently serving the user 🎀. The big jobs are telling the Diameter server which URI is allocated to the user, and storing or clearing that URI on the server. The client can also ask to download the user profile, or just part of it 🧚.
During registration, a SIP server gets assigned to the user 🌸. The Diameter client in that assigned SIP server MUST include its own URI in the SIP-Server-URI AVP of the Server-Assignment-Request (SAR) Diameter message and send it to the Diameter server 🫶. After that, the Diameter server knows which SIP server belongs to the user name, and what that server's URI is. literally the whole point 😭
The Diameter client in the SIP server MAY send a Diameter SAR message for other reasons too 🦋. Those reasons are listed in the SIP-Server-Assignment-Type AVP (Section 9.4) value. For example, the client might ask the Diameter server to deregister a user, tell it about an authentication failure, or just download the user profile 💜. For the full list of SIP-Server-Assignment-Type AVP values, go check Section 9.4 🔥.
Usually, a SIP REGISTER request arriving at a SIP server is what kicks off the Diameter client to send the SAR message ✨. But if the SIP server gets some other SIP request, like an INVITE, and it doesn't have the user profile, the Diameter client can still send a SAR message. That way it can download the profile and let the Diameter server know which SIP server is assigned to the user 🙈.
The user profile is a big deal, ngl 👑. It decides how the SIP server behaves when it's triggering or providing services for the user. It's typically split into these three buckets:
- Services to be rendered to the user when the user is registered and initiates a SIP request.
- Services to be rendered to the user when the user is registered and a SIP request destined to that user arrives to the SIP proxy.
- Services to be rendered to the user when the user is not registered and a SIP request destined to that user arrives to the SIP proxy.
The SIP-Server-Assignment-Type AVP tells the Diameter server why the Diameter client (the SIP server) reached out 🍓. If the client sets it to REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT, AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, then the client MUST include exactly one SIP-AOR AVP in the Diameter SAR message. no exceptions, bestie 🙅♀️
The SAR message MAY contain zero or more SIP-Supported-User-Data-Type AVPs 💖. Each one describes a type of user data the SIP server understands. This lets the Diameter client tell the Diameter server which formats of user data work on its end. The Diameter server then uses that info to pick one or more SIP-User-Data AVPs to put in the SAA message 🌈.
Here's how the message format of the SAR command looks ⭐:
<SAR> ::= < Diameter Header: 284, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-Server-Assignment-Type }
{ SIP-User-Data-Already-Available }
[ Destination-Host ]
[ User-Name ]
[ SIP-Server-URI ]
* [ SIP-Supported-User-Data-Type ]
* [ SIP-AOR ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.4. Server-Assignment-Answer (SAA) Command ✨
okay so the SAA is the one with Command-Code 284 and the 'R' bit cleared 🦋. The Diameter server sends it back as a reply to a SAR it already got, and it can include the user profile (or part of it) if that was requested 💅.
Besides the values already defined in [RFC3588], the Result-Code AVP may contain one of the values defined in Section 10.1.
The Result-Code AVP in the SAA can say whether the SAR worked or hit an error 🔥. If there's no error code, the SAA MAY include one or more SIP-User-Data AVPs, which usually hold the user's profile and show what services the SIP server can provide for that user 🎀.
The Diameter server MAY include one or more SIP-Supported-User-Data-Type AVPs, each one naming a type of user data format the server supports 🧚. If the Diameter client and the server don't have a common supported user data type, the server SHOULD list its supported types by including one or more SIP-Supported-User-Data-Type AVPs in the SAA. This is just for debugging, though, because there's no fallback that lets the client grab the profile in a supported format 🙈.
If the server needs a User-Name AVP value to process the SAR but the SAR didn't include one, the server MUST set the Result-Code AVP to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and send it back in an SAA. When the SIP server gets an SAA with that code, it typically asks for authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy Authentication Required) response to the originator 🔐.
If the User-Name AVP is in the SAR, the server MUST check that the user exists in the realm. That means the User-Name AVP value has to be a valid user in that realm. If the server doesn't recognise the name, it MUST build an SAA and MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN 💀.
Then the server MUST authorise that the User-Name AVP value is a valid authentication name for the SIP or SIPS URI in the SIP-AOR AVP of the SAR. If that check fails, the server must set the Result-Code AVP to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in an SAA.
After a successful SAR, the server MUST clear the "authentication pending" flag and SHOULD move the temporarily stored SIP server URI into permanent storage 🌸.
What the server does next depends on the SIP-Server-Assignment-Type AVP value in the SAR:
- If it's set to REGISTRATION or RE_REGISTRATION, the server SHOULD check that there is only one SIP-AOR AVP. Otherwise, the server MUST answer with an SAA with the Result-Code AVP set to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES, and MUST NOT include any SIP-User-Data AVP. If there's only one SIP-AOR AVP and the SIP-User-Data-Already-Available AVP is set toUSER_DATA_NOT_AVAILABLE, then the server SHOULD include one or more user profile data items with the SIP or SIPS URI (SIP-AOR AVP) and all other SIP identities associated with that AVP in the SIP-User-Data AVP of the SAA. When picking the type of user data, the server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR) and the local policy. The server also MUST set the Result-Code AVP toDIAMETER_SUCCESSin the SAA. The server considers the SIP AOR authenticated and registered 🦋. - If it's set to UNREGISTERED_USER, the server MUST store the SIP server address included in the SIP-Server-URI AVP value. The server will return that SIP server address in Location-Info-Answer (LIA) messages. If the SIP-User-Data-Already-Available AVP is set to
USER_DATA_NOT_AVAILABLE, then the server SHOULD include one or more user profile data items associated with the SIP or SIPS URI (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP of the SAA. When picking the type of user data, the server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR) and the local policy. The server MUST set the Result-Code AVP toDIAMETER_SUCCESS. The server considers the SIP AOR UNREGISTERED, but with a SIP server allocated to trigger and provide services for unregistered users. Also note that for UNREGISTERED_USER (SIP-Server-Assignment-Type AVP), the server MUST check that there is only one SIP-AOR AVP. Otherwise, the server MUST answer the SAR with an SAA, MUST set the Result-Code AVP toDIAMETER_AVP_OCCURS_TOO_MANY_TIMES, and MUST NOT include any SIP-User-Data AVP. If the User-Name AVP was not in the SAR and the SIP-AOR isn't known to the server, the server MUST NOT include a User-Name AVP in the SAA and MUST set the Result-Code AVP toDIAMETER_ERROR_USER_UNKNOWN🙈. - If it's set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION, the server MUST clear the SIP server address associated with all SIP AORs listed in each of the SIP-AOR AVP values in the SAR. The server considers all of these SIP AORs as not registered. The server MUST set the Result-Code AVP to
DIAMETER_SUCCESSin the SAA 🌈. - If it's set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME, the server MAY keep the SIP server address associated with the SIP AORs in the SIP-AOR AVP values of the SAR, even though the SIP AORs become unregistered. This lets a SIP server ask the Diameter server to stay as an assigned SIP server for those SIP AORs (SIP-AOR AVP values) tied to the same user name, so it avoids SIP server assignment 👑. The server MUST consider all these SIP AORs as not registered. If the server honours the client's (SIP server's) request to stay as an allocated SIP server, then the server MUST keep the SIP server assigned to those SIP AORs allocated to the username and MUST set the Result-Code AVP to
DIAMETER_SUCCESSin the SAA. Otherwise, if the server doesn't honour that request, the server MUST clear the SIP server name assigned to those SIP AORs and MUST set the Result-Code AVP toDIAMETER_SUCCESS_SERVER_NAME_NOT_STOREDin the SAA. - If it's set to NO_ASSIGNMENT, the server SHOULD first check that the SIP-Server-URI AVP value in the SAR is the same URI as the one assigned to the SIP-AOR AVP value. If they differ, the server MUST set the Result-Code AVP to
DIAMETER_UNABLE_TO_COMPLYin the SAA. Otherwise, if the SIP-User-Data-Already-Available AVP is set toUSER_DATA_NOT_AVAILABLE, the server SHOULD include the user profile data with the SIP or SIPS URI (SIP-AOR AVP) and all other SIP identities associated with that AVP in the SIP-User-Data AVP of the SAA. When picking the type of user data, the server SHOULD take into account the supported formats at the SIP server (SIP-Supported-User-Data-Type AVP in the SAR) and the local policy 🎀. - If it's set to AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the server MUST check that there is exactly one SIP-AOR AVP in the SAR. If the SIP-AOR AVP doesn't occur exactly once, the server MUST set the Result-Code AVP to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMESin the SAA, and SHOULD not take further actions. If there is exactly one SIP-AOR AVP in the SAR, the server MUST clear the address of the SIP server assigned to the SIP AOR allocated to the user name, and MUST set the Result-Code AVP toDIAMETER_SUCCESSin the SAA. The server MUST consider the SIP AOR as not registered 🥀.
The message format of the SAA command looks like this:
<SAA> ::= < Diameter Header: 284, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
* [ SIP-User-Data ]
[ SIP-Accounting-Information ]
* [ SIP-Supported-User-Data-Type ]
[ User-Name ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.5. Location-Info-Request (LIR) Command 📍
The Location-Info-Request (LIR) has Command-Code 285 and the Command Flags' 'R' bit set 💖. The Diameter client in a SIP server sends it to the Diameter server to ask for routing info, like the URI of the SIP server assigned to the SIP-AOR AVP value for the users 🧚.
The message format of the LIR command looks like this:
<LIR> ::= < Diameter Header: 285, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-AOR }
[ Destination-Host ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.6. Location-Info-Answer (LIA) Command ✨
okay so the LIA is the reply to an LIR 💅 It's identified by Command-Code 285 with the Command Flags' 'R' bit cleared (so it's an answer, not a request). The Diameter server sends it back after getting a previous Diameter Location-Info-Request (LIR) command.
Besides the values already defined in RFC 3588 [RFC3588], the Result-Code AVP can hold one of the values from Section 10.1 🎀 If the Diameter server hits an error while processing the LIR, it MUST stop processing the message and reply with an LIA that has the right error code in the Result-Code AVP 😭 If there's no error, it MUST set the Result-Code AVP to DIAMETER_SUCCESS in the LIA ✅
One error the server might find is that the SIP-AOR AVP value isn't a valid user in the realm. In that case, the server MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN and send it back in an LIA 🙈
If the server can't process the LIR, like because of a database error, it MUST set the Result-Code AVP to DIAMETER_UNABLE_TO_COMPLY and return it in an LIA. And it MUST NOT include any SIP-Server-URI or SIP-Server-Capabilities AVP in that LIA. no sneaking those in 🚫
The server may or may not know about a SIP server assigned to the SIP-AOR AVP value in the LIR. If it does know about a SIP server allocated to that user, it MUST put that server's URI in the SIP-Server-URI AVP and return it in an LIA 💜 This is usually the case when the user is registered, or unregistered but still has a SIP server assigned.
When the server doesn't know about any SIP server allocated to the user (usually because the user unregistered), the Result-Code AVP in the LIA depends on whether the server knows the user has services defined for unregistered users:
- Users with services defined for unregistered users might need a SIP server allocated so those services can be triggered and maybe run. So when the server isn't aware of an assigned SIP server but the user has these services, it MUST set the Result-Code AVP to
DIAMETER_UNREGISTERED_SERVICEand return it in an LIA. It MAY also include a SIP-Server-Capabilities AVP to help the SIP server (Diameter client) pick a SIP server with the required capabilities. If there's no SIP-Server-Capabilities AVP, that tells the SIP server (Diameter client) that any SIP server is suitable for the user 🧚 - Users without services defined for unregistered users don't need any further processing. The server MUST set the Result-Code AVP to
DIAMETER_ERROR_IDENTITY_NOT_REGISTEREDand return it to the Diameter client in an LIA. The SIP server (Diameter client) may then send the appropriate SIP response (e.g., 480 (Temporarily unavailable)) to the original SIP request 💀
The Message Format of the LIA command is as follows:
<LIA> ::= < Diameter Header: 285, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ SIP-Server-URI ]
[ SIP-Server-Capabilities ]
[ Auth-Grace-Period ]
[ Authorization-Lifetime ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.7. Multimedia-Auth-Request (MAR) Command 🦋
okay the MAR is Command-Code 286 with the Command Flags' 'R' bit set, so it's a request! The Diameter client in a SIP server sends it to the Diameter server to ask that the Diameter server authenticate and authorize a user trying to use some SIP service. And "SIP service" can be something as simple as a SIP subscription or using the proxy services for a SIP request 💖
The MAR command may also register the SIP server's own URI with the Diameter server, so future LIR/LIA messages can return this URI 🌸 If the SIP server is acting as a SIP registrar (see examples in Sections 6.2 and 6.3), its Diameter client MUST include a SIP-Server-URI AVP in the MAR command. In any other case (see example in Section 6.4), its Diameter client MUST NOT include a SIP-Server-URI AVP in the MAR command 🙅
The SIP-Method AVP MUST include the SIP method name of the SIP request that triggered this Diameter MAR message. The Diameter server can use this AVP to authorize some SIP requests depending on the method 🔥
The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP indicates the target of the SIP request, and its value gets pulled from different places in the SIP request depending on what the request means. For SIP REGISTER messages, the SIP-AOR AVP value is the intended public user identity under registration. That's the SIP or SIPS URI in the To header field value (addr-spec as per RFC 3261 [RFC3261]) of the REGISTER request. For other types of SIP requests, like INVITE, SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value is the intended destination of the request, typically found in the Request-URI. Grabbing the SIP-AOR AVP value from the proper SIP header field is the Diameter client's responsibility. Extensions to SIP (new SIP methods or new semantics) may need the SIP-AOR pulled from other parts of the request 🌈
If the SIP request includes some sort of authentication information, the Diameter client MUST include the user name, extracted from that authentication information, in the User-Name AVP value 🫶
The Message Format of the MAR command is as follows:
<MAR> ::= < Diameter Header: 286, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ SIP-AOR }
{ SIP-Method }
[ Destination-Host ]
[ User-Name ]
[ SIP-Server-URI ]
[ SIP-Number-Auth-Items ]
[ SIP-Auth-Data-Item ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.8. Multimedia-Auth-Answer (MAA) Command 💅
Okay so the MAA is the answer bestie 🎀 It's identified by Command-Code set to 286 with the Command Flags' 'R' bit cleared. The Diameter server sends this back in response to a Multimedia-Auth-Request (MAR) it got earlier. 🦋
Besides the values already defined in [RFC3588], the Result-Code AVP can hold one of the values from Section 10.1 ✨
If the Diameter server needs a User-Name AVP value to process the MAR, but the MAR didn't have one, the server MUST set Result-Code to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and send it back in a MAA message. The server MAY also include a SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs with auth info (like a challenge) 🔐 When the SIP server gets a MAA with DIAMETER_USER_NAME_REQUIRED, it typically asks for authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy Authentication Required) response back to the originator. Super iconic, no cap 💖
If the User-Name AVP is in the MAR, the server MUST check that the user exists in the realm, meaning the User-Name value is a valid user in that realm 👀 If the server doesn't recognise the user name, it MUST build a MAA and MUST set Result-Code to DIAMETER_ERROR_USER_UNKNOWN. Not me being like "who dis" 💀
If the SIP-Methods AVP in the MAR is set to REGISTER and a User-Name AVP is there, the server MUST check that the User-Name value is allowed to use the URI in the SIP-AOR AVP. If that check fails, the server must set Result-Code to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a MAA message 🙈
Note: MatchingUser-NameagainstSIP-AORis only needed for SIP REGISTER requests, so that one user can't register a SIP-AOR that belongs to someone else. For other SIP requests (like INVITE), the SIP-AOR shows where the request is going, not who sent it. 🧚
The server MUST check whether the authentication scheme (the SIP-Authentication-Scheme AVP value) in the grouped SIP-Auth-Data-Item AVP is supported. If it isn't, the server MUST set Result-Code to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send it in a MAA message 🚫
If the MAR has a SIP-Number-Auth-Items AVP, that tells you how many auth data items the Diameter client wants. It is RECOMMENDED that the server, when building the MAA, includes a number of SIP-Auth-Data-Item AVPs that is a subset of the items the client asked for in that SIP-Number-Auth-Items value ✨
If the MAR has a SIP-Server-URI AVP, the server MUST compare the SIP server stored for the user with the SIP-Server-URI value from the MAR. If they don't match, the server MUST temporarily save the newly received SIP server assigned to the user and MUST set an "authentication pending" flag for the user. If they match, the server shall clear the "authentication pending" flag for the user 🌸
In any other case, if the MAR was processed successfully and the server stored the SIP-Server-URI, the server MUST set Result-Code to DIAMETER_SUCCESS and send it in a MAA message 🎉
If the MAR was processed successfully but the server didn't store the SIP-Server-URI (because the AVP wasn't in the MAR), then the server MUST set Result-Code to either:
DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the server is sending auth credentials to create a challenge.DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the server successfully authenticated the user and okayed the SIP server to carry on with the SIP request. 🍓
Otherwise, the server MUST set Result-Code to DIAMETER_UNABLE_TO_COMPLY, and it MUST NOT include any SIP-Auth-Data-Item AVP. Big "no" energy there 😭
The MAA message format goes like this 💜
<MAA> ::= < Diameter Header: 286, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ SIP-AOR ]
[ SIP-Number-Auth-Items ]
* [ SIP-Auth-Data-Item ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.9. Registration-Termination-Request (RTR) Command 🌈
The Registration-Termination-Request (RTR) command is identified by Command-Code set to 287 with the Command Flags' 'R' bit set. The Diameter server sends this to the Diameter client in a SIP server to tell the SIP server that one or more SIP AORs need to be deregistered. It's how an operator can administratively cancel a user's registration from a centralised Diameter server, which is giving main character energy 👑
The Diameter server can start deregistering a user and tell the SIP server about it with the RTR. The server gets to decide whether it's just one SIP AOR, a list of SIP AORs, or every SIP AOR allocated to the user ✨
No SIP-AOR AVP in the RTR means that all the SIP AORs allocated to the user named in the User-Name AVP are being deregistered. Total clean-slate vibes 🧹
The Diameter server MUST include a SIP-Deregistration-Reason AVP value to show why the deregistration is happening 📝
The RTR message format goes like this 🦋
<RTR> ::= < Diameter Header: 287, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ SIP-Deregistration-Reason }
[ Destination-Realm ]
[ User-Name ]
* [ SIP-AOR ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.10. Registration-Termination-Answer (RTA) Command 💖
The Registration-Termination-Answer (RTA) is identified by Command-Code set to 287 with the Command Flags' 'R' bit cleared. The Diameter client sends this back in response to an RTR it got earlier 🫶
Besides the values already defined in [RFC3588], the Result-Code AVP can hold one of the values from Section 10.1 🎀
If the SIP server (the Diameter client) needs a User-Name AVP value to process the RTR, but the RTR didn't have one, the client MUST set Result-Code to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and send it back in an RTA message 🙈
The SIP server (the Diameter client) applies the administrative deregistration to every URI in each of the SIP-AOR AVP values. If the RTR has no SIP-AOR AVP, it applies it to all the URIs allocated to the User-Name AVP value 🧚
The SIP-Deregistration-Reason AVP value in the RTR changes what the SIP server (the Diameter client) does 👀
- If the value is set to
PERMANENT_TERMINATION, then the user has ended their registration to the realm. If telling the interested parties (for example, subscribers to the "reg" event [RFC3680]) about the administrative deregistration is supported through SIP procedures, the SIP server (Diameter client) will do it. The Diameter Client in the SIP Server SHOULD NOT request a new user registration. The SIP server clears the registration state of the deregistered AORs. 🚪 - If the value is set to
NEW_SIP_SERVER_ASSIGNED, the Diameter server tells the SIP server (Diameter client) that a new SIP server has been allocated to the user, for some reason. If SIP procedures support it, the SIP server will tell the interested parties (for example, subscribers to the "reg" event [RFC3680]) about the administrative deregistration at this SIP server. The Diameter client in the SIP server SHOULD NOT request a new user registration. The SIP server clears the registration state of the deregistered SIP AORs. 🔁 - If the value is set to
SIP_SERVER_CHANGE, the Diameter server tells the SIP server (Diameter client) that a new SIP server has to be allocated to the user, for example because the user's capabilities need a new SIP server, or the current SIP server doesn't have enough resources. If telling the interested parties about the administrative deregistration is supported through SIP procedures (for example, subscriptions to the "reg" event [RFC3680]), the SIP server will do it. The Diameter client in the SIP Server SHOULD NOT request a new user registration. The SIP server clears the registration state of the deregistered SIP AORs. 🌸 - If the value is set to
REMOVE_SIP_SERVER, the Diameter server tells the SIP server (Diameter client) that the SIP server will no longer be bound to that user in the Diameter server. The SIP server can delete all the data related to the user. 🗑️
The RTA message format goes like this 🍓
<RTA> ::= < Diameter Header: 287, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.11. Push-Profile-Request (PPR) Command 💌
okay so the PPR command is the one with Command-Code 288 and the 'R' bit set in the Command Flags 🎀 The Diameter server sends it to the Diameter client sitting in a SIP server, to update either the user profile of someone already registered in that SIP server, or the SIP accounting information. That means an operator can change a user's data and push it straight to the SIP server where that user is registered 🚀
Every user has a user profile attached to them, plus other accounting info 💅 And that stuff can change over time, like when new services get added to the user. When the profile or accounting info changes, the Diameter server sends a PPR to the Diameter client in a SIP server so those new services can actually start getting applied ✨
A PPR MAY contain a SIP-Accounting-Information AVP that updates the addresses of the accounting servers. These changes take effect immediately ⚡ The Diameter client SHOULD close any existing accounting session with the existing server and start sending accounting info to the newly acquired accounting server 🫶
A PPR MAY contain zero or more SIP-User-Data AVP values holding the new user profile. When picking the type of user data, the Diameter server SHOULD take into account the formats the SIP server supports (the SIP-Supported-User-Data-Type AVP that was sent in an earlier SAR message) and the local policy 🧚
The User-Name AVP tells you which user the profile applies to 🌸
Here's the message format of the PPR command:
<PPR> ::= < Diameter Header: 288, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ User-Name }
* [ SIP-User-Data ]
[ SIP-Accounting-Information ]
[ Destination-Host ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]8.12. Push-Profile-Answer (PPA) Command 🦋
the PPA is Command-Code 288 with the 'R' bit cleared, and it's the response the Diameter client sends back to a PPR it got earlier 💖
Besides the values already defined in RFC 3588 [RFC3588], the Result-Code AVP may hold one of the values from Section 10.1 ✨
if the PPR processes with no error, the SIP server (the Diameter client) MUST download the user profile from the SIP-User-Data AVP values in the PPR, and store it linked to the user named in the User-Name AVP value. no cap, this is the main event 👑
if the SIP server doesn't recognise or support some of the data in the SIP-User-Data AVP values, the Diameter client in that SIP server MUST send back a PPA with the Result-Code AVP set to DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA 💀
if the SIP server (the Diameter client) gets a PPR with a User-Name AVP it doesn't know, the Diameter client MUST set the Result-Code AVP to DIAMETER_ERROR_USER_UNKNOWN and MUST return it to the Diameter server in a PPA 🙈
if the SIP server (the Diameter client) gets more data in the SIP-User-Data-Content AVP value (inside the grouped SIP-User-Data AVP) than it can accept, it MUST set the Result-Code AVP to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter server in a PPA. And the SIP server MUST NOT override the existing user profile with the one from the PPR message 🔥
if the Diameter server gets a Result-Code of DIAMETER_ERROR_TOO_MUCH_DATA in a PPA, it SHOULD force a fresh re-registration of the user. It does this by sending the Diameter client a Registration-Termination-Request (RTR) with the SIP-Deregistration-Reason AVP set to SIP_SERVER_CHANGE. That forces the re-registration and triggers the selection of a new SIP server 🌈
if the Diameter client can't honour the command for any other reason, it MUST set the Result-Code AVP to DIAMETER_UNABLE_TO_COMPLY and MUST return it in a PPA message 🍓
Here's the message format of the PPA command:
<PPA> ::= < Diameter Header: 288, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]9. Diameter SIP Application AVPs 🎀
this section defines the new AVPs used in this Diameter SIP application. Applications that follow this spec MUST implement these AVPs, no exceptions 🫶
Table 2 lists every new AVP in this Diameter SIP application. Here's what the Data-Type abbreviations mean:
- DURI: DiameterURI
- E: Enumerated
- G: Grouped
- OS: OctetString
- UTF8S: UTF8String
- U32: Unsigned32
+-----------------------------------+------+----------------+-------+
| Attribute Name | AVP | Reference | Data- |
| | Code | | Type |
+-----------------------------------+------+----------------+-------+
| SIP-Accounting-Information | 368 | Section 9.1 | G |
| SIP-Accounting-Server-URI | 369 | Section 9.1.1 | DURI |
| SIP-Credit-Control-Server-URI | 370 | Section 9.1.2 | DURI |
| SIP-Server-URI | 371 | Section 9.2 | UTF8S |
| SIP-Server-Capabilities | 372 | Section 9.3 | G |
| SIP-Mandatory-Capability | 373 | Section 9.3.1 | U32 |
| SIP-Optional-Capability | 374 | Section 9.3.2 | U32 |
| SIP-Server-Assignment-Type | 375 | Section 9.4 | E |
| SIP-Auth-Data-Item | 376 | Section 9.5 | G |
| SIP-Authentication-Scheme | 377 | Section 9.5.1 | E |
| SIP-Item-Number | 378 | Section 9.5.2 | U32 |
| SIP-Authenticate | 379 | Section 9.5.3 | G |
| SIP-Authorization | 380 | Section 9.5.4 | G |
| SIP-Authentication-Info | 381 | Section 9.5.5 | G |
| SIP-Number-Auth-Items | 382 | Section 9.6 | U32 |
| SIP-Deregistration-Reason | 383 | Section 9.7 | G |
| SIP-Reason-Code | 384 | Section 9.7.1 | E |
| SIP-Reason-Info | 385 | Section 9.7.2 | UTF8S |
| SIP-Visited-Network-Id | 386 | Section 9.9 | UTF8S |
| SIP-User-Authorization-Type | 387 | Section 9.10 | E |
| SIP-Supported-User-Data-Type | 388 | Section 9.11 | UTF8S |
| SIP-User-Data | 389 | Section 9.12 | G |
| SIP-User-Data-Type | 390 | Section 9.12.1 | UTF8S |
| SIP-User-Data-Contents | 391 | Section 9.12.2 | OS |
| SIP-User-Data-Already-Available | 392 | Section 9.13 | E |
| SIP-Method | 393 | Section 9.14 | UTF8S |
+-----------------------------------+------+----------------+-------+
Table 2: Defined AVPsTable 3 expands the table of AVPs from Section 4.5 of RFC 3588 [RFC3588] ✨ It shows the Diameter AVPs defined in this Diameter SIP Application, their possible flag values, and whether each AVP may be encrypted. The 'M', 'P', and 'V' acronyms are AVP flags whose meanings are explained in RFC 3588 [RFC3588], and so is the 'Encr' column 💜
+----------------------------------+------+-----+-----+------+------+
| Attribute Name | MUST | MAY | SHD | MUST | Encr |
| | | | NOT | NOT | |
+----------------------------------+------+-----+-----+------+------+
| SIP-Accounting-Information | M | P | | V | N |
| SIP-Accounting-Server-URI | M | P | | V | N |
| SIP-Credit-Control-Server-URI | M | P | | V | N |
| SIP-Server-URI | M | P | | V | N |
| SIP-Server-Capabilities | M | P | | V | N |
| SIP-Mandatory-Capability | M | P | | V | N |
| SIP-Optional-Capability | M | P | | V | N |
| SIP-Server-Assignment-Type | M | P | | V | N |
| SIP-Auth-Data-Item | M | P | | V | N |
| SIP-Authentication-Scheme | M | P | | V | N |
| SIP-Item-Number | M | P | | V | N |
| SIP-Authenticate | M | P | | V | N |
| SIP-Authorization | M | P | | V | N |
| SIP-Authentication-Info | M | P | | V | N |
| SIP-Number-Auth-Items | M | P | | V | N |
| SIP-Deregistration-Reason | M | P | | V | N |
| SIP-Reason-Code | M | P | | V | N |
| SIP-Reason-Info | M | P | | V | N |
| SIP-Visited-Network-Id | M | P | | V | N |
| SIP-User-Authorization-Type | M | P | | V | N |
| SIP-Supported-User-Data-Type | M | P | | V | N |
| SIP-User-Data | M | P | | V | N |
| SIP-User-Data-Type | M | P | | V | N |
| SIP-User-Data-Contents | M | P | | V | N |
| SIP-User-Data-Already-Available | M | P | | V | N |
| SIP-Method | M | P | | V | N |
+----------------------------------+------+-----+-----+------+------+
Table 3: Summary of the new AVPs flags9.1. SIP-Accounting-Information AVP 🧾
the SIP-Accounting-Information AVP (AVP Code 368) is Grouped, and it holds the Diameter addresses of the nodes that can collect accounting info 💅
It's defined like this (following the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Accounting-Information ::= < AVP Header: 368 >
* [ SIP-Accounting-Server-URI ]
* [ SIP-Credit-Control-Server-URI ]
* [ AVP]9.1.1. SIP-Accounting-Server-URI AVP 📡
the SIP-Accounting-Server-URI AVP (AVP Code 369) is DiameterURI. It contains the address of a Diameter server that can receive SIP-session-related accounting info 🦋
9.1.2. SIP-Credit-Control-Server-URI AVP 💳
the SIP-Credit-Control-Server-URI AVP (AVP Code 370) is DiameterURI. It contains the address of a Diameter server that can authorise real-time credit control usage. The Diameter Credit-Control Application [RFC4006] may be used for this purpose 🌟
9.2. SIP-Server-URI AVP ✨
Okay, so the SIP-Server-URI AVP (AVP Code 371) is a UTF8String 💖 and it holds a SIP or SIPS URI (as defined in [RFC3261]) that identifies a SIP server. Simple, but iconic 🫶
9.3. SIP-Server-Capabilities AVP 🎀
The SIP-Server-Capabilities AVP (AVP Code 372) is Grouped 🧺 and it's how Diameter spells out the requirements for a specific SIP capability, so the Diameter client (SIP server) can pick a different, suitable SIP server to serve the user. Main character energy 👑
This AVP lets a Diameter client (SIP server) choose another SIP server for triggering or running services for the user. A user might have turned on services that need certain features in whichever SIP server triggers or runs them. For example, that server might need to support SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880], or some other kind of capability. Or maybe the user is in a premium group with a really strict quality-of-service deal that calls for a fast SIP server 🚀 The capabilities required or recommended for a given user are carried in the SIP-Server-Capabilities AVP. When the Diameter client (SIP server) that does the selecting gets them, it needs a way to find out which available SIP servers meet the required or optional capabilities. Those methods are outside the scope of this specification 🙈
Note that this AVP helps the Diameter client (SIP server) narrow all the available SIP servers down to a subset that can be given to the user in the Home Realm. That subset is the group that matches the per-user capability requirements. It'll usually have more than one SIP server in it, so after identifying that subset there may be several instances of those servers. In that case, the Diameter client (SIP server) SHOULD choose one particular SIP server to run and trigger services for this user. At that point, the SIP server (Diameter client) is expected to follow the procedures of [RFC3263] to allocate one SIP server to the user 🦋
The SIP-Server-Capabilities AVP is defined like this (using the grouped-avp-def of [RFC3588]):
SIP-Server-Capabilities ::= < AVP Header: 372 >
* [ SIP-Mandatory-Capability ]
* [ SIP-Optional-Capability ]
* [ SIP-Server-URI ]
* [ AVP ]9.3.1. SIP-Mandatory-Capability AVP 🧩
The SIP-Mandatory-Capability AVP (AVP Code 373) is Unsigned32. Its value stands for a certain capability (or set of capabilities) that the SIP server allocated to the user has to fulfill.
What each value means isn't standardized. It's up to the administrative network to decide its own meanings inside its own network. Each value has to represent a single capability within that administrative network 🌸
9.3.2. SIP-Optional-Capability AVP 🌷
The SIP-Optional-Capability AVP (AVP Code 374) is Unsigned32. Its value stands for a certain capability (or set of capabilities) that the SIP server allocated to the user may, but doesn't have to, fulfill.
Same deal as before: the meanings aren't standardized, since each administrative network gets to define its own semantics inside its own network. Each value has to represent a single capability within the administrative network 💅
9.4. SIP-Server-Assignment-Type AVP 🦋
The SIP-Server-Assignment-Type AVP (AVP Code 375) is Enumerated. It tells you what kind of server update is happening in a Diameter Server-Assignment-Request (SAR) operation. These values are defined:
NO_ASSIGNMENT (0): The Diameter client uses this value to ask for the user profile of a SIP AOR without touching the registration state of that identity.REGISTRATION (1): First SIP registration of a SIP AOR.RE_REGISTRATION (2): Subsequent SIP registration of a SIP AOR.UNREGISTERED_USER (3): The SIP server has received a SIP request (e.g., SIP INVITE) addressed to a SIP AOR that is not registered.TIMEOUT_DEREGISTRATION (4): The SIP registration timer of an identity has expired.USER_DEREGISTRATION (5): The SIP server has received a request to deregister a SIP AOR.TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6): The SIP registration timer of an identity has expired. The SIP server keeps the user data stored and asks the Diameter server to store the SIP server address.USER_DEREGISTRATION_STORE_SERVER_NAME (7): The SIP server has received a user-initiated deregistration request. The SIP server keeps the user data stored and asks the Diameter server to store the SIP server address.ADMINISTRATIVE_DEREGISTRATION (8): The SIP server, for administrative reasons, has deregistered a SIP AOR.AUTHENTICATION_FAILURE (9): The authentication of a user has failed.AUTHENTICATION_TIMEOUT (10): The authentication timer has expired.DEREGISTRATION_TOO_MUCH_DATA (11): The SIP server has asked the Diameter server for user profile information and received more data than it can accept.
9.5. SIP-Auth-Data-Item AVP 🔐
The SIP-Auth-Data-Item (AVP Code 376) is Grouped and holds the authentication and/or authorization information for a user 🪪
When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to include a SIP-Authenticate AVP, the Diameter server MUST send a maximum of one authentication data item (for example, even if the SIP request contained several credentials). Section 11 has a detailed discussion and normative text on the case where a SIP request contains several credentials 👀
The SIP-Auth-Data-Item AVP is defined like this (using the grouped-avp-def of [RFC3588]):
SIP-Auth-Data-Item ::= < AVP Header: 376 >
{ SIP-Authentication-Scheme }
[ SIP-Item-Number ]
[ SIP-Authenticate ]
[ SIP-Authorization ]
[ SIP-Authentication-Info ]
* [ AVP ]9.5.1. SIP-Authentication-Scheme AVP 🗝️
The SIP-Authentication-Scheme AVP (AVP Code 377) is Enumerated and shows which authentication scheme was used to authenticate SIP services. [RFC2617] calls this value an "auth-scheme" (see Section 1.2 of [RFC2617]). The only value defined so far is:
DIGEST (0): HTTP Digest authentication as specified in [RFC2617] Section 3.2.1. Derivative work also counts as the Digest authentication scheme, as long as the "auth-scheme" is identified as Digest in the SIP headers carrying the HTTP authentication. This includes, e.g., the HTTP Digest authentication using AKA [RFC3310].
Each HTTP Digest directive (parameter) gets carried in its own AVP, and the name of that AVP follows the pattern Digest-*. The Digest-* AVPs are RADIUS attributes imported from the RADIUS Extension for Digest Authentication [RFC4590] namespace, which makes it a smooth transition between RADIUS and Diameter applications that support SIP 🌈 The Diameter SIP application goes a step further by grouping the Digest-* AVPs into the SIP-Authenticate, SIP-Authorization, and SIP-Authentication-Info grouped AVPs. Those correspond to the SIP WWW-Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization, and Authentication-Info header fields, respectively.
Note: Because HTTP Digest authentication [RFC2617] is the only mandatory authentication mechanism in SIP, this memo only provides support for HTTP Digest authentication and derivative work such as HTTP Digest authentication using AKA [RFC3310]. Extensions to this memo can register new values and new AVPs to provide support for other authentication schemes or extensions to HTTP Digest authentication. Note: Although [RFC2617] defines the Basic and Digest schemes for authenticating HTTP requests, [RFC3261] only imports HTTP Digest as a mechanism to provide authentication in SIP.
Because of syntax rules, HTTP Digest authentication has to escape quote characters in the contents of HTTP Digest directives. When translating directives into Digest-* AVPs, the Diameter client or server removes the surrounding quotes where present, as the syntax of the Digest-* attributes defined in the "RADIUS Extension for Digest Authentication" [RFC4590] requires 📏
9.5.2. SIP-Item-Number AVP 🔢
The SIP-Item-Number (AVP Code 378) is Unsigned32. It's included in a SIP-Auth-Data-Item grouped AVP when there are multiple SIP-Auth-Data-Item AVPs and the order of processing matters. The AVP shows the order in which the Grouped SIP-Auth-Data-Item should be processed. Lower values of the SIP-Item-Number AVP mean that the whole SIP-Auth-Data-Item SHOULD be processed before other SIP-Auth-Data-Item AVPs with higher values in the SIP-Item-Number AVP 🏁
9.5.3. SIP-Authenticate AVP 📨
The SIP-Authenticate AVP (AVP Code 379) is Grouped and contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in [RFC2617] for the HTTP Digest authentication scheme. The AVP may also include a Digest-HA1 AVP that holds H(A1) (as defined in [RFC2617]). H(A1) lets the Diameter client create an expected response and compare it with the Digest response received from the SIP UA 🔍
The SIP-Authenticate AVP is defined like this (using the grouped-avp-def of [RFC3588]):
SIP-Authenticate ::= < AVP Header: 379 >
{ Digest-Realm }
{ Digest-Nonce }
[ Digest-Domain ]
[ Digest-Opaque ]
[ Digest-Stale ]
[ Digest-Algorithm ]
[ Digest-QoP ]
[ Digest-HA1]
* [ Digest-Auth-Param ]
* [ AVP ]9.5.4. SIP-Authorization AVP 🪄
The SIP-Authorization AVP (AVP Code 380) is Grouped and contains a reconstruction of either the SIP Authorization or Proxy-Authorization header fields specified in [RFC2617] for the HTTP Digest authentication scheme.
The SIP-Authorization AVP is defined like this (using the grouped-avp-def of [RFC3588]):
SIP-Authorization ::= < AVP Header: 380 >
{ Digest-Username }
{ Digest-Realm }
{ Digest-Nonce }
{ Digest-URI }
{ Digest-Response }
[ Digest-Algorithm ]
[ Digest-CNonce ]
[ Digest-Opaque ]
[ Digest-QoP ]
[ Digest-Nonce-Count ]
[ Digest-Method]
[ Digest-Entity-Body-Hash ]
* [ Digest-Auth-Param ]
* [ AVP ]9.5.5. SIP-Authentication-Info AVP ✨
okay so the SIP-Authentication-Info AVP (AVP Code 381) is a Grouped AVP, and it's basically a rebuilt copy of the SIP Authentication-Info header from RFC 2617 [RFC2617] for the HTTP Digest auth scheme 💅 It's giving "the header, but make it Diameter."
The grouped-avp-def is from RFC 3588 [RFC3588], and this is how it's laid out:
SIP-Authentication-Info ::= < AVP Header: 381 >
[ Digest-Nextnonce ]
[ Digest-QoP ]
[ Digest-Response-Auth ]
[ Digest-CNonce ]
[ Digest-Nonce-Count ]
* [ AVP ]ngl this part is kinda plot twisty 🙈 In some cases the Digest-Response-Auth AVP can't be calculated at the Diameter server. It has to be figured out at the Diameter client (the SIP server) instead. Like, if Digest's qop is set to "auth-int", then the response-digest (the rspauth parameter) is calculated with a hash of the SIP response body, and the Diameter server doesn't have that body. So the Diameter client (SIP server) has to calculate the response-digest once the body of the SIP response exists. Main character energy for the SIP server, honestly 👑
So, a value of "auth-int" in the Digest-QoP AVP of the SIP-Authentication-Info AVP means the Diameter client (SIP server) MUST compute the Digest "rspauth" parameter value at the Diameter client (SIP server). No skipping that step bestie 🫶
9.5.6. Digest AVPs
these are the RADIUS attributes from the RADIUS Extension for Digest Authentication [RFC4590] that this spec borrows 🎀 The imported ones are: Digest-AKA-Auts, Digest-Algorithm, Digest-Auth-Param, Digest-CNonce, Digest-Domain, Digest-Entity-Body-Hash, Digest-HA1, Digest-Method, Digest-Nextnonce, Digest-Nonce, Digest-Nonce-Count, Digest-Opaque, Digest-QoP, Digest-Realm, Digest-Response, Digest-Response-Auth, Digest-URI, Digest-Username, and Digest-Stale.
9.5.6.1. Considerations about Digest-HA1 AVP
the Digest-HA1 AVP holds H(A1), as defined in RFC 2617 [RFC2617], and the Diameter server works it out ahead of time 🧚 The Diameter client can use H(A1) to calculate the expected Digest response for that challenge. If the SIP UA has the credentials, the expected response it calculates and the response the SIP UA sends will match. The Diameter server MAY include this AVP to enable and assist the SIP server in authenticating the SIP UA.
this doesn't work if the Diameter server is set up to use the session MD5 (MD5-sess) algorithm 💀 The reason is that the Diameter server needs the client nonce to compute H(A1) before it sends it to the Diameter client, and the client nonce might not be around yet when that computation happens. So if the final authentication is handed off to the Diameter client, it is RECOMMENDED to configure the Diameter server to use algorithms other than MD5-sess in HTTP Digest. Pick a different algo, periodt ✨
It's up to the Diameter server whether it includes a Digest-HA1 AVP. The Diameter server calculates the Digest H(A1) using the username, password, and realm (and nonce and cnonce, if they apply) as inputs, then puts the result in the Digest-HA1 AVP value. If you want the nitty-gritty on the A1 computation, check RFC 2617 [RFC2617] Section 3.2.2.2. The Diameter client can then calculate the Digest expected response using H(A1) as input, as described in RFC 2617 [RFC2617] Section 3.2.2.
Section 11 has more normative details about using the Digest-HA1 AVP 📖
9.5.6.2. Considerations about Digest-Entity-Body-Hash AVP
the Digest-Entity-Body-Hash AVP carries a hash of the entity body in the SIP message 🍓 HTTP Digest needs this hash when quality of protection is set to "auth-int". Diameter clients MUST use this AVP to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the Diameter server needs to verify the integrity of the entity body (for example, when the qop parameter is set to "auth-int"). No ghosting the integrity check 😭
The clarifications in Section 22.4 of RFC 3261 [RFC3261] about hashes of empty entity bodies also apply to the Digest-Entity-Body-Hash AVP.
9.5.6.3. Considerations about Digest-Auth-Param AVP
the Digest-Auth-Param AVP is how the Diameter client and Diameter server swap extension parameters that show up in Digest headers, but that the Diameter client doesn't understand or that don't have their own stand-alone AVPs 🦋 Unlike the other Digest-* AVPs listed earlier, Digest-Auth-Param carries the parameter name as well as the value, since the Diameter client doesn't know what the parameter is. The Diameter node MUST insert one Digest parameter/value combination per AVP value. If the Digest header has several unknown parameters, the Diameter implementation MUST repeat this AVP, and each instance MUST contain a different unknown Digest parameter/value combination. This AVP matches the "auth-param" parameter defined in Section 3.2.1 of RFC 2617 [RFC2617].
Example: say the Diameter server wants the SIP server to send a foo parameter with the value bar, so the SIP server puts foo="bar" in a SIP WWW-Authenticate header field 🌈 The Diameter server builds a grouped SIP-Authenticate AVP that contains a Digest-Auth-Param whose value is foo="bar". Then the SIP server builds the WWW-Authenticate header field using all the digest parameters (received in the Digest-* AVPs) and adds the foo="bar" parameter to it. Iconic teamwork ✨
9.6. SIP-Number-Auth-Items AVP
the SIP-Number-Auth-Items AVP (AVP Code 382) is of type Unsigned32 and tells you how many authentication and/or authorization credentials the Diameter server put into a Diameter message 🔥
when it's in a request, it shows how many SIP-Auth-Data-Items the Diameter client wants. This comes in handy when the SIP server is asking for several pre-calculated authentication credentials at once 🧁 In the answer, the SIP-Number-Auth-Items AVP shows the actual number of items the Diameter server actually included.
9.7. SIP-Deregistration-Reason AVP
the SIP-Deregistration-Reason AVP (AVP Code 383) is Grouped and says why a deregistration happened 🌸
it's defined like this (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-Deregistration-Reason ::= < AVP Header: 383 >
{ SIP-Reason-Code }
[ SIP-Reason-Info ]
* [ AVP ]9.7.1. SIP-Reason-Code AVP
the SIP-Reason-Code AVP (AVP Code 384) is Enumerated and defines why the network started the deregistration. These values are defined:
PERMANENT_TERMINATION(0)NEW_SIP_SERVER_ASSIGNED(1)SIP_SERVER_CHANGE(2)REMOVE_SIP_SERVER(3)
9.7.2. SIP-Reason-Info AVP
the SIP-Reason-Info AVP (AVP Code 385) is UTF8String and has text that can be shown to the user about why they were deregistered 💜
9.8. SIP-AOR AVP
the SIP-AOR AVP is a RADIUS attribute borrowed from the RADIUS Extension for Digest Authentication [RFC4590] namespace, so RADIUS and Diameter apps that support SIP can switch between each other smoothly 🦋 It carries the URI of the intended user for the SIP request. Where that URI lives in SIP can change depending on the actual request, and on whether the SIP server is handling a SIP-originated request or a terminating one.
The Diameter client (SIP server) builds the SIP-AOR AVP from a value in the SIP Request-URI or in a SIP header field value. Which one it picks depends on what the SIP message means and on whether the SIP server is acting for originating or terminating requests 🤔 For example, when the SIP server gets an INVITE addressed to the served user (so it's a terminating SIP request), it maps the SIP Request-URI of the request to this AVP. But when the SIP server gets an INVITE that the served user originated, it can map either the P-Asserted-Identity or the From header field values to this AVP. If the SIP server is acting as a SIP registrar, it maps the To header field of the REGISTER request to the SIP-AOR AVP.
9.9. SIP-Visited-Network-Id AVP
the SIP-Visited-Network-Id AVP (AVP Code 386) is UTF8String 🗺️ It holds an identifier that helps the home network figure out which visited network the user is on (for example, the visited network domain name), so it can authorize roaming to that network.
9.10. SIP-User-Authorization-Type AVP
the SIP-User-Authorization-Type AVP (AVP Code 387) is Enumerated and shows what kind of user authorization is happening in a User Authorization operation, which is the Diameter User-Authorization-Request (UAR) command 💅 These values are defined:
REGISTRATION(0) This value is used for initial registration or re-registration. This is the default value.DEREGISTRATION(1) This value is used for deregistration.REGISTRATION_AND_CAPABILITIES(2) This value is used for initial registration or re-registration when the SIP server explicitly asks the Diameter server to get capability information. That capability info helps the SIP server pick another SIP server to serve the user 👑
9.11. SIP-Supported-User-Data-Type AVP
the SIP-Supported-User-Data-Type AVP (AVP Code 388) is UTF8String and holds a string that names a type of supported user data (a user profile; see the SIP-User-Data AVP (Section 9.12)) that the node supports 🎀 You can repeat this AVP if the SIP server supports several user data types. If it gets repeated, the Diameter client should order the instances based on its preferences.
when the Diameter client puts this AVP in a SAR message, it lets the Diameter server know which types of user data the SIP server supports 🫶 The Diameter server looks at these AVPs and sends back a suitable SIP-User-Data AVP (Section 9.12) of the type named in the SIP-User-Data-Type AVP (Section 9.12.1).
9.12. SIP-User-Data AVP
the SIP-User-Data AVP (AVP Code 389) is Grouped, and it lets the Diameter server send user-specific data, like a user profile, over to the SIP server (in the Diameter client) 🌈 The Diameter server picks a type of user data that the SIP server understands, one that was listed in a SIP-Supported-User-Data-Type AVP. If the Diameter client said it supports several types, the Diameter server SHOULD choose the first type the client supports.
the SIP-User-Data grouped AVP has a SIP-User-Data-Type AVP inside it, which says what kind of user data is in the SIP-User-Data-Contents-AVP ✨
it's defined like this (per the grouped-avp-def of RFC 3588 [RFC3588]):
SIP-User-Data ::= < AVP Header: 389 >
{ SIP-User-Data-Type }
{ SIP-User-Data-Contents }
* [ AVP ]9.12.1. SIP-User-Data-Type AVP 🎀
Okay so the SIP-User-Data AVP (AVP Code 390) is a UTF8String, and its whole job is to carry a string that says what kind of user data is inside the SIP-User-Data AVP (Section 9.12) 💖
This document doesn't set up a convention for labelling that data, bestie 🙈 It's believed that most of the time this will live in environments run by a network admin, who can set up the client and the server to use the same value type on both ends ✨ Still, organizations making their own profile of the SIP-User-Data AVP (Section 9.12) are RECOMMENDED to allocate a type based on their canonical DNS name 🌈 For example, the org "example.com" could define a bunch of types and allocate "type1.dsa.example.com", "type2.dsa.example.com", and so on. That way nobody clashes when allocating types for the SIP-User-Data AVP (Section 9.12) 💅
9.12.2. SIP-User-Data-Contents AVP 🧚
The SIP-User-Data-Contents AVP (AVP Code 391) is an OctetString 🫶 Diameter peers don't need to understand its value.
This AVP holds the user profile data a SIP server needs in order to give the user service ✨
9.13. SIP-User-Data-Already-Available AVP 🦋
The SIP-User-Data-Already-Available AVP (AVP Code 392) is Enumerated, and it tells the Diameter server whether the Diameter client (the SIP server) already got the piece of the user profile it needs to serve the user 👑 These values are defined:
USER_DATA_NOT_AVAILABLE(0) The Diameter client (SIP server) doesn't have the data it needs to serve the user 🥀USER_DATA_ALREADY_AVAILABLE(1) The Diameter client (SIP server) already received the data it needs to serve the user 💜
9.14. SIP-Method AVP 💀
The SIP-Method-AVP (AVP Code 393) is a UTF8String, and it holds the method of the SIP request that set off the Diameter message 🔥 The Diameter server MUST use this AVP solely for authorizing SIP requests, and it MUST NOT use it to compute the Digest authentication. For computing Digest authentication, the Diameter server MUST use the Digest-Method AVP instead 🙅♀️
10. New Values for Existing AVPs 🌸
This section is where the Diameter SIP application adds new values to AVPs that already exist 🍓
10.1. Extension to the Result-Code AVP Values 💅
The Result-Code AVP is already defined in RFC 3588 [RFC3588]. On top of the values RFC 3588 [RFC3588] already defines, the Diameter SIP application adds these new Result-Code AVP values:
10.1.1. Success Result-Code AVP Values 🎉
A Diameter peer uses Result-Code AVP values from the success category to tell the remote peer that a request was completed successfully ✨
DIAMETER_FIRST_REGISTRATION2003 The user wasn't previously registered. The Diameter server has now authorized the registration 🥳DIAMETER_SUBSEQUENT_REGISTRATION2004 The user is already registered. The Diameter server has now authorized the re-registration 🔁DIAMETER_UNREGISTERED_SERVICE2005 The user isn't currently registered, but the requested service can still be granted to them 🫶DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED2006 The request operation was processed successfully. The Diameter server doesn't keep a record of the SIP server address assigned to the user 🤫DIAMETER_SERVER_SELECTION2007 The Diameter server has authorized the registration. The user has already been assigned a SIP server, but it may be necessary to select a new SIP server for them 🧭DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED2008 The requested operation was executed successfully. The Diameter server is sending a number of authentication credentials in the answer message, and it doesn't keep a record of the SIP server 🔐
10.1.2. Transient Failures Result-Code AVP Values ⏳
A Diameter peer uses a Result-Code AVP value from the transient failures category to tell the remote peer that a request couldn't be satisfied when it arrived, but it MAY be satisfied by the Diameter peer later on 🌤️
DIAMETER_USER_NAME_REQUIRED4013 The Diameter request didn't contain aUser-NameAVP, which is required to complete the transaction. The Diameter peer MAY include aUser-NameAVP and try the request again 📝
10.1.3. Permanent Failures Result-Code AVP Values 🚫
A Diameter peer uses a Result-Code AVP value from the permanent failure category to tell the remote peer that the request failed and shouldn't be tried again 💔
DIAMETER_ERROR_USER_UNKNOWN5032 TheSIP-AORAVP value doesn't belong to a known user in this realm 👻DIAMETER_ERROR_IDENTITIES_DONT_MATCH5033 The value in one of theSIP-AORAVPs isn't allocated to the user named in theUser-NameAVP 🙅♀️DIAMETER_ERROR_IDENTITY_NOT_REGISTERED5034 A query for location information came in for a SIP AOR that hasn't been registered before. The user this identity belongs to can't be given service in this situation 🕳️DIAMETER_ERROR_ROAMING_NOT_ALLOWED5035 The user isn't allowed to roam to the visited network 🛑DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED5036 The identity being registered has already been assigned a server, and the registration status doesn't allow it to be overwritten 🔒DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED5037 The authentication scheme indicated in an authentication request isn't supported 🙃DIAMETER_ERROR_IN_ASSIGNMENT_TYPE5038 The SIP server address sent in theSIP-Server-URIAVP value of the Diameter Server-Assignment-Request (SAR) command is the same SIP server address currently assigned to the user name, but theSIP-Server-Assignment-TypeAVP isn't allowed. For example, the user is registered and the Server-Assignment-Request indicates an assignment for an unregistered user 🌀DIAMETER_ERROR_TOO_MUCH_DATA5039 The Diameter peer in the SIP server receives more data than it can accept. The SIP server can't overwrite the data it already stored 📦DIAMETER_ERROR_NOT SUPPORTED_USER_DATA5040 The SIP server tells the Diameter server that the subscription data it received included information that wasn't recognized or supported 🥺
11. Authentication Details 🔐
Authenticating a user can happen through different mechanisms ✨ Right now, HTTP Digest authentication is the one that's supported. The actual authentication gets done in either the SIP server or the Diameter server, so it's kind of a choose-your-fighter situation 🥊
If the Diameter server wants to make sure authentication happens in the Diameter server (instead of a delegated authentication happening in the SIP server), it MUST NOT include a Digest-HA1 AVP (part of the grouped SIP-Authenticate AVP, which in turn is part of the SIP-Auth-Data-Item AVP) in a MAA message. The Diameter server MAY include a pre-calculated Digest-HA1 AVP in the MAA message if it wants to delegate the user's authentication to the SIP server 🎀
Note that on systems where the SIP User Agent uses HTTP Digest authentication [RFC2617] inside of Transport Layer Security (TLS) [RFC4346], and only the SIP proxy server has a certificate, delegating authentication to the SIP server (by making Digest-HA1 available to the SIP server) might reduce the load on the Diameter server 🧠✨
When the Diameter client is requesting authentication, it indicates in the SIP-Number-Auth-Items AVP value of a Diameter MAR message how many authentication credentials it's asking for 🙋♀️ In the Diameter MAA message, the Diameter server MAY include more than one SIP-Auth-Data-Item AVP. That's only useful for the Diameter client if the Digest-QoP AVP was set to 'auth-int' (in the MAR message), and if future authentications will have the same realm 🫠 When the Diameter server includes more than one SIP-Auth-Data-Item AVP, it SHOULD indicate how many instances of SIP-Auth-Data-Item AVPs are present with the SIP-Number-Auth-Items AVP. That number may be different from the one requested in the Diameter MAR message 🔢 If multiple SIP-Auth-Data-Item AVPs are present and their ordering is significant, the Diameter server MUST include a SIP-Item-Number AVP in each grouping to show the order 🪜 The SIP-Authentication-Scheme AVP indicates "Digest", and the SIP-Authenticate AVP contains data (typically a challenge of some kind) that the user can use for her authentication 🗝️ The grouped SIP-Authorization AVP contains the AVPs that match the response expected from the user 💌
If the Diameter server performs the user's authentication, the Diameter MAR message that the Diameter client sends to the Diameter server MUST include all the authentication credentials supplied by the SIP UA (there might be more than one credential, e.g., different realms, authentication of proxies, etc.) 🧺 Each credential goes inside a grouped SIP-Authorization AVP (part of the grouped SIP-Auth-Data-Item AVP). The Diameter client MUST insert a SIP-Number-Auth-Items AVP with its value set to the number of credentials enclosed 🔢 If it's necessary, the Digest-Entity-Body-Hash AVP will contain a hash of the body, which is needed to perform the authentication 🧾 If the authentication succeeds, the Diameter MAA message will contain a Result-Code AVP indicating success. If it's necessary, the Diameter server MAY include one or more SIP-Auth-Data-Item AVPs to provide further authentication credentials to the SIP server 🎁 If the authentication fails because credentials are missing, the Diameter MAA message will include a SIP-Auth-Data-Item AVP with the SIP-Authentication-Scheme and SIP-Authenticate AVPs, containing data (typically a challenge of some kind) that the user can use to authenticate itself 😤
There are situations where a SIP request goes through several proxies, and each of those proxies asks to authenticate the SIP UA 🛣️ In that case, it's a totally valid scenario for a SIP request received at a SIP server to contain several sets of credentials 👯♀️ The 'realm' directive in HTTP is the key the Diameter client can use to work out which credential applies 🔑 Also, none of the realms may be of interest to the Diameter client. If that's the case, the Diameter client MUST consider that no credentials (of interest) were sent 🙈 In any case, a Diameter client MUST send zero or exactly one credential to the Diameter server 🫶 The Diameter client MUST choose the credential based on the 'realm' directive in the Authorization/Proxy-Authorization header field, and it MUST match the realm of the Diameter client 💖
It must be noted that nonces are always generated in the Diameter server 🧁
12. Migration from RADIUS 🎀
okay so RADIUS already does HTTP Digest auth through the RADIUS Extension for Digest Authentication [RFC4590] 🦋 A bunch of the Digest-* AVPs in this Diameter SIP application were borrowed straight from the RADIUS attributes namespace, so moving from RADIUS to Diameter is smooth and not a whole thing 💖
ngl the RADIUS extension is a lot smaller in scope, though. It only does HTTP Digest auth. The Diameter SIP application does way more, like user location, profile downloading and update, and so on ✨
The next sections walk through a few setups where a gateway translates RADIUS to Diameter and back again 🧚
12.1. Gateway from RADIUS Client to Diameter Server
the gateway turns Access-Request messages into a MAR request 💅 If a RADIUS Access-Request has at least one Digest-* attribute, the gateway maps all of the Digest-* attributes into the AVPs of a Diameter SIP-Authorization AVP, builds a MAR message, and sends it to the Diameter server 🔥 If there's no Digest-* attribute at all, the RADIUS client isn't asking for HTTP Digest auth, so whatever the gateway does in that case is outside the scope of this document 🙈
The Diameter server answers with a MAA message. If that MAA has a Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH and includes challenge parameters in a SIP-Authenticate AVP, the gateway translates the SIP-Authenticate AVP and drops the resulting RADIUS attributes into an Access-Challenge message. Then it sends that Access-Challenge to the RADIUS client 🌸
If the MAA has a SIP-Authentication-Info and a Digest-Response AVP, the gateway converts both into the matching RADIUS attributes and builds a RADIUS message. If the Result-Code is DIAMETER_SUCCESS, the gateway sends an Access-Accept. In every other case it sends an Access-Reject 💀
12.2. Gateway from Diameter Client to RADIUS Server
the Diameter client sends a Diameter MAR message to the gateway 🫶 If that MAR doesn't have any SIP-Auth-Data-Item AVPs, the gateway builds an Access-Request and maps the SIP-AOR and SIP-Method AVPs to RADIUS attributes. It sends the Access-Request to the RADIUS server, which replies with an Access-Challenge 👑
Next, the gateway makes a MAA with a Result-Code set to DIAMETER_MULTI_ROUND_AUTH, maps the Digest-* attributes into Diameter AVPs inside a SIP-Authenticate AVP, and sends that MAA to the Diameter client. The client then answers with a new MAR, lowkey the second round of the same dance 🎀
When this new MAR shows up, the gateway checks its SIP-Auth-Data-Item AVPs for one where the Digest-Realm AVP matches the locally configured realm value 🔍 It grabs the AVPs from that SIP-Auth-Data-Item AVP, converts them into RADIUS attributes, builds a RADIUS Access-Request, and sends it to the RADIUS server 🌈
If the RADIUS server replies with an Access-Accept, the gateway converts the RADIUS attributes back into Diameter AVPs, builds a MAA with a Result-Code set to DIAMETER_SUCCESS, and sends it to the Diameter client ⭐ If the RADIUS server replies with an Access-Reject, the gateway converts the attributes, builds a MAA with a Result-Code set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH, and sends that to the Diameter client 😭
12.3. Known Limitations
not gonna lie, there isn't a perfect 1:1 match between the Diameter SIP application and the RADIUS Extension for Digest Authentication [RFC4590] 🙃 The big one is that the RADIUS extension doesn't have anything equivalent to the Diameter UAR/UAA, SAR/SAA, LIR/LIA, RTR/RTA, and PPR/PPA messages that this specification defines 💜
13. IANA Considerations 🍓
this document is basically the IANA registration request for a bunch of stuff that should go into the AAA parameters registry 📝
13.1. Application Identifier
this document defines a standards-track Application-ID 🎀 It falls into the Application Identifier standards-track address space defined by RFC 3588 [RFC3588] Section 11.3. The Application-ID is registered in the Application IDs sub-registry of the AAA parameters registry with this data:
ID values Name Reference
----------- ------------------------ ---------
6 Diameter Session Initiation RFC 4740
Protocol (SIP) Application13.2. Command Codes
this document defines new standard commands 🦋 Their Command Codes get allocated inside the standard permanent Command Codes address space defined in RFC 3588 [RFC3588] Section 11.2.1. These command codes should be registered in the Command Codes sub-registry of the AAA parameters registry 💅
Table 1 in Section 8 has the full list of Command Code names and values that are part of this Diameter application ✨
13.3. AVP Codes
this document defines new standard AVPs, and their AVP Codes get allocated inside the AVP Codes address space defined in RFC 3588 [RFC3588] Section 11.4 🌸 These AVP codes are registered in the AVP Codes sub-registry of the AAA parameters registry 🧚
Table 2 in Section 9 has the full list of AVP names and AVP codes in this Diameter application 🫶
13.4. Additional Values for the Result-Code AVP Value
this document defines new standard Result-Code AVP values, which get allocated inside the Result-Code AVP address space defined in RFC 3588 [RFC3588] Section 14.4.1 👑 They're listed in the Result-Code AVP values section of the AVP Specific Values sub-registry of the AAA parameters registry 🎀
Section 10.1.1 lists the new Result-Code AVP values in the success category, per RFC 3588 [RFC3588] Section 7.1.2 🦋
Section 10.1.2 lists the new ones in the transient failures category, per RFC 3588 [RFC3588] Section 7.1.4 💖
Section 10.1.3 lists the new ones in the permanent failures category, per RFC 3588 [RFC3588] Section 7.1.5 💀
13.5. Creation of the SIP-Server-Assignment-Type Section in the AAA Registry
this document defines a new SIP-Server-Assignment-Type AVP (see Section 9.4) 🌈 It's an Enumerated type. We define an initial set of values that IANA should register 🍓 IANA should create a new "SIP-Sever-Assignment-Type AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is in Section 9.4 ✨
13.6. Creation of the SIP-Authentication-Scheme Section in the AAA Registry
this document defines a new SIP-Authentication-Scheme AVP (see Section 9.5.1) 🧚 It's Enumerated too. We currently define a single value that IANA should register 🌸 IANA should create a new "SIP-Authentication-Scheme AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is included in Section 9.5.1 💅
13.7. Creation of the SIP-Reason-Code Section in the AAA Registry
this document defines a new SIP-Reason-Code AVP (see Section 9.7.1), an Enumerated type 🔥 We define an initial set of values that IANA should register. IANA should create a new "SIP-Reason-Code AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is in Section 9.7.1 🫶
13.8. Creation of the SIP-User-Authorization-Type Section in the AAA Registry
this document defines a new SIP-User-Authorization-Type AVP (see Section 9.10), also Enumerated 👑 We define an initial set of values that IANA should register. IANA should create a new "SIP-User-Authorization-Type AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is in Section 9.10 🎀
13.9. Creation of the SIP-User-Data-Already-Available Section in the AAA Registry
this document defines a new SIP-User-Data-Already-Available AVP (see Section 9.13), Enumerated again 🦋 We define an initial set of values which IANA should register. IANA should create a new "SIP-User-Data-Already-Available AVP values" section under the AVP Specific Values sub-registry of the AAA parameters registry. The initial list of values is in Section 9.13 💖
14. Security Considerations 💀
this memo doesn't describe a stand-alone protocol. It's a particular application for the Diameter protocol [RFC3588] 😭 That means all the security considerations that apply to Diameter automatically apply here too. In particular, Section 13 of RFC 3588 applies to this memo 🚨
This is serious, bestie: the security considerations below are not optional vibes. Read them all.
This Diameter SIP application lets a Diameter client use the properties of HTTP Digest authentication [RFC2617] by evaluating or sending the credentials a user supplied to the Diameter server. The discussion of HTTP Digest authentication in Section 4 of RFC 2617 [RFC2617] applies to this memo as well 🔐
It also lets a Diameter client use the properties of HTTP Digest authentication using AKA [RFC3310] by evaluating or sending the credentials a user supplied to the Diameter server. Section 5 of RFC 3310 [RFC3310] also applies to this memo 🔥
14.1. Final Authentication Check in the Diameter Client/SIP Server
the Diameter SIP application can be set up so the final authentication check happens in the Diameter client (SIP server) 🧚 There are a few security considerations for that setup, and they all come from one requirement: H(A1) has to be transferred from the Diameter server to the Diameter client 😱
- Both Diameter client and server must trust each other, such as when both client and server belong to the same administrative domain.
- To avoid eavesdroppers, the transport protocol between the Diameter client and server MUST be secured. RFC 3588 [RFC3588] specifies TLS [RFC4346] and IPsec as possible transport protection mechanisms for Diameter. 🔒
Because of all these security considerations, it is RECOMMENDED to configure the Diameter SIP application so the final authentication check happens in the Diameter server instead 👑 🫶
15. Contributors 🌈
the authors would like to thank these contributors, who made substantial contributions to this work 💜
Pete McCann Lucent
Jaakko Rajaniemi NokiaWolfgang Beck (Deutsche Telekom AG) provided the text in Section 12, "Migration from RADIUS" ✨🍓
16. Acknowledgements 🙏✨
okay bestie, the authors wanna give a big shoutout to Tony Johansson and Kevin Purser 💖 for helping get this whole application off the ground and keeping it moving. they also thank Daniel Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior, Wolfgang Beck, Ulrich Wiehe, Cullen Jennings, Anu Leinonen, Glen Zorn, German Blanco, Mikko Aittola, Bert Wijnen, and Sam Hartman 🫶 for their reviews and comments, which were literally so valuable.
the Diameter SIP application is based on the Diameter application for the Cx interface of the 3GPP IP Multimedia Subsystem [3GPP.29.229] 🧚. the authors thank 3GPP Working Group CN4 for this work. the glow-up is real 💅
17. References 📚
17.1. Normative References
These are the must-read sources the spec is built on 👑
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext
Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA)", RFC 3310,
September 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams,
D., and W. Beck, "RADIUS Extension for Digest
Authentication", RFC 4590, July 2006.17.2. Informative References
these ones are super helpful for context but not required reading 🌸
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP)
Event Package for Registrations", RFC 3680,
March 2004.
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call
Processing Language (CPL): A Language for User Control
of Internet Telephony Services", RFC 3880,
October 2004.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,
and P. McCann, "Diameter Mobile IPv4 Application",
RFC 4004, August 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application",
RFC 4005, August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M.,
and J. Loughney, "Diameter Credit-Control
Application", RFC 4006, August 2005.
[3GPP.29.229] 3GPP, "Cx and Dx interfaces based on the Diameter
protocol; Protocol details", 3GPP TS 29.229 5.12.0,
June 2006.
[JSR-000116] Java Community Process, "SIP Servlet API Specification
1.0 Final Release", JSR 000116, March 2003.Authors' Addresses 📬
these are the people to slide into DMs about the spec 💌
Miguel A. Garcia-Martin (Editor)
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 480 4586
EMail: miguel.an.garcia@nokia.com
Maria-Carmen Belinchon
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 3535
EMail: maria.carmen.belinchon@ericsson.com
Miguel A. Pallares-Lopez
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 4222
EMail: miguel-angel.pallares@ericsson.com
Carolina Canales-Valenzuela
Ericsson
Via de los Poblados 13
Madrid 28033
Spain
Phone: +34 91 339 2680
EMail: carolina.canales@ericsson.com
Kalle Tammi
Nokia
P.O.Box 785
Tampere 33101
Finland
Phone: +358 40 505 8670
EMail: kalle.tammi@nokia.comFull Copyright Statement ⚖️
okay legal bit, but make it quick 💅 Copyright (C) The IETF Trust (2006). this document is subject to the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights.
this document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE 🙅♀️ disclaim ALL warranties, express or implied, including but not limited to any warranty that using the info won't infringe any rights, or any implied warranties of merchantability or fitness for a particular purpose.
Intellectual Property 🦋
the IETF doesn't take a position on whether any IPR claims apply to the tech in this document, or whether any license for it might be available. it also doesn't claim it went looking for any of those rights. the procedures for rights in RFC docs are in BCP 78 and BCP 79 📖
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
the IETF invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 🌈
funding for the RFC Editor function is currently provided by the Internet Society 🎀
📦 where this page comes from
- ietf: rfc4740 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms