[asterisk-users] IAX trunktimestamps and AST_CONTROL_SRCUPDATE

[Steve Davies]

2009/3/23 Kevin P. Fleming <kpfleming at digium.com>:
> Tilghman Lesher wrote:
>
>> It will have no effect.  The issue has always been that if the stream source
>> changed during a call, the sequence numbers could be reset, sometimes
>> causing audio weirdness.  What has changed is that we're now able to tell
>> the other side to expect such a reset, thus preventing audio weirdness
>> (basically, audio would drop until the remote end decided that it was okay
>> that it was missing a bunch of frames and could continue on).  If your calls
>> are breaking, they would have broken, regardless of whether this frame was
>> sent or not.
>
> This is all true, but since IAX2 does not transport the native
> timestamps of the Asterisk frames it is asked to send (it creates its
> own timestamps), there is no value in sending a SRCUPDATE frame across
> IAX2, because the receiver of the frame will never see any timestamp
> discontinuity due to it.
>

Thanks for both of those answers. It turned out that the call drop was
a horrible coincidence that happened to follow immediately after a
SRCUPDATE frame almost every time. We switched to an alternative IAX
server at the ITSP end and the problem cleared up.

I hope I did not take too much of your time, but the explanations are
welcome either way :)

Regards,
Steve