File: rfc2806.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1179 lines) | stat: -rw-r--r-- 50,647 bytes parent folder | download | duplicates (5)
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
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179






Network Working Group                                    A. Vaha-Sipila
Request for Comments: 2806                                        Nokia
Category: Standards Track                                    April 2000


                        URLs for Telephone Calls

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 Internet Society (2000).  All Rights Reserved.

Abstract

   This document specifies URL (Uniform Resource Locator) schemes "tel",
   "fax" and "modem" for specifying the location of a terminal in the
   phone network and the connection types (modes of operation) that can
   be used to connect to that entity. This specification covers voice
   calls (normal phone calls, answering machines and voice messaging
   systems), facsimile (telefax) calls and data calls, both for POTS and
   digital/mobile subscribers.

Table of Contents

   1. Introduction ................................................    2
   1.1 New URL schemes ............................................    2
   1.2 Formal definitions .........................................    3
   1.3 Requirements ...............................................    3
   2. URL schemes for telephone calls .............................    3
   2.1 Applicability ..............................................    3
   2.2 "tel" URL scheme ...........................................    4
   2.3 "fax" URL scheme ...........................................    6
   2.4 "modem" URL scheme .........................................    6
   2.5 Parsing telephone, fax and modem URLs ......................    7
   2.5.1 Call type ................................................    7
   2.5.2 Phone numbers and their scope ............................    7
   2.5.3 Separators in phone numbers ..............................   10
   2.5.4 Converting the number to the local numbering scheme ......   10
   2.5.5 Sending post-dial sequence after call setup ..............   10
   2.5.6 Pauses in dialing and post-dial sequence .................   11
   2.5.7 ISDN subaddresses ........................................   11



Vaha-Sipila                 Standards Track                     [Page 1]

RFC 2806                URLs for Telephone Calls              April 2000


   2.5.8 T.33 subaddresses ........................................   11
   2.5.9 Data call parameters .....................................   12
   2.5.10 Telephony service provider identification ...............   13
   2.5.11 Additional parameters ...................................   14
   2.6 Examples of Use ............................................   14
   2.7 Rationale behind the syntax ................................   15
   2.7.1 Why distinguish between call types?  .....................   15
   2.7.2 Why "tel" is "tel"?  .....................................   16
   2.7.3 Why to use E.164-style numbering? ........................   16
   2.7.4 Not everyone has the same equipment as you ...............   17
   2.7.5 Do not confuse numbers with how they are dialled .........   17
   3. Comments on usage ...........................................   17
   4. References ..................................................   18
   5. Security Considerations .....................................   19
   6. Acknowledgements ............................................   20
   7. Author's Address ............................................   20
   8. Full Copyright Statement ....................................   21

1. Introduction

1.1 New URL schemes

   This specification defines three new URL schemes: "tel", "fax" and
   "modem". They are intended for describing a terminal that can be
   contacted using the telephone network. The description includes the
   subscriber (telephone) number of the terminal and the necessary
   parameters to be able to successfully connect to that terminal.

   The "tel" scheme describes a connection to a terminal that handles
   normal voice telephone calls, a voice mailbox or another voice
   messaging system or a service that can be operated using DTMF tones.

   The "fax" scheme describes a connection to a terminal that can handle
   telefaxes (facsimiles). The name (scheme specifier) for the URL is
   "fax" as recommended by [E.123].

   The "modem" scheme describes a connection to a terminal that can
   handle incoming data calls. The term "modem" refers to a device that
   does digital-to-analog and analog-to-digital conversions; in addition
   to these, a "modem" scheme can describe a fully digital connection.

   The notation for phone numbers is the same which is specified in
   [RFC2303] and [RFC2304]. However, the syntax definition is a bit
   different due to the fact that this document specifies URLs whereas
   [RFC2303] and [RFC2304] specify electronic mail addresses. For
   example, "/" (used in URLs to separate parts in a hierarchical URL
   [RFC2396]) has been replaced by ";". In addition, this URL scheme has
   been synchronized with [RFC2543].



Vaha-Sipila                 Standards Track                     [Page 2]

RFC 2806                URLs for Telephone Calls              April 2000


   When these URLs are used, the number of parameters should be kept to
   the minimum, unless this would make the context of use unclear.
   Having a short URL is especially important if the URL is intended to
   be shown to the end user, printed, or otherwise distributed so that
   it is visible.

1.2 Formal definitions

   The ABNF (augmented Backus-Naur form) notation used in formal
   definitions follows [RFC2234]. This specification uses elements from
   the 'core' definitions (Appendix A of [RFC2234]). Some elements have
   been defined in previous RFCs. If this is the case, the RFC in
   question has been referenced in comments.

   Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this
   document specifies strings of raw, unescaped characters. If those
   characters are present in a URL, and are not unreserved [RFC2396],
   they MUST be escaped as explained in [RFC2396] prior to using the
   URL.  In addition, when parsing a URL, it must be noted that some
   characters may have been escaped.

   An example: ABNF notation "%x20" means a single octet with a
   hexadecimal value of "20" (in US-ASCII, a space character). This must
   be escaped in a URL, and it becomes "%20".

   In addition, the ABNF in this document only uses lower case. The URLs
   are case-insensitive (except for the <future-extension> parameter,
   whose case-sensitivity is application-specific).

1.3 Requirements

   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 [RFC2119].

   Compliant software MUST follow this specification.

2. URL schemes for telephone calls

2.1 Applicability

   In this document, "local entity" means software and hardware that can
   detect and parse one or more of these URLs and possibly place a call
   to a remote entity, or otherwise utilize the contents of the URL.

   These URL schemes are used to direct the local entity to place a call
   using the telephone network, or as a method to transfer or store a
   phone number plus other relevant data. The network in question may be



Vaha-Sipila                 Standards Track                     [Page 3]

RFC 2806                URLs for Telephone Calls              April 2000


   a landline or mobile phone network, or a combination of these. If the
   phone network differentiates between (for example) voice and data
   calls, or if the local entity has several different
   telecommunications equipment at its disposal, it is possible to
   specify which kind of call (voice/fax/data) is requested. The URL can
   also contain information about the capabilities of the remote entity,
   so that the connection can be established successfully.

   The "tel", "fax" and "modem" URL schemes defined here do not use the
   hierarchical URL syntax; there are no applicable relative URL forms.
   The URLs are always case-insensitive, except for the <future-
   extension> parameter (see below), whose case-sensitivity is
   application specific. Characters in the URL MUST be escaped when
   needed as explained in [RFC2396].

2.2 "tel" URL scheme

   The URL syntax is formally described as follows. For the basis of
   this syntax, see [RFC2303].

telephone-url         = telephone-scheme ":"
                        telephone-subscriber
telephone-scheme      = "tel"
telephone-subscriber  = global-phone-number / local-phone-number
global-phone-number   = "+" base-phone-number [isdn-subaddress]
                        [post-dial] *(area-specifier /
                        service-provider / future-extension)
base-phone-number     = 1*phonedigit
local-phone-number    = 1*(phonedigit / dtmf-digit /
                        pause-character) [isdn-subaddress]
                        [post-dial] area-specifier
                        *(area-specifier / service-provider /
                        future-extension)
isdn-subaddress       = ";isub=" 1*phonedigit
post-dial             = ";postd=" 1*(phonedigit /
                        dtmf-digit / pause-character)
area-specifier        = ";" phone-context-tag "=" phone-context-ident
phone-context-tag     = "phone-context"
phone-context-ident   = network-prefix / private-prefix
network-prefix        = global-network-prefix / local-network-prefix
global-network-prefix = "+" 1*phonedigit
local-network-prefix  = 1*(phonedigit / dtmf-digit / pause-character)
private-prefix        = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A /
                        %x3C-40 / %x45-4F / %x51-56 / %x58-60 /
                        %x65-6F / %x71-76 / %x78-7E)
                        *(%x21-3A / %x3C-7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]



Vaha-Sipila                 Standards Track                     [Page 4]

RFC 2806                URLs for Telephone Calls              April 2000


                        ; See sections 1.2 and 2.5.2
service-provider      = ";" provider-tag "=" provider-hostname
provider-tag          = "tsp"
provider-hostname     = domain ; <domain> is defined in [RFC1035]
                        ; See section 2.5.10
future-extension      = ";" 1*(token-char) ["=" ((1*(token-char)
                        ["?" 1*(token-char)]) / quoted-string )]
                        ; See section 2.5.11 and [RFC2543]
token-char            = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                        / %x41-5A / %x5E-7A / %x7C / %x7E)
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]
                        ; See sections 1.2 and 2.5.11
quoted-string         = %x22 *( "\" CHAR / (%x20-21 / %x23-7E
                        / %x80-FF )) %x22
                        ; Characters in URLs must follow escaping rules
                        ; as explained in [RFC2396]
                        ; See sections 1.2 and 2.5.11
phonedigit            = DIGIT / visual-separator
visual-separator      = "-" / "." / "(" / ")"
pause-character       = one-second-pause / wait-for-dial-tone
one-second-pause      = "p"
wait-for-dial-tone    = "w"
dtmf-digit            = "*" / "#" / "A" / "B" / "C" / "D"

   The URL starts with <telephone-scheme>, which tells the local entity
   that what follows is a URL that should be parsed as described in this
   document. After that, the URL contains the phone number of the remote
   entity. Phone numbers can also contain subaddresses, which are used
   to identify different remote entities under the same phone number. If
   a subaddress is present, it is appended to the phone number after
   ";isub=". Phone numbers can also contain a post-dial sequence. This
   is what is often used with voice mailboxes and other services that
   are controlled by dialing numbers from your phone keypad while the
   call is in progress. The <post-dial> sequence describes what and when
   the local entity should send to the phone line.

   Phone numbers can be either "global" or "local". Global numbers are
   unambiguous everywhere. Local numbers are usable only within a
   certain area, which is called "context", see section 2.5.2.

   Local numbers always have an <area-specifier>, which specifies the
   context in which the number is usable (the same number may have
   different interpretation in different network areas). The context can
   be indicated with three different prefixes. A <global-network-prefix>
   indicates that the number is valid within a numbering area whose
   global numbers start with <global-network-prefix>. Similarly,
   <local-network-prefix> means that the number is valid within a



Vaha-Sipila                 Standards Track                     [Page 5]

RFC 2806                URLs for Telephone Calls              April 2000


   numbering area whose numbers (or dial strings) start with it. A
   <private-prefix> is a name of a context. The local entity must have
   knowledge of this private context to be able to deduce whether it can
   use the number, see section 2.5.2. Additional information about the
   phone number's usage can be included by adding the name of the
   telephony services provider in <service-provider>, see section
   2.5.10.

   The <future-extension> mechanism makes it possible to add new
   parameters to this URL scheme. See section 2.5.11.

   The <private-prefix>, <token-char> and <quoted-string> nonterminals
   may seem a bit complex at first, but they simply describe the set of
   octets that are legal in those nonterminals. Some octets may have to
   be escaped, see [RFC2396].

2.3 "fax" URL scheme

   The URL syntax is formally described as follows (the definition
   reuses nonterminals from the above definition). For the basis of this
   syntax, see [RFC2303] and [RFC2304].

      fax-url          = fax-scheme ":" fax-subscriber
      fax-scheme       = "fax"
      fax-subscriber   = fax-global-phone / fax-local-phone
      fax-global-phone = "+" base-phone-number [isdn-subaddress]
                         [t33-subaddress] [post-dial]
                         *(area-specifier / service-provider /
                         future-extension)
      fax-local-phone  = 1*(phonedigit / dtmf-digit /
                         pause-character) [isdn-subaddress]
                         [t33-subaddress] [post-dial]
                         area-specifier
                         *(area-specifier / service-provider /
                         future-extension)
      t33-subaddress   = ";tsub=" 1*phonedigit

   The fax: URL is very similar to the tel: URL. The main difference is
   that in addition to ISDN subaddresses, telefaxes also have an another
   type of subaddress, see section 2.5.8.

2.4 "modem" URL scheme

   The URL syntax is formally described as follows (the definition
   reuses nonterminals from the above definitions). For the basis of
   this syntax, see [RFC2303].





Vaha-Sipila                 Standards Track                     [Page 6]

RFC 2806                URLs for Telephone Calls              April 2000


      modem-url          = modem-scheme ":" remote-host
      modem-scheme       = "modem"
      remote-host        = telephone-subscriber *(modem-params
                           / recommended-params)
      modem-params       = ";type=" data-capabilities
      recommended-params = ";rec=" data-capabilities
      data-capabilities  = accepted-modem ["?" data-bits parity
                           stop-bits]
      accepted-modem     = "V21" / "V22" / "V22b" /
                           "V23" / "V26t" / "V32" /
                           "V32b" / "V34" / "V90" /
                           "V110" / "V120" / "B103" /
                           "B212" / "X75" /
                           "vnd." vendor-name "." modem-type
      data-bits          = "7" / "8"
      parity             = "n" / "e" / "o" / "m" / "s"
      stop-bits          = "1" / "2"
      vendor-name        = 1*(ALPHA / DIGIT / "-" / "+")
      modem-type         = 1*(ALPHA / DIGIT / "-" / "+")

   The modem: URL scheme is also very similar to both the tel: and fax:
   schemes, but it adds the description of the capabilities of the
   remote entity. Minimum required compliance is listed in <modem-
   params> and recommended compliance is listed in <recommended-params>.
   For details, see section 2.5.9.

2.5 Parsing telephone, fax and modem URLs

2.5.1 Call type

   The type of call is specified by the scheme specifier.  "Tel" means
   that a voice call is opened. "Fax" indicates that the call should be
   a facsimile (telefax) call. "Modem" means that it should be a data
   call. Not all networks differentiate between the types of call; in
   this case, the scheme specifier indicates the telecommunications
   equipment type to use.

2.5.2 Phone numbers and their scope

   <telephone-subscriber> and <fax-subscriber> indicate the phone number
   to be dialed. The phone number can be written in either international
   or local notation. All phone numbers SHOULD always be written in the
   international form if there is no good reason to use the local form.

   Not all numbers are valid within all numbering areas. The <area-
   specifier> parameter, which is mandatory for local numbers, is used
   to indicate the locale within which this number is valid, or to
   qualify the phone number so that it may be used unambiguously. The



Vaha-Sipila                 Standards Track                     [Page 7]

RFC 2806                URLs for Telephone Calls              April 2000


   <area-specifier> can take three forms: <global-network-prefix>,
   <local-network-prefix> or <private-prefix>. These are used to
   describe the validity area of the phone number either in global
   numbering plan, local numbering plan, or in a private numbering plan,
   respectively.

   If <area-specifier> is present, the local entity MUST NOT attempt to
   call out using the phone number if it cannot originate the call
   within the specified locale. If a <local-phone-number> is used, an
   <area-specifier> MUST be included as well.

   There can be multiple instances of <area-specifier>. In this case,
   the number is valid in all of the given numbering areas.

   The global prefix form is intended to act as the outermost context
   for a phone number, so it will start with a "+", followed by some
   part of an E.164 number. It also specifies the region in which the
   phone number is valid. For example, if <global-network-prefix> is
   "+358", the given number is valid only within Finland (country code
   358) - even if it is a <global-phone-number>.

   The local prefix form is intended to act as an intermediate context
   in those situations where the outermost context for a phone number is
   given by another means. One example of use is where the local entity
   is known to originate calls only within the North American Number
   Plan Area, so an "outermost" phone context can be assumed. The local
   context could, for example, be used to indicate the area code within
   which an associated phone number is situated. Thus "tel:456-
   7890;phone-context=213" would suffice to deliver a call to the
   telephone number "+1-213-456-7890". Note that the version including
   the <phone-context> implies further that the call can only be
   originated within the "area code 213" region.

   The <private-prefix> form is intended for use in those situations
   where the context cannot be expressed with a start of a global phone
   number or a dialing string. The <private-prefix> is actually a name
   of a private context. The creator of the URL and the local entity
   have been configured to recognize this name, and as such they can
   interpret the number and know how they can utilize the number. For
   example, a private network numbering plan may be indicated by the
   name "X-COMPANY-NET", but the private dialling plan from the locales
   of the sender of the telephony URL and the local entity are
   different. The syntax of these tokens will be left for future
   specification. The ABNF above specifies the accepted characters that
   can be a part of <private-prefix>.






Vaha-Sipila                 Standards Track                     [Page 8]

RFC 2806                URLs for Telephone Calls              April 2000


   Unless the sender is absolutely sure that they share the same private
   network access digit string with the local entity, then they MUST NOT
   use a dialling plan number (a local phone number, or one qualified by
   a local context), as the result may be incorrect. Instead, they
   SHOULD use a global number, or if that is not possible, a private
   context as the last resort. If the local entity does not support
   dialling into the private network indicated by that context, then the
   request MUST be rejected. If it does, then it will use the access
   digit string appropriate for its locale.

   Note that the use of <area-specifier> is orthogonal to use of the
   telephony service provider parameter (see 2.5.10); it qualifies the
   phone number, whilst the <service-provider> parameter indicates the
   carrier to be used for the call attempt.

   For example, a large company may have private network
   interconnections between its sites, as well as connections to the
   Global Switched Telephone Network. A phone number may be given in
   "public network" form, but with a <service-provider> indicating that
   the call should be carried over the corporate network.

   Conversely, it would be possible to represent a phone number in
   private network form, with a private context to indicate this, but
   indicate a public telephony service provider. This would request that
   the user agent convert the private network number plan address into a
   form that can be carried using the selected service provider.

   Any telephone number MUST contain at least one <phonedigit> or
   <dtmf-digit>, that is, subscriber numbers consisting only of pause
   characters are not allowed.

   International numbers MUST begin with the "+" character. Local
   numbers MUST NOT contain that character. International numbers MUST
   be written with the country (CC) and national (NSN) numbers as
   specified in [E.123] and [E.164]. International numbers have the
   property of being totally unambiguous everywhere in the world if the
   local entity is properly configured.

   Local numbers MAY be used if the number only works from inside a
   certain geographical area or a network. Note that some numbers may
   work from several networks but not from the whole world - these
   SHOULD be written in international form, with a set of <area-
   specifier> tags and optional <service-provider> parameters. URLs
   containing local phone numbers should only appear in an environment
   where all local entities can get the call successfully set up by
   passing the number to the dialing entity "as is". An example could be
   a company intranet, where all local entities are located under a the
   same private telephone exchange. If local phone numbers are used,



Vaha-Sipila                 Standards Track                     [Page 9]

RFC 2806                URLs for Telephone Calls              April 2000


   the document in which they are present SHOULD contain an indication
   of the context in which they are intended to be used, and an
   appropriate <area-specifier> SHOULD be present in the URL.

   In some regions, it is popular to write phone numbers using
   alphabetic characters which correspond to certain numbers on the
   telephone keypad.  Letters in <dtmf-digit> characters do not have
   anything to do with this, nor is this method supported by these URL
   schemes.

   It should also be noted that implementations MUST NOT assume that
   telephone numbers have a maximum, minimum or fixed length, or that
   they would always begin with a certain number.  Implementors are
   encouraged to familiarize themselves with the international
   standards.

2.5.3 Separators in phone numbers

   All <visual-separator> characters MUST be ignored by the local entity
   when using the URL. These characters are present only to aid
   readability: they MUST NOT have any other meaning. Note that although
   [E.123] recommends the use of space (SP) characters as the separators
   in printed telephone numbers, spaces MUST NOT be used in phone
   numbers in URLs as the space character cannot be used in URLs without
   escaping it.

2.5.4 Converting the number to the local numbering scheme

   After the telephone number has been extracted, it can be converted to
   the local dialing convention. (For example, the "+" character might
   be replaced by the international call prefix, or the international
   and trunk prefixes might be removed to place a local call.) Numbers
   that have been specified using <local-phone> or <fax-local-phone>
   MUST be used by the local entity "as is", without any conversions,
   unless the local entity decides to utilize the information in an
   optional <service-provider> parameter.

2.5.5 Sending post-dial sequence after call setup

   The number may contain a <post-dial> sequence, which MUST be dialled
   using Dual Tone Multifrequency (DTMF) in-band signalling or pulse
   dialing after the call setup is complete. If the user agent does not
   support DTMF or pulse dialing after the call has been set up, <post-
   dial> MUST be ignored. In that case, the user SHOULD be notified.







Vaha-Sipila                 Standards Track                    [Page 10]

RFC 2806                URLs for Telephone Calls              April 2000


2.5.6 Pauses in dialing and post-dial sequence

   A local phone number or a post-dial sequence may contain <pause-
   character> characters which indicate a pause while dialing ("p"), or
   a wait for dial tone ("w").

   Local entities MAY support this method of dialing, and the final
   interpretation of these characters is left to the local entity.  It
   is RECOMMENDED that the length of each pause is about one second.

   If it is not supported, local entities MUST ignore everything in the
   dial string after the first <pause-character> and the user SHOULD be
   notified. The user or the local entity MAY opt not to place a call if
   this feature is not supported and these characters are present in the
   URL.

   Any <dtmf-digit> characters and all dial string characters after the
   first <pause-character> or <dtmf-digit> SHOULD be sent to line using
   DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is
   done using direct network signaling (a digital subscriber loop or a
   mobile phone). If the local infrastructure does not support DTMF
   codes, the local entity MAY opt to use pulse dialing. However, it
   should be noted that certain services which are controlled using DTMF
   tones cannot be controlled with pulse dialing. If pulse dialing is
   used, the user SHOULD be notified.

2.5.7 ISDN subaddresses

   A phone number MAY also contain an <isdn-subaddress> which indicates
   an ISDN subaddress. The local entity SHOULD support ISDN
   subaddresses. These addresses are sent to the network by using a
   method available to the local entity (typically, ISDN subscribers
   send the address with the call setup signalling). If ISDN
   subaddressing is not supported by the caller, <isdn-subaddress> MUST
   be ignored and the user SHOULD be notified. The user or the local
   entity MAY opt not to place a call if this feature is not supported.

2.5.8 T.33 subaddresses

   A fax number MAY also contain a <t33-subaddress>, which indicates the
   start of a T.33 subaddress [T.33]. Local entities SHOULD support
   this. Otherwise <t33-subaddress> MUST be ignored and the user SHOULD
   be notified. The user or the local entity MAY opt not to place a call
   if this feature is not supported.







Vaha-Sipila                 Standards Track                    [Page 11]

RFC 2806                URLs for Telephone Calls              April 2000


2.5.9 Data call parameters

   <modem-params> indicate the minimum compliance required from the
   local entity to be able to connect to the remote entity. The minimum
   compliance is defined as being equal to or a superset of the
   capabilities of the listed modem type. There can be several <modem-
   param> parameters, in which case compliance to any one of them will
   be accepted.  <recommended-params> indicates the recommended
   compliance required from the local entity. This is typically the
   fastest and/or the most reliable modem type supported by the modem
   pool. The local entity can use this information to select the best
   number from a group of modem URLs.  There can be several recommended
   modem types, which are equally desirable from the modem pool's point
   of view. <recommended-params> MAY NOT conflict with <modem-params>.
   If they do, the local entity MUST ignore the <recommended-params>.

   The local entity MUST call out using compatible hardware, or request
   that the network provides such a service.

   For example, if the local entity only has access to a V.22bis modem
   and the URL indicates that the minimum acceptable connection is
   V.32bis, the local entity MUST NOT try to connect to the remote host
   since V.22bis is a subset of V.32bis. However, if the URL lists V.32
   as the minimum acceptable connection, the local entity can use
   V.32bis to create a connection since V.32bis is a superset of V.32.

   This feature is present because modem pools often have separate
   numbers for slow modems and fast modems, or have different numbers
   for analog and ISDN connections, or may use proprietary modems that
   are incompatible with standards. It is somewhat analogous to the
   connection type specifier (typecode) in FTP URLs [RFC1738]: it
   provides the local entity with information that can not be deduced
   from the scheme specifier, but is helpful for successful operation.

   This also means that the number of data and stop bits and parity MUST
   be set according to the information given in the URL, or to default
   values given in this document, if the information is not present.

   The capability tokens are listed below. If capabilities suggest that
   it is impossible to create a connection, the connection MUST NOT be
   created.

   If new modem types are standardized by ITU-T, this list can be
   extended with those capability tokens. Tokens are formed by taking
   the number of the standard and joining together the first letter (for
   example, "V"), number (for example, 22) and the first letter of the
   postfix (for example "bis" would become "b").




Vaha-Sipila                 Standards Track                    [Page 12]

RFC 2806                URLs for Telephone Calls              April 2000


   Proprietary modem types MUST be specified using the 'vendor naming
   tree', which takes the form "vnd.x.y", in which "x" is the name of
   the entity from which the specifications for the modem type can be
   acquired and "y" is the type or model of the modem. Vendor names MUST
   share the same name space with vendor names used in MIME types
   [RFC2048]. Submitting the modem types to ietf-types list for review
   is strongly recommended.

   New capabilities MUST always be documented in an RFC, and they MUST
   refer to this document or a newer version of it. The documentation
   SHOULD also list the existing modem types with which the newly
   defined modem type is compatible with.

      Capability              Explanation

      V21                     ITU-T V.21
      V22                     ITU-T V.22
      V22b                    ITU-T V.22bis
      V23                     ITU-T V.23
      V26t                    ITU-T V.26ter
      V32                     ITU-T V.32
      V32b                    ITU-T V.32bis
      V34                     ITU-T V.34
      V90                     ITU-T V.90
      V110                    ITU-T V.110
      V120                    ITU-T V.120
      X75                     ITU-T X.75
      B103                    Bell 103
      B212                    Bell 212
      Data bits: "8" or "7"   The number of data bits. If not
                              specified, defaults to "8".
      Parity: "n", "e", "o",  Parity. None, even, odd, mark or
              "m", "s"        space parity, respectively. If
                              not specified, defaults to "n".
      Stop bits: "1" or "2"   The number of stop bits. If not
                              specified, defaults to "1".

2.5.10 Telephony service provider identification

   It is possible to indicate the identity of the telephony service
   provider for the given phone number. <service-provider> MAY be used
   by the user-agent to place the call using this network, to enhance
   the user interface, for billing estimates or to otherwise optimize
   its functionality. It MAY also be ignored by the user-agent.
   <service-provider> consists of a fully qualified Internet domain name
   of the telephony service provider, for example
   ";tsp=terrifictelecom.com". The syntax of the domain name follows
   Internet domain name rules and is defined in [RFC1035].



Vaha-Sipila                 Standards Track                    [Page 13]

RFC 2806                URLs for Telephone Calls              April 2000


2.5.11 Additional parameters

   In addition to T.33 and ISDN subaddresses, modem types and area
   specifiers, future extensions to this URL scheme may add other
   additional parameters (<future-extension> in the BNF) to these URLs.
   These parameters are added to the URL after a semicolon (";").
   Implementations MUST be prepared to handle additional and/or unknown
   parameters gracefully. Implementations MUST NOT use the URL if it
   contains unknown parameters, as they may be vital for the correct
   interpretation of the URL. Instead, the implementation SHOULD report
   an error.

   For example, <future-extension> can be used to store application-
   specific additional data about the phone number, its intended use, or
   any conversions that have been applied to the number.  Whenever a
   <future-extension> is used in an open environment, its syntax and
   usage MUST be properly documented in an RFC.

   <future-extension> nonterminal a rephrased version of, and compatible
   with the <other-param> as defined in [RFC2543] (which actually
   borrows BNF from an earlier version of this specification).

2.6 Examples of Use

     tel:+358-555-1234567

   This URL points to a phone number in Finland capable of receiving
   voice calls. The hyphens are included to make the number more human-
   readable: country and area codes have been separated from the
   subscriber number.

     fax:+358.555.1234567

   The above URL describes a phone number which can receive fax calls.
   It uses dots instead of hyphens as separators, but they have no
   effect on the functionality.

     modem:+3585551234567;type=v32b?7e1;type=v110

   This phone number belongs to an entity which is able to receive data
   calls. The local entity may opt to use either a ITU-T V.32bis modem
   (or a faster one, which is compatible with V.32bis), using settings
   of 7 data bits, even parity and one stop bit, or an ISDN connection
   using ITU-T V.110 protocol.







Vaha-Sipila                 Standards Track                    [Page 14]

RFC 2806                URLs for Telephone Calls              April 2000


     tel:+358-555-1234567;postd=pp22

   The above URL instructs the local entity to place a voice call to
   +358-555-1234567, then wait for an implementation-dependent time (for
   example, two seconds) and emit two DTMF dialing tones "2" on the line
   (for example, to choose a particular extension number, or to invoke a
   particular service).

     tel:0w003585551234567;phone-context=+3585551234

   This URL places a voice call to the given number. The number format
   is intended for local use: the first zero opens an outside line, the
   "w" character waits for a second dial tone, and the number already
   has the international access code appended to it ("00"). This kind of
   phone number MUST NOT be used in an environment where all users of
   this URL might not be able to successfully dial out by using this
   number directly. However, this might be appropriate for pages in a
   company intranet. The <area-specifier> which is present hints that
   the number is usable only in an environment where the local entity's
   phone number starts with the given string (perhaps singling out a
   company-wide block of telephone numbers).

     tel:+1234567890;phone-context=+1234;vnd.company.option=foo

   The URL describes a phone number which, even if it is written in its
   international form, is only usable within the numbering area where
   phone numbers start with +1234. There is also a proprietary extension
   "vnd.company.option", which has the value "foo". The meaning of this
   extension is application-specific. Note that the order of these
   parameters (phone-context and vnd.company.option) is irrelevant.

2.7 Rationale behind the syntax

2.7.1 Why distinguish between call types?

   URLs locate resources, which in this case is some telecommunications
   equipment at a given phone number. However, it is not necessarily
   enough to know the subscriber number in order to successfully
   communicate with that equipment. Digital phone networks distinguish
   between voice, fax and data calls (and possibly other types of calls,
   not discussed in this specification). To be able to successfully
   connect to, say, a fax machine, the caller may have to specify that a
   fax call is being made. Otherwise the call might be routed to the
   voice number of the subscriber. In this sense, the call type is an
   integral part of the 'location' of the target resource.






Vaha-Sipila                 Standards Track                    [Page 15]

RFC 2806                URLs for Telephone Calls              April 2000


   The reason to have the call type in the scheme specifier is to make
   the URL simple to remember and use. Making it a parameter, much like
   the way modem parameters are handled now, will substantially reduce
   the human readability of this URL.

2.7.2 Why "tel" is "tel"?

   There has been discussion on whether the scheme name "tel" is
   appropriate. To summarize, these are the points made against the
   other proposals.

      callto      URL schemes locate a resource and do not specify
                  an action to be taken.
      telephone   Too long. Also, "tel" considered to be a more
                  international form.
      phone       Was countered on the basis that "tel" is more
                  internationally acceptable.

2.7.3 Why to use E.164-style numbering?

   E.164 refers to international telephone numbers, and the string of
   digits after the country code is usually a national matter. In any
   case, phone numbers are usually written as a simple string of numbers
   everywhere. Because of this, the syntax in this specification is
   intuitively clear to most people. This is the usual way to write
   phone numbers in business cards, advertisements, telephone books and
   so on.

   It should be noted that phone numbers may have 'hierarchical'
   characteristics, so that one could build a 'forest' of phone numbers
   with country codes as roots, area codes as branches and subscriber
   numbers as leaves. However, this is not always the case. Not all
   areas have area codes; some areas may have different area codes
   depending on how one wants to route the call; some numbers must
   always be dialled "as is", without prepending area or country codes
   (notably emergency numbers); and area codes can and do change.

   Usually, if something has a hierarchical structure, the URL syntax
   should reflect that fact. These URLs are an exception.

   Also, when writing the phone number in the form described in this
   specification, the writer does not need to know which part of the
   number is the country code and which part is the area code. If a
   hierarchical URL would be used (with a "/" character separating the
   parts of the phone numbers), the writer of the URL would have to know
   which parts are which.





Vaha-Sipila                 Standards Track                    [Page 16]

RFC 2806                URLs for Telephone Calls              April 2000


   Finally, when phone numbers are written in the international form as
   specified here, they are unambiguous and can always be converted to
   the local dialing convention, given that the user agent has the
   knowledge of the local country and area codes.

2.7.4 Not everyone has the same equipment as you

   There are several ways for the subscriber to dial a phone number:

     - By pulse dialing. Typically old telephone exchanges. Usually this
     dialing method has only to be used to set up the call; after
     connecting to the remote entity, <post-dial> can be sent to the
     line using DTMF, because it will typically be processed by the
     remote entity, not the telephone network.

     - By DTMF. These are the 'beeps' that you hear when you dial on
     most phones.

     - By direct network signalling. ISDN subscribers and mobile phone
     users usually have this. There is no dial tone (or if there is, it
     is generated locally by the equipment), and the number of the
     called party is communicated to the telephone network using some
     network signalling method. After setting up the call, <post-dial>
     sequences are usually sent using DTMF codes.

2.7.5 Do not confuse numbers with how they are dialled

   As an example, +123456789 will be dialled in many countries as
   00123456789, where the leading "00" is a prefix for international
   calls. However, if a URL contains a local phone number 00123456789,
   the user-agent MUST NOT assume that this number is equal to a global
   phone number +123456789. If a user-agent received a telephony URL
   with a local number in it, it MUST make sure that it knows the
   context in which the local phone number is to be processed, or else
   the number MUST NOT be used. Equally, anyone sending a telephony URL
   MUST take into consideration that the recipient may have insufficient
   information about the phone number's context.

3. Comments on usage

   These are examples of the recommended usage of this URL in HTML
   documents.

   First of all, the number SHOULD be visible to the end user, if it is
   conceivable that the user might not have a local entity which is able
   to use these URLs.

     Telephone: <a href="tel:+3585551234567">+358-555-1234567</a>



Vaha-Sipila                 Standards Track                    [Page 17]

RFC 2806                URLs for Telephone Calls              April 2000


   Second, on a public HTML page, the telephone number in the URL SHOULD
   always be in the international form, even if the text of the link
   uses some local format.

     Telephone: <a href="tel:+3585551234567">(0555) 1234567</a>

   or even

     For more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ-
     OK</a>.

   Moreover, if the number is a <local-phone-number>, and the scope of
   the number is not clear from the context in which the URL is
   displayed, a human-readable explanation SHOULD be included.

     For customer service, dial <a href="tel:1234;phone-
     context=+358555">1234</a> (only from Terrific Telecom mobile
     phones).

4. References

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
             Specification", STD 13, RFC 1035, November 1987.

   [RFC1738] Berners-Lee, T., et al., "Uniform Resource Locators (URL)",
             RFC 1738, December 1994.

   [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language
             - 2.0", RFC 1866, November 1995.

   [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
             Internet Mail Extensions (MIME) Part Four: Registration
             Procedures", RFC 2048, November 1996.

   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234, November 1997.

   [RFC2303] Allocchio, C., "Minimal PSTN Address Format in Internet
             Mail", RFC 2303, March 1998.

   [RFC2304] Allocchio, C., "Minimal FAX Address Format in Internet
             Mail", RFC 2304, March 1998.






Vaha-Sipila                 Standards Track                    [Page 18]

RFC 2806                URLs for Telephone Calls              April 2000


   [RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

   [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
             Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
             March 1999.

   [E.123]   ITU-T Recommendation E.123: Telephone Network and ISDN
             Operation, Numbering, Routing and Mobile Service: Notation
             for National and International Telephone Numbers. 1993.

   [E.164]   ITU-T Recommendation E.164/I.331 (05/97): The International
             Public Telecommunication Numbering Plan. 1997.

   [T.33]    ITU-T Recommendation T.33: Facsimile Routing Utilizing the
             Subaddress. 1996.

5. Security Considerations

   It should be noted that the local entity SHOULD NOT call out without
   the knowledge of the user because of associated risks, which include

   - call costs (including long calls, long distance calls,
     international calls and premium rate calls, or calls which do not
     terminate due to <post-dial> sequences that have been left out by
     the local entity)

   - wrong numbers inserted on web pages by malicious users, or sent via
     e-mail, perhaps in direct advertising

   - making the user's phone line unavailable (off-hook) for a malicious
     purpose

   - opening a data call to a remote host, thus possibly opening a back
     door to the user's computer

   - revealing the user's (possibly unlisted) phone number to the remote
     host in the caller identification data, and correlating the local
     entity's phone number with other information such as the e-mail or
     IP address

   - using the same local number in different contexts, in which the
     number may have a different meaning

   All of these risks MUST be taken into consideration when designing
   the local entity.




Vaha-Sipila                 Standards Track                    [Page 19]

RFC 2806                URLs for Telephone Calls              April 2000


   The local entity SHOULD have some mechanism that the user can use to
   filter out unwanted numbers. The local entity SHOULD NOT use rapid
   redialing of the number if it is busy to avoid the congestion of the
   (signaling) network. Also, the local entity SHOULD detect if the
   number is unavailable or if the call is terminated before the dialing
   string has been completely processed (for example, the call is
   terminated while waiting for user input) and not try to call again,
   unless instructed by the user.

6. Acknowledgements

   Writing this specification would not have been possible without
   extensive support from many people.

   Contributors include numerous people from IETF FAX, PINT, URI and
   URLREG mailing lists, as well as from World Wide Web Consortium and
   several companies, plus several individuals. Thanks to all people who
   offered criticism, corrections and feedback.

   All phone numbers and company names used in the examples of this
   specification are fictional. Any similarities to real entities are
   coincidental.

7. Author's Address

   Antti Vaha-Sipila
   (quoted-printable: Antti V=E4h=E4-Sipil=E4)
   Nokia Mobile Phones
   P. O. Box 68
   FIN-33721 Tampere
   Finland

   EMail: avs@iki.fi
          antti.vaha-sipila@nokia.com

















Vaha-Sipila                 Standards Track                    [Page 20]

RFC 2806                URLs for Telephone Calls              April 2000


8.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Vaha-Sipila                 Standards Track                    [Page 21]