Summary:ASTERISK-01437: chan_zap doesn't check for multiple / ambiguous matches on PRI overlap dialling
Reporter:apollon (apollon)Labels:
Date Opened:2004-04-20 05:37:39Date Closed:2008-01-15 14:53:08.000-0600
Versions:Frequency of
Environment:Attachments:( 0) zapdiff
Description:chan_zap doesn't check for multiple or ambiguous extensions in overlap dialling (before audio mode is established) and thus won't allow for variable-length extensions.
Comments:By: Mark Spencer (markster) 2004-04-20 11:27:32

I don't believe there is a workable solution here within the PRI specification, because we have to respond with SETUP_ACK.  Is it permissible to send a CALL PROCEEDING after sending SETUP_ACK without having received another SETUP?

By: James Golovich (jamesgolovich) 2004-04-21 02:14:44

This can get complicated.  We probably should get t302 implemented.

I believe we should be sending the SETUP_ACK right away, reading the INFO messages until either we get the Sending Complete IE or the timer expires.

When we get a match in either of those cases we should be sending either an ALERT or CALL PROCEEDING

Been a while since I've dug into this though.

By: Mark Spencer (markster) 2004-04-23 09:57:22

Actually looking at Q.931 it looks like we can do this trick, it's just gonna take some time.

By: apollon (apollon) 2004-04-23 10:41:20

Is this actually a trick? After some discussion (and some background reading on Q.931) I have reached a tentative conclusion that what's actually missing here is indeed the T302 timer. I just started scanning the q931.c code today... I hope I'll have some feedback to provide by Wednsday.

By: Mark Spencer (markster) 2004-04-26 00:37:25

Right the T302 timer can do it, although you ahve to look at the table to see that it's actually permissible to send PROGRESS at its expiration as well.

By: Mark Spencer (markster) 2004-04-28 10:33:18

Maybe we can make PRI use ss_thread as well.  Perhaps I can login to your system and implement it.

By: Mark Spencer (markster) 2004-05-01 23:32:01

This should be fixed in latest CVS.  Please confirm.

By: Mark Spencer (markster) 2004-05-02 12:44:42

I'm upgrading this to "major" since it is now implemented and I want to be sure it's carefully tracked.  It is closely related to bug ASTERISK-1074

By: apollon (apollon) 2004-05-03 08:10:06

I checked the cvs version. It appears that my digits are coming in as INFO events, but not in overlap mode. I don't really know why that is happening, but by removing the overlap check I managed to get the system to work and accept calls (not thouroughly tested, yet). Don't take the patch seriously, I'm no coder :D

By: Mark Spencer (markster) 2004-05-03 09:11:14

Just add "overlapdial=yes" to your zapata.conf to enable support for overlapdial.

By: Mark Spencer (markster) 2004-05-03 23:44:55

Again, please try to answer as timely as possible.

By: apollon (apollon) 2004-05-04 04:25:54

Indeed, the overlap setting changed *'s behaviour - sorry for the blunder. I reversed all my changes, and everything seems to be in perfect order in all parts of my dialpan. Thanks Mark!!! and sorry for the delay.

By: Mark Spencer (markster) 2004-05-04 10:09:10

Fixed in CVS!

By: Digium Subversion (svnbot) 2008-01-15 14:53:08.000-0600

Repository: asterisk
Revision: 2854

U   trunk/channels/chan_zap.c

r2854 | markster | 2008-01-15 14:53:07 -0600 (Tue, 15 Jan 2008) | 2 lines

Make overlap dial be interpreted in the same way an FXS would be (bugs ASTERISK-1074 and ASTERISK-1437)