aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/standard/rfc4740.txt
blob: 2154334b662e6a0f5936d10e61355caca0dd7860 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
Network Working Group                              M. Garcia-Martin, Ed.
Request for Comments: 4740                                         Nokia
Category: Standards Track                                   M. Belinchon
                                                       M. Pallares-Lopez
                                                   C. Canales-Valenzuela
                                                                Ericsson
                                                                K. Tammi
                                                                   Nokia
                                                           November 2006


         Diameter Session Initiation Protocol (SIP) Application

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   This document specifies the Diameter Session Initiation Protocol
   (SIP) application.  This is a Diameter application that allows a
   Diameter client to request authentication and authorization
   information.  This application is designed to be used in conjunction
   with SIP and provides a Diameter client co-located with a SIP server,
   with the ability to request the authentication of users and
   authorization of SIP resources usage from a Diameter server.

















Garcia-Martin, et al.       Standards Track                     [Page 1]

RFC 4740                Diameter SIP Application           November 2006


Table of Contents

   1. Introduction ....................................................4
   2. Terminology .....................................................5
   3. Definitions .....................................................5
   4. Acronyms ........................................................6
   5. Applicability Statement .........................................6
   6. Overview of Operation ...........................................7
      6.1. General Architecture .......................................7
      6.2. Diameter Server Authenticates the User .....................9
      6.3. Delegating Final Authentication Check to the SIP Server ...12
      6.4. SIP Server Requests Authentication and Authorization ......15
      6.5. Locating the Recipient of the SIP Request .................16
      6.6. Update of the User Profile ................................17
      6.7. SIP Soft State Termination ................................18
      6.8. Diameter Server Discovery .................................19
   7. Advertising Application Support ................................21
   8. Diameter SIP Application Command Codes .........................22
      8.1. User-Authorization-Request (UAR) Command ..................22
      8.2. User-Authorization-Answer (UAA) Command ...................23
      8.3. Server-Assignment-Request (SAR) Command ...................27
      8.4. Server-Assignment-Answer (SAA) Command ....................29
      8.5. Location-Info-Request (LIR) Command .......................33
      8.6. Location-Info-Answer (LIA) Command ........................33
      8.7. Multimedia-Auth-Request (MAR) Command .....................35
      8.8. Multimedia-Auth-Answer (MAA) Command ......................36
      8.9. Registration-Termination-Request (RTR) Command ............39
      8.10. Registration-Termination-Answer (RTA) Command ............39
      8.11. Push-Profile-Request (PPR) Command .......................41
      8.12. Push-Profile-Answer (PPA) Command ........................42
   9. Diameter SIP Application AVPs ..................................44
      9.1. SIP-Accounting-Information AVP ............................46
           9.1.1. SIP-Accounting-Server-URI AVP ......................47
           9.1.2. SIP-Credit-Control-Server-URI AVP ..................47
      9.2. SIP-Server-URI AVP ........................................47
      9.3. SIP-Server-Capabilities AVP ...............................47
           9.3.1. SIP-Mandatory-Capability AVP .......................48
           9.3.2. SIP-Optional-Capability AVP ........................48
      9.4. SIP-Server-Assignment-Type AVP ............................48
      9.5. SIP-Auth-Data-Item AVP ....................................50
           9.5.1. SIP-Authentication-Scheme AVP ......................50
           9.5.2. SIP-Item-Number AVP ................................51
           9.5.3. SIP-Authenticate AVP ...............................51
           9.5.4. SIP-Authorization AVP ..............................52
           9.5.5. SIP-Authentication-Info AVP ........................52
           9.5.6. Digest AVPs ........................................53
      9.6. SIP-Number-Auth-Items AVP .................................55




Garcia-Martin, et al.       Standards Track                     [Page 2]

RFC 4740                Diameter SIP Application           November 2006


      9.7. SIP-Deregistration-Reason AVP .............................55
           9.7.1. SIP-Reason-Code AVP ................................55
           9.7.2. SIP-Reason-Info AVP ................................56
      9.8. SIP-AOR AVP ...............................................56
      9.9. SIP-Visited-Network-Id AVP ................................56
      9.10. SIP-User-Authorization-Type AVP ..........................56
      9.11. SIP-Supported-User-Data-Type AVP .........................57
      9.12. SIP-User-Data AVP ........................................57
           9.12.1. SIP-User-Data-Type AVP ............................58
           9.12.2. SIP-User-Data-Contents AVP ........................58
      9.13. SIP-User-Data-Already-Available AVP ......................58
      9.14. SIP-Method AVP ...........................................59
   10. New Values for Existing AVPs ..................................59
      10.1. Extension to the Result-Code AVP Values ..................59
           10.1.1. Success Result-Code AVP Values ....................59
           10.1.2. Transient Failures Result-Code AVP Values .........60
           10.1.3. Permanent Failures Result-Code AVP Values .........60
   11. Authentication Details ........................................61
   12. Migration from RADIUS .........................................63
      12.1. Gateway from RADIUS Client to Diameter Server ............63
      12.2. Gateway from Diameter Client to RADIUS Server ............63
      12.3. Known Limitations ........................................64
   13. IANA Considerations ...........................................64
      13.1. Application Identifier ...................................64
      13.2. Command Codes ............................................65
      13.3. AVP Codes ................................................65
      13.4. Additional Values for the Result-Code AVP Value ..........65
      13.5. Creation of the SIP-Server-Assignment-Type
            Section in the AAA .......................................66
      13.6. Creation of the SIP-Authentication-Scheme Section
            in the AAA ...............................................66
      13.7. Creation of the SIP-Reason-Code Section in the
            AAA Registry .............................................66
      13.8. Creation of the SIP-User-Authorization-Type
            Section in the AAA .......................................66
      13.9. Creation of the SIP-User-Data-Already-Available
            Section in the ...........................................66
   14. Security Considerations .......................................67
      14.1. Final Authentication Check in the Diameter
            Client/SIP Server ........................................67
   15. Contributors ..................................................68
   16. Acknowledgements ..............................................68
   17. References ....................................................68
      17.1. Normative References .....................................68
      17.2. Informative References ...................................69






Garcia-Martin, et al.       Standards Track                     [Page 3]

RFC 4740                Diameter SIP Application           November 2006


1.  Introduction

   This document specifies the Diameter Session Initiation Protocol
   (SIP) application.  This is a Diameter application that allows a
   Diameter client to request authentication and authorization
   information to a Diameter server for SIP-based IP multimedia services
   (see [RFC3261] about SIP).  Furthermore, this Diameter SIP
   application provides the Diameter client with functions that go
   beyond the typical authorization and authentication, such as the
   ability to download or receive updated user profiles, or rudimentary
   routing functions that can assist a SIP server in finding another SIP
   server allocated to the user.

   We assume that the SIP server (such as SIP proxy server, registrar,
   redirect server, or alike) and the Diameter client are co-located in
   the same node, so that the SIP server is able to receive and process
   SIP requests and responses.  In turn, the SIP server relies on the
   Authentication, Authorization, and Accounting (AAA) infrastructure
   for authenticating the SIP request and authorizing the usage of
   particular SIP services.

   This document provides Diameter procedures to implement certain
   required functionality when SIP is the protocol chosen to initiate
   and tear down multimedia sessions or when SIP is used for other
   non-session-related applications.  However, this document does not
   mandate any particular mapping of SIP procedures to Diameter SIP
   application procedures, nor does it mandate any particular sequence
   of events between SIP and Diameter.  This document provides useful
   examples to show the interaction between SIP and the Diameter SIP
   application in order to achieve the desired functionality.

   This application does not require and is not related to other
   authentication services provided by the Diameter Mobile IPv4
   [RFC4004] or the Diameter Network Access Server [RFC4005]
   applications.

   This Diameter SIP application is loosely related to the Diameter
   credit-control application [RFC4006].  Although both applications are
   independent, the Diameter SIP application is able to supply the
   addresses of credit-control servers that will be implementing the
   Diameter credit-control application [RFC4006].

   Section 5 discusses assumptions and configurations assumed by this
   document.

   Section 6 provides the reader with informative descriptions of the
   Diameter SIP application commands and responses and with some
   guidance about their linkage with SIP procedures.



Garcia-Martin, et al.       Standards Track                     [Page 4]

RFC 4740                Diameter SIP Application           November 2006


   Advertisement of this application is specified in Section 7.

   Section 8 provides a normative description of all the new Diameter
   commands defined by this specification.

   This application extends the Result-Code Attribute-Value-Pair (AVP)
   with some new values.  Further information is described in
   Section 10.

   This application defines some new AVPs.  All these AVPs are described
   in Section 9.

   Some extra information about authentication is provided in
   Section 11.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.

3.  Definitions

   For the purpose of this document, the following terms and definitions
   apply:

   Node:  an addressable device attached to a computer network that
      implements SIP functionality, Diameter functionality, or a
      combination of both.

   For the purpose of this document, the following terms and definitions
   given in RFC 3261 [RFC3261] Section 6, apply:

   o  Address-of-Record (AOR)
   o  Outbound proxy
   o  Proxy
   o  Registrar
   o  Server (SIP server)
   o  User Agent (UA)
   o  User Agent Client (UAC)
   o  User Agent Server (UAS)

   For the purpose of this document, the following terms and definitions
   given in RFC 3588 [RFC3588] Section 1.3, apply:





Garcia-Martin, et al.       Standards Track                     [Page 5]

RFC 4740                Diameter SIP Application           November 2006


   o  Authorization
   o  Authentication
   o  Attribute-Value Pair (AVP)
   o  Diameter Client
   o  Diameter Server
   o  Home Realm
   o  Redirect Agent
   o  User

4.  Acronyms

   AKA:  Authentication and Key Agreement
   LIR:  Location-Info-Request
   LIA:  Location-Info-Answer
   MAR:  Multimedia-Auth-Request
   MAA:  Multimedia-Auth-Answer
   PPR:  Push-Profile-Request
   PPA:  Push-Profile-Answer
   RTR:  Registration-Termination-Request
   RTA:  Registration-Termination-Answer
   SAR:  Server-Assignment-Request
   SAA:  Server-Assignment-Answer
   SL:   Subscriber Locator
   UAR:  User-Authorization-Request
   UAA:  User-Authorization-Answer

5.  Applicability Statement

   This document assumes a general architecture where a Home Realm is
   composed of one or more nodes implementing Diameter or SIP functions.
   Users are issuing SIP requests to access SIP resources.  For each
   particular user, the Home Realm needs to authenticate and authorize
   the usage of those resources and/or the route to the appropriate
   node.  We assume that the database containing the user-related data
   is located outside the SIP node that requires authorization.  Data
   belonging to different users may be stored in different nodes in the
   Home Realm, but we assume that all the data related to a particular
   user is stored in a single node.

      Note: Central to the architecture is the fact that the user data
      is stored in a single point in the network.  This restriction does
      not mandate a particular implementation, e.g., it is possible to
      implement clusters of databases operating in mirror mode to
      provide redundancy.  The property required by this specification
      is that the user data the Diameter server has access to is stored
      safely in what is seen, from the external point of view, as a
      single user database.




Garcia-Martin, et al.       Standards Track                     [Page 6]

RFC 4740                Diameter SIP Application           November 2006


   This document allows several configurations of the Home Realm.  In
   one configuration, a SIP server (proxy, registrar, etc.) is allocated
   to a user for the purpose of triggering and executing services.  The
   allocation of the SIP server may be done dynamically, e.g., at the
   time the user registers in the network.  This configuration requires
   a SIP server, typically located at the edge of the network, that is
   able to allocate another SIP server for the user and that also
   supports routing of SIP requests and responses towards that allocated
   SIP server.  Both SIP server nodes implement a Diameter client.

   In another configuration, the address of a SIP outbound proxy is
   configured (by means outside the scope of this specification) into
   the SIP User Agent.  The outbound Diameter client in the SIP outbound
   proxy node authenticates the user, requests authorization for SIP
   requests, and performs accounting activities.

6.  Overview of Operation

   This section provides an informative description of how the Diameter
   SIP application can be used together with SIP.  This section is not
   intended to mandate any specific usage of the Diameter SIP
   application nor does it mandate a specific mapping between SIP and
   Diameter messages.  We provide a collection of examples that show how
   the required AAA functionality can be achieved in conjunction with
   SIP.

6.1.  General Architecture

   The Diameter SIP application can be used in a SIP environment where
   an interface to a AAA infrastructure is required to authenticate and
   authorize the usage of SIP resources.  This application provides
   support for SIP User Agents and proxies that implement and use HTTP
   Digest authentication [RFC2617], which is the authentication
   mechanism mandated by SIP [RFC3261].  The application is extensible
   and, if need arises, it can be extended to provide support for other
   authentication mechanisms or extensions to HTTP Digest authentication
   when they occur.

   This application provides limited support for accounting services as
   follows: the Diameter server is able to provide the addresses of
   accounting severs to the Diameter client.  Figure 1, below, shows a
   general overview of the integration of the SIP architecture with the
   AAA architecture.

   According to Figure 1, there are one or more SIP User Agents (UAs)
   that initiate or terminate SIP traffic through one or more SIP
   servers.  Both SIP servers implement a Diameter client that supports
   the Diameter application described in this specification.



Garcia-Martin, et al.       Standards Track                     [Page 7]

RFC 4740                Diameter SIP Application           November 2006


                               +--------+
                  UAR/UAA +--->|Diameter|<----+ PPR/PPA
                  LIR/LIA |    | server |     | MAR/MAA
                          |    +--------+     | SAR/SAA
                          |                   | RTR/RTA
                          |                   |
                          v                   v
   +------+   SIP     +--------+    SIP   +--------+   SIP     +------+
   | SIP  |<--------->|  SIP   |<-------->|  SIP   |<--------->| SIP  |
   |  UA  |           |server 1|          |server 2|           |  UA  |
   +------+           +--------+          +--------+           +------+
                          ^                   ^
                  UAR/UAA |                   |
                  LIR/LIA |                   | MAR/MAA
                          |    +--------+     | SAR/SAA
                          +--->|Diameter|<----+
                               |   SL   |
                               +--------+

        Figure 1: Architecture of the Diameter application for SIP

   In Figure 1, it can be seen that SIP server 1 sends different
   Diameter commands and receives different responses than those sent
   and received by SIP server 2.  This is because SIP server 1 in
   Figure 1 is located at the edge of a network, and its main task is to
   locate SIP server 2.  SIP server 2 is requesting and receiving
   authentication and authorization data from the Diameter server and is
   not located at the edge of the network.

   This Diameter application assumes that all the data pertaining to a
   given user is stored in a single Diameter server.  For redundancy
   purposes, several Diameter servers can be configured in a redundancy
   fashion, in which case all of them keep the data synchronized and
   operate externally as a single Diameter server.

   With respect to SIP server 1 in Figure 1, the Diameter SIP
   application provides support for the existence of a farm of these
   servers, typically configured through one or more DNS records that
   point to several hosts (this is a typical configuration in common SIP
   deployments).  There is no requirement for these types of servers to
   keep state related to the Diameter SIP application.

   The Diameter SIP application provides support for a feature that
   allows an administrative domain to provide a collection of SIP
   servers 2 (as per Figure 1).  Once the user registers for the first
   time, one of these SIP servers is selected and all the SIP requests
   related to the user are processed by the same SIP server.




Garcia-Martin, et al.       Standards Track                     [Page 8]

RFC 4740                Diameter SIP Application           November 2006


   The Diameter Subscriber Locator (SL) serves the purpose of locating
   the Diameter server that contains the user-related data.  Its
   functionality is based on the Diameter redirect mechanism and is
   further described in Section 6.8.

   It should be noted that this document does not mandate any particular
   SIP/AAA architecture.  However, the Diameter SIP application provides
   the functionality needed to accommodate all the different
   architectures where SIP and Diameter are used.

   The following subsections provide an informative overview of the
   Diameter SIP application, its commands, and a possible interaction
   with SIP signaling.

6.2.  Diameter Server Authenticates the User

   This is the generic mechanism to authenticate users.  In this
   approach, we show an example of an administrative network where the
   Diameter server is authenticating SIP user requests.  This could be
   the case of a medium-size network where the Diameter server is
   keeping user records and authenticating SIP requests to perform a
   certain transaction.  We have chosen to show a SIP REGISTER request
   in the example, but the SIP server could request authentication of
   any other SIP request.



























Garcia-Martin, et al.       Standards Track                     [Page 9]

RFC 4740                Diameter SIP Application           November 2006


                    +--------+           +--------+         +--------+
                    |  SIP   |           |Diameter|         |  SIP   |
                    |server 1|           | server |         |server 2|
                    +--------+           +--------+         +--------+
                         |                   |                   |
    1. SIP REGISTER      |                   |                   |
    -------------------->|     2. UAR        |                   |
                         |------------------>|                   |
                         |     3. UAA        |                   |
                         |<------------------|                   |
                         |         4. SIP REGISTER               |
                         |-------------------------------------->|
                         |                   |      5. MAR       |
                         |                   |<------------------|
                         |                   |      6. MAA       |
                         |                   |------------------>|
                         |         7. SIP 401 (Unauthorized)     |
    8. SIP 401 (Unauth.) |<--------------------------------------|
    <--------------------|                   |                   |
    9. SIP REGISTER      |                   |                   |
    -------------------->|     10. UAR       |                   |
                         |------------------>|                   |
                         |     11. UAA       |                   |
                         |<------------------|                   |
                         |         12. SIP REGISTER              |
                         |-------------------------------------->|
                         |                   |      13. MAR      |
                         |                   |<------------------|
                         |                   |      14. MAA      |
                         |                   |------------------>|
                         |         15. SIP 200 (OK)              |
    16. SIP 200 (OK)     |<--------------------------------------|
    <--------------------|                   |                   |
                         |                   |      17. SAR      |
                         |                   |<------------------|
                         |                   |      18. SAA      |
                         |                   |------------------>|
                         |                   |                   |

         Figure 2: Authentication performed in the Diameter server

   According to Figure 2, a SIP User Agent Client (UAC) sends a SIP
   REGISTER request (step 1) to SIP server 1, which receives the SIP
   request.  In Figure 2, we assume that this SIP server is located at
   the edge of the administrative home domain.  The Diameter client in
   SIP server 1 contacts its Diameter server by sending a Diameter
   User-Authorization-Request (UAR) message (step 2) to determine if
   this user is allowed to receive service, and if so, request the



Garcia-Martin, et al.       Standards Track                    [Page 10]

RFC 4740                Diameter SIP Application           November 2006


   address of a local SIP server capable of handling this user.  The
   Diameter server answers with a Diameter User-Authorization-Answer
   (UAA) message (step 3), which indicates a list of capabilities that
   SIP server 1 may use to select an appropriate SIP server (SIP server
   2) and/or a SIP or SIPS URI pointing to SIP server 2.

   SIP server 1 forwards the SIP REGISTER request (step 4) to an
   appropriate SIP server (SIP server 2).  Then the Diameter client in
   SIP server 2 requests user authentication from the Diameter server by
   sending a Diameter Multimedia-Auth-Request (MAR) message (step 5).
   This request also serves to make the Diameter server aware of the SIP
   or SIPS URI of SIP server 2, so as to return subsequent requests for
   the same user to the same SIP server 2.  The Diameter server responds
   with a Diameter Multimedia-Auth-Answer (MAA) message (step 6) with
   Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH.  The
   Diameter server also generates a nonce and includes a challenge in
   the MAA message.  SIP server 2 uses that challenge to map into the
   WWW-Authenticate header in the SIP 401 (Unauthorized) response (step
   7), which is sent back to SIP server 1 and then to the SIP UAC (step
   8).

   SIP server 1 receives a next SIP REGISTER request containing the user
   credentials (step 9).  Note that SIP server 1 does not need to keep a
   state, and even more, there is no guarantee that the SIP request
   arrives at the same SIP server 1; there could be a farm of SIP
   servers 1 operating in redundant configuration.  The Diameter client
   in SIP server 1 contacts the Diameter server by sending a Diameter
   UAR message (step 10) to determine the SIP server allocated to the
   user.  The Diameter server sends the SIP or SIPS URI of SIP server 2
   in a Diameter UAA message (step 11).

   Then SIP server 1 forwards the SIP REGISTER request to SIP server 2
   (step 12).  SIP server 2 extracts the credentials from the SIP
   REGISTER request.  The Diameter client in SIP server 2 sends those
   credentials in a Diameter MAR message (step 13) to the Diameter
   server.  At this point, the Diameter server is able to authenticate
   the user, and upon success, returns a Diameter MAA message (step 14)
   with the AVP Result-Code set to the value DIAMETER_SUCCESS.

   Then SIP server 2 generates a SIP 200 (OK) response (step 15), which
   is forwarded to SIP server 1 and eventually to the SIP UAC (step 16).

   If the Diameter client in SIP server 2 is interested in downloading
   the user profile information or is required to store the address of
   the SIP server in the Diameter server, then the Diameter client sends
   a Diameter SAR message (step 17) to the Diameter server.  The
   Diameter server replies with a Diameter SAA message (step 18) that
   contains the requested user profile information and the



Garcia-Martin, et al.       Standards Track                    [Page 11]

RFC 4740                Diameter SIP Application           November 2006


   acknowledgement of the SIP server address storage.  These actions are
   needed when the SIP server has to retrieve a user profile used to
   provide services to the served user, or when the SIP server keeps a
   state for the user, so the Diameter server needs to store the SIP
   server's address.

6.3.  Delegating Final Authentication Check to the SIP Server

   An operator with a large base of installed SIP servers may wish to
   minimize the number of round-trips between the Diameter client and
   the Diameter server.  We provide support for a mechanism where the
   Diameter server delegates the final authentication check to the SIP
   server, thereby saving a round-trip.  Section 14.1 discusses the
   security considerations of this scenario.

   It must noted that this scenario is not applicable when the Diameter
   server is configured to use a session MD5 (MD5-sess) algorithm,
   because the Diameter server requires the client nonce to compute the
   H(A1) before sending it to the Diameter client.  However, the client
   nonce might not be available at that time.































Garcia-Martin, et al.       Standards Track                    [Page 12]

RFC 4740                Diameter SIP Application           November 2006


                    +--------+           +--------+         +--------+
                    |  SIP   |           |Diameter|         |  SIP   |
                    |server 1|           | server |         |server 2|
                    +--------+           +--------+         +--------+
                         |                   |                   |
    1. SIP REGISTER      |                   |                   |
    -------------------->|     2. UAR        |                   |
                         |------------------>|                   |
                         |     3. UAA        |                   |
                         |<------------------|                   |
                         |         4. SIP REGISTER               |
                         |-------------------------------------->|
                         |                   |      5. MAR       |
                         |                   |<------------------|
                         |                   |      6. MAA       |
                         |                   |------------------>|
                         |         7. SIP 401 (Unauthorized)     |
    8. SIP 401 (Unauth.) |<--------------------------------------|
    <--------------------|                   |                   |
    9. SIP REGISTER      |                   |                   |
    -------------------->|     10. UAR       |                   |
                         |------------------>|                   |
                         |     11. UAA       |                   |
                         |<------------------|                   |
                         |         12. SIP REGISTER              |
                         |-------------------------------------->|
                         |                   |      13. SAR      |
                         |                   |<------------------|
                         |                   |      14. SAA      |
                         |                   |------------------>|
                         |         15. SIP 200 (OK)              |
    16. SIP 200 (OK)     |<--------------------------------------|
    <--------------------|                   |                   |
                         |                   |                   |

         Figure 3: Delegation of authentication to the SIP server

   Figure 3 shows an example where a SIP server is dynamically allocated
   to serve a SIP User Agent with the support of the Diameter server.
   This may be the case of certain architectures, such as that of the
   3rd Generation Partnership Project (3GPP) IP Multimedia Core Network
   Subsystem.

   A first SIP server receives a SIP REGISTER request (step 1) whose
   target is the home network domain.  In Figure 3, we assume that this
   SIP server is located at the edge of the administrative home domain.
   The Diameter client in this SIP server requests authorization from
   the Diameter server to proceed with the registration, by sending a



Garcia-Martin, et al.       Standards Track                    [Page 13]

RFC 4740                Diameter SIP Application           November 2006


   Diameter User-Authorization-Request (UAR) message (step 2).  The
   message includes, among other Attribute-Value-Pairs (AVPs), the SIP
   Address-Of-Record (AOR) that is included in the SIP REGISTER request.
   The Diameter server verifies the SIP AOR and, if it is a valid
   defined user in the home network, authorizes the registration to
   proceed.  The Diameter server responds with a Diameter
   User-Authorization-Answer (UAA) message (step 3), which informs the
   Diameter client/SIP server about the result of the user
   authorization.  In case of a successful authorization, the Diameter
   UAA message indicates the address of a local SIP server (SIP server 2
   in Figure 3) and/or a list of capabilities that SIP server 1 may use
   to select an appropriate SIP server 2.

   When the authorization is successful, SIP server 1 forwards the SIP
   REGISTER request (step 4) to the appropriate SIP server (SIP server
   2).  The Diameter client in SIP server 2 requests authentication
   parameters by sending a Diameter Multimedia-Auth-Request (MAR)
   message (step 5) to the Diameter server.  This request also makes the
   Diameter server aware of the SIP or SIPS URI of SIP server 2, so as
   to return subsequent requests of the same user to the same SIP server
   2.  The Diameter server responds with a Diameter
   Multimedia-Auth-Answer (MAA) message (step 6), which includes a nonce
   and all the rest of the parameters necessary for the designated
   authentication algorithm associated with the user.  Among others, the
   MAA message includes a Digest-HA1 AVP that contains H(A1) (as defined
   in RFC 2617 [RFC2617]), and that allows the Diameter client to
   calculate the expected response.  Then the Diameter client can
   compare this expected response with the response to the challenge
   sent from the SIP UA.  The absence of the Digest-HA1 AVP in MAA
   indicates that authentication and authorization take place in the
   Diameter server, as per the scenario described in Section 6.2.

   SIP server 2 creates a SIP 401 (Unauthorized) SIP response (step 7)
   based on the challenge included in the MAA message, including the
   authentication material needed by the SIP User Agent Client (UAC) to
   include the appropriate credentials.  SIP server 1 forwards the SIP
   response to the SIP UAC (step 8).

   The SIP server 1 receives the next SIP REGISTER request containing
   the user credentials (step 9).  Because SIP server 1 does not need to
   keep a state (and there is no guarantee that the SIP request arrives
   to the same SIP server 1), the Diameter client in SIP server 1
   contacts the Diameter server again by sending a Diameter UAR message
   (step 10) to determine the SIP server allocated to the user.  The
   Diameter server sends the SIP or SIPS URI of SIP server 2 in a
   Diameter UAA message (step 11).





Garcia-Martin, et al.       Standards Track                    [Page 14]

RFC 4740                Diameter SIP Application           November 2006


   SIP server 1 forwards the SIP REGISTER request to SIP server 2 (step
   12).  SIP server 2 validates the credentials by comparing the
   response supplied by the SIP UA with the expected response calculated
   by the SIP server 2 (based on the H(A1) received from the Diameter
   server).

   If the credentials are valid, SIP server 2 sends a Diameter
   Server-Assignment-Request (SAR) message (step 13) requesting the
   Diameter server to confirm the completion of the authentication
   procedure and to confirm the SIP or SIPS URI of the SIP server that
   is currently serving the user.  The Diameter SAR message also serves
   the purpose of requesting that the Diameter server send the user
   profile to the SIP server.  The Diameter server responds with a
   Diameter Server-Assignment-Answer (SAA) message (step 14).  If the
   Result-Code AVP value does not inform SIP Server 2 of an error, the
   SAA message can include zero or more SIP-User-Data AVPs containing
   the information that SIP server 2 needs in order to provide a service
   to the user.

   SIP server 2 generates a SIP 200 (OK) response (step 15), which is
   forwarded to SIP server 1 and eventually to the SIP UAC (step 16).

6.4.  SIP Server Requests Authentication and Authorization

   Figure 4 depicts a typical scenario where a stateless SIP proxy
   requests authentication information and authorization to a Diameter
   server, for the purpose of providing SIP routing services to a SIP
   User Agent.  The SIP proxy server may be configured as an outbound
   SIP proxy, so that all the requests initiated by the SIP UA traverse
   the SIP proxy.

   According to Figure 4, a SIP User Agent sends a SIP request to its
   outbound SIP proxy server.  In this case, the message is a SIP INVITE
   request (see step 1), but it could be any other SIP request.  We
   assume that this SIP request does not contain any credentials at this
   time.  The outbound SIP proxy server needs to authenticate and
   authorize the proxy services offered to the user.  The Diameter
   client in the SIP server sends a Multimedia-Auth-Request (MAR)
   message (step 2).  The Diameter server generates a nonce and sends a
   Multimedia-Auth-Answer (MAA) message (step 3) that includes the nonce
   and the rest of the data necessary for the SIP server to challenge
   the user, typically with HTTP Digest Authentication indicated in the
   MAA message.  This data enables the SIP server to create a SIP 407
   (Proxy Authentication Required) response (step 4) that contains a
   challenge.  The SIP UA creates a new INVITE request (step 5) that
   contains the credentials.  The Diameter client in the SIP server
   sends the credentials to the Diameter server in a new Diameter MAR
   message (step 6).  The Diameter server validates the credentials and



Garcia-Martin, et al.       Standards Track                    [Page 15]

RFC 4740                Diameter SIP Application           November 2006


   authorize the SIP transaction in a Diameter MAA message (step 7).
   The SIP server forwards the SIP INVITE request to its destination
   (step 8) as per regular SIP procedures.  Eventually, the session
   setup is confirmed with a SIP 200 (OK) response (step 9) that is
   forwarded to the SIP UA (step 10).  The session setup is complete.

                +--------+         +--------+
                |Diameter|         |  SIP   |
                | server |         | server |
                +--------+         +--------+
                    |                   |
                    |                   |
             1. SIP INVITE              |
    ----------------------------------->|
                    |      2. MAR       |
                    |<------------------|
                    |      3. MAA       |
                    |------------------>|
                    |                   |
             4. SIP 407 (Proxy          |
         Authentication Required)       |
    <-----------------------------------|
                    |                   |
             5. SIP INVITE              |
    ----------------------------------->|
                    |      6. MAR       |
                    |<------------------|
                    |      7. MAA       |
                    |------------------>| 8. SIP INVITE
                    |                   |---------------->
                    |                   | 9. SIP 200 (OK)
             10. SIP 200 (OK)           |<----------------
    <-----------------------------------|
                    |                   |

                Figure 4: SIP server requests authorization

6.5.  Locating the Recipient of the SIP Request

   Figure 5 shows the scenario where SIP server 1 may be configured as a
   SIP edge proxy server, processing SIP traffic at the edge of a
   network.  SIP server 1 receives a SIP INVITE request (step 1).  SIP
   server 1 needs to find the address of SIP server 2, which is serving
   the recipient of the SIP request.  The Diameter client in SIP server
   1 sends a Diameter Location-Info-Request (LIR) message (step 2) to
   the Diameter server.  The Diameter server responds with a Diameter
   Location-Info-Answer (LIA) message (step 3) that contains the SIP or




Garcia-Martin, et al.       Standards Track                    [Page 16]

RFC 4740                Diameter SIP Application           November 2006


   SIPS URI of SIP server 2.  SIP server 1 then forwards the SIP INVITE
   to SIP server 2 (step 4).  SIP server 2 eventually forwards the SIP
   INVITE to the appropriate UAS (step 5).

             +--------+         +--------+      +--------+
             |  SIP   |         |Diameter|      |  SIP   |
             |server 1|         | server |      |server 2|
             +--------+         +--------+      +--------+
                  |                 |                |
   1. SIP INVITE  |                 |                |
   -------------->|     2. LIR      |                |
                  |---------------->|                |
                  |     3. LIA      |                |
                  |<----------------|                |
                  |         4. SIP INVITE            |
                  |--------------------------------->|
                  |                 |                | 5. SIP INVITE
                  |                 |                |-------------->
                  |                 |                |
                  |                 |                |

            Figure 5: Locating the SIP server of the recipient

   Although the example shows the connection between a SIP INVITE
   request and the Diameter LIR message, any SIP request other than
   REGISTER (such as SUBSCRIBE, OPTIONS, etc.) would trigger the same
   Diameter message.  (A SIP REGISTER request will trigger a Diameter
   UAR message, as indicated in Figure 2 and Figure 3.)

   The scenario described in this section is also applicable in case an
   outbound SIP server is not interested in authenticating the user, but
   is required to locate a further SIP server to route the outbound SIP
   requests.  In this case, the outbound SIP server is mapped to SIP
   server 1 as shown in Figure 5.

6.6.  Update of the User Profile

   The Diameter SIP application provides a mechanism for a Diameter
   server to asynchronously download a user profile to a SIP server
   whenever there is an update of such user profile.  It must be noted
   that the Diameter server also attaches the user profile to the
   Diameter Server-Assignment-Answer (SAA) message.  This is valid for
   most of the daily situations; however, the administrator may decide
   to update or modify the user profile for a particular user, due to,
   e.g., new services made available to the user.  This may involve
   mechanisms outside the scope of this specification, such as human





Garcia-Martin, et al.       Standards Track                    [Page 17]

RFC 4740                Diameter SIP Application           November 2006


   intervention, in the Diameter server.  In this situation, the
   Diameter server is able to push the new user profile into the SIP
   server allocated to the user.

   The scenario is illustrated in Figure 6.  When the user profile
   changes, the Diameter server sends a Diameter Push-Profile-Request
   (PPR) message (step 1) to the Diameter client in the SIP server
   allocated to that user (SIP server 2 in the examples).  The Diameter
   PPR message contains one or more SIP-User-Data AVPs, a User-Name AVP
   and zero or more SIP-AOR AVPs.  The Diameter client in SIP server 2
   acknowledges the Diameter PPR message by sending a Diameter
   Push-Profile-Answer (PPA) message (step 2) to the Diameter server.

                   +--------+          +--------+
                   |Diameter|          |  SIP   |
                   | server |          |server 2|
                   +--------+          +--------+
                       |                   |
                       |     1. PPR        |
                       |------------------>|
                       |                   |
                       |     2. PPA        |
                       |<------------------|
                       |                   |

      Figure 6: Diameter server pushes an update of the user profile

6.7.  SIP Soft State Termination

   SIP can create soft states in SIP nodes based on events such as SIP
   registrations or SIP event subscriptions.  These states are
   periodically refreshed, and cease to exist if they are not refreshed.
   Additionally, an administrative action can be taken to terminate a
   SIP soft state, or the SIP UA can explicitly terminate a SIP soft
   state.

   The Diameter base protocol offers a mechanism to create and delete
   states in Diameter nodes.  These states are called Diameter user
   sessions.  The Diameter server decides whether to use a Diameter user
   session as a mechanism to map to a SIP soft state.  If the Diameter
   server decides to use Diameter user sessions, the termination of a
   Diameter user session implies the termination of the corresponding
   SIP soft state (e.g., registration, event subscription), and vice
   versa.  If the Diameter server does not use Diameter user sessions,
   this Diameter SIP application offers specific commands to manage the
   SIP soft states.  Implementations compliant with this specification
   MUST support both mechanisms of session management.




Garcia-Martin, et al.       Standards Track                    [Page 18]

RFC 4740                Diameter SIP Application           November 2006


   We provide support for both Diameter client- and Diameter
   server-initiated session termination.  Depending on whether Diameter
   sessions are used, termination of a SIP soft state can be achieved by
   one of the following methods:

   o  When the Diameter client (SIP proxy) wants to terminate the SIP
      soft state and Diameter user sessions are not maintained (i.e.,
      the Auth-Session-State AVP has been previously set to
      NO_STATE_MAINTAINED), the Diameter client MUST send a
      Server-Assignment-Request (SAR) message with the
      SIP-Server-Assignment-Type AVP (Section 9.4) set to any of the
      deregistration values:  TIMEOUT_DEREGISTRATION,
      USER_DEREGISTRATION, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME,
      USER_DEREGISTRATION_STORE_SERVER_NAME,
      ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA.

   o  When the Diameter client (SIP proxy) wants to terminate the SIP
      soft state and Diameter user sessions are maintained (i.e., the
      Auth-Session-State AVP has been previously set to
      STATE_MAINTAINED), the Diameter client MUST send a Session-
      Termination-Request (STR) message as per regular procedures
      according to RFC 3588 [RFC3588].

   o  When the Diameter server wants to terminate the SIP soft state and
      Diameter user sessions are not maintained (i.e., the
      Auth-Session-State AVP has been previously set to
      NO_STATE_MAINTAINED), the Diameter server MUST send a
      Registration-Termination-Request (RTR) message (see Section 8.9).

   o  When the Diameter server wants to terminate the SIP soft state and
      Diameter user sessions are maintained (i.e., the
      Auth-Session-State AVP has been previously set to
      STATE_MAINTAINED), the Diameter server MUST send an
      Abort-Session-Request (ASR) message as per regular procedures
      according to RFC 3588 [RFC3588].

6.8.  Diameter Server Discovery

   The basic architecture assumption of this document is that all the
   data related to a user is stored in a unique Diameter server.
   Contrary to general opinion, this does not create a single point of
   failure.  It is assumed that Diameter servers are configured in a
   redundant fashion in an attempt to mitigate the
   single-point-of-failure problem.

   In large networks, where the number of users may be significantly
   high, there might be a need to scale the number of Diameter servers.
   All the data associated with a user is still stored in one Diameter



Garcia-Martin, et al.       Standards Track                    [Page 19]

RFC 4740                Diameter SIP Application           November 2006


   server (typically, operating in a redundant configuration), but the
   data associated with different users may reside in different Diameter
   servers.

   Although this configuration scales well, it introduces a new problem,
   namely: given the user's SIP AOR as an input, how to determine which
   of various Diameter servers is storing the data for that particular
   SIP AOR.  We solve this problem with inspiration from the Diameter
   redirection mechanism specified in RFC 3588 [RFC3588].  We include in
   the architecture a new Diameter node that, for the purpose of this
   document, is known as Diameter Subscriber Locator (SL).  The Diameter
   SL contains a database or routing tables that map SIP AORs to
   Diameter server URIs.  A particular Diameter server URI points to the
   actual Diameter server that stores all the data related to a
   particular SIP AOR, and in consequence, to the user who owns the SIP
   AOR.  The Diameter SL acts in a similar way to a Diameter Redirect
   Agent, dispatching Diameter requests (e.g., providing the redirection
   URI in the answer).  The Diameter SL can redirect all the request
   pertaining to a user by setting the Redirect-Host-Usage AVP with a
   value ALL_USER, as specified in RFC 3588 [RFC3588].

   The Diameter SL can be replicated in different nodes along the
   network, for the purpose of building scalability and redundancy.  The
   database or routing tables have to be consistent across all these
   different Diameter SLs, so that equal Diameter requests will produce
   equal Diameter answers, no matter which Diameter SL processes the
   request.

           +--------+   +--------+  +--------+  +--------+
           |  SIP   |   |Diameter|  |Diameter|  |  SIP   |
           |server 1|   |SL red. |  |server 1|  |server 2|
           +--------+   +--------+  +--------+  +--------+
                |           |           |            |
   1. SIP INVITE|           |           |            |
   ------------>| 2. LIR    |           |            |
                |---------->|           |            |
                | 3. LIA    |           |            |
                |<----------|           |            |
                |       4. LIR          |            |
                |---------------------->|            |
                |       5. LIA          |            |
                |<----------------------|            |
                |         6. SIP INVITE |            |
                |----------------------------------->| 7. SIP INVITE
                |           |           |            | ------------->
                |           |           |            |

      Figure 7: Locating a Diameter server.  SL redirecting requests



Garcia-Martin, et al.       Standards Track                    [Page 20]

RFC 4740                Diameter SIP Application           November 2006


   Figure 7 shows an example of operation of a Diameter SL acting in
   redirect mode.  SIP server 1 receives an INVITE request (step 1)
   addressed (in the SIP Request-URI) to a user for which the Diameter
   client in SIP server 1 does not possess routing information.  In
   other words, the Diameter client in SIP server 1 does not know the
   URI of the Diameter server 1.  The Diameter client sends a Diameter
   LIR message (step 2) to any of the Diameter SLs configured in the
   network.  The address of those SLs is assumed to be pre-provisioned
   in the Diameter client.  The Diameter SL, based on the contents of
   the SIP-AOR AVP and its own routing tables, determines the Diameter
   server that stores the information allocated to such user.  Then it
   builds a Diameter LIA message (step 3) that includes a Result-Code
   AVP set to DIAMETER_REDIRECT_INDICATION and one Redirect-Host AVP,
   whose value is set to the URI of the Diameter server that stores the
   information related to such user.  Then the Diameter client in SIP
   server 1 builds a new LIR message (step 4) addressed to the Diameter
   server received in the Redirect-Host AVP.  The rest of the procedure
   is completed as described in previous sections.

7.  Advertising Application Support

   Diameter implementations conforming to this specification MUST
   advertise its support by including an Auth-Application-Id AVP in the
   Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer
   (CEA) commands, according to the Diameter base protocol, RFC 3588
   [RFC3588].  This Auth-Application-Id AVP MUST be set to the value of
   this Diameter SIP application (Section 13.1 indicates the actual
   value allocated by IANA).























Garcia-Martin, et al.       Standards Track                    [Page 21]

RFC 4740                Diameter SIP Application           November 2006


8.  Diameter SIP Application Command Codes

   All the Diameter implementations conforming to this specification
   MUST implement and support the list of Diameter commands listed in
   Table 1.

   +-------------------------------------+-------+------+--------------+
   | Command Name                        | Abbr. | Code | Reference    |
   +-------------------------------------+-------+------+--------------+
   | User-Authorization-Request          |  UAR  |  283 | Section 8.1  |
   | User-Authorization-Answer           |  UAA  |  283 | Section 8.2  |
   | Server-Assignment-Request           |  SAR  |  284 | Section 8.3  |
   | Server-Assignment-Answer            |  SAA  |  284 | Section 8.4  |
   | Location-Info-Request               |  LIR  |  285 | Section 8.5  |
   | Location-Info-Answer                |  LIA  |  285 | Section 8.6  |
   | Multimedia-Auth-Request             |  MAR  |  286 | Section 8.7  |
   | Multimedia-Auth-Answer              |  MAA  |  286 | Section 8.8  |
   | Registration-Termination-Request    |  RTR  |  287 | Section 8.9  |
   | Registration-Termination-Answer     |  RTA  |  287 | Section 8.10 |
   | Push-Profile-Request                |  PPR  |  288 | Section 8.11 |
   | Push-Profile-Answer                 |  PPA  |  288 | Section 8.12 |
   +-------------------------------------+-------+------+--------------+

                      Table 1: Defined command codes

   Sections defining commands contain the Message Format for that
   particular command.  The Message Formats included in this document
   are defined as per Section 3.2 of RFC 3588 [RFC3588].

8.1.  User-Authorization-Request (UAR) Command

   The User-Authorization-Request (UAR) is indicated by the Command-Code
   set to 283 and the Command Flags' 'R' bit set.  The Diameter client
   in a SIP server sends this command to the Diameter server to request
   authorization for the SIP User Agent to route a SIP REGISTER request.
   Because the SIP REGISTER request implicitly carries a permission to
   bind an AOR to a contact address, the Diameter client uses the
   Diameter UAR as a first authorization request towards the Diameter
   server to authorize the registration.  For instance, the Diameter
   server can verify that the AOR is a legitimate user of the realm.

   The Diameter client in the SIP server requests authorization for one
   of the possible values defined in the SIP-User-Authorization-Type AVP
   (Section 9.10).

   The user name used for authentication of the user is conveyed in a
   User-Name AVP (defined in the Diameter base protocol, RFC 3588
   [RFC3588]).  The location of the authentication user name in the SIP



Garcia-Martin, et al.       Standards Track                    [Page 22]

RFC 4740                Diameter SIP Application           November 2006


   REGISTER request varies depending on the authentication mechanism.
   When the authentication mechanism is HTTP Digest as defined in RFC
   2617 [RFC2617], the authentication user name is found in the
   "username" directive of the SIP Authorization header field value.
   This Diameter SIP application only provides support for HTTP Digest
   authentication in SIP; other authentication mechanisms are not
   currently supported.

   The SIP or SIPS URI to be registered is conveyed in the SIP-AOR AVP
   (Section 9.8).  Typically this SIP or SIPS URI is found in the To
   header field value of the SIP REGISTER request that triggered the
   Diameter UAR message.

   The SIP-Visited-Network-Id AVP indicates the network that is
   providing SIP services (e.g., SIP proxy functionality or any other
   kind of services) to the SIP User Agent.

   The Message Format of the UAR command is as follows:

       <UAR> ::= < Diameter Header: 283, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Visited-Network-Id ]
                 [ SIP-User-Authorization-Type ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.2.  User-Authorization-Answer (UAA) Command

   The User-Authorization-Answer (UAA) is indicated by the Command-Code
   set to 283 and the Command Flags' 'R' bit cleared.  The Diameter
   server sends this command in response to a previously received
   Diameter User-Authorization-Request (UAR) command.  The Diameter
   server indicates the result of the requested registration
   authorization.  Additionally, the Diameter server may indicate a
   collection of SIP capabilities that assists the Diameter client to
   select a SIP proxy to the AOR under registration.






Garcia-Martin, et al.       Standards Track                    [Page 23]

RFC 4740                Diameter SIP Application           November 2006


   In addition to the values already defined in RFC 3588 [RFC3588], the
   Result-Code AVP may contain one of the values defined in
   Section 10.1.

   Whenever the Diameter server fails to process the Diameter UAR
   message, it MUST stop processing and return the relevant error in the
   Diameter UAA message.  When there is success in the process, the
   Diameter server MUST set the code to DIAMETER_SUCCESS in the Diameter
   UAA message.

   If the Diameter server requires a User-Name AVP value to process the
   Diameter UAR request, but the Diameter UAR message did not contain a
   User-Name AVP value, the Diameter server MUST set the Result-Code AVP
   value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return
   it in a Diameter UAA message.  Upon reception of this Diameter UAA
   message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
   authentication by sending a SIP 401 (Unauthorized) or SIP 407 (Proxy
   Authentication Required) response back to the originator.

   When the authorization procedure succeeds, the Diameter server
   constructs a User-Authorization-Answer (UAA) message that MUST
   include (1) the address of the SIP server already assigned to the
   user name, (2) the capabilities needed by the SIP server (Diameter
   client) to select another SIP server for the user, or (3) a
   combination of the previous two options.

   If the Diameter server is already aware of a SIP server allocated to
   the user, the Diameter UAA message contains the address of that SIP
   server.

   The Diameter UAA message contains the capabilities required by a SIP
   server to trigger and execute services.  It is required that these
   capabilities are present in the Diameter UAA message due to the
   possibility that the Diameter client (in the SIP server) allocates a
   different SIP server to trigger and execute services for that
   particular user.

   If a User-Name AVP is present in the Diameter UAR message, then the
   Diameter server MUST verify the existence of the user in the realm,
   i.e., the User-Name AVP value is a valid user within that realm.  If
   the Diameter server does not recognize the user name received in the
   User-Name AVP, the Diameter server MUST build a Diameter User-
   Authorization-Answer (UAA) message and MUST set the Result-Code AVP
   to DIAMETER_ERROR_USER_UNKNOWN.






Garcia-Martin, et al.       Standards Track                    [Page 24]

RFC 4740                Diameter SIP Application           November 2006


   If a User-Name AVP is present in the Diameter UAR message, then the
   Diameter server MUST authorize that User-Name AVP value is able to
   register the SIP or SIPS URI included in the SIP-AOR AVP.  If this
   authorization fails, the Diameter server must set the Result-Code AVP
   to DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
   User-Authorization-Answer (UAA) message.

      Note: Correlation between User-Name and SIP-AOR AVP values is
      required in order to avoid registration of a SIP-AOR allocated to
      another user.

   If there is a SIP-Visited-Network-Id AVP in the Diameter UAR message,
   and the SIP-User-Authorization-Type AVP value received in the
   Diameter UAR message is set to REGISTRATION or REGISTRATION&
   CAPABILITIES, then the Diameter server SHOULD verify whether the user
   is allowed to roam into the network specified in the
   SIP-Visited-Network-Id AVP in the Diameter UAR message.  If the user
   is not allowed to roam into that network, the Diameter AAA server
   MUST set the Result-Code AVP value in the Diameter UAA message to
   DIAMETER_ERROR_ROAMING_NOT_ALLOWED.

   If the SIP-User-Authorization-Type AVP value received in the Diameter
   UAR message is set to REGISTRATION or REGISTRATION&CAPABILITIES, then
   the Diameter server SHOULD verify whether the SIP-AOR AVP value is
   authorized to register in the Home Realm.  Where the SIP AOR is not
   authorized to register in the Home Realm, the Diameter server MUST
   set the Result-Code AVP to DIAMETER_AUTHORIZATION_REJECTED and send
   it in a Diameter UAA message.

   When the SIP-User-Authorization-Type AVP is not present in the
   Diameter UAR message, or when it is present and its value is set to
   REGISTRATION, then:

   o  If the Diameter server is not aware of any previous registration
      of the user name (including registrations of other SIP AORs
      allocated to the same user name), then the Diameter server does
      not know of any SIP server allocated to the user.  In this case,
      the Diameter server MUST set the Result-Code AVP value to
      DIAMETER_FIRST_REGISTRATION in the Diameter UAA message, and the
      Diameter server SHOULD include the required SIP server
      capabilities in the SIP-Server-Capabilities AVP value in the
      Diameter UAA message.  The SIP-Server-Capabilities AVP assists the
      Diameter client (SIP server) to select an appropriate SIP server
      for the user, according to the required capabilities.

   o  In some cases, the Diameter server is aware of a previously
      assigned SIP server for the same or different SIP AORs allocated
      to the same user name.  In these cases, re-assignment of a new SIP



Garcia-Martin, et al.       Standards Track                    [Page 25]

RFC 4740                Diameter SIP Application           November 2006


      server may or may not be needed, depending on the capabilities of
      the SIP server.  The Diameter server MUST always include the
      allocated SIP server URI in the SIP-Server-URI AVP of the UAA
      message.  If the Diameter server does not return the SIP
      capabilities, the Diameter server MUST set the Result-Code AVP in
      the Diameter UAA message to DIAMETER_SUBSEQUENT_REGISTRATION.
      Otherwise (i.e., if the Diameter server includes a
      SIP-Server-Capabilities AVP), then the Diameter server MUST set
      the Result-Code AVP in the Diameter UAA message to
      DIAMETER_SERVER_SELECTION.  Then the Diameter client determines,
      based on the received information, whether it needs to select a
      new SIP server.

   When the SIP-User-Authorization-Type AVP value received in the
   Diameter UAR message is set to REGISTRATION&CAPABILITIES, then
   Diameter Server MUST return the list of capabilities in the
   SIP-Server-Capabilities AVP value of the Diameter UAA message, it
   MUST set the Result-Code to DIAMETER_SUCCESS, and it MUST NOT return
   a SIP-Server-URI AVP.  The SIP-Server-Capabilities AVP enables the
   SIP server (Diameter client) to select another appropriate SIP server
   for invoking and executing services for the user, depending on the
   required capabilities.  The Diameter server MAY leave the list of
   capabilities empty to indicate that any SIP server can be selected.

   When the SIP-User-Authorization-Type AVP value received in the
   Diameter UAR message is set to DEREGISTRATION, then:

   o  If the Diameter server is aware of a SIP server assigned to the
      SIP AOR under deregistration, the Diameter server MUST set the
      Result-Code AVP to DIAMETER_SUCCESS and MUST set the
      SIP-Server-URI AVP value to the known SIP server, and return them
      in the Diameter UAA message.

   o  If the Diameter server is not aware of a SIP server assigned to
      the SIP AOR under deregistration, then the Diameter server MUST
      set the Result-Code AVP in the Diameter UAA message to
      DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.

   The Message Format of the UAA command is as follows:

       <UAA> ::= < Diameter Header: 283, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ SIP-Server-URI ]



Garcia-Martin, et al.       Standards Track                    [Page 26]

RFC 4740                Diameter SIP Application           November 2006


                 [ SIP-Server-Capabilities ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.3.  Server-Assignment-Request (SAR) Command

   The Server-Assignment-Request (SAR) command is indicated by the
   Command-Code set to 284 and the Command Flags' 'R' bit set.  The
   Diameter client in a SIP server sends this command to the Diameter
   server to indicate the completion of the authentication process and
   to request that the Diameter server store the URI of the SIP server
   that is currently serving the user.  The main functions of the
   Diameter SAR command are to inform the Diameter server of the URI of
   the SIP server allocated to the user, and to store or clear it from
   the Diameter server.  Additionally, the Diameter client can request
   to download the user profile or part of it.

   During the registration procedure, a SIP server becomes assigned to
   the user.  The Diameter client in the assigned SIP server MUST
   include its own URI in the SIP-Server-URI AVP of the
   Server-Assignment-Request (SAR) Diameter message and send it to the
   Diameter server.  The Diameter server then becomes aware of the
   allocation of the SIP server to the user name and the server's URI.

   The Diameter client in the SIP server MAY send a Diameter SAR message
   because of other reasons.  These reasons are identified in the
   SIP-Server-Assignment-Type AVP (Section 9.4) value.  For instance, a
   Diameter client in a SIP server may contact the Diameter server to
   request deregistration of a user, to inform the Diameter server of an
   authentication failure, or just to download the user profile.  For a
   complete description of all the SIP-Server-Assignment-Type AVP
   values, see Section 9.4.

   Typically the reception of a SIP REGISTER request in a SIP server
   will trigger the Diameter client in the SIP server to send the
   Diameter SAR message.  However, if a SIP server is receiving other
   SIP request, such as INVITE, and the SIP server does not have the
   user profile, the Diameter client in the SIP server may send the
   Diameter SAR message to the Diameter server in order to download the
   user profile and make the Diameter server aware of the SIP server
   assigned to the user.




Garcia-Martin, et al.       Standards Track                    [Page 27]

RFC 4740                Diameter SIP Application           November 2006


   The user profile is an important piece of information that dictates
   the behavior of the SIP server when triggering or providing services
   for the user.  Typically the user profile is divided into:

   o  Services to be rendered to the user when the user is registered
      and initiates a SIP request.

   o  Services to be rendered to the user when the user is registered
      and a SIP request destined to that user arrives to the SIP proxy.

   o  Services to be rendered to the user when the user is not
      registered and a SIP request destined to that user arrives to the
      SIP proxy.

   The SIP-Server-Assignment-Type AVP indicates the reason why the
   Diameter client (SIP server) contacted the Diameter server.  If the
   Diameter client sets the SIP-Server-Assignment-Type AVP value to
   REGISTRATION, RE_REGISTRATION, UNREGISTERED_USER, NO_ASSIGNMENT,
   AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, the Diameter client
   MUST include exactly one SIP-AOR AVP in the Diameter SAR message.

   The SAR message MAY contain zero or more SIP-Supported-User-Data-Type
   AVPs.  Each of them contains a type of user data understood by the
   SIP server.  This allows the Diameter client to provide an indication
   to the Diameter server of the different format of user data
   understood by the SIP server.  The Diameter server uses this
   information to select one or more SIP-User-Data AVPs that will be
   included in the SAA message.

   The Message Format of the SAR command is as follows:

       <SAR> ::= < Diameter Header: 284, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-Server-Assignment-Type }
                 { SIP-User-Data-Already-Available }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
               * [ SIP-Supported-User-Data-Type ]
               * [ SIP-AOR ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]



Garcia-Martin, et al.       Standards Track                    [Page 28]

RFC 4740                Diameter SIP Application           November 2006


8.4.  Server-Assignment-Answer (SAA) Command

   The Server-Assignment-Answer (SAA) is indicated by the Command-Code
   set to 284 and the Command Flags' 'R' bit cleared.  The Diameter
   server sends this command in response to a previously received
   Diameter Server-Assignment-Request (SAR) command.  The response may
   include the user profile or part of it, if requested.

   In addition to the values already defined in RFC 3588 [RFC3588], the
   Result-Code AVP may contain one of the values defined in
   Section 10.1.

   The Result-Code AVP value in the Diameter SAA message may indicate a
   success or an error in the execution of the Diameter SAR command.  If
   Result-Code AVP value in the Diameter SAA message does not contain an
   error code, the SAA message MAY include one or more SIP-User-Data
   AVPs that typically contain the profile of the user, indicating
   services that the SIP server can provide to that user.

   The Diameter server MAY include one or more
   SIP-Supported-User-Data-Type AVPs, each one identifying a type of
   user data format supported in the Diameter server.  If there is not a
   common supported user data type between the Diameter client and the
   Diameter server, the Diameter server SHOULD declare its list of
   supported user data types by including one or more
   SIP-Supported-User-Data-Type AVPs in a Diameter SAA message.  This
   indication is merely for debugging reasons, since there is not a
   fallback mechanism that allows the Diameter client to retrieve the
   profile in a supported format.

   If the Diameter server requires a User-Name AVP value to process the
   Diameter SAR request, but the Diameter SAR message did not contain a
   User-Name AVP value, the Diameter server MUST set the Result-Code AVP
   value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return
   it in a Diameter SAA message.  Upon reception of this Diameter SAA
   message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
   authentication by generating a SIP 401 (Unauthorized) or SIP 407
   (Proxy Authentication Required) response back to the originator.

   If the User-Name AVP is included in the Diameter SAR message, upon
   reception of the Diameter SAR message, the Diameter server MUST
   verify the existence of the user in the realm, i.e., the User-Name
   AVP value is a valid user within that realm.  If the Diameter server
   does not recognize the user name received in the User-Name AVP, the
   Diameter server MUST build a Diameter Server-Assignment-Answer (SAA)
   message and MUST set the Result-Code AVP to
   DIAMETER_ERROR_USER_UNKNOWN.



Garcia-Martin, et al.       Standards Track                    [Page 29]

RFC 4740                Diameter SIP Application           November 2006


   Then the Diameter server MUST authorize that User-Name AVP value is a
   valid authentication name for the SIP or SIPS URI included in the
   SIP-AOR AVP of the Diameter SAR message.  If this authorization
   fails, the Diameter server must set the Result-Code AVP to
   DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
   Server-Assignment-Answer (SAA) message.

   After successful execution of the Diameter SAR command, the Diameter
   server MUST clear the "authentication pending" flag and SHOULD move
   the temporarily stored SIP server URI to permanent storage.

   The actions of the Diameter server upon reception of the Diameter SAR
   message depend on the value of the SIP-Server-Assignment-Type:

   o  If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
      message is set to REGISTRATION or RE_REGISTRATION, the Diameter
      server SHOULD verify that there is only one SIP-AOR AVP.
      Otherwise, the Diameter server MUST answer with a Diameter SAA
      message with the Result-Code AVP value set to
      DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and MUST NOT include any
      SIP-User-Data AVP.  If there is only one SIP-AOR AVP and if the
      SIP-User-Data-Already-Available AVP value is set to
      USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
      one or more user profile data with the SIP or SIPS URI (SIP-AOR
      AVP) and all other SIP identities associated with that AVP in the
      SIP-User-Data AVP value of the Diameter SAA message.  On selecting
      the type of user data, the Diameter server SHOULD take into
      account the supported formats at the SIP server
      (SIP-Supported-User-Data-Type AVP in the SAR message) and the
      local policy.  Additionally, the Diameter server MUST set the
      Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
      message.  The Diameter server considers the SIP AOR authenticated
      and registered.

   o  If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
      message is set to UNREGISTERED_USER, then the Diameter server MUST
      store the SIP server address included in the SIP-Server-URI AVP
      value.  The Diameter server will return the SIP server address in
      Diameter Location-Info-Answer (LIA) messages.  If the
      SIP-User-Data-Already-Available AVP value is set to
      USER_DATA_NOT_AVAILABLE, then the Diameter server SHOULD include
      one or more user profile data associated with the SIP or SIPS URI
      (SIP-AOR AVP) and associated identities in the SIP-User-Data AVP
      value of the Diameter SAA message.  On selecting the type of user
      data, the Diameter server SHOULD take into account the supported
      formats at the SIP server (SIP-Supported-User-Data-Type AVP in the
      SAR message) and the local policy.  The Diameter server MUST set
      the Result-Code AVP value to DIAMETER_SUCCESS.  The Diameter



Garcia-Martin, et al.       Standards Track                    [Page 30]

RFC 4740                Diameter SIP Application           November 2006


      server considers the SIP AOR UNREGISTERED, but with a SIP server
      allocated to trigger and provide services for unregistered users.
      Note that in case of UNREGISTERED_USER (SIP-Server-Assignment-Type
      AVP), the Diameter server MUST verify that there is only one
      SIP-AOR AVP.  Otherwise, the Diameter server MUST answer the
      Diameter SAR message with a Diameter SAA message, and it MUST set
      the Result-Code AVP value to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES
      and MUST NOT include any SIP-User-Data AVP.
      If the User-Name AVP was not present in the Diameter SAR message
      and the SIP-AOR is not known for the Diameter server, the Diameter
      server MUST NOT include a User-Name AVP in the Diameter SAA
      message and MUST set the Result-Code AVP value to
      DIAMETER_ERROR_USER_UNKNOWN.

   o  If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
      message is set to TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION,
      DEREGISTRATION_TOO_MUCH_DATA, or ADMINISTRATIVE_DEREGISTRATION,
      the Diameter server MUST clear the SIP server address associated
      with all SIP AORs indicated in each of the SIP-AOR AVP values
      included in the Diameter SAR message.  The Diameter server
      considers all of these SIP AORs as not registered.  The Diameter
      server MUST set the Result-Code AVP value to DIAMETER_SUCCESS in
      the Diameter SAA message.

   o  If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
      message is set to TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or
      USER_DEREGISTRATION_STORE_SERVER_NAME, the Diameter server MAY
      keep the SIP server address associated with the SIP AORs included
      in the SIP-AOR AVP values of the Diameter SAR message, even though
      the SIP AORs become unregistered.  This feature allows a SIP
      server to request that the Diameter server remain an assigned SIP
      server for those SIP AORs (SIP-AOR AVP values) allocated to the
      same user name, and avoid SIP server assignment.  The Diameter
      server MUST consider all these SIP AORs as not registered.  If the
      Diameter server honors the request of the Diameter client (SIP
      server) to remain as an allocated SIP server, then the Diameter
      server MUST keep the SIP server assigned to those SIP AORs
      allocated to the username and MUST set the Result-Code AVP value
      to DIAMETER_SUCCESS in the Diameter SAA message.  Otherwise, when
      the Diameter server does not honor the request of the Diameter
      client (SIP server) to remain as an allocated SIP server, the
      Diameter server MUST clear the SIP server name assigned to those
      SIP AORs and it MUST set the Result-Code AVP value to
      DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED in the Diameter SAA
      message.






Garcia-Martin, et al.       Standards Track                    [Page 31]

RFC 4740                Diameter SIP Application           November 2006


   o  If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
      message is set to NO_ASSIGNMENT, the Diameter server SHOULD first
      verify that the SIP-Server-URI AVP value in the Diameter SAR
      message is the same URI as the one assigned to the SIP-AOR AVP
      value.  If they differ, then the Diameter server MUST set the
      Result-Code AVP value to DIAMETER_UNABLE_TO_COMPLY in the Diameter
      SAA message.  Otherwise, if the SIP-User-Data-Already-Available
      AVP value is set to USER_DATA_NOT_AVAILABLE, then the Diameter
      server SHOULD include the user profile data with the SIP or SIPS
      URI (SIP-AOR AVP) and all other SIP identities associated with
      that AVP in the SIP-User-Data AVP value of the Diameter SAA
      message.  On selecting the type of user data, the Diameter server
      SHOULD take into account the supported formats at the SIP server
      (SIP-Supported-User-Data-Type AVP in the SAR message) and the
      local policy.

   o  If the SIP-Server-Assignment-Type AVP value in the Diameter SAR
      message is set to AUTHENTICATION_FAILURE or
      AUTHENTICATION_TIMEOUT, the Diameter server MUST verify that there
      is exactly one SIP-AOR AVP in the Diameter SAR message.  If the
      number of occurrences of the SIP-AOR AVP is not exactly one, the
      Diameter server MUST set the Result-Code AVP value to
      DIAMETER_AVP_OCCURS_TOO_MANY_TIMES in the Diameter SAA message,
      and SHOULD not take further actions.  If there is exactly one
      SIP-AOR AVP in the Diameter SAR message, the Diameter server MUST
      clear the address of the SIP server assigned to the SIP AOR
      allocated to the user name, and the Diameter server MUST set the
      Result-Code AVP value to DIAMETER_SUCCESS in the Diameter SAA
      message.  The Diameter server MUST consider the SIP AOR as not
      registered.

   The Message Format of the SAA command is as follows:

       <SAA> ::= < Diameter Header: 284, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
               * [ SIP-User-Data ]
                 [ SIP-Accounting-Information ]
               * [ SIP-Supported-User-Data-Type ]
                 [ User-Name ]
                 [ Auth-Grace-Period ]
                 [ Authorization-Lifetime ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]



Garcia-Martin, et al.       Standards Track                    [Page 32]

RFC 4740                Diameter SIP Application           November 2006


                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.5.  Location-Info-Request (LIR) Command

   The Location-Info-Request (LIR) is indicated by the Command-Code set
   to 285 and the Command Flags' 'R' bit set.  The Diameter client in a
   SIP server sends this command to the Diameter server to request
   routing information, e.g., the URI of the SIP server assigned to the
   SIP-AOR AVP value allocated to the users.

   The Message Format of the LIR command is as follows:

       <LIR> ::= < Diameter Header: 285, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 [ Destination-Host ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.6.  Location-Info-Answer (LIA) Command

   The Location-Info-Answer (LIA) is indicated by the Command-Code set
   to 285 and the Command Flags' 'R' bit cleared.  The Diameter server
   sends this command in response to a previously received Diameter
   Location-Info-Request (LIR) command.

   In addition to the values already defined in RFC 3588 [RFC3588], the
   Result-Code AVP may contain one of the values defined in
   Section 10.1.  When the Diameter server finds an error in processing
   the Diameter LIR message, the Diameter server MUST stop the process
   of the message and answer with a Diameter LIA message that includes
   the appropriate error code in the Result-Code AVP value.  When there
   is no error, the Diameter server MUST set the Result-Code AVP value
   to DIAMETER_SUCCESS in the Diameter LIA message.

   One of the errors that the Diameter server may find is that the
   SIP-AOR AVP value is not a valid user in the realm.  In such cases,
   the Diameter server MUST set the Result-Code AVP value to
   DIAMETER_ERROR_USER_UNKNOWN and return it in a Diameter LIA message.



Garcia-Martin, et al.       Standards Track                    [Page 33]

RFC 4740                Diameter SIP Application           November 2006


   If the Diameter server cannot process the Diameter LIR command, e.g.,
   due to a database error, the Diameter server MUST set the Result-Code
   AVP value to DIAMETER_UNABLE_TO_COMPLY and return it in a Diameter
   LIA message.  The Diameter server MUST NOT include any SIP-Server-URI
   or SIP-Server-Capabilities AVP in the Diameter LIA message.

   The Diameter server may or may not be aware of a SIP server assigned
   to the SIP-AOR AVP value included in the Diameter LIR message.  If
   the Diameter server is aware of a SIP server allocated to that
   particular user, the Diameter server MUST include the URI of such SIP
   server in the SIP-Server-URI AVP and return it in a Diameter LIA
   message.  This is typically the situation when the user is either
   registered, or unregistered but a SIP server is still assigned to the
   user.

   When the Diameter server is not aware of a SIP server allocated to
   the user (typically the case when the user unregistered), the
   Result-Code AVP value in the Diameter LIA message depends on whether
   the Diameter server is aware that the user has services defined for
   unregistered users:

   o  Those users who have services defined for unregistered users may
      require the allocation of a SIP server to trigger and perhaps
      execute those services.  Therefore, when the Diameter server is
      not aware of an assigned SIP server, but the user has services
      defined for unregistered users, the Diameter server MUST set the
      Result-Code AVP value to DIAMETER_UNREGISTERED_SERVICE and return
      it in a Diameter LIA message.  The Diameter server MAY also
      include a SIP-Server-Capabilities AVP to facilitate the SIP server
      (Diameter client) with the selection of an appropriate SIP server
      with the required capabilities.  Absence of the SIP-Server-
      Capabilities AVP indicates to the SIP server (Diameter client)
      that any SIP server is suitable to be allocated for the user.

   o  Those users who do not have service defined for unregistered users
      do not require further processing.  The Diameter server MUST set
      the Result-Code AVP value to
      DIAMETER_ERROR_IDENTITY_NOT_REGISTERED and return it to the
      Diameter client in a Diameter LIA message.  The SIP server
      (Diameter client) may return the appropriate SIP response (e.g.,
      480 (Temporarily unavailable)) to the original SIP request.

   The Message Format of the LIA command is as follows:

       <LIA> ::= < Diameter Header: 285, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }



Garcia-Martin, et al.       Standards Track                    [Page 34]

RFC 4740                Diameter SIP Application           November 2006


                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ SIP-Server-URI ]
                 [ SIP-Server-Capabilities ]
                 [ Auth-Grace-Period ]
                 [ Authorization-Lifetime ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.7.  Multimedia-Auth-Request (MAR) Command

   The Multimedia-Auth-Request (MAR) command is indicated by the
   Command-Code set to 286 and the Command Flags' 'R' bit set.  The
   Diameter client in a SIP server sends this command to the Diameter
   server to request that the Diameter server authenticate and authorize
   a user attempt to use some SIP service (in this context, SIP service
   can be something as simple as a SIP subscription or using the proxy
   services for a SIP request).

   The MAR command may also register the SIP server's own URI to the
   Diameter server, so that future LIR/LIA messages can return this URI.
   If the SIP server is acting as a SIP registrar (see examples in
   Sections 6.2 and 6.3), its Diameter client MUST include a SIP-
   Server-URI AVP in the MAR command.  In any other cases (see example
   in Section 6.4), its Diameter client MUST NOT include a SIP-Server-
   URI AVP in the MAR command.

   The SIP-Method AVP MUST include the SIP method name of the SIP
   request that triggered this Diameter MAR message.  The Diameter
   server can use this AVP to authorize some SIP requests depending on
   the method.

   The Diameter MAR message MUST include a SIP-AOR AVP.  The SIP-AOR AVP
   indicates the target of the SIP request.  The value of the AVP is
   extracted from different places in SIP request, depending on the
   semantics of the SIP request.  For SIP REGISTER messages the SIP-AOR
   AVP value indicates the intended public user identity under
   registration, and it is the SIP or SIPS URI populated in the To
   header field value (addr-spec as per RFC 3261 [RFC3261]) of the SIP
   REGISTER request.  For other types of SIP requests, such as INVITE,
   SUBSCRIBE, MESSAGE, etc., the SIP-AOR AVP value indicates the
   intended destination of the request.  This is typically populated in
   the Request-URI of the SIP request.  Extracting the SIP-AOR AVP value



Garcia-Martin, et al.       Standards Track                    [Page 35]

RFC 4740                Diameter SIP Application           November 2006


   from the proper SIP header field is the Diameter client's
   responsibility.  Extensions to SIP (new SIP methods or new semantics)
   may require the SIP-AOR to be extracted from other parts of the
   request.

   If the SIP request includes some sort of authentication information,
   the Diameter client MUST include the user name, extracted from the
   authentication information of the SIP request, in the User-Name AVP
   value.

   The Message Format of the MAR command is as follows:

       <MAR> ::= < Diameter Header: 286, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 { SIP-Method }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
                 [ SIP-Number-Auth-Items ]
                 [ SIP-Auth-Data-Item ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.8.  Multimedia-Auth-Answer (MAA) Command

   The Multimedia-Auth-Answer (MAA) is indicated by the Command-Code set
   to 286 and the Command Flags' 'R' bit cleared.  The Diameter server
   sends this command in response to a previously received Diameter
   Multimedia-Auth-Request (MAR) command.

   In addition to the values already defined in RFC 3588 [RFC3588], the
   Result-Code AVP may contain one of the values defined in
   Section 10.1.

   If the Diameter server requires a User-Name AVP value to process the
   Diameter MAR request, but the Diameter MAR message did not contain a
   User-Name AVP value, the Diameter server MUST set the Result-Code AVP
   value to DIAMETER_USER_NAME_REQUIRED (see Section 10.1.2) and return
   it in a Diameter MAA message.  The Diameter server MAY include a
   SIP-Number-Auth-Items AVP and one or more SIP-Auth-Data-Item AVPs
   with authentication information (e.g., a challenge).  Upon reception



Garcia-Martin, et al.       Standards Track                    [Page 36]

RFC 4740                Diameter SIP Application           November 2006


   of this Diameter MAA message with the Result-Code AVP value set to
   DIAMETER_USER_NAME_REQUIRED, the SIP server typically requests
   authentication by generating a SIP 401 (Unauthorized) or SIP 407
   (Proxy Authentication Required) response back to the originator.

   If the User-Name AVP is present in the Diameter MAR message, the
   Diameter server MUST verify the existence of the user in the realm,
   i.e., the User-Name AVP value is a valid user within that realm.  If
   the Diameter server does not recognize the user name received in the
   User-Name AVP, the Diameter server MUST build a Diameter
   Multimedia-Auth-Answer (MAA) message and MUST set the Result-Code AVP
   to DIAMETER_ERROR_USER_UNKNOWN.

   If the SIP-Methods AVP value of the Diameter MAR message is set to
   REGISTER and a User-Name AVP is present, then the Diameter server
   MUST authorize that User-Name AVP value is able to use the URI
   included in the SIP-AOR AVP.  If this authorization fails, the
   Diameter server must set the Result-Code AVP to
   DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
   Multimedia-Auth-Answer (MAA) message.

      Note: Correlation between User-Name and SIP-AOR AVP values is only
      required for SIP REGISTER request, to prevent a user from
      registering a SIP-AOR allocated to another user.  In other types
      of SIP requests (e.g., INVITE), the SIP-AOR indicates the intended
      destination of the request, rather than the originator of it.

   The Diameter server MUST verify whether the authentication scheme
   (SIP-Authentication-Scheme AVP value) indicated in the grouped
   SIP-Auth-Data-Item AVP is supported or not.  If that authentication
   scheme is not supported, then the Diameter server MUST set the
   Result-Code AVP to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED and send
   it in a Diameter Multimedia-Auth-Answer (MAA) message.

   If the SIP-Number-Auth-Items AVP is present in the Diameter MAR
   message, it indicates the number of authentication data items that
   the Diameter client is requesting.  It is RECOMMENDED that the
   Diameter server, when building the Diameter MAA message, includes a
   number of SIP-Auth-Data-Item AVPs that are a subset of the
   authentication data items requested by the Diameter client in the
   SIP-Number-Auth-Items AVP value of the Diameter MAR message.

   If the SIP-Server-URI AVP is present in the Diameter MAR message,
   then the Diameter server MUST compare the stored SIP server (assigned
   to the user) with the SIP-Server-URI AVP value (received in the
   Diameter MAR message).  If they don't match, the Diameter server MUST
   temporarily save the newly received SIP server assigned to the user,
   and MUST set an "authentication pending" flag for the user.  If they



Garcia-Martin, et al.       Standards Track                    [Page 37]

RFC 4740                Diameter SIP Application           November 2006


   match, the Diameter server shall clear the "authentication pending"
   flag for the user.

   In any other situation, if there is a success in processing the
   Diameter MAR command and the Diameter server stored the
   SIP-Server-URI, the Diameter server MUST set the Result-Code AVP
   value to DIAMETER_SUCCESS and return it in a Diameter MAA message.

   If there is a success in processing the Diameter MAR command, but the
   Diameter server does not store the SIP-Server-URI because the AVP was
   not present in the Diameter MAR command, then the Diameter server
   MUST set the Result-Code AVP value to either:

   1.  DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED, if the Diameter
       server is sending authentication credentials to create a
       challenge.

   2.  DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED, if the Diameter server
       successfully authenticated the user and authorized the SIP server
       to proceed with the SIP request.

   Otherwise, the Diameter server MUST set the Result-Code AVP value to
   DIAMETER_UNABLE_TO_COMPLY, and it MUST NOT include any
   SIP-Auth-Data-Item AVP.

   The Message Format of the MAA command is as follows:

       <MAA> ::= < Diameter Header: 286, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
                 [ SIP-AOR ]
                 [ SIP-Number-Auth-Items ]
               * [ SIP-Auth-Data-Item ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]





Garcia-Martin, et al.       Standards Track                    [Page 38]

RFC 4740                Diameter SIP Application           November 2006


8.9.  Registration-Termination-Request (RTR) Command

   The Registration-Termination-Request (RTR) command is indicated by
   the Command-Code set to 287 and the Command Flags' 'R' bit set.  The
   Diameter server sends this command to the Diameter client in a SIP
   server to indicate to the SIP server that one or more SIP AORs have
   to be deregistered.  The command allows an operator to
   administratively cancel the registration of a user from a centralized
   Diameter server.

   The Diameter server has the capability to initiate the deregistration
   of a user and inform the SIP server by means of the Diameter RTR
   command.  The Diameter server can decide whether only one SIP AOR is
   going to be deregistered, a list of SIP AORs, or all the SIP AORs
   allocated to the user.

   The absence of a SIP-AOR AVP in the Diameter RTR message indicates
   that all the SIP AORs allocated to the user identified by the
   User-Name AVP are being deregistered.

   The Diameter server MUST include a SIP-Deregistration-Reason AVP
   value to indicate the reason for the deregistration.

   The Message Format of the RTR command is as follows:

       <RTR> ::= < Diameter Header: 287, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Host }
                 { SIP-Deregistration-Reason }
                 [ Destination-Realm ]
                 [ User-Name ]
               * [ SIP-AOR ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.10.  Registration-Termination-Answer (RTA) Command

   The Registration-Termination-Answer (RTA) is indicated by the
   Command-Code set to 287 and the Command Flags' 'R' bit cleared.  The
   Diameter client sends this command in response to a previously
   received Diameter Registration-Termination-Request (RTR) command.





Garcia-Martin, et al.       Standards Track                    [Page 39]

RFC 4740                Diameter SIP Application           November 2006


   In addition to the values already defined in RFC 3588 [RFC3588], the
   Result-Code AVP may contain one of the values defined in
   Section 10.1.

   If the SIP server (Diameter client) requires a User-Name AVP value to
   process the Diameter RTR request, but the Diameter RTR message did
   not contain a User-Name AVP value, the Diameter client MUST set the
   Result-Code AVP value to DIAMETER_USER_NAME_REQUIRED (see Section
   10.1.2) and return it in a Diameter RTA message.

   The SIP server (Diameter client) applies the administrative
   deregistration to each of the URIs included in each of the SIP-AOR
   AVP values, or, if there is no SIP-AOR AVP present in the Diameter
   RTR request, to all the URIs allocated to the User-Name AVP value.

   The value of the SIP-Deregistration-Reason AVP in the Diameter RTR
   command has an effect on the actions performed at the SIP server
   (Diameter client):

   o  If the value is set to PERMANENT_TERMINATION, then the user has
      terminated his/her registration to the realm.  If informing the
      interested parties (e.g., subscribers to the "reg" event
      [RFC3680]) about the administrative deregistration is supported
      through SIP procedures, the SIP server (Diameter client) will do
      so.  The Diameter Client in the SIP Server SHOULD NOT request a
      new user registration.  The SIP server clears the registration
      state of the deregistered AORs.

   o  If the value is set to NEW_SIP_SERVER_ASSIGNED, the Diameter
      server informs the SIP server (Diameter client) that a new SIP
      server has been allocated to the user, due to some reason.  The
      SIP server, if supported through SIP procedures, will inform the
      interested parties (e.g., subscribers to the "reg" event
      [RFC3680]) about the administrative deregistration at this SIP
      server.  The Diameter client in the SIP server SHOULD NOT request
      a new user registration.  The SIP server clears the registration
      state of the deregistered SIP AORs.

   o  If the value is set to SIP_SERVER_CHANGE, the Diameter server
      informs the SIP server (Diameter client) that a new SIP server has
      to be allocated to the user, e.g., due to user's capabilities
      requiring a new SIP server, or not enough resources in the current
      SIP server.  If informing the interested parties about the
      administrative deregistration is supported through SIP procedures
      (e.g., subscriptions to the "reg" event [RFC3680]), the SIP server
      will do so.  The Diameter client in the SIP Server SHOULD NOT
      request a new user registration.  The SIP server clears the
      registration state of the deregistered SIP AORs.



Garcia-Martin, et al.       Standards Track                    [Page 40]

RFC 4740                Diameter SIP Application           November 2006


   o  If the value is set to REMOVE_SIP_SERVER, the Diameter server
      informs the SIP server (Diameter client) that the SIP server will
      no longer be bound in the Diameter server with that user.  The SIP
      server can delete all data related to the user.

   The Message Format of the RTA command is as follows:

       <RTA> ::= < Diameter Header: 287, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.11.  Push-Profile-Request (PPR) Command

   The Push-Profile-Request (PPR) command is indicated by the
   Command-Code set to 288 and the Command Flags' 'R' bit set.  The
   Diameter server sends this command to the Diameter client in a SIP
   server to update either the user profile of an already registered
   user in that SIP server or the SIP accounting information.  This
   allows an operator to modify the data of a user profile or the
   accounting information and push it to the SIP server where the user
   is registered.

   Each user has a user profile associated with him/her and other
   accounting information.  The profile or the accounting information
   may change with time, e.g., due to addition of new services to the
   user.  When the user profile or the accounting information changes,
   the Diameter server sends a Diameter Push-Profile-Request (PPR)
   command to the Diameter client in a SIP server, in order to start
   applying those new services.

   A PPR command MAY contain a SIP-Accounting-Information AVP that
   updates the addresses of the accounting servers.  Changes in the
   addresses of the accounting servers take effect immediately.  The
   Diameter client SHOULD close any existing accounting session with the
   existing server and start providing accounting information to the
   newly acquired accounting server.



Garcia-Martin, et al.       Standards Track                    [Page 41]

RFC 4740                Diameter SIP Application           November 2006


   A PPR command MAY contain zero or more SIP-User-Data AVP values
   containing the new user profile.  On selecting the type of user data,
   the Diameter server SHOULD take into account the supported formats at
   the SIP server (SIP-Supported-User-Data-Type AVP sent in a previous
   SAR message) and the local policy.

   The User-Name AVP indicates the user to whom the profile is
   applicable.

   The Message Format of the PPR command is as follows:

       <PPR> ::= < Diameter Header: 288, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { User-Name }
               * [ SIP-User-Data ]
                 [ SIP-Accounting-Information ]
                 [ Destination-Host ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

8.12.  Push-Profile-Answer (PPA) Command

   The Push-Profile-Answer (PPA) is indicated by the Command-Code set to
   288 and the Command Flags' 'R' bit cleared.  The Diameter client
   sends this command in response to a previously received Diameter
   Push-Profile-Request (PPR) command.

   In addition to the values already defined in RFC 3588 [RFC3588], the
   Result-Code AVP may contain one of the values defined in
   Section 10.1.

   If there is no error when processing the received Diameter PPR
   message, the SIP server (Diameter client) MUST download the received
   user profile from the SIP-User-Data AVP values in the Diameter PPR
   message and store it associated with the user specified in the
   User-Name AVP value.

   If the SIP server does not recognize or does not support some of the
   data transferred in the SIP-User-Data AVP values, the Diameter client
   in the SIP server MUST return a Diameter PPA message that includes a



Garcia-Martin, et al.       Standards Track                    [Page 42]

RFC 4740                Diameter SIP Application           November 2006


   Result-Code AVP set to the value
   DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.

   If the SIP server (Diameter client) receives a Diameter PPR message
   with a User-Name AVP that is unknown, the Diameter client MUST set
   the Result-Code AVP value to DIAMETER_ERROR_USER_UNKNOWN and MUST
   return it to the Diameter server in a Diameter PPA message.

   If the SIP server (Diameter client) receives in the
   SIP-User-Data-Content AVP value (of the grouped SIP-User-Data AVP)
   more data than it can accept, it MUST set the Result-Code AVP value
   to DIAMETER_ERROR_TOO_MUCH_DATA and MUST return it to the Diameter
   server in a Diameter PPA message.  The SIP server MUST NOT override
   the existing user profile with the one received in the PPR message.

   If the Diameter server receives the Result-Code AVP value set to
   DIAMETER_ERROR_TOO_MUCH_DATA in a Diameter PPA message, it SHOULD
   force a new re-registration of the user by sending to the Diameter
   client a Diameter Registration-Termination-Request (RTR) with the
   SIP-Deregistration-Reason AVP value set to SIP_SERVER_CHANGE.  This
   will force a re-registration of the user and will trigger a selection
   of a new SIP server.

   If the Diameter client is not able to honor the command, for any
   other reason, it MUST set the Result-Code AVP value to
   DIAMETER_UNABLE_TO_COMPLY and it MUST return it in a Diameter PPA
   message.

   The Message Format of the PPA command is as follows:

       <PPA> ::= < Diameter Header: 288, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]








Garcia-Martin, et al.       Standards Track                    [Page 43]

RFC 4740                Diameter SIP Application           November 2006


9.  Diameter SIP Application AVPs

   This section defines new AVPs used in this Diameter SIP application.
   Applications compliant with this specification MUST implement these
   AVPs.

   Table 2 lists the new AVPs defined in this Diameter SIP application.
   The following abbreviations are used in the Data-Type column:

   o  DURI: DiameterURI
   o  E: Enumerated
   o  G: Grouped
   o  OS: OctetString
   o  UTF8S: UTF8String
   o  U32: Unsigned32




































Garcia-Martin, et al.       Standards Track                    [Page 44]

RFC 4740                Diameter SIP Application           November 2006


   +-----------------------------------+------+----------------+-------+
   | Attribute Name                    | AVP  | Reference      | Data- |
   |                                   | Code |                | Type  |
   +-----------------------------------+------+----------------+-------+
   | SIP-Accounting-Information        |  368 | Section 9.1    | G     |
   | SIP-Accounting-Server-URI         |  369 | Section 9.1.1  | DURI  |
   | SIP-Credit-Control-Server-URI     |  370 | Section 9.1.2  | DURI  |
   | SIP-Server-URI                    |  371 | Section 9.2    | UTF8S |
   | SIP-Server-Capabilities           |  372 | Section 9.3    | G     |
   | SIP-Mandatory-Capability          |  373 | Section 9.3.1  | U32   |
   | SIP-Optional-Capability           |  374 | Section 9.3.2  | U32   |
   | SIP-Server-Assignment-Type        |  375 | Section 9.4    | E     |
   | SIP-Auth-Data-Item                |  376 | Section 9.5    | G     |
   | SIP-Authentication-Scheme         |  377 | Section 9.5.1  | E     |
   | SIP-Item-Number                   |  378 | Section 9.5.2  | U32   |
   | SIP-Authenticate                  |  379 | Section 9.5.3  | G     |
   | SIP-Authorization                 |  380 | Section 9.5.4  | G     |
   | SIP-Authentication-Info           |  381 | Section 9.5.5  | G     |
   | SIP-Number-Auth-Items             |  382 | Section 9.6    | U32   |
   | SIP-Deregistration-Reason         |  383 | Section 9.7    | G     |
   | SIP-Reason-Code                   |  384 | Section 9.7.1  | E     |
   | SIP-Reason-Info                   |  385 | Section 9.7.2  | UTF8S |
   | SIP-Visited-Network-Id            |  386 | Section 9.9    | UTF8S |
   | SIP-User-Authorization-Type       |  387 | Section 9.10   | E     |
   | SIP-Supported-User-Data-Type      |  388 | Section 9.11   | UTF8S |
   | SIP-User-Data                     |  389 | Section 9.12   | G     |
   | SIP-User-Data-Type                |  390 | Section 9.12.1 | UTF8S |
   | SIP-User-Data-Contents            |  391 | Section 9.12.2 | OS    |
   | SIP-User-Data-Already-Available   |  392 | Section 9.13   | E     |
   | SIP-Method                        |  393 | Section 9.14   | UTF8S |
   +-----------------------------------+------+----------------+-------+

                           Table 2: Defined AVPs

   Table 3 expands the table of AVPs included in Section 4.5 of RFC 3588
   [RFC3588].  The table indicates the Diameter AVPs defined in this
   Diameter SIP Application, their possible flag values, and whether the
   AVP may be encrypted.  The acronyms 'M', 'P', and 'V' refer to AVP
   flags whose semantics are described in RFC 3588 [RFC3588].  The value
   of the 'Encr' column is also described in RFC 3588 [RFC3588].











Garcia-Martin, et al.       Standards Track                    [Page 45]

RFC 4740                Diameter SIP Application           November 2006


   +----------------------------------+------+-----+-----+------+------+
   | Attribute Name                   | MUST | MAY | SHD | MUST | Encr |
   |                                  |      |     | NOT |  NOT |      |
   +----------------------------------+------+-----+-----+------+------+
   | SIP-Accounting-Information       |   M  |  P  |     |   V  |   N  |
   | SIP-Accounting-Server-URI        |   M  |  P  |     |   V  |   N  |
   | SIP-Credit-Control-Server-URI    |   M  |  P  |     |   V  |   N  |
   | SIP-Server-URI                   |   M  |  P  |     |   V  |   N  |
   | SIP-Server-Capabilities          |   M  |  P  |     |   V  |   N  |
   | SIP-Mandatory-Capability         |   M  |  P  |     |   V  |   N  |
   | SIP-Optional-Capability          |   M  |  P  |     |   V  |   N  |
   | SIP-Server-Assignment-Type       |   M  |  P  |     |   V  |   N  |
   | SIP-Auth-Data-Item               |   M  |  P  |     |   V  |   N  |
   | SIP-Authentication-Scheme        |   M  |  P  |     |   V  |   N  |
   | SIP-Item-Number                  |   M  |  P  |     |   V  |   N  |
   | SIP-Authenticate                 |   M  |  P  |     |   V  |   N  |
   | SIP-Authorization                |   M  |  P  |     |   V  |   N  |
   | SIP-Authentication-Info          |   M  |  P  |     |   V  |   N  |
   | SIP-Number-Auth-Items            |   M  |  P  |     |   V  |   N  |
   | SIP-Deregistration-Reason        |   M  |  P  |     |   V  |   N  |
   | SIP-Reason-Code                  |   M  |  P  |     |   V  |   N  |
   | SIP-Reason-Info                  |   M  |  P  |     |   V  |   N  |
   | SIP-Visited-Network-Id           |   M  |  P  |     |   V  |   N  |
   | SIP-User-Authorization-Type      |   M  |  P  |     |   V  |   N  |
   | SIP-Supported-User-Data-Type     |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data                    |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Type               |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Contents           |   M  |  P  |     |   V  |   N  |
   | SIP-User-Data-Already-Available  |   M  |  P  |     |   V  |   N  |
   | SIP-Method                       |   M  |  P  |     |   V  |   N  |
   +----------------------------------+------+-----+-----+------+------+

                  Table 3: Summary of the new AVPs flags

9.1.  SIP-Accounting-Information AVP

   The SIP-Accounting-Information (AVP Code 368) is of type Grouped, and
   contains the Diameter addresses of those nodes that are able to
   collect accounting information.

   The SIP-Accounting-Information AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Accounting-Information ::= < AVP Header: 368 >
                                   * [ SIP-Accounting-Server-URI ]
                                   * [ SIP-Credit-Control-Server-URI ]
                                   * [ AVP]




Garcia-Martin, et al.       Standards Track                    [Page 46]

RFC 4740                Diameter SIP Application           November 2006


9.1.1.  SIP-Accounting-Server-URI AVP

   The SIP-Accounting-Server-URI AVP (AVP Code 369) is of type
   DiameterURI.  This AVP contains the address of a Diameter server that
   is able to receive SIP-session-related accounting information.

9.1.2.  SIP-Credit-Control-Server-URI AVP

   The SIP-Credit-Control-Server-URI AVP (AVP Code 370) is of type
   DiameterURI.  This AVP contains the address of a Diameter server that
   is able to authorize real-time credit control usage.  The Diameter
   Credit-Control Application [RFC4006] may be used for this purpose.

9.2.  SIP-Server-URI AVP

   The SIP-Server-URI AVP (AVP Code 371) is of type UTF8String.  This
   AVP contains a SIP or SIPS URI (as defined in RFC 3261 [RFC3261])
   that identifies a SIP server.

9.3.  SIP-Server-Capabilities AVP

   The SIP-Server-Capabilities AVP (AVP Code 372) is of type Grouped.
   The Diameter indicates in this AVP the requirements for a particular
   SIP capability, so that the Diameter client (SIP server) is able to
   select another appropriate SIP server to serve the user.

   The SIP-Server-Capabilities AVP allows a Diameter client (SIP server)
   to select another SIP server for triggering or executing services to
   the user.  A user may have enabled some services that require the
   implementation of certain capabilities in the SIP server that
   triggers or executes those services.  For example, the SIP server
   that triggers or executes services to this user may need to implement
   SIP servlets [JSR-000116], Call Processing Language (CPL) [RFC3880],
   or any other kind of capability.  Or perhaps that user belongs to a
   premium users group that has a certain stringent quality-of-service
   agreement that requires a fast SIP server.  The capabilities required
   or recommended to a given user are conveyed in the
   SIP-Server-Capabilities AVP.  When it receives them, the Diameter
   client (SIP server) that does the SIP server selection needs to have
   the means to find out available SIP servers that meet the required or
   optional capabilities.  Such means are outside the scope of this
   specification.

   Note that the SIP-Server-Capabilities AVP assists the Diameter client
   (SIP server) to produce a subset of all the available SIP servers to
   be allocated to the user in the Home Realm; this is the subset that
   conforms the requirements of capabilities on a per-user basis.
   Typically this subset will be formed of more than a single SIP



Garcia-Martin, et al.       Standards Track                    [Page 47]

RFC 4740                Diameter SIP Application           November 2006


   server, so once the subset of those SIP servers is identified, it is
   possible that several instances of these SIP servers exist, in which
   case the Diameter client (SIP server) should choose one particular
   SIP server to execute and trigger services to this user.  It is
   expected that at this point the SIP server (Diameter client) will
   follow the procedures of RFC 3263 [RFC3263] to allocate one SIP
   server to the user.

   The SIP-Server-Capabilities AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Server-Capabilities ::= < AVP Header: 372 >
                                * [ SIP-Mandatory-Capability ]
                                * [ SIP-Optional-Capability ]
                                * [ SIP-Server-URI ]
                                * [ AVP ]

9.3.1.  SIP-Mandatory-Capability AVP

   The SIP-Mandatory-Capability AVP (AVP Code 373) is of type
   Unsigned32.  The value represents a certain capability (or set of
   capabilities) that have to be fulfilled by the SIP server allocated
   to the user.

   The semantics of the different values are not standardized, as it is
   a matter of the administrative network to allocate its own semantics
   within its own network.  Each value has to represent a single
   capability within the administrative network.

9.3.2.  SIP-Optional-Capability AVP

   The SIP-Optional-Capability AVP (AVP Code 374) is of type Unsigned32.
   The value represents a certain capability (or set of capabilities)
   that, optionally, may be fulfilled by the SIP server allocated to the
   user.

   The semantics of the different values are not standardized, as it is
   a matter of the administrative network to allocate its own semantics
   within its own network.  Each value has to represent a single
   capability within the administrative network.

9.4.  SIP-Server-Assignment-Type AVP

   The SIP-Server-Assignment-Type AVP (AVP Code 375) is of type
   Enumerated and indicates the type of server update being performed in
   a Diameter Server-Assignment-Request (SAR) operation.  The following
   values are defined:




Garcia-Martin, et al.       Standards Track                    [Page 48]

RFC 4740                Diameter SIP Application           November 2006


   o  NO_ASSIGNMENT (0)
      The Diameter client uses this value to request the user profile of
      a SIP AOR, without affecting the registration state of that
      identity.

   o  REGISTRATION (1)
      First SIP registration of a SIP AOR.

   o  RE_REGISTRATION (2)
      Subsequent SIP registration of a SIP AOR.

   o  UNREGISTERED_USER (3)
      The SIP server has received a SIP request (e.g., SIP INVITE)
      addressed for a SIP AOR that is not registered.

   o  TIMEOUT_DEREGISTRATION (4)
      The SIP registration timer of an identity has expired.

   o  USER_DEREGISTRATION (5)
      The SIP server has received a request to deregister a SIP AOR.

   o  TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6)
      The SIP registration timer of an identity has expired.  The SIP
      server keeps the user data stored and requests the Diameter server
      to store the SIP server address.

   o  USER_DEREGISTRATION_STORE_SERVER_NAME (7)
      The SIP server has received a user-initiated deregistration
      request.  The SIP server keeps the user data stored and requests
      the Diameter server to store the SIP server address.

   o  ADMINISTRATIVE_DEREGISTRATION (8)
      The SIP server, due to administrative reasons, has deregistered a
      SIP AOR.

   o  AUTHENTICATION_FAILURE (9)
      The authentication of a user has failed.

   o  AUTHENTICATION_TIMEOUT (10)
      The authentication timer has expired.

   o  DEREGISTRATION_TOO_MUCH_DATA (11)
      The SIP server has requested user profile information from the
      Diameter server and has received a volume of data higher than it
      can accept.






Garcia-Martin, et al.       Standards Track                    [Page 49]

RFC 4740                Diameter SIP Application           November 2006


9.5.  SIP-Auth-Data-Item AVP

   The SIP-Auth-Data-Item (AVP Code 376) is of type Grouped and contains
   the authentication and/or authorization information pertaining to a
   user.

   When the Diameter server uses the grouped SIP-Auth-Data-Item AVP to
   include a SIP-Authenticate AVP, the Diameter server MUST send a
   maximum of one authentication data item (e.g., in case the SIP
   request contained several credentials).  Section 11 contains a
   detailed discussion and normative text of the case when a SIP request
   contains several credentials.

   The SIP-Auth-Data-Item AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Auth-Data-Item ::= < AVP Header: 376 >
                             { SIP-Authentication-Scheme }
                             [ SIP-Item-Number ]
                             [ SIP-Authenticate ]
                             [ SIP-Authorization ]
                             [ SIP-Authentication-Info ]
                           * [ AVP ]

9.5.1.  SIP-Authentication-Scheme AVP

   The SIP-Authentication-Scheme AVP (AVP Code 377) is of type
   Enumerated and indicates the authentication scheme used in the
   authentication of SIP services.  RFC 2617 identifies this value as an
   "auth-scheme" (see Section 1.2 of RFC 2617 [RFC2617]).  The only
   currently defined value is:

   o  DIGEST (0) to indicate HTTP Digest authentication as specified in
      RFC 2617 [RFC2617] Section 3.2.1.  Derivative work is also
      considered Digest authentication scheme, as long as the
      "auth-scheme" is identified as Digest in the SIP headers carrying
      the HTTP authentication.  This includes, e.g., the HTTP Digest
      authentication using AKA [RFC3310].

   Each HTTP Digest directive (parameter) is transported in a
   corresponding AVP, whose name follows the pattern Digest-*.  The
   Digest-* AVPs are RADIUS attributes imported from the RADIUS
   Extension for Digest Authentication [RFC4590] namespace, allowing a
   smooth transition between RADIUS and Diameter applications supporting
   SIP.  The Diameter SIP application goes a step further by grouping
   the Digest-* AVPs into the SIP-Authenticate, SIP-Authorization, and





Garcia-Martin, et al.       Standards Track                    [Page 50]

RFC 4740                Diameter SIP Application           November 2006


   SIP-Authentication-Info grouped AVPs that correspond to the SIP WWW-
   Authenticate/Proxy-Authentication, Authorization/Proxy-Authorization,
   and Authentication-Info headers fields, respectively.

      Note: Due to the fact that HTTP Digest authentication [RFC2617] is
      the only mandatory authentication mechanism in SIP, this memo only
      provides support for HTTP Digest authentication and derivative
      work such as HTTP Digest authentication using AKA [RFC3310].
      Extensions to this memo can register new values and new AVPs to
      provide support for other authentication schemes or extensions to
      HTTP Digest authentication.

      Note: Although RFC 2617 [RFC2617] defines the Basic and Digest
      schemes for authenticating HTTP requests, RFC 3261 [RFC3261] only
      imports HTTP Digest as a mechanism to provide authentication in
      SIP.

   Due to syntactic requirements, HTTP Digest authentication has to
   escape quote characters in contents of HTTP Digest directives.  When
   translating directives into Digest-* AVPs, the Diameter client or
   server removes the surrounding quotes where present, as required by
   the syntax of the Digest-* attributes defined in the "RADIUS
   Extension for Digest Authentication" [RFC4590].

9.5.2.  SIP-Item-Number AVP

   The SIP-Item-Number (AVP Code 378) is of type Unsigned32 and is
   included in a SIP-Auth-Data-Item grouped AVP in circumstances where
   there are multiple occurrences of SIP-Auth-Data-Item AVPs and the
   order of processing is relevant.  The AVP indicates the order in
   which the Grouped SIP-Auth-Data-Item should be processed.  Lower
   values of the SIP-Item-Number AVP indicate that the whole
   SIP-Auth-Data-Item SHOULD be processed before other
   SIP-Auth-Data-Item AVPs that contain higher values in the
   SIP-Item-Number AVP.

9.5.3.  SIP-Authenticate AVP

   The SIP-Authenticate AVP (AVP Code 379) is of type Grouped and
   contains a reconstruction of either the SIP WWW-Authenticate or
   Proxy-Authentication header fields specified in RFC 2617 [RFC2617]
   for the HTTP Digest authentication scheme.  Additionally, the AVP may
   include a Digest-HA1 AVP that contains H(A1) (as defined in RFC 2617
   [RFC2617]).  H(A1) allows the Diameter client to create an expected
   response and compare it with the Digest response received from the
   SIP UA.





Garcia-Martin, et al.       Standards Track                    [Page 51]

RFC 4740                Diameter SIP Application           November 2006


   The SIP-Authenticate AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Authenticate ::= < AVP Header: 379 >
                           { Digest-Realm }
                           { Digest-Nonce }
                           [ Digest-Domain ]
                           [ Digest-Opaque ]
                           [ Digest-Stale ]
                           [ Digest-Algorithm ]
                           [ Digest-QoP ]
                           [ Digest-HA1]
                         * [ Digest-Auth-Param ]
                         * [ AVP ]

9.5.4.  SIP-Authorization AVP

   The SIP-Authorization AVP (AVP Code 380) is of type Grouped and
   contains a reconstruction of either the SIP Authorization or
   Proxy-Authorization header fields specified in RFC 2617 [RFC2617] for
   the HTTP Digest authentication scheme.

   The SIP-Authorization AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Authorization ::= < AVP Header: 380 >
                            { Digest-Username }
                            { Digest-Realm }
                            { Digest-Nonce }
                            { Digest-URI }
                            { Digest-Response }
                            [ Digest-Algorithm ]
                            [ Digest-CNonce ]
                            [ Digest-Opaque ]
                            [ Digest-QoP ]
                            [ Digest-Nonce-Count ]
                            [ Digest-Method]
                            [ Digest-Entity-Body-Hash ]
                          * [ Digest-Auth-Param ]
                          * [ AVP ]

9.5.5.  SIP-Authentication-Info AVP

   The SIP-Authentication-Info AVP (AVP Code 381) is of type Grouped and
   contains a reconstruction of the SIP Authentication-Info header
   specified in RFC 2617 [RFC2617] for the HTTP Digest authentication
   scheme.




Garcia-Martin, et al.       Standards Track                    [Page 52]

RFC 4740                Diameter SIP Application           November 2006


   The SIP-Authentication-Info AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Authentication-Info ::= < AVP Header: 381 >
                                  [ Digest-Nextnonce ]
                                  [ Digest-QoP ]
                                  [ Digest-Response-Auth ]
                                  [ Digest-CNonce ]
                                  [ Digest-Nonce-Count ]
                                * [ AVP ]

   Note that, in some cases, the Digest-Response-Auth AVP cannot be
   calculated at the Diameter server, but has to be calculated at the
   Diameter client (SIP server).  For example, if the value of the
   quality of protection (qop) parameter in Digest is set to "auth-int",
   then the response-digest (rspauth parameter value in Digest) is
   calculated with the hash of the body of the SIP response, which is
   not available at the Diameter server.  In this case, the Diameter
   client (SIP server) must calculate the response-digest once the body
   of the SIP response is calculated.

   Therefore, a value of "auth-int" in the Digest-QoP AVP of the
   SIP-Authentication-Info AVP indicates that the Diameter client (SIP
   server) MUST compute the Digest "rspauth" parameter value at the
   Diameter client (SIP server).

9.5.6.  Digest AVPs

   The following AVPs are RADIUS attributes defined in the RADIUS
   Extension for Digest Authentication [RFC4590] and imported by this
   specification: Digest-AKA-Auts, Digest-Algorithm, Digest-Auth-Param,
   Digest-CNonce, Digest-Domain, Digest-Entity-Body-Hash, Digest-HA1,
   Digest-Method, Digest-Nextnonce, Digest-Nonce, Digest-Nonce-Count,
   Digest-Opaque, Digest-QoP, Digest-Realm, Digest-Response,
   Digest-Response-Auth, Digest-URI, Digest-Username, and Digest-Stale.

9.5.6.1.  Considerations about Digest-HA1 AVP

   The Digest-HA1 AVP contains the value, pre-calculated at the Diameter
   server, of H(A1) as defined in RFC 2617 [RFC2617].  The Diameter
   client can use H(A1) to calculate the expected Digest response,
   according to this challenge.  If the SIP UA is in possession of the
   credentials, the calculated expected response and the response sent
   from the SIP UA will match.  The Diameter server MAY include this AVP
   to enable and assist the SIP server in authenticating the SIP UA.

   This scenario is not applicable when the Diameter server is
   configured to use a session MD5 (MD5-sess) algorithm, because the



Garcia-Martin, et al.       Standards Track                    [Page 53]

RFC 4740                Diameter SIP Application           November 2006


   Diameter server requires the client nonce to compute the H(A1) before
   sending it to the Diameter client, and the client nonce might not be
   available when the computation of H(A1) is done.  Therefore, if the
   final authentication is delegated to the Diameter client, it is
   RECOMMENDED to configure the Diameter server to use algorithms
   different than MD5-sess in HTTP Digest.

   It is up to the Diameter server to include a Digest-HA1 AVP.  The
   Diameter server calculates the Digest H(A1) with the username,
   password, and realm (and nonce and cnonce, if applicable) as inputs,
   and places the result in the Digest-HA1 AVP value.  For more details
   of the A1 computation, see RFC 2617 [RFC2617] Section 3.2.2.2.  The
   Diameter client can calculate the Digest expected response with H(A1)
   as input, as described in RFC 2617 [RFC2617] Section 3.2.2.

   Section 11 provides further normative details about the usage of the
   Digest-HA1 AVP.

9.5.6.2.  Considerations about Digest-Entity-Body-Hash AVP

   The Digest-Entity-Body-Hash AVP contains a hash of the entity body
   contained in the SIP message.  This hash is required by HTTP Digest
   with quality of protection set to "auth-int".  Diameter clients MUST
   use this AVP to transport the hash of the entity body when HTTP
   Digest is the authentication mechanism and the Diameter server
   requires verification of the integrity of the entity body (e.g., qop
   parameter set to "auth-int").

   The clarifications described in Section 22.4 of RFC 3261 [RFC3261]
   about the hash of empty entity bodies apply to the
   Digest-Entity-Body-Hash AVP.

9.5.6.3.  Considerations about Digest-Auth-Param AVP

   The Digest-Auth-Param AVP is the mechanism whereby the Diameter
   client and Diameter server can exchange possible extension parameters
   contained in Digest headers that are either not understood by the
   Diameter client or for which there are no corresponding stand-alone
   AVPs.  Unlike the previously listed Digest-* AVPs, the
   Digest-Auth-Param contains not only the value, but also the parameter
   name, since it is unknown to the Diameter client.  The Diameter node
   MUST insert one Digest parameter/value combination per AVP value.  If
   the Digest header contains several unknown parameters, then the
   Diameter implementation MUST repeat this AVP and each instance MUST
   contain one different unknown Digest parameter/value combination.
   This AVP corresponds to the "auth-param" parameter defined in Section
   3.2.1 of RFC 2617 [RFC2617].




Garcia-Martin, et al.       Standards Track                    [Page 54]

RFC 4740                Diameter SIP Application           November 2006


   Example: Assume that the Diameter server wants the SIP server to send
   a "foo" parameter with the value set to "bar", so that the SIP server
   sends that combination in a SIP WWW-Authenticate header field.  The
   Diameter server builds a grouped SIP-Authenticate AVP that contains a
   Digest-Auth-Param whose value is set to foo="bar".  Then the SIP
   server creates the WWW-Authenticate header field with all the digest
   parameters (received in Digest-* AVPs) and adds the foo="bar"
   parameter to that header field.

9.6.  SIP-Number-Auth-Items AVP

   The SIP-Number-Auth-Items AVP (AVP Code 382) is of type Unsigned32
   and indicates the number of authentication and/or authorization
   credentials that the Diameter server included in a Diameter message.

   When the AVP is present in a request, it indicates the number of
   SIP-Auth-Data-Items the Diameter client is requesting.  This can be
   used, for instance, when the SIP server is requesting several
   pre-calculated authentication credentials.  In the answer message,
   the SIP-Number-Auth-Items AVP indicates the actual number of items
   that the Diameter server included.

9.7.  SIP-Deregistration-Reason AVP

   The SIP-Deregistration-Reason AVP (AVP Code 383) is of type Grouped
   and indicates the reason for a deregistration operation.

   The SIP-Deregistration-Reason AVP is defined as follows (per the
   grouped-avp-def of RFC 3588 [RFC3588]):

      SIP-Deregistration-Reason ::= < AVP Header: 383 >
                                    { SIP-Reason-Code }
                                    [ SIP-Reason-Info ]
                                  * [ AVP ]

9.7.1.  SIP-Reason-Code AVP

   The SIP-Reason-Code AVP (AVP Code 384) is of type Enumerated and
   defines the reason for the network initiated deregistration.  The
   following values are defined:

   o  PERMANENT_TERMINATION (0)
   o  NEW_SIP_SERVER_ASSIGNED (1)
   o  SIP_SERVER_CHANGE (2)
   o  REMOVE_SIP_SERVER (3)






Garcia-Martin, et al.       Standards Track                    [Page 55]

RFC 4740                Diameter SIP Application           November 2006


9.7.2.  SIP-Reason-Info AVP

   The SIP-Reason-Info AVP (AVP Code 385) is of type UTF8String and
   contains textual information that can be rendered to the user, about
   the reason for a deregistration.

9.8.  SIP-AOR AVP

   The SIP-AOR AVP is a RADIUS attribute imported from the RADIUS
   Extension for Digest Authentication [RFC4590] namespace, allowing a
   smooth transition between RADIUS and Diameter applications supporting
   SIP.  The SIP-AOR AVP carries the URI of the intended user related to
   the SIP request (whose location in SIP may vary depending on the
   actual SIP request and whether the SIP server is acting on Diameter
   due to a SIP-originated or terminating requests).

   The Diameter client (SIP server) uses the value found in a SIP
   Request-URI or a header field value of the SIP request to construct
   the SIP-AOR AVP.  The selection of a Request-URI or a particular
   header field to create the value of the SIP-AOR AVP depends on the
   semantics of the SIP message and whether the SIP server is acting for
   originating or terminating requests.  For instance, when the SIP
   server receives an INVITE request addressed to the served user (e.g.,
   the SIP server is receiving a terminating SIP request), it maps the
   SIP Request-URI of the SIP request to this AVP.  However, when the
   SIP server receives an INVITE request originated by the served user,
   it can map either the P-Asserted-Identity or the From header field
   values to this AVP.  If the SIP server is acting as a SIP registrar,
   then it maps the To header field of the REGISTER request to the
   SIP-AOR AVP.

9.9.  SIP-Visited-Network-Id AVP

   The SIP-Visited-Network-Id AVP (AVP Code 386) is of type UTF8String.
   This AVP contains an identifier that helps the home network identify
   the visited network (e.g., the visited network domain name), in order
   to authorize roaming to that visited network.

9.10.  SIP-User-Authorization-Type AVP

   The SIP-User-Authorization-Type AVP (AVP Code 387) is of type
   Enumerated and indicates the type of user authorization being
   performed in a User Authorization operation, i.e., the Diameter
   User-Authorization-Request (UAR) command.  The following values are
   defined:






Garcia-Martin, et al.       Standards Track                    [Page 56]

RFC 4740                Diameter SIP Application           November 2006


   o  REGISTRATION (0)
      This value is used for initial registration or re-registration.
      This is the default value.

   o  DEREGISTRATION (1)
      This value is used for deregistration.

   o  REGISTRATION_AND_CAPABILITIES (2)
      This value is used for initial registration or re-registration
      when the SIP server explicitly requests the Diameter server to get
      capability information.  This capability information helps the SIP
      server to allocate another SIP server to serve the user.

9.11.  SIP-Supported-User-Data-Type AVP

   The SIP-Supported-User-Data-Type AVP (AVP Code 388) is of type
   UTF8String and contains a string that identifies the type of
   supported user data (user profile, see SIP-User-Data AVP
   (Section 9.12)) supported in the node.  The AVP can be repeated, if
   the SIP server supports several user data types.  In case of
   repetition, the Diameter client should order the different instances
   of this AVP according to its preferences.

   When the Diameter client inserts this AVP in a SAR message, it allows
   the Diameter client to provide an indication to the Diameter server
   of the types of user data supported by the SIP server.  The Diameter
   server, upon inspection of these AVPs, will return a suitable
   SIP-User-Data AVP (Section 9.12) of the type indicated in the
   SIP-User-Data-Type AVP (Section 9.12.1).

9.12.  SIP-User-Data AVP

   The SIP-User-Data AVP (AVP Code 389) is of type Grouped.  This AVP
   allows the Diameter server to transport user-specific data, such as a
   user profile, to the SIP server (in the Diameter client).  The
   Diameter server selects a type of user data that is understood by the
   SIP server in the Diameter client, and has been indicated in a
   SIP-Supported-User-Data-Type AVP.  In case the Diameter client
   indicated support for several types of user data, the Diameter server
   SHOULD choose the first type supported by the client.

   The SIP-User-Data grouped AVP contains a SIP-User-Data-Type AVP that
   indicates the type of user data included in the
   SIP-User-Data-Contents-AVP.

   The SIP-User-Data AVP is defined as follows (per the grouped-avp-def
   of RFC 3588 [RFC3588]):




Garcia-Martin, et al.       Standards Track                    [Page 57]

RFC 4740                Diameter SIP Application           November 2006


      SIP-User-Data ::= < AVP Header: 389 >
                        { SIP-User-Data-Type }
                        { SIP-User-Data-Contents }
                      * [ AVP ]

9.12.1.  SIP-User-Data-Type AVP

   The SIP-User-Data AVP (AVP Code 390) is of type UTF8String and
   contains a string that identifies the type of user data included in
   the SIP-User-Data AVP (Section 9.12).

   This document does not specify a convention to characterize the type
   of user data contained in the SIP-User-Data AVP (Section 9.12).  It
   is believed that in most cases this feature will be used in
   environments controlled by a network administrator who can configure
   both the client and server to assign the same value type at the
   client and server.  It is also RECOMMENDED that organizations
   developing their own profile of SIP-User-Data AVP (Section 9.12)
   allocate a type based on their canonical DNS name.  For instance,
   organization "example.com" can define several types of SIP-User-Data
   and allocate the types "type1.dsa.example.com",
   "type2.dsa.example.com", and so on.  This convention will avoid a
   clash in the allocation of types of SIP-User-Data AVP (Section 9.12).

9.12.2.  SIP-User-Data-Contents AVP

   The SIP-User-Data-Contents AVP (AVP Code 391) is of type OctetString.
   The Diameter peers do not need to understand the value of this AVP.

   The AVP contains the user profile data required for a SIP server to
   give service to the user.

9.13.  SIP-User-Data-Already-Available AVP

   The SIP-User-Data-Already-Available AVP (AVP Code 392) is of type
   Enumerated and gives an indication to the Diameter server about
   whether the Diameter client (SIP server) already received the portion
   of the user profile needed in order to serve the user.  The following
   values are defined:

   o  USER_DATA_NOT_AVAILABLE (0)
      The Diameter client (SIP server) does not have the data that it
      needs to serve the user.

   o  USER_DATA_ALREADY_AVAILABLE (1)
      The Diameter client (SIP server) already has received the data
      that it needs to serve the user.




Garcia-Martin, et al.       Standards Track                    [Page 58]

RFC 4740                Diameter SIP Application           November 2006


9.14.  SIP-Method AVP

   The SIP-Method-AVP (AVP Code 393) is of type UTF8String and contains
   the method of the SIP request that triggered the Diameter message.
   The Diameter server MUST use this AVP solely for authorization of SIP
   requests, and MUST NOT use it to compute the Digest authentication.
   To compute the Digest authentication, the Diameter server MUST use
   the Digest-Method AVP instead.

10.  New Values for Existing AVPs

   This section defines new values that the Diameter SIP application
   extends to already existing AVPs.

10.1.  Extension to the Result-Code AVP Values

   The Result-Code AVP is already defined in RFC 3588 [RFC3588].  In
   addition to the values already defined in RFC 3588 [RFC3588], the
   Diameter SIP application defines the following new Result-Code AVP
   values:

10.1.1.  Success Result-Code AVP Values

   A Diameter peer uses Result-Code AVP values that fall into the
   success category to inform the remote peer that a request has been
   successfully completed.

   o  DIAMETER_FIRST_REGISTRATION 2003
      The user was not previously registered.  The Diameter server has
      now authorized the registration.

   o  DIAMETER_SUBSEQUENT_REGISTRATION 2004
      The user is already registered.  The Diameter server has now
      authorized the re-registration.

   o  DIAMETER_UNREGISTERED_SERVICE 2005
      The user is not currently registered, but the requested service
      can still be granted to the user.

   o  DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2006
      The request operation was successfully processed.  The Diameter
      server does not keep a record of the SIP server address assigned
      to the user.

   o  DIAMETER_SERVER_SELECTION 2007
      The Diameter server has authorized the registration.  The user has
      already been assigned a SIP server, but it may be necessary to
      select a new SIP server for the user.



Garcia-Martin, et al.       Standards Track                    [Page 59]

RFC 4740                Diameter SIP Application           November 2006


   o  DIAMETER_SUCCESS_AUTH_SENT_SERVER_NOT_STORED 2008
      The requested operation was successfully executed.  The Diameter
      server is sending a number of authentication credentials in the
      answer message.  The Diameter server does not keep a record of the
      SIP server.

10.1.2.  Transient Failures Result-Code AVP Values

   A Diameter peer uses a Result-Code AVP value that falls in the
   transient failures category to inform the remote peer that a request
   could not be satisfied at the time it was received, but it MAY be
   satisfied by the Diameter peer in the future.

   o  DIAMETER_USER_NAME_REQUIRED 4013
      The Diameter request did not contain a User-Name AVP, which is
      required to complete the transaction.  The Diameter peer MAY
      include a User-Name AVP and attempt the request again.

10.1.3.  Permanent Failures Result-Code AVP Values

   A Diameter peer uses a Result-Code AVP value that falls into the
   permanent failure category to inform the remote peer that the request
   failed and should not be attempted again.

   o  DIAMETER_ERROR_USER_UNKNOWN 5032
      The SIP-AOR AVP value does not belong to a known user in this
      realm.

   o  DIAMETER_ERROR_IDENTITIES_DONT_MATCH 5033
      The value in one of the SIP-AOR AVPs is not allocated to the user
      specified in the User-Name AVP.

   o  DIAMETER_ERROR_IDENTITY_NOT_REGISTERED 5034
      A query for location information is received for a SIP AOR that
      has not been registered before.  The user to which this identity
      belongs cannot be given service in this situation.

   o  DIAMETER_ERROR_ROAMING_NOT_ALLOWED 5035
      The user is not allowed to roam to the visited network.

   o  DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED 5036
      The identity being registered has already been assigned a server
      and the registration status does not allow that it is overwritten.

   o  DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED 5037
      The authentication scheme indicated in an authentication request
      is not supported.




Garcia-Martin, et al.       Standards Track                    [Page 60]

RFC 4740                Diameter SIP Application           November 2006


   o  DIAMETER_ERROR_IN_ASSIGNMENT_TYPE 5038
      The SIP server address sent in the SIP-Server-URI AVP value of the
      Diameter Server-Assignment-Request (SAR) command is the same SIP
      server address that is currently assigned to the user name, but
      the SIP-Server-Assignment-Type AVP is not allowed.  For example,
      the user is registered and the Server-Assignment-Request indicates
      the assignment for an unregistered user.

   o  DIAMETER_ERROR_TOO_MUCH_DATA 5039
      The Diameter peer in the SIP server receives more data than it can
      accept.  The SIP server cannot overwrite the already stored data.

   o  DIAMETER_ERROR_NOT SUPPORTED_USER_DATA 5040
      The SIP server informs the Diameter server that the received
      subscription data contained information that was not recognized or
      supported.

11.  Authentication Details

   Authenticating a user can occur through various mechanisms.
   Currently HTTP Digest authentication is supported.  The actual
   authentication is performed in either the SIP server or the Diameter
   server.

   If the Diameter server wants to assure that authentication will take
   place in the Diameter server (as opposed to a delegated
   authentication taking place in the SIP server), it MUST NOT include a
   Digest-HA1 AVP (part of the grouped SIP-Authenticate AVP, which in
   turn is part of the SIP-Auth-Data-Item AVP) in a MAA message.  The
   Diameter server MAY include a pre-calculated Digest-HA1 AVP in the
   MAA message if it wants to delegate authentication of the user to the
   SIP server.

   Note that on systems where the SIP User Agent is using HTTP Digest
   authentication [RFC2617] inside of Transport Layer Security (TLS)
   [RFC4346], where only the SIP proxy server has a certificate,
   delegating authentication to the SIP server (by making Digest-HA1
   available to the SIP server) might reduce the load on the Diameter
   server.

   When requesting authentication, the Diameter client indicates in the
   SIP-Number-Auth-Items AVP value of a Diameter MAR message how many
   authentication credentials are being requested.  In the Diameter MAA
   message, the Diameter server MAY include more than one
   SIP-Auth-Data-Item AVP, but it is only useful for the Diameter client
   if the Digest-QoP AVP was set to 'auth-int' (in the MAR message), and
   if future authentications will have the same realm.  When including
   more than one SIP-Auth-Data-Item AVP, the Diameter server SHOULD



Garcia-Martin, et al.       Standards Track                    [Page 61]

RFC 4740                Diameter SIP Application           November 2006


   indicate how many instances of SIP-Auth-Data-Item AVPs are present
   with the SIP-Number-Auth-Items AVP.  This number may be different
   from the one requested in the Diameter MAR message.  If multiple
   SIP-Auth-Data-Item AVPs are present, and their ordering is
   significant, the Diameter server MUST include a SIP-Item-Number AVP
   in each grouping to indicate the order.  The
   SIP-Authentication-Scheme AVP indicates "Digest" and the
   SIP-Authenticate AVP contains data (typically a challenge of some
   kind) that the user can use for her authentication.  The grouped
   SIP-Authorization AVP contains the AVPs that conform to the response
   expected from the user.

   If the Diameter server performs the authentication of the user, the
   Diameter MAR message that the Diameter client sends to the Diameter
   server MUST include all the authentication credentials supplied by
   the SIP UA (there might be more than one credential, e.g., different
   realms, authentication of proxies, etc.).  Each credential is
   inserted in a grouped SIP-Authorization AVP (part of the grouped
   SIP-Auth-Data-Item AVP).  The Diameter client MUST insert a
   SIP-Number-Auth-Items AVP with the value set to the number of
   credentials enclosed.  If necessary, the Digest-Entity-Body-Hash AVP
   will contain a hash of the body, needed to perform the
   authentication.  If the authentication is successful, the Diameter
   MAA message will contain a Result-Code AVP indicating success, and if
   necessary, the Diameter server MAY include one or more
   SIP-Auth-Data-Item AVPs to provide further authentication credentials
   to the SIP server.  If the authentication is unsuccessful due to
   missing credentials, the Diameter MAA message will include a
   SIP-Auth-Data-Item AVP with the SIP-Authentication-Scheme and
   SIP-Authenticate AVPs containing data (typically a challenge of some
   kind) that the user can use to authenticate itself.

   There are situations where a SIP request traverses several proxies,
   and each of the proxies requests to authenticate the SIP UA.  In this
   situation, it is a valid scenario that a SIP request received at a
   SIP server contains several sets of credentials.  The 'realm'
   directive in HTTP is the key that the Diameter client can use to
   determine which credential is applicable.  Also, none of the realms
   may be of interest to the Diameter client, in which case the Diameter
   client MUST consider that no credentials (of interest) were sent.  In
   any case, a Diameter client MUST send zero or exactly one credential
   to the Diameter server.  The Diameter client MUST choose the
   credential based on the 'realm' directive in the
   Authorization/Proxy-Authorization header field, and it MUST match the
   realm of the Diameter client.

   It must be noted that nonces are always generated in the Diameter
   server.



Garcia-Martin, et al.       Standards Track                    [Page 62]

RFC 4740                Diameter SIP Application           November 2006


12.  Migration from RADIUS

   RADIUS offers support for HTTP Digest authentication in the RADIUS
   Extension for Digest Authentication [RFC4590].  A number of AVPs (the
   Digest-* AVPs) of this Diameter SIP application are imported from the
   RADIUS attributes namespace, thus making the migration from RADIUS to
   Diameter smooth.

   Note that the RADIUS Extension for Digest Authentication [RFC4590]
   provides a more limited scope than this Diameter SIP application.
   Specifically, the RADIUS extension for Digest Authentication merely
   provides support for HTTP Digest authentication, whereas the Diameter
   SIP application provides support for user location, profile
   downloading and update, etc.

   The following sections discuss several configurations in which a
   gateway translates RADIUS to Diameter and vice versa.

12.1.  Gateway from RADIUS Client to Diameter Server

   The gateway maps Access-Request messages to MAR request.  If a RADIUS
   Access-Request message contains at least one Digest-* attribute, the
   gateway maps all Digest-* attributes to the AVPs of a Diameter
   SIP-Authorization AVP, constructs a MAR message, and sends it to the
   Diameter server.  If the RADIUS Access-Request message does not
   contain any Digest-* attribute, then the RADIUS client does not want
   to apply HTTP Digest authentication, in which case, actions at the
   gateway are outside the scope of this document.

   The Diameter server responds with a MAA message.  If the MAA message
   contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH
   and contains challenge parameters in a SIP-Authenticate AVP, then the
   gateway translates the AVPs of SIP-Authenticate AVP and puts the
   resulting RADIUS attributes into an Access-Challenge message.  It
   sends the Access-Challenge message to the RADIUS client.

   If the MAA message contains a SIP-Authentication-Info and a
   Digest-Response AVP, the gateway converts these AVPs to the
   corresponding RADIUS attributes and constructs a RADIUS message.  If
   the Result-Code AVP is DIAMETER_SUCCESS, an Access-Accept is sent.
   In all other cases, an Access-Reject is sent.

12.2.  Gateway from Diameter Client to RADIUS Server

   The Diameter client sends a Diameter MAR message to the gateway.  If
   the MAR message does not contain SIP-Auth-Data-Item AVPs, the gateway
   constructs an Access-Request message and maps the SIP-AOR and
   SIP-Method AVPs to RADIUS attributes.  The gateway sends the



Garcia-Martin, et al.       Standards Track                    [Page 63]

RFC 4740                Diameter SIP Application           November 2006


   Access-Request message to the RADIUS server, which will respond with
   an Access-Challenge.  The gateway creates a MAA message with a
   Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH and maps the
   Digest-* attributes to Diameter AVPs in a SIP-Authenticate AVP.  The
   gateway sends the resulting MAA to the Diameter client, which will
   respond with a new MAR.

   The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP
   where the Digest-Realm AVP matches the locally configured realm
   value.  It takes the AVPs from this SIP-Auth-Data-Item AVP, converts
   them into the corresponding RADIUS attributes and constructs a RADIUS
   Access-Request message.  The gateway sends the Access-Request message
   to the RADIUS server.  If the RADIUS server responds with an
   Access-Accept message, the gateway converts the RADIUS attributes to
   Diameter AVPs, constructs a MAA message with a Result-Code AVP set to
   DIAMETER_SUCCESS and sends this message to the Diameter client.  If
   the RADIUS server responds with an Access-Reject message, the gateway
   converts the RADIUS attributes to Diameter AVPs, constructs a MAA
   message with a Result-Code AVP set to
   DIAMETER_ERROR_IDENTITIES_DONT_MATCH, and sends this message to the
   Diameter client.

12.3.  Known Limitations

   As mentioned earlier, there is not a 100% match between the Diameter
   SIP application and the RADIUS Extension for Digest Authentication
   [RFC4590].  In particular, the RADIUS Extension for Digest
   Authentication [RFC4590] does not offer equivalent functionality to
   the Diameter UAR/UAA, SAR/SAA, LIR/LIA, RTR/RTA, and PPR/PPA messages
   defined by this specification.

13.  IANA Considerations

   This document serves as IANA registration request for a number of
   items that should be registered in the AAA parameters registry.

13.1.  Application Identifier

   This document defines a standards-track Application-ID that falls
   into the Application Identifier standards-track address space defined
   by RFC 3588 [RFC3588] Section 11.3.  This Application-ID has been
   registered in the Application IDs sub-registry of the AAA parameters
   registry with the following data:

    ID values     Name                                Reference
   -----------    ------------------------            ---------
           6      Diameter Session Initiation         RFC 4740
                  Protocol (SIP) Application



Garcia-Martin, et al.       Standards Track                    [Page 64]

RFC 4740                Diameter SIP Application           November 2006


13.2.  Command Codes

   This document defines new standard commands whose Command Codes are
   to be allocated within the standard permanent Command Codes address
   space defined in RFC 3588 [RFC3588] Section 11.2.1.  These command
   codes should be registered in the Command Codes sub-registry of the
   AAA parameters registry.

   Table 1 in Section 8 contains the detailed list of Command Code names
   and values that are part of this Diameter application.

13.3.  AVP Codes

   This document defines new standard AVPs, whose AVP Codes are to be
   allocated within the AVP Codes address space defined in RFC 3588
   [RFC3588] Section 11.4.  These AVP codes have been registered in the
   AVP Codes sub-registry of the AAA parameters registry.

   Table 2 in Section 9 contains the detailed list of AVP names and AVP
   codes that are part of this Diameter application.

13.4.  Additional Values for the Result-Code AVP Value

   This document defines new standard Result-Code AVP values to be
   allocated within the Result-Code AVP address space defined in RFC
   3588 [RFC3588] Section 14.4.1.  These values are listed in the
   Result-Code AVP values section of the AVP Specific Values
   sub-registry of the AAA parameters registry.

   Section 10.1.1 lists the new Result-Code AVP values that fall into
   the success category, according to RFC 3588 [RFC3588] Section 7.1.2.

   Section 10.1.2 lists the new Result-Code AVP values that fall into
   the transient failures category, according to RFC 3588 [RFC3588]
   Section 7.1.4.

   Section 10.1.3 lists the new Result-Code AVP values that fall into
   the permanent failures category, according to RFC 3588 [RFC3588]
   Section 7.1.5.












Garcia-Martin, et al.       Standards Track                    [Page 65]

RFC 4740                Diameter SIP Application           November 2006


13.5.  Creation of the SIP-Server-Assignment-Type Section in the AAA
       Registry

   This document defines a new SIP-Server-Assignment-Type AVP (see
   Section 9.4).  This AVP is of type Enumerated.  We define an initial
   set of values that should be registered by IANA.  IANA should create
   a new "SIP-Sever-Assignment-Type AVP values" section under the AVP
   Specific Values sub-registry of the AAA parameters registry.  The
   initial list of values is listed in Section 9.4.

13.6.  Creation of the SIP-Authentication-Scheme Section in the AAA
       Registry

   This document defines a new SIP-Authentication-Scheme AVP (see
   Section 9.5.1).  This AVP is of type Enumerated.  We currently define
   a single value that should be registered by IANA.  IANA should create
   a new "SIP-Authentication-Scheme AVP values" section under the AVP
   Specific Values sub-registry of the AAA parameters registry.  The
   initial list of values is included in Section 9.5.1.

13.7.  Creation of the SIP-Reason-Code Section in the AAA Registry

   This document defines a new SIP-Reason-Code AVP (see Section 9.7.1).
   This AVP is of type Enumerated.  We define an initial set of values
   that should be registered by IANA.  IANA should create a new
   "SIP-Reason-Code AVP values" section under the AVP Specific Values
   sub-registry of the AAA parameters registry.  The initial list of
   values is listed in Section 9.7.1.

13.8.  Creation of the SIP-User-Authorization-Type Section in the AAA
       Registry

   This document defines a new SIP-User-Authorization-Type AVP (see
   Section 9.10).  This AVP is of type Enumerated.  We define an initial
   set of values that should be registered by IANA.  IANA should create
   a new "SIP-User-Authorization-Type AVP values" section under the AVP
   Specific Values sub-registry of the AAA parameters registry.  The
   initial list of values is listed in Section 9.10.

13.9.  Creation of the SIP-User-Data-Already-Available Section in the
       AAA Registry

   This document defines a new SIP-User-Data-Already-Available AVP (see
   Section 9.13).  This AVP is of type Enumerated.  We define an initial
   set of values which should be registered by IANA.  IANA should create
   a new "SIP-User-Data-Already-Available AVP values" section under the
   AVP Specific Values sub-registry of the AAA parameters registry.  The
   initial list of values is listed in Section 9.13.



Garcia-Martin, et al.       Standards Track                    [Page 66]

RFC 4740                Diameter SIP Application           November 2006


14.  Security Considerations

   This memo does not describe a stand-alone protocol, but a particular
   application for the Diameter protocol [RFC3588].  Consequently, all
   the security considerations applicable to Diameter automatically
   apply to this memo.  In particular, Section 13 of RFC 3588 applies to
   this memo.

   This Diameter SIP application allows a Diameter client to use the
   properties of HTTP Digest authentication [RFC2617] by evaluating or
   sending to the Diameter server the credentials supplied by a user.
   The discussion of HTTP Digest authentication in Section 4 of RFC 2617
   [RFC2617] is also applicable to this memo.

   This Diameter SIP application also allows a Diameter client to use
   the properties of HTTP Digest authentication using AKA [RFC3310] by
   evaluating or sending to the Diameter server the credentials supplied
   by a user.  Section 5 of RFC 3310 [RFC3310] is also applicable to
   this memo.

14.1.  Final Authentication Check in the Diameter Client/SIP Server

   The Diameter SIP application can be configured to operate in a
   scenario where the final authentication check is performed in the
   Diameter client (SIP server).  There are a number of security
   considerations associated to it; all of them are consequences of the
   requirement to transfer H(A1) from the Diameter server to the
   Diameter client:

   o  Both Diameter client and server must trust each other, such as
      when both client and server belong to the same administrative
      domain.

   o  To avoid eavesdroppers, the transport protocol between the
      Diameter client and server MUST be secured.  RFC 3588 [RFC3588]
      specifies TLS [RFC4346] and IPsec as possible transport protection
      mechanisms for Diameter.

   Due to these security considerations, it is RECOMMENDED to configure
   the Diameter SIP application to operate in the mode where the final
   authentication check is performed in the Diameter server.










Garcia-Martin, et al.       Standards Track                    [Page 67]

RFC 4740                Diameter SIP Application           November 2006


15.  Contributors

   The authors would like to thank the following contributors who made
   substantial contributions to this work:

          Pete McCann           Lucent

          Jaakko Rajaniemi      Nokia

   Wolfgang Beck (Deutsche Telekom AG) provided the text in Section 12,
   "Migration from RADIUS".

16.  Acknowledgements

   The authors would like to thank Tony Johansson and Kevin Purser for
   their invaluable contribution to the start-up of this application and
   the continuous progress.  The authors would like to thank Daniel
   Warren, Jayshree Bharatia, Kuntal Chowdhury, Jari Arkko, Avi Lior,
   Wolfgang Beck, Ulrich Wiehe, Cullen Jennings, Anu Leinonen, Glen
   Zorn, German Blanco, Mikko Aittola, Bert Wijnen, and Sam Hartman for
   their reviews and valuable comments.

   The Diameter SIP application is based on the Diameter application for
   the Cx interface of the 3GPP IP Multimedia Subsystem [3GPP.29.229].
   The authors would like to thank 3GPP Working Group CN4 for this work.

17.  References

17.1.  Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2617]      Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
                  S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
                  Authentication: Basic and Digest Access
                  Authentication", RFC 2617, June 1999.

   [RFC3261]      Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                  Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                  and E.  Schooler, "SIP: Session Initiation Protocol",
                  RFC 3261, June 2002.

   [RFC3310]      Niemi, A., Arkko, J., and V. Torvinen, "Hypertext
                  Transfer Protocol (HTTP) Digest Authentication Using
                  Authentication and Key Agreement (AKA)", RFC 3310,
                  September 2002.




Garcia-Martin, et al.       Standards Track                    [Page 68]

RFC 4740                Diameter SIP Application           November 2006


   [RFC3588]      Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
                  J.  Arkko, "Diameter Base Protocol", RFC 3588,
                  September 2003.

   [RFC4590]      Sterman, B., Sadolevsky, D., Schwartz, D., Williams,
                  D., and W. Beck, "RADIUS Extension for Digest
                  Authentication", RFC 4590, July 2006.

17.2.  Informative References

   [RFC4346]      Dierks, T. and E. Rescorla, "The Transport Layer
                  Security (TLS) Protocol Version 1.1", RFC 4346, April
                  2006.

   [RFC3263]      Rosenberg, J. and H. Schulzrinne, "Session Initiation
                  Protocol (SIP): Locating SIP Servers", RFC 3263,
                  June 2002.

   [RFC3680]      Rosenberg, J., "A Session Initiation Protocol (SIP)
                  Event Package for Registrations", RFC 3680,
                  March 2004.

   [RFC3880]      Lennox, J., Wu, X., and H. Schulzrinne, "Call
                  Processing Language (CPL): A Language for User Control
                  of Internet Telephony Services", RFC 3880,
                  October 2004.

   [RFC4004]      Calhoun, P., Johansson, T., Perkins, C., Hiller, T.,
                  and P. McCann, "Diameter Mobile IPv4 Application",
                  RFC 4004, August 2005.

   [RFC4005]      Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
                  "Diameter Network Access Server Application",
                  RFC 4005, August 2005.

   [RFC4006]      Hakala, H., Mattila, L., Koskinen, J-P., Stura, M.,
                  and J. Loughney, "Diameter Credit-Control
                  Application", RFC 4006, August 2005.

   [3GPP.29.229]  3GPP, "Cx and Dx interfaces based on the Diameter
                  protocol; Protocol details", 3GPP TS 29.229 5.12.0,
                  June 2006.

   [JSR-000116]   Java Community Process, "SIP Servlet API Specification
                  1.0 Final Release", JSR 000116, March 2003.






Garcia-Martin, et al.       Standards Track                    [Page 69]

RFC 4740                Diameter SIP Application           November 2006


Authors' Addresses

   Miguel A. Garcia-Martin (Editor)
   Nokia
   P.O. Box 407
   NOKIA GROUP, FIN  00045
   Finland

   Phone: +358 50 480 4586
   EMail: miguel.an.garcia@nokia.com


   Maria-Carmen Belinchon
   Ericsson
   Via de los Poblados 13
   Madrid  28033
   Spain

   Phone: +34 91 339 3535
   EMail: maria.carmen.belinchon@ericsson.com


   Miguel A. Pallares-Lopez
   Ericsson
   Via de los Poblados 13
   Madrid  28033
   Spain

   Phone: +34 91 339 4222
   EMail: miguel-angel.pallares@ericsson.com


   Carolina Canales-Valenzuela
   Ericsson
   Via de los Poblados 13
   Madrid  28033
   Spain

   Phone: +34 91 339 2680
   EMail: carolina.canales@ericsson.com











Garcia-Martin, et al.       Standards Track                    [Page 70]

RFC 4740                Diameter SIP Application           November 2006


   Kalle Tammi
   Nokia
   P.O.Box 785
   Tampere  33101
   Finland

   Phone: +358 40 505 8670
   EMail: kalle.tammi@nokia.com











































Garcia-Martin, et al.       Standards Track                    [Page 71]

RFC 4740                Diameter SIP Application           November 2006


Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.






Garcia-Martin, et al.       Standards Track                    [Page 72]