Skip to main content

Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier
RFC 4967

Revision differences

Document history

Date Rev. By Action
2020-01-21
05 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
05 (System) Notify list changed from br@brianrosen.net to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2007-07-31
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-07-31
05 Amy Vezza [Note]: 'RFC 4967' added by Amy Vezza
2007-07-27
05 (System) RFC published
2007-05-27
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-05-24
05 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2007-05-06
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-05-03
05 (System) IANA Action state changed to In Progress from Waiting on ADs
2007-05-01
05 (System) IANA Action state changed to Waiting on ADs from In Progress
2007-04-19
05 (System) IANA Action state changed to In Progress
2007-04-17
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-04-16
05 Amy Vezza IESG state changed to Approved-announcement sent
2007-04-16
05 Amy Vezza IESG has approved the document
2007-04-16
05 Amy Vezza Closed "Approve" ballot
2007-04-16
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-03-02
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-03-02
05 (System) New version available: draft-rosen-iptel-dialstring-05.txt
2007-03-02
05 Jon Peterson State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jon Peterson
2006-06-28
05 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2006-06-27
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-06-27
04 (System) New version available: draft-rosen-iptel-dialstring-04.txt
2006-04-28
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-04-28
05 (System) Removed from agenda for telechat - 2006-04-27
2006-04-27
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by IESG Secretary
2006-04-27
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-04-27
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-04-27
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-04-27
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-04-26
05 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Yes from Undefined by Cullen Jennings
2006-04-26
05 Cullen Jennings [Ballot comment]
Small problem in that 3969 reference looks wrong and 3rd para in section 5 refers to 3969 instead of 3966.
2006-04-26
05 Cullen Jennings [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings
2006-04-26
05 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2006-04-26
05 Lisa Dusseault [Ballot comment]
Is the length of a pause defined anywhere?
2006-04-26
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-04-26
05 Brian Carpenter
[Ballot comment]
I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set?

And, why …
[Ballot comment]
I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set?

And, why is this document a direct submission rather than an IPTEL WG document?

Gen-ART review from Tom Taylor. Brian Rosen agrees with the proposed clarifications:

Substantive comments:
=====================

1. I believe the problem is mis-stated in the second paragraph of
section 1. Ignoring the matter of RFC 2806-based implementations, the
user part of a SIP URI with the "user=phone" parameter is, without
ambiguity, a phone number. The real problem is that before the
transformation occurs (and the "user=phone" parameter is added if
applicable), entities beyond the originating point cannot distinguish
between a dial string and an user part that happens to consist of the
characters that can be present in a dial string. I suggest that the
second paragraph be replaced by the following:

"There is a problem here. The intermediary can apply its transformation
only if it recognizes that the user part of the SIP URI is a dial
string. However, there is currently no way to distinguish an user part
consisting of a dial string from an user part that happens to be
composed of characters that would appear in a dial string."

It is also necessary to change the second-last requirement in section 3
as follows:

Current text:
"  It MUST be possible to distinguish between a dialstring and a phone
    number."

New text:
"  It MUST be possible to distinguish between a dialstring and an user
part that happens to consist of the same characters."


2. The requirement in section 3 that a context be present is
unmotivated. I suggest adding the following sentence at the end of the
first paragraph of section 1:

" The intermediary is able to perform this transform provided that it
knows the context (i.e., dialling plan) within which the number was
dialled."

3. In section 3, a dial string is defined to consist of a certain set of
characters, but then the requirement to convey pause and "wait for call
completion" is added. It would be cleaner to include the characters for
the latter functions in the definition of dial string in the first
place. I therefore suggest the following changes:

  -- move the requirement to represent pause and "wait for call
completion" from its present position near the end of the section to
follow the first sentence/requirement of the section.

  -- add the following bullet point to the list of characters in a dial
string:

    <* Characters to express "pause" and "wait for call completion".>

Editorial comments
==================

General: "user part" and "dial string" (except as a parameter value),
not "userpart" and "dialstring".

Section 1, para 1, second sentence: "One enters ..." -> "The user enters
...".

Section 1, para 1, third sentence:
"The entered sequence, called a "dialstring", may ..."
                                            ^ ^^^

Section 1, para 3, first sentence: "post dial" -> "after the initial
number has been dialled".

Section 1, para 3, second sentence: "functions" -> "function".

Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of
DTMF digits".

Section 1, para 3: add this sentence at the end to make the point of the
paragraph:

"This is another case where the ability to indicate that a dialstring is
being presented would be useful."

Section 3, dial string character list, third bullet:
"* The MF digits A-D" -> "* The DTMF digits A-D"

Section 3, note on DTMF following the bullets: suggest this be indented
(empty list item in XML2RFC) to show its informative status.

Section 4 para 1, final sentence:
"E represent *" -> "E represents *"
<X represents call completion> -> <X represents "wait for call completion">

Section 4 para 2, final sentence:
current: <change the URI to specify user=phone.>
proposed: <change the URI parameter value from "user=dialstring" to
"user=phone".>

Section 4, voicemail example: to be consistent with the motivation in
section 1, one would expect the dial string to be 4500X4123 rather than
4500P4123.

Section 5, second para, second sentence: "This RFC would" -> "This RFC
must".

Section 5, third para, end: "[RFC3969]" -> "[RFC3966]"

References, [RFC3969] repeats citation for [RFC3966] rather than giving
the details for RFC 3969.
2006-04-26
05 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Undefined by Brian Carpenter
2006-04-26
05 Brian Carpenter
[Ballot comment]
I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set?

And, why …
[Ballot comment]
I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set?

And, why is this document a direct submission rather than an IPTEL WG document?
2006-04-26
05 Brian Carpenter [Ballot Position Update] New position, Undefined, has been recorded for Brian Carpenter by Brian Carpenter
2006-04-26
05 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Undefined by Dan Romascanu
2006-04-26
05 Dan Romascanu
[Ballot comment]
1. I believe that the readability of the document would be improved if the acronyms would be expanded at the first occurence or …
[Ballot comment]
1. I believe that the readability of the document would be improved if the acronyms would be expanded at the first occurence or in the terminology session. Some of the acronyms that could use such a help are URI, SIP, SIPS (in the title and Abstract) and B2BUA.
2. There is no separation of the References section into Normative and Informative
2006-04-26
05 Dan Romascanu [Ballot Position Update] New position, Undefined, has been recorded for Dan Romascanu by Dan Romascanu
2006-04-25
05 Jon Peterson State Change Notice email list have been change to br@brianrosen.net from brian.rosen@marconi.com
2006-04-25
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2006-04-25
05 Sam Hartman
[Ballot comment]
It would be good if this document gave (or perhaps better pointed to)
some advice for how a user agent determines the context …
[Ballot comment]
It would be good if this document gave (or perhaps better pointed to)
some advice for how a user agent determines the context to use.  For
example I don't know how the phone on my desk would be both usable,
not require vendor-specific configuration and stick something
reasonable in the context.  I'm also not all that sure that the
context needs to be reasonable.  Presumably the target SIP server will
just take the dialstring and dial it in many cases.
2006-04-25
05 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2006-04-25
05 Magnus Westerlund
[Ballot discuss]
* IANA consideration, third paragraph:

This RFC defines a new parameter in the sub-registry, "phone-
  context", whose meaning and syntax are derived …
[Ballot discuss]
* IANA consideration, third paragraph:

This RFC defines a new parameter in the sub-registry, "phone-
  context", whose meaning and syntax are derived from the same
  parameter in [RFC3969]

As there is no "phone-context" parameter defined in RFC 3969 is it RFC 3966 that is intended in the above reference?
2006-04-24
05 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Undefined by Lars Eggert
2006-04-24
05 Lars Eggert [Ballot comment]
Section 4: What's a "B2BUA?"

Security considerations are weak ("normally should not be sent (...) without some kind of protection").
2006-04-24
05 Lars Eggert [Ballot Position Update] New position, Undefined, has been recorded for Lars Eggert by Lars Eggert
2006-04-24
05 Michelle Cotton
IANA Comments:
Upon approval of this document, the IANA will add this document as a reference for the "user" SIP/SIPS URI Parameter.

The IANA will …
IANA Comments:
Upon approval of this document, the IANA will add this document as a reference for the "user" SIP/SIPS URI Parameter.

The IANA will also add "phone-context" to the SIP/SIPS URI Parameter registry located at the following:
http://www.iana.org/assignments/sip-parameters
Are there any predefined values for the phone-context parameter?
(This question is appears to be similar to Magnus' discuss)

We understand the 2 actions described above to be the only IANA Actions.
2006-04-24
05 Magnus Westerlund
[Ballot discuss]
* IANA consideration, third paragraph:

This RFC defines a new parameter in the sub-registry, "phone-
  context", whose meaning and syntax are derived …
[Ballot discuss]
* IANA consideration, third paragraph:

This RFC defines a new parameter in the sub-registry, "phone-
  context", whose meaning and syntax are derived from the same
  parameter in [RFC3969]

As there is no "phone-context" parameter defined in RFC 3969 is it RFC 3966 that is intended in the above reference?

* First page header and abstract:
Discuss Discuss: Should documents adding functionality to specification that has a registry also include Updates RFC xxxx or is this handled through the IANA registry? To me it seems a good thing if the RFC also is visable as updating the URI spec through the RFC inforamation thus adding an update statement would be positive. The downside is if there is many additions the reader of the RFC can get confused by the massive update list.
2006-04-24
05 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to Discuss from Undefined by Magnus Westerlund
2006-04-24
05 Magnus Westerlund [Ballot Position Update] New position, Undefined, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-04-21
05 Jon Peterson State Changes to IESG Evaluation from Waiting for Writeup by Jon Peterson
2006-04-21
05 Jon Peterson Placed on agenda for telechat - 2006-04-27 by Jon Peterson
2006-04-21
05 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2006-04-21
05 Jon Peterson Ballot has been issued by Jon Peterson
2006-04-21
05 Jon Peterson Created "Approve" ballot
2006-04-21
05 (System) Ballot writeup text was added
2006-04-21
05 (System) Last call text was added
2006-04-21
05 (System) Ballot approval text was added
2006-04-20
05 Jon Peterson State Changes to Waiting for Writeup from AD Evaluation::AD Followup by Jon Peterson
2006-03-07
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-03-07
03 (System) New version available: draft-rosen-iptel-dialstring-03.txt
2006-02-06
05 Jon Peterson State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jon Peterson
2005-10-12
05 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2005-07-27
05 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-07-19
02 (System) New version available: draft-rosen-iptel-dialstring-02.txt
2005-02-14
01 (System) New version available: draft-rosen-iptel-dialstring-01.txt
2004-06-03
00 (System) New version available: draft-rosen-iptel-dialstring-00.txt