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
|
<pre>Network Working Group M. Munakata
Request for Comments: 4715 S. Schubert
Category: Informational T. Ohba
NTT
November 2006
<span class="h1">The Integrated Services Digital Network (ISDN)</span>
<span class="h1">Subaddress Encoding Type for tel URI</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
Without a tel URI parameter to carry an encoding type of Integrated
Services Digital Network (ISDN) subaddress, interworking between ISDN
User Part (ISUP) network and a Session Initiation Protocol (SIP)
network is impossible in some cases. To solve this problem, this
document specifies a new optional tel URI parameter to carry the
encoding type of ISDN subaddress.
<span class="grey">Munakata, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Problem Statement ...............................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. SIP-ISDN Interconnection ...................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. ISDN-SIP-ISDN Interconnection ..............................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Requirements ....................................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Parameter Definition ............................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Usage ...........................................................<a href="#page-6">6</a>
<a href="#section-6.1">6.1</a>. Gateway Behavior ...........................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. SIP Entity Behavior ........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-8">8</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-9">9</a>. Acknowledgements ................................................<a href="#page-9">9</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>] defines a tel URI parameter "isub" that is designed to
carry Integrated Services Digital Network (ISDN) subaddresses.
In an ISDN User Part (ISUP) message, a Network Service Access Point
(NSAP) address [<a href="#ref-6" title=""Information technology - Open Systems Interconnection - Network service definition"">6</a>] or a "user specified" address can be carried as an
ISDN subaddress. The NSAP address accommodates various types of
address information along with an identifier for the address type and
its encoding type.
The "isub" parameter can carry any type of address, but <a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>]
does not define a solution to carry information on a subaddress type
(whether the subaddress is NSAP or user specific) or an identifier
for the encoding type used.
The most commonly used encoding type for the ISDN subaddress is an
International Alphabet 5 (IA5) [<a href="#ref-5" title=""International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information interchange"">5</a>]. <a href="./rfc3966">RFC 3966</a> does state, "ISDN
subaddresses typically contain IA5 characters but may contain any
octet value" considering this fact. Nevertheless, IA5 is just one of
the encoding types among various encoding types used in the NSAP
address. Therefore, "isub" parameter alone is not sufficient to
describe ISDN subaddresses, and additional information is needed.
<span class="grey">Munakata, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
Lack of information describing the encoding type of ISDN
subaddress will make it difficult for an ISDN terminal receiving
the ISDN subaddress from the SIP network (SIP-ISDN
Interconnection) to interpret the "isub" parameter value, as a
gateway may translate it using a wrong encoding type and end up
with a wrong subaddress value due to inconsistency in the encoding
type used. It will also make it difficult to recover the original
ISDN subaddress value when an ISUP message is translated to a SIP
message and translated back to the ISUP message (ISDN-SIP-ISDN
Interconnection). As there is no placeholder to carry the
encoding type in the SIP message, the encoding type information
that was present in the original ISUP message will be lost, and
reconstructing the intended ISDN subaddress value is nearly
impossible.
To solve the issues presented, this specification defines an "isub-
encoding" parameter to carry information describing whether the value
of the "isub" parameter is an NSAP address as well as its encoding
type. In addition, this document specifies the accommodating values
to be carried in the "isub" parameter for each encoding type used.
<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">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-3" href="#section-3">3</a>. Problem Statement</span>
Without a tel URI parameter to carry an encoding type of ISDN
subaddress, the problems described in Sections <a href="#section-3.1">3.1</a>. and 3.2. might be
observed.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. SIP-ISDN Interconnection</span>
The diagrams in Figure 1 show an issue that will be observed when
interworking between SIP network and ISDN network with an ISDN
subaddress. When SIP equipment sends a request with an "isub"
parameter to address an ISDN terminal behind Private Branch Exchange
(PBX), the encoding type of the ISDN subaddress currently cannot be
specified. Therefore, gateway sitting between the SIP network and
ISDN network cannot translate the value of "isub" into an ISUP
Initial Address Message (IAM) properly as the encoding type
information of the ISDN subaddress is missing.
<span class="grey">Munakata, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
ISDN Terminal
+-----+
|--->| Bob |
SIP Network <---|---> ISDN | |12345|
| +-----+
SIP Equipment |
+-----+ +-----+ +----+ +-----+ | +-----+
|Alice|------->|Proxy|----->| GW |----->| PBX |----->|Carol|
+-----+ +-----+ +----+ +-----+ | +-----+
|
| +-----+
|--->|David|
+-----+
Alice Proxy GW Switch PBX Bob
| | | | | |
| INVITE | | | | |
|------------>| INVITE | | | |
| |------------>| IAM | | |
| | |----->|SETUP| |
| | | |---->| SETUP |
| | | | |---------->|
| | | | | |
Figure 1: SIP-ISDN Interconnection
INVITE tel:+17005554141;isub=12345 SIP/2.0
Note: SETUP is an ISDN message used between ISDN switch and
ISDN end terminal.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. ISDN-SIP-ISDN Interconnection</span>
The diagrams in Figure 2 show an issue that will be observed when
interworking messages with an ISDN subaddress between two ISDN
networks that traverses through SIP networks. When an ISDN terminal
sends a message that contains an ISDN subaddress along with its
encoding type information, Gateway 1 translates the subaddress into
an "isub" parameter in a SIP message. However, its encoding type
information is dropped because there is no placeholder for the
encoding type in the SIP message. When Gateway 2 receives the
"isub", it cannot translate the value of the "isub" parameter back
into the IAM message properly because the encoding type information
of the ISDN subaddress is missing.
<span class="grey">Munakata, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
ISDN Terminal
+-----+
|--->| Bob |
ISDN <---|---> SIP Network <---|---> ISDN | |12345|
| +-----+
ISDN Terminal |
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
|Alice|----->| GW1 |---->|Proxy|---->| GW2 |---->| PBX |----->|Carol|
+-----+ +-----+ +-----+ +-----+ +-----+ | +-----+
|
| +-----+
|--->|David|
+-----+
Alice Switch GW1 Proxy GW2 Switch PBX Bob
| | | | | | | |
| SETUP | | | | | | |
|------>| IAM | | | | | |
| |---->| INVITE | | | | |
| | |---------->| INVITE | | | |
| | | |---------->| IAM | | |
| | | | |---->|SETUP| |
| | | | | |---->| SETUP |
| | | | | | |----------->|
| | | | | | | |
Figure 2: ISDN-SIP-ISDN Interconnection
INVITE tel:+17005554141;isub=12345 SIP/2.0
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Requirements</span>
The followings are requirements for a solution to carry an ISDN
subaddress along with information of subaddress encoding type.
Req 1: When the "isub" parameter is present but no "isub-encoding"
parameter is present in a tel URI, the encoding of the ISDN
subaddress in the original message MUST be assumed to be IA5
(AFI=0x50).
Req 2: When using the "isub" parameters in tel URIs, the encoding
SHOULD be specified by using the optional "isub-encoding"
parameter unless the encoding of the ISDN subaddress is IA5
(AFI=0x50).
<span class="grey">Munakata, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Parameter Definition</span>
The parameter defined in this document is represented as a tel URI
parameter, which describes the encoding type information of the ISDN
subaddress. It is an optional parameter to tel URI to accommodate
some of the information lacking in the "isub" parameter defined in
<a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>]. The ABNF [<a href="#ref-3" title=""Augmented BNF for Syntax Specifications: ABNF"">3</a>] syntax is as follows.
isub-encoding = isub-encoding-tag "=" isub-encoding-value
isub-encoding-tag = "isub-encoding"
isub-encoding-value = "nsap-ia5" / "nsap-bcd" / "nsap" / token
The semantics of these "isub-encoding" values are described below:
nsap-ia5: Indication that the "isub" parameter value needs to be
encoded using IA5 (AFI=0x50) when translated to an ISUP
message.
nsap-bcd: Indication that the "isub" parameter value needs to be
encoded using Binary Coded Decimal (BCD) (AFI=0x48) when
translated to an ISUP message.
nsap: Indication that the "isub" parameter value needs to be
encoded using the encoding type defined in ISO 8348 [<a href="#ref-6" title=""Information technology - Open Systems Interconnection - Network service definition"">6</a>]
other than IA5 (AFI=0x50) or BCD (AFI=0x48).
Note: Q.931 [<a href="#ref-7" title=""ISDN User-Network Interface Layer 3 Specification for Basic Call Control"">7</a>] defines a "user specified" subaddress type, but
this document does not specify any behavior or value for
"user specified" subaddress type. Therefore, the "user
specified" subaddress is beyond the scope of this document.
An example of the syntax of the "isub-encoding" parameter (in a small
fragment of a SIP [<a href="#ref-4" title=""SIP: Session Initiation Protocol"">4</a>] message) is given below:
INVITE tel:+17005554141;isub=12345;isub-encoding=nsap-ia5 SIP/2.0
To: <tel:+17005554141;isub=12345;isub-encoding=nsap-ia5>
From: "Bob"<sip:bob@biloxi.example.com>;tag=1928301774
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Usage</span>
It is anticipated that a tel URI parameter defined in this document
will be used along with an "isub" parameter defined in <a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>]
when interworking between an ISUP network and a SIP network. The URI
parameter defined here is an optional parameter to the tel URI and is
useful only when it's accompanying the "isub" parameter.
<span class="grey">Munakata, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
An ISDN subaddress information element carried in the ISUP message
consists of a 3-octet header followed by either an NSAP address or a
user-specified address. The NSAP address consists of an Initial
Domain Part (IDP) (Authority and Format Identifier (AFI) and
conditionally Initial Domain Identifier (IDI)) that identifies an
encoding type of the subaddress, and a Domain Specific Part (DSP)
that represents the subaddress value itself.
To find out more about the ISDN subaddress information element and
the NSAP address including definition of AFI, IDI, IDP, and DSP,
please refer to Appendices A and B.
If the "isub-encoding" is absent, and a message is interpreted by an
entity on the SIP network, the entity compliant to this specification
MUST assume that the original ISDN subaddress in an ISUP message was
an NSAP address with an encoding type of IA5 (AFI=0x50), of which the
DSP value was translated and set to the "isub" parameter value, and
MUST handle the message accordingly.
If the "isub-encoding" is absent, and the message is handled by a
gateway translating the SIP message to ISUP message, the gateway
compliant to this specification MUST encode the value in the "isub"
parameter using IA5 (AFI=0x50) and set the encoded value into the DSP
part of the NSAP address when translating the message into an ISUP
message.
If the value of "isub-encoding" is set to "nsap", the encoding type
(AFI) is assumed to be in the first two characters of the "isub"
parameter in hexadecimal represented as US-ASCII characters 0-9 and
A-F.
If the ISDN subaddress is not an NSAP address, the entity translating
the message SHOULD treat the message as if neither the "isub-
encoding" nor the "isub" parameters existed, unless it has a prior
knowledge of the encoding method used.
When an entity that is not compliant to this specification handles
the message with the "isub-encoding" parameter, it would simply
ignore the parameter and its value.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Gateway Behavior</span>
A gateway compliant to this specification that receives a message/
signal from an ISDN network containing an ISDN subaddress MUST check
the encoding used for the subaddress and MUST follow the procedures
given below.
<span class="grey">Munakata, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
If the ISDN subaddress is an NSAP address encoded using IA5
(AFI=0x50), the entity MAY set the "isub-encoding" parameter to
the value "nsap-ia5" and set the DSP value of the NSAP address as
the value for the "isub" parameter using characters permitted for
the "isub" parameter as specified in <a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>] or omit the
"isub-encoding" parameter.
If the ISDN subaddress is an NSAP address encoded using BCD
(AFI=0x48), the entity MUST set the "isub-encoding" parameter to
the value "nsap-bcd" and set the decoded DSP value of the NSAP
address as the value for the "isub" parameter in US-ASCII
characters using numbers.
Note: Each semi-octet should be translated into numbers (e.g.
01011001 would be translated as 5 and 9).
If the ISDN subaddress is an NSAP address but is not encoded using
either IA5 (AFI=0x50) or BCD (AFI=0x48), the entity translating
the message MUST set the "isub-encoding" parameter to the value
"nsap" and the entire NSAP address as the value for the "isub"
parameter in hexadecimal represented as US-ASCII characters (0-9
and A-F).
If the ISDN subaddress is not an NSAP address, the entity
translating the message SHOULD NOT generate any "isub-encoding" or
"isub" parameters, unless it has a private agreement with the
recipient about what to do in this case.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. SIP Entity Behavior</span>
An entity compliant to this specification setting an "isub" parameter
MUST follow the procedures given below.
If the ISDN subaddress is an NSAP address encoded using IA5
(AFI=0x50), the entity MAY set the "isub-encoding" to "nsap-ia5".
The "isub" parameter value MUST NOT exceed 19 characters. The
characters used MUST follow the syntax defined for the "isub"
parameter as specified in <a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>].
If the ISDN subaddress is an NSAP address encoded using BCD
(AFI=0x48), the entity MUST set the "isub-encoding" to "nsap-bcd".
The "isub" parameter value MUST NOT exceed 38 US-ASCII characters
(numbers).
<span class="grey">Munakata, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
If the ISDN subaddress is an NSAP address encoded using an
encoding type other than IA5 (AFI=0x50) or BCD (AFI=0x48), the
entity MUST set the "isub-encoding" to "nsap". The "isub"
parameter value MUST NOT exceed 40 US-ASCII characters and it MUST
be in hexadecimal represented as US-ASCII characters (0-9 and A-
F). The first two characters of the "isub" parameter MUST be the
encoding type (AFI) in this case.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The parameter defined here adds no new security considerations to
those discussed in <a href="./rfc3966">RFC 3966</a> [<a href="#ref-2" title=""The tel URI for Telephone Numbers"">2</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This document requires no action by IANA.
Further information on a registry for tel parameters is covered in
[<a href="#ref-8" title=""The Internet Assigned Numbers Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry"">8</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors thank John Elwell, James Rafferty, Steve Norreys, Michael
Hammer, Ray Forbes, Martin Dolly, Cullen Jennings, and Henning
Schulzrinne for providing extensive and constructive reviews and
feedback.
<span class="grey">Munakata, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Structure of an ISDN Subaddress Information Element</span>
The structure of an ISDN subaddress information element in ISUP
messages is defined in Q.931 [<a href="#ref-7" title=""ISDN User-Network Interface Layer 3 Specification for Basic Call Control"">7</a>] as follows.
Bits
8 7 6 5 4 3 2 1 Octets
+-----+-----------------------------------------+
| 0 | 1 1 1 0 0 0 0 | 1
+-----+-----------------------------------------+
| Length of called party subaddress contents | 2
+-----+-----------------------------------------+
| 1 | Subaddress type | o/e | 0 0 0 | 3
+-----+-----------------------------------------+
| | 4
| Subaddress information |
| |
| |
| |
+-----------------------------------------------+ max. 23
Figure 3: Structure of an ISDN Subaddress Information Element
Although the length varies, the maximum length of an ISDN subaddress
information element shown in the figure above is 23 octets. The
first 3 octets are the header. The rest of the octets comprise the
subaddress information that is either an NSAP address or a "user
specified" address.
The 1st octet is a called party subaddress information element
identifier that identifies that this information element is a called
party subaddress. The 2nd octet represents the length of called
party subaddress contents.
The 5th to 7th bits of the 3rd octet identify the type of subaddress.
This field is set to 0 0 0 when the subaddress is an NSAP address.
It is set to 0 1 0 when the subaddress is "user specified".
The 4th bit of the 3rd octet is an odd/even indicator. The odd/even
indicator is used when the type of subaddress is "user specified"
with the encoding type of BCD, to enable an entity to pad the missing
bits (last 4 bits of the subaddress information) when the number of
digits composing the subaddress is odd.
Note: When interworking with SIP, it is recommended not to
translate the padding bits to "isub" parameter.
<span class="grey">Munakata, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Structure of NSAP Addresses</span>
In ISUP messages, the ISDN subaddress is generally represented as an
NSAP address. The NSAP address is defined as follows in ISO 8348
[<a href="#ref-6" title=""Information technology - Open Systems Interconnection - Network service definition"">6</a>].
The NSAP address consists of an Initial Domain Part (IDP) and a
Domain Specific Part (DSP). The IDP consists of two fields, an
Authority and Format Identifier (AFI) and an Initial Domain
Identifier (IDI). The maximum length of an NSAP address is 20
octets.
<------------------ NSAP Address ------------------>
+--------------------------------------------------+
| I D P | |
|-------------| D S P |
| AFI | IDI | |
+--------------------------------------------------+
<a href="#section-0">0</a> 1 k ... Octets ... max. 20
Figure 4: Structure of NSAP Addresses
The AFI value is 2 hexadecimal digits (00-FF), and it identifies the
IDI format and the DSP syntax.
The IDI value when present is represented as decimal digits, and it
identifies a network addressing domain or authority responsible for
allocating values of the DSP. The length of IDI varies and depends
on the value of AFI.
The typical encoding type of the ISDN subaddress, IA5, is identified
as AFI=0x50. When the AFI value is 0x50, the length of IDI is zero;
therefore, the length of IDP is 2 digits (1 octet). In this case,
the DSP value is a subaddress encoded by IA5, and its maximum length
is 19 octets. The length of IDI is also zero when the encoding type
is BCD (AFI=0x48). The NSAP address for when the AFI value is set to
either 0x50 or 0x48 is shown below. As shown, DSP starts from the
2nd octet of the NSAP address.
+--------------------------------------------------+
| IDP | |
|-----| D S P |
| AFI | |
+--------------------------------------------------+
<a href="#section-0">0</a> 1 ... Octets ... max. 20
Figure 5 Structure of NSAP Addresses (AFI=0x50 or AFI=0x48)
<span class="grey">Munakata, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.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>] Schulzrinne, H., "The tel URI for Telephone Numbers", <a href="./rfc3966">RFC 3966</a>,
December 2004.
[<a id="ref-3">3</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc4234">RFC 4234</a>, October 2005.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-4">4</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-5">5</a>] International Telecommunication Union, "International Reference
Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) -
Information technology - 7-bit coded character set for
information interchange", Recommendation T.50, 1992.
[<a id="ref-6">6</a>] International Standard, "Information technology - Open Systems
Interconnection - Network service definition", ISO/IEC 8348,
2002.
[<a id="ref-7">7</a>] International Telecommunication Union, "ISDN User-Network
Interface Layer 3 Specification for Basic Call Control",
Recommendation Q.931, 1998.
[<a id="ref-8">8</a>] Jennings, C. and V. Gurbani, "The Internet Assigned Numbers
Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
Registry", Work in Progress, May 2006.
<span class="grey">Munakata, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
Authors' Addresses
Mayumi Munakata
NTT Corporation
Phone: +81 422 36 7565
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert
NTT Corporation
Phone: +1 604 762 5606
EMail: shida@ntt-at.com
Takumi Ohba
NTT Corporation
9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
URI: <a href="http://www.ntt.co.jp">http://www.ntt.co.jp</a>
<span class="grey">Munakata, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4715">RFC 4715</a> ISDN for tel URI November 2006</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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.
Munakata, et al. Informational [Page 14]
</pre>
|
