[Asterisk-Users] CAPI<->SIP broken incoming audio

[Vic Cross]

G'day list,

Follow-up post to the one I sent last week regarding bad calls between SIP 
and ISDN.

On Fri, 14 May 2004, Vic Cross wrote:

> To me, it looks like a variation of the SIP RTP timestamp problem (yes, my
> 7960 is at 6.3 code), but the problem exists on the ATA-186 too and I
> don't have any other issues with that (not even SIP-IAX, where the 7960 is
> really bad).

I've done some crawling over ethereal traces, and have found the problem 
to indeed be bad timestamps in the RTP payload from *.  I was advised (by 
JerJer on the IRC channel, thanks!) to update to latest CVS-HEAD, but the 
problem has recurred.  What's happening is that the RTP frames from * are 
all going out with the same timestamp, which is causing my 
timestamp-sensitive 7960 to barf and ignore the incoming audio stream 
(it's interesting that X-Lite is largely trouble-free in this scenario!).

On calls that work well, the RTP frames from * have a timestamp starting
at 160 and incrementing normally (160,320,480...).  On the bad calls, the
timestamp is a very large number (4015105112, for example) and does not
increment.  So, next step is to look thru the code and find where the
timestamp is initialised and incremented.

In rtp.c, I found a couple of instances of a variable declared as "signed
int" being used to hold the return value of the unsigned int function
calc_txstamp(), but only time will tell if this fixes the problem (as it
still takes anything up to a couple of days after an * restart before the
problem occurs).

What bugs me the most is that I can call SIP-SIP to the 7960 (from my ATA,
for example) and the RTP timestamp is incremented correctly.  Immediately
afterwards I will call from ISDN, and I get bad timestamp.  Which would
imply that the generation of the timestamp is related to the source of the
call, but I'm %$*&ed if I can find where -- it seems to be time-of-day
dependent, but nothing else (I can see where the codec seems to affect
timestamps, but in my test case I'm using the same codec as the ISDN
call).

Finally, should I take this to asterisk-dev?

Cheers,
Vic Cross


PS: Now that I can show a real problem I'm going to file a bug report too.