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
|
<pre>Internet Engineering Task Force (IETF) K. Drage, Ed.
Request for Comments: 7434 Alcatel-Lucent
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
January 2015
<span class="h1">Interworking ISDN Call Control User Information with SIP</span>
Abstract
The motivation and use cases for interworking and transporting User-
to-User Information (UUI) from the ITU-T Digital Subscriber
Signalling System No. 1 (DSS1) User-user information element within
SIP are described in <a href="./rfc6567">RFC 6567</a>. As networks move to SIP, it is
important that applications requiring this data can continue to
function in SIP networks as well as have the ability to interwork
with this ISDN service for end-to-end transparency. This document
defines a usage (a new package called the ISDN UUI package) of the
User-to-User header field to enable interworking with this ISDN
service.
This document covers interworking with both public ISDN and private
ISDN capabilities, so the potential interworking with QSIG will also
be addressed.
The package is identified by the new value "isdn-uui" of the
"purpose" header field parameter.
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/rfc7434">http://www.rfc-editor.org/info/rfc7434</a>.
<span class="grey">Drage & Johnston Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI 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>. Summary of the ISDN User-to-User Service . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. The Service . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Impacts of the ISDN Service on SIP Operation . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Transition Away from ISDN . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. ISDN Usage of the User-to-User Header Field . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7">7</a>. UAC Requirements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. UAS Requirements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9">9</a>. UUI Contents . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-10">10</a>. Considerations for ISDN Interworking Gateways . . . . . . . . <a href="#page-12">12</a>
<a href="#section-11">11</a>. Coding Requirements . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-12">12</a>. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-13">13</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-14">14</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-15">15</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-15.1">15.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-15.2">15.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Drage & Johnston Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Overview</span>
This document describes a usage of the User-to-User header field
defined in [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>] to enable the transport of UUI in ISDN
interworking scenarios using SIP [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]. Specifically, this
document discusses the interworking of the following items, which are
call control related: ITU-T Recommendation Q.931 DSS1 User-user
information element [<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>], ITU-T Recommendation Q.957.1 DSS1 User-
to-User Signalling (UUS) supplementary service [<a href="#ref-Q957.1" title=""Digital subscriber Signalling System No. 1 - Stage 3 description for supplementary services using DSS 1; Stage 3 description for additional information transfer supplementary services using DSS 1: User-to-User Signalling (UUS)"">Q957.1</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. Today, UUI is widely used in the Public Switched Telephone
Network (PSTN) in contact centers and call centers that are
transitioning away from ISDN to SIP.
This usage is not limited to scenarios where interworking will occur.
Rather it describes a usage where interworking is possible if
interworking is met. That does not preclude its usage directly
between two SIP terminals.
<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", "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="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Summary of the ISDN User-to-User Service</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. The Service</span>
ISDN defines a number of related services. Firstly, there is a user
signalling bearer service that uses the information elements /
parameters in the signalling channel to carry the data and does not
establish a related circuit-switched connection. For DSS1, this is
specified in ITU-T Recommendation Q.931, Sections <a href="#section-3.3">3.3</a> and <a href="#section-7">7</a> of
[<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>]. Secondly, it defines a User-to-User Signalling (UUS)
supplementary service that uses the information elements / parameters
in the signalling channel to carry additional data but that is used
in conjunction with the establishment of a related circuit-switched
connection. This reuses the same information elements / parameters
as the user signalling bearer service, with the addition of other
signalling information, and for DSS1 this is specified in ITU-T
Recommendation Q.957.1 [<a href="#ref-Q957.1" title=""Digital subscriber Signalling System No. 1 - Stage 3 description for supplementary services using DSS 1; Stage 3 description for additional information transfer supplementary services using DSS 1: User-to-User Signalling (UUS)"">Q957.1</a>].
<span class="grey">Drage & Johnston Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
ISDN defines three variants of the UUS supplementary service as
follows:
UUS1: User-to-User Information exchanged during the setup and
clearing phases of a call by transporting DSS1 User-user
information elements within call control messages. This in itself
has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1
implicit, it is the presence of the user signalling data itself
that constitutes the request for the service. UUS1 explicit uses
additional supplementary service control information to control
the request and granting of the service, as in UUS2 and UUS3. As
a result, UUS1 explicit also allows the requester to additionally
specify whether the parallel circuit-switched connection should
proceed if the UUS1 service cannot be provided (preferred or
required);
UUS2: DSS1 User-user information elements exchanged from the
sender's point of view during call establishment, between the DSS1
ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION
messages; and
UUS3: DSS1 User-user information elements exchanged while a call is
in the Active state, within DSS1 USER INFORMATION messages.
The service is always requested by the calling user.
This document defines only the provision of the ISDN UUS1 implicit
supplementary service to interworking scenarios, this being the most
widely deployed and used of the various ISDN User-to-User services,
and is indeed the one that matches the requirements specified in
[<a href="./rfc6567" title=""Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP"">RFC6567</a>].
The above comes from the ISDN specifications defined for public
networks. There is a parallel set of ISDN specifications defined for
private networks (QSIG). These specifications do not define a UUS1
implicit supplementary service. However, implementation of such a
UUS1 implicit supplementary service for private networks can readily
be constructed in a proprietary fashion based on the specifications
for public networks, and evidence suggests that some vendors have
done so. On this basis, there is no reason why this package cannot
also be used to support interworking with such a private network
service, on the assumption that the constraints are exactly the same
as those for the public network.
<span class="grey">Drage & Johnston Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
The ISDN UUS1 service has the following additional characteristics as
to the data that can be transported:
The maximum number of octets of user information that can be
transported is 128 octets plus a protocol discriminator. It is
noted that some early ISDN implementations had a limitation of 32
octets, but it is understood that these are not currently
deployed. While this package does not prohibit longer data
fields, the mechanism at any interworking point discards data
elements that are too long to handle. The handled length can
normally be assumed to be 128 octets.
The content of the user information octets is described by a
single octet protocol discriminator (see Table 4-26 of ITU-T
Recommendation Q.931) [<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>]. That protocol discriminator may
describe the protocol used within the user data, the structure of
the user data, or leave it entirely open. Note that not all
values within the protocol discriminator necessarily make sense
for use in the ISDN User-to-User service, as the content is
aligned with the protocol discriminator that appears at the start
of all DSS1 messages (see Table 4-1 of ITU-T Recommendation Q.931)
[<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>]. The protocol discriminator value has no impact on the
interworking capability.
Only a single piece of UUI data can be transported in each
message.
The ISDN service works without encryption or integrity protection.
The user trusts the intermediate network elements, and therefore
the operator of those elements, not to modify the data and to
deliver all the data to the remote user. On a link-by-link basis,
message contents are protected at Layer 2 by standard cyclic
redundancy check mechanisms -- this allows loss on a link-level
basis to be detected but does not guard against fraudulent attacks
on the link itself. This does not prevent the use of additional
encryption or integrity protection within the UUI data itself,
although the limit on the size of the UUI data (protocol
discriminator plus 128 octets) will restrict this.
<span class="grey">Drage & Johnston Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Impacts of the ISDN Service on SIP Operation</span>
The ISDN service has the following impacts that need to be understood
within the SIP environment.
Call transfer: ISDN call transfer cancels all ISDN User-to-User
supplementary services. In the ISDN, if User-to-User data is
required after call transfer, then UUS3 has to be renegotiated,
which is not provided by this SIP extension. The impact of this
restriction on the SIP environment is that UUI header fields
cannot be exchanged in transactions clearing down the SIP dialog
after call transfer has occurred.
Conference: ISDN conferencing allows the user to still exchange
User-to-User data after the conference is created. As far as UUS1
is concerned, it is not permitted. The ISDN three-party
supplementary service is similar in many ways to conferencing but
is signalled using a different mechanism. This means that on
clearing, the controller using UUS1 implicit does have the choice
of sending data to either or both remote users. Because SIP
conferencing cannot completely emulate the ISDN three-party
supplementary service at the served user, UUS1 implicit is not
possible.
Diversion: When ISDN diversion occurs, any UUS1 User-to-User data is
sent to the forwarded-to-user (assuming that the call meets
requirements for providing the service -- this is impacted by the
explicit service only). If the type of diversion is such that the
call is also delivered to the forwarding user, they will also
receive any UUS1 User-to-User data.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Relation to SIP-T</span>
A method of transport of ISDN User-to-User data is to use SIP-T
[<a href="./rfc3372" title=""Session Initiation Protocol for Telephones (SIP-T): Context and Architectures"">RFC3372</a>] and transport the UUI information end-to-end (as part of an
ISUP message or QSIG message) as a MIME body. If the SIP-T method of
encapsulation of ISDN instead of interworking is used, this is a
reasonable mechanism and does not require any extensions to existing
SIP-T. However, if true ISDN interworking is being done, and
therefore SIP-T would not otherwise be used, this approach is not
reasonable because then implementation of the many elements of the
ISUP syntax would be required to understand one element of data.
Instead, the better approach is to interwork the ISDN User-to-User
data using the native SIP UUI transport mechanism, the User-to-User
header field. The rest of this document describes this approach.
<span class="grey">Drage & Johnston Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Transition Away from ISDN</span>
This interworking usage of the SIP UUI mechanism will likely begin
with one UA as an ISDN gateway while the other UA is a native SIP
endpoint. As networks transition away from ISDN, it is possible that
both UAs could become native SIP endpoints. In this case, there is
an opportunity to transition away from this ISDN usage to a more
general usage of [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>].
The SIP UUI mechanism provides a way to achieve this transition. As
an endpoint moves from being an ISDN gateway to a native SIP
endpoint, and a future package for some form of enhanced UUI has been
standardized, the endpoint can carry the UUI data both as ISDN and as
the future package in parallel and in the same messages or in
different messages depending on the needs of the application. This
will permit the other endpoint to use the UUI according to the ISDN
UUI package if it is an ISDN gateway or according to the future
package if it is a native SIP endpoint.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. ISDN Usage of the User-to-User Header Field</span>
This document defines the package for the ISDN interworking of UUI
that interoperates with ISDN UUS, a supplementary service in which
the user is able to send/receive a limited amount of information to/
from another ISDN user over the signalling channel in association
with a call to the other ISDN user.
Two examples of ISDN UUI with redirection (transfer and diversion)
are defined in [<a href="#ref-ANSII" title=""Integrated Services Digital Network (ISDN) - Explicit Call Transfer Supplementary Service"">ANSII</a>] and [<a href="#ref-ETSI" title=""Integrated Services Digital Network (ISDN); Diversion supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification"">ETSI</a>].
One objective of the design of this package has been to keep the
functionality at the interworking point as simple as possible. As a
result, there is also only one encoding value specified.
Responsibility for respecting the limits has been transferred to the
end UA. If an interworking point is reached, and the limitations of
the ISDN (see <a href="#section-3.1">Section 3.1</a>) are not met, then the UUI data will not be
transferred, although the SIP request will otherwise be interworked.
This is rather than have the interworking point attempt to resolve
the non-compliance with the limitations of ISDN.
The general principals of the UUI mechanism package are, therefore,
as follows:
The sending application is expected to limit their sending
requirements to the subset provided by the ISDN User-to-User
service.
<span class="grey">Drage & Johnston Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
The SIP UA will not allow the reception of more than one
User-to-User header field relating to the "isdn-uui" package in
the same SIP request or response; it will only allow it in a
request or response of the appropriate method (INVITE or BYE).
What happens to User-to-User header fields relating to other
packages is outside the scope of this document.
An interworking point trying to interwork UUI data that is too
long will discard the UUI data but proceed with the interworking.
There is no notification of such discard back to the sending user.
If the SIP user knows that it is interworking with the ISDN, then
the UUI application at the SIP endpoint should limit its
communication to packets of 128 octets plus the protocol
discriminator, with the knowledge that discard will occur if it
does not. The UUI application at the SIP endpoint has complete
control over what occurs. It should be noted that this was
exactly the envisaged operation when early ISDN implementations
that only supported 32 octets interworked with those supporting
128 octets. It also corresponds to the interworking with ISDNs
that do not support the supplementary service at all, as discard
will occur in these circumstances as well. Note that failure to
include the User-to-User data into the ISDN SETUP message (when
discard occurs) will result in the service being unavailable for
the remainder of the call when UUS1 implicit operation is used.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. UAC Requirements</span>
The User Agent Client (UAC) MUST meet the requirements of [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>]
in addition to the requirements defined in this document.
The UAC MUST only use this UUI mechanism extension package in
association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with
any other type of dialog, or on methods not associated with a dialog,
is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded.
If the UAC wishes to use or permit the sending of UUI data at any
point in the dialog, the UAC MUST include in the INVITE request for
that dialog a User-to-User header field. The UAC SHOULD set the
"purpose" header field parameter to "isdn-uui". Non-inclusion of the
"purpose" header field parameter is permitted, but this is primarily
to allow earlier implementations to support this package. This
initial header field constitutes the implicit request to use the UUI
service and is, therefore, included even when there is no data except
the protocol discriminator octet to send at that point in time.
<span class="grey">Drage & Johnston Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
The UAC MUST NOT include the User-to-User header field with a
"purpose" header field parameter set to "isdn-uui", or with no
"purpose" header field parameter, in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to
"isdn-uui" or with no "purpose" header field parameter included.
When sending UUI for the ISDN UUI package, if the "purpose" header
field is included, the UAC MUST set the User-to-User "purpose" header
field parameter to "isdn-uui". The UAC MUST NOT include more than
one User-to-User header field for this package in any SIP request or
response.
When receiving UUI, when multiple User-to-User header fields are
received in the same response with the "purpose" header field
parameter set to "isdn-uui", or with no "purpose" header field
parameter, or with some combination of these, the UAC MUST discard
all these header fields. There are no mechanisms for determining
which ones are the intended UUI data, so all are discarded.
The application designer will need to take into account the ISDN
service restrictions; failure to do so can result in information
being discarded at any interworking point with the ISDN. This
document makes no further normative requirements based on those
constraints because those constraints may vary from one ISDN to
another. It is reasonable to expect that a limitation of 128 octets
(plus a protocol discriminator) can be imposed by the ISDN;
therefore, UUI data longer than this will never reach the destination
if such interworking occurs. Note that the 128-octet limit (plus a
protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in
[<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>].
A "uui" option tag for use with the UUI mechanism extension is
defined in [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>]. Because the service is UUS1 implicit for the
ISDN User-to-User service, the inclusion of the "uui" option tag in a
Supported header field conveys no additional information over and
above the presence, in the INVITE request, of the User-to-User header
field with the "purpose" header field parameter set to "isdn-uui".
While there is no harm in including the "uui" option tag, and
strictly it should be included if the extension is supported, it
performs no function. The presence of the "uui" option tag in the
Require header field of an INVITE request will cause the request to
fail if it reaches a UAS or ISDN interworking gateway that does not
support this extension; such usage is allowed but will produce
results that are inconsistent with the mechanisms defined in the ISDN
UUS supplementary service.
<span class="grey">Drage & Johnston Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. UAS Requirements</span>
The UAS MUST meet the requirements of [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>] in addition to the
requirements defined in this document.
The UAS MUST only use this UUI mechanism extension package in
association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with
any other type of dialog, or on methods not associated with a dialog,
is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded.
The UAS MUST NOT include the User-to-User header field with a
"purpose" header field parameter set to "isdn-uui", or with no
"purpose" header field parameter, in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User
header field, either with a "purpose" header field parameter set to
"isdn-uui" or with no "purpose" header field parameter included.
The UAS MAY include the User-to-User header field in responses to the
initial INVITE request, or the BYE requests or responses for the
dialog, only where the original INVITE request included a
User-to-User header field with the "purpose" header field parameter
set to "isdn-uui" or where no "purpose" header field parameter was
included. When sending UUI for the ISDN UUI package, the UAS SHOULD
set the User-to-User "purpose" header field parameter to "isdn-uui".
Non-inclusion of the "purpose" header field parameter is permitted,
but this is primarily to allow earlier implementations to support
this package.
When sending UUI for the ISDN UUI package, if the "purpose" header
field is included, the UAS MUST set the User-to-User "purpose" header
field parameter to "isdn-uui". The UAS MUST NOT include more than
one User-to-User header field for this package in any SIP request or
response.
The "isdn-interwork" value for the "purpose" header field parameter
was used in documents that led to the publication of the present
document. Although these documents had no other status than "Work in
Progress", this value is implemented by some vendors. While not
defined by this document, implementations could find it useful for
interoperability purposes to support parsing and interpreting
"isdn-interwork" the same way as "isdn-uui" when receiving messages.
Where the UAS is acting as a redirect server, the UAS MUST NOT
include the User-to-User header field in the header URI parameter in
a 3xx response to an incoming request.
<span class="grey">Drage & Johnston Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
When receiving UUI, when a User-to-User header field is received in a
request that is not from the originating user with the "purpose"
header field parameter set to "isdn-uui", or with no "purpose" header
field parameter, the UAS MUST discard this header field.
When receiving UUI, when multiple User-to-User header fields are
received from the originating user in the same request with the
"purpose" header field parameter set to "isdn-uui", or with no
"purpose" header field parameter, or with some combination of these,
the UAS MUST discard all these header fields. There are no
mechanisms for determining which ones are the intended UUI data, so
all are discarded.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. UUI Contents</span>
These requirements apply when the "purpose" header field parameter is
set to "isdn-uui" or when there is no "purpose" header field
parameter.
Processing for User-to-User header fields sent or received with
values other than this value are outside the scope of this document,
and the appropriate package document for that value applies.
The default and only content defined for this package is "isdn-uui".
When sending UUI, the sending SIP entity MAY, but need not, include a
"content" header field with a value set to "isdn-uui". A receiving
SIP entity MUST ignore a received User-to-User header field if the
"content" header field parameter is present and the value is some
other value than "isdn-uui".
The default and only encoding defined for this package is "hex".
When sending UUI, the sending SIP entity MAY, but need not, include
an "encoding" header field with a value set to "hex". A receiving
SIP entity MUST ignore a received User-to-User header field if the
"encoding" header field parameter is present and the value is some
other value than "hex".
When sending UUI, the sending application MUST include a protocol
discriminator octet, conforming to Table 4-26 of ITU-T Recommendation
Q.931 [<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>], as the first octet of the UUI data. It is up to the
receiving application what it does with this value. This document
places no other normative requirement on the use of the protocol
discriminator; it is required at interworking gateways to allow
mapping into the appropriate fields in the ISDN protocols; otherwise,
the usage is entirely up to the application and is outside the scope
of this document. Valid values are identified and documented by
ITU-T, and there is no IANA registry for these values.
<span class="grey">Drage & Johnston Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Considerations for ISDN Interworking Gateways</span>
ISDN interworking gateways MUST support the requirements defined for
UAS and UAC operation.
ISDN interworking gateways MUST support only the "isdn-uui" package
on dialogs that are interworked.
ISDN interworking gateways will take octet-structured data from the
ISDN side and encode it using the "hex" encoding scheme defined in
[<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>] for inclusion as the UUI data in the User-to-User header
field. In the reverse direction, it will take valid UUI data
according to the "hex" encoding scheme and decode it to octet-
structured data to send to the ISDN side.
When mapping data content from the ISDN to SIP signalling, or from
SIP signalling to the ISDN, the gateway needs to assume that all
content is octet-structured binary, irrespective of the value of the
received protocol discriminator. There are no requirements in the
ISDN to ensure that the content matches the value of the protocol
discriminator; the application usage sorts out any discrepancy. The
same applies to the ISDN protocol discriminator as the first octet of
the UUI data, as defined in Table 4-26 of ITU-T Recommendation Q.931
[<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>]; the interworking gateway will not perform any additional
checking of this value.
A "uui" option tag for use with the UUI mechanism extension is
defined in [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>]. The option tag is not interworked at an ISDN
interworking gateway. The ISDN interworking gateways MUST NOT take
the omission of the "uui" option tag in a received INVITE request to
indicate that interworking of a received header field is not to be
performed.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Coding Requirements</span>
This document defines "isdn-uui" as a new value of the User-to-User
"purpose" header field parameter. The following ABNF adds to the
production in [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>]:
pkg-param-value =/ "isdn-uui"
This document defines "isdn-uui" as a new value of the User-to-User
"content" header field parameter. A content value of "isdn-uui"
indicates that the contents have a first octet that is a protocol
discriminator (see Table 4-26 of ITU-T Recommendation Q.931 [<a href="#ref-Q931" title=""ISDN user-network interface layer 3 specification for basic call control"">Q931</a>])
followed by UUI data that can be subject to a length limitation
(before encoding or after decoding) that is generally 128 octets.
<span class="grey">Drage & Johnston Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
The following ABNF adds to the production in [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>].
cont-param-value =/ "isdn-uui"
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Media Feature Tag</span>
This document defines the new media feature tag "sip.uui-isdn". This
feature tag indicates that this ISDN UUI package is supported by the
sender, and its usage is entirely in accordance with [<a href="./rfc3840" title=""Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"">RFC3840</a>]. This
document makes no additional provisions for the use of this feature
tag.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. IANA Considerations</span>
Per this document, the following row has been added to the "UUI
Packages" subregistry of the SIP parameter registry:
Value: isdn-uui
Description: The associated application is being used with
constraints suitable for interworking with the ISDN User-to-User
service, and therefore can be interworked at ISDN gateways.
Reference: <a href="./rfc7434">RFC 7434</a>
Per this document, the following row has been added to the "UUI
Content" subregistry of the SIP parameter registry:
Value: isdn-uui
Description: The associated contents conform to the content
associated with the ISDN User-to-User service. In the presence of
the "purpose" header field parameter set to "isdn-uui" (or the
absence of any "purpose" header field parameter), this is the
default meaning and therefore need not be included in this case.
Reference: <a href="./rfc7434">RFC 7434</a>
This document defines the following media feature tag, which has been
added to the features.sip-tree of the Media feature tags registry:
Media feature tag name: sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x
<span class="grey">Drage & Johnston Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
Summary of the media feature indicated by this tag: This media
feature tag when used in a Contact header field of a SIP request
or a SIP response indicates that the entity sending the SIP
message supports the package "uui-isdn".
Values appropriate for use with this feature tag: none
Examples of typical use: Indicating that a mobile phone supports
Single Radio Voice call Continuity (SRVCC) for calls in the
alerting phase.
Related standards or documents: <a href="./rfc7434">RFC 7434</a>
Security Considerations: Security considerations for this media
feature tag are discussed in <a href="./rfc3840#section-11.1">Section 11.1 of [RFC3840]</a>
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Security Considerations</span>
This document contains no specific requirements in regard to security
over and above those specified in [<a href="./rfc7433" title=""A Mechanism for Transporting User-to-User Call Control Information in SIP"">RFC7433</a>]. However, since this
capability is designed to interwork with the ISDN, the general
security considerations of SIP to ISDN User Part (ISUP) interworking
defined in [<a href="./rfc3398" title=""Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping"">RFC3398</a>] apply. Any SIP/PSTN gateway implementing the
ISDN User-to-User service should not blindly trust ISUP from the
PSTN. In general, the overlying use case will define the security
measures required. The underlying User-to-User header field
extension provides a number of tools that can meet certain security
requirements.
Information that might otherwise reveal private information about an
individual, or where a level of authenticity needs to be guaranteed,
may need a higher level of protection and may indeed not be suitable
for this package, particularly taking into account the statement in
the following paragraph.
As this capability is defined to interwork with the ISDN, if the ISDN
forms part of the route, any usage needs to be aware that the
security level of the ISDN service may be lower than the security of
the SIP service. The ISDN security is itself not definable on an
end-to-end basis and exists on a hop-by-hop basis. This can be high
in some places (e.g., it can require physical access to a secure
building) and in other places it can be low (e.g., the point where an
ISDN access enters a building). If this level of security is not
sufficient, then either a different package or indeed a different
method of data transfer needs to be selected by the application user.
<span class="grey">Drage & Johnston Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>. References</span>
<span class="h3"><a class="selflink" id="section-15.1" href="#section-15.1">15.1</a>. Normative References</span>
[<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-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-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-RFC3398">RFC3398</a>] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
"Integrated Services Digital Network (ISDN) User Part
(ISUP) to Session Initiation Protocol (SIP) Mapping", <a href="./rfc3398">RFC</a>
<a href="./rfc3398">3398</a>, December 2002,
<<a href="http://www.rfc-editor.org/info/rfc3398">http://www.rfc-editor.org/info/rfc3398</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-RFC7433">RFC7433</a>] Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User-to-User Call Control Information in
SIP", <a href="./rfc7433">RFC 7433</a>, December 2014,
<<a href="http://www.rfc-editor.org/info/rfc7433">http://www.rfc-editor.org/info/rfc7433</a>>.
<span class="grey">Drage & Johnston Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
<span class="h3"><a class="selflink" id="section-15.2" href="#section-15.2">15.2</a>. Informative References</span>
[<a id="ref-ANSII">ANSII</a>] ANSI, "Integrated Services Digital Network (ISDN) -
Explicit Call Transfer Supplementary Service", ANSI-
T1.643A - SUP A, December 1996.
[<a id="ref-ETSI">ETSI</a>] ETSI, "Integrated Services Digital Network (ISDN);
Diversion supplementary services; Digital Subscriber
Signalling System No. one (DSS1) protocol; Part 1:
Protocol specification", ETSI ETS 300 207-1, Ed. 1,
December 1994.
[<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-Q957.1">Q957.1</a>] ITU-T, "Digital subscriber Signalling System No. 1 - Stage
3 description for supplementary services using DSS 1;
Stage 3 description for additional information transfer
supplementary services using DSS 1: User-to-User
Signalling (UUS)", ITU-T Recommendation Q.957.1,
<<a href="http://www.itu.int/rec/T-REC-Q.957.1-199607-I">http://www.itu.int/rec/T-REC-Q.957.1-199607-I</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">Drage & Johnston Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7434">RFC 7434</a> ISDN Call Control UUI January 2015</span>
Acknowledgments
Joanne McMillen was a major contributor and coauthor of earlier
versions of this document.
Thanks to Spencer Dawkins, Vijay Gurbani, Laura Liess, and Roland
Jesske for their reviews of this document. The authors wish to thank
Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings,
Mahalingam Mani, and Celine Serrut-Valette for their comments.
The death of Francois Audet occurred before this document was
finalized, and the authors would like to identify the significant
contribution of Francois to this and a number of important RFCs and
to express their condolences to his family. It was always a pleasure
to work with Francois.
Authors' Addresses
Keith Drage (editor)
Alcatel-Lucent
Quadrant, Stonehill Green, Westlea
Swindon
United Kingdom
EMail: keith.drage@alcatel-lucent.com
Alan Johnston
Avaya
St. Louis, MO
United States
EMail: alan.b.johnston@gmail.com
Drage & Johnston Standards Track [Page 17]
</pre>
|
