On 09/08/2011 10:04 AM, Daniel Tryba wrote:
On Thu, Sep 08, 2011 at 08:38:39AM -0500, Kevin P. Fleming wrote:The following just works for any SIP client (without overlap dialing): exten => _X.,1,Answer() exten => _X.,n,Dial(${TRUNK})Unless I'm mis-remembering, this was the point of adding the '!' dialplan match character. If you use _X!, and you have your SIP endpoints configured to send an INVITE as soon as the user has entered two digits (and you have no other patterns in the context that could match), then the dialplan will match against that and initiate a Dial() on your ISDN PRI. Since the number is not yet complete, the SETUP message on the PRI won't result in the call proceeding, and as the user of the phone presses additional digits they'll be sent to Asterisk as DTMF, bridged over to chan_dahdi, and it will send them as INFORMATION messages rather than as DTMF digits, because it knows the outbound call is still in 'dialing' state.That is what I read, but I can't find any working examples. With the following context: [overlap] exten => _X!,1,Dial(${TRUNK) This happens: Caller hits a number, which is immediatly send with an INVITE. SIP endpoint receives a TRYING. A DAHDI channel is opened. SIP endpoint "locks up", no further input iws accepted. Nothing happens for 10s. SIP endpoint received a TRYING. Nothing happens for 40s. DAHDI fails, SIP endpoint received a 503 Service Unavailable: X-Asterisk-HangupCause: Mandatory information element is missing X-Asterisk-HangupCauseCode: 96 SIP => SIP/SDP Request: INVITE sip:0...@ouzo.pocos.nl, with session description SIP<= SIP Status: 100 Trying DAHDI=> Message Type: SETUP (5) DAHDI=> Calling Number DAHDI=> Presentation: Presentation permitted, user number not screened (0) '' ] DAHDI=> Called Number DAHDI<= Message Type: STATUS (125) DAHDI<= Cause DAHDI<= Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ] DAHDI<= Call State (len= 3) [ Ext: 0 Coding: CCITT (ITU) standard (0) Call state: Call Initiated (1) DAHDI<= Message Type: SETUP ACKNOWLEDGE (13) DAHDI<= Channel ID DAHDI<= ChanSel: As indicated in following octets DAHDI<= Ext: 1 Coding: 0 Number Specified Channel Type: 3 DAHDI<= Ext: 1 Channel: 1 Type: CPE] DAHDI<= Progress Indicator DAHDI<= Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] q931.c:7194 post_handle_q931_message: Call 32806 enters state 2 (Overlap Sending). Hold state: Idle DAHDI<= Message Type: CALL PROCEEDING (2) SIP<= SIP Status: 100 Trying DAHDI<= Message Type: DISCONNECT (69) DAHDI<= Message Type: RELEASE (77) DAHDI<= Cause DAHDI<= Ext: 1 Cause: Mandatory information element is missing (96), class = Protocol Error (e.g. unknown message) (6) ] DAHDI=> Message Type: RELEASE COMPLETE (90) DAHDI=> Cause DAHDI=> Ext: 1 Cause: Mandatory information element is missing (96), class = Protocol Error (e.g. unknown message) (6) ] SIP<= SIP Status: 503 Service Unavailable SIP => SIP Request: ACK sip:0...@ouzo.pocos.nl Notice the "Call 32806 enters state 2 (Overlap Sending)." This is not propagated to the SIP endpoint.
OK, yes, I can see how this would occur. Explicit Answer() (or even Progress()) before Dial() would resolve that problem, but makes the CDR situation even worse.
Honestly, I'm not really sure that there is a practical solution here. ISDN overlap dialing was intended for 'dumb' phones, and SIP phones aren't 'dumb' :-)
-- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
