[Speex-dev] Changing the meaning of jitter buffer timestamp

[Duane Storey]

A client should in general be able to handle both rtp timestamp and sequence
number changes..  I've seen many busted implementations where these two
fields change more often than they should (i.e. where placing a party on and
then off hold will reset the sequence number and timestamp of the rtp
packets)..


-----Original Message-----
From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On
Behalf Of Jean-Marc Valin
Sent: Wednesday, October 05, 2005 6:47 AM
To: Peter Kirk
Cc: speex-dev at xiph.org
Subject: Re: [Speex-dev] Changing the meaning of jitter buffer timestamp

> My C book taught me an int is only guaranteed to be 16bits or bigger, and 
> since I am trying to write code that doesn't break on other systems, I am 
> assuming the "worst case". Hence I have to deal with the overflow... Is my

> information that "int" can be 16bit (a) false or (b) true but not valid
for 
> any relevant architecture?

c) assumes that I won't just change the call to say spx_int32_t instead
of "int" ;-) It was always meant to be 32 bits anyway.

> Even with 32 bits, is 37 hours of audio transmition (wide band) something
that 
> one should consider not to happen?

I guess I should deal with it at some point, but I'd like to know what
the RTP RFC says first.

	Jean-Marc
_______________________________________________
Speex-dev mailing list
Speex-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/speex-dev