[asterisk-dev] Overlapped dialing: SIP, IAX, Zap, et al

[Timo Teräs]

Hi all,

I've been thinking about the overlapped dialing support in Asterisk and I have several thoughts regarding to different protocols and the implementation in Asterisk in general.

First of all, it seems that Asterisk was originally done only with en-bloc dialing support. And it looks like all the overlapped stuff was added later on without proper support in Asterisk core code.

Some thoughts about the issues:

1. chan_zap is one of the places that needs it most (since overlapped dialing is still needed in ISDN world). It appears that chan_zap does lots of the overlapped stuff in channel specific code (e.g. it has code to wait additional digits until extension matches; imho this should be in dialplan core code).

2. IAX does not have real support for overlapped digits, but when channel has not yet indicated ringing, chan_zap translates the overlapped stuff to DTMF events. Thus Zap-IAX-Zap bridging works properly with overlapped dialing. However, Asterisk core does not know about the additional digits and CDR records contain bad number which is a major problem for me, at least.

3. SIP doesn't have proper overlapped support either way. RFC 3578 explains how SIP should work:
Incoming:
a. If from dialplan we can make see that the number is incomplete we send 484 back (this is implemented).
b. If in dialplan we have only one matching ! number we should match immediately (should work too).
c. If we have unknown number length e.g. a . rule we should wait for inter-digit-delay until returning 484 and wait for new INVITEs (not done).
d. If we get new INVITE (with same Call-ID and From tag; only updated Request-URI) while old INVITE is pending we should get the new digits and reply old INVITE with 484 (see RFC 3578, section 3.5) (not done).

Outgoing:
a. We should send overlapped digits using the multiple INVITE scheme as defined in RFC (not done).
b. Handle immediate 484 replies (new code just committed; should work).
c. Handle delayed 484 replies (not working).

4. The Incomplete stuff that was just recently added basically does the same that chan_zap does when "immediate=off". E.g. now chan_zap and core duplicates core and it might be unclear which should be used and how things work with different channel drivers. E.g. I wanted the Incomplete stuff for my call routing to work properly in Zap->IAX->Zap scenario. E.g. Zap->IAX worked perfectly. But received IAX call would work only if there was one matching ! rule. But I have multiple.

I'm now thinking that we should implement some helper code in the core (e.g. channel has "overlapped" mode where dtmf digits will be translated to overlapped signaling if supported by channel driver. This would have several benefits. It would reduce code in channel drivers, make the system handle calls consistently no matter which channel driver they are using, overlapped calls would get proper CDR record (ie. record would contain the complete number; not just the first match in dialplan) and overlapped stuff would be easier to implement in other channel drivers.

I hope we can get a good discussion what should be done. I'm also available to help coding to some degree.

Cheers,
  Timo