[asterisk-dev] [svn-commits] jrose: branch 11 r399457 - in /branches/11: ./ channels/chan_sip.c

[Matthew Jordan]

On Fri, Sep 20, 2013 at 12:26 AM, Olle E. Johansson <oej at edvina.net> wrote:

>
> 19 sep 2013 kl. 18:45 skrev SVN commits to the Digium repositories <
> svn-commits at lists.digium.com>:
>
> Prior to this patch, Asterisk would incorrectly use the previous endpoint
> addresses in SDP in spite of providing its own port. T38 is never meant to
> be done through directmedia and Asterisk should always be in the media path
> for these streams.
>
>
> Just being curious: Why was T.38 never meant to use directmedia? Any
> technichal reasons in the protocol?
> Or just something missing in our code?
>
>
It's actually really rather difficult to get right reliably. Unlike audio,
where some audio packets can be dropped during the re-negotiation for
directmedia, you don't want to lose or other perturb any of the T.38 fax
packets once the sending device starts transmitting to Asterisk. We know
that in some scenarios, directmedia set up of a media stream can take
a measurable amount of time - sometimes, even a second or two. What's more,
since you can't predict when both devices will get the re-INVITE, often a
device will send media to its new target before that device is ready - and
devices will usually drop media received from endpoints they don't
recognize (to avoid the 'media injection attack' scenario).

That length of time - and dropping packets - could play havoc with a T.38
fax stream. For example, say that a transmitting device has established a
fax session passing through Asterisk and has started long training to
determine the fax rate. While doing so, it receives a re-INVITE from
Asterisk to send its fax media stream directly to another device. Does it
re-start the training with the new device? Does it restart the entire
transmission? Does it fail the training and try again with the new device?
If so, how does it know what state the receiving device is in? Does it
assume that Asterisk has relayed its received fax packets already? If so,
does it assume that Asterisk has sent all of them - or some subset?

Unlike audio, every packet during a T.38 fax transmission matters to some
extent - either as control information or as part of the image. This is why
fax is temperamental and hard to get right in even the best of scenarios.
Direct media involving fax *may* work in some very specific scenarios, but
is much more likely to lead to incredibly difficult to diagnose problems.
Hence Mark's/Josh's/my insistence that - barring a *very* good patch that
implements it, testing, and a very good explanation of how it avoids and/or
handles various edge cases - it's better to just not do direct media for
fax. (I'd go so far as to say that even if such a patch were possible,
investing such time on fax is insane, but that's just me).

Hope that clears it up for everyone!

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130922/f3d94bb5/attachment.htm>