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

[Raj Jain]

On Tue, Apr 29, 2008 at 12:56 AM, Tilghman Lesher <
tilghman at mail.jeffandtilghman.com> wrote:

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

My question is whether this should be done in a stateless or stateful manner
through Asterisk. Proxy vs. B2BUA or protocol agnostic handling are
irrelevant from that perspective.

There are a couple of modes in which Asterisk could potentially participate
in overlap dialing:

1. Overlap to en-bloc gateway (as described in RFC 3578)
2. End-to-end overlap

End-to-end overlap mode (the subject of this email thread) is where the
phone and trunk both support overlap signaling. This is a scenario where
Asterisk isn't aware of the numbering plan and thus relies on an upstream
entity to decide how many digits should be dialed. A common deployment
scenario for this PBX-PBX trunking using Q.SIG. Since SIP doesn't exactly
support overlap signaling, we rely on the 484 message to signal to the UAC
that more digits need to be sent.

Now the question is should Asterisk call processing (dial-plan) do something
(e.g. remember the state) when it receives an address incomplete message on
the trunk (SIP, ISDN or whatever). The thing about SIP 484 is that it is a
final response code and the INVITE transaction is over as soon as the 484 is
received. The next INVITE will contain a completely different transaction id
and call id, so you can't correlate the INVITE's anyway. That is why I was
thinking that 484 should be treated simply as call failure such as 404. All
we should have to do is tell the phone to send more digits if our trunk
provider tells us that.

-- 
Raj Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080429/0c06f62f/attachment.htm