[Asterisk-Users] IAX2 update - timestamp issue within iax pkts

[Rich Adamson]

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