asterisk users - Apr 2004 - IAX2 update - timestamp issue within iax pkts

Would this fix also help random quality issues both on a LAN and also 
with a remote SIP based installation running CVS from 3/22.

We're having too frequent complaints in conjunction with Grandstream 
phones and very stuttery/choppy sound, usually outgoing to land lines, 
to the point of being unintelligible, but also on internal voicemail 
messages. Our voice LAN is a dedicated 100Mb ethernet switch for voice, 
and no general network traffic.

Thanks,
Ryan

On Apr 14, 2004, at 4:26 PM, Rich Adamson wrote:
>
> For those that might be using Cisco 7940/7960 sip phones and placing
> calls across an iax2 link, we think the voice quality problem has been
> identified and corrected. The dev cvs should be updated as of about
> 3:30pm CDT today (April 14).
>
> <snip>
>
> If you use iax2 and Cisco sip phones, please update from cvs and give 
> it a
> try. I am not aware of any other sip phone vendor that is sensitive to
> these timestamps, but there could be others.
>
> Keep in mind the fix addresses iax2 timestamp problems "at the distant
> end", therefore iax updates will be required at both ends of an iax 
> link
> to address the end-to-end audio quality problem.

For those that might be using Cisco 7940/7960 sip phones and placing
calls across an iax2 link, we think the voice quality problem has been
identified and corrected. The dev cvs should be updated as of about
3:30pm CDT today (April 14).

History: Calls originating from a Cisco 79x0 sip phone and sent via
iax2 link to some distant * machine resulted in very poor quality audio,
and in some cases, the audio was so choppy as to be unusable. The 
quality problem surfaced around March 5th when coding changes were 
made to directly associate iax2 timestamps with the sip/rtp timestamps 
sent to the sip phones. 

The actual problem was traced back to timestamp issues within the iax2
packets being transmitted from the distant end. Those timestamps were
suppose to be exactly 20 milliseconds from one iax2 packet to another,
however in actual practice they ranged from as low as 10 milliseconds
to well over 40 milliseconds (as observed with ethereal).

When those seemingly random iax2 timestamps were transcoded to sip/rtp
timestamps, the rtp timestamps became seemingly random. The Cisco 7940/60
phones running v6.x code effectively dumped any rtp packet that did not
occur on nice 160 millisecond boundaries. In other words, if the timestamp
sent to the Cisco was 152 milliseconds, inbound audio on the Cisco stopped.
Very disruptive for the user, and if two or more sequential packets
arrived with non-160 millisecond timestamps, the Cisco audio would be
stopped for several seconds.

Mark and I (mostly Mark) spent a significant amount of time over the last
three days tracing the problem with ethereal, etc, and believe the issue
has been resolved. Mark committed the changes to cvs earlier this afternoon.

Testing from my * to digium (11 hops) today resulted in rock solid audio
even with lag times ranging upwards of 500 milliseconds, and jitter
ranging upwareds of 200 milliseconds.

If you use iax2 and Cisco sip phones, please update from cvs and give it a 
try. I am not aware of any other sip phone vendor that is sensitive to
these timestamps, but there could be others.

Keep in mind the fix addresses iax2 timestamp problems "at the distant
end", therefore iax updates will be required at both ends of an iax link
to address the end-to-end audio quality problem.

Rich

I saw the message on the CVS mailing list, but it looked like it was 
only fixed in CVS latest, not CVS stable.  Is this correct?

Rich Adamson wrote:
> For those that might be using Cisco 7940/7960 sip phones and placing
> calls across an iax2 link, we think the voice quality problem has been
> identified and corrected. The dev cvs should be updated as of about
> 3:30pm CDT today (April 14).

Rich Adamson wrote:
>For those that might be using Cisco 7940/7960 sip phones and placing
>calls across an iax2 link, we think the voice quality problem has been
>identified and corrected. The dev cvs should be updated as of about
>3:30pm CDT today (April 14).
>
>  
>
Thanks Rich.  I'll test this again next week when I get back to our 
lab.  I hope we can close this issue once and for all.

Regards,
Andres