/*********************************************************************************************************
* 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);