[Home]

Summary:ASTERISK-05724: EM Wink problems
Reporter:Joel Scotkin (jscotkin)Labels:
Date Opened:2005-11-28 12:09:01.000-0600Date Closed:2008-01-15 16:06:13.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) em_trunk_patch
( 1) em_trunk_patch.7365
( 2) jscotkin-zapata.conf
( 3) jscotkin-zaptel.conf
( 4) zapata.conf
( 5) zaptel.conf
Description:I have a channelized T1 (Verizon Flexgrow) coming in with 3 E&M Wink channels for DID.  Asterisk up to and including version 1.2.0-beta1 seem to work fine for getting the full DID information through.  From beta2 onwards (including 1.2.0 final and CVS head as of today - Nov 28 2005) I'm only getting a single digit through for the DID information.

For example, my DID range includes (212) xxx-7220 through (212) xxx-7229. We are set up to receive 4 digits from the DID. Using beta1 I see "7220" come through on the console.  Using beta2 and on, I just see "7" come through.

I'm using a Digium TE410P card, and I've recompiled and reinstalled the full zaptel/libpri/asterisk set.

I think this may be related to bug 5323, which may have led to a change about the same timeframe.  

I can easily test any patches - this seems to be 100% reproducible - old version works, new one doesn't.

Thanks!
Joel
Comments:By: Will McCown (flynwill) 2005-11-28 23:06:30.000-0600

We've been having a similar problem (reported in an email to support@digium.com).

As with jscotkin's report the last version that worked for us was 1.2-Beta1,
everything since, including the current CVSHEAD has problems.

What we see is that on our E&M Wink DID trunks to AT&T the very first
call the system receives after a reboot typically works.  However,
most subsequent calls only receive the first digit and the remaining
digits, will be ignored and the digits from the previous call used
instead.

We have a test system which is set up with an E&M Wink T1 to our
existing phone system.  With that test setup I can reproduce the
second part of the problem quite reliably.  For example if I
place a call to the astrisk and pass the digits "1234567890",
the asterisk systems sees them all correctly.  However if I
connect again and send just "555" asterisk sees "5554567890"
that is it still sees the remainging digits from the previous
call.  An outbound call placed on the same trunk seems to clear
out the digits so that the next inbound call works.

We've started looking at the changes between Beta1 and Beta2,
in chan_zap.c and there was quite a lot.

By: Mark Spencer (markster) 2005-11-29 22:33:37.000-0600

Can you find me on IRC?  kram, irc.freenode.net...  I'd like to look at this.

By: Serge Vecher (serge-v) 2005-11-30 10:49:26.000-0600

jscotkin / flynwill:

Can you post your zaptel.conf & zapata.conf here? We are running E&M Wink DID trunks and not seeing DTMF problems with 11/21 HEAD. The only problems we see are with incorrect hangups that result in fake incoming calls (issue ASTERISK-5161), but that's a long-standing unrelated problem.

By: Will McCown (flynwill) 2005-11-30 11:02:05.000-0600

Ok, ours are there.
- Will

By: Joel Scotkin (jscotkin) 2005-11-30 14:06:20.000-0600

Mine up are up as well.  The files are basically unchanged from "make samples".  In zapata.conf I set "signalling=em_w" and "channels=1-3".  In zaptel.conf "e&m=1-3".

Thanks!

By: Serge Vecher (serge-v) 2005-12-01 12:02:29.000-0600

jscotkin: I think you have a lot of unrelated (AFAIK) settings in your zapata.conf for your configuration (you have E&M Wink not PRI). I've removed a lot of problems in my config by enabling only applicable settings. Here are my comments:
1) switchtype=national (PRI setting, not E&M)
2) usecallerid=yes (I believe this is for FXO signalling, on E&M signalling CallerID is passed in a DID string, if at all)
3) hidecallerid=no (ditto)
4) callwaiting=yes (FXO signalling --> this caused problems in my case)
5) usecallingpres=yes (PRI setting, AFAIK)
6) callwaitingcallerid=yes (FXO)
7) threewaycalling=yes (FXO)
8) transfer=yes
9) cancallforward=yes

Try to remove these settings and see if your problem is fixed.

By: Lance Kimes (lkimes) 2005-12-05 17:19:29.000-0600

flynwill and I believe that we've found the problem in chan_zap. It appears to have been introduced in revision 1.496 of chan_zap.c. A new while loop methodology was introduced in that revision between beta1 & beta2 when dealing with e&m trunks. The extension string was never zero terminated in this new while loop. The loop would grab a digit or 2 and insert them into the proper position in the char array. If that extension, along with the rest of the string, matched an extension in the dialplan, then no more digits were read and the extension was passed on.

I have patched the code to add zero termination whenever new digit is added in the while loop. I will be posting the patch shortly.

Lance Kimes
Rhythm and Hues Studios

By: Will McCown (flynwill) 2005-12-06 08:55:12.000-0600

lkimes' patch isn't quite complete -- You actually have to append
the zero in two different places, will upload a revised patch later
today.

jscotkin:

Testing with our AT&T trunks this morning this does fix our
problem.  Unfortunately it doesn't really explain your problem
with just getting the "7" -- unless "7" is a complete match
in your dialplan.  (eg There was a goto a different context on "7".)

What breaks out of the loop early is such a match (which without
the zero being inserted matches on whatever was left in the buffer
from the previous call).

-Will

By: Joel Scotkin (jscotkin) 2005-12-06 10:23:11.000-0600

Sounds great - I'll wait for the revised patch and give it a spin.

Will - My guess is that this will do the trick.  In order to narrow it down as much as possible, the results I had reported had been with just the "make samples" config and -vvvc.  So I was able to see on the console a message like "Unknown extension '7222' in context 'default' requested".  After Beta1, it switched to "Unknown extension '7' in context 'default' requested.  

So the question is whether the loops you and Lance identified also fix the exception case where there is *no* valid match.

I wasn't expecting that my attempt to simplify things by removing all extension matches would change the symptoms of the problem, but clearly it did.

Thanks much!
Joel

By: Lance Kimes (lkimes) 2005-12-06 15:51:40.000-0600

patch with additional bugfixes has been created against svn revision 7365 and uploaded.

By: Gerhard Venter (gventer) 2005-12-07 13:51:04.000-0600

Has this not been included in the Asterisk 1.2.1 build?

Thanks
Gerhard



By: Gerhard Venter (gventer) 2005-12-08 10:31:37.000-0600

Forgive my ignorance, but I looked around in the CVS to find out when this is going to make it into the next build but I cannot seem to find anything and the status still says new. I cannot find a 7365 tag and in the 7366 tag I did not see the changes in the code. How can I get this specific change so I can start testing my Astrerisk server?
Thanks
Gehard.

By: Will McCown (flynwill) 2005-12-08 11:37:21.000-0600

lkimes and I are just the bug reporters, with no control on
getting fixes into the tree.  The developers are aware that
a patch exists so I'm sure they'll look at it sooner or later.
I'm not completely sure the fix we're submitting is the best one,
or complete.

In the mean time you can download the em_trunk_patch.7365 patch
above and apply it to your copy of chan_zap.c yourself.  (It's
trivial edit adding 3 lines, so you can do it by hand if
need be).

By: Gerhard Venter (gventer) 2005-12-08 11:39:34.000-0600

Thank you. :)

By: Joel Scotkin (jscotkin) 2005-12-08 16:03:20.000-0600

I just tried the patch 7365.  It doesn't quite fix my initial test case, as described below.  Most importantly, it seems to work fine now for valid extensions in extensions.conf, which is the important thing.

I'm still seeing a failure to report the correct DID number when it does *not* have a valid match in extensions.conf.  

Repeating my earlier comment, but with a little more data:

The results I had reported had been with just the "make samples" config and -vvvc. So I was able to see on the console a message like "Unknown extension '7222' in context 'default' requested". After Beta1, it switched to "Unknown extension '7' in context 'default' requested.  Even with the patch, I still only see the '7' instead of the '7222'.

Hmmm.  A little more experimenting shows that asterisk is only matching one digit past a similar extension match, rather than printing the full DID number for failed matches.  If I always dial 212-xxx-7222, here is what I see on the console for various extensions defined in extensions.conf:

7222 defined ->  I call 7222 - extension answers.
7223 defined ->  I call 7222 - I see "Unknown extension '7222' ..."
7211 defined ->  I call 7222 - I see "Unknown extension '722' ..."
7111 defined ->  I call 7222 - I see "Unknown extension '72' ..."
No 7xxx extensions defined -> I call 7222 - I see "Unknown extension '7' ...".

Up through beta1, this test reported 7222 no matter what extensions were defined in extensions.conf

Thanks!!!

Joel

By: Will McCown (flynwill) 2005-12-08 16:22:06.000-0600

Yes that does appear to be the intended behavior of the new code (new with beta2).  The old loop just collected digits until the "E&M wait for digits" time expired then tried to match them to the dialplan.  The new code now tries to match with each new collected digit, and bails as soon as it has complete match or (I'm guessing here) as soon as the digits couldn't possibly match anything.

By: Joel Scotkin (jscotkin) 2005-12-08 16:45:18.000-0600

Makes sense - thanks for the explanation.  Might make debugging a little harder.

Thanks again!
Joel

By: Gerhard Venter (gventer) 2005-12-08 18:43:58.000-0600

Thanks guys! The patch seems to work for me.

Gerhard.

By: BJ Weschke (bweschke) 2005-12-10 11:05:58.000-0600

Committed to /trunk and /branches/1.2 thanks!

By: Digium Subversion (svnbot) 2008-01-15 16:05:24.000-0600

Repository: asterisk
Revision: 7424

U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r7424 | bweschke | 2008-01-15 16:05:23 -0600 (Tue, 15 Jan 2008) | 4 lines

Bug ASTERISK-5724
Make sure the digit string from E&M wink DNIS collection is properly null terminated as it grows.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7424

By: Digium Subversion (svnbot) 2008-01-15 16:05:25.000-0600

Repository: asterisk
Revision: 7425

U   branches/1.2/channels/chan_zap.c

------------------------------------------------------------------------
r7425 | bweschke | 2008-01-15 16:05:24 -0600 (Tue, 15 Jan 2008) | 4 lines

Bug ASTERISK-5724
Make sure the digit string from E&M wink DNIS collection is properly null terminated as it grows.


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7425

By: Digium Subversion (svnbot) 2008-01-15 16:05:30.000-0600

Repository: asterisk
Revision: 7431

_U  trunk/
U   trunk/apps/app_voicemail.c
U   trunk/utils/astman.c

------------------------------------------------------------------------
r7431 | russell | 2008-01-15 16:05:30 -0600 (Tue, 15 Jan 2008) | 37 lines

Merged revisions 7404,7406,7425,7427,7429-7430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r7404 | tilghman | 2005-12-08 18:32:08 -0500 (Thu, 08 Dec 2005) | 2 lines

Documenting two keywords that were previously missing

........
r7406 | tilghman | 2005-12-08 18:45:36 -0500 (Thu, 08 Dec 2005) | 2 lines

Bug 5960

........
r7425 | bweschke | 2005-12-10 13:10:50 -0500 (Sat, 10 Dec 2005) | 4 lines

Bug ASTERISK-5724
Make sure the digit string from E&M wink DNIS collection is properly null terminated as it grows.


........
r7427 | tilghman | 2005-12-10 20:15:15 -0500 (Sat, 10 Dec 2005) | 2 lines

Bug 5967

........
r7429 | tilghman | 2005-12-10 20:26:51 -0500 (Sat, 10 Dec 2005) | 2 lines

Bug 5965 - major bug in AST_LIST_REMOVE

........
r7430 | russell | 2005-12-11 01:08:56 -0500 (Sun, 11 Dec 2005) | 2 lines

silence a couple of compiler warnings about pointer signedness

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7431

By: Digium Subversion (svnbot) 2008-01-15 16:06:13.000-0600

Repository: asterisk
Revision: 7442

_U  team/russell/make_menuconfig/
U   team/russell/make_menuconfig/apps/app_externalivr.c
U   team/russell/make_menuconfig/apps/app_voicemail.c
U   team/russell/make_menuconfig/channels/chan_zap.c
U   team/russell/make_menuconfig/include/asterisk/linkedlists.h
U   team/russell/make_menuconfig/utils/astman.c

------------------------------------------------------------------------
r7442 | russell | 2008-01-15 16:06:12 -0600 (Tue, 15 Jan 2008) | 80 lines

Merged revisions 7424,7428,7431,7434,7436 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r7424 | bweschke | 2005-12-10 13:05:00 -0500 (Sat, 10 Dec 2005) | 4 lines

Bug ASTERISK-5724
Make sure the digit string from E&M wink DNIS collection is properly null terminated as it grows.


................
r7428 | tilghman | 2005-12-10 20:26:09 -0500 (Sat, 10 Dec 2005) | 2 lines

Bug 5965 - major bug in AST_LIST_REMOVE

................
r7431 | russell | 2005-12-11 01:17:36 -0500 (Sun, 11 Dec 2005) | 37 lines

Merged revisions 7404,7406,7425,7427,7429-7430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r7404 | tilghman | 2005-12-08 18:32:08 -0500 (Thu, 08 Dec 2005) | 2 lines

Documenting two keywords that were previously missing

........
r7406 | tilghman | 2005-12-08 18:45:36 -0500 (Thu, 08 Dec 2005) | 2 lines

Bug 5960

........
r7425 | bweschke | 2005-12-10 13:10:50 -0500 (Sat, 10 Dec 2005) | 4 lines

Bug ASTERISK-5724
Make sure the digit string from E&M wink DNIS collection is properly null terminated as it grows.


........
r7427 | tilghman | 2005-12-10 20:15:15 -0500 (Sat, 10 Dec 2005) | 2 lines

Bug 5967

........
r7429 | tilghman | 2005-12-10 20:26:51 -0500 (Sat, 10 Dec 2005) | 2 lines

Bug 5965 - major bug in AST_LIST_REMOVE

........
r7430 | russell | 2005-12-11 01:08:56 -0500 (Sun, 11 Dec 2005) | 2 lines

silence a couple of compiler warnings about pointer signedness

........

................
r7434 | tilghman | 2005-12-12 12:20:21 -0500 (Mon, 12 Dec 2005) | 2 lines

Typo

................
r7436 | kpfleming | 2005-12-12 12:31:45 -0500 (Mon, 12 Dec 2005) | 15 lines

Merged revisions 7433,7435 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r7433 | tilghman | 2005-12-12 11:19:29 -0600 (Mon, 12 Dec 2005) | 2 lines

Typo

........
r7435 | kpfleming | 2005-12-12 11:30:59 -0600 (Mon, 12 Dec 2005) | 2 lines

set all the child file descriptors to non-blocking so that we don't hang if the child fails to send a newline-terminated command or error message

........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7442