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
|
<pre>Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6809 I. Sedlacek
Category: Standards Track Ericsson
ISSN: 2070-1721 H. Kaplan
Acme Packet
November 2012
<span class="h1">Mechanism to Indicate Support of Features and Capabilities in</span>
<span class="h1">the Session Initiation Protocol (SIP)</span>
Abstract
This specification defines a new SIP header field, Feature-Caps. The
Feature-Caps header field conveys feature-capability indicators that
are used to indicate support of features and capabilities for SIP
entities that are not represented by the Uniform Resource Identifier
(URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact
header field can convey media feature tags in the Contact header
field to indicate support of features and capabilities.
This specification also defines feature-capability indicators and
creates a new IANA registry, "Proxy-Feature Feature-Capability
Indicator Trees", for registering feature-capability indicators.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6809">http://www.rfc-editor.org/info/rfc6809</a>.
<span class="grey">Holmberg, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Definitions .....................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Feature-Caps Header Field .......................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Introduction ...............................................<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. User Agent and Proxy Behavior ..............................<a href="#page-4">4</a>
<a href="#section-4.2.1">4.2.1</a>. General .............................................<a href="#page-4">4</a>
<a href="#section-4.2.2">4.2.2</a>. B2BUA Behavior ......................................<a href="#page-5">5</a>
<a href="#section-4.2.3">4.2.3</a>. Registrar Behavior ..................................<a href="#page-6">6</a>
<a href="#section-4.2.4">4.2.4</a>. Proxy Behavior ......................................<a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. SIP Message Type and Response Code Semantics ...............<a href="#page-7">7</a>
<a href="#section-4.3.1">4.3.1</a>. General .............................................<a href="#page-7">7</a>
<a href="#section-4.3.2">4.3.2</a>. SIP Dialog ..........................................<a href="#page-7">7</a>
<a href="#section-4.3.3">4.3.3</a>. SIP Registration (REGISTER) .........................<a href="#page-7">7</a>
<a href="#section-4.3.4">4.3.4</a>. SIP Standalone Transactions .........................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Feature-Capability Indicators ...................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. Introduction ...............................................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Registration Trees .........................................<a href="#page-9">9</a>
<a href="#section-5.2.1">5.2.1</a>. General .............................................<a href="#page-9">9</a>
<a href="#section-5.2.2">5.2.2</a>. Global Tree .........................................<a href="#page-9">9</a>
<a href="#section-5.2.3">5.2.3</a>. SIP Tree ............................................<a href="#page-9">9</a>
<a href="#section-5.3">5.3</a>. Feature-Capability Indicator Specification Requirements ...<a href="#page-10">10</a>
<a href="#section-5.3.1">5.3.1</a>. General ............................................<a href="#page-10">10</a>
<a href="#section-5.3.2">5.3.2</a>. Overall Description ................................<a href="#page-10">10</a>
<a href="#section-5.3.3">5.3.3</a>. Feature-Capability Indicator Values ................<a href="#page-10">10</a>
<a href="#section-5.3.4">5.3.4</a>. Usage Restrictions .................................<a href="#page-11">11</a>
<a href="#section-5.3.5">5.3.5</a>. Interoperability Considerations ....................<a href="#page-11">11</a>
<a href="#section-5.3.6">5.3.6</a>. Security Considerations ............................<a href="#page-11">11</a>
<a href="#section-5.3.7">5.3.7</a>. Examples ...........................................<a href="#page-12">12</a>
<a href="#section-5.3.8">5.3.8</a>. Other Information ..................................<a href="#page-12">12</a>
<span class="grey">Holmberg, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<a href="#section-6">6</a>. Syntax .........................................................<a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. General ...................................................<a href="#page-12">12</a>
<a href="#section-6.2">6.2</a>. Syntax: Feature-Caps Header Field .........................<a href="#page-12">12</a>
<a href="#section-6.2.1">6.2.1</a>. ABNF ...............................................<a href="#page-12">12</a>
<a href="#section-6.3">6.3</a>. Syntax: Feature-Capability Indicator ......................<a href="#page-12">12</a>
<a href="#section-6.3.1">6.3.1</a>. General ............................................<a href="#page-12">12</a>
<a href="#section-6.3.2">6.3.2</a>. ABNF ...............................................<a href="#page-13">13</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Registration of the Feature-Caps Header Field .............<a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Registration of the Feature-Caps Header Field Parameter ...<a href="#page-13">13</a>
<a href="#section-7.3">7.3</a>. Proxy-Feature Feature-Capability Indicator Trees ..........<a href="#page-14">14</a>
<a href="#section-7.3.1">7.3.1</a>. Introduction .......................................<a href="#page-14">14</a>
7.3.2. Global Feature-Capability Indicator
Registration Tree ..................................<a href="#page-14">14</a>
7.3.3. SIP Feature-Capability Indicator
Registration Tree ..................................<a href="#page-15">15</a>
<a href="#section-8">8</a>. Feature-Capability Indicator Registration Template .............<a href="#page-16">16</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-17">17</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-17">17</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-18">18</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-18">18</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-18">18</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Session Initiation Protocol (SIP) [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] extension for
indicating User Agent (UA) capabilities, defined in <a href="./rfc3840">RFC 3840</a>
[<a href="./rfc3840" title=""Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"">RFC3840</a>], provides a mechanism that allows a SIP message to convey
information relating to the originator's features and capabilities,
using the Contact header field.
This specification defines a new SIP header field, Feature-Caps. The
Feature-Caps header field conveys feature-capability indicators that
are used to indicate support of features and capabilities for SIP
entities that are not represented by the Uniform Resource Identifier
(URI) of the Contact header field. Such cases are:
o The SIP entity acts as a SIP proxy.
o The SIP entity acts as a SIP registrar.
o The SIP entity acts as a Back-to-Back User Agent (B2BUA)
[<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], where the Contact header field URI represents another
SIP entity.
SIP entities that are represented by the URI of the SIP Contact
header field can convey media feature tags in the Contact header
field to indicate support of features and capabilities.
<span class="grey">Holmberg, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
Unlike media feature tags, feature-capability indicators are intended
to only be used with SIP.
This specification also defines feature-capability indicators and
creates a new IANA registry, "Proxy-Feature Feature-Capability
Indicator Trees", for registering feature-capability indicators.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Definitions</span>
Downstream SIP entity: SIP entity in the direction towards which a
SIP request is sent.
Upstream SIP entity: SIP entity in the direction from which a SIP
request is received.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Feature-Caps Header Field</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Introduction</span>
The Feature-Caps header field is used by SIP entities to convey
support of features and capabilities, by setting feature-capability
indicators. A feature-capability indicator conveyed in a
Feature-Caps header field indicates that a SIP entity in the SIP
message signaling path supports the associated feature and
capability.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. User Agent and Proxy Behavior</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. General</span>
If the URI in a Contact header field of a request or response
represents a SIP entity, the entity MUST NOT indicate supported
features and capabilities using a Feature-Caps header field within
that request or response.
When a SIP entity receives a SIP request, or response, that contains
one or more Feature-Caps header fields, the feature-capability
indicators in the header field inform the entity about the features
and capabilities supported by entities in the SIP message signaling
<span class="grey">Holmberg, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
path. The procedure by which features and capabilities are invoked
are outside the scope of this specification and MUST be described by
individual feature-capability indicator specifications.
A Feature-Caps header field value cannot convey the address of the
SIP entity that inserted the Feature-Caps header field. If
additional data about a supported feature needs to be conveyed, such
as the address of the SIP entity that indicated support of the
feature, then the feature definition needs to define a way to convey
that information as a value of the associated feature-capability
indicator.
When a SIP entity adds a Feature-Caps header field to a SIP message,
it MUST place the header field before any existing Feature-Caps
header field in the message to be forwarded, so that the added header
field becomes the top-most one. Then, when another SIP entity
receives a SIP request or the response, the SIP feature-capability
indicators in the top-most Feature-Caps header field will represent
the supported features and capabilities "closest", from a SIP
signaling point of view, to the entity.
Based on features and policies, a SIP entity MAY remove a
Feature-Caps header field from a SIP message. Also, a SIP entity MAY
remove a feature-capability indicator from a Feature-Caps header
field within a SIP message. A SIP entity SHOULD NOT re-order the
Feature-Caps header fields within a SIP message.
For a given fc-value, as defined in <a href="#section-6.2.1">Section 6.2.1</a>, the order in which
feature-capability indicators are listed has no significance. For
example, "foo;bar" and "bar;foo" have the same meaning (i.e., that
the SIP entity that inserted the feature-capability indicator
supports the features and capabilities associated with the "foo" and
"bar" feature-capability indicators).
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. B2BUA Behavior</span>
The procedures in this section apply to User Agents (UAs) [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]
that are part of B2BUAs that are referenced in the message by a
Record-Route header field rather than by the URI of the Contact
header field.
When such a UA sends a SIP request, if the UA wants to indicate
support of features and capabilities towards its downstream SIP
entities, it inserts a Feature-Caps header field in the request,
containing one or more feature-capability indicators associated with
the supported features and capabilities, before it forwards the
request.
<span class="grey">Holmberg, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
If the SIP request is triggered by another SIP request that the B2BUA
has received, the UA MAY forward received Feature-Caps header fields
by copying them to the outgoing SIP request, similar to a SIP proxy,
before it inserts its own Feature-Caps header field in the SIP
request.
When such a UA receives a SIP response, if the UA wants to indicate
support of features and capabilities towards its upstream SIP
entities, it inserts a Feature-Caps header field in the response,
containing one or more feature-capability indicators associated with
the supported features and capabilities, before it forwards the
response.
If the SIP response is triggered by another SIP response that the
B2BUA has received, the UA MAY forward received Feature-Caps header
fields by copying them to the outgoing SIP response, similar to a SIP
proxy, before it inserts its own Feature-Caps header field in the SIP
response.
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. Registrar Behavior</span>
If a SIP registrar wants to indicate support of features and
capabilities towards its upstream SIP entities, it inserts a
Feature-Caps header field, containing one or more feature-capability
indicators associated with the supported features and capabilities,
in a REGISTER response.
<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>. Proxy Behavior</span>
When a SIP proxy receives a SIP request, if the proxy wants to
indicate support of features and capabilities towards its downstream
SIP entities, it inserts a Feature-Caps header field in the request,
containing one or more SIP feature-capability indicators associated
with the supported features and capabilities, before it forwards the
request.
When a proxy receives a SIP response, if the proxy wants to indicate
support of features and capabilities towards its upstream SIP
entities, it inserts a Feature-Caps header field in the response,
containing one or more SIP feature-capability indicators associated
with the supported features and capabilities, before it forwards the
response.
<span class="grey">Holmberg, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. SIP Message Type and Response Code Semantics</span>
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. General</span>
This section describes the general usage and semantics of the
Feature-Caps header field for different SIP message types and
response codes.
<a href="#section-6.2.1">Section 6.2.1</a> defines the Feature-Caps header field ABNF.
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. SIP Dialog</span>
The Feature-Caps header field can be used within an initial SIP
request for a dialog, within a target refresh SIP request, and within
any 18x or 2xx response associated with such requests.
If a feature-capability indicator is inserted in a Feature-Caps
header field of an initial request for a dialog, or within a response
of such a request, it indicates to the receivers of the request (or
response) that the feature associated with the feature-capability
indicator is supported for the duration of the dialog, until a target
refresh request is sent for the dialog, or until the dialog is
terminated.
Unless a feature-capability indicator is inserted in a Feature-Caps
header field of a target refresh request, or within a response of
such a request, it indicates to the receivers of the request (or
response) that the feature is no longer supported for the dialog.
For a given dialog, a SIP entity MUST insert the same feature-
capability indicators in all 18x and 2xx responses associated with a
given transaction.
As it cannot be guaranteed that 2xx responses associated with SIP
SUBSCRIBE requests will reach the User Agent Client (UAC) [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>],
due to forking of the request, entities need to indicate supported
features and capabilities in the SIP NOTIFY request that will be sent
for each of the created subscription dialogs.
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. SIP Registration (REGISTER)</span>
The Feature-Caps header field can be used within a SIP REGISTER
request and within the 200 (OK) response associated with such a
request.
If a feature-capability indicator is conveyed in a Feature-Caps
header field of a REGISTER request, or within an associated response,
it indicates to the receivers of the message that the feature
<span class="grey">Holmberg, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
associated with the feature-capability indicator is supported for the
registration, until the registration of the contact that was
explicitly conveyed in the REGISTER request expires, or until the
registered contact is explicitly refreshed and the refresh REGISTER
request does not contain the feature-capability indicator associated
with the feature.
While a REGISTER response can contain contacts that have been
registered as part of other registration transactions, support of any
indicated feature only applies to requests sent to the contact(s)
that were explicitly conveyed in the associated REGISTER request.
This specification does not define any semantics for usage of the
Feature-Caps header field in pure registration binding fetching
messages (see <a href="./rfc3261#section-10.2.3">Section 10.2.3 of RFC 3261</a>), where the REGISTER request
does not contain a Contact header field. Unless such semantics are
defined in a future extension, fetching messages will not have any
impact on previously indicated support of features and capabilities,
and SIP entities MUST NOT insert a Feature-Caps header field in such
messages.
If SIP outbound [<a href="./rfc5626" title=""Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)"">RFC5626</a>] is used, the rules above apply. However,
supported features and capabilities only apply for the registration
flow on which support has been explicitly indicated.
<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>. SIP Standalone Transactions</span>
The Feature-Caps header field can be used within a standalone SIP
request and within any 2xx response associated with such a request.
If a feature-capability indicator is inserted in a Feature-Caps
header field of a standalone request, or within a response of such a
request, it indicates to the receivers of the request (or response)
that the feature associated with the feature-capability indicator is
supported for the duration of the standalone transaction.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Feature-Capability Indicators</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Introduction</span>
Feature-capability indicators are used by SIP entities not
represented by the URI of the Contact header field to indicate
support of features and capabilities, where media feature tags cannot
be used to indicate such support.
A value, or a list of values, that provides additional information
about the supported feature or capability can be associated with a
feature-capability indicator.
<span class="grey">Holmberg, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Registration Trees</span>
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. General</span>
The following subsections define registration trees, distinguished
by the use of faceted names (e.g., names of the form
"tree.feature-name"). The registration trees are defined in the IANA
"Proxy-Feature Feature-Capability Indicator Trees" registry.
The trees defined herein are similar to the global tree and SIP tree
defined for media feature tags, in RFCs 2506 [<a href="./rfc2506" title=""Media Feature Tag Registration Procedure"">RFC2506</a>] and 3840
[<a href="./rfc3840" title=""Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"">RFC3840</a>]. Other registration trees are outside the scope of this
specification.
In contrast to RFCs 2506 and 3840, this specification only defines a
global tree and a SIP tree, as they are the only trees defined in
those RFCs that have been used for defining SIP-specific media
feature tags.
When a feature-capability indicator is registered in any registration
tree, no leading "+" is used in the registration.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Global Tree</span>
The global feature-capability indicator tree is similar to the media
feature tag global tree defined in <a href="./rfc2506">RFC 2506</a> [<a href="./rfc2506" title=""Media Feature Tag Registration Procedure"">RFC2506</a>].
A feature-capability indicator in the global tree will be
distinguished by the leading facet "g.". An organization can propose
either a designation indicative of the feature (e.g., "g.blinktags")
or a faceted designation including the organization name (e.g.,
"g.organization.blinktags").
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. SIP Tree</span>
The SIP feature-capability indicator tree is similar to the media
feature tag SIP tree defined in <a href="./rfc3840">RFC 3840</a>.
A feature-capability indicator in the SIP tree will be distinguished
by the leading facet "sip.".
<span class="grey">Holmberg, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Feature-Capability Indicator Specification Requirements</span>
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. General</span>
A feature-capability indicator specification MUST address the issues
defined in the following subsections or document why an issue is not
applicable for the specific feature-capability indicator. A
reference to the specification MUST be provided when the feature-
capability indicator is registered with IANA (see <a href="#section-8">Section 8</a>).
It is bad practice for feature-capability indicator specifications to
repeat procedures (e.g., general procedures on the usage of the
Feature-Caps header field and feature-capability indicators) defined
in this specification, unless needed for clarification or emphasis
purposes. A feature-capability indicator specification MUST NOT
modify the Feature-Caps header field rules and semantics defined in
<a href="#section-4">Section 4</a>.
A feature-capability indicator specification MUST NOT weaken any
behavior designated with "SHOULD" or "MUST" in this specification.
However, a specification MAY strengthen "SHOULD", "MAY", or
"RECOMMENDED" requirements to "MUST" strength if features and
capabilities associated with the feature-capability indicator
require it.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Overall Description</span>
The feature-capability indicator specification MUST contain an
overall description of the feature-capability indicator: how it is
used to indicate support of a feature, a description of the feature
associated with the feature-capability indicator, a description of
any additional information (conveyed using one or more feature-
capability indicator values) that can be conveyed together with the
feature-capability indicator, and a description of how the associated
feature MAY be exercised/invoked.
<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>. Feature-Capability Indicator Values</span>
A feature-capability indicator can have an associated value, or a
list of values. The feature-capability indicator specification MUST
define the syntax and semantics of any value defined for the feature-
capability indicator, including possible restrictions related to the
usage of a specific value. The feature-capability indicator
specification MUST define the value(s) in accordance with the ABNF
defined in <a href="#section-6.3.2">Section 6.3.2</a>. The feature-capability indicator
specification MUST define whether the feature-capability indicator
has a default value.
<span class="grey">Holmberg, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
If no values are defined for the feature-capability indicator, it
MUST be indicated in the feature-capability indicator specification.
A feature-capability indicator value is only applicable for the
feature-capability indicator for which it has been defined. For
other feature-capability indicators, the value has to be defined
explicitly, even if the semantics are identical.
It is strongly RECOMMENDED to not re-use a value that already has
been defined for another feature-capability indicator, unless the
semantics of the values are the same.
<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>. Usage Restrictions</span>
If there are restrictions on how SIP entities can insert a feature-
capability indicator, the feature-capability indicator specification
MUST document such restrictions.
There might be restrictions related to whether or not entities
o are allowed to insert a feature-capability indicator in
registration-related messages, standalone transaction messages, or
dialog-related messages,
o are allowed to insert a feature-capability indicator in requests
or responses,
o also need to support other features and capabilities in order to
insert a feature-capability indicator, and
o are allowed to indicate support of a feature in conjunction with
another feature.
<span class="h4"><a class="selflink" id="section-5.3.5" href="#section-5.3.5">5.3.5</a>. Interoperability Considerations</span>
The feature-capability indicator specification MUST document any
specific interoperability considerations that apply to the feature-
capability indicator.
Interoperability considerations can, e.g., include procedures related
to cases where an expected feature-capability indicator is not
present or where it contains an unexpected value.
<span class="h4"><a class="selflink" id="section-5.3.6" href="#section-5.3.6">5.3.6</a>. Security Considerations</span>
The feature-capability indicator specification MUST document any
specific security considerations that apply to the feature-capability
indicator.
<span class="grey">Holmberg, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h4"><a class="selflink" id="section-5.3.7" href="#section-5.3.7">5.3.7</a>. Examples</span>
It is recommended that the feature-capability indicator specification
provide demonstrative message flow diagrams, paired with complete
messages and message descriptions.
Note that example message flows are by definition informative and do
not replace normative text.
<span class="h4"><a class="selflink" id="section-5.3.8" href="#section-5.3.8">5.3.8</a>. Other Information</span>
If there is additional information about the feature-capability
indicator, it is recommended to describe such information. It can
include, for example, names of related feature-capability indicators.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Syntax</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. General</span>
This section defines the ABNF for the Feature-Caps header field and
for the feature-capability indicators. The ABNF defined in this
specification is conformant to <a href="./rfc5234">RFC 5234</a> [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Syntax: Feature-Caps Header Field</span>
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. ABNF</span>
The ABNF for the Feature-Caps header fields is:
Feature-Caps = "Feature-Caps" HCOLON fc-value
*(COMMA fc-value)
fc-value = "*" *(SEMI feature-cap)
NOTE: The "*" value is present in order to follow the guidelines for
syntax in <a href="./rfc4485">RFC 4485</a> [<a href="./rfc4485" title=""Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)"">RFC4485</a>] and to maintain a consistent format with
RFCs 3840 [<a href="./rfc3840" title=""Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"">RFC3840</a>] and 3841 [<a href="./rfc3841" title=""Caller Preferences for the Session Initiation Protocol (SIP)"">RFC3841</a>].
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Syntax: Feature-Capability Indicator</span>
<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>. General</span>
In a feature-capability indicator name (ABNF: fcap-name), dots can be
used to implement a feature-capability indicator tree hierarchy
(e.g., tree.feature.subfeature). The description of usage of such a
tree hierarchy must be described when registered.
<span class="grey">Holmberg, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>. ABNF</span>
The ABNF for the feature-capability indicator is:
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list
/ fcap-string-value ) RDQUOT]
fcap-name = ftag-name
fcap-value-list = tag-value-list
fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in <a href="./rfc3840">RFC 3840</a>
NOTE: In comparison with media feature tags, the "+" sign in front of
the feature-capability indicator name is mandatory.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Registration of the Feature-Caps Header Field</span>
This specification registers a new SIP header field, Feature-Caps,
according to the process defined in <a href="./rfc3261">RFC 3261</a> [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>].
The following is the registration for Feature-Caps in the "Header
Fields" registry:
RFC Number: <a href="./rfc6809">RFC 6809</a>
Header Field Name: Feature-Caps
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Registration of the Feature-Caps Header Field Parameter</span>
This specification adds the Feature-Caps header field to the IANA
"Header Field Parameters and Parameter Values" registry, according to
the process described in <a href="./rfc3968">RFC 3968</a> [<a href="./rfc3968" title=""The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)"">RFC3968</a>].
Predefined
Header Field Parameter Name Values Reference
--------------------------------------------------------------------
Feature-Caps +<fcap-name> * No [<a href="./rfc6809">RFC6809</a>]
* <fcap-name> denotes parameter names conforming to the
syntax <fcap-name> defined in <a href="./rfc6809">RFC 6809</a>. Valid
feature-capability indicators are registered in the
Proxy-Feature Feature-Capability Indicator Trees registry.
<span class="grey">Holmberg, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Proxy-Feature Feature-Capability Indicator Trees</span>
<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>. Introduction</span>
This specification creates a new sub-registry to the IANA "Session
Initiation Protocol (SIP) Parameters" registry, according to the
process defined in <a href="./rfc5226">RFC 5226</a>. The name of the sub-registry is
"Proxy-Feature Feature-Capability Indicator Trees".
Feature-capability indicators are categorized by the "leading facet"
of their name. The leading facet is a prefix of the name consisting
of all characters up to and including the first ".". Feature-
capability indicator names that contain no "." characters are
considered to have an empty ("") leading facet.
The "Proxy-Feature Feature-Capability Indicator Trees" registry
contains sub-registries for subsets (called 'trees') of feature-
capability indicators sharing the same leading facet. Each feature-
capability indicator is registered within the tree that matches its
leading facet. If no tree matches its leading facet, then the
feature-capability indicator cannot be registered.
New feature-capability indicator sub-registries (trees) can be
registered. The registration must meet the "Standards Action"
policies defined in <a href="./rfc5226">RFC 5226</a> [<a href="./rfc5226" title="">RFC5226</a>]. A new name, unique leading
facet, and registration policies (as defined in <a href="./rfc5226">RFC 5226</a>) for
feature-capability indicators within this tree need to be provided.
This document defines the first two feature-capability indicator
trees ("g." and "sip."). It does not define a tree for the empty
leading facet.
<span class="h4"><a class="selflink" id="section-7.3.2" href="#section-7.3.2">7.3.2</a>. Global Feature-Capability Indicator Registration Tree</span>
This specification creates a new feature-capability indicator tree in
the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry.
The name of the tree is "Global Feature-Capability Indicator
Registration Tree", and its leading facet is "g.". It is used for
the registration of feature-capability indicators.
When a feature-capability indicator is registered in the global tree,
it needs to meet the "Specification Required" policies defined in
<a href="./rfc5226">RFC 5226</a>. A designated area expert will review the proposed feature-
capability indicator and consult with members of related mailing
lists. The information required in the registration is defined in
<a href="#section-5.3">Section 5.3</a> of this document.
<span class="grey">Holmberg, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
Note that all feature-capability indicators registered in the global
tree will have names with a leading facet "g.". No leading "+" is
used in the registrations in any of the feature-capability indicator
registration trees.
The format of the global tree is as described below:
Name Description Reference
------------------------------
Name - contains the Feature-Capability Indicator Name, provided in
the registration feature-capability indication registration template.
Description - provided in the registration feature-capability
indication registration template.
Reference - contains the Feature-Capability Indicator specification
reference provided in the registration feature-capability indication
registration template.
No initial values are registered in the global tree.
<span class="h4"><a class="selflink" id="section-7.3.3" href="#section-7.3.3">7.3.3</a>. SIP Feature-Capability Indicator Registration Tree</span>
This specification creates a new feature-capability indicator tree in
the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry.
The name of the tree is "SIP Feature-Capability Indicator
Registration Tree", and its leading facet is "sip.". It is used for
the registration of feature-capability indicators.
When a feature-capability indicator is registered in the SIP tree, it
needs to meet the "IETF Review" policies defined in <a href="./rfc5226">RFC 5226</a>. The
information required in the registration is defined in <a href="#section-5.3">Section 5.3</a> of
this document.
Note that all feature-capability indicators registered in the SIP
tree will have names with a leading facet "sip.". No leading "+" is
used in the registrations in any of the feature-capability indicator
registration trees.
<span class="grey">Holmberg, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
The format of the SIP tree is as described below:
Name Description Reference
------------------------------
Name - contains the Feature-Capability Indicator Name, provided in
the registration feature-capability indication registration template.
Description - provided in the registration feature-capability
indication registration template.
Reference - contains the Feature-Capability Indicator specification
reference provided in the registration feature-capability indication
registration template.
No initial values are registered in the SIP tree.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Feature-Capability Indicator Registration Template</span>
Registration requests for the global tree are submitted by email to
iana@iana.org.
Registration requests for the SIP tree requires submitting an
Internet-Draft to the IESG.
| Instructions are preceded by '|'. All fields are mandatory.
Feature-capability indicator name:
Description:
| The description should be no longer than 4 lines. More
| detailed information can be provided in the feature
| capability indicator specification.
Feature-capability indicator specification reference:
| The referenced specification must contain the information
| listed in <a href="./rfc6809#section-5.3">Section 5.3 of RFC 6809</a>.
Contact:
| Name(s) & email address(es) of person(s) to
| contact for further information.
<span class="grey">Holmberg, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The security issues for feature-capability indicators are similar to
the ones defined in <a href="./rfc3840">RFC 3840</a> for media feature tags. Media feature
tags can reveal information about end users and end-user equipment,
which can be used for industrial espionage. The knowledge about end-
user equipment capabilities can also be used to influence application
behavior. As feature-capability indicators are not intended to
convey capability information of end-user devices, such end-user
security aspects of <a href="./rfc3840">RFC 3840</a> do not apply to feature-capability
indicators.
In addition, the security issue discussed in <a href="./rfc3840">RFC 3840</a> regarding an
attacker using the SIP caller preferences extension [<a href="./rfc3841" title=""Caller Preferences for the Session Initiation Protocol (SIP)"">RFC3841</a>] in
order to affect routing decisions does not apply, as the mechanism is
not defined to be used with feature-capability indicators.
Feature-capability indicators can, however, provide capability and
characteristics information about the SIP entity, some of which might
be sensitive. Malicious elements viewing the indicators may be able
to discern application deployment details or identify elements with
exploitable feature implementation weaknesses. The Feature-Caps
header field does not convey address information about SIP entities.
However, individual feature-capability indicators might provide
address information as feature-capability indicator values.
Therefore, if the feature-capability indicators provide information
that requires data integrity or origin authentication, mechanisms for
providing those MUST be provided. If confidentiality is required,
then the specification MUST call for the use of Transport Layer
Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] at all hops. Since there are no
satisfactory middle-to-end or middle-to-middle SIP confidentiality
mechanisms, TLS is as good as it gets, and specifications SHOULD NOT
define feature-capability indicators that need confidentiality that
is better than the hop-by-hop confidentiality provided by TLS.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The authors wish to thank everyone in the SIP community that provided
input and feedback on the work of this specification.
<span class="grey">Holmberg, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC2506">RFC2506</a>] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", <a href="https://www.rfc-editor.org/bcp/bcp31">BCP 31</a>, <a href="./rfc2506">RFC 2506</a>, March 1999.
[<a id="ref-RFC3840">RFC3840</a>] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", <a href="./rfc3840">RFC 3840</a>, August 2004.
[<a id="ref-RFC3841">RFC3841</a>] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
<a href="./rfc3841">RFC 3841</a>, August 2004.
[<a id="ref-RFC3968">RFC3968</a>] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", <a href="https://www.rfc-editor.org/bcp/bcp98">BCP 98</a>, <a href="./rfc3968">RFC 3968</a>,
December 2004.
[<a id="ref-RFC4485">RFC4485</a>] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)",
<a href="./rfc4485">RFC 4485</a>, May 2006.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5626">RFC5626</a>] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", <a href="./rfc5626">RFC 5626</a>, October 2009.
<span class="grey">Holmberg, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6809">RFC 6809</a> Proxy Feature November 2012</span>
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: christer.holmberg@ericsson.com
Ivo Sedlacek
Ericsson
Scheelevaegen 19C
Lund 22363
Sweden
EMail: ivo.sedlacek@ericsson.com
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803
USA
EMail: hkaplan@acmepacket.com
Holmberg, et al. Standards Track [Page 19]
</pre>
|
