[Asterisk-Users] Codec Voodoo: piece of evidence
Ray Burkholder
ray at oneunified.net
Sat Mar 27 14:36:27 MST 2004
>
> Andres wrote:
> > another? We noticed this problem when we upgraded one of
> our servers to
> > the latest CVS and left another one with an older version.
> Seems that
> > the latest changes with rtp.c need to be applied
> everywhere. When we
> > upgraded all servers then the audio returned to normal but the
> > connection with Nufone started sounding horrible.
> >
> > We had to roll back to the older version of rtp.c to get
> back the good
> > audio with Nufone.
> >
> Codec stuff sure does feel like voodoo sometime. I'd love it
> if someone
> with a handle on this (particularly the "why would a changed
> RTP stack
> cause some ITSP connections to go down the shi**er" deal) could
> enlighten us all.
>
We, too, have noticed issues with sound quality with recent versions of rtp.
I think there is a rounding problem in it. It isn't just something to
Nuphone. We can recreate between Asterisk and a Cisco 7940 with G.711.
In the following ethereal extraction, 10.1.6.2 is the Cisco Phone, 10.1.1.12
is Asterisk. Notice that the cisco phone consistently produces sequence
differences of 160 (the last column), while asterisk produces sequence
differences of 152 and 160. And because the time differences aren't
consistent, the phone probably 'stagger-steps' to get back in sequence, and
therefore sound quality suffers. This probably happens in time calcs for
gsm and other codec types as well.
Here is the snippet from rtp.c that does the processing. How do we fix the
rounding problem.?
static unsigned int calc_txstamp(struct ast_rtp *rtp, struct timeval
*delivery)
{
struct timeval now;
unsigned int ms;
if (!rtp->txcore.tv_sec && !rtp->txcore.tv_usec) {
gettimeofday(&rtp->txcore, NULL);
}
gettimeofday(&now, NULL);
ms = (now.tv_sec - rtp->txcore.tv_sec) * 1000;
ms += (now.tv_usec - rtp->txcore.tv_usec) / 1000;
/* Use what we just got for next time */
rtp->txcore.tv_sec = now.tv_sec;
rtp->txcore.tv_usec = now.tv_usec;
return ms;
}
Here is the ethereal extraction:
114 2.718259 10.1.6.2 -> 10.1.1.12
G.711 Seq 33943, Time 37206320
115 2.731003 10.1.1.12 -> 10.1.6.2
G.711 Seq 11856, Time 9472
116 2.738137 0.019878 10.1.6.2 -> 10.1.1.12
G.711 Seq 33944, Time 37206480 160
117 2.750979 0.019976 10.1.1.12 -> 10.1.6.2
G.711 Seq 11857, Time 9624 152
118 2.757836 0.019699 10.1.6.2 -> 10.1.1.12
G.711 Seq 33945, Time 37206640 160
119 2.771035 0.020056 10.1.1.12 -> 10.1.6.2
G.711 Seq 11858, Time 9784 160
120 2.777749 0.019913 10.1.6.2 -> 10.1.1.12
G.711 Seq 33946, Time 37206800 160
121 2.791071 0.020036 10.1.1.12 -> 10.1.6.2
G.711 Seq 11859, Time 9944 160
122 2.798419 0.02067 10.1.6.2 -> 10.1.1.12
G.711 Seq 33947, Time 37206960 160
123 2.811 0.019929 10.1.1.12 -> 10.1.6.2
G.711 Seq 11860, Time 10096 152
124 2.818484 0.020065 10.1.6.2 -> 10.1.1.12
G.711 Seq 33948, Time 37207120 160
125 2.830993 0.019993 10.1.1.12 -> 10.1.6.2
G.711 Seq 11861, Time 10248 152
126 2.838682 0.020198 10.1.6.2 -> 10.1.1.12
G.711 Seq 33949, Time 37207280 160
--
Scanned for viruses and dangerous content at
http://www.oneunified.net and is believed to be clean.
More information about the asterisk-users
mailing list