[Asterisk-Users] PRI/Zap premature dialing problem
Jerry Glomph Black
asterisk-users at glomph.com
Tue Dec 7 03:42:14 MST 2004
Peter, thanks for educating this ISDN-ignorant American! The ASCOM and the
problem are in Germany. This is definitely overlap dialing in the extreme,
from looking at the PRI debug output of asterisk. I set overlapdial=yes in zapata.conf, with no
difference observed in the behavior.
Here's the PRI debug output. Each dialed digit (from an Ascom desk phone) is
transmitted separately, immediately when the user presses the key.
(essentially the same as if it were sending DTMF). Asterisk is jumping
instantly on the first match, even tthough there is a pattern _2XXX in the same
dialplan, with higher priority (the 224 is in an include=> context to suppress
it).
So when I want to get to extension 2246, I have no chance, it immediately jumps to 224.
I agree that modifying the ASCOM behavior would probably be better, but that is
a slow and expensive strategy, there must be some way to get Asterisk to play
well with this simple digit-by-digit inbound dialing method...
----- PRI DEBUG LOG...Please excuse the verbosity!! -----
< Protocol Discriminator: Q.931 (8) len=30
< Call Ref: len= 2 (reference 36/0x24) (Originator)
< Message type: SETUP (5)
< Bearer Capability (len= 3) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< Ext: 1 User information layer 1: A-Law (35)
< Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
< ChanSel: Reserved
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 31 ]
< Calling Number (len=11) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Unknown (52) '1520440' ]
< IE: High-layer Compatibility (len = 4)
-- Making new call for cr 36
-- Processing Q.931 Call Setup
-- Processing IE 4 (Bearer Capability)
-- Processing IE 24 (Channel Identification)
-- Processing IE 108 (Calling Party Number)
-- Processing IE 125 (High-layer Compatibility)
> Protocol Discriminator: Q.931 (8) len=14
> Call Ref: len= 2 (reference 32804/0x8024) (Terminator)
> Message type: SETUP ACKNOWLEDGE (13)
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 31 ]
> Progress Indicator (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Called equipment is non-ISDN. (2) ]
< Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 36/0x24) (Originator)
< Message type: INFORMATION (123)
< Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '2' ]
-- Processing IE 112 (Called Party Number)
< Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 36/0x24) (Originator)
< Message type: INFORMATION (123)
< Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '2' ]
-- Processing IE 112 (Called Party Number)
< Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 36/0x24) (Originator)
< Message type: INFORMATION (123)
< Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '4' ]
-- Processing IE 112 (Called Party Number)
-- Executing Goto("Zap/31-1", "default|nikoflat|1") in new stack
-- Goto (default,nikoflat,1)
-- Executing Dial("Zap/31-1", "IAX2/pbx:dummkopf at 192.168.50.254/nikoflat|16") in new stack
-- Called pbx:dummkopf at 192.168.50.254/nikoflat
-- Accepting call from '41520440' to '224' on channel 31, span 1
-- Call accepted by 192.168.50.254 (format ULAW)
-- Format for call is ULAW
-- IAX2[192.168.50.254:4569]/1 is ringing
> Protocol Discriminator: Q.931 (8) len=10
> Call Ref: len= 2 (reference 32804/0x8024) (Terminator)
> Message type: CALL PROCEEDING (2)
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 31 ]
> Protocol Discriminator: Q.931 (8) len=14
> Call Ref: len= 2 (reference 32804/0x8024) (Terminator)
> Message type: ALERTING (1)
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
> ChanSel: Reserved
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 31 ]
> Progress Indicator (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 36/0x24) (Originator)
< Message type: DISCONNECT (69)
< Cause (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the remote user (5)
< Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Processing IE 8 (Cause)
-- Channel 31, span 1 got hangup
-- Hungup 'IAX2[192.168.50.254:4569]/1'
== Spawn extension (default, nikoflat, 1) exited non-zero on 'Zap/31-1'
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 32804/0x8024) (Terminator)
> Message type: RELEASE (77)
> Cause (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Hungup 'Zap/31-1'
< Protocol Discriminator: Q.931 (8) len=5
< Call Ref: len= 2 (reference 36/0x24) (Originator)
< Message type: RELEASE COMPLETE (90)
----- END OF PRI DEBUG LOG...Please excuse the verbosity!! -----
On Mon, 6 Dec 2004, Peter Svensson wrote:
> On Mon, 6 Dec 2004, Jerry Glomph Black wrote:
>
>> But... If I remove the 3-digit number (224) from the asterisk
>> dialplan, I have no problem dialing 2246 successfully. If the Ascom were just
>> seeing a 3-digit dialplan match for 224, would the fourth digit still be
>> transmitted along the PRI? This is the basis of the puzzle, it's as if
>> asterisk is feeding back some info about whether a complete number has been
>> passed along.
>
> In isdn you have two dialing concepts: enbloc and overlap.
>
> Enbloc is a complete number. The number is known at transmission time, and
> if it is too short an error is generated. The user can not add more
> numbers. The sending device will transmit a "sending complete" information
> element to signal that no more digits will be sent.
>
> In overlap sending more digits are added. "Sending complete" can be sent
> to signal that no more digits will come. The receiving end can send a
> "proceeding" message to the caller to signal that enough digits have been
> received to complete the call. More digits will be ignored or passed to
> the destination of the call.
>
More information about the asterisk-users
mailing list