[asterisk-dev] Issue 10417 - T.38 with devices behind NAT does not work in all circumstances

Raj Jain rj2807 at gmail.com
Thu May 22 06:29:17 CDT 2008

This sounds more like a band-aid than an actual solution.

There is a big assumption involved here that the NAT binding
established at the time of audio will indeed be valid when the media
switches over to fax. This means that the device behind NAT must not
change it's own listening IP and port when the switchover of media
occurs. While this may be true for the scenario and device reported in
the bug report, it seems like a very big assumption that will probably
not hold true in other environments or when the media change happens
for other reasons (change to MoH source, for instance).

That said, if this is how some T.38 devices behave (that they wait for
incoming packets before sending outbound packets after media
switchover and they don't change their IP/port), then MAYBE this is
worth considering as a solution. Of course, any configurable parameter
defined here should only be applied to the very specific case of media
switching from audio to image.

Raj Jain

On Wed, May 21, 2008 at 2:49 PM, Joshua Colp <jcolp at digium.com> wrote:
> Greetings All,
> The current patch on this issue sets the UDPTL remote IP address to either the received RTP IP address (if there is one) or the source IP address of SIP signalling when nat is set to yes. It does this so that outgoing UDPTL packets will reach the remote side if the correct ports are forwarded. This is done as some T38 capable devices do not send UDPTL (so we can't learn the source IP address/port) until they receive it.
> My question to the list is what are your thoughts on this? Is this something we should do? Make it an option?
> Joshua Colp
> Software Developer
> Digium, Inc.
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

More information about the asterisk-dev mailing list