[Home]

Summary:ASTERISK-01364: timestamps not updated properly when using IAX2 trunking.
Reporter:zoa (zoa)Labels:
Date Opened:2004-04-07 05:58:06Date Closed:2011-06-07 14:05:26
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax2dump.txt
( 1) sipdump.txt
( 2) tcpdump.txt
Description:with cisco 7960 i get choppy audio with cvs-head.

When doing a sip debug, i noticed that asterisk is destroying non existing calls from my 2 ciscos.



****** ADDITIONAL INFORMATION ******

Sip debug shows a lot of:

Destroying call '70c6cc60072e2d8534c1e7004de13eed@10.5.0.7'
&
Scheduling destruction of call '000d299d-53ec0273-2d6e6228-34a69dd1@10.0.1.51' in 15000 ms

even when there are no active calls.

I upgraded my cisco from to 6.1 (was on 4.3) but the problem persists.
Comments:By: zoa (zoa) 2004-04-07 06:04:37

this is my setup:

7960G ulaw -> * -HEAD -> IAX2 (gsm) -> *-HEAD -> te410p

if i replace terminating server with an old version, i still get the same audio quality problem, didnt try replacing the first * as that was very unstable with old zaptel.
By: zoa (zoa) 2004-04-07 06:13:15

that tcpdump file is probably pretty useless :)

What exactly should i try to log ? sip ? iax2 ? on what server ? complete packets ?
By: bdolljr (bdolljr) 2004-04-11 02:36:36

i been having this same problem for some time now.  i've had to roll back to asterisk -stable (which does not have this problem) on both my asterisk servers.  i checked again using cvs -head 4/9/04 and it's still a problem in that verison.  i can confirm that the gsm conversion doesn't seem to matter in my case.

7960 ulaw -> * -HEAD -> IAX2 (gsm) -> *-HEAD -> te410p
7960 ulaw -> * -HEAD -> IAX2 (ulaw) -> *-HEAD -> te410p

both have the same horrible audio quality.  mark has logged onto my box and verified that the timestamps looked good during a call with poor quality.  i'm not sure where to go from here.

this has been a very serious issue for us and has kept us from running -head except for quick after hours tests.
By: Ricardo Villa (ricvil) 2004-04-11 13:05:03

Check this out and see if it fixes your problems:

If you are still testing out the Cisco phones give the following rtp.c modification a try.   It basically has the "Timestamp" carryover stuff commented out.  Asterisk thus generates evenly spaced out timestamps.  (also note the 2560 change).  My hunch is this will fix your Cisco issues.  Let me know please.

Andres


              /* Re-calculate last TS */
              rtp->lastts = rtp->lastts + ms * 8;
/*              if (!f->delivery.tv_sec && !f->delivery.tv_usec) { */
                      /* If this isn't an absolute delivery time, Check if it is close to our prediction,
                         and if so, go with our prediction */
                      if (abs(rtp->lastts - pred) < 2560)
                              rtp->lastts = pred;
                      else
                              ast_log(LOG_DEBUG, "Difference is %d, ms is %d\n", abs(rtp->lastts - pred), ms);
/*                }*/
By: bdolljr (bdolljr) 2004-04-12 13:43:43

I rebuilt and applied this *patch* to CVS -head 4/11/04.  It works great! The audio now sounds normal on my 7960's (5.3 firmware).  I'm not sure what else this fix will effect (or if it should be submitted as a patch), but I wanted to provide you with an update.  Thanks again.

zoa: Did you get a chance to try this?
By: Ricardo Villa (ricvil) 2004-04-12 14:36:03

Just to let you know this is the way it worked **before**.  So if you like it then you must request to Mark to backout the recent patch that is supposed to "carry over" the timestamp.
By: zoa (zoa) 2004-04-14 19:18:40

this should be resolved in cvs today.

Didnt test if it worked for me yet, but looks like it should, if it doesnt, i'll reopen this bug.
By: zoa (zoa) 2004-04-22 12:47:42

i tried latest cvs -head today, this is what it got me (i was using -stable before)


 1.601650     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=1308276826, Seq=47806, Time=6720
 1.606407    10.0.1.12 -> 10.5.0.7     RTP Payload type=ITU-T G.711 PCMU, SSRC=2149171241, Seq=58459, Time=42938960
 1.621648     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=1308276826, Seq=47807, Time=6880
 1.626412    10.0.1.12 -> 10.5.0.7     RTP Payload type=ITU-T G.711 PCMU, SSRC=2149171241, Seq=58460, Time=42939120
 1.641638     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=1308276826, Seq=47808, Time=7040
 1.646818    10.0.1.12 -> 10.5.0.7     RTP Payload type=ITU-T G.711 PCMU, SSRC=2149171241, Seq=58461, Time=42939280
 1.662635     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=1308276826, Seq=47809, Time=7208
 1.666392    10.0.1.12 -> 10.5.0.7     RTP Payload type=ITU-T G.711 PCMU, SSRC=2149171241, Seq=58462, Time=42939440

I suppose something is still very wrong, its audible once every 10 calls or so, and terrible once every 20 calls.

a dump of the iax2 packets shows a constant timestamp of 256ms (not an increase with 256ms, its a constant timestamp).
By: zoa (zoa) 2004-04-22 12:50:44

tethereal dump added
By: zoa (zoa) 2004-04-22 13:03:53

i tried disabling the jitter buffer on both ends, but it still the same, (maybe less frequent?) but i have a lot of jitter here, so now i get little drops extra for free. (i cant live without the jitter buffer).
By: zoa (zoa) 2004-04-22 13:08:04

i'm doing sip -> * -> iax2 -> TE410p.

I'm on a link with often up to 150ms jitter. (during national internet peak hours), causing a lot of out of order packets.

The jitter ranges from 5ms to 150ms, its not like its always 150ms, the jitter graphs are like a mountain horizon with a lot of peaks.
By: zoa (zoa) 2004-04-22 13:47:56

BKW found out that this problem was related to trunking, if i use trunking, the iax2 timestamps are always 256, if i don't use trunking the iax2 timestamps increment nicely.

I turned off trunking, and tried calling 10 times and it sounded nice, will try 90 times more.

I really need trunking though, i only have a 3mbit fiber for voice here.
By: Mark Spencer (markster) 2004-04-22 14:47:23

Okay test fix is in CVS, let me know if that does it (it should, but then, what does that mean).
By: Mark Spencer (markster) 2004-04-23 01:30:45

Should be fixed now in CVS but it requires the transmitting side to update their code since that's where the problem really is.
By: zoa (zoa) 2004-04-23 02:43:22

i upgraded both * ends, i still get fixed 256ms timestamps on both audio streams when i turn on trunking.

I did a fresh checkout on both ends.
By: zoa (zoa) 2004-04-23 10:05:40

the problem with the sip timestamps looks fixed. (and so does the audio).

The 256ms timestamp on the iax2 end is because it doesnt know how to handle trunked timestamps or so.

Fixed in cvs. (except for the output of the timestamps on the iax2 side that don't need fixing or so).
By: zoa (zoa) 2004-04-23 10:08:25

fixed in cvs (except for the output of iax2 trunked timestamps, maybe that is a tethereal bug?).

Kram for president !
By: zoa (zoa) 2004-04-27 12:50:26

similar problem found,

When SIP -> * server A (26/04/2004's cvs) calls server B (26/04/2004's cvs) using a 2 way trunk -> te410p audio is good in both directions.

When SIP -> * server A (26/04/2004's cvs) calls server C (26/04/2004's cvs) using a 2 way trunk -> te410p audio is bad at the sip side, other side sounds good.

The voice is trembling, not choppy as with the previous problem.

When i make all streams from A to C trunked, and all streams from C to A not trunked, audio quality is perfect in both directions.

I checked the sip timestamps, but can't see anything weird...

(this is a part of the stream going from A to the SIP phone, i see this with cisco 7960 and snom 200).

20.634422     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61285, Time=129936
20.663584     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61286, Time=130176
20.663599     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61287, Time=130336
20.693399     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61288, Time=130416
20.723571     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61289, Time=130656
20.723586     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61290, Time=130816
20.753394     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61291, Time=130896
20.783569     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61292, Time=131136
20.783586     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61293, Time=131296
20.814382     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61294, Time=131376
20.843545     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61295, Time=131616
20.843560     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61296, Time=131776
20.873378     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61297, Time=131856
20.904544     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61298, Time=132096
20.904558     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61299, Time=132256
20.933368     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61300, Time=132336
20.964536     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61301, Time=132576
20.964553     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61302, Time=132736
20.994362     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61303, Time=132816
21.024525     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61304, Time=133056
21.024540     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61305, Time=133216
21.053358     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61306, Time=133296
21.083527     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61307, Time=133536
21.083543     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61308, Time=133696
21.114367     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61309, Time=133776
21.143513     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61310, Time=134016
21.143528     10.5.0.7 -> 10.0.1.12    RTP Payload type=ITU-T G.711 PCMU, SSRC=334330023, Seq=61311, Time=134176
21.173343     10.5.0.7 -> 10.0.1.12    RTP Payl

The iax2 trunked timestamps are all 256ms.

The only difference between Server B and C is that server C is a dual opteron on 64 bit suse.
By: zoa (zoa) 2004-04-27 12:57:28

sip to asterisk is ulaw, for the * A to * C i tried gsm, ilbc, and g729, they all trembled...

edited on: 04-27-04 11:51
By: Mark Spencer (markster) 2004-04-27 13:18:46

I notice th timestamps here are 240 samples apart.  I think you need to change the sampling size to match up with what you're trying to do.

The iax2 trunked timestmaps are not 256ms, but the ethereal plugin doesn't know how to read them.

I believe this is a configuration issue related to your phones.
By: zoa (zoa) 2004-04-27 13:24:37

configuration error on my side