[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