asterisk users - Mar 2009 - IAX trunktimestamps and AST_CONTROL_SRCUPDATE

Hi,

I have just discovered (a year after it was implemented) a possibly
undocumented incompatability between IAX in Asterisk 1.4 and any
version of Asterisk pre-March 2008.

It seems an AST_CONTROL_SRCUPDATE frame type was added (in March '08),
but no mechanism to negotiate whether it can be sent to the remote
end, so if a "new" IAX endpoint sends it, and the remote end ignores
it, I believe it can cause the call to fail.

Am I being overdramatic? I have a scenario which seems to be showing a
1.2 box talking to a 1.4 box dropping calls sometimes, and the error
message on the 1.2 box is showing that it does not like the
unrecognised AST_CONTROL_SRCUPDATE frame that it receives. This issue
may be exagerated by the fact that the Asterisk 1.2 box has
"trunktimestamps=no" set to ensure compatability with an old Asterisk
1.0.x service.

Help? Is there a workaround? Might it be enough to enable
trunktimestamps in this instance?

Thanks,
Steve

On Thursday 19 March 2009 05:29:00 Steve Davies wrote:
> I have just discovered (a year after it was implemented) a possibly
> undocumented incompatability between IAX in Asterisk 1.4 and any
> version of Asterisk pre-March 2008.
>
> It seems an AST_CONTROL_SRCUPDATE frame type was added (in March '08),
> but no mechanism to negotiate whether it can be sent to the remote
> end, so if a "new" IAX endpoint sends it, and the remote end
ignores
> it, I believe it can cause the call to fail.
>
> Am I being overdramatic? I have a scenario which seems to be showing a
> 1.2 box talking to a 1.4 box dropping calls sometimes, and the error
> message on the 1.2 box is showing that it does not like the
> unrecognised AST_CONTROL_SRCUPDATE frame that it receives. This issue
> may be exagerated by the fact that the Asterisk 1.2 box has
> "trunktimestamps=no" set to ensure compatability with an old
Asterisk
> 1.0.x service.
>
> Help? Is there a workaround? Might it be enough to enable
> trunktimestamps in this instance?
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.

In other words, this is a long-standing bug that was recently solved.  If
either one of your Asterisk servers cannot send the frame or interpret
the frame, then the old familiar behavior is the result.

-- 
Tilghman