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

[Rich Adamson]

> 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?

Vic,

It sounds like you've nailed the problem with the "signed int" statement.
However, I'd suggest you open a bug report on this (rather than using list
mail only) to get it some attention and tracking. It is very likely that
other rtp channel drivers have the same issue as well. (We know it was
a problem for iax/gsm -> sip/rtp.)

As for the Cisco dropping packets with uneven timestamps, that issue is
totally unrelated to which codec is used; it affects all. In researching
the Cisco bug tracking list, it would appear this particular problem is
rated as a Sev 6 (lowest) and unless folks with smartnet maintenance
contracts start pushing to increase the Sev level, its not likely to get
fixed anytime soon. Sev 6 is basically considered cosmetic and not service
impacting.

Rich