Summary:ASTERISK-02545: garbled audio with trunking on some devices
Reporter:zoa (zoa)Labels:
Date Opened:2004-10-06 02:37:50Date Closed:2008-01-15 15:10:07.000-0600
Versions:Frequency of
Environment:Attachments:( 0) asterisk-patch-nodeliveryfortrunkedframes.patch
( 1) debug.txt
( 2) debug2.txt
Description:I seen to have problems with garbled audio when using an iax2 trunk.

(especially on cisco 7960s).

When i dial with a cisco to * using sip, then using iax2 trunked(no jitter buffers) to another server than to te410p, i get garbled audio on the cisco end.

(The te410p side hears everything loud and clear).

When using ZAP to iax2 to ZAP no garbled audio is heard.

Comments:By: zoa (zoa) 2004-10-06 02:38:18

im using the 1.0.1 from cvs on both asterisk servers.

By: pfn (pfn) 2004-10-06 02:48:21

I, too, am experiencing garbled sound when using IAX2 trunking.  jitterbuffer is off in all instances.

My setups/tests:

7960 -> * (1.0.1) -> inet (IAX2 trunk) -> * (1.0.1)

Results in garbled sound when both * servers specify trunk=yes for the peer/user combo


Zap FXS -> * (1.0.1) -> inet (IAX2 trunk) -> * (1.0.1)

Does not result in garbled sound.


Setting trunk=no on either side of the connection eliminates this garbled sound.

While I am experiencing the garbled sound, jitter jumps all over the place as high as ~600ms (as evidenced by running iax2 show channels during the call--this jitter indication isn't always repeatable).

The local end originating the call has an x100p for zap timing, while the remote end has ztdummy.  The remote end is playing back an IVR menu recorded in pcmu so I don't know how the sound quality is on the remote end.

edited on: 10-06-04 02:53

By: zoa (zoa) 2004-10-06 04:11:29

Hmmz, i thought -r 1.0.1 was the latest one, but looks like v1.0.10 is the latest one.

Will try again with this one.

Pfn what version are you running ?

By: pfn (pfn) 2004-10-06 18:25:41

1.0.1 is the latest version outside of the v1-0 branch, 1-0-10 means 1.0 built in October.... (as noted in my bug notes, my version is 1.0.1)

By: Mark Spencer (markster) 2004-10-06 19:32:40

Can you find where it stopped working, which patch broke it from one of the release candidates to 1.0?  thanks.

By: pfn (pfn) 2004-10-06 19:59:00

zoa pasted this ethereal capture on irc last night while experiencing this problem.  notice how at least one of the timestamps is out of sequence?  I wonder if that has to do with anything...

23.778880 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13728, Time=99848
23.799749 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13729, Time=100008
23.818555 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13730, Time=100168
23.838551 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13731, Time=104192
23.858252 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13732, Time=100480
23.878667 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13733, Time=100640
23.897884 ->    RTP Payload type=ITU-T G.711 PCMU, SSRC=1835366382, Seq=13734, Time=100800

By: zoa (zoa) 2004-10-07 01:47:09

pfn, cvs co -r 1-0-1 is not the latest one,

Get cvs co -r 1-0 to get the latest one.

By: Mark Spencer (markster) 2004-10-07 14:50:40

Yes, clearly his debug has diverging timestamps.  I want to be sure this is really in CVS head (stable or head) and if so, did it ever work and if so, when did it break?

By: zoa (zoa) 2004-10-08 02:26:20

i changed to 1-0-10 yesterday, will try to find some time today to test it today.
(please be patient :-)

I'm affraid that if its also in -head i will not have the possibility (time nor test servers) to try to find out on what date it got broken.


edited on: 10-08-04 04:26

By: zoa (zoa) 2004-10-08 10:20:20

lets make that tomorrow....

By: zoa (zoa) 2004-10-09 03:22:37

ok, i just tried it,

Asterisk CVS-v1-0-10/06/04-13:29:15 HAS the timestamp issue when trunking is used. (at least here it does :-).

AI seeee a bug peeeople :)

By: zoa (zoa) 2004-10-09 03:24:32

I think this was introduced right before astricon.
(i didnt have any problems before i went to astricon, and at that time i was running a 2 week old cvs).

By: Mark Spencer (markster) 2004-10-09 10:08:45

Can you give me a specific diff please...

By: pfn (pfn) 2004-10-09 11:16:25

On a whim (given the description of the cvs log), I decided to do the following on 1.0.1:

cvs diff -u -r 1.185 -r 1.186 chan_iax2.c | patch -R

Ignore the 1 reject as it causes no problems--just an extra variable definition.

This only had to be done on the machine that is dialing out (i.e. with the type=peer).  The garbled sound appears to go away.

However, I can't narrow it down further as I need to get to work today, too, bleh  :-(

edited on: 10-09-04 11:17

By: Mark Spencer (markster) 2004-10-09 11:23:49

nicely done, this gives me a place to get started.

By: Steve Davies . (stevedavies) 2004-10-10 08:13:19

I've attached a patch that stops chan_iax2.c setting the frame "delivery" time when the frame came off a trunk.  This is needed because frame timestamps get mangled by the trunking process - propagating these timestamps over into rtp.c, where they get used for outbound rtp timestamps, is a bad idea.

The patch also disables dejittering for frames coming from a trunk.  Also needed because of the damaged timestamps.

Please let me know if it fixes this problem with the 7960!


By: pfn (pfn) 2004-10-10 16:24:33

I've tried your patch, Steve, and it sounds flawless now.

By: Mark Spencer (markster) 2004-10-10 16:27:05

Fixed in CVS head, worthy of backport to CVS

By: Russell Bryant (russell) 2004-10-11 22:25:12

fixed in the 1.0 branch

By: Digium Subversion (svnbot) 2008-01-15 15:10:01.000-0600

Repository: asterisk
Revision: 3974

U   trunk/channels/chan_iax2.c

r3974 | markster | 2008-01-15 15:10:00 -0600 (Tue, 15 Jan 2008) | 2 lines

Keep back delivery times on trunk (bug ASTERISK-2545)



By: Digium Subversion (svnbot) 2008-01-15 15:10:07.000-0600

Repository: asterisk
Revision: 3981

U   branches/v1-0/channels/chan_iax2.c

r3981 | russell | 2008-01-15 15:10:07 -0600 (Tue, 15 Jan 2008) | 2 lines

fix delivery times on trunks (bug ASTERISK-2545)