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