Skip to main content

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

Yes

(Jon Peterson)

No Objection

(Bill Fenner)
(David Kessens)
(Jari Arkko)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Ted Hardie)

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert No Objection

Comment (2006-04-24)
Section 4: What's a "B2BUA?"

Security considerations are weak ("normally should not be sent (...) without some kind of protection").

(Cullen Jennings; former steering group member) Yes

Yes (2006-04-26)
Small problem in that 3969 reference looks wrong and 3rd para in section 5 refers to 3969 instead of 3966.

(Jon Peterson; former steering group member) Yes

Yes ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2006-04-26)
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.

(Dan Romascanu; former steering group member) No Objection

No Objection (2006-04-26)
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

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection (2006-04-26)
Is the length of a pause defined anywhere?

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection (2006-04-25)
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.

(Ted Hardie; former steering group member) No Objection

No Objection ()