1 /*********************************************************************************************************
2 * Software License Agreement (BSD License) *
3 * Author: Alexandre Westfahl <awestfahl@freediameter.net> *
4 * *
5 * Copyright (c) 2010, Alexandre Westfahl, Teraoka Laboratory (Keio University), and the WIDE Project. * *
6 * All rights reserved. *
7 * *
8 * Redistribution and use of this software in source and binary forms, with or without modification, are *
9 * permitted provided that the following conditions are met: *
10 * *
11 * * Redistributions of source code must retain the above *
12 * copyright notice, this list of conditions and the *
13 * following disclaimer. *
14 * *
15 * * Redistributions in binary form must reproduce the above *
16 * copyright notice, this list of conditions and the *
17 * following disclaimer in the documentation and/or other *
18 * materials provided with the distribution. *
19 * *
20 * * Neither the name of the Teraoka Laboratory nor the *
21 * names of its contributors may be used to endorse or *
22 * promote products derived from this software without *
23 * specific prior written permission of Teraoka Laboratory *
24 * *
25 * *
26 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED *
27 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A *
28 * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR *
29 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT *
30 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS *
31 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR *
32 * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF *
33 * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. *
34 *********************************************************************************************************/
35
36 #include <freeDiameter/extension.h>
37
38
39
40 /* The content of this file follows the same structure as dict_base_proto.c */
41
42 #define CHECK_dict_new( _type, _data, _parent, _ref ) \
43 CHECK_FCT( fd_dict_new( fd_g_config->cnf_dict, (_type), (_data), (_parent), (_ref)) );
44
45 #define CHECK_dict_search( _type, _criteria, _what, _result ) \
46 CHECK_FCT( fd_dict_search( fd_g_config->cnf_dict, (_type), (_criteria), (_what), (_result), ENOENT) );
47
48 struct local_rules_definition {
49 char *avp_name;
50 enum rule_position position;
51 int min;
52 int max;
53 };
54
55 #define RULE_ORDER( _position ) ((((_position) == RULE_FIXED_HEAD) || ((_position) == RULE_FIXED_TAIL)) ? 1 : 0 )
56
57 #define PARSE_loc_rules( _rulearray, _parent) { \
58 int __ar; \
59 for (__ar=0; __ar < sizeof(_rulearray) / sizeof((_rulearray)[0]); __ar++) { \
60 struct dict_rule_data __data = { NULL, \
61 (_rulearray)[__ar].position, \
62 0, \
63 (_rulearray)[__ar].min, \
64 (_rulearray)[__ar].max}; \
65 __data.rule_order = RULE_ORDER(__data.rule_position); \
66 CHECK_FCT( fd_dict_search( \
67 fd_g_config->cnf_dict, \
68 DICT_AVP, \
69 AVP_BY_NAME, \
70 (_rulearray)[__ar].avp_name, \
71 &__data.rule_avp, 0 ) ); \
72 if ( !__data.rule_avp ) { \
73 TRACE_DEBUG(INFO, "AVP Not found: '%s'", (_rulearray)[__ar].avp_name ); \
74 return ENOENT; \
75 } \
76 CHECK_FCT_DO( fd_dict_new( fd_g_config->cnf_dict, DICT_RULE, &__data, _parent, NULL), \
77 { \
78 TRACE_DEBUG(INFO, "Error on rule with AVP '%s'", \
79 (_rulearray)[__ar].avp_name ); \
80 return EINVAL; \
81 } ); \
82 } \
83 }
84
85 #define enumval_def_u32( _val_, _str_ ) \
86 { _str_, { .u32 = _val_ }}
87
88 #define enumval_def_os( _len_, _val_, _str_ ) \
89 { _str_, { .os = { .data = (unsigned char *)_val_, .len = _len_ }}}
90
91
92
ds_dict_init(char * conffile)93 int ds_dict_init(char * conffile)
94 {
95 struct dict_object * sip;
96 {
97 struct dict_application_data data = { 6, "Diameter Session Initiation Protocol (SIP) Application" };
98 CHECK_dict_new( DICT_APPLICATION, &data , NULL, &sip);
99 }
100
101 /* AVP section */
102 {
103 struct dict_object * UTF8String_type;
104 struct dict_object * DiameterURI_type;
105
106 CHECK_dict_search( DICT_TYPE, TYPE_BY_NAME, "UTF8String", &UTF8String_type);
107 CHECK_dict_search( DICT_TYPE, TYPE_BY_NAME, "DiameterURI", &DiameterURI_type);
108
109 /* Digest AVPs (from RADIUS) */
110
111 /* Digest-Response */
112 {
113 /*
114
115 */
116
117 struct dict_avp_data data = {
118 103, /* Code */
119 0, /* Vendor */
120 "Digest-Response", /* Name */
121 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
122 AVP_FLAG_MANDATORY, /* Fixed flag values */
123 AVP_TYPE_OCTETSTRING /* base type of data */
124 };
125 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
126 }
127
128 /* Digest-Realm */
129 {
130 /*
131
132 */
133
134 struct dict_avp_data data = {
135 104, /* Code */
136 0, /* Vendor */
137 "Digest-Realm", /* Name */
138 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
139 AVP_FLAG_MANDATORY, /* Fixed flag values */
140 AVP_TYPE_OCTETSTRING /* base type of data */
141 };
142 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
143 }
144
145 /* Digest-Nonce */
146 {
147 /*
148
149 */
150
151 struct dict_avp_data data = {
152 105, /* Code */
153 0, /* Vendor */
154 "Digest-Nonce", /* Name */
155 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
156 AVP_FLAG_MANDATORY, /* Fixed flag values */
157 AVP_TYPE_OCTETSTRING /* base type of data */
158 };
159 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
160 }
161
162 /* Digest-Response-Auth */
163 {
164 /*
165
166 */
167
168 struct dict_avp_data data = {
169 106, /* Code */
170 0, /* Vendor */
171 "Digest-Response-Auth", /* Name */
172 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
173 AVP_FLAG_MANDATORY, /* Fixed flag values */
174 AVP_TYPE_OCTETSTRING /* base type of data */
175 };
176 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
177 }
178
179 /* Digest-Nextnonce */
180 {
181 /*
182
183 */
184
185 struct dict_avp_data data = {
186 107, /* Code */
187 0, /* Vendor */
188 "Digest-Nextnonce", /* Name */
189 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
190 AVP_FLAG_MANDATORY, /* Fixed flag values */
191 AVP_TYPE_OCTETSTRING /* base type of data */
192 };
193 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
194 }
195
196 /* Digest-Method */
197 {
198 /*
199
200 */
201
202 struct dict_avp_data data = {
203 108, /* Code */
204 0, /* Vendor */
205 "Digest-Method", /* Name */
206 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
207 AVP_FLAG_MANDATORY, /* Fixed flag values */
208 AVP_TYPE_OCTETSTRING /* base type of data */
209 };
210 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
211 }
212
213 /* Digest-URI */
214 {
215 /*
216
217 */
218
219 struct dict_avp_data data = {
220 109, /* Code */
221 0, /* Vendor */
222 "Digest-URI", /* Name */
223 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
224 AVP_FLAG_MANDATORY, /* Fixed flag values */
225 AVP_TYPE_OCTETSTRING /* base type of data */
226 };
227 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
228 }
229
230 /* Digest-QoP */
231 {
232 /*
233
234 */
235
236 struct dict_avp_data data = {
237 110, /* Code */
238 0, /* Vendor */
239 "Digest-QoP", /* Name */
240 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
241 AVP_FLAG_MANDATORY, /* Fixed flag values */
242 AVP_TYPE_OCTETSTRING /* base type of data */
243 };
244 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
245 }
246
247 /* Digest-Algorithm */
248 {
249 /*
250
251 */
252
253 struct dict_avp_data data = {
254 111, /* Code */
255 0, /* Vendor */
256 "Digest-Algorithm", /* Name */
257 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
258 AVP_FLAG_MANDATORY, /* Fixed flag values */
259 AVP_TYPE_OCTETSTRING /* base type of data */
260 };
261 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
262 }
263
264 /* Digest-Entity-Body-Hash */
265 {
266 /*
267
268 */
269
270 struct dict_avp_data data = {
271 112, /* Code */
272 0, /* Vendor */
273 "Digest-Entity-Body-Hash", /* Name */
274 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
275 AVP_FLAG_MANDATORY, /* Fixed flag values */
276 AVP_TYPE_OCTETSTRING /* base type of data */
277 };
278 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
279 }
280
281 /* Digest-CNonce */
282 {
283 /*
284
285 */
286
287 struct dict_avp_data data = {
288 113, /* Code */
289 0, /* Vendor */
290 "Digest-CNonce", /* Name */
291 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
292 AVP_FLAG_MANDATORY, /* Fixed flag values */
293 AVP_TYPE_OCTETSTRING /* base type of data */
294 };
295 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
296 }
297
298 /* Digest-Nonce-Count */
299 {
300 /*
301
302 */
303
304 struct dict_avp_data data = {
305 114, /* Code */
306 0, /* Vendor */
307 "Digest-Nonce-Count", /* Name */
308 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
309 AVP_FLAG_MANDATORY, /* Fixed flag values */
310 AVP_TYPE_OCTETSTRING /* base type of data */
311 };
312 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
313 }
314
315 /* Digest-Username */
316 {
317 /*
318
319 */
320
321 struct dict_avp_data data = {
322 115, /* Code */
323 0, /* Vendor */
324 "Digest-Username", /* Name */
325 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
326 AVP_FLAG_MANDATORY, /* Fixed flag values */
327 AVP_TYPE_OCTETSTRING /* base type of data */
328 };
329 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
330 }
331
332 /* Digest-Opaque */
333 {
334 /*
335
336 */
337
338 struct dict_avp_data data = {
339 116, /* Code */
340 0, /* Vendor */
341 "Digest-Opaque", /* Name */
342 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
343 AVP_FLAG_MANDATORY, /* Fixed flag values */
344 AVP_TYPE_OCTETSTRING /* base type of data */
345 };
346 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
347 }
348
349 /* Digest-Auth-Param */
350 {
351 /*
352
353 */
354
355 struct dict_avp_data data = {
356 117, /* Code */
357 0, /* Vendor */
358 "Digest-Auth-Param", /* Name */
359 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
360 AVP_FLAG_MANDATORY, /* Fixed flag values */
361 AVP_TYPE_OCTETSTRING /* base type of data */
362 };
363 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
364 }
365
366 /* Digest-AKA-Auts */
367 {
368 /*
369
370 */
371
372 struct dict_avp_data data = {
373 118, /* Code */
374 0, /* Vendor */
375 "Digest-AKA-Auts", /* Name */
376 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
377 AVP_FLAG_MANDATORY, /* Fixed flag values */
378 AVP_TYPE_OCTETSTRING /* base type of data */
379 };
380 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
381 }
382
383 /* Digest-Domain */
384 {
385 /*
386
387 */
388
389 struct dict_avp_data data = {
390 119, /* Code */
391 0, /* Vendor */
392 "Digest-Domain", /* Name */
393 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
394 AVP_FLAG_MANDATORY, /* Fixed flag values */
395 AVP_TYPE_OCTETSTRING /* base type of data */
396 };
397 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
398 }
399
400 /* Digest-Stale */
401 {
402 /*
403
404 */
405
406 struct dict_avp_data data = {
407 120, /* Code */
408 0, /* Vendor */
409 "Digest-Stale", /* Name */
410 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
411 AVP_FLAG_MANDATORY, /* Fixed flag values */
412 AVP_TYPE_OCTETSTRING /* base type of data */
413 };
414 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
415 }
416
417 /* Digest-HA1 */
418 {
419 /*
420
421 */
422
423 struct dict_avp_data data = {
424 121, /* Code */
425 0, /* Vendor */
426 "Digest-HA1", /* Name */
427 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
428 AVP_FLAG_MANDATORY, /* Fixed flag values */
429 AVP_TYPE_OCTETSTRING /* base type of data */
430 };
431 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
432 }
433 /* SIP-AOR */
434 {
435 /*
436
437 */
438
439 struct dict_avp_data data = {
440 122, /* Code */
441 0, /* Vendor */
442 "SIP-AOR", /* Name */
443 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
444 AVP_FLAG_MANDATORY, /* Fixed flag values */
445 AVP_TYPE_OCTETSTRING /* base type of data */
446 };
447 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
448 }
449
450
451 /* Diameter SIP AVPs*/
452 /* SIP-Accounting-Server-URI*/
453 {
454 /*
455 The SIP-Accounting-Server-URI AVP (AVP Code 369) is of type
456 DiameterURI. This AVP contains the address of a Diameter server that
457 is able to receive SIP-session-related accounting information.
458 */
459
460 struct dict_avp_data data = {
461 369, /* Code */
462 0, /* Vendor */
463 "SIP-Accounting-Server-URI", /* Name */
464 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
465 AVP_FLAG_MANDATORY, /* Fixed flag values */
466 AVP_TYPE_OCTETSTRING /* base type of data */
467 };
468 CHECK_dict_new( DICT_AVP, &data , DiameterURI_type, NULL);
469 }
470 /* SIP-Credit-Control-Server-URI */
471 {
472 /*
473 The SIP-Credit-Control-Server-URI AVP (AVP Code 370) is of type
474 DiameterURI. This AVP contains the address of a Diameter server that
475 is able to authorize real-time credit control usage. The Diameter
476 Credit-Control Application [RFC4006] may be used for this purpose.
477
478
479 */
480
481 struct dict_avp_data data = {
482 370, /* Code */
483 0, /* Vendor */
484 "SIP-Credit-Control-Server-URI", /* Name */
485 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
486 AVP_FLAG_MANDATORY, /* Fixed flag values */
487 AVP_TYPE_OCTETSTRING /* base type of data */
488 };
489 CHECK_dict_new( DICT_AVP, &data , DiameterURI_type, NULL);
490 }
491
492 /* SIP-Accounting-Information */
493 {
494 /*
495 The SIP-Accounting-Information (AVP Code 368) is of type Grouped, and
496 contains the Diameter addresses of those nodes that are able to
497 collect accounting information.
498
499 The SIP-Accounting-Information AVP is defined as follows (per the
500 grouped-avp-def of RFC 3588 [RFC3588]):
501
502 SIP-Accounting-Information ::= < AVP Header: 368 >
503 * [ SIP-Accounting-Server-URI ]
504 * [ SIP-Credit-Control-Server-URI ]
505 * [ AVP]
506
507 */
508 struct dict_object * avp;
509 struct dict_avp_data data = {
510 368, /* Code */
511 0, /* Vendor */
512 "SIP-Accounting-Information", /* Name */
513 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
514 AVP_FLAG_MANDATORY, /* Fixed flag values */
515 AVP_TYPE_GROUPED /* base type of data */
516 };
517 struct local_rules_definition rules[] =
518 { { "SIP-Accounting-Server-URI", RULE_OPTIONAL, -1, -1 }
519 ,{ "SIP-Credit-Control-Server-URI", RULE_OPTIONAL, -1, -1 }
520 };
521
522 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
523 PARSE_loc_rules( rules, avp );
524 }
525
526 /* SIP-Server-URI */
527 {
528 /*
529 The SIP-Server-URI AVP (AVP Code 371) is of type UTF8String. This
530 AVP contains a SIP or SIPS URI (as defined in RFC 3261 [RFC3261])
531 that identifies a SIP server.
532 */
533
534 struct dict_avp_data data = {
535 371, /* Code */
536 0, /* Vendor */
537 "SIP-Server-URI", /* Name */
538 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
539 AVP_FLAG_MANDATORY, /* Fixed flag values */
540 AVP_TYPE_OCTETSTRING /* base type of data */
541 };
542 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
543 }
544
545 /* SIP-Mandatory-Capability */
546 {
547 /*
548 The SIP-Mandatory-Capability AVP (AVP Code 373) is of type
549 Unsigned32. The value represents a certain capability (or set of
550 capabilities) that have to be fulfilled by the SIP server allocated
551 to the user.
552
553 The semantics of the different values are not standardized, as it is
554 a matter of the administrative network to allocate its own semantics
555 within its own network. Each value has to represent a single
556 capability within the administrative network.
557
558 */
559
560 struct dict_avp_data data = {
561 373, /* Code */
562 0, /* Vendor */
563 "SIP-Mandatory-Capability", /* Name */
564 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
565 AVP_FLAG_MANDATORY, /* Fixed flag values */
566 AVP_TYPE_UNSIGNED32 /* base type of data */
567 };
568 CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
569 }
570 /* SIP-Optional-Capability */
571 {
572 /*
573 The SIP-Optional-Capability AVP (AVP Code 374) is of type Unsigned32.
574 The value represents a certain capability (or set of capabilities)
575 that, optionally, may be fulfilled by the SIP server allocated to the
576 user.
577
578 The semantics of the different values are not standardized, as it is
579 a matter of the administrative network to allocate its own semantics
580 within its own network. Each value has to represent a single
581 capability within the administrative network.
582
583 */
584
585 struct dict_avp_data data = {
586 374, /* Code */
587 0, /* Vendor */
588 "SIP-Optional-Capability", /* Name */
589 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
590 AVP_FLAG_MANDATORY, /* Fixed flag values */
591 AVP_TYPE_UNSIGNED32 /* base type of data */
592 };
593 CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
594 }
595
596
597 /* SIP-Server-Capabilities */
598 {
599 /*
600 The SIP-Server-Capabilities AVP (AVP Code 372) is of type Grouped.
601 The Diameter indicates in this AVP the requirements for a particular
602 SIP capability, so that the Diameter client (SIP server) is able to
603 select another appropriate SIP server to serve the user.
604
605 The SIP-Server-Capabilities AVP allows a Diameter client (SIP server)
606 to select another SIP server for triggering or executing services to
607 the user. A user may have enabled some services that require the
608 implementation of certain capabilities in the SIP server that
609 triggers or executes those services. For example, the SIP server
610 that triggers or executes services to this user may need to implement
611 SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880],
612 or any other kind of capability. Or perhaps that user belongs to a
613 premium users group that has a certain stringent quality-of-service
614 agreement that requires a fast SIP server. The capabilities required
615 or recommended to a given user are conveyed in the
616 SIP-Server-Capabilities AVP. When it receives them, the Diameter
617 client (SIP server) that does the SIP server selection needs to have
618 the means to find out available SIP servers that meet the required or
619 optional capabilities. Such means are outside the scope of this
620 specification.
621
622 Note that the SIP-Server-Capabilities AVP assists the Diameter client
623 (SIP server) to produce a subset of all the available SIP servers to
624 be allocated to the user in the Home Realm; this is the subset that
625 conforms the requirements of capabilities on a per-user basis.
626 Typically this subset will be formed of more than a single SIP
627 server, so once the subset of those SIP servers is identified, it is
628 possible that several instances of these SIP servers exist, in which
629 case the Diameter client (SIP server) should choose one particular
630 SIP server to execute and trigger services to this user. It is
631 expected that at this point the SIP server (Diameter client) will
632 follow the procedures of RFC 3263 [RFC3263] to allocate one SIP
633 server to the user.
634
635 The SIP-Server-Capabilities AVP is defined as follows (per the
636 grouped-avp-def of RFC 3588 [RFC3588]):
637
638 SIP-Server-Capabilities ::= < AVP Header: 372 >
639 * [ SIP-Mandatory-Capability ]
640 * [ SIP-Optional-Capability ]
641 * [ SIP-Server-URI ]
642 * [ AVP ]
643
644 */
645 struct dict_object * avp;
646 struct dict_avp_data data = {
647 372, /* Code */
648 0, /* Vendor */
649 "SIP-Server-Capabilities", /* Name */
650 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
651 AVP_FLAG_MANDATORY, /* Fixed flag values */
652 AVP_TYPE_GROUPED /* base type of data */
653 };
654 struct local_rules_definition rules[] =
655 { { "SIP-Mandatory-Capability", RULE_OPTIONAL, -1, -1 }
656 ,{ "SIP-Optional-Capability", RULE_OPTIONAL, -1, -1 }
657 ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, -1 }
658 };
659
660 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
661 PARSE_loc_rules( rules, avp );
662 }
663
664
665 /* SIP-Server-Assignment-Type */
666 {
667 /*
668 The SIP-Server-Assignment-Type AVP (AVP Code 375) is of type
669 Enumerated and indicates the type of server update being performed in
670 a Diameter Server-Assignment-Request (SAR) operation. The following
671 values are defined:
672
673
674 o NO_ASSIGNMENT (0)
675 The Diameter client uses this value to request the user profile of
676 a SIP AOR, without affecting the registration state of that
677 identity.
678
679 o REGISTRATION (1)
680 First SIP registration of a SIP AOR.
681
682 o RE_REGISTRATION (2)
683 Subsequent SIP registration of a SIP AOR.
684
685 o UNREGISTERED_USER (3)
686 The SIP server has received a SIP request (e.g., SIP INVITE)
687 addressed for a SIP AOR that is not registered.
688
689 o TIMEOUT_DEREGISTRATION (4)
690 The SIP registration timer of an identity has expired.
691
692 o USER_DEREGISTRATION (5)
693 The SIP server has received a request to deregister a SIP AOR.
694
695 o TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
696 The SIP registration timer of an identity has expired. The SIP
697 server keeps the user data stored and requests the Diameter server
698 to store the SIP server address.
699
700 o USER_DEREGISTRATION_STORE_SERVER_NAME (7)
701 The SIP server has received a user-initiated deregistration
702 request. The SIP server keeps the user data stored and requests
703 the Diameter server to store the SIP server address.
704
705 o ADMINISTRATIVE_DEREGISTRATION (8)
706 The SIP server, due to administrative reasons, has deregistered a
707 SIP AOR.
708
709 o AUTHENTICATION_FAILURE (9)
710 The authentication of a user has failed.
711
712 o AUTHENTICATION_TIMEOUT (10)
713 The authentication timer has expired.
714
715 o DEREGISTRATION_TOO_MUCH_DATA (11)
716 The SIP server has requested user profile information from the
717 Diameter server and has received a volume of data higher than it
718 can accept.
719
720 */
721 struct dict_object *type;
722 struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-Server-Assignment-Type)" , NULL, NULL};
723 struct dict_enumval_data tvals[] = {
724 enumval_def_u32( 0, "NO_ASSIGNMENT"),
725 enumval_def_u32( 1, "REGISTRATION"),
726 enumval_def_u32( 2, "RE_REGISTRATION"),
727 enumval_def_u32( 3, "UNREGISTERED_USER"),
728 enumval_def_u32( 4, "TIMEOUT_DEREGISTRATION"),
729 enumval_def_u32( 5, "USER_DEREGISTRATION"),
730 enumval_def_u32( 6, "TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME"),
731 enumval_def_u32( 7, "USER_DEREGISTRATION_STORE_SERVER_NAME"),
732 enumval_def_u32( 8, "ADMINISTRATIVE_DEREGISTRATION"),
733 enumval_def_u32( 9, "AUTHENTICATION_FAILURE"),
734 enumval_def_u32( 10, "AUTHENTICATION_TIMEOUT"),
735 enumval_def_u32( 11, "DEREGISTRATION_TOO_MUCH_DATA")
736 };
737 struct dict_avp_data data = {
738 375, /* Code */
739 0, /* Vendor */
740 "SIP-Server-Assignment-Type", /* Name */
741 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
742 AVP_FLAG_MANDATORY, /* Fixed flag values */
743 AVP_TYPE_UNSIGNED32 /* base type of data */
744 };
745 int i;
746 /* Create the Enumerated type, enumerated values, and the AVP */
747 CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
748 for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
749 CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
750 }
751 CHECK_dict_new( DICT_AVP, &data , type, NULL);
752 }
753
754
755 /* SIP-Authenticate */
756 {
757 /*
758 The SIP-Authenticate AVP (AVP Code 379) is of type Grouped and
759 contains a reconstruction of either the SIP WWW-Authenticate or
760 Proxy-Authentication header fields specified in RFC 2617 [RFC2617]
761 for the HTTP Digest authentication scheme. Additionally, the AVP may
762 include a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617
763 [RFC2617]). H(A1) allows the Diameter client to create an expected
764 response and compare it with the Digest response received from the
765 SIP UA.
766 The SIP-Authenticate AVP is defined as follows (per the
767 grouped-avp-def of RFC 3588 [RFC3588]):
768
769 SIP-Authenticate ::= < AVP Header: 379 >
770 { Digest-Realm }
771 { Digest-Nonce }
772 [ Digest-Domain ]
773 [ Digest-Opaque ]
774 [ Digest-Stale ]
775 [ Digest-Algorithm ]
776 [ Digest-QoP ]
777 [ Digest-HA1]
778 * [ Digest-Auth-Param ]
779 * [ AVP ]
780
781
782 */
783 struct dict_object * avp;
784 struct dict_avp_data data = {
785 379, /* Code */
786 0, /* Vendor */
787 "SIP-Authenticate", /* Name */
788 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
789 AVP_FLAG_MANDATORY, /* Fixed flag values */
790 AVP_TYPE_GROUPED /* base type of data */
791 };
792 struct local_rules_definition rules[] =
793 { { "Digest-Realm", RULE_REQUIRED, -1, 1 }
794 ,{ "Digest-Nonce", RULE_REQUIRED, -1, 1 }
795 ,{ "Digest-Domain", RULE_OPTIONAL, -1, 1 }
796 ,{ "Digest-Opaque", RULE_OPTIONAL, -1, 1 }
797 ,{ "Digest-Stale", RULE_OPTIONAL, -1, 1 }
798 ,{ "Digest-Algorithm", RULE_OPTIONAL, -1, 1 }
799 ,{ "Digest-QoP", RULE_OPTIONAL, -1, 1 }
800 ,{ "Digest-HA1", RULE_OPTIONAL, -1, 1 }
801 ,{ "Digest-Auth-Param", RULE_OPTIONAL, -1, -1 }
802
803 };
804
805 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
806 PARSE_loc_rules( rules, avp );
807 }
808 /* SIP-Authorization */
809 {
810 /*
811 The SIP-Authorization AVP (AVP Code 380) is of type Grouped and
812 contains a reconstruction of either the SIP Authorization or
813 Proxy-Authorization header fields specified in RFC 2617 [RFC2617] for
814 the HTTP Digest authentication scheme.
815
816 The SIP-Authorization AVP is defined as follows (per the
817 grouped-avp-def of RFC 3588 [RFC3588]):
818
819 SIP-Authorization ::= < AVP Header: 380 >
820 { Digest-Username }
821 { Digest-Realm }
822 { Digest-Nonce }
823 { Digest-URI }
824 { Digest-Response }
825 [ Digest-Algorithm ]
826 [ Digest-CNonce ]
827 [ Digest-Opaque ]
828 [ Digest-QoP ]
829 [ Digest-Nonce-Count ]
830 [ Digest-Method]
831 [ Digest-Entity-Body-Hash ]
832 * [ Digest-Auth-Param ]
833 * [ AVP ]
834
835 */
836 struct dict_object * avp;
837 struct dict_avp_data data = {
838 380, /* Code */
839 0, /* Vendor */
840 "SIP-Authorization", /* Name */
841 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
842 AVP_FLAG_MANDATORY, /* Fixed flag values */
843 AVP_TYPE_GROUPED /* base type of data */
844 };
845 struct local_rules_definition rules[] =
846 { { "Digest-Username", RULE_REQUIRED, -1, 1 }
847 ,{ "Digest-Realm", RULE_REQUIRED, -1, 1 }
848 ,{ "Digest-Nonce", RULE_REQUIRED, -1, 1 }
849 ,{ "Digest-URI", RULE_REQUIRED, -1, 1 }
850 ,{ "Digest-Response", RULE_REQUIRED, -1, 1 }
851 ,{ "Digest-Algorithm", RULE_OPTIONAL, -1, 1 }
852 ,{ "Digest-CNonce", RULE_OPTIONAL, -1, 1 }
853 ,{ "Digest-Opaque", RULE_OPTIONAL, -1, 1 }
854 ,{ "Digest-QoP", RULE_OPTIONAL, -1, 1 }
855 ,{ "Digest-Nonce-Count", RULE_OPTIONAL, -1, 1 }
856 ,{ "Digest-Method", RULE_OPTIONAL, -1, 1 }
857 ,{ "Digest-Entity-Body-Hash", RULE_OPTIONAL, -1, 1 }
858 ,{ "Digest-Auth-Param", RULE_OPTIONAL, -1, -1 }
859 };
860
861 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
862 PARSE_loc_rules( rules, avp );
863 }
864 /* SIP-Authentication-Info */
865 {
866 /*
867 The SIP-Authentication-Info AVP (AVP Code 381) is of type Grouped and
868 contains a reconstruction of the SIP Authentication-Info header
869 specified in RFC 2617 [RFC2617] for the HTTP Digest authentication
870 scheme.
871 The SIP-Authentication-Info AVP is defined as follows (per the
872 grouped-avp-def of RFC 3588 [RFC3588]):
873
874 SIP-Authentication-Info ::= < AVP Header: 381 >
875 [ Digest-Nextnonce ]
876 [ Digest-QoP ]
877 [ Digest-Response-Auth ]
878 [ Digest-CNonce ]
879 [ Digest-Nonce-Count ]
880 * [ AVP ]
881
882 Note that, in some cases, the Digest-Response-Auth AVP cannot be
883 calculated at the Diameter server, but has to be calculated at the
884 Diameter client (SIP server). For example, if the value of the
885 quality of protection (qop) parameter in Digest is set to "auth-int",
886 then the response-digest (rspauth parameter value in Digest) is
887 calculated with the hash of the body of the SIP response, which is
888 not available at the Diameter server. In this case, the Diameter
889 client (SIP server) must calculate the response-digest once the body
890 of the SIP response is calculated.
891
892 Therefore, a value of "auth-int" in the Digest-QoP AVP of the
893 SIP-Authentication-Info AVP indicates that the Diameter client (SIP
894 server) MUST compute the Digest "rspauth" parameter value at the
895 Diameter client (SIP server).
896
897 */
898 struct dict_object * avp;
899 struct dict_avp_data data = {
900 381, /* Code */
901 0, /* Vendor */
902 "SIP-Authentication-Info", /* Name */
903 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
904 AVP_FLAG_MANDATORY, /* Fixed flag values */
905 AVP_TYPE_GROUPED /* base type of data */
906 };
907 struct local_rules_definition rules[] =
908 { { "Digest-Nextnonce", RULE_OPTIONAL, -1, 1 }
909 ,{ "Digest-QoP", RULE_OPTIONAL, -1, 1 }
910 ,{ "Digest-Response-Auth", RULE_OPTIONAL, -1, 1 }
911 ,{ "Digest-CNonce", RULE_OPTIONAL, -1, 1 }
912 ,{ "Digest-Nonce-Count", RULE_OPTIONAL, -1, 1 }
913 };
914
915 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
916 PARSE_loc_rules( rules, avp );
917 }
918 /* SIP-Authentication-Scheme */
919 {
920 /*
921 The SIP-Authentication-Scheme AVP (AVP Code 377) is of type
922 Enumerated and indicates the authentication scheme used in the
923 authentication of SIP services. RFC 2617 identifies this value as an
924 "auth-scheme" (see Section 1.2 of RFC 2617 [RFC2617]). The only
925 currently defined value is:
926
927 o DIGEST (0) to indicate HTTP Digest authentication as specified in
928 RFC 2617 [RFC2617] Section 3.2.1. Derivative work is also
929 considered Digest authentication scheme, as long as the
930 "auth-scheme" is identified as Digest in the SIP headers carrying
931 the HTTP authentication. This includes, e.g., the HTTP Digest
932 authentication using AKA [RFC3310].
933
934 Each HTTP Digest directive (parameter) is transported in a
935 corresponding AVP, whose name follows the pattern Digest-*. The
936 Digest-* AVPs are RADIUS attributes imported from the RADIUS
937 Extension for Digest Authentication [RFC4590] namespace, allowing a
938 smooth transition between RADIUS and Diameter applications supporting
939 SIP. The Diameter SIP application goes a step further by grouping
940 the Digest-* AVPs into the SIP-Authenticate, SIP-Authorization, and
941 SIP-Authentication-Info grouped AVPs that correspond to the SIP WWW-
942 Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization,
943 and Authentication-Info headers fields, respectively.
944
945 Note: Due to the fact that HTTP Digest authentication [RFC2617] is
946 the only mandatory authentication mechanism in SIP, this memo only
947 provides support for HTTP Digest authentication and derivative
948 work such as HTTP Digest authentication using AKA [RFC3310].
949 Extensions to this memo can register new values and new AVPs to
950 provide support for other authentication schemes or extensions to
951 HTTP Digest authentication.
952
953 Note: Although RFC 2617 [RFC2617] defines the Basic and Digest
954 schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only
955 imports HTTP Digest as a mechanism to provide authentication in
956 SIP.
957
958 Due to syntactic requirements, HTTP Digest authentication has to
959 escape quote characters in contents of HTTP Digest directives. When
960 translating directives into Digest-* AVPs, the Diameter client or
961 server removes the surrounding quotes where present, as required by
962 the syntax of the Digest-* attributes defined in the "RADIUS
963 Extension for Digest Authentication" [RFC4590].
964
965 */
966
967 struct dict_object *type;
968 struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-Authentication-Scheme)" , NULL, NULL};
969 struct dict_enumval_data tvals[] = {
970 enumval_def_u32( 0, "DIGEST")
971 };
972 struct dict_avp_data data = {
973 377, /* Code */
974 0, /* Vendor */
975 "SIP-Authentication-Scheme", /* Name */
976 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
977 AVP_FLAG_MANDATORY, /* Fixed flag values */
978 AVP_TYPE_UNSIGNED32 /* base type of data */
979 };
980 int i;
981 /* Create the Enumerated type, enumerated values, and the AVP */
982 CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
983 for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
984 CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
985 }
986 CHECK_dict_new( DICT_AVP, &data , type, NULL);
987 }
988 /* SIP-Item-Number */
989 {
990 /*
991 The SIP-Item-Number (AVP Code 378) is of type Unsigned32 and is
992 included in a SIP-Auth-Data-Item grouped AVP in circumstances where
993 there are multiple occurrences of SIP-Auth-Data-Item AVPs and the
994 order of processing is relevant. The AVP indicates the order in
995 which the Grouped SIP-Auth-Data-Item should be processed. Lower
996 values of the SIP-Item-Number AVP indicate that the whole
997 SIP-Auth-Data-Item SHOULD be processed before other
998 SIP-Auth-Data-Item AVPs that contain higher values in the
999 SIP-Item-Number AVP.
1000
1001 */
1002
1003 struct dict_avp_data data = {
1004 378, /* Code */
1005 0, /* Vendor */
1006 "SIP-Item-Number", /* Name */
1007 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1008 AVP_FLAG_MANDATORY, /* Fixed flag values */
1009 AVP_TYPE_UNSIGNED32 /* base type of data */
1010 };
1011 CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
1012 }
1013 /* SIP-Auth-Data-Item */
1014 {
1015 /*
1016 The SIP-Auth-Data-Item (AVP Code 376) is of type Grouped and contains
1017 the authentication and/or authorization information pertaining to a
1018 user.
1019
1020 When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to
1021 include a SIP-Authenticate AVP, the Diameter server MUST send a
1022 maximum of one authentication data item (e.g., in case the SIP
1023 request contained several credentials). Section 11 contains a
1024 detailed discussion and normative text of the case when a SIP request
1025 contains several credentials.
1026
1027 The SIP-Auth-Data-Item AVP is defined as follows (per the
1028 grouped-avp-def of RFC 3588 [RFC3588]):
1029
1030 SIP-Auth-Data-Item ::= < AVP Header: 376 >
1031 { SIP-Authentication-Scheme }
1032 [ SIP-Item-Number ]
1033 [ SIP-Authenticate ]
1034 [ SIP-Authorization ]
1035 [ SIP-Authentication-Info ]
1036 * [ AVP ]
1037
1038
1039 */
1040 struct dict_object * avp;
1041 struct dict_avp_data data = {
1042 376, /* Code */
1043 0, /* Vendor */
1044 "SIP-Auth-Data-Item", /* Name */
1045 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1046 AVP_FLAG_MANDATORY, /* Fixed flag values */
1047 AVP_TYPE_GROUPED /* base type of data */
1048 };
1049 struct local_rules_definition rules[] =
1050 { { "SIP-Authentication-Scheme",RULE_REQUIRED, -1, 1 }
1051 ,{ "SIP-Item-Number", RULE_OPTIONAL, -1, 1 }
1052 ,{ "SIP-Authenticate", RULE_OPTIONAL, -1, 1 }
1053 ,{ "SIP-Authorization", RULE_OPTIONAL, -1, 1 }
1054 ,{ "SIP-Authentication-Info", RULE_OPTIONAL, -1, 1 }
1055 };
1056
1057 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
1058 PARSE_loc_rules( rules, avp );
1059 }
1060 /* SIP-Number-Auth-Items */
1061 {
1062 /*
1063 The SIP-Number-Auth-Items AVP (AVP Code 382) is of type Unsigned32
1064 and indicates the number of authentication and/or authorization
1065 credentials that the Diameter server included in a Diameter message.
1066
1067 When the AVP is present in a request, it indicates the number of
1068 SIP-Auth-Data-Items the Diameter client is requesting. This can be
1069 used, for instance, when the SIP server is requesting several
1070 pre-calculated authentication credentials. In the answer message,
1071 the SIP-Number-Auth-Items AVP indicates the actual number of items
1072 that the Diameter server included.
1073
1074 */
1075
1076 struct dict_avp_data data = {
1077 382, /* Code */
1078 0, /* Vendor */
1079 "SIP-Number-Auth-Items", /* Name */
1080 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1081 AVP_FLAG_MANDATORY, /* Fixed flag values */
1082 AVP_TYPE_UNSIGNED32 /* base type of data */
1083 };
1084 CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
1085 }
1086
1087 /* SIP-Reason-Code */
1088 {
1089 /*
1090 The SIP-Reason-Code AVP (AVP Code 384) is of type Enumerated and
1091 defines the reason for the network initiated deregistration. The
1092 following values are defined:
1093
1094 o PERMANENT_TERMINATION (0)
1095 o NEW_SIP_SERVER_ASSIGNED (1)
1096 o SIP_SERVER_CHANGE (2)
1097 o REMOVE_SIP_SERVER (3)
1098 */
1099
1100 struct dict_object *type;
1101 struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-Reason-Code)" , NULL, NULL};
1102 struct dict_enumval_data tvals[] = {
1103 enumval_def_u32( 0, "PERMANENT_TERMINATION"),
1104 enumval_def_u32( 1, "NEW_SIP_SERVER_ASSIGNED"),
1105 enumval_def_u32( 2, "SIP_SERVER_CHANGE"),
1106 enumval_def_u32( 3, "REMOVE_SIP_SERVER")
1107 };
1108 struct dict_avp_data data = {
1109 384, /* Code */
1110 0, /* Vendor */
1111 "SIP-Reason-Code", /* Name */
1112 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1113 AVP_FLAG_MANDATORY, /* Fixed flag values */
1114 AVP_TYPE_UNSIGNED32 /* base type of data */
1115 };
1116 int i;
1117 /* Create the Enumerated type, enumerated values, and the AVP */
1118 CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
1119 for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
1120 CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
1121 }
1122 CHECK_dict_new( DICT_AVP, &data , type, NULL);
1123 }
1124
1125 /* SIP-Reason-Info */
1126 {
1127 /*
1128 The SIP-Reason-Info AVP (AVP Code 385) is of type UTF8String and
1129 contains textual information that can be rendered to the user, about
1130 the reason for a deregistration.
1131
1132 */
1133
1134 struct dict_avp_data data = {
1135 385, /* Code */
1136 0, /* Vendor */
1137 "SIP-Reason-Info", /* Name */
1138 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1139 AVP_FLAG_MANDATORY, /* Fixed flag values */
1140 AVP_TYPE_OCTETSTRING /* base type of data */
1141 };
1142 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
1143 }
1144
1145 /* SIP-Deregistration-Reason */
1146 {
1147 /*
1148 The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped
1149 and indicates the reason for a deregistration operation.
1150
1151 The SIP-Deregistration-Reason AVP is defined as follows (per the
1152 grouped-avp-def of RFC 3588 [RFC3588]):
1153
1154 SIP-Deregistration-Reason ::= < AVP Header: 383 >
1155 { SIP-Reason-Code }
1156 [ SIP-Reason-Info ]
1157 * [ AVP ]
1158
1159 */
1160 struct dict_object * avp;
1161 struct dict_avp_data data = {
1162 383, /* Code */
1163 0, /* Vendor */
1164 "SIP-Deregistration-Reason", /* Name */
1165 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1166 AVP_FLAG_MANDATORY, /* Fixed flag values */
1167 AVP_TYPE_GROUPED /* base type of data */
1168 };
1169 struct local_rules_definition rules[] =
1170 { { "SIP-Reason-Code", RULE_REQUIRED, -1, 1 }
1171 ,{ "SIP-Reason-Info", RULE_OPTIONAL, -1, 1 }
1172 };
1173
1174 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
1175 PARSE_loc_rules( rules, avp );
1176 }
1177
1178 /* SIP-Visited-Network-Id */
1179 {
1180 /*
1181 The SIP-Visited-Network-Id AVP (AVP Code 386) is of type UTF8String.
1182 This AVP contains an identifier that helps the home network identify
1183 the visited network (e.g., the visited network domain name), in order
1184 to authorize roaming to that visited network.
1185
1186 */
1187
1188 struct dict_avp_data data = {
1189 386, /* Code */
1190 0, /* Vendor */
1191 "SIP-Visited-Network-Id", /* Name */
1192 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1193 AVP_FLAG_MANDATORY, /* Fixed flag values */
1194 AVP_TYPE_OCTETSTRING /* base type of data */
1195 };
1196 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
1197 }
1198 /* SIP-User-Authorization-Type */
1199 {
1200 /*
1201 The SIP-User-Authorization-Type AVP (AVP Code 387) is of type
1202 Enumerated and indicates the type of user authorization being
1203 performed in a User Authorization operation, i.e., the Diameter
1204 User-Authorization-Request (UAR) command. The following values are
1205 defined:
1206
1207 o REGISTRATION (0)
1208 This value is used for initial registration or re-registration.
1209 This is the default value.
1210
1211 o DEREGISTRATION (1)
1212 This value is used for deregistration.
1213
1214 o REGISTRATION_AND_CAPABILITIES (2)
1215 This value is used for initial registration or re-registration
1216 when the SIP server explicitly requests the Diameter server to get
1217 capability information. This capability information helps the SIP
1218 server to allocate another SIP server to serve the user.
1219
1220 */
1221
1222 struct dict_object *type;
1223 struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-User-Authorization-Type)" , NULL, NULL};
1224 struct dict_enumval_data tvals[] = {
1225 enumval_def_u32( 0, "REGISTRATION"),
1226 enumval_def_u32( 1, "DEREGISTRATION"),
1227 enumval_def_u32( 2, "REGISTRATION_AND_CAPABILITIES")
1228 };
1229 struct dict_avp_data data = {
1230 387, /* Code */
1231 0, /* Vendor */
1232 "SIP-User-Authorization-Type", /* Name */
1233 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1234 AVP_FLAG_MANDATORY, /* Fixed flag values */
1235 AVP_TYPE_UNSIGNED32 /* base type of data */
1236 };
1237 int i;
1238 /* Create the Enumerated type, enumerated values, and the AVP */
1239 CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
1240 for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
1241 CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
1242 }
1243 CHECK_dict_new( DICT_AVP, &data , type, NULL);
1244 }
1245 /* SIP-Supported-User-Data-Type */
1246 {
1247 /*
1248 The SIP-Supported-User-Data-Type AVP (AVP Code 388) is of type
1249 UTF8String and contains a string that identifies the type of
1250 supported user data (user profile, see SIP-User-Data AVP
1251 (Section 9.12)) supported in the node. The AVP can be repeated, if
1252 the SIP server supports several user data types. In case of
1253 repetition, the Diameter client should order the different instances
1254 of this AVP according to its preferences.
1255
1256 When the Diameter client inserts this AVP in a SAR message, it allows
1257 the Diameter client to provide an indication to the Diameter server
1258 of the types of user data supported by the SIP server. The Diameter
1259 server, upon inspection of these AVPs, will return a suitable
1260 SIP-User-Data AVP (Section 9.12) of the type indicated in the
1261 SIP-User-Data-Type AVP (Section 9.12.1).
1262
1263 */
1264
1265 struct dict_avp_data data = {
1266 388, /* Code */
1267 0, /* Vendor */
1268 "SIP-Supported-User-Data-Type", /* Name */
1269 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1270 AVP_FLAG_MANDATORY, /* Fixed flag values */
1271 AVP_TYPE_OCTETSTRING /* base type of data */
1272 };
1273 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
1274 }
1275 /* SIP-User-Data-Type */
1276 {
1277 /*
1278 The SIP-User-Data-Type AVP (AVP Code 390) is of type UTF8String and
1279 contains a string that identifies the type of user data included in
1280 the SIP-User-Data-Type AVP (Section 9.12).
1281
1282 This document does not specify a convention to characterize the type
1283 of user data contained in the SIP-User-Data-Type AVP (Section 9.12). It
1284 is believed that in most cases this feature will be used in
1285 environments controlled by a network administrator who can configure
1286 both the client and server to assign the same value type at the
1287 client and server. It is also RECOMMENDED that organizations
1288 developing their own profile of SIP-User-Data-Type AVP (Section 9.12)
1289 allocate a type based on their canonical DNS name. For instance,
1290 organization "example.com" can define several types of SIP-User-Data
1291 and allocate the types "type1.dsa.example.com",
1292 "type2.dsa.example.com", and so on. This convention will avoid a
1293 clash in the allocation of types of SIP-User-Data-Type AVP (Section 9.12).
1294
1295 */
1296
1297 struct dict_avp_data data = {
1298 390, /* Code */
1299 0, /* Vendor */
1300 "SIP-User-Data-Type", /* Name */
1301 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1302 AVP_FLAG_MANDATORY, /* Fixed flag values */
1303 AVP_TYPE_OCTETSTRING /* base type of data */
1304 };
1305 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
1306 }
1307 /* SIP-User-Data-Contents */
1308 {
1309 /*
1310 The SIP-User-Data-Contents AVP (AVP Code 391) is of type OctetString.
1311 The Diameter peers do not need to understand the value of this AVP.
1312
1313 The AVP contains the user profile data required for a SIP server to
1314 give service to the user.
1315
1316
1317 */
1318
1319 struct dict_avp_data data = {
1320 391, /* Code */
1321 0, /* Vendor */
1322 "SIP-User-Data-Contents", /* Name */
1323 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1324 AVP_FLAG_MANDATORY, /* Fixed flag values */
1325 AVP_TYPE_OCTETSTRING /* base type of data */
1326 };
1327 CHECK_dict_new( DICT_AVP, &data , NULL, NULL);
1328 }
1329
1330 /* SIP-User-Data */
1331 {
1332 /*
1333 The SIP-User-Data AVP (AVP Code 389) is of type Grouped. This AVP
1334 allows the Diameter server to transport user-specific data, such as a
1335 user profile, to the SIP server (in the Diameter client). The
1336 Diameter server selects a type of user data that is understood by the
1337 SIP server in the Diameter client, and has been indicated in a
1338 SIP-Supported-User-Data-Type AVP. In case the Diameter client
1339 indicated support for several types of user data, the Diameter server
1340 SHOULD choose the first type supported by the client.
1341
1342 The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP that
1343 indicates the type of user data included in the
1344 SIP-User-Data-Contents-AVP.
1345
1346 The SIP-User-Data AVP is defined as follows (per the grouped-avp-def
1347 of RFC 3588 [RFC3588]):
1348
1349
1350 SIP-User-Data ::= < AVP Header: 389 >
1351 { SIP-User-Data-Type }
1352 { SIP-User-Data-Contents }
1353 * [ AVP ]
1354
1355 */
1356 struct dict_object * avp;
1357 struct dict_avp_data data = {
1358 389, /* Code */
1359 0, /* Vendor */
1360 "SIP-User-Data", /* Name */
1361 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1362 AVP_FLAG_MANDATORY, /* Fixed flag values */
1363 AVP_TYPE_GROUPED /* base type of data */
1364 };
1365 struct local_rules_definition rules[] =
1366 { { "SIP-User-Data-Type", RULE_REQUIRED, -1, 1 }
1367 ,{ "SIP-User-Data-Contents", RULE_REQUIRED, -1, 1 }
1368 };
1369
1370 CHECK_dict_new( DICT_AVP, &data , NULL, &avp);
1371 PARSE_loc_rules( rules, avp );
1372 }
1373 /* SIP-User-Data-Already-Available */
1374 {
1375 /*
1376 The SIP-User-Data-Already-Available AVP (AVP Code 392) is of type
1377 Enumerated and gives an indication to the Diameter server about
1378 whether the Diameter client (SIP server) already received the portion
1379 of the user profile needed in order to serve the user. The following
1380 values are defined:
1381
1382 o USER_DATA_NOT_AVAILABLE (0)
1383 The Diameter client (SIP server) does not have the data that it
1384 needs to serve the user.
1385
1386 o USER_DATA_ALREADY_AVAILABLE (1)
1387 The Diameter client (SIP server) already has received the data
1388 that it needs to serve the user.
1389
1390
1391 */
1392
1393 struct dict_object *type;
1394 struct dict_type_data tdata = { AVP_TYPE_UNSIGNED32, "Enumerated(SIP-User-Data-Already-Available)" , NULL, NULL};
1395 struct dict_enumval_data tvals[] = {
1396 enumval_def_u32( 0, "USER_DATA_NOT_AVAILABLE"),
1397 enumval_def_u32( 1, "USER_DATA_ALREADY_AVAILABLE")
1398 };
1399 struct dict_avp_data data = {
1400 392, /* Code */
1401 0, /* Vendor */
1402 "SIP-User-Data-Already-Available", /* Name */
1403 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1404 AVP_FLAG_MANDATORY, /* Fixed flag values */
1405 AVP_TYPE_UNSIGNED32 /* base type of data */
1406 };
1407 int i;
1408 /* Create the Enumerated type, enumerated values, and the AVP */
1409 CHECK_dict_new( DICT_TYPE, &tdata , NULL, &type);
1410 for (i = 0; i < sizeof(tvals) / sizeof(tvals[0]); i++) {
1411 CHECK_dict_new( DICT_ENUMVAL, &tvals[i], type, NULL);
1412 }
1413 CHECK_dict_new( DICT_AVP, &data , type, NULL);
1414 }
1415 /* SIP-Method */
1416 {
1417 /*
1418 The SIP-Method-AVP (AVP Code 393) is of type UTF8String and contains
1419 the method of the SIP request that triggered the Diameter message.
1420 The Diameter server MUST use this AVP solely for authorization of SIP
1421 requests, and MUST NOT use it to compute the Digest authentication.
1422 To compute the Digest authentication, the Diameter server MUST use
1423 the Digest-Method AVP instead.
1424
1425
1426 */
1427
1428 struct dict_avp_data data = {
1429 393, /* Code */
1430 0, /* Vendor */
1431 "SIP-Method", /* Name */
1432 AVP_FLAG_VENDOR | AVP_FLAG_MANDATORY, /* Fixed flags */
1433 AVP_FLAG_MANDATORY, /* Fixed flag values */
1434 AVP_TYPE_OCTETSTRING /* base type of data */
1435 };
1436 CHECK_dict_new( DICT_AVP, &data , UTF8String_type, NULL);
1437 }
1438 /* Complement of Result-Code AVP values */
1439 {
1440 struct dict_object * resultcode_data_type;
1441 CHECK_dict_search(DICT_TYPE,TYPE_BY_NAME,"Enumerated(Result-Code)",&resultcode_data_type);
1442
1443
1444 {
1445
1446 /* Success */
1447 {
1448 /* 2003 */
1449 {
1450 /*
1451 The user was not previously registered. The Diameter server has
1452 now authorized the registration.
1453 */
1454 struct dict_enumval_data error_code = { "DIAMETER_FIRST_REGISTRATION", { .u32 = 2003 }};
1455 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1456 }
1457 /* 2004 */
1458 {
1459 /*
1460 The user is already registered. The Diameter server has now
1461 authorized the re-registration.
1462
1463 */
1464 struct dict_enumval_data error_code = { "DIAMETER_SUBSEQUENT_REGISTRATION", { .u32 = 2004 }};
1465 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1466 }
1467 /* 2005 */
1468 {
1469 struct dict_enumval_data error_code = { "DIAMETER_UNREGISTERED_SERVICE", { .u32 = 2005 }};
1470 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1471 }
1472 /* 2006 */
1473 {
1474 struct dict_enumval_data error_code = { "DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED", { .u32 = 2006 }};
1475 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1476 }
1477 /* 2007 */
1478 {
1479 struct dict_enumval_data error_code = { "DIAMETER_SERVER_SELECTION", { .u32 = 2007 }};
1480 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1481 }
1482 /* 2008 */
1483 {
1484 struct dict_enumval_data error_code = { "DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED", { .u32 = 2008 }};
1485 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1486 }
1487 }
1488 /* Transient Failures */
1489 {
1490 /* 4013 */
1491 {
1492 struct dict_enumval_data error_code = { "DIAMETER_USER_NAME_REQUIRED", { .u32 = 4013 }};
1493 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1494 }
1495 }
1496 /* Permanent Failures */
1497 {
1498 /* 5032 */
1499 {
1500 struct dict_enumval_data error_code = { "DIAMETER_ERROR_USER_UNKNOWN", { .u32 = 5032 }};
1501 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1502 }
1503 /* 5033 */
1504 {
1505 struct dict_enumval_data error_code = { "DIAMETER_ERROR_IDENTITIES_DONT_MATCH", { .u32 = 5033 }};
1506 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1507 }
1508 /* 5034 */
1509 {
1510 struct dict_enumval_data error_code = { "DIAMETER_ERROR_IDENTITY_NOT_REGISTERED", { .u32 = 5034 }};
1511 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1512 }
1513 /* 5035 */
1514 {
1515 struct dict_enumval_data error_code = { "DIAMETER_ERROR_ROAMING_NOT_ALLOWED", { .u32 = 5035 }};
1516 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1517 }
1518 /* 5036 */
1519 {
1520 struct dict_enumval_data error_code = { "DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED", { .u32 = 5036 }};
1521 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1522 }
1523 /* 5037 */
1524 {
1525 struct dict_enumval_data error_code = { "DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED", { .u32 = 5037 }};
1526 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1527 }
1528 /* 5038 */
1529 {
1530 struct dict_enumval_data error_code = { "DIAMETER_ERROR_IN_ASSIGNMENT_TYPE", { .u32 = 5038 }};
1531 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1532 }
1533 /* 5039 */
1534 {
1535 struct dict_enumval_data error_code = { "DIAMETER_ERROR_TOO_MUCH_DATA", { .u32 = 5039 }};
1536 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1537 }
1538 /* 5040 */
1539 {
1540 struct dict_enumval_data error_code = { "DIAMETER_ERROR_NOT SUPPORTED_USER_DATA", { .u32 = 5040 }};
1541 CHECK_dict_new( DICT_ENUMVAL, &error_code , resultcode_data_type, NULL);
1542 }
1543 }
1544 }
1545
1546
1547 }
1548 }
1549 /* Command section */
1550 {
1551 /* User-Authorization-Request (UAR) Command */
1552 {
1553 /*
1554 The User-Authorization-Request (UAR) is indicated by the Command-Code
1555 set to 283 and the Command Flags' 'R' bit set. The Diameter client
1556 in a SIP server sends this command to the Diameter server to request
1557 authorization for the SIP User Agent to route a SIP REGISTER request.
1558 Because the SIP REGISTER request implicitly carries a permission to
1559 bind an AOR to a contact address, the Diameter client uses the
1560 Diameter UAR as a first authorization request towards the Diameter
1561 server to authorize the registration. For instance, the Diameter
1562 server can verify that the AOR is a legitimate user of the realm.
1563
1564 The Diameter client in the SIP server requests authorization for one
1565 of the possible values defined in the SIP-User-Authorization-Type AVP
1566 (Section 9.10).
1567
1568 The user name used for authentication of the user is conveyed in a
1569 User-Name AVP (defined in the Diameter base protocol, RFC 3588
1570 [RFC3588]). The location of the authentication user name in the SIP
1571 REGISTER request varies depending on the authentication mechanism.
1572 When the authentication mechanism is HTTP Digest as defined in RFC
1573 2617 [RFC2617], the authentication user name is found in the
1574 "username" directive of the SIP Authorization header field value.
1575 This Diameter SIP application only provides support for HTTP Digest
1576 authentication in SIP; other authentication mechanisms are not
1577 currently supported.
1578
1579 The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP
1580 (Section 9.8). Typically this SIP or SIPS URI is found in the To
1581 header field value of the SIP REGISTER request that triggered the
1582 Diameter UAR message.
1583
1584 The SIP-Visited-Network-Id AVP indicates the network that is
1585 providing SIP services (e.g., SIP proxy functionality or any other
1586 kind of services) to the SIP User Agent.
1587
1588 The Message Format of the UAR command is as follows:
1589
1590 <UAR> ::= < Diameter Header: 283, REQ, PXY >
1591 < Session-Id >
1592 { Auth-Application-Id }
1593 { Auth-Session-State }
1594 { Origin-Host }
1595 { Origin-Realm }
1596 { Destination-Realm }
1597 { SIP-AOR }
1598 [ Destination-Host ]
1599 [ User-Name ]
1600 [ SIP-Visited-Network-Id ]
1601 [ SIP-User-Authorization-Type ]
1602 * [ Proxy-Info ]
1603 * [ Route-Record ]
1604 * [ AVP ]
1605
1606 */
1607 struct dict_object * cmd;
1608 struct dict_cmd_data data = {
1609 283, /* Code */
1610 "User-Authorization-Request", /* Name */
1611 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
1612 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
1613 };
1614 struct local_rules_definition rules[] =
1615 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
1616 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
1617 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
1618 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
1619 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
1620 ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
1621 ,{ "SIP-AOR", RULE_REQUIRED, -1, 1 }
1622 ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
1623 ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
1624 ,{ "SIP-Visited-Network-Id", RULE_OPTIONAL, -1, 1 }
1625 ,{ "SIP-User-Authorization-Type", RULE_OPTIONAL, -1, 1 }
1626 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
1627 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
1628
1629 };
1630
1631 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
1632 PARSE_loc_rules( rules, cmd );
1633 }
1634
1635 /* User-Authorization-Answer (UAA) Command */
1636 {
1637 /*
1638 The User-Authorization-Answer (UAA) is indicated by the Command-Code
1639 set to 283 and the Command Flags' 'R' bit cleared. The Diameter
1640 server sends this command in response to a previously received
1641 Diameter User-Authorization-Request (UAR) command. The Diameter
1642 server indicates the result of the requested registration
1643 authorization. Additionally, the Diameter server may indicate a
1644 collection of SIP capabilities that assists the Diameter client to
1645 select a SIP proxy to the AOR under registration.
1646
1647
1648 In addition to the values already defined in RFC 3588 [RFC3588], the
1649 Result-Code AVP may contain one of the values defined in
1650 Section 10.1.
1651
1652 Whenever the Diameter server fails to process the Diameter UAR
1653 message, it MUST stop processing and return the relevant error in the
1654 Diameter UAA message. When there is success in the process, the
1655 Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter
1656 UAA message.
1657
1658 If the Diameter server requires a User-Name AVP value to process the
1659 Diameter UAR request, but the Diameter UAR message did not contain a
1660 User-Name AVP value, the Diameter server MUST set the Result-Code AVP
1661 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return
1662 it in a Diameter UAA message. Upon reception of this Diameter UAA
1663 message with the Result-Code AVP value set to
1664 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
1665 authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy
1666 Authentication Required) response back to the originator.
1667
1668 When the authorization procedure succeeds, the Diameter server
1669 constructs a User-Authorization-Answer (UAA) message that MUST
1670 include (1) the address of the SIP server already assigned to the
1671 user name, (2) the capabilities needed by the SIP server (Diameter
1672 client) to select another SIP server for the user, or (3) a
1673 combination of the previous two options.
1674
1675 If the Diameter server is already aware of a SIP server allocated to
1676 the user, the Diameter UAA message contains the address of that SIP
1677 server.
1678
1679 The Diameter UAA message contains the capabilities required by a SIP
1680 server to trigger and execute services. It is required that these
1681 capabilities are present in the Diameter UAA message due to the
1682 possibility that the Diameter client (in the SIP server) allocates a
1683 different SIP server to trigger and execute services for that
1684 particular user.
1685
1686 If a User-Name AVP is present in the Diameter UAR message, then the
1687 Diameter server MUST verify the existence of the user in the realm,
1688 i.e., the User-Name AVP value is a valid user within that realm. If
1689 the Diameter server does not recognize the user name received in the
1690 User-Name AVP, the Diameter server MUST build a Diameter User-
1691 Authorization-Answer (UAA) message and MUST set the Result-Code AVP
1692 to DIAMETER_ERROR_USER_UNKNOWN.
1693
1694
1695 If a User-Name AVP is present in the Diameter UAR message, then the
1696 Diameter server MUST authorize that User-Name AVP value is able to
1697 register the SIP or SIPS URI included in the SIP-AOR AVP. If this
1698 authorization fails, the Diameter server must set the Result-Code AVP
1699 to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
1700 User-Authorization-Answer (UAA) message.
1701
1702 Note: Correlation between User-Name and SIP-AOR AVP values is
1703 required in order to avoid registration of a SIP-AOR allocated to
1704 another user.
1705
1706 If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message,
1707 and the SIP-User-Authorization-Type AVP value received in the
1708 Diameter UAR message is set to REGISTRATION or REGISTRATION&
1709 CAPABILITIES, then the Diameter server SHOULD verify whether the user
1710 is allowed to roam into the network specified in the
1711 SIP-Visited-Network-Id AVP in the Diameter UAR message. If the user
1712 is not allowed to roam into that network, the Diameter AAA server
1713 MUST set the Result-Code AVP value in the Diameter UAA message to
1714 DIAMETER_ERROR_ROAMING_NOT_ALLOWED.
1715
1716 If the SIP-User-Authorization-Type AVP value received in the Diameter
1717 UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES, then
1718 the Diameter server SHOULD verify whether the SIP-AOR AVP value is
1719 authorized to register in the Home Realm. Where the SIP AOR is not
1720 authorized to register in the Home Realm, the Diameter server MUST
1721 set the Result-Code AVP to DIAMETER_AUTHORIZATION_REJECTED and send
1722 it in a Diameter UAA message.
1723
1724 When the SIP-User-Authorization-Type AVP is not present in the
1725 Diameter UAR message, or when it is present and its value is set to
1726 REGISTRATION, then:
1727
1728 o If the Diameter server is not aware of any previous registration
1729 of the user name (including registrations of other SIP AORs
1730 allocated to the same user name), then the Diameter server does
1731 not know of any SIP server allocated to the user. In this case,
1732 the Diameter server MUST set the Result-Code AVP value to
1733 DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and the
1734 Diameter server SHOULD include the required SIP server
1735 capabilities in the SIP-Server-Capabilities AVP value in the
1736 Diameter UAA message. The SIP-Server-Capabilities AVP assists the
1737 Diameter client (SIP server) to select an appropriate SIP server
1738 for the user, according to the required capabilities.
1739
1740 o In some cases, the Diameter server is aware of a previously
1741 assigned SIP server for the same or different SIP AORs allocated
1742 to the same user name. In these cases, re-assignment of a new SIP
1743 server may or may not be needed, depending on the capabilities of
1744 the SIP server. The Diameter server MUST always include the
1745 allocated SIP server URI in the SIP-Server-URI AVP of the UAA
1746 message. If the Diameter server does not return the SIP
1747 capabilities, the Diameter server MUST set the Result-Code AVP in
1748 the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION.
1749 Otherwise (i.e., if the Diameter server includes a
1750 SIP-Server-Capabilities AVP), then the Diameter server MUST set
1751 the Result-Code AVP in the Diameter UAA message to
1752 DIAMETER_SERVER_SELECTION. Then the Diameter client determines,
1753 based on the received information, whether it needs to select a
1754 new SIP server.
1755
1756 When the SIP-User-Authorization-Type AVP value received in the
1757 Diameter UAR message is set to REGISTRATION&CAPABILITIES, then
1758 Diameter Server MUST return the list of capabilities in the
1759 SIP-Server-Capabilities AVP value of the Diameter UAA message, it
1760 MUST set the Result-Code to DIAMETER_SUCCESS, and it MUST NOT return
1761 a SIP-Server-URI AVP. The SIP-Server-Capabilities AVP enables the
1762 SIP server (Diameter client) to select another appropriate SIP server
1763 for invoking and executing services for the user, depending on the
1764 required capabilities. The Diameter server MAY leave the list of
1765 capabilities empty to indicate that any SIP server can be selected.
1766
1767 When the SIP-User-Authorization-Type AVP value received in the
1768 Diameter UAR message is set to DEREGISTRATION, then:
1769
1770 o If the Diameter server is aware of a SIP server assigned to the
1771 SIP AOR under deregistration, the Diameter server MUST set the
1772 Result-Code AVP to DIAMETER_SUCCESS and MUST set the
1773 SIP-Server-URI AVP value to the known SIP server, and return them
1774 in the Diameter UAA message.
1775
1776 o If the Diameter server is not aware of a SIP server assigned to
1777 the SIP AOR under deregistration, then the Diameter server MUST
1778 set the Result-Code AVP in the Diameter UAA message to
1779 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.
1780
1781 The Message Format of the UAA command is as follows:
1782
1783 <UAA> ::= < Diameter Header: 283, PXY >
1784 < Session-Id >
1785 { Auth-Application-Id }
1786 { Auth-Session-State }
1787 { Result-Code }
1788 { Origin-Host }
1789 { Origin-Realm }
1790 [ SIP-Server-URI ]
1791 [ SIP-Server-Capabilities ]
1792 [ Authorization-Lifetime ]
1793 [ Auth-Grace-Period ]
1794 [ Redirect-Host ]
1795 [ Redirect-Host-Usage ]
1796 [ Redirect-Max-Cache-Time ]
1797 * [ Proxy-Info ]
1798 * [ Route-Record ]
1799 * [ AVP ]
1800
1801
1802 */
1803 struct dict_object * cmd;
1804 struct dict_cmd_data data = {
1805 283, /* Code */
1806 "User-Authorization-Answer", /* Name */
1807 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
1808 CMD_FLAG_PROXIABLE /* Fixed flag values */
1809 };
1810 struct local_rules_definition rules[] =
1811 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
1812 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
1813 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
1814 ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
1815 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
1816 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
1817 ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
1818 ,{ "SIP-Server-Capabilities", RULE_OPTIONAL, -1, 1 }
1819 ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
1820 ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
1821 ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
1822 ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
1823 ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
1824 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
1825 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
1826
1827 };
1828
1829 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
1830 PARSE_loc_rules( rules, cmd );
1831 }
1832
1833 /* Multimedia-Auth-Request (MAR) Command */
1834 {
1835 /*
1836
1837 The Multimedia-Auth-Request (MAR) command is indicated by the
1838 Command-Code set to 286 and the Command Flags' 'R' bit set. The
1839 Diameter client in a SIP server sends this command to the Diameter
1840 server to request that the Diameter server authenticate and authorize
1841 a user attempt to use some SIP service (in this context, SIP service
1842 can be something as simple as a SIP subscription or using the proxy
1843 services for a SIP request).
1844
1845 The MAR command may also register the SIP server's own URI to the
1846 Diameter server, so that future LIR/LIA messages can return this URI.
1847 If the SIP server is acting as a SIP registrar (see examples in
1848 Sections 6.2 and 6.3), its Diameter client MUST include a SIP-
1849 Server-URI AVP in the MAR command. In any other cases (see example
1850 in Section 6.4), its Diameter client MUST NOT include a SIP-Server-
1851 URI AVP in the MAR command.
1852
1853 The SIP-Method AVP MUST include the SIP method name of the SIP
1854 request that triggered this Diameter MAR message. The Diameter
1855 server can use this AVP to authorize some SIP requests depending on
1856 the method.
1857
1858 The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP
1859 indicates the target of the SIP request. The value of the AVP is
1860 extracted from different places in SIP request, depending on the
1861 semantics of the SIP request. For SIP REGISTER messages the SIP-AOR
1862 AVP value indicates the intended public user identity under
1863 registration, and it is the SIP or SIPS URI populated in the To
1864 header field value (addr-spec as per RFC 3261 [RFC3261]) of the SIP
1865 REGISTER request. For other types of SIP requests, such as INVITE,
1866 SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the
1867 intended destination of the request. This is typically populated in
1868 the Request-URI of the SIP request. Extracting the SIP-AOR AVP value
1869 from the proper SIP header field is the Diameter client's
1870 responsibility. Extensions to SIP (new SIP methods or new semantics)
1871 may require the SIP-AOR to be extracted from other parts of the
1872 request.
1873
1874 If the SIP request includes some sort of authentication information,
1875 the Diameter client MUST include the user name, extracted from the
1876 authentication information of the SIP request, in the User-Name AVP
1877 value.
1878
1879 The Message Format of the MAR command is as follows:
1880
1881 <MAR> ::= < Diameter Header: 286, REQ, PXY >
1882 < Session-Id >
1883 { Auth-Application-Id }
1884 { Auth-Session-State }
1885 { Origin-Host }
1886 { Origin-Realm }
1887 { Destination-Realm }
1888 { SIP-AOR }
1889 { SIP-Method }
1890 [ Destination-Host ]
1891 [ User-Name ]
1892 [ SIP-Server-URI ]
1893 [ SIP-Number-Auth-Items ]
1894 [ SIP-Auth-Data-Item ]
1895 * [ Proxy-Info ]
1896 * [ Route-Record ]
1897 * [ AVP ]
1898
1899
1900
1901 */
1902 struct dict_object * cmd;
1903 struct dict_cmd_data data = {
1904 286, /* Code */
1905 "Multimedia-Auth-Request", /* Name */
1906 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
1907 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
1908 };
1909 struct local_rules_definition rules[] =
1910 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
1911 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
1912 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
1913 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
1914 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
1915 ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
1916 ,{ "SIP-AOR", RULE_REQUIRED, -1, 1 }
1917 ,{ "SIP-Method", RULE_REQUIRED, -1, 1 }
1918 ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
1919 ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
1920 ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
1921 ,{ "SIP-Number-Auth-Items", RULE_OPTIONAL, -1, 1 }
1922 ,{ "SIP-Auth-Data-Item", RULE_OPTIONAL, -1, 1 }
1923 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
1924 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
1925
1926 };
1927
1928 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
1929 PARSE_loc_rules( rules, cmd );
1930 }
1931 /* Multimedia-Auth-Answer (MAA) Command */
1932 {
1933 /*
1934
1935 The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set
1936 to 286 and the Command Flags' 'R' bit cleared. The Diameter server
1937 sends this command in response to a previously received Diameter
1938 Multimedia-Auth-Request (MAR) command.
1939
1940 In addition to the values already defined in RFC 3588 [RFC3588], the
1941 Result-Code AVP may contain one of the values defined in
1942 Section 10.1.
1943
1944 If the Diameter server requires a User-Name AVP value to process the
1945 Diameter MAR request, but the Diameter MAR message did not contain a
1946 User-Name AVP value, the Diameter server MUST set the Result-Code AVP
1947 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return
1948 it in a Diameter MAA message. The Diameter server MAY include a
1949 SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs
1950 with authentication information (e.g., a challenge). Upon reception
1951 of this Diameter MAA message with the Result-Code AVP value set to
1952 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
1953 authentication by generating a SIP 401 (Unauthorized) or SIP 407
1954 (Proxy Authentication Required) response back to the originator.
1955
1956 If the User-Name AVP is present in the Diameter MAR message, the
1957 Diameter server MUST verify the existence of the user in the realm,
1958 i.e., the User-Name AVP value is a valid user within that realm. If
1959 the Diameter server does not recognize the user name received in the
1960 User-Name AVP, the Diameter server MUST build a Diameter
1961 Multimedia-Auth-Answer (MAA) message and MUST set the Result-Code AVP
1962 to DIAMETER_ERROR_USER_UNKNOWN.
1963
1964 If the SIP-Methods AVP value of the Diameter MAR message is set to
1965 REGISTER and a User-Name AVP is present, then the Diameter server
1966 MUST authorize that User-Name AVP value is able to use the URI
1967 included in the SIP-AOR AVP. If this authorization fails, the
1968 Diameter server must set the Result-Code AVP to
1969 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
1970 Multimedia-Auth-Answer (MAA) message.
1971
1972 Note: Correlation between User-Name and SIP-AOR AVP values is only
1973 required for SIP REGISTER request, to prevent a user from
1974 registering a SIP-AOR allocated to another user. In other types
1975 of SIP requests (e.g., INVITE), the SIP-AOR indicates the intended
1976 destination of the request, rather than the originator of it.
1977
1978 The Diameter server MUST verify whether the authentication scheme
1979 (SIP-Authentication-Scheme AVP value) indicated in the grouped
1980 SIP-Auth-Data-Item AVP is supported or not. If that authentication
1981 scheme is not supported, then the Diameter server MUST set the
1982 Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send
1983 it in a Diameter Multimedia-Auth-Answer (MAA) message.
1984
1985 If the SIP-Number-Auth-Items AVP is present in the Diameter MAR
1986 message, it indicates the number of authentication data items that
1987 the Diameter client is requesting. It is RECOMMENDED that the
1988 Diameter server, when building the Diameter MAA message, includes a
1989 number of SIP-Auth-Data-Item AVPs that are a subset of the
1990 authentication data items requested by the Diameter client in the
1991 SIP-Number-Auth-Items AVP value of the Diameter MAR message.
1992
1993 If the SIP-Server-URI AVP is present in the Diameter MAR message,
1994 then the Diameter server MUST compare the stored SIP server (assigned
1995 to the user) with the SIP-Server-URI AVP value (received in the
1996 Diameter MAR message). If they don't match, the Diameter server MUST
1997 temporarily save the newly received SIP server assigned to the user,
1998 and MUST set an "authentication pending" flag for the user. If they
1999 match, the Diameter server shall clear the "authentication pending"
2000 flag for the user.
2001
2002 In any other situation, if there is a success in processing the
2003 Diameter MAR command and the Diameter server stored the
2004 SIP-Server-URI, the Diameter server MUST set the Result-Code AVP
2005 value to DIAMETER_SUCCESS and return it in a Diameter MAA message.
2006
2007 If there is a success in processing the Diameter MAR command, but the
2008 Diameter server does not store the SIP-Server-URI because the AVP was
2009 not present in the Diameter MAR command, then the Diameter server
2010 MUST set the Result-Code AVP value to either:
2011
2012 1. DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter
2013 server is sending authentication credentials to create a
2014 challenge.
2015
2016 2. DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the Diameter server
2017 successfully authenticated the user and authorized the SIP server
2018 to proceed with the SIP request.
2019
2020 Otherwise, the Diameter server MUST set the Result-Code AVP value to
2021 DIAMETER_UNABLE_TO_COMPLY, and it MUST NOT include any
2022 SIP-Auth-Data-Item AVP.
2023
2024 The Message Format of the MAA command is as follows:
2025
2026 <MAA> ::= < Diameter Header: 286, PXY >
2027 < Session-Id >
2028 { Auth-Application-Id }
2029 { Result-Code }
2030 { Auth-Session-State }
2031 { Origin-Host }
2032 { Origin-Realm }
2033 [ User-Name ]
2034 [ SIP-AOR ]
2035 [ SIP-Number-Auth-Items ]
2036 * [ SIP-Auth-Data-Item ]
2037 [ Authorization-Lifetime ]
2038 [ Auth-Grace-Period ]
2039 [ Redirect-Host ]
2040 [ Redirect-Host-Usage ]
2041 [ Redirect-Max-Cache-Time ]
2042 * [ Proxy-Info ]
2043 * [ Route-Record ]
2044 * [ AVP ]
2045
2046 */
2047 struct dict_object * cmd;
2048 struct dict_cmd_data data = {
2049 286, /* Code */
2050 "Multimedia-Auth-Answer", /* Name */
2051 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2052 CMD_FLAG_PROXIABLE /* Fixed flag values */
2053 };
2054 struct local_rules_definition rules[] =
2055 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2056 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2057 ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
2058 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2059 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2060 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2061 ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
2062 ,{ "SIP-AOR", RULE_OPTIONAL, -1, 1 }
2063 ,{ "SIP-Number-Auth-Items", RULE_OPTIONAL, -1, 1 }
2064 ,{ "SIP-Auth-Data-Item", RULE_OPTIONAL, -1, -1 }
2065 ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
2066 ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
2067 ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
2068 ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
2069 ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
2070 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2071 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2072
2073 };
2074
2075 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2076 PARSE_loc_rules( rules, cmd );
2077 }
2078 /* Server-Assignment-Request (SAR) Command */
2079 {
2080 /*
2081
2082 The Server-Assignment-Request (SAR) command is indicated by the
2083 Command-Code set to 284 and the Command Flags' 'R' bit set. The
2084 Diameter client in a SIP server sends this command to the Diameter
2085 server to indicate the completion of the authentication process and
2086 to request that the Diameter server store the URI of the SIP server
2087 that is currently serving the user. The main functions of the
2088 Diameter SAR command are to inform the Diameter server of the URI of
2089 the SIP server allocated to the user, and to store or clear it from
2090 the Diameter server. Additionally, the Diameter client can request
2091 to download the user profile or part of it.
2092
2093 During the registration procedure, a SIP server becomes assigned to
2094 the user. The Diameter client in the assigned SIP server MUST
2095 include its own URI in the SIP-Server-URI AVP of the
2096 Server-Assignment-Request (SAR) Diameter message and send it to the
2097 Diameter server. The Diameter server then becomes aware of the
2098 allocation of the SIP server to the user name and the server's URI.
2099
2100 The Diameter client in the SIP server MAY send a Diameter SAR message
2101 because of other reasons. These reasons are identified in the
2102 SIP-Server-Assignment-Type AVP (Section 9.4) value. For instance, a
2103 Diameter client in a SIP server may contact the Diameter server to
2104 request deregistration of a user, to inform the Diameter server of an
2105 authentication failure, or just to download the user profile. For a
2106 complete description of all the SIP-Server-Assignment-Type AVP
2107 values, see Section 9.4.
2108
2109 Typically the reception of a SIP REGISTER request in a SIP server
2110 will trigger the Diameter client in the SIP server to send the
2111 Diameter SAR message. However, if a SIP server is receiving other
2112 SIP request, such as INVITE, and the SIP server does not have the
2113 user profile, the Diameter client in the SIP server may send the
2114 Diameter SAR message to the Diameter server in order to download the
2115 user profile and make the Diameter server aware of the SIP server
2116 assigned to the user.
2117 The user profile is an important piece of information that dictates
2118 the behavior of the SIP server when triggering or providing services
2119 for the user. Typically the user profile is divided into:
2120
2121 o Services to be rendered to the user when the user is registered
2122 and initiates a SIP request.
2123
2124 o Services to be rendered to the user when the user is registered
2125 and a SIP request destined to that user arrives to the SIP proxy.
2126
2127 o Services to be rendered to the user when the user is not
2128 registered and a SIP request destined to that user arrives to the
2129 SIP proxy.
2130
2131 The SIP-Server-Assignment-Type AVP indicates the reason why the
2132 Diameter client (SIP server) contacted the Diameter server. If the
2133 Diameter client sets the SIP-Server-Assignment-Type AVP value to
2134 REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT,
2135 AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client
2136 MUST include exactly one SIP-AOR AVP in the Diameter SAR message.
2137
2138 The SAR message MAY contain zero or more SIP-Supported-User-Data-Type
2139 AVPs. Each of them contains a type of user data understood by the
2140 SIP server. This allows the Diameter client to provide an indication
2141 to the Diameter server of the different format of user data
2142 understood by the SIP server. The Diameter server uses this
2143 information to select one or more SIP-User-Data AVPs that will be
2144 included in the SAA message.
2145
2146 The Message Format of the SAR command is as follows:
2147
2148 <SAR> ::= < Diameter Header: 284, REQ, PXY >
2149 < Session-Id >
2150 { Auth-Application-Id }
2151 { Auth-Session-State }
2152 { Origin-Host }
2153 { Origin-Realm }
2154 { Destination-Realm }
2155 { SIP-Server-Assignment-Type }
2156 { SIP-User-Data-Already-Available }
2157 [ Destination-Host ]
2158 [ User-Name ]
2159 [ SIP-Server-URI ]
2160 * [ SIP-Supported-User-Data-Type ]
2161 * [ SIP-AOR ]
2162 * [ Proxy-Info ]
2163 * [ Route-Record ]
2164 * [ AVP ]
2165 */
2166 struct dict_object * cmd;
2167 struct dict_cmd_data data = {
2168 284, /* Code */
2169 "Server-Assignment-Request", /* Name */
2170 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2171 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
2172 };
2173 struct local_rules_definition rules[] =
2174 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2175 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2176 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2177 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2178 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2179 ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
2180 ,{ "SIP-Server-Assignment-Type", RULE_REQUIRED, -1, 1 }
2181 ,{ "SIP-User-Data-Already-Available", RULE_REQUIRED, -1, 1 }
2182 ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
2183 ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
2184 ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
2185 ,{ "SIP-Supported-User-Data-Type", RULE_OPTIONAL, -1, -1 }
2186 ,{ "SIP-AOR", RULE_OPTIONAL, -1, -1 }
2187 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2188 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2189
2190 };
2191
2192 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2193 PARSE_loc_rules( rules, cmd );
2194 }
2195 /* Server-Assignment-Answer (SAA) Command */
2196 {
2197 /*
2198
2199 The Server-Assignment-Answer (SAA) is indicated by the Command-Code
2200 set to 284 and the Command Flags' 'R' bit cleared. The Diameter
2201 server sends this command in response to a previously received
2202 Diameter Server-Assignment-Request (SAR) command. The response may
2203 include the user profile or part of it, if requested.
2204
2205 In addition to the values already defined in RFC 3588 [RFC3588], the
2206 Result-Code AVP may contain one of the values defined in
2207 Section 10.1.
2208
2209 The Result-Code AVP value in the Diameter SAA message may indicate a
2210 success or an error in the execution of the Diameter SAR command. If
2211 Result-Code AVP value in the Diameter SAA message does not contain an
2212 error code, the SAA message MAY include one or more SIP-User-Data
2213 AVPs that typically contain the profile of the user, indicating
2214 services that the SIP server can provide to that user.
2215
2216 The Diameter server MAY include one or more
2217 SIP-Supported-User-Data-Type AVPs, each one identifying a type of
2218 user data format supported in the Diameter server. If there is not a
2219 common supported user data type between the Diameter client and the
2220 Diameter server, the Diameter server SHOULD declare its list of
2221 supported user data types by including one or more
2222 SIP-Supported-User-Data-Type AVPs in a Diameter SAA message. This
2223 indication is merely for debugging reasons, since there is not a
2224 fallback mechanism that allows the Diameter client to retrieve the
2225 profile in a supported format.
2226
2227 If the Diameter server requires a User-Name AVP value to process the
2228 Diameter SAR request, but the Diameter SAR message did not contain a
2229 User-Name AVP value, the Diameter server MUST set the Result-Code AVP
2230 value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return
2231 it in a Diameter SAA message. Upon reception of this Diameter SAA
2232 message with the Result-Code AVP value set to
2233 DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
2234 authentication by generating a SIP 401 (Unauthorized) or SIP 407
2235 (Proxy Authentication Required) response back to the originator.
2236
2237 If the User-Name AVP is included in the Diameter SAR message, upon
2238 reception of the Diameter SAR message, the Diameter server MUST
2239 verify the existence of the user in the realm, i.e., the User-Name
2240 AVP value is a valid user within that realm. If the Diameter server
2241 does not recognize the user name received in the User-Name AVP, the
2242 Diameter server MUST build a Diameter Server-Assignment-Answer (SAA)
2243 message and MUST set the Result-Code AVP to
2244 DIAMETER_ERROR_USER_UNKNOWN.
2245 Then the Diameter server MUST authorize that User-Name AVP value is a
2246 valid authentication name for the SIP or SIPS URI included in the
2247 SIP-AOR AVP of the Diameter SAR message. If this authorization
2248 fails, the Diameter server must set the Result-Code AVP to
2249 DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
2250 Server-Assignment-Answer (SAA) message.
2251
2252 After successful execution of the Diameter SAR command, the Diameter
2253 server MUST clear the "authentication pending" flag and SHOULD move
2254 the temporarily stored SIP server URI to permanent storage.
2255
2256 The actions of the Diameter server upon reception of the Diameter SAR
2257 message depend on the value of the SIP-Server-Assignment-Type:
2258
2259 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
2260 message is set to REGISTRATION or RE_REGISTRATION, the Diameter
2261 server SHOULD verify that there is only one SIP-AOR AVP.
2262 Otherwise, the Diameter server MUST answer with a Diameter SAA
2263 message with the Result-Code AVP value set to
2264 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any
2265 SIP-User-Data AVP. If there is only one SIP-AOR AVP and if the
2266 SIP-User-Data-Already-Available AVP value is set to
2267 USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
2268 one or more user profile data with the SIP or SIPS URI (SIP-AOR
2269 AVP) and all other SIP identities associated with that AVP in the
2270 SIP-User-Data AVP value of the Diameter SAA message. On selecting
2271 the type of user data, the Diameter server SHOULD take into
2272 account the supported formats at the SIP server
2273 (SIP-Supported-User-Data-Type AVP in the SAR message) and the
2274 local policy. Additionally, the Diameter server MUST set the
2275 Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
2276 message. The Diameter server considers the SIP AOR authenticated
2277 and registered.
2278
2279 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
2280 message is set to UNREGISTERED_USER, then the Diameter server MUST
2281 store the SIP server address included in the SIP-Server-URI AVP
2282 value. The Diameter server will return the SIP server address in
2283 Diameter Location-Info-Answer (LIA) messages. If the
2284 SIP-User-Data-Already-Available AVP value is set to
2285 USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
2286 one or more user profile data associated with the SIP or SIPS URI
2287 (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP
2288 value of the Diameter SAA message. On selecting the type of user
2289 data, the Diameter server SHOULD take into account the supported
2290 formats at the SIP server (SIP-Supported-User-Data-Type AVP in the
2291 SAR message) and the local policy. The Diameter server MUST set
2292 the Result-Code AVP value to DIAMETER_SUCCESS. The Diameter
2293 server considers the SIP AOR UNREGISTERED, but with a SIP server
2294 allocated to trigger and provide services for unregistered users.
2295 Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type
2296 AVP), the Diameter server MUST verify that there is only one
2297 SIP-AOR AVP. Otherwise, the Diameter server MUST answer the
2298 Diameter SAR message with a Diameter SAA message, and it MUST set
2299 the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES
2300 and MUST NOT include any SIP-User-Data AVP.
2301 If the User-Name AVP was not present in the Diameter SAR message
2302 and the SIP-AOR is not known for the Diameter server, the Diameter
2303 server MUST NOT include a User-Name AVP in the Diameter SAA
2304 message and MUST set the Result-Code AVP value to
2305 DIAMETER_ERROR_USER_UNKNOWN.
2306
2307 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
2308 message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION,
2309 DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION,
2310 the Diameter server MUST clear the SIP server address associated
2311 with all SIP AORs indicated in each of the SIP-AOR AVP values
2312 included in the Diameter SAR message. The Diameter server
2313 considers all of these SIP AORs as not registered. The Diameter
2314 server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in
2315 the Diameter SAA message.
2316
2317 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
2318 message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or
2319 USER_DEREGISTRATION_STORE_SERVER_NAME, the Diameter server MAY
2320 keep the SIP server address associated with the SIP AORs included
2321 in the SIP-AOR AVP values of the Diameter SAR message, even though
2322 the SIP AORs become unregistered. This feature allows a SIP
2323 server to request that the Diameter server remain an assigned SIP
2324 server for those SIP AORs (SIP-AOR AVP values) allocated to the
2325 same user name, and avoid SIP server assignment. The Diameter
2326 server MUST consider all these SIP AORs as not registered. If the
2327 Diameter server honors the request of the Diameter client (SIP
2328 server) to remain as an allocated SIP server, then the Diameter
2329 server MUST keep the SIP server assigned to those SIP AORs
2330 allocated to the username and MUST set the Result-Code AVP value
2331 to DIAMETER_SUCCESS in the Diameter SAA message. Otherwise, when
2332 the Diameter server does not honor the request of the Diameter
2333 client (SIP server) to remain as an allocated SIP server, the
2334 Diameter server MUST clear the SIP server name assigned to those
2335 SIP AORs and it MUST set the Result-Code AVP value to
2336 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA
2337 message.
2338 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
2339 message is set to NO_ASSIGNMENT, the Diameter server SHOULD first
2340 verify that the SIP-Server-URI AVP value in the Diameter SAR
2341 message is the same URI as the one assigned to the SIP-AOR AVP
2342 value. If they differ, then the Diameter server MUST set the
2343 Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter
2344 SAA message. Otherwise, if the SIP-User-Data-Already-Available
2345 AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter
2346 server SHOULD include the user profile data with the SIP or SIPS
2347 URI (SIP-AOR AVP) and all other SIP identities associated with
2348 that AVP in the SIP-User-Data AVP value of the Diameter SAA
2349 message. On selecting the type of user data, the Diameter server
2350 SHOULD take into account the supported formats at the SIP server
2351 (SIP-Supported-User-Data-Type AVP in the SAR message) and the
2352 local policy.
2353
2354 o If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
2355 message is set to AUTHENTICATION_FAILURE or
2356 AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there
2357 is exactly one SIP-AOR AVP in the Diameter SAR message. If the
2358 number of occurrences of the SIP-AOR AVP is not exactly one, the
2359 Diameter server MUST set the Result-Code AVP value to
2360 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message,
2361 and SHOULD not take further actions. If there is exactly one
2362 SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST
2363 clear the address of the SIP server assigned to the SIP AOR
2364 allocated to the user name, and the Diameter server MUST set the
2365 Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
2366 message. The Diameter server MUST consider the SIP AOR as not
2367 registered.
2368
2369 The Message Format of the SAA command is as follows:
2370
2371 <SAA> ::= < Diameter Header: 284, PXY >
2372 < Session-Id >
2373 { Auth-Application-Id }
2374 { Result-Code }
2375 { Auth-Session-State }
2376 { Origin-Host }
2377 { Origin-Realm }
2378 * [ SIP-User-Data ]
2379 [ SIP-Accounting-Information ]
2380 * [ SIP-Supported-User-Data-Type ]
2381 [ User-Name ]
2382 [ Auth-Grace-Period ]
2383 [ Authorization-Lifetime ]
2384 [ Redirect-Host ]
2385 [ Redirect-Host-Usage ]
2386 [ Redirect-Max-Cache-Time ]
2387 * [ Proxy-Info ]
2388 * [ Route-Record ]
2389 * [ AVP ]
2390
2391
2392
2393
2394 */
2395 struct dict_object * cmd;
2396 struct dict_cmd_data data = {
2397 284, /* Code */
2398 "Server-Assignment-Answer", /* Name */
2399 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2400 CMD_FLAG_PROXIABLE /* Fixed flag values */
2401 };
2402 struct local_rules_definition rules[] =
2403 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2404 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2405 ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
2406 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2407 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2408 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2409 ,{ "SIP-User-Data", RULE_OPTIONAL, -1, -1 }
2410 ,{ "SIP-Accounting-Information", RULE_OPTIONAL, -1, 1 }
2411 ,{ "SIP-Supported-User-Data-Type", RULE_OPTIONAL, -1, -1 }
2412 ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
2413 ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
2414 ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
2415 ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
2416 ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
2417 ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
2418 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2419 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2420
2421 };
2422
2423 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2424 PARSE_loc_rules( rules, cmd );
2425 }
2426 /* Location-Info-Request (LIR) Command */
2427 {
2428 /*
2429
2430 The Location-Info-Request (LIR) is indicated by the Command-Code set
2431 to 285 and the Command Flags' 'R' bit set. The Diameter client in a
2432 SIP server sends this command to the Diameter server to request
2433 routing information, e.g., the URI of the SIP server assigned to the
2434 SIP-AOR AVP value allocated to the users.
2435
2436 The Message Format of the LIR command is as follows:
2437
2438 <LIR> ::= < Diameter Header: 285, REQ, PXY >
2439 < Session-Id >
2440 { Auth-Application-Id }
2441 { Auth-Session-State }
2442 { Origin-Host }
2443 { Origin-Realm }
2444 { Destination-Realm }
2445 { SIP-AOR }
2446 [ Destination-Host ]
2447 * [ Proxy-Info ]
2448 * [ Route-Record ]
2449 * [ AVP ]
2450 */
2451 struct dict_object * cmd;
2452 struct dict_cmd_data data = {
2453 285, /* Code */
2454 "Location-Info-Request", /* Name */
2455 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2456 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
2457 };
2458 struct local_rules_definition rules[] =
2459 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2460 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2461 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2462 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2463 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2464 ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
2465 ,{ "SIP-AOR", RULE_REQUIRED, -1, 1 }
2466 ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
2467 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2468 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2469
2470 };
2471
2472 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2473 PARSE_loc_rules( rules, cmd );
2474 }
2475 /* Location-Info-Answer (LIA) Command */
2476 {
2477 /*
2478 The Location-Info-Answer (LIA) is indicated by the Command-Code set
2479 to 285 and the Command Flags' 'R' bit cleared. The Diameter server
2480 sends this command in response to a previously received Diameter
2481 Location-Info-Request (LIR) command.
2482
2483 In addition to the values already defined in RFC 3588 [RFC3588], the
2484 Result-Code AVP may contain one of the values defined in
2485 Section 10.1. When the Diameter server finds an error in processing
2486 the Diameter LIR message, the Diameter server MUST stop the process
2487 of the message and answer with a Diameter LIA message that includes
2488 the appropriate error code in the Result-Code AVP value. When there
2489 is no error, the Diameter server MUST set the Result-Code AVP value
2490 to DIAMETER_SUCCESS in the Diameter LIA message.
2491
2492 One of the errors that the Diameter server may find is that the
2493 SIP-AOR AVP value is not a valid user in the realm. In such cases,
2494 the Diameter server MUST set the Result-Code AVP value to
2495 DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message.
2496
2497 If the Diameter server cannot process the Diameter LIR command, e.g.,
2498 due to a database error, the Diameter server MUST set the Result-Code
2499 AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter
2500 LIA message. The Diameter server MUST NOT include any SIP-Server-URI
2501 or SIP-Server-Capabilities AVP in the Diameter LIA message.
2502
2503 The Diameter server may or may not be aware of a SIP server assigned
2504 to the SIP-AOR AVP value included in the Diameter LIR message. If
2505 the Diameter server is aware of a SIP server allocated to that
2506 particular user, the Diameter server MUST include the URI of such SIP
2507 server in the SIP-Server-URI AVP and return it in a Diameter LIA
2508 message. This is typically the situation when the user is either
2509 registered, or unregistered but a SIP server is still assigned to the
2510 user.
2511
2512 When the Diameter server is not aware of a SIP server allocated to
2513 the user (typically the case when the user unregistered), the
2514 Result-Code AVP value in the Diameter LIA message depends on whether
2515 the Diameter server is aware that the user has services defined for
2516 unregistered users:
2517
2518 o Those users who have services defined for unregistered users may
2519 require the allocation of a SIP server to trigger and perhaps
2520 execute those services. Therefore, when the Diameter server is
2521 not aware of an assigned SIP server, but the user has services
2522 defined for unregistered users, the Diameter server MUST set the
2523 Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return
2524 it in a Diameter LIA message. The Diameter server MAY also
2525 include a SIP-Server-Capabilities AVP to facilitate the SIP server
2526 (Diameter client) with the selection of an appropriate SIP server
2527 with the required capabilities. Absence of the SIP-Server-
2528 Capabilities AVP indicates to the SIP server (Diameter client)
2529 that any SIP server is suitable to be allocated for the user.
2530
2531 o Those users who do not have service defined for unregistered users
2532 do not require further processing. The Diameter server MUST set
2533 the Result-Code AVP value to
2534 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the
2535 Diameter client in a Diameter LIA message. The SIP server
2536 (Diameter client) may return the appropriate SIP response (e.g.,
2537 480 (Temporarily unavailable)) to the original SIP request.
2538
2539 The Message Format of the LIA command is as follows:
2540
2541 <LIA> ::= < Diameter Header: 285, PXY >
2542 < Session-Id >
2543 { Auth-Application-Id }
2544 { Result-Code }
2545 { Auth-Session-State }
2546 { Origin-Host }
2547 { Origin-Realm }
2548 [ SIP-Server-URI ]
2549 [ SIP-Server-Capabilities ]
2550 [ Auth-Grace-Period ]
2551 [ Authorization-Lifetime ]
2552 [ Redirect-Host ]
2553 [ Redirect-Host-Usage ]
2554 [ Redirect-Max-Cache-Time ]
2555 * [ Proxy-Info ]
2556 * [ Route-Record ]
2557 * [ AVP ]
2558 */
2559 struct dict_object * cmd;
2560 struct dict_cmd_data data = {
2561 285, /* Code */
2562 "Location-Info-Answer", /* Name */
2563 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2564 CMD_FLAG_PROXIABLE /* Fixed flag values */
2565 };
2566 struct local_rules_definition rules[] =
2567 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2568 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2569 ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
2570 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2571 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2572 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2573 ,{ "SIP-Server-URI", RULE_OPTIONAL, -1, 1 }
2574 ,{ "SIP-Server-Capabilities", RULE_OPTIONAL, -1, 1 }
2575 ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
2576 ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
2577 ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
2578 ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
2579 ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
2580 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2581 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2582
2583 };
2584
2585 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2586 PARSE_loc_rules( rules, cmd );
2587 }
2588 /* Registration-Termination-Request (RTR) Command */
2589 {
2590 /*
2591 The Registration-Termination-Request (RTR) command is indicated by
2592 the Command-Code set to 287 and the Command Flags' 'R' bit set. The
2593 Diameter server sends this command to the Diameter client in a SIP
2594 server to indicate to the SIP server that one or more SIP AORs have
2595 to be deregistered. The command allows an operator to
2596 administratively cancel the registration of a user from a centralized
2597 Diameter server.
2598
2599 The Diameter server has the capability to initiate the deregistration
2600 of a user and inform the SIP server by means of the Diameter RTR
2601 command. The Diameter server can decide whether only one SIP AOR is
2602 going to be deregistered, a list of SIP AORs, or all the SIP AORs
2603 allocated to the user.
2604
2605 The absence of a SIP-AOR AVP in the Diameter RTR message indicates
2606 that all the SIP AORs allocated to the user identified by the
2607 User-Name AVP are being deregistered.
2608
2609 The Diameter server MUST include a SIP-Deregistration-Reason AVP
2610 value to indicate the reason for the deregistration.
2611
2612 The Message Format of the RTR command is as follows:
2613
2614 <RTR> ::= < Diameter Header: 287, REQ, PXY >
2615 < Session-Id >
2616 { Auth-Application-Id }
2617 { Auth-Session-State }
2618 { Origin-Host }
2619 { Origin-Realm }
2620 { Destination-Host }
2621 { SIP-Deregistration-Reason }
2622 [ Destination-Realm ]
2623 [ User-Name ]
2624 * [ SIP-AOR ]
2625 * [ Proxy-Info ]
2626 * [ Route-Record ]
2627 * [ AVP ]
2628
2629
2630
2631
2632
2633 */
2634 struct dict_object * cmd;
2635 struct dict_cmd_data data = {
2636 287, /* Code */
2637 "Registration-Termination-Request", /* Name */
2638 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2639 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
2640 };
2641 struct local_rules_definition rules[] =
2642 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2643 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2644 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2645 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2646 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2647 ,{ "Destination-Host", RULE_REQUIRED, -1, 1 }
2648 ,{ "SIP-Deregistration-Reason",RULE_REQUIRED, -1, 1 }
2649 ,{ "Destination-Realm", RULE_OPTIONAL, -1, 1 }
2650 ,{ "User-Name", RULE_OPTIONAL, -1, 1 }
2651 ,{ "SIP-AOR", RULE_REQUIRED, -1, -1 }
2652 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2653 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2654
2655 };
2656
2657 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2658 PARSE_loc_rules( rules, cmd );
2659 }
2660 /* Registration-Termination-Answer (RTA) Command */
2661 {
2662 /*
2663 The Registration-Termination-Answer (RTA) is indicated by the
2664 Command-Code set to 287 and the Command Flags' 'R' bit cleared. The
2665 Diameter client sends this command in response to a previously
2666 received Diameter Registration-Termination-Request (RTR) command.
2667
2668 In addition to the values already defined in RFC 3588 [RFC3588], the
2669 Result-Code AVP may contain one of the values defined in
2670 Section 10.1.
2671
2672 If the SIP server (Diameter client) requires a User-Name AVP value to
2673 process the Diameter RTR request, but the Diameter RTR message did
2674 not contain a User-Name AVP value, the Diameter client MUST set the
2675 Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section
2676 10.1.2) and return it in a Diameter RTA message.
2677
2678 The SIP server (Diameter client) applies the administrative
2679 deregistration to each of the URIs included in each of the SIP-AOR
2680 AVP values, or, if there is no SIP-AOR AVP present in the Diameter
2681 RTR request, to all the URIs allocated to the User-Name AVP value.
2682
2683 The value of the SIP-Deregistration-Reason AVP in the Diameter RTR
2684 command has an effect on the actions performed at the SIP server
2685 (Diameter client):
2686
2687 o If the value is set to PERMANENT_TERMINATION, then the user has
2688 terminated his/her registration to the realm. If informing the
2689 interested parties (e.g., subscribers to the "reg" event
2690 [RFC3680]) about the administrative deregistration is supported
2691 through SIP procedures, the SIP server (Diameter client) will do
2692 so. The Diameter Client in the SIP Server SHOULD NOT request a
2693 new user registration. The SIP server clears the registration
2694 state of the deregistered AORs.
2695
2696 o If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter
2697 server informs the SIP server (Diameter client) that a new SIP
2698 server has been allocated to the user, due to some reason. The
2699 SIP server, if supported through SIP procedures, will inform the
2700 interested parties (e.g., subscribers to the "reg" event
2701 [RFC3680]) about the administrative deregistration at this SIP
2702 server. The Diameter client in the SIP server SHOULD NOT request
2703 a new user registration. The SIP server clears the registration
2704 state of the deregistered SIP AORs.
2705
2706 o If the value is set to SIP_SERVER_CHANGE, the Diameter server
2707 informs the SIP server (Diameter client) that a new SIP server has
2708 to be allocated to the user, e.g., due to user's capabilities
2709 requiring a new SIP server, or not enough resources in the current
2710 SIP server. If informing the interested parties about the
2711 administrative deregistration is supported through SIP procedures
2712 (e.g., subscriptions to the "reg" event [RFC3680]), the SIP server
2713 will do so. The Diameter client in the SIP Server SHOULD NOT
2714 request a new user registration. The SIP server clears the
2715 registration state of the deregistered SIP AORs.
2716
2717 o If the value is set to REMOVE_SIP_SERVER, the Diameter server
2718 informs the SIP server (Diameter client) that the SIP server will
2719 no longer be bound in the Diameter server with that user. The SIP
2720 server can delete all data related to the user.
2721
2722 The Message Format of the RTA command is as follows:
2723
2724 <RTA> ::= < Diameter Header: 287, PXY >
2725 < Session-Id >
2726 { Auth-Application-Id }
2727 { Result-Code }
2728 { Auth-Session-State }
2729 { Origin-Host }
2730 { Origin-Realm }
2731 [ Authorization-Lifetime ]
2732 [ Auth-Grace-Period ]
2733 [ Redirect-Host ]
2734 [ Redirect-Host-Usage ]
2735 [ Redirect-Max-Cache-Time ]
2736 * [ Proxy-Info ]
2737 * [ Route-Record ]
2738 * [ AVP ]
2739
2740 */
2741 struct dict_object * cmd;
2742 struct dict_cmd_data data = {
2743 287, /* Code */
2744 "Registration-Termination-Answer", /* Name */
2745 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2746 CMD_FLAG_PROXIABLE /* Fixed flag values */
2747 };
2748 struct local_rules_definition rules[] =
2749 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2750 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2751 ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
2752 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2753 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2754 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2755 ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
2756 ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
2757 ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
2758 ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
2759 ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
2760 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2761 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2762
2763 };
2764
2765 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2766 PARSE_loc_rules( rules, cmd );
2767 }
2768
2769 /* Push-Profile-Request (PPR) Command */
2770 {
2771 /*
2772 The Push-Profile-Request (PPR) command is indicated by the
2773 Command-Code set to 288 and the Command Flags' 'R' bit set. The
2774 Diameter server sends this command to the Diameter client in a SIP
2775 server to update either the user profile of an already registered
2776 user in that SIP server or the SIP accounting information. This
2777 allows an operator to modify the data of a user profile or the
2778 accounting information and push it to the SIP server where the user
2779 is registered.
2780
2781 Each user has a user profile associated with him/her and other
2782 accounting information. The profile or the accounting information
2783 may change with time, e.g., due to addition of new services to the
2784 user. When the user profile or the accounting information changes,
2785 the Diameter server sends a Diameter Push-Profile-Request (PPR)
2786 command to the Diameter client in a SIP server, in order to start
2787 applying those new services.
2788
2789 A PPR command MAY contain a SIP-Accounting-Information AVP that
2790 updates the addresses of the accounting servers. Changes in the
2791 addresses of the accounting servers take effect immediately. The
2792 Diameter client SHOULD close any existing accounting session with the
2793 existing server and start providing accounting information to the
2794 newly acquired accounting server.
2795
2796 A PPR command MAY contain zero or more SIP-User-Data AVP values
2797 containing the new user profile. On selecting the type of user data,
2798 the Diameter server SHOULD take into account the supported formats at
2799 the SIP server (SIP-Supported-User-Data-Type AVP sent in a previous
2800 SAR message) and the local policy.
2801
2802 The User-Name AVP indicates the user to whom the profile is
2803 applicable.
2804
2805 The Message Format of the PPR command is as follows:
2806
2807 <PPR> ::= < Diameter Header: 288, REQ, PXY >
2808 < Session-Id >
2809 { Auth-Application-Id }
2810 { Auth-Session-State }
2811 { Origin-Host }
2812 { Origin-Realm }
2813 { Destination-Realm }
2814 { User-Name }
2815 * [ SIP-User-Data ]
2816 [ SIP-Accounting-Information ]
2817 [ Destination-Host ]
2818 [ Authorization-Lifetime ]
2819 [ Auth-Grace-Period ]
2820 * [ Proxy-Info ]
2821 * [ Route-Record ]
2822 * [ AVP ]
2823
2824 */
2825 struct dict_object * cmd;
2826 struct dict_cmd_data data = {
2827 288, /* Code */
2828 "Push-Profile-Request", /* Name */
2829 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2830 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE /* Fixed flag values */
2831 };
2832 struct local_rules_definition rules[] =
2833 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2834 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2835 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2836 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2837 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2838 ,{ "Destination-Realm", RULE_REQUIRED, -1, 1 }
2839 ,{ "User-Name", RULE_REQUIRED, -1, 1 }
2840 ,{ "SIP-User-Data", RULE_OPTIONAL, -1, -1 }
2841 ,{ "SIP-Accounting-Information", RULE_OPTIONAL, -1, 1 }
2842 ,{ "Destination-Host", RULE_OPTIONAL, -1, 1 }
2843 ,{ "Authorization-Lifetime", RULE_OPTIONAL, -1, 1 }
2844 ,{ "Auth-Grace-Period", RULE_OPTIONAL, -1, 1 }
2845 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2846 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2847
2848 };
2849
2850 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2851 PARSE_loc_rules( rules, cmd );
2852 }
2853 /* Push-Profile-Answer (PPA) Command */
2854 {
2855 /*
2856
2857
2858 The Push-Profile-Answer (PPA) is indicated by the Command-Code set to
2859 288 and the Command Flags' 'R' bit cleared. The Diameter client
2860 sends this command in response to a previously received Diameter
2861 Push-Profile-Request (PPR) command.
2862
2863 In addition to the values already defined in RFC 3588 [RFC3588], the
2864 Result-Code AVP may contain one of the values defined in
2865 Section 10.1.
2866
2867 If there is no error when processing the received Diameter PPR
2868 message, the SIP server (Diameter client) MUST download the received
2869 user profile from the SIP-User-Data AVP values in the Diameter PPR
2870 message and store it associated with the user specified in the
2871 User-Name AVP value.
2872
2873 If the SIP server does not recognize or does not support some of the
2874 data transferred in the SIP-User-Data AVP values, the Diameter client
2875 in the SIP server MUST return a Diameter PPA message that includes a
2876 Result-Code AVP set to the value DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.
2877
2878 If the SIP server (Diameter client) receives a Diameter PPR message
2879 with a User-Name AVP that is unknown, the Diameter client MUST set
2880 the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and MUST
2881 return it to the Diameter server in a Diameter PPA message.
2882
2883 If the SIP server (Diameter client) receives in the
2884 SIP-User-Data-Content AVP value (of the grouped SIP-User-Data AVP)
2885 more data than it can accept, it MUST set the Result-Code AVP value
2886 to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter
2887 server in a Diameter PPA message. The SIP server MUST NOT override
2888 the existing user profile with the one received in the PPR message.
2889
2890 If the Diameter server receives the Result-Code AVP value set to
2891 DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD
2892 force a new re-registration of the user by sending to the Diameter
2893 client a Diameter Registration-Termination-Request (RTR) with the
2894 SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE. This
2895 will force a re-registration of the user and will trigger a selection
2896 of a new SIP server.
2897
2898 If the Diameter client is not able to honor the command, for any
2899 other reason, it MUST set the Result-Code AVP value to
2900 DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA
2901 message.
2902
2903 The Message Format of the PPA command is as follows:
2904
2905 <PPA> ::= < Diameter Header: 288, PXY >
2906 < Session-Id >
2907 { Auth-Application-Id }
2908 { Result-Code }
2909 { Auth-Session-State }
2910 { Origin-Host }
2911 { Origin-Realm }
2912 [ Redirect-Host ]
2913 [ Redirect-Host-Usage ]
2914 [ Redirect-Max-Cache-Time ]
2915 * [ Proxy-Info ]
2916 * [ Route-Record ]
2917 * [ AVP ]
2918
2919
2920
2921 */
2922 struct dict_object * cmd;
2923 struct dict_cmd_data data = {
2924 288, /* Code */
2925 "Push-Profile-Answer", /* Name */
2926 CMD_FLAG_REQUEST | CMD_FLAG_PROXIABLE | CMD_FLAG_ERROR, /* Fixed flags */
2927 CMD_FLAG_PROXIABLE /* Fixed flag values */
2928 };
2929 struct local_rules_definition rules[] =
2930 { { "Session-Id", RULE_FIXED_HEAD, -1, 1 }
2931 ,{ "Auth-Application-Id", RULE_REQUIRED, -1, 1 }
2932 ,{ "Result-Code", RULE_REQUIRED, -1, 1 }
2933 ,{ "Auth-Session-State", RULE_REQUIRED, -1, 1 }
2934 ,{ "Origin-Host", RULE_REQUIRED, -1, 1 }
2935 ,{ "Origin-Realm", RULE_REQUIRED, -1, 1 }
2936 ,{ "Redirect-Host", RULE_OPTIONAL, -1, 1 }
2937 ,{ "Redirect-Host-Usage", RULE_OPTIONAL, -1, 1 }
2938 ,{ "Redirect-Max-Cache-Time", RULE_OPTIONAL, -1, 1 }
2939 ,{ "Proxy-Info", RULE_OPTIONAL, -1, -1 }
2940 ,{ "Route-Record", RULE_OPTIONAL, -1, -1 }
2941
2942 };
2943
2944 CHECK_dict_new( DICT_COMMAND, &data , sip, &cmd);
2945 PARSE_loc_rules( rules, cmd );
2946 }
2947 }
2948
2949 LOG_D( "Extension 'Dictionary definitions for SIP' initialized");
2950 return 0;
2951 }
2952 EXTENSION_ENTRY("dict_sip", ds_dict_init);
2953