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>Network Working Group V. Gurbani
Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent
Category: Standards Track C. Jennings
Cisco Systems
June 2007
<span class="h1">Representing Trunk Groups in tel/sip</span>
<span class="h1">Uniform Resource Identifiers (URIs)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a standardized mechanism to convey trunk
group parameters in sip and tel Uniform Resource Identifiers (URIs).
An extension to the tel URI is defined for this purpose.
<span class="grey">Gurbani & Jennings Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Table of Contents
<a href="#section-1">1</a>. Background . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Problem Statement . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Requirements and Rationale . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Trunk Group Namespace: Global or Local? . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Originating Trunk Group and Terminating Trunk Group . . . <a href="#page-6">6</a>
<a href="#section-4.4">4.4</a>. Intermediary Processing of Trunk Groups . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Trunk Group Identifier: ABNF and Examples . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Normative Behavior of SIP Entities Using Trunk Groups . . . . <a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. User Agent Client Behavior . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. User Agent Server Behavior . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.3">6.3</a>. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7.1">7.1</a>. Reference Architecture . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7.2">7.2</a>. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7.3">7.3</a>. Inter-Domain Call Flow . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. IANA considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-10">10</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Gurbani & Jennings Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Background</span>
Call routing in the Public Switched Telephone Network (PSTN) is
accomplished by routing calls over specific circuits (commonly
referred to as "trunks") between Time Division Multiplexed (TDM)
circuit switches. In switches, a group of trunks that connect to the
same target switch or network is called a "trunk group".
Consequently, trunk groups have labels, which are used as the main
indication for the previous and next TDM switch participating in
routing the call.
Formally, we define a trunk and trunk group and related terminology
as follows (definition of "trunk" and "trunk group" is from [<a href="#ref-5" title=""Telcordia Notes on the Network"">5</a>]).
Trunk: In a network, a communication path connecting two
switching systems used in the establishment of an end-to-end
connection. In selected applications, it may have both its
terminations in the same switching system.
Trunk Group: A set of trunks, traffic engineered as a unit, for
the establishment of connections within or between switching
systems in which all of the paths are interchangeable. A single
trunk group can be shared across multiple switches for redundancy
purposes.
Digital Signal 0 (DS0): Digital Signal X is a term for a series
of standard digital transmission rates based on DS0, a
transmission rate of 64 kbps (the bandwidth normally used for one
telephone voice channel). The European E-carrier system of
transmission also operates using the DS series as a base multiple.
Since the introduction of ubiquitous digital trunking, which resulted
in the allocation of DS0s between end offices in minimum groups of 24
(in North America), it has become common to refer to bundles of DS0s
as a trunk. Strictly speaking, however, a trunk is a single DS0
between two PSTN end offices; however, for the purposes of this
document, the PSTN interface of a gateway acts effectively as an end
office (i.e., if the gateway interfaces with Signaling System 7
(SS7), it has its own SS7 point code, and so on). A trunk group,
then, is a bundle of DS0s (that need not be numerically contiguous in
an SS7 Trunk Circuit Identification Code numbering scheme) that are
grouped under a common administrative policy for routing.
A Session Initiation Protocol (SIP) [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>] to PSTN gateway may have
trunks that are connected to different carriers. It is entirely
reasonable for a SIP proxy to choose -- based on factors not
enumerated in this document -- which carrier a call is sent to when
it proxies a session setup request to the gateway. Since multiple
<span class="grey">Gurbani & Jennings Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
carriers can transport a call to a particular phone number, the phone
number itself is not sufficient to identify the carrier at the
gateway. An additional piece of information in the form of a trunk
group can be used to further pare down the choices at the gateway.
As used in this document, trunks are necessarily tied to gateways,
and a proxy that uses trunk groups during routing of the request to a
particular gateway knows and controls which gateway the call will be
routed to, and knows what trunking resources are present on that
gateway.
As another example, consider the case where an IP network is being
used as a transit network between two PSTN networks. Here, a SIP
proxy can apply the originating trunk group to its routing logic to
ensure that the same ingress and egress carrier is chosen.
How the proxy picked a particular trunk group is outside the scope of
this document ([<a href="#ref-6" title=""A Telephony Gateway REgistration Protocol (TGREP)"">6</a>] provides one such way); however, once trunk group
has been decided upon, this document provides a standardized means to
represent it in the signaling messages.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Problem Statement</span>
Currently, there isn't any standardized manner of transporting trunk
groups between Internet signaling entities. This leads to ambiguity
on at least two fronts:
1. Positional ambiguity: A SIP proxy that wants to send a call to
an egress Voice over IP (VoIP) gateway may insert the trunk group
as a parameter in the user portion of the Request-URI (R-URI), or
it may insert it as a parameter to the R-URI itself. This
ambiguity persists in the reverse direction as well, that is,
when an ingress VoIP gateway wants to send an incoming call
notification to its default outbound proxy.
2. Semantic ambiguity: The lack of any standardized grammar to
represent trunk groups leads to the unfortunate choice of ad hoc
names and values.
VoIP routing entities in the Internet, such as SIP proxies, may be
interested in using trunk groups for normal operations. To that
extent, any standards-driven requirements will enable proxies from
one vendor to interoperate with gateways from yet another vendor.
Absent such guidelines, interoperability will suffer, as a proxy
vendor must conform to the expectations of a gateway as to where it
expects trunk group parameters to be present (and vice versa).
<span class="grey">Gurbani & Jennings Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
The aim of this specification is to outline how to structure and
represent the trunk group parameters as an extension to the tel URI
[<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>] in a standardized manner.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Requirements and Rationale</span>
This section captures the motivations for the design decisions for
the specification of a trunk group. These motivations are captured
as a set of requirements that are used to guide the eventual trunk
group specification in this document.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. sip URI or tel URI?</span>
REQ 1: Trunk group parameters must be defined as an extension to the
tel URI [<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>].
The trunk group parameters can be carried in either the sip URI or
the tel URI. Since trunk groups are intimately associated with the
PSTN, it seems reasonable to define them as extensions to the tel URI
(any SIP request that goes to a gateway could reasonably be expected
to have a tel URI, in whole or in part, in its R-URI anyway).
Furthermore, using the tel URI also allows this format to be reused
by non-SIP VoIP protocols (which could include anything from MGCP or
Megaco to H.323, if the proper information elements are created).
Finally, once the trunk group is defined for a tel URI, the normative
procedures of Section 19.1.6 of [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>] can be used to derive an
equivalent sip URI from a tel URI, complete with the trunk group
parameters.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Trunk Group Namespace: Global or Local?</span>
REQ 2: Inter-domain trunk group name collisions must be prevented.
Under normal operations, trunk groups are pertinent only within an
administrative domain (i.e., local scope). However, given that
inadvertent cross-domain trunk group name collisions may occur, it is
desirable to prevent them. The judicious use of namespaces is a
solution to this problem. Thus, it seems appropriate to scope the
trunk group through a namespace.
<span class="grey">Gurbani & Jennings Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Note: At first glance, it would appear that the use of the tel
URI's "phone-context" parameter provides a satisfactory means of
imposing a namespace on a trunk group. The "phone-context"
parameter identifies the scope of validity of a local telephone
number. And therein lies the problem. Semantically, a "phone-
context" tel URI parameter is applicable only to a local telephone
number and not a global one (i.e., one preceded by a '+'). Trunk
groups, on the other hand, may appear in local or global telephone
numbers. Thus, what is needed is a new parameter with equivalent
functionality of the "phone-context" parameter of the tel URI, but
one that is equally applicable to local and global telephone
numbers.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Originating Trunk Group and Terminating Trunk Group</span>
REQ 3: Originating trunk group and destination trunk group must be
able to appear separately and concurrently in a SIP message.
SIP routing entities can make informed routing decisions based on
either the originating or the terminating trunk groups. Thus, it is
required that both of these trunk groups be carried in SIP requests.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Intermediary Processing of Trunk Groups</span>
REQ 4: SIP network intermediaries (proxy servers and redirect
servers) should be able to add the destination trunk group attribute
to SIP sessions as a route is selected for a call.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Trunk Group Identifier: ABNF and Examples</span>
The Augmented Backus Naur Form [<a href="#ref-2" title=""Augmented BNF for Syntax Specifications: ABNF"">2</a>] syntax for a trunk group
identifier is given below and extends the "par" production rule of
the tel URI defined in [<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>]:
par = parameter / extension / isdn-subaddress / trunk-group /
trunk-context
trunk-group = ";tgrp=" trunk-group-label
trunk-context = ";trunk-context=" descriptor
trunk-group-label = 1*( unreserved / escaped /
trunk-group-unreserved )
trunk-group-unreserved = "/" / "&" / "+" / "$"
descriptor is defined in [<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>].
unreserved is defined in [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>] and [<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>].
escaped is defined in [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>].
<span class="grey">Gurbani & Jennings Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Trunk groups are identified by two parameters: "tgrp" and "trunk-
context"; both parameters MUST be present in a tel URI to identify a
trunk group. Collectively, these two parameters are called "trunk
group parameters" in this specification.
All implementations conforming to this specification MUST generate
both of these parameters when using trunk groups. If an
implementation receives a tel URI with only one of the "tgrp" or
"trunk-context" parameter, it MUST act as if there were not any trunk
group parameters present at all in that URI. Whether or not to
further process such an URI is up to the discretion of the
implementation; however, if a decision is made to process it, the
implementation MUST act as if there were not any trunk group
parameters present in the URI.
The "trunk-context" parameter imposes a namespace on the trunk group
by specifying a global number or any number of its leading digits
(e.g., +33), or a domain name. Syntactically, it is modeled after
the "phone-context" parameter of the tel URI [<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>], except that unlike
the "phone-context" parameter, the "trunk-context" parameter can
appear in either a local or global tel URI.
Semantically, the "trunk-context" parameter establishes a scope of
the trunk group specified in the "tgrp" parameter, i.e., whether it
is valid at a single gateway, a set of gateways, or an entire domain
managed by a service provider. The "trunk-context" can contain four
discrete value types:
1. The value in the "trunk-context" literally identifies a host (a
gateway), in which case, the trunk groups are scoped to the
specific host.
2. The value in the "trunk-context" is a subdomain (e.g.,
"north.example.com"), which identifies a subset of the gateways
in a domain across which the trunk groups are shared.
3. The value in the "trunk-context" is a service provider domain
(e.g., "example.com"), which identifies all gateways in the
specific domain.
4. The value in the "trunk-context" is a global number or any number
of its leading digits; this is useful for provider-wide scoping
and does not lend itself very well to specifying trunk groups
across a gateway or a set of gateways.
<span class="grey">Gurbani & Jennings Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
For equivalency purposes, two URIs containing trunk group parameters
are equivalent according to the base comparison rules of the URIs.
The base comparison rules of a tel URI are specified in Section 4 of
[<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>], and the base comparison rules of a sip URI are specified in
Section 19.1.4 of [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>].
Examples:
1. Trunk group in a local number, with a phone-context parameter
(line breaks added for readability):
tel:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com
Transforming this tel URI to a sip URI yields:
sip:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
2. Trunk group in a global number, with a domain name
trunk-context:
tel:+16305550100;tgrp=TG-1;trunk-context=example.com
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
3. Trunk group in a global number, with a number prefix trunk-
context:
tel:+16305550100;tgrp=TG-1;trunk-context=+1-630
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=+1-630@isp.example.net;user=phone
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Normative Behavior of SIP Entities Using Trunk Groups</span>
The terminating (or egress) trunk group parameters MUST be specified
in the R-URI. This is an indication from a SIP entity to the next
downstream entity that a specific terminating (or egress) trunk group
should be used.
<span class="grey">Gurbani & Jennings Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Note: This is consistent with using the R-URI as a routing
element; SIP routing entities may use the trunk group parameter in
the R-URI to make intelligent routing decisions. Furthermore,
this also satisfies REQ 4, since a SIP network intermediary can
modify the R-URI to include the trunk group parameters.
Conversely, the appearance of the trunk group parameters in the
Contact header URI signifies the trunk group over which the call
arrived on, i.e., the originating (or ingress) trunk group. Thus,
the originating (or ingress) trunk group MUST appear in the Contact
header of a SIP request.
The behavior described in this section effectively addresses REQ 3.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. User Agent Client Behavior</span>
A User Agent Client (UAC) initiating a call that uses trunk groups
and supports this specification MUST include the trunk group
parameters in the Contact header URI (a Contact URI MUST be a sip or
sips URI; thus, what appears in the Contact header is a SIP
translation of the tel URI, complete with the trunk group
parameters). The trunk group parameters in the Contact header
represent the originating trunk group. As a consequence of the
processing rules for the Contact header defined in <a href="./rfc3261">RFC 3261</a> [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>],
subsequent requests in the dialog towards this user agent will
contain this Contact URI in the R-URI. Note that the user part of
this URI, which contains the trunk group parameters, will be copied
as a consequence of this processing.
Note: Arguably, the originating trunk group can be part of the
From URI. However, semantically, the URI in a From header is an
abstract identifier that represents the resource thus identified
on a long-term basis. The presence of a trunk group, on the other
hand, signifies a binding that is valid for the duration of the
session only; a trunk group has no significance once the session
is over. Thus, the Contact URI is the best place to impart this
information since it has exactly those semantics.
If the UAC is aware of the routing topology, it MAY insert the
destination trunk group parameters in the R-URI of the request.
However, in most deployments, the UAC will use the services of a
proxy to further route the request, and it will be up to the proxy to
insert such parameters in the R-URI (see <a href="#section-6.3">Section 6.3</a>).
<span class="grey">Gurbani & Jennings Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. User Agent Server Behavior</span>
To the processing User Agent Server (UAS) associated with a gateway,
the trunk group parameters in the R-URI implies that it should use
the named trunk group for the outbound call. If a UAS supports trunk
groups, but finds that all the trunk circuit identification codes for
that particular trunk group are occupied, it MAY send a 603 Decline
final response.
If a UAS supports trunk groups but is not configured with the
particular trunk group identified in the R-URI, it SHOULD NOT use any
other trunk group other than the one specified in the parameters. In
such a case, it MAY reject the request with a 404 final response; or
if it makes a decision to process the request in any case, it MUST
disregard the values in the "trunk-context" and the "tgrp"
parameters.
If the receiver of a SIP request is not authoritatively responsible
for the value specified in the "trunk-context", it MUST treat the
value in the "tgrp" parameter as if it were not there. Whether or
not to process the request further is up to the discretion of the
processing entity; the request MAY be rejected with a 404 final
response. Alternatively, if a decision is made to process the
request further, the processing entity MUST disregard the values in
the "trunk-context" and the "tgrp" parameters since it is not
authoritatively responsible for the value specified in "trunk-
context".
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Proxy Behavior</span>
A proxy server receiving a request that contains the trunk group
parameter in the Contact header SHOULD NOT change these parameters as
the request traverses through it. Changing these parameters may have
adverse consequences, since the UAC that populated the parameters did
so on some authoritative knowledge that the proxy may not be privy
to. Instead, the proxy SHOULD pass the trunk group parameters in the
Contact header unchanged to the client transaction that the proxy
creates to send the request downstream.
A proxy that is aware of the routing topology and supports this
specification MAY insert destination trunk group parameters in the
R-URI if none are present (see Sections <a href="#section-7.1">7.1</a> and <a href="#section-7.2">7.2</a> for an example).
However, if destination trunk group parameters are already present in
the R-URI, the proxy SHOULD NOT change them unless it has further
authoritative information about the routing topology than the
upstream client did when it originally inserted the trunk group
parameters in the R-URI.
<span class="grey">Gurbani & Jennings Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Depending on the specific situation, it is perfectly reasonable
for a proxy not to insert the destination trunk group parameters
in the R-URI. Consider, for instance, a proxy that understands
the originating trunk group parameters and, in accordance with
local policy, uses these to route the request to a destination
other than a PSTN gateway.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Example Call Flows</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Reference Architecture</span>
Consider Figure 1, which depicts a SIP proxy in a routing
relationship with three gateways in its domain, GW1, GW2, and GW3.
Requests arrive at the SIP proxy through GW1. Gateways GW2 and GW3
are used as egress gateways from the domain. GW2 has two trunk
groups configured, TG2-1 and TG2-2. GW3 also has two trunk groups
configured, TG3-1 and TG2-2 (TG2-2 is shared between gateways GW2 and
GW3).
+-----+ TG2-1
| |--------> To
TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN
From ----->| | | SIP | | | |-------->
PSTN | GW1 |--->| Proxy |-----+ +-----+
----->| | +-------+ | +-----+ TG3-1
+-----+ | | |--------> To
+---->| GW3 | TG2-2 PSTN
| |-------->
+-----+
Reference Architecture
GW1 in Figure 1 is always cognizant of any requests that arrive over
trunk group TG1-1. If it wishes to propagate the ingress trunk group
to the proxy, it must arrange for the trunk group to appear in the
Contact header of the SIP request destined to the proxy. The proxy
will, in turn, propagate the ingress trunk group in the Contact
header further downstream.
The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is
assumed that the proxy has access to a routing table for GW2 and GW3
that includes the appropriate trunk groups to use when sending a call
to the PSTN (exactly how this table is constructed is out of scope
for this specification; [<a href="#ref-6" title=""A Telephony Gateway REgistration Protocol (TGREP)"">6</a>] is one way to do so, a manually created
and maintained routing table is another). When the proxy sends a
request to either of the egress gateways, and the gateway routing
<span class="grey">Gurbani & Jennings Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
table is so configured that a trunk group is required by the gateway,
the proxy must arrange for the trunk group to appear in the SIP R-URI
of the request destined to that gateway.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Basic Call Flow</span>
This example uses the reference architecture of Figure 1. Gateways
GW1, GW2, and GW3, and the SIP proxy are assumed to be owned by a
service provider whose domain is example.com.
GW1 SIP Proxy GW2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
... ... ...
| | | Send to PSTN
| | | --> and receive Answer
| | | Complete Message
-----------------------------------------
Call in progress
-----------------------------------------
| | |
| |<-----------F3---+
+<--------------+ |
... ... ...
Basic Call Flow
In the call flow below, certain headers and messages have been
omitted for brevity. In F1, GW1 receives a call setup request from
the PSTN over a certain trunk group. GW1 arranges for this trunk
group to appear in the Contact header of the request destined to the
SIP proxy.
F1:
INVITE sip:+16305550100@example.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
In F2, the SIP proxy translates the R-URI and adds a destination
trunk group to the R-URI. The request is then sent to GW2.
<span class="grey">Gurbani & Jennings Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
F2:
INVITE sip:+16305550100;tgrp=TG2-1;
trunk-context=example.com@gw2.example.com;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
Once the call is established, either end can tear the call down. For
illustrative purposes, F3 depicts GW2 tearing the call down. Note
that the Contact from F1, including the trunk group parameters, is
now the R-URI of the request. When GW1 gets this request, it can
associate the call with the appropriate trunk group to deallocate
resources.
F3:
BYE sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone SIP/2.0
Route: <sip:proxy.example.com;lr>
...
It is worth documenting the behavior when an incoming call from the
PSTN is received at a gateway without a calling party number.
Consider Figure 1, and assume that GW1 gets a call request from the
PSTN without a calling party number. This is not an uncommon case,
and may happen for a variety of reasons, including privacy and
interworking between different signaling protocols before the request
reached GW1. Under normal circumstances (i.e., instances where the
calling party number is present in signaling), GW1 would derive a sip
URI to insert into the Contact header. This sip URI will contain, as
its user portion, the calling party number from the incoming SS7
signaling information. The trunk group parameters then becomes part
of the user portion as discussed previously.
If a gateway receives an incoming call where the calling party number
is not available, it MUST create a tel URI containing a token that is
generated locally and has local significance to the gateway. Details
of generating such a token are implementation dependent; potential
candidates include the gateway line number or port number where the
call was accepted. This tel URI is subsequently converted to a sip
URI to be inserted in the Contact header of the SIP request going
downstream from the gateway.
<span class="grey">Gurbani & Jennings Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Note: The tel scheme does not allow for an empty URI; thus, the
global-number or local-number production rule of the tel URI [<a href="#ref-4" title=""The tel URI for Telephone Calls"">4</a>]
cannot contain an empty string. Consequently, the behavior in the
above paragraph is mandated for cases where the incoming SS7
signaling message does not contain a calling party number.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Inter-Domain Call Flow</span>
This example demonstrates the advantage of namespaces in trunk
groups. In the example flow below, GW1 and SIP Proxy 1 belong to the
example.com domain, and SIP Proxy 2 belongs to another domain,
example.net. A call arrives at GW1 (F1) and is routed to the
example.net domain. In the call flow below, certain headers and
messages have been omitted for brevity.
example.com example.net
/-------------------------\ /-----------\
GW1 SIP Proxy 1 SIP Proxy 2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
| | |
... ... ...
| +<--F3------------+
... ... ...
Inter-Domain Call Flow
F1:
INVITE sip:+16305550100@example.com;user=phone SIP/2.0
...
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
In F2, the SIP proxy executes its routing logic and re-targets the
R-URI to refer to a resource in example.net domain.
F2:
INVITE sip:+16305550100@example.net;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
<span class="grey">Gurbani & Jennings Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
In F3, the example.net domain sends a request in the backwards
direction. The example.net domain does not interpret the trunk group
parameters in the Contact header since they do not belong to that
domain. The Contact header, including the trunk group parameters, is
simply used as the R-URI in a subsequent request going towards the
example.com domain.
F3:
BYE sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone
Route: <sip:proxy.example.com;lr>
...
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The trunk group parameters are carried in R-URIs and Contact headers;
they are simply a modifier of an address. Any existing trust
relationship between the originator of a request and an intermediary
(or final recipient) that processes the request is not affected by
such a modifier.
Maliciously modifying a trunk group of a R-URI in transit may cause
the receiving entity (say, a gateway) to prefer one trunk over
another, thus leading to attacks that use resources not privy to the
call. For example, an attacker who knows the name of a toll-free
trunk on a gateway may modify the trunk group in the R-URI to
effectively receive free service, or he may modify the trunk group in
a R-URI to affect the flow of traffic across trunks. Similarly,
modifying the trunk group in a Contact header may cause the routing
intermediary to erroneously associate a call with a different source
than it would normally be associated with.
Although this specification imparts more information to the R-URI and
the Contact header in the form of trunk groups, the class of attacks
and possible protection mechanism are the same as that specified for
baseline SIP systems [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>]. The Security Session Initiation Protocol
Secure (SIPS) scheme and the resulting Transport Layer Security (TLS)
mechanism SHOULD be used to provide integrity protection, thereby
mitigating these attacks.
A question naturally arises: how does the receiver determine whether
the sender is authorized to use the resources represented by the
trunk group parameters? There are two cases to consider: intra-
domain signaling exchange as discussed in <a href="#section-7.2">Section 7.2</a>, and inter-
domain signaling exchange as discussed in <a href="#section-7.3">Section 7.3</a>.
<span class="grey">Gurbani & Jennings Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
In the intra-domain case, a proxy receiving trunk group parameters
from an upstream user agent (typically a gateway) should only accept
them using the SIPS URI scheme; furthermore, it should use HTTP
Digest to challenge and properly authorize the sender. A user agent
(or a gateway) receiving the trunk group parameters from a proxy will
not be able to challenge the proxy using HTTP Digest, but it should
examine the X.509 certificate of the proxy to determine whether the
proxy is authorized to insert the resources represented by the trunk
group parameters into the signaling flow.
In the inter-domain case, a receiving proxy may depend on the
identity stored in the X.509 certificate of the sending proxy to
determine whether the sender is authorized to insert the resources
represented by the trunk group parameters in the signaling message.
Because of these considerations, the trunk group parameters are only
applicable within a set of network nodes among which there is mutual
trust. If a node receives a call signaling request from an upstream
node that it does not trust, it SHOULD remove the trunk group
parameters.
The privacy information revealed with a trunk group does not
generally advertise much information about a particular (human) user.
It does, however, convey two pieces of potentially private
information that may be considered sensitive by carriers. First, it
may reveal how a carrier may be performing least-cost routing and
peering; and secondly, it does introduce an additional means for
network topology and information of a carrier. It is up to the
discretionary judgment of the carrier if it wants to include the
trunk group parameters and reveal potentially sensitive information
on its network topology. If confidentiality is desired, TLS SHOULD
be used to protect this information while in transit.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA considerations</span>
This specification does not require any IANA considerations.
The tel URI parameters introduced in this document are registered
with IANA through the tel URI parameter registry document [<a href="#ref-7" title=""The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry"">7</a>].
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
The authors would like to acknowledge the efforts of the participants
of the SIPPING and IPTEL working group, especially Jeroen van Bemmel,
Bryan Byerly, John Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon
Peterson, Mike Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg,
Dave Oran, Takuya Sawada, Tom Taylor, and Al Varney.
<span class="grey">Gurbani & Jennings Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Jon Peterson was also instrumental in the original formulation of
this work.
Alex Mayrhofer brought up the issue of lexicographic ordering of tel
URI parameters when it is converted to a sip or sips URI.
Ted Hardie, Sam Hartman, and Russ Housley took pains to ensure that
the text around URI comparisons and security considerations was as
unambiguous as possible.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc4234">RFC 4234</a>, October 2005.
[<a id="ref-3">3</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-4">4</a>] Schulzrinne, H., "The tel URI for Telephone Calls", <a href="./rfc3966">RFC 3966</a>,
December 2004.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-5">5</a>] "Telcordia Notes on the Network", Telcordia SR-2275, Issue 04,
October 2000, <<a href="http://telecom-info.telcordia.com">http://telecom-info.telcordia.com</a>>.
[<a id="ref-6">6</a>] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D.
Shah, "A Telephony Gateway REgistration Protocol (TGREP)", Work
in Progress, January 2007.
[<a id="ref-7">7</a>] Jennings, C. and V. Gurbani, "The Internet Assigned Number
Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
Registry", Work in Progress, December 2006.
<span class="grey">Gurbani & Jennings Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Authors' Addresses
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane
Rm 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/3
San Jose, CA 95134
USA
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
<span class="grey">Gurbani & Jennings Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4904">RFC 4904</a> Trunk Groups in tel/sip URIs June 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gurbani & Jennings Standards Track [Page 19]
</pre>
|
