[asterisk-dev] Overlapped dialling on SIP trunks for outgoing calls

[Tilghman Lesher]

On Tuesday 29 April 2008 01:57:59 Klaus Darilion wrote:
> Tilghman Lesher wrote:
> > On Monday 28 April 2008 15:08, Klaus Darilion wrote:
> >> How do SIP phones with overlap dialing handle the following scenario:
> >> 1. User presses "1"
> >> 2. SIP phone sends INVITE sip:1 at ....
> >> 3. user presses "2"
> >> 4. what happens now? does the phone CANCEL sip:1 at ... and INVITE
> >> sip:12 at ..?
> >
> > That depends on 1) what's in your dialplan, and 2) how the remote end
> > responds.  If the remote end sends a 484, trunk will now cause Dial to
> > exit with status AST_PBX_INCOMPLETE, which will allow the dialplan to
> > accept additional digits.
>
> Sorry - I have to make myself more clear. I am interested in the phone's
> behavior.
>
> Consider the scenario where Asterisk itself does not know if the number
> is complete but forwards the number upstream (SIP or ZAP or whatelse).
>
> This might look like:
>
> phone              Asterisk              PSTN
> ---INVITE 1---------->
> <--------100----------
>                        ---INVITE 1---------->
>                        <------484/Cause 28---
> <--------484----------
> ---------ACK--------->
>
> ---INVITE 12--------->
> <--------100----------
> ...
>
> In the previous example it is rather clear. But what if the answer from
> the PSTN takes longer as the user dials? E.g.
>
>
> ---INVITE 1---------->
> <--------100----------
>                        ---INVITE 1---------->
>                        (waiting for response)
> (now user pressed digit 2)
>
> How will a SIP phone which support overlap dialing behave now? Will it
> CANCEL 1 and INVITE 12 or will it wait for an 200/484 response bevor it
> decides if it will send a new INVITE?

I'm still working on getting the 484 back to the SIP channel.  Right now, it's
better in that Asterisk won't end the call, but it currently waits for more
digits in the PBX core, which is not optimal for SIP, because we'd like the
SIP phone to continue collecting digits.

What I'm planning on doing is using one of the channel flags to indicate
whether a channel type can individually handle the incomplete indication,
and if it can, we'll pass the cause code back to the channel type (which is
then responsible for issuing a 484 in the case of SIP, or some other
indication for another channel type).  If it can't, we'll wait in the PBX core
for more digits or a timeout.

-- 
Tilghman