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) A. Johnston
Request for Comments: 7433 Avaya
Category: Standards Track J. Rafferty
ISSN: 2070-1721 Human Communications
January 2015
<span class="h1">A Mechanism for Transporting User-to-User Call Control Information</span>
<span class="h1">in SIP</span>
Abstract
There is a class of applications that benefit from using SIP to
exchange User-to-User Information (UUI) data during session
establishment. This information, known as call control UUI data, is
a small piece of data inserted by an application initiating the
session and utilized by an application accepting the session. The
syntax and semantics for the UUI data used by a specific application
are defined by a UUI package. This UUI data is opaque to SIP and its
function is unrelated to any basic SIP function. This document
defines a new SIP header field, User-to-User, to transport UUI data,
along with an extension mechanism.
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/rfc7433">http://www.rfc-editor.org/info/rfc7433</a>.
<span class="grey">Johnston & Rafferty Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
Copyright Notice
Copyright (c) 2015 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>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Requirements Discussion . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Normative Definition . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Syntax for UUI Header Field . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Hex Encoding Definition . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.3">4.3</a>. Source Identity of UUI Data . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Extensibility . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.1">6.1</a>. Registration of User-to-User Header Field . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. Registration of User-to-User Header Field Parameters . . <a href="#page-11">11</a>
<a href="#section-6.3">6.3</a>. Registration of UUI Packages . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.4">6.4</a>. Registration of UUI Content Parameters . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.5">6.5</a>. Registration of UUI Encoding Parameters . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.6">6.6</a>. Registration of SIP Option Tag . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. Other Possible Mechanisms . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-A.1">A.1</a>. Why INFO is Not Used . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
A.2. Why Other Protocol Encapsulation UUI Mechanisms Are Not
Used . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-A.3">A.3</a>. MIME Body Approach . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-A.4">A.4</a>. URI Parameter . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<span class="grey">Johnston & Rafferty Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Overview</span>
This document describes the transport of UUI data using SIP
[<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]. It defines a mechanism for the transport of general
application UUI data and for the transport of the call control
related ITU-T Recommendation Q.931 User-user information element
[<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>] and ITU-T Recommendation Q.763 User-to-User information
parameter [<a href="#ref-Q763" title=""Signalling System No. 7 - ISDN User Part formats and codes"">Q763</a>] data in SIP. UUI data is widely used in the Public
Switched Telephone Network (PSTN) today for contact centers and call
centers. There is also a trend for the related applications to
transition from ISDN to SIP. The UUI extension for SIP may also be
used for native SIP User Agents (UAs) implementing similar services
and to interwork with ISDN services. Note that in most cases, there
is an a priori understanding between the UAs in regard to what to do
with received UUI data. This document enables the definition of
packages and related attributes that can make such understandings
more explicit.
The UUI mechanism is designed to meet the use cases, requirements,
and call flows for SIP call control UUI detailed in [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>]. All
references to requirement numbers (REQ-N) and figure numbers refer to
[<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>].
The mechanism is a new SIP header field, along with a new SIP option
tag. The header field carries the UUI data, along with parameters
indicating the encoding of the UUI data, the UUI package, and
optionally the content of the UUI data. The package definition
contains details about how a particular application can utilize the
UUI mechanism. The header field can be included (sometimes called
"escaped") into URIs supporting referral and redirection scenarios.
In these scenarios, the History-Info header field is used to indicate
the inserter of the UUI data. The SIP option tag can be used to
indicate support for the header field. Support for the UUI header
field indicates that a UA is able to extract the information in the
UUI data and pass it up the protocol stack. Individual packages
using the UUI mechanism can utilize SIP media feature tags to
indicate that a UA supports a particular UUI package. Guidelines for
defining UUI packages are provided.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Johnston & Rafferty Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
Note that the <allOneLine> tag convention from SIP Torture Test
Messages [<a href="./rfc4475" title=""Session Initiation Protocol (SIP) Torture Test Messages"">RFC4475</a>] is used to show that there are no line breaks in
the actual message syntax.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Requirements Discussion</span>
This section describes how the User-to-User header field meets the
requirements in [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>]. The header field can be included in
INVITE requests and responses and BYE requests and responses, meeting
REQ-1 and REQ-2.
For redirection and referral use cases and REQ-3, the header field is
included (escaped) within the Contact or Refer-To URI. The details
of this mechanism as it applies for redirection and referral use
cases are covered in <a href="#section-4.1">Section 4.1</a>.
Since SIP proxy forwarding and retargeting does not affect header
fields, the header field meets REQ-4.
The UUI header field will carry the UUI data and not a pointer to the
data, so REQ-5 is met.
Since the basic design of the UUI header field is similar to the ISDN
UUI service, interworking with PSTN protocols is straightforward and
is documented in a separate specification [<a href="./rfc7434" title=""Interworking ISDN Call Control User Information with SIP"">RFC7434</a>], meeting REQ-6.
Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the
mechanism and supported packages, and hence applications. REQ-7
relates to support of the UUI header field, while REQ-8 relates to
routing based on support of the UUI header field. REQ-7 is met by
defining a new SIP option tag "uui". The use of a Require:uui in a
request or Supported:uui in an OPTIONS response could be used to
require or discover support of the mechanism. The presence of a
Supported:uui or Require:uui header field can be used by proxies to
route to an appropriate UA, meeting REQ-8. However, note that only
UAs are expected to understand the UUI data -- proxies and other
intermediaries do not. REQ-10 is met by utilizing SIP feature tags
[<a href="./rfc3840" title=""Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"">RFC3840</a>]. For example, the feature tag "sip.uui-isdn" could be used
to indicate support of the ISDN UUI package, or "sip.uui-pk1" could
be used to indicate support for a particular package, pk1.
Proxies commonly apply policy to the presence of certain SIP header
fields in requests by either passing them or removing them from
requests. REQ-9 is met by allowing proxies and other intermediaries
to remove UUI header fields in a request or response based on policy.
<span class="grey">Johnston & Rafferty Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
Carrying UUI data elements of at least 129 octets is trivial in the
UUI header field, meeting REQ-11. Note that avoiding having very
large UUI data elements is a good idea, as SIP header fields have
traditionally not been large.
To meet REQ-12 for the redirection and referral use cases, the
History-Info header field [<a href="./rfc7044" title=""An Extension to the Session Initiation Protocol (SIP) for Request History Information"">RFC7044</a>] can be used. In these
retargeting cases, the changed Request-URI will be recorded in the
History-Info header field along with the identity of the element that
performed the retargeting.
The requirement for integrity protection in REQ-13 could be met by
the use of an S/MIME signature over a subset of header fields, as
defined in "SIP Header Privacy and Integrity using S/MIME: Tunneling
SIP", <a href="./rfc3261#section-23.4">Section 23.4 of RFC 3261</a>. Note that the lack of deployment of
S/MIME with SIP means that, in general, REQ-13 is not met. The
requirement of REQ-14 for end-to-end privacy could be met using
S/MIME or using encryption at the application layer. Note that the
use of S/MIME to secure the UUI data will result in an additional
body being added to the request. Hop-wise Transport Layer Security
(TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] allows the header field to meet REQ-15 for hop-by-hop
security.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Normative Definition</span>
This document defines a new SIP header field "User-to-User" to
transport call control UUI data to meet the requirements in
[<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>].
To help tag and identify the UUI data used with this header field,
"purpose", "content", and "encoding" header field parameters are
defined. The "purpose" header field parameter identifies the package
that defines the generation and usage of the UUI data for a
particular application. The value of the "purpose" parameter is the
package name, as registered in the "UUI Packages" subregistry defined
in <a href="#section-6.3">Section 6.3</a>. For the case of interworking with the ISDN UUI
service, the ISDN UUI service interworking package is used. The
default value for the "purpose" header field is "isdn-uui" as defined
in [<a href="./rfc7434" title=""Interworking ISDN Call Control User Information with SIP"">RFC7434</a>]. If the "purpose" header field parameter is not
present, the ISDN UUI MUST be used. The "content" header field
parameter identifies the actual content of the UUI data. If not
present, the default content defined for the package MUST be used.
Newly defined UUI packages MUST define or reference at least a
default "content" value. The "encoding" header field parameter
indicates the method of encoding the information in the UUI data
associated with a particular "content" value. This specification
<span class="grey">Johnston & Rafferty Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
only defines "encoding=hex". If the "encoding" header field
parameter is not present, the default encoding defined for the
package MUST be used.
UUI data is considered an opaque series of octets. This mechanism
MUST NOT be used to convey a URL or URI, since the Call-Info header
field in [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] already supports this use case.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Syntax for UUI Header Field</span>
The UUI header field can be present in INVITE requests and responses
and in BYE requests and responses. Note that when the UUI header is
used in responses, it can only be utilized in end-to-end responses,
e.g., 1xx (excluding 100), 2xx, and 3xx responses.
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in <a href="./rfc5234">RFC 5234</a> and extends <a href="./rfc3261">RFC 3261</a> (where
token, quoted-string, and generic-param are defined).
UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value)
uui-value = uui-data *(SEMI uui-param)
uui-data = token / quoted-string
uui-param = pkg-param / cont-param / enc-param / generic-param
pkg-param = "purpose" EQUAL pkg-param-value
pkg-param-value = token
cont-param = "content" EQUAL cont-param-value
cont-param-value = token
enc-param = "encoding" EQUAL enc-param-value
enc-param-value = token / "hex"
Each package defines how many User-to-User header fields of each
package may be present in a request or a response. A sender MAY
include multiple User-to-User header fields, and a receiver MUST be
prepared to receive multiple User-to-User header fields. Consistent
with the rules of SIP syntax, the syntax defined in this document
allows any combination of individual User-to-User header fields or
User-to-User header fields with multiple comma separated UUI data
elements. Any size limitations on the UUI data for a particular
purpose are to be defined by the related UUI package.
UAs SHALL ignore UUI data from packages or encoding that they do not
understand.
For redirection use cases, the header field is included (escaped)
within the Contact URI. For referral use cases, the header field is
included (escaped) within the Refer-To URI. For example, if a UA
supports this specification, it SHOULD include any UUI data included
in a redirection URI (if the UUI data and encoding is understood).
<span class="grey">Johnston & Rafferty Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
Note that redirection can occur multiple times to a request.
Currently, UAs that support attended transfer support the ability to
include a Replaces header field [<a href="./rfc3891" title=""The Session Initiation Protocol (SIP) "">RFC3891</a>] into a Refer-To URI, and
when acting upon this URI, UAs add the Replaces header field to the
triggered INVITE. This sort of logic and behavior is utilized for
the UUI header field (that is, the UUI header field is included in
the triggered INVITE). The UA processing the REFER [<a href="./rfc3515" title=""The Session Initiation Protocol (SIP) Refer Method"">RFC3515</a>] or the
3xx response to the INVITE SHOULD support the UUI mechanism. If the
REFER or redirect target does not support UUI, the UUI header will be
discarded as per [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]. However, this may limit the utility of
use cases that depend upon the UUI being supported by all elements.
Here is an example of an included User-to-User header field from the
redirection response F2 of Figure 2 in [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>]:
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
content%3Dbar>
</allOneLine>
The resulting INVITE F4 would contain:
User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Hex Encoding Definition</span>
This specification defines hex encoding of UUI data. When the value
of "hex" is used in the "encoding" parameter of a header field, the
data is encoded using base16 encoding according to <a href="./rfc4648#section-8">Section 8 of
[RFC4648]</a>. The hex-encoded value is normally represented using the
"token" construction from <a href="./rfc3261">RFC 3261</a>, although the "quoted-string"
construction is permitted, in which case the quotes MUST be ignored.
If a canonicalized version of a normally case-insensitive hex encoded
UUI data object is needed for a digital signature or integrity
checking, then the base16 encoding with all upper case MUST be used.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Source Identity of UUI Data</span>
It is important for the recipient of UUI data to know the identity of
the UA that inserted the UUI data. In a request without a History-
Info header field, the identity of the entity that inserted the UUI
data will be assumed to be the source of the SIP message. For a SIP
request, typically this is the UA identified by the URI in the From
header field or a P-Asserted-Identity [<a href="./rfc3325" title=""Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks"">RFC3325</a>] header field. In a
request with a History-Info header field, the recipient needs to
parse the Targeted-to-URIs present (hi-targeted-to-uri defined in
<span class="grey">Johnston & Rafferty Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
[<a href="./rfc7044" title=""An Extension to the Session Initiation Protocol (SIP) for Request History Information"">RFC7044</a>]) to see if any included User-to-User header fields are
present. If an included User-to-User header field is present and
matches the UUI data in the request, this indicates that redirection
has taken place, resulting in the inclusion of UUI data in the
request. The inserter of the UUI data will be the UA identified by
the Targeted-to-URI of the History-Info element prior to the element
with the included UUI data. In a response, the inserter of the UUI
data will be the identity of the UA that generated the response.
Typically, this is the UA identified in the To header field of the
response. Note that any updates to this identity by use of the SIP
connected identity extension [<a href="./rfc4916" title=""Connected Identity in the Session Initiation Protocol (SIP)"">RFC4916</a>] or other identity modifiers
will update this information.
For an example of History-Info and redirection, consider Figure 2
from [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>] where the Originating UA is Carol, the Redirector Bob,
and the Terminating UA Alice. The INVITE F4 containing UUI data
could be:
INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061
;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com>
From: Carol <sips:carol@example.com>;tag=323sf33k2
Call-ID: dfaosidfoiwe83ifkdf
Max-Forwards: 70
Contact: <sips:carol@lab.example.com>
Supported: histinfo
User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1
<allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine>
Without the redirection captured in the History-Info header field,
Alice would conclude that the UUI data was inserted by Carol.
However, the History-Info containing UUI data (index=1.1) indicates
that the inserter was Bob (index=1).
To enable maintaining a record of the inserter identity of UUI data,
UAs supporting this mechanism SHOULD support History-Info [<a href="./rfc7044" title=""An Extension to the Session Initiation Protocol (SIP) for Request History Information"">RFC7044</a>]
and include Supported: histinfo in all requests and responses.
If a border element such as a proxy or a Back-to-Back User Agent
(B2BUA) removes a History-Info header field containing a User-to-User
parameter, the UA consuming the UUI data may not be able at the SIP
level to identify the source of the UUI data.
<span class="grey">Johnston & Rafferty Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Guidelines for UUI Packages</span>
UUI packages defined using this SIP UUI mechanism MUST follow the
"Standards Action" guideline as defined in [<a href="./rfc5226" title="">RFC5226</a>] and publish a
Standards Track RFC that describes the usage. The CUSS WG chose to
adopt this conservative policy while it considers other potential
registration policies. Note that this mechanism is not suitable for
the transport of arbitrary data between UAs. The following
guidelines are provided to help determine if this mechanism is
appropriate or not. The SIP UUI mechanism is applicable when all of
the following conditions are met:
1. The information is generated and consumed by an application
during session setup using SIP, but the application is not
necessarily SIP aware.
2. The behavior of SIP entities that support it is not significantly
changed (as discussed in <a href="./rfc5727#section-4">Section 4 of [RFC5727]</a>).
3. UAs are the generators and consumers of the UUI data. Proxies
and other intermediaries may route based on the presence of a
User-to-User header field or a particular package tag but do not
otherwise consume or generate the UUI data.
4. There are no privacy issues associated with the information being
transported (e.g., geolocation or emergency-related information
are examples of inappropriate UUI data).
5. The UUI data is not being utilized for User-to-User Remote
Procedure Calls (RPCs).
UUI packages define the semantics for a particular application usage
of UUI data. The content defines the syntax of the UUI data, while
the encoding defines the encoding of the UUI data for the content.
Each content is defined as a stream of octets, which allows multiple
encodings of that content. For example, packages may define:
1. The SIP methods and responses in which the UUI data may be
present.
2. The maximum number of UUI data elements that may be inserted into
a request or response. The default is one per encoding. Note
that a UA may still receive a request with more than this maximum
number due to redirection. The package needs to define how to
handle this situation.
<span class="grey">Johnston & Rafferty Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
3. The default values for content and encoding if they are not
present. If the same UUI data may be inserted multiple times
with different encodings, the package needs to state this. A
package may support and define multiple contents and their
associated encodings and reuse contents defined by other
packages.
4. Any size limitations on the UUI data. Size needs to be specified
in terms of the octet stream output of the content, since the
size of the resulting uui-data element will vary depending on the
encoding scheme.
A package MUST define a "purpose" header field value to identify the
package in the coding. A package MUST describe the new application
that is utilizing the UUI data and provide some use case examples.
The default "content" value MUST be defined or referenced in another
document for the package. Additional allowed contents MAY also be
defined or referenced. Any restrictions on the size of the UUI data
MUST be described. In addition, a package MAY define a media feature
tag per [<a href="./rfc3840" title=""Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"">RFC3840</a>] to indicate support for this UUI package. For
example, the media feature tag "sip.uui-pk1" could be defined to
indicate support for a UUI package named pk1. The definition of a
new SIP option tag solely to identify support for a UUI package is
NOT RECOMMENDED unless there are additional SIP behaviors needed to
implement this feature.
For an example UUI package definition, see [<a href="./rfc7434" title=""Interworking ISDN Call Control User Information with SIP"">RFC7434</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Extensibility</span>
New "content" values MUST describe the semantics of the UUI data and
valid encodings, and give some example use cases. A previously
defined UUI content value can be used in a new package. In this
case, the semantics and usage of the content by the new package is
defined within the new package. New UUI content types cannot be
added to existing packages -- instead, a new package would need to be
defined. New content values that are defined are added to the IANA
registry with a Standards Track RFC, which needs to discuss the
issues in this section. If no new encoding value is defined for a
content, the encoding defaults to "hex" as defined in this document.
In this case, the "hex" value will be explicitly stated via the
encoding parameter as the encoding for the content.
New "encoding" values associated with a new content MUST reference a
specific encoding scheme (such as "hex", which is defined in this
specification) or define the new encoding scheme. A previously
defined UUI encoding value can be used with a newly defined content.
In this case, the usage of the encoding is defined by the content
<span class="grey">Johnston & Rafferty Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
definition. New UUI encodings cannot be added to existing contents
-- instead, a new content would need to be defined. Newly defined
encoding values are added to the IANA registry with a Standards Track
RFC, which needs to discuss the issues in this section.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Registration of User-to-User Header Field</span>
This document defines a new SIP header field named "User-to-User".
The following row has been added to the "Header Fields" section of
the SIP parameter registry:
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [<a href="./rfc7433">RFC7433</a>] |
+------------------+--------------+-----------+
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Registration of User-to-User Header Field Parameters</span>
This document defines the parameters for the header field defined in
the preceding section. The header field "User-to-User" can contain
the parameters "encoding", "content", and "purpose".
The following rows have been added to the "Header Field Parameters
and Parameter Values" section of the SIP parameter registry:
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| User-to-User | encoding | Yes | [<a href="./rfc7433">RFC7433</a>] |
+------------------+----------------+-------------------+-----------+
| User-to-User | content | No | [<a href="./rfc7433">RFC7433</a>] |
+------------------+----------------+-------------------+-----------+
| User-to-User | purpose | No | [<a href="./rfc7433">RFC7433</a>] |
+------------------+----------------+-------------------+-----------+
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Registration of UUI Packages</span>
This specification establishes the "UUI Packages" subregistry under
<<a href="http://www.iana.org/assignments/sip-parameters">http://www.iana.org/assignments/sip-parameters</a>>.
The descriptive text for this subregistry is:
UUI packages provide information about the usage of the UUI data in a
User-to-User header field [<a href="./rfc7433">RFC7433</a>].
<span class="grey">Johnston & Rafferty Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
The registration policy for this registry is "Standards Action" as
defined in [<a href="./rfc5226" title="">RFC5226</a>].
+------------+------------------------------------------+-----------+
| Package | Description | Reference |
+------------+------------------------------------------+-----------+
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Registration of UUI Content Parameters</span>
This specification establishes the "UUI Content Parameters"
subregistry under <<a href="http://www.iana.org/assignments/sip-parameters">http://www.iana.org/assignments/sip-parameters</a>>.
The descriptive text for this subregistry is:
UUI content provides information about the content of the UUI data in
a User-to-User header field [<a href="./rfc7433">RFC7433</a>].
The registration policy for this registry is "Standards Action" as
defined in [<a href="./rfc5226" title="">RFC5226</a>].
+------------+------------------------------------------+-----------+
| Content | Description | Reference |
+------------+------------------------------------------+-----------+
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. Registration of UUI Encoding Parameters</span>
This specification establishes the "UUI Encoding Parameters"
subregistry under <<a href="http://www.iana.org/assignments/sip-parameters">http://www.iana.org/assignments/sip-parameters</a>>
and initiates its population with the table below.
The descriptive text for this subregistry is:
UUI encoding provides information about the encoding of the UUI data
in a User-to-User header field [<a href="./rfc7433">RFC7433</a>].
The registration policy for this registry is "Standards Action" as
defined in [<a href="./rfc5226" title="">RFC5226</a>].
+-----------+-------------------------------------------+-----------+
| Encoding | Description | Reference |
+-----------+-------------------------------------------+-----------+
| hex | The UUI data is encoded using hexadecimal | [<a href="./rfc7433">RFC7433</a>] |
+-----------+-------------------------------------------+-----------+
<span class="grey">Johnston & Rafferty Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Registration of SIP Option Tag</span>
This specification registers a new SIP option tag, as per the
guidelines in <a href="./rfc3261#section-27.1">Section 27.1 of [RFC3261]</a>.
This document defines the SIP option tag "uui".
The following row has been added to the "Option Tags" section of the
SIP Parameter Registry:
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| uui | This option tag is used to indicate that | [<a href="./rfc7433">RFC7433</a>] |
| | a UA supports and understands the | |
| | User-to-User header field. | |
+------------+------------------------------------------+-----------+
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
UUI data can potentially carry sensitive information that might
require confidentiality protection for privacy or integrity
protection from third parties that may wish to read or modify the UUI
data. The three security models described in [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>] may be
applicable for the UUI mechanism.
One model treats the SIP layer as untrusted and requires end-to-end
integrity protection and/or encryption. This model can be achieved
by providing these security services at a layer above SIP. In this
case, applications are encouraged to use their own integrity and/or
encryption mechanisms before passing it to the SIP layer.
The second approach is for the application to pass the UUI without
any protection to the SIP layer and require the SIP layer to provide
this security. This approach is possible in theory, although its
practical use would be extremely limited. To preserve multi-hop or
end-to-end confidentiality and integrity of UUI data, approaches
using S/MIME or IPsec can be used, as discussed in the review of
REQ-13 and REQ-14 in <a href="#section-3">Section 3</a> of this document. However, the lack
of deployment of these mechanisms means that applications cannot in
general rely on them being present.
The third model utilizes a trust domain and relies on perimeter
security at the SIP layer. This is the security model of the PSTN
and ISDN where UUI is commonly used today. This approach uses hop-
by-hop security mechanisms and relies on border elements for
<span class="grey">Johnston & Rafferty Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
filtering and application of policy. Standard deployed SIP security
mechanisms such as TLS transport offer privacy and integrity
protection properties on a hop-by-hop basis at the SIP layer.
If the UUI data was included by the UA originator of the SIP request
or response, normal SIP mechanisms can be used to determine the
identity of the inserter of the UUI data. If the UUI data was
included by a UA that was not the originator of the request, a
History-Info header field can be used to determine the identity of
the inserter of the UUI data. UAs can apply policy based on the
origin of the UUI data using this information. In short, the UUI
data included in an INVITE can be trusted as much as the INVITE
itself can be trusted.
Note that it is possible that this mechanism could be used as a
covert communication channel between UAs, conveying information
unknown to the SIP network.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.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 href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<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 href="http://www.rfc-editor.org/info/rfc3261">http://www.rfc-editor.org/info/rfc3261</a>>.
[<a id="ref-RFC3515">RFC3515</a>] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", <a href="./rfc3515">RFC 3515</a>, April 2003,
<<a href="http://www.rfc-editor.org/info/rfc3515">http://www.rfc-editor.org/info/rfc3515</a>>.
[<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 href="http://www.rfc-editor.org/info/rfc3840">http://www.rfc-editor.org/info/rfc3840</a>>.
[<a id="ref-RFC3891">RFC3891</a>] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", <a href="./rfc3891">RFC 3891</a>, September
2004, <<a href="http://www.rfc-editor.org/info/rfc3891">http://www.rfc-editor.org/info/rfc3891</a>>.
[<a id="ref-RFC4474">RFC4474</a>] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", <a href="./rfc4474">RFC 4474</a>, August 2006,
<<a href="http://www.rfc-editor.org/info/rfc4474">http://www.rfc-editor.org/info/rfc4474</a>>.
<span class="grey">Johnston & Rafferty Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
[<a id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", <a href="./rfc4648">RFC 4648</a>, October 2006,
<<a href="http://www.rfc-editor.org/info/rfc4648">http://www.rfc-editor.org/info/rfc4648</a>>.
[<a id="ref-RFC4916">RFC4916</a>] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", <a href="./rfc4916">RFC 4916</a>, June 2007,
<<a href="http://www.rfc-editor.org/info/rfc4916">http://www.rfc-editor.org/info/rfc4916</a>>.
[<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 href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>>.
[<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 href="http://www.rfc-editor.org/info/rfc5246">http://www.rfc-editor.org/info/rfc5246</a>>.
[<a id="ref-RFC7044">RFC7044</a>] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
C. Holmberg, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", <a href="./rfc7044">RFC 7044</a>,
February 2014, <<a href="http://www.rfc-editor.org/info/rfc7044">http://www.rfc-editor.org/info/rfc7044</a>>.
[<a id="ref-RFC7434">RFC7434</a>] Drage, K. and A. Johnston, "Interworking ISDN Call Control
User Information with SIP", <a href="./rfc7434">RFC 7434</a>, January 2015,
<<a href="http://www.rfc-editor.org/info/rfc7434">http://www.rfc-editor.org/info/rfc7434</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-Q1980">Q1980</a>] ITU-T, "The Narrowband Signalling Syntax (NSS) - Syntax
Definition", ITU-T Recommendation Q.1980.1,
<<a href="http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/q1980.1/q1980.1.html">http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/</a>
<a href="http://www.itu.int/itudoc/itu-t/aap/sg11aap/history/q1980.1/q1980.1.html">q1980.1/q1980.1.html</a>>.
[<a id="ref-Q763">Q763</a>] ITU-T, "Signalling System No. 7 - ISDN User Part formats
and codes", ITU-T Recommendation Q.763,
<<a href="http://www.itu.int/rec/T-REC-Q.763-199912-I/en">http://www.itu.int/rec/T-REC-Q.763-199912-I/en</a>>.
[<a id="ref-Q931">Q931</a>] ITU-T, "ISDN user-network interface layer 3 specification
for basic call control", ITU-T Recommendation Q.931,
<<a href="http://www.itu.int/rec/T-REC-Q.931-199805-I/en">http://www.itu.int/rec/T-REC-Q.931-199805-I/en</a>>.
[<a id="ref-RFC3325">RFC3325</a>] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", <a href="./rfc3325">RFC 3325</a>,
November 2002, <<a href="http://www.rfc-editor.org/info/rfc3325">http://www.rfc-editor.org/info/rfc3325</a>>.
<span class="grey">Johnston & Rafferty Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
[<a id="ref-RFC3372">RFC3372</a>] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures", <a href="https://www.rfc-editor.org/bcp/bcp63">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp63">63</a>, <a href="./rfc3372">RFC 3372</a>, September 2002,
<<a href="http://www.rfc-editor.org/info/rfc3372">http://www.rfc-editor.org/info/rfc3372</a>>.
[<a id="ref-RFC4475">RFC4475</a>] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", <a href="./rfc4475">RFC 4475</a>, May 2006,
<<a href="http://www.rfc-editor.org/info/rfc4475">http://www.rfc-editor.org/info/rfc4475</a>>.
[<a id="ref-RFC5727">RFC5727</a>] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", <a href="https://www.rfc-editor.org/bcp/bcp67">BCP 67</a>, <a href="./rfc5727">RFC</a>
<a href="./rfc5727">5727</a>, March 2010,
<<a href="http://www.rfc-editor.org/info/rfc5727">http://www.rfc-editor.org/info/rfc5727</a>>.
[<a id="ref-RFC6086">RFC6086</a>] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package
Framework", <a href="./rfc6086">RFC 6086</a>, January 2011,
<<a href="http://www.rfc-editor.org/info/rfc6086">http://www.rfc-editor.org/info/rfc6086</a>>.
[<a id="ref-RFC6567">RFC6567</a>] Johnston, A. and L. Liess, "Problem Statement and
Requirements for Transporting User-to-User Call Control
Information in SIP", <a href="./rfc6567">RFC 6567</a>, April 2012,
<<a href="http://www.rfc-editor.org/info/rfc6567">http://www.rfc-editor.org/info/rfc6567</a>>.
<span class="grey">Johnston & Rafferty Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Other Possible Mechanisms</span>
Two other possible mechanisms for transporting UUI data will be
described: MIME body and URI parameter transport.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Why INFO is Not Used</span>
Since the INFO method [<a href="./rfc6086" title=""Session Initiation Protocol (SIP) INFO Method and Package Framework"">RFC6086</a>] was developed for ISDN User Part
(ISUP) interworking of User-to-User Information, it might seem to be
the logical choice here. For non-call control User-to-User
Information, INFO can be utilized for end-to-end transport. However,
for transport of call control User-to-User Information, INFO can not
be used. As the call flows in [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>] show, the information is
related to an attempt to establish a session and needs to be passed
with the session setup request (INVITE), responses to that INVITE, or
session termination requests. As a result, it is not possible to use
INFO in these cases.
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Why Other Protocol Encapsulation UUI Mechanisms Are Not Used</span>
Other protocols have the ability to transport UUI data. For example,
consider the ITU-T Recommendation Q.931 User-user information element
[<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>] and the ITU-T Recommendation Q.763 User-to-User information
parameter [<a href="#ref-Q763" title=""Signalling System No. 7 - ISDN User Part formats and codes"">Q763</a>]. In addition, the Narrowband Signalling System
(NSS) [<a href="#ref-Q1980" title=""The Narrowband Signalling Syntax (NSS) - Syntax Definition"">Q1980</a>] is also able to transport UUI data. Should one of
these protocols be in use, and present in both User Agents, then
utilizing these other protocols to transport UUI data might be a
logical solution. Essentially, this is just adding an additional
layer in the protocol stack. In these cases, SIP is not transporting
the UUI data; it is encapsulating another protocol, and that protocol
is transporting the UUI data. Once a mechanism to transport that
other protocol using SIP exists, the UUI data transport function is
essentially obtained without any additional effort or work.
However, the CUSS working group believes, consistent with its
charter, that SIP needs to have its own native UUI data transport
mechanism. It is not reasonable for a SIP UA to have to implement
another entire protocol (either ISDN or NSS, for example) just to get
the very simple UUI data transport service. Of course, this work
does not preclude anyone from using other protocols with SIP to
transport UUI data.
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. MIME Body Approach</span>
One method of transport is to use a MIME body. This is in keeping
with the Session Initiation Protocol for Telephones (SIP-T)
architecture [<a href="./rfc3372" title=""Session Initiation Protocol for Telephones (SIP-T): Context and Architectures"">RFC3372</a>] in which MIME bodies are used to transport
ISUP information. Since the INVITE will normally have a Session
<span class="grey">Johnston & Rafferty Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
Description Protocol (SDP) message body, the resulting INVITE with
SDP and UUI data will be multipart MIME. This is not ideal as many
SIP UAs do not support multipart MIME INVITEs.
A bigger problem is the insertion of a UUI message body by a redirect
server or in a REFER. The body would need to be encoded in the
Contact URI of the 3xx response or the Refer-To URI of a REFER.
Currently, the authors are not aware of any UAs that support this
capability today for any body type. As such, the complete set of
semantics for this operation would need to be determined and defined.
Some issues will need to be resolved, such as, do all the Content-*
header fields have to be included as well? And, what if the included
Content-Length does not agree with the included body?
Since proxies cannot remove a body from a request or response, it is
not clear how this mechanism could meet REQ-9.
The requirement for integrity protection could be met by the use of
an S/MIME signature over the body, as defined in "Securing MIME
bodies", <a href="./rfc3261#section-23.3">Section 23.3 of RFC 3261</a>. Alternatively, this could be
achieved using [<a href="./rfc4474" title=""Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"">RFC4474</a>]. The requirement for end-to-end privacy
could be met using S/MIME encryption or using encryption at the
application layer. However, note that neither S/MIME or <a href="./rfc4474">RFC 4474</a>
enjoys deployment in SIP today.
An example:
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible,
although the authors do not have a specific mechanism to propose.
Meeting REQ-3 is problematic but not impossible for this mechanism.
However, this mechanism does not seem to be able to meet REQ-9.
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. URI Parameter</span>
Another proposed approach is to encode the UUI data as a URI
parameter. This UUI parameter could be included in a Request-URI or
in the Contact URI or Refer-To URI. It is not clear how it could be
transported in a response that does not have a Request-URI, or in BYE
requests or responses.
<span class="grey">Johnston & Rafferty Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7433">RFC 7433</a> SIP UUI for CC January 2015</span>
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT
6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
An INVITE sent to this Contact URI would contain UUI data in the
Request-URI of the INVITE. The URI parameter has a drawback in that
a URI parameter carried in a Request-URI will not survive retargeting
by a proxy as shown in Figure 2 of [<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>]. That is, if the URI is
included with an Address of Record instead of a Contact URI, the URI
parameter in the Request-URI will not be copied over to the Contact
URI, resulting in the loss of the information. Note that if this
same URI was present in a Refer-To header field, the same loss of
information would occur.
The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
REQ-11. It is possible the approach could meet REQ-12 and REQ-13.
The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
REQ-14.
Acknowledgments
Joanne McMillen was a major contributor and coauthor of earlier
versions of this document. Thanks to Paul Kyzivat for his
contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith
Drage, Vijay Gurbani, and Laura Liess for their review of the
document. The authors wish to thank Roland Jesske, Celine Serrut-
Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
Jennings, and Mahalingam Mani for their comments. Thanks to Scott
Kelly and Joel Halpern for their reviews.
Authors' Addresses
Alan Johnston
Avaya
St. Louis, MO 63124
United States
EMail: alan.b.johnston@gmail.com
James Rafferty
Human Communications
Norfolk, MA 02056
United States
EMail: jay@humancomm.com
Johnston & Rafferty Standards Track [Page 19]
</pre>
|
