[Asterisk-Users] New RFC: How to specify a phone number

[John Todd]

>A new RFC was published today, RFC 3601:
>
>Abstract:
>"This memo describes the full set of notations needed to represent a
>    text string in a Dial Sequence.  A Dial Sequence is normally composed
>    of Dual Tone Multi Frequency (DTMF) elements, plus separators and
>    additional "actions" (such as "wait for dialtone", "pause for N
>    secs", etc.) which could be needed to successfully establish the
>    connection with the target service:  this includes the cases where
>    subaddresses or DTMF menu navigation apply."
>
>ftp://ftp.rfc-editor.org/in-notes/rfc3601.txt
>
>This RFC is synchronized with many other documents, from ETSI and 
>ITU as well as the IETF standard for
>TEL: URL:s.
>
>Any Asterisk-pro' out there that can check if Asterisk conforms to this or
>if there's any changes needed? It would make life easier if there was
>only one way to specify phone numbers, DMTF and pauses in URL:s and
>dial plans - or are there reasons not to follow the IETF RFC?
>
>/Olle


I've been waiting for a document like this for a while.  It might 
have existed in the annals of the IEEE or ITU, but I'm pleased to see 
an RFC making an "official" ruling.

These dial strings might only be interpreted specially in Zap or 
other "hardware" channels that connect directly to PSTN equipment. 
Do they mirror what is in Asterisk now?   I suppose I should test out 
insertion of "." and "-" characters in a dial string, but I'll do 
that after I've had a bit more sleep.

Basically:
   0-9, *, #, A, B, C, D   = valid dialing digits (note: does lower 
case abcd work?)
   p = 1 second pause
   w = wait for alternate dialtone
   . and - are valid non-parsed characters (human-readable, machine-ignored)
   + is the character proceeding all global phone numbers (ignored by 
machine dialers)

Read the RFC for the "real" data; my shorthand is not adequate for 
all possible combinations.

JT