[Home]

Summary:ASTERISK-02282: channel.c 1.134 breaks MOH for MeetMe
Reporter:Tony Mountifield (softins)Labels:
Date Opened:2004-08-27 07:12:20Date Closed:2008-01-15 15:05:58.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ff.summary.txt
( 1) gs.summary.txt
( 2) gs1.summary.txt
Description:Calling MeetMe(1111|Mp) as the first user gets very broken MOH with 1.134 of channel.c. Reverting to 1.133 fixes the problem.

Interestingly, calling MusicOnHold() or WaitMusicOnHold() does not exhibit the problem. It seems to be only when MOH is being played to a channel that is also part of a conference.

I haven't yet investigated a fix, but it must be to do with the generator changes.
Comments:By: Mark Spencer (markster) 2004-08-27 10:01:27

What kind of channel do you have calling?
By: Mark Spencer (markster) 2004-08-27 10:32:31

I've tried it from a zap channel as well as a sip channeland have no problems with the example you gave.
By: Tony Mountifield (softins) 2004-08-27 10:42:16

Calling via SIP from a Grandstream BT102. Definitely does it with 1.134 but not with 1.133.

Using a X101P for timing, and that is the only Zap card in the system.
By: Mark Spencer (markster) 2004-08-27 11:12:39

What does zttest say?
By: Tony Mountifield (softins) 2004-08-27 11:13:44

Interestingly, using Firefly as the SIP client doesn't show the problem.

Using ALAW in both cases:

softins*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)   Format
192.168.0.200    2000        cd53f045b34  00101/63010   ALAW  
192.168.0.4      2003        b543ea30902  00101/00002   ALAW  
2 active SIP channel(s)

Firefly sound is fine, Grandstream sound is severely fluttery about 5-10 times a second. This is both at the same time.

Just reverted to 1.133 again and both devices are fine.
By: Mark Spencer (markster) 2004-08-27 11:19:44

I need to know the result of zttest as well as what's different on the wire.  I'm going to relabel this as minor since I cannot duplicate this problem and it only seems to be affecting your one phone in one particular situation.
By: Tony Mountifield (softins) 2004-08-27 11:21:58

This is zttest on the working version with both clients running:
[root@softins asterisk]# ../zaptel/zttest
Opened pseudo zap interface, measuring accuracy...
99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793%
99.987793% 99.987793% 100.000000% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793%
99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793%
--- Results after 21 passes ---
Best: 100.000000 -- Worst: 99.987793

This is the same using 1.134 of channel.c:
[root@softins asterisk]# ../zaptel/zttest
Opened pseudo zap interface, measuring accuracy...
99.987793% 100.000000% 99.987793% 100.000000% 99.987793% 99.987793% 99.987793%
99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793%
99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 100.000000% 99.987793%
99.987793%
--- Results after 24 passes ---
Best: 100.000000 -- Worst: 99.987793

Doesn't seem to be different.

GS is set to 2 voice frames per Tx, with Silence Suppression disabled (of course).
By: Tony Mountifield (softins) 2004-08-27 11:23:31

I have two GS phones and they are both affected. Both running 1.0.5.9 firmware.
By: Mark Spencer (markster) 2004-08-27 11:40:14

When you say two voice frames do you mean 20ms or 40ms voice?
By: Tony Mountifield (softins) 2004-08-27 11:45:35

I was just mentioning what was on the setup screen in case it was relevant. In any case, it is the default value: I've never changed it.

I've posted to asterisk-users asking for others with GS phones to try it.
By: linuxa (linuxa) 2004-08-27 12:13:51

Connected to Asterisk CVS-HEAD-08/27/04-18:34:54   CET

From my snom200 everything is perfect, from a GS HT286 it is as others have described.

This machine has an X100P as timing.
By: Mark Spencer (markster) 2004-08-27 14:17:00

How many ms of voice are there?
By: Mark Spencer (markster) 2004-08-27 14:19:33

And again, if you use ethereal, what is different on th ewire.
By: Tony Mountifield (softins) 2004-08-27 14:49:48

I don't know specifically "how many ms of voice". I assume the frames are at 20ms, and I guess the GS setting of 2 frames/packet means one packet every 40ms containing 2 frames. But it is the default and always used to work.

I haven't tried ethereal, but I will do, to see if it shows anything.

Is there a Grandstream at Digium that could be tried?
By: Mark Spencer (markster) 2004-08-27 15:06:07

I need to know whether it's 20 or 40.  You can use ethereal to look at it and see.
By: Tony Mountifield (softins) 2004-08-27 15:46:02

Ethereal summary traces attached. Firefly was sending frames to Asterisk individually, one per packet every 20ms (ff.summary.txt). The Grandstream was sending two frames to Asterisk together, one pair per packet every 40ms (gs.summary.txt). This is the default setting.

I set the Grandstream to 1 frame per packet instead of 2, and the problem went away (gs1.summary.txt).

So it seems the latest channel.c can't cope with bundling of RTP packets, although the previous version could.

edited on: 08-27-04 15:47
By: Mark Spencer (markster) 2004-08-27 16:08:35

Okay, i have a fix in mind, can you find me on IRC?
By: Tony Mountifield (softins) 2004-08-27 16:32:58

Attempting to. It's 10.30pm here in the UK, so I'll have to try again tomorrow if I can't find you.
By: Mark Spencer (markster) 2004-08-27 17:54:32

Fixed in CVS
By: Digium Subversion (svnbot) 2008-01-15 15:05:58.000-0600

Repository: asterisk
Revision: 3668

U   trunk/channel.c

------------------------------------------------------------------------
r3668 | markster | 2008-01-15 15:05:57 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix generator for VAD as well as for automatically syncing to incoming signal if present (bug ASTERISK-2282)

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

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