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. > However, this is still going to 'mess with CDRs' as you put it, because > the only switch in the network that knows the complete number that was > dialed is the PSTN switch that your PRI is connected to. It seems > possible that chan_dahdi could 'update' the EXTEN on the current channel > as the additional digits are dialed so that the CDR contains the > complete number, but I have no idea whether it does or not. Didn't think about this CDR problem (was only concerned about billsec). As far as I can see this doesn't happen in 1.6.2.x. The lack of destination in CDR makes overlap dialing useless since I can't bill my customers. -- Daniel Tryba -- _____________________________________________________________________ -- 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