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

[Tilghman Lesher]

On Monday 28 April 2008 19:47:53 Raj Jain wrote:
> On Mon, Apr 28, 2008 at 4:41 PM, Tilghman Lesher <
>
> tilghman at mail.jeffandtilghman.com> wrote:
> > On Monday 28 April 2008 14:41, Andreas Brodmann wrote:
> > > One thing I am not sure about - would your patch also cover the
> >
> > following
> >
> > > scenario
> > > for international numbers with unknown length?
> > >
> > > exten => _000!,1,Incomplete
> > > exten => _000!,n,Dial(SIP/${EXTEN:1}@carrier,120)
> >
> > That will never work.  Calling the Incomplete application means that the
> > dialplan will wait for more digits (and so the dialplan will restart).
> >  You
> > need a more exact extension in the same context (or else the Incomplete
> > app
> > needs to go into an included context).
>
> May be I'm missing something basic and someone can help clarify it for me.
> I've dealt with this with Cisco Call Manager 6.X and Cisco 7960 phones that
> support KPML (KeyPad Markup Language; a dialplan language expressed in XML)
> that support this feature. The part that escapes me is that why do we need
> Asterisk dial-plan to be stateful across INVITE/484 pairs if both the SIP
> phone and the SIP trunk understand the 484 semantics.
>
> Why can't we treat 484 received on the SIP trunk as a failed call and
> propagate that specific response code to the phone and eliminate that state
> from the Asterisk dial-plan?  Remember that the phone sends the previous
> digits in the new INVITEs after receiving 484s so that the To: or R-URI
> eventually satisfies the SIP trunk provider's routing plan.
>
> But like I said, I may be missing something basic. What would that be?

You're missing that Asterisk is not a SIP proxy.  That would be the expected
behavior of a SIP proxy, but Asterisk is a Back-To-Back-User-Agent, which
means that Asterisk needs to actually understand the code passed back and
needs to be able to deal with that code in a protocol agnostic way.

-- 
Tilghman