>> 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
For what it is worth, the un-even rtp timestamp also impacted SCCP
phones when used with Cisco's own conferencing solution. After almost
two years of trying to fix the conferencing software, we were informed
of the issue and it was suggested we update the phones to the 6.0.3
code. Since then we've seen a marked improvement. Now that Cisco has
the fix in the SCCP code, maybe it'll find its way into the SIP code.
Dan
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
