Initial commit
Change-Id: I6a4444e3c193dae437cd7929f4c39aba7b749efa
diff --git a/extensions/dict_sip/dict_sip.c b/extensions/dict_sip/dict_sip.c
new file mode 100644
index 0000000..636c0cb
--- /dev/null
+++ b/extensions/dict_sip/dict_sip.c
@@ -0,0 +1,2952 @@
+/*********************************************************************************************************
+* Software License Agreement (BSD License) *
+* Author: Alexandre Westfahl <awestfahl@freediameter.net> *
+* *
+* Copyright (c) 2010, Alexandre Westfahl, Teraoka Laboratory (Keio University), and the WIDE Project. * *
+* All rights reserved. *
+* *
+* Redistribution and use of this software in source and binary forms, with or without modification, are *
+* permitted provided that the following conditions are met: *
+* *
+* * Redistributions of source code must retain the above *
+* copyright notice, this list of conditions and the *
+* following disclaimer. *
+* *
+* * Redistributions in binary form must reproduce the above *
+* copyright notice, this list of conditions and the *
+* following disclaimer in the documentation and/or other *
+* materials provided with the distribution. *
+* *
+* * Neither the name of the Teraoka Laboratory nor the *
+* names of its contributors may be used to endorse or *
+* promote products derived from this software without *
+* specific prior written permission of Teraoka Laboratory *
+* *
+* *
+* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED *
+* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A *
+* PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR *
+* ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT *
+* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS *
+* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR *
+* TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF *
+* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. *
+*********************************************************************************************************/
+
+#include <freeDiameter/extension.h>
+
+
+
+/* The content of this file follows the same structure as dict_base_proto.c */
+
+#define CHECK_dict_new( _type, _data, _parent, _ref ) \
+ CHECK_FCT( fd_dict_new( fd_g_config->cnf_dict, (_type), (_data), (_parent), (_ref)) );
+
+#define CHECK_dict_search( _type, _criteria, _what, _result ) \
+ CHECK_FCT( fd_dict_search( fd_g_config->cnf_dict, (_type), (_criteria), (_what), (_result), ENOENT) );
+
+struct local_rules_definition {
+ char *avp_name;
+ enum rule_position position;
+ int min;
+ int max;
+};
+
+#define RULE_ORDER( _position ) ((((_position) == RULE_FIXED_HEAD) || ((_position) == RULE_FIXED_TAIL)) ? 1 : 0 )
+
+#define PARSE_loc_rules( _rulearray, _parent) { \
+ int __ar; \
+ for (__ar=0; __ar < sizeof(_rulearray) / sizeof((_rulearray)[0]); __ar++) { \
+ struct dict_rule_data __data = { NULL, \
+ (_rulearray)[__ar].position, \
+ 0, \
+ (_rulearray)[__ar].min, \
+ (_rulearray)[__ar].max}; \
+ __data.rule_order = RULE_ORDER(__data.rule_position); \
+ CHECK_FCT( fd_dict_search( \
+ fd_g_config->cnf_dict, \
+ DICT_AVP, \
+ AVP_BY_NAME, \
+ (_rulearray)[__ar].avp_name, \
+ &__data.rule_avp, 0 ) ); \
+ if ( !__data.rule_avp ) { \
+ TRACE_DEBUG(INFO, "AVP Not found: '%s'", (_rulearray)[__ar].avp_name ); \
+ return ENOENT; \
+ } \
+ CHECK_FCT_DO( fd_dict_new( fd_g_config->cnf_dict, DICT_RULE, &__data, _parent, NULL), \
+ { \
+ TRACE_DEBUG(INFO, "Error on rule with AVP '%s'", \
+ (_rulearray)[__ar].avp_name ); \
+ return EINVAL; \
+ } ); \
+ } \
+}
+
+#define enumval_def_u32( _val_, _str_ ) \
+ { _str_, { .u32 = _val_ }}
+
+#define enumval_def_os( _len_, _val_, _str_ ) \
+ { _str_, { .os = { .data = (unsigned char *)_val_, .len = _len_ }}}
+
+
+
+int ds_dict_init(char * conffile)
+{
+ struct dict_object * sip;
+ {
+ struct dict_application_data data = { 6, "Diameter Session Initiation Protocol (SIP) Application" };
+ CHECK_dict_new( DICT_APPLICATION, &data , NULL, &sip);
+ }
+
+ /* AVP section */
+ {
+ struct dict_object * UTF8String_type;
+ struct dict_object * DiameterURI_type;
+
+ CHECK_dict_search( DICT_TYPE, TYPE_BY_NAME, "UTF8String", &UTF8String_type);
+ CHECK_dict_search( DICT_TYPE, TYPE_BY_NAME, "DiameterURI", &DiameterURI_type);
+
+ /* Digest AVPs (from RADIUS) */
+
+ /* Digest-Response */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 103, /* Code */
+ 0, /* Vendor */
+ "Digest-Response", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Realm */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 104, /* Code */
+ 0, /* Vendor */
+ "Digest-Realm", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Nonce */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 105, /* Code */
+ 0, /* Vendor */
+ "Digest-Nonce", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Response-Auth */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 106, /* Code */
+ 0, /* Vendor */
+ "Digest-Response-Auth", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Nextnonce */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 107, /* Code */
+ 0, /* Vendor */
+ "Digest-Nextnonce", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Method */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 108, /* Code */
+ 0, /* Vendor */
+ "Digest-Method", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-URI */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 109, /* Code */
+ 0, /* Vendor */
+ "Digest-URI", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-QoP */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 110, /* Code */
+ 0, /* Vendor */
+ "Digest-QoP", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Algorithm */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 111, /* Code */
+ 0, /* Vendor */
+ "Digest-Algorithm", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Entity-Body-Hash */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 112, /* Code */
+ 0, /* Vendor */
+ "Digest-Entity-Body-Hash", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-CNonce */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 113, /* Code */
+ 0, /* Vendor */
+ "Digest-CNonce", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Nonce-Count */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 114, /* Code */
+ 0, /* Vendor */
+ "Digest-Nonce-Count", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Username */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 115, /* Code */
+ 0, /* Vendor */
+ "Digest-Username", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Opaque */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 116, /* Code */
+ 0, /* Vendor */
+ "Digest-Opaque", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Auth-Param */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 117, /* Code */
+ 0, /* Vendor */
+ "Digest-Auth-Param", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-AKA-Auts */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 118, /* Code */
+ 0, /* Vendor */
+ "Digest-AKA-Auts", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Domain */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 119, /* Code */
+ 0, /* Vendor */
+ "Digest-Domain", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-Stale */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 120, /* Code */
+ 0, /* Vendor */
+ "Digest-Stale", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* Digest-HA1 */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 121, /* Code */
+ 0, /* Vendor */
+ "Digest-HA1", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+ /* SIP-AOR */
+ {
+ /*
+
+ */
+
+ struct dict_avp_data data = {
+ 122, /* Code */
+ 0, /* Vendor */
+ "SIP-AOR", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+
+ /* Diameter SIP AVPs*/
+ /* SIP-Accounting-Server-URI*/
+ {
+ /*
+ The SIP-Accounting-Server-URI AVP (AVP Code 369) is of type
+ DiameterURI. This AVP contains the address of a Diameter server that
+ is able to receive SIP-session-related accounting information.
+ */
+
+ struct dict_avp_data data = {
+ 369, /* Code */
+ 0, /* Vendor */
+ "SIP-Accounting-Server-URI", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , DiameterURI_type, NULL);
+ }
+ /* SIP-Credit-Control-Server-URI */
+ {
+ /*
+ The SIP-Credit-Control-Server-URI AVP (AVP Code 370) is of type
+ DiameterURI. This AVP contains the address of a Diameter server that
+ is able to authorize real-time credit control usage. The Diameter
+ Credit-Control Application [RFC4006] may be used for this purpose.
+
+
+ */
+
+ struct dict_avp_data data = {
+ 370, /* Code */
+ 0, /* Vendor */
+ "SIP-Credit-Control-Server-URI", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , DiameterURI_type, NULL);
+ }
+
+ /* SIP-Accounting-Information */
+ {
+ /*
+ The SIP-Accounting-Information (AVP Code 368) is of type Grouped, and
+ contains the Diameter addresses of those nodes that are able to
+ collect accounting information.
+
+ The SIP-Accounting-Information AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [RFC3588]):
+
+ SIP-Accounting-Information ::= < AVP Header: 368 >
+ * [ SIP-Accounting-Server-URI ]
+ * [ SIP-Credit-Control-Server-URI ]
+ * [ AVP]
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 368, /* Code */
+ 0, /* Vendor */
+ "SIP-Accounting-Information", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "SIP-Accounting-Server-URI", RULE_OPTIONAL, -1, -1 }
+ ,{ "SIP-Credit-Control-Server-URI", RULE_OPTIONAL, -1, -1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+
+ /* SIP-Server-URI */
+ {
+ /*
+ The SIP-Server-URI AVP (AVP Code 371) is of type UTF8String. This
+ AVP contains a SIP or SIPS URI (as defined in RFC 3261 [RFC3261])
+ that identifies a SIP server.
+ */
+
+ struct dict_avp_data data = {
+ 371, /* Code */
+ 0, /* Vendor */
+ "SIP-Server-URI", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* SIP-Mandatory-Capability */
+ {
+ /*
+ The SIP-Mandatory-Capability AVP (AVP Code 373) is of type
+ Unsigned32. The value represents a certain capability (or set of
+ capabilities) that have to be fulfilled by the SIP server allocated
+ to the user.
+
+ The semantics of the different values are not standardized, as it is
+ a matter of the administrative network to allocate its own semantics
+ within its own network. Each value has to represent a single
+ capability within the administrative network.
+
+ */
+
+ struct dict_avp_data data = {
+ 373, /* Code */
+ 0, /* Vendor */
+ "SIP-Mandatory-Capability", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
+ }
+ /* SIP-Optional-Capability */
+ {
+ /*
+ The SIP-Optional-Capability AVP (AVP Code 374) is of type Unsigned32.
+ The value represents a certain capability (or set of capabilities)
+ that, optionally, may be fulfilled by the SIP server allocated to the
+ user.
+
+ The semantics of the different values are not standardized, as it is
+ a matter of the administrative network to allocate its own semantics
+ within its own network. Each value has to represent a single
+ capability within the administrative network.
+
+ */
+
+ struct dict_avp_data data = {
+ 374, /* Code */
+ 0, /* Vendor */
+ "SIP-Optional-Capability", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
+ }
+
+
+ /* SIP-Server-Capabilities */
+ {
+ /*
+ The SIP-Server-Capabilities AVP (AVP Code 372) is of type Grouped.
+ The Diameter indicates in this AVP the requirements for a particular
+ SIP capability, so that the Diameter client (SIP server) is able to
+ select another appropriate SIP server to serve the user.
+
+ The SIP-Server-Capabilities AVP allows a Diameter client (SIP server)
+ to select another SIP server for triggering or executing services to
+ the user. A user may have enabled some services that require the
+ implementation of certain capabilities in the SIP server that
+ triggers or executes those services. For example, the SIP server
+ that triggers or executes services to this user may need to implement
+ SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880],
+ or any other kind of capability. Or perhaps that user belongs to a
+ premium users group that has a certain stringent quality-of-service
+ agreement that requires a fast SIP server. The capabilities required
+ or recommended to a given user are conveyed in the
+ SIP-Server-Capabilities AVP. When it receives them, the Diameter
+ client (SIP server) that does the SIP server selection needs to have
+ the means to find out available SIP servers that meet the required or
+ optional capabilities. Such means are outside the scope of this
+ specification.
+
+ Note that the SIP-Server-Capabilities AVP assists the Diameter client
+ (SIP server) to produce a subset of all the available SIP servers to
+ be allocated to the user in the Home Realm; this is the subset that
+ conforms the requirements of capabilities on a per-user basis.
+ Typically this subset will be formed of more than a single SIP
+ server, so once the subset of those SIP servers is identified, it is
+ possible that several instances of these SIP servers exist, in which
+ case the Diameter client (SIP server) should choose one particular
+ SIP server to execute and trigger services to this user. It is
+ expected that at this point the SIP server (Diameter client) will
+ follow the procedures of RFC 3263 [RFC3263] to allocate one SIP
+ server to the user.
+
+ The SIP-Server-Capabilities AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [RFC3588]):
+
+ SIP-Server-Capabilities ::= < AVP Header: 372 >
+ * [ SIP-Mandatory-Capability ]
+ * [ SIP-Optional-Capability ]
+ * [ SIP-Server-URI ]
+ * [ AVP ]
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 372, /* Code */
+ 0, /* Vendor */
+ "SIP-Server-Capabilities", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "SIP-Mandatory-Capability", RULE_OPTIONAL, -1, -1 }
+ ,{ "SIP-Optional-Capability", RULE_OPTIONAL, -1, -1 }
+ ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, -1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+
+
+ /* SIP-Server-Assignment-Type */
+ {
+ /*
+ The SIP-Server-Assignment-Type AVP (AVP Code 375) is of type
+ Enumerated and indicates the type of server update being performed in
+ a Diameter Server-Assignment-Request (SAR) operation. The following
+ values are defined:
+
+
+ o NO_ASSIGNMENT (0)
+ The Diameter client uses this value to request the user profile of
+ a SIP AOR, without affecting the registration state of that
+ identity.
+
+ o REGISTRATION (1)
+ First SIP registration of a SIP AOR.
+
+ o RE_REGISTRATION (2)
+ Subsequent SIP registration of a SIP AOR.
+
+ o UNREGISTERED_USER (3)
+ The SIP server has received a SIP request (e.g., SIP INVITE)
+ addressed for a SIP AOR that is not registered.
+
+ o TIMEOUT_DEREGISTRATION (4)
+ The SIP registration timer of an identity has expired.
+
+ o USER_DEREGISTRATION (5)
+ The SIP server has received a request to deregister a SIP AOR.
+
+ o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
+ The SIP registration timer of an identity has expired. The SIP
+ server keeps the user data stored and requests the Diameter server
+ to store the SIP server address.
+
+ o 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 requests
+ the Diameter server to store the SIP server address.
+
+ o ADMINISTRATIVE_DEREGISTRATION (8)
+ The SIP server, due to administrative reasons, has deregistered a
+ SIP AOR.
+
+ o AUTHENTICATION_FAILURE (9)
+ The authentication of a user has failed.
+
+ o AUTHENTICATION_TIMEOUT (10)
+ The authentication timer has expired.
+
+ o DEREGISTRATION_TOO_MUCH_DATA (11)
+ The SIP server has requested user profile information from the
+ Diameter server and has received a volume of data higher than it
+ can accept.
+
+ */
+ struct dict_object *type;
+ struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-Server-Assignment-Type)" , NULL, NULL};
+ struct dict_enumval_data tvals[] = {
+ enumval_def_u32( 0, "NO_ASSIGNMENT"),
+ enumval_def_u32( 1, "REGISTRATION"),
+ enumval_def_u32( 2, "RE_REGISTRATION"),
+ enumval_def_u32( 3, "UNREGISTERED_USER"),
+ enumval_def_u32( 4, "TIMEOUT_DEREGISTRATION"),
+ enumval_def_u32( 5, "USER_DEREGISTRATION"),
+ enumval_def_u32( 6, "TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME"),
+ enumval_def_u32( 7, "USER_DEREGISTRATION_STORE_SERVER_NAME"),
+ enumval_def_u32( 8, "ADMINISTRATIVE_DEREGISTRATION"),
+ enumval_def_u32( 9, "AUTHENTICATION_FAILURE"),
+ enumval_def_u32( 10, "AUTHENTICATION_TIMEOUT"),
+ enumval_def_u32( 11, "DEREGISTRATION_TOO_MUCH_DATA")
+ };
+ struct dict_avp_data data = {
+ 375, /* Code */
+ 0, /* Vendor */
+ "SIP-Server-Assignment-Type", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ int i;
+ /* Create the Enumerated type, enumerated values, and the AVP */
+ CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
+ for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
+ CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
+ }
+ CHECK_dict_new( DICT_AVP, &data , type, NULL);
+ }
+
+
+ /* SIP-Authenticate */
+ {
+ /*
+ The SIP-Authenticate AVP (AVP Code 379) is of type Grouped and
+ contains a reconstruction of either the SIP WWW-Authenticate or
+ Proxy-Authentication header fields specified in RFC 2617 [RFC2617]
+ for the HTTP Digest authentication scheme. Additionally, the AVP may
+ include a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617
+ [RFC2617]). H(A1) allows the Diameter client to create an expected
+ response and compare it with the Digest response received from the
+ SIP UA.
+ The SIP-Authenticate AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [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 ]
+
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 379, /* Code */
+ 0, /* Vendor */
+ "SIP-Authenticate", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "Digest-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-Nonce", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-Domain", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Opaque", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Stale", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Algorithm", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-QoP", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-HA1", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Auth-Param", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+ /* SIP-Authorization */
+ {
+ /*
+ The SIP-Authorization AVP (AVP Code 380) is of type Grouped and
+ contains a reconstruction of either the SIP Authorization or
+ Proxy-Authorization header fields specified in RFC 2617 [RFC2617] for
+ the HTTP Digest authentication scheme.
+
+ The SIP-Authorization AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [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 ]
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 380, /* Code */
+ 0, /* Vendor */
+ "SIP-Authorization", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "Digest-Username", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-Nonce", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-URI", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-Response", RULE_REQUIRED, -1, 1 }
+ ,{ "Digest-Algorithm", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-CNonce", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Opaque", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-QoP", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Nonce-Count", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Method", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Entity-Body-Hash", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Auth-Param", RULE_OPTIONAL, -1, -1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+ /* SIP-Authentication-Info */
+ {
+ /*
+ The SIP-Authentication-Info AVP (AVP Code 381) is of type Grouped and
+ contains a reconstruction of the SIP Authentication-Info header
+ specified in RFC 2617 [RFC2617] for the HTTP Digest authentication
+ scheme.
+ The SIP-Authentication-Info AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [RFC3588]):
+
+ SIP-Authentication-Info ::= < AVP Header: 381 >
+ [ Digest-Nextnonce ]
+ [ Digest-QoP ]
+ [ Digest-Response-Auth ]
+ [ Digest-CNonce ]
+ [ Digest-Nonce-Count ]
+ * [ AVP ]
+
+ Note that, in some cases, the Digest-Response-Auth AVP cannot be
+ calculated at the Diameter server, but has to be calculated at the
+ Diameter client (SIP server). For example, if the value of the
+ quality of protection (qop) parameter in Digest is set to "auth-int",
+ then the response-digest (rspauth parameter value in Digest) is
+ calculated with the hash of the body of the SIP response, which is
+ not available at the Diameter server. In this case, the Diameter
+ client (SIP server) must calculate the response-digest once the body
+ of the SIP response is calculated.
+
+ Therefore, a value of "auth-int" in the Digest-QoP AVP of the
+ SIP-Authentication-Info AVP indicates that the Diameter client (SIP
+ server) MUST compute the Digest "rspauth" parameter value at the
+ Diameter client (SIP server).
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 381, /* Code */
+ 0, /* Vendor */
+ "SIP-Authentication-Info", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "Digest-Nextnonce", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-QoP", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Response-Auth", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-CNonce", RULE_OPTIONAL, -1, 1 }
+ ,{ "Digest-Nonce-Count", RULE_OPTIONAL, -1, 1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+ /* SIP-Authentication-Scheme */
+ {
+ /*
+ The SIP-Authentication-Scheme AVP (AVP Code 377) is of type
+ Enumerated and indicates the authentication scheme used in the
+ authentication of SIP services. RFC 2617 identifies this value as an
+ "auth-scheme" (see Section 1.2 of RFC 2617 [RFC2617]). The only
+ currently defined value is:
+
+ o DIGEST (0) to indicate HTTP Digest authentication as specified in
+ RFC 2617 [RFC2617] Section 3.2.1. Derivative work is also
+ considered 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) is transported in a
+ corresponding AVP, whose name follows the pattern Digest-*. The
+ Digest-* AVPs are RADIUS attributes imported from the RADIUS
+ Extension for Digest Authentication [RFC4590] namespace, allowing a
+ smooth transition between RADIUS and Diameter applications supporting
+ 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 that correspond to the SIP WWW-
+ Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization,
+ and Authentication-Info headers fields, respectively.
+
+ Note: Due to the fact that 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 RFC 2617 [RFC2617] defines the Basic and Digest
+ schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only
+ imports HTTP Digest as a mechanism to provide authentication in
+ SIP.
+
+ Due to syntactic requirements, HTTP Digest authentication has to
+ escape quote characters in contents of HTTP Digest directives. When
+ translating directives into Digest-* AVPs, the Diameter client or
+ server removes the surrounding quotes where present, as required by
+ the syntax of the Digest-* attributes defined in the "RADIUS
+ Extension for Digest Authentication" [RFC4590].
+
+ */
+
+ struct dict_object *type;
+ struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-Authentication-Scheme)" , NULL, NULL};
+ struct dict_enumval_data tvals[] = {
+ enumval_def_u32( 0, "DIGEST")
+ };
+ struct dict_avp_data data = {
+ 377, /* Code */
+ 0, /* Vendor */
+ "SIP-Authentication-Scheme", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ int i;
+ /* Create the Enumerated type, enumerated values, and the AVP */
+ CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
+ for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
+ CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
+ }
+ CHECK_dict_new( DICT_AVP, &data , type, NULL);
+ }
+ /* SIP-Item-Number */
+ {
+ /*
+ The SIP-Item-Number (AVP Code 378) is of type Unsigned32 and is
+ included in a SIP-Auth-Data-Item grouped AVP in circumstances where
+ there are multiple occurrences of SIP-Auth-Data-Item AVPs and the
+ order of processing is relevant. The AVP indicates the order in
+ which the Grouped SIP-Auth-Data-Item should be processed. Lower
+ values of the SIP-Item-Number AVP indicate that the whole
+ SIP-Auth-Data-Item SHOULD be processed before other
+ SIP-Auth-Data-Item AVPs that contain higher values in the
+ SIP-Item-Number AVP.
+
+ */
+
+ struct dict_avp_data data = {
+ 378, /* Code */
+ 0, /* Vendor */
+ "SIP-Item-Number", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
+ }
+ /* SIP-Auth-Data-Item */
+ {
+ /*
+ The SIP-Auth-Data-Item (AVP Code 376) is of type Grouped and contains
+ the authentication and/or authorization information pertaining to 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 (e.g., in case the SIP
+ request contained several credentials). Section 11 contains a
+ detailed discussion and normative text of the case when a SIP request
+ contains several credentials.
+
+ The SIP-Auth-Data-Item AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [RFC3588]):
+
+ SIP-Auth-Data-Item ::= < AVP Header: 376 >
+ { SIP-Authentication-Scheme }
+ [ SIP-Item-Number ]
+ [ SIP-Authenticate ]
+ [ SIP-Authorization ]
+ [ SIP-Authentication-Info ]
+ * [ AVP ]
+
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 376, /* Code */
+ 0, /* Vendor */
+ "SIP-Auth-Data-Item", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "SIP-Authentication-Scheme",RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Item-Number", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Authenticate", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Authorization", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Authentication-Info", RULE_OPTIONAL, -1, 1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+ /* SIP-Number-Auth-Items */
+ {
+ /*
+ The SIP-Number-Auth-Items AVP (AVP Code 382) is of type Unsigned32
+ and indicates the number of authentication and/or authorization
+ credentials that the Diameter server included in a Diameter message.
+
+ When the AVP is present in a request, it indicates the number of
+ SIP-Auth-Data-Items the Diameter client is requesting. This can be
+ used, for instance, when the SIP server is requesting several
+ pre-calculated authentication credentials. In the answer message,
+ the SIP-Number-Auth-Items AVP indicates the actual number of items
+ that the Diameter server included.
+
+ */
+
+ struct dict_avp_data data = {
+ 382, /* Code */
+ 0, /* Vendor */
+ "SIP-Number-Auth-Items", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
+ }
+
+ /* SIP-Reason-Code */
+ {
+ /*
+ The SIP-Reason-Code AVP (AVP Code 384) is of type Enumerated and
+ defines the reason for the network initiated deregistration. The
+ following values are defined:
+
+ o PERMANENT_TERMINATION (0)
+ o NEW_SIP_SERVER_ASSIGNED (1)
+ o SIP_SERVER_CHANGE (2)
+ o REMOVE_SIP_SERVER (3)
+ */
+
+ struct dict_object *type;
+ struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-Reason-Code)" , NULL, NULL};
+ struct dict_enumval_data tvals[] = {
+ enumval_def_u32( 0, "PERMANENT_TERMINATION"),
+ enumval_def_u32( 1, "NEW_SIP_SERVER_ASSIGNED"),
+ enumval_def_u32( 2, "SIP_SERVER_CHANGE"),
+ enumval_def_u32( 3, "REMOVE_SIP_SERVER")
+ };
+ struct dict_avp_data data = {
+ 384, /* Code */
+ 0, /* Vendor */
+ "SIP-Reason-Code", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ int i;
+ /* Create the Enumerated type, enumerated values, and the AVP */
+ CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
+ for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
+ CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
+ }
+ CHECK_dict_new( DICT_AVP, &data , type, NULL);
+ }
+
+ /* SIP-Reason-Info */
+ {
+ /*
+ The SIP-Reason-Info AVP (AVP Code 385) is of type UTF8String and
+ contains textual information that can be rendered to the user, about
+ the reason for a deregistration.
+
+ */
+
+ struct dict_avp_data data = {
+ 385, /* Code */
+ 0, /* Vendor */
+ "SIP-Reason-Info", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+
+ /* SIP-Deregistration-Reason */
+ {
+ /*
+ The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped
+ and indicates the reason for a deregistration operation.
+
+ The SIP-Deregistration-Reason AVP is defined as follows (per the
+ grouped-avp-def of RFC 3588 [RFC3588]):
+
+ SIP-Deregistration-Reason ::= < AVP Header: 383 >
+ { SIP-Reason-Code }
+ [ SIP-Reason-Info ]
+ * [ AVP ]
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 383, /* Code */
+ 0, /* Vendor */
+ "SIP-Deregistration-Reason", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "SIP-Reason-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Reason-Info", RULE_OPTIONAL, -1, 1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+
+ /* SIP-Visited-Network-Id */
+ {
+ /*
+ The SIP-Visited-Network-Id AVP (AVP Code 386) is of type UTF8String.
+ This AVP contains an identifier that helps the home network identify
+ the visited network (e.g., the visited network domain name), in order
+ to authorize roaming to that visited network.
+
+ */
+
+ struct dict_avp_data data = {
+ 386, /* Code */
+ 0, /* Vendor */
+ "SIP-Visited-Network-Id", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+ /* SIP-User-Authorization-Type */
+ {
+ /*
+ The SIP-User-Authorization-Type AVP (AVP Code 387) is of type
+ Enumerated and indicates the type of user authorization being
+ performed in a User Authorization operation, i.e., the Diameter
+ User-Authorization-Request (UAR) command. The following values are
+ defined:
+
+ o REGISTRATION (0)
+ This value is used for initial registration or re-registration.
+ This is the default value.
+
+ o DEREGISTRATION (1)
+ This value is used for deregistration.
+
+ o REGISTRATION_AND_CAPABILITIES (2)
+ This value is used for initial registration or re-registration
+ when the SIP server explicitly requests the Diameter server to get
+ capability information. This capability information helps the SIP
+ server to allocate another SIP server to serve the user.
+
+ */
+
+ struct dict_object *type;
+ struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-User-Authorization-Type)" , NULL, NULL};
+ struct dict_enumval_data tvals[] = {
+ enumval_def_u32( 0, "REGISTRATION"),
+ enumval_def_u32( 1, "DEREGISTRATION"),
+ enumval_def_u32( 2, "REGISTRATION_AND_CAPABILITIES")
+ };
+ struct dict_avp_data data = {
+ 387, /* Code */
+ 0, /* Vendor */
+ "SIP-User-Authorization-Type", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ int i;
+ /* Create the Enumerated type, enumerated values, and the AVP */
+ CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
+ for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
+ CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
+ }
+ CHECK_dict_new( DICT_AVP, &data , type, NULL);
+ }
+ /* SIP-Supported-User-Data-Type */
+ {
+ /*
+ The SIP-Supported-User-Data-Type AVP (AVP Code 388) is of type
+ UTF8String and contains a string that identifies the type of
+ supported user data (user profile, see SIP-User-Data AVP
+ (Section 9.12)) supported in the node. The AVP can be repeated, if
+ the SIP server supports several user data types. In case of
+ repetition, the Diameter client should order the different instances
+ of this AVP according to its preferences.
+
+ When the Diameter client inserts this AVP in a SAR message, it allows
+ the Diameter client to provide an indication to the Diameter server
+ of the types of user data supported by the SIP server. The Diameter
+ server, upon inspection of these AVPs, will return a suitable
+ SIP-User-Data AVP (Section 9.12) of the type indicated in the
+ SIP-User-Data-Type AVP (Section 9.12.1).
+
+ */
+
+ struct dict_avp_data data = {
+ 388, /* Code */
+ 0, /* Vendor */
+ "SIP-Supported-User-Data-Type", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+ /* SIP-User-Data-Type */
+ {
+ /*
+ The SIP-User-Data-Type AVP (AVP Code 390) is of type UTF8String and
+ contains a string that identifies the type of user data included in
+ the SIP-User-Data-Type AVP (Section 9.12).
+
+ This document does not specify a convention to characterize the type
+ of user data contained in the SIP-User-Data-Type AVP (Section 9.12). It
+ is believed that in most cases this feature will be used in
+ environments controlled by a network administrator who can configure
+ both the client and server to assign the same value type at the
+ client and server. It is also RECOMMENDED that organizations
+ developing their own profile of SIP-User-Data-Type AVP (Section 9.12)
+ allocate a type based on their canonical DNS name. For instance,
+ organization "example.com" can define several types of SIP-User-Data
+ and allocate the types "type1.dsa.example.com",
+ "type2.dsa.example.com", and so on. This convention will avoid a
+ clash in the allocation of types of SIP-User-Data-Type AVP (Section 9.12).
+
+ */
+
+ struct dict_avp_data data = {
+ 390, /* Code */
+ 0, /* Vendor */
+ "SIP-User-Data-Type", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+ /* SIP-User-Data-Contents */
+ {
+ /*
+ The SIP-User-Data-Contents AVP (AVP Code 391) is of type OctetString.
+ The Diameter peers do not need to understand the value of this AVP.
+
+ The AVP contains the user profile data required for a SIP server to
+ give service to the user.
+
+
+ */
+
+ struct dict_avp_data data = {
+ 391, /* Code */
+ 0, /* Vendor */
+ "SIP-User-Data-Contents", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
+ }
+
+ /* SIP-User-Data */
+ {
+ /*
+ The SIP-User-Data AVP (AVP Code 389) is of type Grouped. This AVP
+ allows the Diameter server to transport user-specific data, such as a
+ user profile, to the SIP server (in the Diameter client). The
+ Diameter server selects a type of user data that is understood by the
+ SIP server in the Diameter client, and has been indicated in a
+ SIP-Supported-User-Data-Type AVP. In case the Diameter client
+ indicated support for several types of user data, the Diameter server
+ SHOULD choose the first type supported by the client.
+
+ The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP that
+ indicates the type of user data included in the
+ SIP-User-Data-Contents-AVP.
+
+ The SIP-User-Data AVP is defined as follows (per the grouped-avp-def
+ of RFC 3588 [RFC3588]):
+
+
+ SIP-User-Data ::= < AVP Header: 389 >
+ { SIP-User-Data-Type }
+ { SIP-User-Data-Contents }
+ * [ AVP ]
+
+ */
+ struct dict_object * avp;
+ struct dict_avp_data data = {
+ 389, /* Code */
+ 0, /* Vendor */
+ "SIP-User-Data", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_GROUPED /* base type of data */
+ };
+ struct local_rules_definition rules[] =
+ { { "SIP-User-Data-Type", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-User-Data-Contents", RULE_REQUIRED, -1, 1 }
+ };
+
+ CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
+ PARSE_loc_rules( rules, avp );
+ }
+ /* SIP-User-Data-Already-Available */
+ {
+ /*
+ The SIP-User-Data-Already-Available AVP (AVP Code 392) is of type
+ Enumerated and gives an indication to the Diameter server about
+ whether the Diameter client (SIP server) already received the portion
+ of the user profile needed in order to serve the user. The following
+ values are defined:
+
+ o USER_DATA_NOT_AVAILABLE (0)
+ The Diameter client (SIP server) does not have the data that it
+ needs to serve the user.
+
+ o USER_DATA_ALREADY_AVAILABLE (1)
+ The Diameter client (SIP server) already has received the data
+ that it needs to serve the user.
+
+
+ */
+
+ struct dict_object *type;
+ struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-User-Data-Already-Available)" , NULL, NULL};
+ struct dict_enumval_data tvals[] = {
+ enumval_def_u32( 0, "USER_DATA_NOT_AVAILABLE"),
+ enumval_def_u32( 1, "USER_DATA_ALREADY_AVAILABLE")
+ };
+ struct dict_avp_data data = {
+ 392, /* Code */
+ 0, /* Vendor */
+ "SIP-User-Data-Already-Available", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_UNSIGNED32 /* base type of data */
+ };
+ int i;
+ /* Create the Enumerated type, enumerated values, and the AVP */
+ CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
+ for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
+ CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
+ }
+ CHECK_dict_new( DICT_AVP, &data , type, NULL);
+ }
+ /* SIP-Method */
+ {
+ /*
+ The SIP-Method-AVP (AVP Code 393) is of type UTF8String and contains
+ the method of the SIP request that triggered the Diameter message.
+ The Diameter server MUST use this AVP solely for authorization of SIP
+ requests, and MUST NOT use it to compute the Digest authentication.
+ To compute the Digest authentication, the Diameter server MUST use
+ the Digest-Method AVP instead.
+
+
+ */
+
+ struct dict_avp_data data = {
+ 393, /* Code */
+ 0, /* Vendor */
+ "SIP-Method", /* Name */
+ AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
+ AVP_FLAG_MANDATORY, /* Fixed flag values */
+ AVP_TYPE_OCTETSTRING /* base type of data */
+ };
+ CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
+ }
+ /* Complement of Result-Code AVP values */
+ {
+ struct dict_object * resultcode_data_type;
+ CHECK_dict_search(DICT_TYPE,TYPE_BY_NAME,"Enumerated(Result-Code)",&resultcode_data_type);
+
+
+ {
+
+ /* Success */
+ {
+ /* 2003 */
+ {
+ /*
+ The user was not previously registered. The Diameter server has
+ now authorized the registration.
+ */
+ struct dict_enumval_data error_code = { "DIAMETER_FIRST_REGISTRATION", { .u32 = 2003 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 2004 */
+ {
+ /*
+ The user is already registered. The Diameter server has now
+ authorized the re-registration.
+
+ */
+ struct dict_enumval_data error_code = { "DIAMETER_SUBSEQUENT_REGISTRATION", { .u32 = 2004 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 2005 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_UNREGISTERED_SERVICE", { .u32 = 2005 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 2006 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED", { .u32 = 2006 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 2007 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_SERVER_SELECTION", { .u32 = 2007 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 2008 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED", { .u32 = 2008 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ }
+ /* Transient Failures */
+ {
+ /* 4013 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_USER_NAME_REQUIRED", { .u32 = 4013 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ }
+ /* Permanent Failures */
+ {
+ /* 5032 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_USER_UNKNOWN", { .u32 = 5032 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5033 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_IDENTITIES_DONT_MATCH", { .u32 = 5033 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5034 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_IDENTITY_NOT_REGISTERED", { .u32 = 5034 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5035 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_ROAMING_NOT_ALLOWED", { .u32 = 5035 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5036 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED", { .u32 = 5036 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5037 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED", { .u32 = 5037 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5038 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_IN_ASSIGNMENT_TYPE", { .u32 = 5038 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5039 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_TOO_MUCH_DATA", { .u32 = 5039 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ /* 5040 */
+ {
+ struct dict_enumval_data error_code = { "DIAMETER_ERROR_NOT SUPPORTED_USER_DATA", { .u32 = 5040 }};
+ CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
+ }
+ }
+ }
+
+
+ }
+ }
+ /* Command section */
+ {
+ /* User-Authorization-Request (UAR) Command */
+ {
+ /*
+ The User-Authorization-Request (UAR) is indicated by the Command-Code
+ set to 283 and the Command Flags' 'R' bit set. The Diameter client
+ in a SIP server sends this command to the Diameter server to request
+ authorization for the SIP User Agent to route a SIP REGISTER request.
+ Because the SIP REGISTER request implicitly carries a permission to
+ bind an AOR to a contact address, the Diameter client uses the
+ Diameter UAR as a first authorization request towards the Diameter
+ server to authorize the registration. For instance, the Diameter
+ server can verify that the AOR is a legitimate user of the realm.
+
+ The Diameter client in the SIP server requests authorization for one
+ of the possible values defined in the SIP-User-Authorization-Type AVP
+ (Section 9.10).
+
+ The user name used for authentication of the user is conveyed in a
+ User-Name AVP (defined in the Diameter base protocol, RFC 3588
+ [RFC3588]). The location of the authentication user name in the SIP
+ REGISTER request varies depending on the authentication mechanism.
+ When the authentication mechanism is HTTP Digest as defined in RFC
+ 2617 [RFC2617], the authentication user name is found in the
+ "username" directive of the SIP Authorization header field value.
+ This Diameter SIP application only provides support for HTTP Digest
+ authentication in SIP; other authentication mechanisms are not
+ currently supported.
+
+ The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP
+ (Section 9.8). Typically this SIP or SIPS URI is found in the To
+ header field value of the SIP REGISTER request that triggered the
+ Diameter UAR message.
+
+ The SIP-Visited-Network-Id AVP indicates the network that is
+ providing SIP services (e.g., SIP proxy functionality or any other
+ kind of services) to the SIP User Agent.
+
+ The Message Format of the UAR command is as follows:
+
+ <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 ]
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 283, /* Code */
+ "User-Authorization-Request", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-AOR", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Visited-Network-Id", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-User-Authorization-Type", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+
+ /* User-Authorization-Answer (UAA) Command */
+ {
+ /*
+ The User-Authorization-Answer (UAA) is indicated by the Command-Code
+ set to 283 and the Command Flags' 'R' bit cleared. The Diameter
+ server sends this command in response to a previously received
+ Diameter User-Authorization-Request (UAR) command. The Diameter
+ server indicates the result of the requested registration
+ authorization. Additionally, the Diameter server may indicate a
+ collection of SIP capabilities that assists the Diameter client to
+ select a SIP proxy to the AOR under registration.
+
+
+ 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 there is success in the process, the
+ Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter
+ UAA message.
+
+ If the Diameter server requires a User-Name AVP value to process the
+ Diameter UAR request, but the Diameter UAR message did not contain 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. Upon reception of this Diameter UAA
+ message with the Result-Code AVP value set to
+ DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
+ 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 is already aware of 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 due to the
+ possibility that the Diameter client (in the SIP server) allocates 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 does not recognize the user name received in the
+ User-Name AVP, the Diameter server 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 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.
+
+ 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
+ Diameter 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 in the Diameter UAR message. 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:
+
+ o If the Diameter server is not 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 does
+ not 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_REGISTRATION in 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 assists the
+ Diameter client (SIP server) to select an appropriate SIP server
+ for the user, according to the required capabilities.
+
+ o 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 to
+ DIAMETER_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 enables the
+ SIP server (Diameter client) to 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:
+
+ o 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_SUCCESS and MUST set the
+ SIP-Server-URI AVP value to the known SIP server, and return them
+ in the Diameter UAA message.
+
+ o 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 is as follows:
+
+ <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 ]
+
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 283, /* Code */
+ "User-Authorization-Answer", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Server-Capabilities", RULE_OPTIONAL, -1, 1 }
+ ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
+ ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+
+ /* Multimedia-Auth-Request (MAR) Command */
+ {
+ /*
+
+ The Multimedia-Auth-Request (MAR) command is indicated by the
+ Command-Code set to 286 and the Command Flags' 'R' bit set. The
+ Diameter client in a SIP server sends this command to the Diameter
+ server to request that the Diameter server authenticate and authorize
+ a user attempt to use some SIP service (in this context, 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 to the
+ Diameter server, so that 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 cases (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. The value of the AVP is
+ extracted from different places in SIP request, depending on the
+ semantics of the SIP request. For SIP REGISTER messages the SIP-AOR
+ AVP value indicates the intended public user identity under
+ registration, and it is the SIP or SIPS URI populated in the To
+ header field value (addr-spec as per RFC 3261 [RFC3261]) of the SIP
+ REGISTER request. For other types of SIP requests, such as INVITE,
+ SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the
+ intended destination of the request. This is typically populated in
+ the Request-URI of the SIP request. Extracting 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 require the SIP-AOR to be extracted 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 the
+ authentication information of the SIP request, 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 ]
+
+
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 286, /* Code */
+ "Multimedia-Auth-Request", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-AOR", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Method", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Number-Auth-Items", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Auth-Data-Item", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Multimedia-Auth-Answer (MAA) Command */
+ {
+ /*
+
+ The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set
+ to 286 and the Command Flags' 'R' bit cleared. The Diameter server
+ sends this command in response to a previously received Diameter
+ Multimedia-Auth-Request (MAR) command.
+
+ 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.
+
+ If the Diameter server requires a User-Name AVP value to process the
+ Diameter MAR request, but the Diameter MAR message did not contain 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 MAA message. The Diameter server MAY include a
+ SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs
+ with authentication information (e.g., a challenge). Upon reception
+ of this Diameter MAA message with the Result-Code AVP value set to
+ DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
+ authentication by generating a SIP 401 (Unauthorized) or SIP 407
+ (Proxy Authentication Required) response back to the originator.
+
+ If the User-Name AVP is present in the Diameter MAR message, 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 does not recognize the user name received in the
+ User-Name AVP, the Diameter server MUST build a Diameter
+ Multimedia-Auth-Answer (MAA) message and MUST set the Result-Code AVP
+ to DIAMETER_ERROR_USER_UNKNOWN.
+
+ If the SIP-Methods AVP value of the Diameter MAR message is set to
+ REGISTER and a User-Name AVP is present, then the Diameter server
+ MUST authorize that User-Name AVP value is able to use the 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
+ Multimedia-Auth-Answer (MAA) message.
+
+ Note: Correlation between User-Name and SIP-AOR AVP values is only
+ required for SIP REGISTER request, to prevent a user from
+ registering a SIP-AOR allocated to another user. In other types
+ of SIP requests (e.g., INVITE), the SIP-AOR indicates the intended
+ destination of the request, rather than the originator of it.
+
+ The Diameter server MUST verify whether the authentication scheme
+ (SIP-Authentication-Scheme AVP value) indicated in the grouped
+ SIP-Auth-Data-Item AVP is supported or not. If that authentication
+ scheme is not supported, then the Diameter server MUST set the
+ Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send
+ it in a Diameter Multimedia-Auth-Answer (MAA) message.
+
+ If the SIP-Number-Auth-Items AVP is present in the Diameter MAR
+ message, it indicates the number of authentication data items that
+ the Diameter client is requesting. It is RECOMMENDED that the
+ Diameter server, when building the Diameter MAA message, includes a
+ number of SIP-Auth-Data-Item AVPs that are a subset of the
+ authentication data items requested by the Diameter client in the
+ SIP-Number-Auth-Items AVP value of the Diameter MAR message.
+
+ If the SIP-Server-URI AVP is present in the Diameter MAR message,
+ then the Diameter server MUST compare the stored SIP server (assigned
+ to the user) with the SIP-Server-URI AVP value (received in the
+ Diameter MAR message). If they don't match, the Diameter 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 Diameter server shall clear the "authentication pending"
+ flag for the user.
+
+ In any other situation, if there is a success in processing the
+ Diameter MAR command and the Diameter server stored the
+ SIP-Server-URI, the Diameter server MUST set the Result-Code AVP
+ value to DIAMETER_SUCCESS and return it in a Diameter MAA message.
+
+ If there is a success in processing the Diameter MAR command, but the
+ Diameter server does not store the SIP-Server-URI because the AVP was
+ not present in the Diameter MAR command, then the Diameter server
+ MUST set the Result-Code AVP value to either:
+
+ 1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter
+ server is sending authentication credentials to create a
+ challenge.
+
+ 2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the Diameter server
+ successfully authenticated the user and authorized the SIP server
+ to proceed with the SIP request.
+
+ Otherwise, the Diameter server MUST set the Result-Code AVP value to
+ DIAMETER_UNABLE_TO_COMPLY, and it MUST NOT include any
+ SIP-Auth-Data-Item AVP.
+
+ The Message Format of the MAA command is as follows:
+
+ <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 ]
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 286, /* Code */
+ "Multimedia-Auth-Answer", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-AOR", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Number-Auth-Items", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Auth-Data-Item", RULE_OPTIONAL, -1, -1 }
+ ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
+ ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Server-Assignment-Request (SAR) Command */
+ {
+ /*
+
+ The Server-Assignment-Request (SAR) command is indicated by the
+ Command-Code set to 284 and the Command Flags' 'R' bit set. The
+ Diameter client in a SIP server sends this command to the Diameter
+ server to indicate the completion of the authentication process and
+ to request that the Diameter server store the URI of the SIP server
+ that is currently serving the user. The main functions of the
+ Diameter SAR command are to inform the Diameter server of the URI of
+ the SIP server allocated to the user, and to store or clear it from
+ the Diameter server. Additionally, the Diameter client can request
+ to download the user profile or part of it.
+
+ During the registration procedure, a SIP server becomes assigned to
+ the user. The Diameter client in the 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. The Diameter server then becomes aware of the
+ allocation of the SIP server to the user name and the server's URI.
+
+ The Diameter client in the SIP server MAY send a Diameter SAR message
+ because of other reasons. These reasons are identified in the
+ SIP-Server-Assignment-Type AVP (Section 9.4) value. For instance, a
+ Diameter client in a SIP server may contact the Diameter server to
+ request deregistration of a user, to inform the Diameter server of an
+ authentication failure, or just to download the user profile. For a
+ complete description of all the SIP-Server-Assignment-Type AVP
+ values, see Section 9.4.
+
+ Typically the reception of a SIP REGISTER request in a SIP server
+ will trigger the Diameter client in the SIP server to send the
+ Diameter SAR message. However, if a SIP server is receiving other
+ SIP request, such as INVITE, and the SIP server does not have the
+ user profile, the Diameter client in the SIP server may send the
+ Diameter SAR message to the Diameter server in order to download the
+ user profile and make the Diameter server aware of the SIP server
+ assigned to the user.
+ The user profile is an important piece of information that dictates
+ the behavior of the SIP server when triggering or providing services
+ for the user. Typically the user profile is divided into:
+
+ o Services to be rendered to the user when the user is registered
+ and initiates a SIP request.
+
+ o 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.
+
+ o 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 indicates the reason why the
+ Diameter client (SIP server) contacted the Diameter server. If the
+ Diameter client sets the SIP-Server-Assignment-Type AVP value to
+ REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT,
+ AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client
+ MUST include exactly one SIP-AOR AVP in the Diameter SAR message.
+
+ The SAR message MAY contain zero or more SIP-Supported-User-Data-Type
+ AVPs. Each of them contains a type of user data understood by the
+ SIP server. This allows the Diameter client to provide an indication
+ to the Diameter server of the different format of user data
+ understood by the SIP server. The Diameter server uses this
+ information to select one or more SIP-User-Data AVPs that will be
+ included in the SAA message.
+
+ The Message Format of the SAR command is as follows:
+
+ <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 ]
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 284, /* Code */
+ "Server-Assignment-Request", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Server-Assignment-Type", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-User-Data-Already-Available", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Supported-User-Data-Type", RULE_OPTIONAL, -1, -1 }
+ ,{ "SIP-AOR", RULE_OPTIONAL, -1, -1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Server-Assignment-Answer (SAA) Command */
+ {
+ /*
+
+ The Server-Assignment-Answer (SAA) is indicated by the Command-Code
+ set to 284 and the Command Flags' 'R' bit cleared. The Diameter
+ server sends this command in response to a previously received
+ Diameter Server-Assignment-Request (SAR) command. The response may
+ include the user profile or part of it, if requested.
+
+ 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.
+
+ The Result-Code AVP value in the Diameter SAA message may indicate a
+ success or an error in the execution of the Diameter SAR command. If
+ Result-Code AVP value in the Diameter SAA message does not contain an
+ error code, the SAA message MAY include one or more SIP-User-Data
+ AVPs that typically contain the profile of the user, indicating
+ services that the SIP server can provide to that user.
+
+ The Diameter server MAY include one or more
+ SIP-Supported-User-Data-Type AVPs, each one identifying a type of
+ user data format supported in the Diameter server. If there is not a
+ common supported user data type between the Diameter client and the
+ Diameter server, the Diameter server SHOULD declare its list of
+ supported user data types by including one or more
+ SIP-Supported-User-Data-Type AVPs in a Diameter SAA message. This
+ indication is merely for debugging reasons, since there is not a
+ fallback mechanism that allows the Diameter client to retrieve the
+ profile in a supported format.
+
+ If the Diameter server requires a User-Name AVP value to process the
+ Diameter SAR request, but the Diameter SAR message did not contain 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 SAA message. Upon reception of this Diameter SAA
+ message with the Result-Code AVP value set to
+ DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
+ authentication by generating a SIP 401 (Unauthorized) or SIP 407
+ (Proxy Authentication Required) response back to the originator.
+
+ If the User-Name AVP is included in the Diameter SAR message, upon
+ reception of the Diameter SAR message, 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
+ does not recognize the user name received in the User-Name AVP, the
+ Diameter server MUST build a Diameter Server-Assignment-Answer (SAA)
+ message and MUST set the Result-Code AVP to
+ DIAMETER_ERROR_USER_UNKNOWN.
+ Then the Diameter server MUST authorize that User-Name AVP value is a
+ valid authentication name for the SIP or SIPS URI included in the
+ SIP-AOR AVP of the Diameter SAR message. 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
+ Server-Assignment-Answer (SAA) message.
+
+ After successful execution of the Diameter SAR command, the Diameter
+ server MUST clear the "authentication pending" flag and SHOULD move
+ the temporarily stored SIP server URI to permanent storage.
+
+ The actions of the Diameter server upon reception of the Diameter SAR
+ message depend on the value of the SIP-Server-Assignment-Type:
+
+ o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
+ message is set to REGISTRATION or RE_REGISTRATION, the Diameter
+ server SHOULD verify that there is only one SIP-AOR AVP.
+ Otherwise, the Diameter server MUST answer with a Diameter SAA
+ message with the Result-Code AVP value set to
+ DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any
+ SIP-User-Data AVP. If there is only one SIP-AOR AVP and if the
+ SIP-User-Data-Already-Available AVP value is set to
+ USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
+ one or more 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 value of the Diameter SAA message. On selecting
+ the type of user data, the Diameter server SHOULD take into
+ account the supported formats at the SIP server
+ (SIP-Supported-User-Data-Type AVP in the SAR message) and the
+ local policy. Additionally, the Diameter server MUST set the
+ Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
+ message. The Diameter server considers the SIP AOR authenticated
+ and registered.
+
+ o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
+ message is set to UNREGISTERED_USER, then the Diameter server MUST
+ store the SIP server address included in the SIP-Server-URI AVP
+ value. The Diameter server will return the SIP server address in
+ Diameter Location-Info-Answer (LIA) messages. If the
+ SIP-User-Data-Already-Available AVP value is set to
+ USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
+ one or more user profile data associated with the SIP or SIPS URI
+ (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP
+ value of the Diameter SAA message. On selecting the type of user
+ data, the Diameter server SHOULD take into account the supported
+ formats at the SIP server (SIP-Supported-User-Data-Type AVP in the
+ SAR message) and the local policy. The Diameter server MUST set
+ the Result-Code AVP value to DIAMETER_SUCCESS. The Diameter
+ server considers the SIP AOR UNREGISTERED, but with a SIP server
+ allocated to trigger and provide services for unregistered users.
+ Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type
+ AVP), the Diameter server MUST verify that there is only one
+ SIP-AOR AVP. Otherwise, the Diameter server MUST answer the
+ Diameter SAR message with a Diameter SAA message, and it MUST set
+ the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES
+ and MUST NOT include any SIP-User-Data AVP.
+ If the User-Name AVP was not present in the Diameter SAR message
+ and the SIP-AOR is not known for the Diameter server, the Diameter
+ server MUST NOT include a User-Name AVP in the Diameter SAA
+ message and MUST set the Result-Code AVP value to
+ DIAMETER_ERROR_USER_UNKNOWN.
+
+ o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
+ message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION,
+ DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION,
+ the Diameter server MUST clear the SIP server address associated
+ with all SIP AORs indicated in each of the SIP-AOR AVP values
+ included in the Diameter SAR message. The Diameter server
+ considers all of these SIP AORs as not registered. The Diameter
+ server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in
+ the Diameter SAA message.
+
+ o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
+ message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or
+ USER_DEREGISTRATION_STORE_SERVER_NAME, the Diameter server MAY
+ keep the SIP server address associated with the SIP AORs included
+ in the SIP-AOR AVP values of the Diameter SAR message, even though
+ the SIP AORs become unregistered. This feature allows a SIP
+ server to request that the Diameter server remain an assigned SIP
+ server for those SIP AORs (SIP-AOR AVP values) allocated to the
+ same user name, and avoid SIP server assignment. The Diameter
+ server MUST consider all these SIP AORs as not registered. If the
+ Diameter server honors the request of the Diameter client (SIP
+ server) to remain as an allocated SIP server, then the Diameter
+ server MUST keep the SIP server assigned to those SIP AORs
+ allocated to the username and MUST set the Result-Code AVP value
+ to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, when
+ the Diameter server does not honor the request of the Diameter
+ client (SIP server) to remain as an allocated SIP server, the
+ Diameter server MUST clear the SIP server name assigned to those
+ SIP AORs and it MUST set the Result-Code AVP value to
+ DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA
+ message.
+ o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
+ message is set to NO_ASSIGNMENT, the Diameter server SHOULD first
+ verify that the SIP-Server-URI AVP value in the Diameter SAR
+ message is the same URI as the one assigned to the SIP-AOR AVP
+ value. If they differ, then the Diameter server MUST set the
+ Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter
+ SAA message. Otherwise, if the SIP-User-Data-Already-Available
+ AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter
+ 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 value of the Diameter SAA
+ message. On selecting the type of user data, the Diameter server
+ SHOULD take into account the supported formats at the SIP server
+ (SIP-Supported-User-Data-Type AVP in the SAR message) and the
+ local policy.
+
+ o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
+ message is set to AUTHENTICATION_FAILURE or
+ AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there
+ is exactly one SIP-AOR AVP in the Diameter SAR message. If the
+ number of occurrences of the SIP-AOR AVP is not exactly one, the
+ Diameter server MUST set the Result-Code AVP value to
+ DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message,
+ and SHOULD not take further actions. If there is exactly one
+ SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST
+ clear the address of the SIP server assigned to the SIP AOR
+ allocated to the user name, and the Diameter server MUST set the
+ Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
+ message. The Diameter server MUST consider the SIP AOR as not
+ registered.
+
+ The Message Format of the SAA command is as follows:
+
+ <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 ]
+
+
+
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 284, /* Code */
+ "Server-Assignment-Answer", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-User-Data", RULE_OPTIONAL, -1, -1 }
+ ,{ "SIP-Accounting-Information", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Supported-User-Data-Type", RULE_OPTIONAL, -1, -1 }
+ ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
+ ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
+ ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Location-Info-Request (LIR) Command */
+ {
+ /*
+
+ The Location-Info-Request (LIR) is indicated by the Command-Code set
+ to 285 and the Command Flags' 'R' bit set. The Diameter client in a
+ SIP server sends this command to the Diameter server to request
+ routing information, e.g., the URI of the SIP server assigned to the
+ SIP-AOR AVP value allocated to the users.
+
+ The Message Format of the LIR command is as follows:
+
+ <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 ]
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 285, /* Code */
+ "Location-Info-Request", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-AOR", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Location-Info-Answer (LIA) Command */
+ {
+ /*
+ The Location-Info-Answer (LIA) is indicated by the Command-Code set
+ to 285 and the Command Flags' 'R' bit cleared. The Diameter server
+ sends this command in response to a previously received Diameter
+ Location-Info-Request (LIR) command.
+
+ 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. When the Diameter server finds an error in processing
+ the Diameter LIR message, the Diameter server MUST stop the process
+ of the message and answer with a Diameter LIA message that includes
+ the appropriate error code in the Result-Code AVP value. When there
+ is no error, the Diameter server MUST set the Result-Code AVP value
+ to DIAMETER_SUCCESS in the Diameter LIA message.
+
+ One of the errors that the Diameter server may find is that the
+ SIP-AOR AVP value is not a valid user in the realm. In such cases,
+ the Diameter server MUST set the Result-Code AVP value to
+ DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message.
+
+ If the Diameter server cannot process the Diameter LIR command, e.g.,
+ due to a database error, the Diameter server MUST set the Result-Code
+ AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter
+ LIA message. The Diameter server MUST NOT include any SIP-Server-URI
+ or SIP-Server-Capabilities AVP in the Diameter LIA message.
+
+ The Diameter server may or may not be aware of a SIP server assigned
+ to the SIP-AOR AVP value included in the Diameter LIR message. If
+ the Diameter server is aware of a SIP server allocated to that
+ particular user, the Diameter server MUST include the URI of such SIP
+ server in the SIP-Server-URI AVP and return it in a Diameter LIA
+ message. This is typically the situation when the user is either
+ registered, or unregistered but a SIP server is still assigned to the
+ user.
+
+ When the Diameter server is not aware of a SIP server allocated to
+ the user (typically the case when the user unregistered), the
+ Result-Code AVP value in the Diameter LIA message depends on whether
+ the Diameter server is aware that the user has services defined for
+ unregistered users:
+
+ o Those users who have services defined for unregistered users may
+ require the allocation of a SIP server to trigger and perhaps
+ execute those services. Therefore, when the Diameter server is
+ not aware of an assigned SIP server, but the user has services
+ defined for unregistered users, the Diameter server MUST set the
+ Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return
+ it in a Diameter LIA message. The Diameter server MAY also
+ include a SIP-Server-Capabilities AVP to facilitate the SIP server
+ (Diameter client) with the selection of an appropriate SIP server
+ with the required capabilities. Absence of the SIP-Server-
+ Capabilities AVP indicates to the SIP server (Diameter client)
+ that any SIP server is suitable to be allocated for the user.
+
+ o Those users who do not have service defined for unregistered users
+ do not require further processing. The Diameter server MUST set
+ the Result-Code AVP value to
+ DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the
+ Diameter client in a Diameter LIA message. The SIP server
+ (Diameter client) may return 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 ]
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 285, /* Code */
+ "Location-Info-Answer", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-Server-Capabilities", RULE_OPTIONAL, -1, 1 }
+ ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
+ ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Registration-Termination-Request (RTR) Command */
+ {
+ /*
+ The Registration-Termination-Request (RTR) command is indicated by
+ the Command-Code set to 287 and the Command Flags' 'R' bit set. The
+ Diameter server sends this command to the Diameter client in a SIP
+ server to indicate to the SIP server that one or more SIP AORs have
+ to be deregistered. The command allows an operator to
+ administratively cancel the registration of a user from a centralized
+ Diameter server.
+
+ The Diameter server has the capability to initiate the deregistration
+ of a user and inform the SIP server by means of the Diameter RTR
+ command. The Diameter server can decide whether only one SIP AOR is
+ going to be deregistered, a list of SIP AORs, or all the SIP AORs
+ allocated to the user.
+
+ The absence of a SIP-AOR AVP in the Diameter RTR message indicates
+ that all the SIP AORs allocated to the user identified by the
+ User-Name AVP are being deregistered.
+
+ The Diameter server MUST include a SIP-Deregistration-Reason AVP
+ value to indicate the reason for the deregistration.
+
+ The Message Format of the RTR command is as follows:
+
+ <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 ]
+
+
+
+
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 287, /* Code */
+ "Registration-Termination-Request", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-Deregistration-Reason",RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Realm", RULE_OPTIONAL, -1, 1 }
+ ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
+ ,{ "SIP-AOR", RULE_REQUIRED, -1, -1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Registration-Termination-Answer (RTA) Command */
+ {
+ /*
+ The Registration-Termination-Answer (RTA) is indicated by the
+ Command-Code set to 287 and the Command Flags' 'R' bit cleared. The
+ Diameter client sends this command in response to a previously
+ received Diameter Registration-Termination-Request (RTR) command.
+
+ 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.
+
+ If the SIP server (Diameter client) requires a User-Name AVP value to
+ process the Diameter RTR request, but the Diameter RTR message did
+ not contain a User-Name AVP value, the Diameter client MUST set the
+ Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section
+ 10.1.2) and return it in a Diameter RTA message.
+
+ The SIP server (Diameter client) applies the administrative
+ deregistration to each of the URIs included in each of the SIP-AOR
+ AVP values, or, if there is no SIP-AOR AVP present in the Diameter
+ RTR request, to all the URIs allocated to the User-Name AVP value.
+
+ The value of the SIP-Deregistration-Reason AVP in the Diameter RTR
+ command has an effect on the actions performed at the SIP server
+ (Diameter client):
+
+ o If the value is set to PERMANENT_TERMINATION, then the user has
+ terminated his/her registration to the realm. If informing the
+ interested parties (e.g., subscribers to the "reg" event
+ [RFC3680]) about the administrative deregistration is supported
+ through SIP procedures, the SIP server (Diameter client) will do
+ so. 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.
+
+ o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter
+ server informs the SIP server (Diameter client) that a new SIP
+ server has been allocated to the user, due to some reason. The
+ SIP server, if supported through SIP procedures, will inform the
+ interested parties (e.g., 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.
+
+ o If the value is set to SIP_SERVER_CHANGE, the Diameter server
+ informs the SIP server (Diameter client) that a new SIP server has
+ to be allocated to the user, e.g., due to user's capabilities
+ requiring a new SIP server, or not enough resources in the current
+ SIP server. If informing the interested parties about the
+ administrative deregistration is supported through SIP procedures
+ (e.g., subscriptions to the "reg" event [RFC3680]), the SIP server
+ will do so. 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.
+
+ o If the value is set to REMOVE_SIP_SERVER, the Diameter server
+ informs the SIP server (Diameter client) that the SIP server will
+ no longer be bound in the Diameter server with that user. The SIP
+ server can delete all data related to the user.
+
+ The Message Format of the RTA command is as follows:
+
+ <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 ]
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 287, /* Code */
+ "Registration-Termination-Answer", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
+ ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+
+ /* Push-Profile-Request (PPR) Command */
+ {
+ /*
+ The Push-Profile-Request (PPR) command is indicated by the
+ Command-Code set to 288 and the Command Flags' 'R' bit set. The
+ Diameter server sends this command to the Diameter client in a SIP
+ server to update either the user profile of an already registered
+ user in that SIP server or the SIP accounting information. This
+ allows an operator to modify the data of a user profile or the
+ accounting information and push it to the SIP server where the user
+ is registered.
+
+ Each user has a user profile associated with him/her and other
+ accounting information. The profile or the accounting information
+ may change with time, e.g., due to addition of new services to the
+ user. When the user profile or the accounting information changes,
+ the Diameter server sends a Diameter Push-Profile-Request (PPR)
+ command to the Diameter client in a SIP server, in order to start
+ applying those new services.
+
+ A PPR command MAY contain a SIP-Accounting-Information AVP that
+ updates the addresses of the accounting servers. Changes in the
+ addresses of the accounting servers take effect immediately. The
+ Diameter client SHOULD close any existing accounting session with the
+ existing server and start providing accounting information to the
+ newly acquired accounting server.
+
+ A PPR command MAY contain zero or more SIP-User-Data AVP values
+ containing the new user profile. On selecting the type of user data,
+ the Diameter server SHOULD take into account the supported formats at
+ the SIP server (SIP-Supported-User-Data-Type AVP sent in a previous
+ SAR message) and the local policy.
+
+ The User-Name AVP indicates the user to whom the profile is
+ applicable.
+
+ The Message Format of the PPR command is as follows:
+
+ <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 ]
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 288, /* Code */
+ "Push-Profile-Request", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "User-Name", RULE_REQUIRED, -1, 1 }
+ ,{ "SIP-User-Data", RULE_OPTIONAL, -1, -1 }
+ ,{ "SIP-Accounting-Information", RULE_OPTIONAL, -1, 1 }
+ ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
+ ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ /* Push-Profile-Answer (PPA) Command */
+ {
+ /*
+
+
+ The Push-Profile-Answer (PPA) is indicated by the Command-Code set to
+ 288 and the Command Flags' 'R' bit cleared. The Diameter client
+ sends this command in response to a previously received Diameter
+ Push-Profile-Request (PPR) command.
+
+ 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.
+
+ If there is no error when processing the received Diameter PPR
+ message, the SIP server (Diameter client) MUST download the received
+ user profile from the SIP-User-Data AVP values in the Diameter PPR
+ message and store it associated with the user specified in the
+ User-Name AVP value.
+
+ If the SIP server does not recognize or does not support some of the
+ data transferred in the SIP-User-Data AVP values, the Diameter client
+ in the SIP server MUST return a Diameter PPA message that includes a
+ Result-Code AVP set to the value DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.
+
+ If the SIP server (Diameter client) receives a Diameter PPR message
+ with a User-Name AVP that is unknown, the Diameter client MUST set
+ the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and MUST
+ return it to the Diameter server in a Diameter PPA message.
+
+ If the SIP server (Diameter client) receives in the
+ SIP-User-Data-Content AVP value (of the grouped SIP-User-Data AVP)
+ more data than it can accept, it MUST set the Result-Code AVP value
+ to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter
+ server in a Diameter PPA message. The SIP server MUST NOT override
+ the existing user profile with the one received in the PPR message.
+
+ If the Diameter server receives the Result-Code AVP value set to
+ DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD
+ force a new re-registration of the user by sending to the Diameter
+ client a Diameter Registration-Termination-Request (RTR) with the
+ SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This
+ will force a re-registration of the user and will trigger a selection
+ of a new SIP server.
+
+ If the Diameter client is not able to honor the command, for any
+ other reason, it MUST set the Result-Code AVP value to
+ DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA
+ message.
+
+ The Message Format of the PPA command is as follows:
+
+ <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 ]
+
+
+
+ */
+ struct dict_object * cmd;
+ struct dict_cmd_data data = {
+ 288, /* Code */
+ "Push-Profile-Answer", /* Name */
+ CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
+ CMD_FLAG_PROXIABLE /* Fixed flag values */
+ };
+ struct local_rules_definition rules[] =
+ { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
+ ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
+ ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
+ ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
+ ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
+ ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
+ ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
+ ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
+ ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
+
+ };
+
+ CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
+ PARSE_loc_rules( rules, cmd );
+ }
+ }
+
+ LOG_D( "Extension 'Dictionary definitions for SIP' initialized");
+ return 0;
+}
+EXTENSION_ENTRY("dict_sip", ds_dict_init);