RFC 4967

Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier

📅 published July 2007, from ietf

Okay bestie, let's get into RFC 4967 💅✨

This one's titled "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier" 🎀 It's from the Network Working Group, written by Brian Rosen at NeuStar, and it's a Standards Track doc dated July 2007. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Status of This Memo

ngl this part is the paperwork bit, but it's important 📋 It says this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright Notice

Abstract

So here's the tea 🫖 RFC 3966 explicitly says that 'tel' URIs may not represent a dial string. That leaves no way to specify a dial string in a standardized way 😭 People get really confused about the SIP URI parameter "user=phone" and whether it can represent a dial string. This memo creates a new value for the user parameter, "dialstring", so you can write "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI ✨

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5

1. Introduction ✨

Picture a user on a phone with a super limited User Interface 🙈 Sometimes it's just a 10 key pad, and sometimes there's a "flash" function with the switchhook. The user types in a series of digits that trigger some kind of function. That entered sequence is called a "dial string", and it might get translated into a telephone number, or it might invoke a special service 📞 In lots of newer designs, the mapping between a dial string and a phone number or service URI lives inside the phone (digitmap). But a bunch of phones and terminal adapters don't have any internal translation mechanism 😤 So without one, the phone has to send the dial string in a 'sip:' or 'sips:' URI [RFC3261] to an intermediary that can transform the dial string into a phone number or a service invocation. That intermediary can do the transform as long as it knows the context (i.e., dialing plan) the number was dialed in 🧚

Here's the problem 💀 The intermediary can only apply its transformation if it recognizes that the user part of the SIP URI is a dial string. Right now there's no way to tell a user part that's a dial string apart from a user part that just happens to be made of characters that could show up in a dial string 🙃

Using DTMF (dual tone multi-frequency) detectors after the initial number has been dialed is pretty common 🎶 Some systems have a function that expresses a string with fixed time delays, or in some cases an actual "wait for call completion" step, after which more DTMF signals get emitted. For example, lots of voicemail systems use a common phone number, and then they expect the desired mailbox number as a series of DTMF digits so you can leave a message for that mailbox 📫 Plenty of gateways can interpret strings like that, but there's no standardized way to write them down, which causes interoperability problems between endpoints 😩 This is another case where being able to say "a dial string is being presented here" would be super useful 🌸

2. Terminology 📚

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

It's assumed you already know the terminology and acronyms from [RFC3261] 🤓

3. Requirements 🎯

A mechanism to express a dial string in a 'sip:' or 'sips:' URI is required. A dial string is made up of:

the digits 0-9
the special characters # and *
the DTMF digits A-D
characters representing a short pause, and a "Wait for call completion" in a dial string

Note: DTMF = dual tone multi-frequency. Each "tone:" is actually two frequencies superimposed 🎵 DTMF is a 4 x 4 matrix with four row frequencies (697, 770, 852, 941 Hz) and four column frequencies (1209, 1336, 1477, 1633). Most telephones only implement 3 of the 4 columns, and those are used just the way the telephone dial pad suggests. So the digit 2 is in the first row, second column, and it's made of the 770Hz and 1209Hz frequencies mixed together 🍓 The fourth column isn't used in the PSTN (Public Switched Telephone Network). The "digits" for the fourth column are usually written as the letters A through D, so "C" is 852/1633Hz. Some systems do use these digits, so they're included in the definition of the dial string 💜

A dial string always exists within a context. The context MUST be specified when expressing a dial string 🗺️

It MUST be possible to distinguish between a dial string and a user part that happens to consist of the same characters 👀

4. Solution 🔥

There's a new alternative value for the "userinfo" parameter of the 'sip:' or 'sips:' URI schemes, and it's called "dialstring" 🎀 You can use this value in a 'sip:' or 'sips:' URI when the user part is a dial string. The dial string is a sequence of the characters 0-9, A-F, P, X, '*' and '#'. E represents *, F represents #, P is a pause (a short wait, like a comma in a modem string), and X represents "wait for call completion" 🌈

When "user=dialstring" is used, a context parameter, as defined in [RFC3966], MUST be specified. The context parameter would normally be a domain name 🏡 That domain name doesn't have to resolve to any actual host, but it MUST be under the administrative control of the entity managing the local phone context. The context parameter value is normally configured in the user agent ⭐

The syntax of the context parameter follows the same conventions as the same parameter in [RFC3966]. It shows up between the digits and the "@" in the userinfo [RFC3261] of the URI:

    dialstring = dialstring-digits context; context from RFC 3966
    dialstring-digits = *dialstring-element dialstring-digit
                *dialstring-element
    dialstring-digit = HEXDIG / "*" / "#"; HEXDIG from RFC 3966
    dialstring-element =  dialstring-digit  / "P" / "X" /
                visual-separator; visual-separator from RFC 3966

A dial string SHOULD NOT be used for an AoR (Address of Record) in a REGISTER 🙅 Parameters get ignored in registration. So two registrations with different phone-contexts would be treated as equivalent, which is probably not what you want 🙈

A proxy server or Back to Back User Agent (B2BUA) [RFC3261], which is authoritative for the context, may translate the dial string into a telephone number or a service invocation URI. The telephone number MAY be expressed as a global or local tel: URI, or it MAY be left as a sip: or sips: URI with the URI parameter value changed from "user= " to "user=phone" 🦋

Here are some examples of dial string use 💖

;what a SIP Phone might emit when a user dials extension 123
sip:123;phone-context=atlanta.example.com@example.com;user=dialstring

;existing voicemail systems have a local access extension,
;then expect to see the extension number as DTMF for the mailbox
sip:450X123;phone-context=biloxi.example.com@example.com;user=dialstring

5. IANA Considerations 🗂️

[RFC3969] defines a 'sip:' or 'sips:' URI Parameter sub registry. The "user" parameter is specified as having predefined values.

This RFC defines a new value for the "user" parameter, "dialstring". It's also been added to the references listed for the "user" parameter 🧾

6. Security Considerations 🚨

Okay, this section is serious, so listen up 😱 Dial strings exposed to the Internet may reveal information about internal network details or service invocations. That could let attackers use the PSTN or the Internet to go after those internal systems. Dial strings normally SHOULD NOT be sent beyond the domain of the UAC (User Agent Client). If they do go across the Internet, they SHOULD be protected against eavesdropping with TLS (Transport Layer Security) per the procedures in [RFC3261] 🔐💀

7. Normative References 📖

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

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

   [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Uniform Resource Identifier (URI) Parameter
              Registry for the Session Initiation Protocol (SIP)",
              BCP 99, RFC 3969, December 2004.

Author's Address 🎀

Brian Rosen
NeuStar
470 Conrad Dr
Mars, PA  16046
USA

Phone: +1 724 382 1051
EMail: br@brianrosen.net

Full Copyright Statement ⚖️

This document is subject to the rights, licenses and restrictions contained in BCP 78, 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 on 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 on whether any license under such rights might or might not be available. It also doesn't claim it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt 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 online IPR repository at http://www.ietf.org/ipr.

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. Send that info to the IETF at ietf-ipr@ietf.org 🫶

Acknowledgement 🌸

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

📦 where this page comes from

ietf: rfc4967 2007-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms