Olle E. Johansson
2003-Sep-10 11:32 UTC
[Asterisk-Users] New RFC: How to specify a phone number
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
>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? > >/OlleI'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
Reasonably Related Threads
- X100P callerid ETSI - caller*ID failed checksum
- Q: ISDN / E1-PRI - fax problems - Receiving and setting of Service Indicator (SIN) / Bearer Capability (BC) / High Level Compatibility (HLC) / Low Level Compatibility (LLC)
- E1 and/or Euro-ISDN specifications?
- Compiling Asterisk with G.723.1
- Dumb question (hang up detection/Zapata.conf)