Gitiles
Code Review Sign In
gerrit.opencord.org / freeDiameter-old / 13b0e7de0d66906d50e074a339f890d6e59813ad / . / contrib / CxDx / dict_cxdx.c
blob: dd58c8d81af3597d6da543631887b54220f56ddc [file] [log] [blame]
/*********************************************************************************************************
* Software License Agreement (BSD License) *
* Author: Norberto R. de Goes Jr. *
* *
* Copyright (c) 2011, Norberto R. de Goes Jr.. *
* *
* 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. *
*********************************************************************************************************/
/*********************************************************************************************************
=== CpqD/DRC - Projeto ADRIMS - Mar/2011 ===
=== Dicionario Dx/Cx ===
Baseado no "dict_sip" do FreeDiameter (www.freediameter.net)
Norberto R Goes Jr
*********************************************************************************************************/
#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, _avp_search_flag) { \
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_search_flag, \
(_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 cxdx_dict_init(char * conffile)
{
#define VENDOR_3GPP_Id 10415
struct dict_object * vendor_dict;
{
struct dict_vendor_data vendor_data = { VENDOR_3GPP_Id, "3GPP" };
CHECK_dict_new (DICT_VENDOR, &vendor_data, NULL, &vendor_dict);
}
struct dict_object * cxdx_dict;
{
struct dict_application_data data = { 16777216 /* NRGJ */, "Diameter CxDx Application" };
CHECK_dict_new (DICT_APPLICATION, &data, vendor_dict, &cxdx_dict);
}
/* ##### 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: */
/* Visited-Network-Identifier */
{
struct dict_avp_data data =
{
600, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Visited-Network-Identifier", /* Name */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_OCTETSTRING /* base type of data */
};
CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
}
/* Public-Identity */
{
struct dict_avp_data data =
{
601, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Public-Identity", /* Name */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_OCTETSTRING /* base type of data */
};
CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
}
/* Server-Name */
{
struct dict_avp_data data =
{
602, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Server-Name", /* Name */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_OCTETSTRING /* base type of data */
};
CHECK_dict_new( DICT_AVP, &data , DiameterURI_type/*UTF8String_type*/, NULL);
}
/* Optional-Capability */
{
struct dict_avp_data data =
{
605, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Optional-Capability", /* Name */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_UNSIGNED32 /* base type of data */
};
CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
}
/* Feature-List-ID */
{
struct dict_avp_data data =
{
629, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Feature-List-ID", /* Name */
AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_UNSIGNED32 /* base type of data */
};
CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
}
/* Feature-List */
{
struct dict_avp_data data =
{
630, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Feature-List", /* 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);
}
/* Server-Capabilities */
{
struct dict_object * avp;
struct dict_avp_data data =
{
603, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Server-Capabilities", /* Name */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_GROUPED /* base type of data */
};
struct local_rules_definition rules[] =
{
{ "Vendor-Id", RULE_REQUIRED, -1, 1 },
{ "Feature-List-ID", RULE_REQUIRED, -1, 1 },
{ "Feature-List", RULE_REQUIRED, -1, 1 }
};
CHECK_dict_new (DICT_AVP, &data , NULL, &avp);
PARSE_loc_rules(rules, avp, AVP_BY_NAME_ALL_VENDORS );
}
/* User-Authorization-Type */
{
struct dict_avp_data data =
{
623, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"User-Authorization-Type", /* Name */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flags */
AVP_FLAG_MANDATORY | AVP_FLAG_VENDOR, /* Fixed flag values */
AVP_TYPE_OCTETSTRING /* base type of data */
};
CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
}
/* Supported-Features */
{
struct dict_object * avp;
struct dict_avp_data data =
{
628, /* Code */
VENDOR_3GPP_Id, /* Vendor */
"Supported-Features", /* 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[] =
{
{ "Vendor-Id", RULE_REQUIRED, -1, 1 },
{ "Feature-List-ID", RULE_REQUIRED, -1, 1 },
{ "Feature-List", RULE_REQUIRED, -1, 1 }
};
CHECK_dict_new (DICT_AVP, &data , NULL, &avp);
PARSE_loc_rules(rules, avp, AVP_BY_NAME_ALL_VENDORS );
}
} /* end AVP section */
/* ### 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: 300, REQ, PXY, 16777216 >
< Session-Id >
{ Vendor-Specific-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
{ Public-Identity }
{ Visited-Network-Identifier }
[ User-Authorization-Type ]
[ UAR-Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*/
struct dict_object * cmd;
struct dict_cmd_data data =
{
300, /* 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 },
{ "Vendor-Specific-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_OPTIONAL, -1, 1 },
{ "Destination-Realm", RULE_REQUIRED, -1, 1 },
{ "User-Name", RULE_REQUIRED, -1, 1 },
// { "Supported-Features", RULE_OPTIONAL, -1, -1 },
{ "Public-Identity", RULE_REQUIRED, -1, 1 },
{ "Visited-Network-Identifier", RULE_REQUIRED, -1, 1 },
// { "UAR-Flags", RULE_OPTIONAL, -1, 1 },
// { "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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME_ALL_VENDORS);
}
/* 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 =
{
300, /* 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 },
{ "Proxy-Info", RULE_OPTIONAL, -1, -1 },
{ "Route-Record", RULE_OPTIONAL, -1, -1 }
};
CHECK_dict_new( DICT_COMMAND, &data , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
#if 0 /* TODO - NRGJ : alterar conforme RFC-3GPP : */
/* 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 =
{
303, /* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
/* 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 , cxdx_dict, &cmd);
PARSE_loc_rules( rules, cmd, AVP_BY_NAME );
}
#endif /* TODO - NRGJ */
} /* end Command section */
TRACE_DEBUG(INFO, "Extension 'Dictionary CxDx' initialized");
return 0;
}
EXTENSION_ENTRY("dict_cxdx", cxdx_dict_init);