[asterisk-users] Overlap SIP dialing

[Kevin P. Fleming]

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

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: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org