[asterisk-users] Overlap SIP dialing

[Daniel Tryba]

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 at 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 at 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