[asterisk-bugs] [Asterisk 0016771]: T.38 with devices behind NAT does not work

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16771 
====================================================================== 
Reported By:                ipich
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16771
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.2 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.2 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-04 07:42 CST
Last Modified:              2010-02-04 08:38 CST
====================================================================== 
Summary:                    T.38 with devices behind NAT does not work
Description: 
I've found trouble described in
https://issues.asterisk.org/view.php?id=10417
There is patch for 1.4, but I have 1.6.2, so it does not work

Scenario is :
Host1 192.168.x.x (NAT IP 100.100.100.100) sends fax host2 200.200.200.200
but after re-invite t.38 session asterisk transmits udptl packets to
internal IP 192.168.x.x
====================================================================== 

---------------------------------------------------------------------- 
 (0117707) file (administrator) - 2010-02-04 08:38
 https://issues.asterisk.org/view.php?id=16771#c117707 
---------------------------------------------------------------------- 
The patch you are referencing added a configuration option which caused
Asterisk to send UDPTL to the IP address of the RTP, and to the port
negotiated for UDPTL. If the port was forwarded then it could work.

Have you done so? Otherwise this trace looks normal, we get no packets
from the other side so we can't use the source IP address/port of them for
sending UDPTL and have to use what was given in the SDP. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-04 08:38 file           Note Added: 0117707                          
======================================================================