[asterisk-bugs] [Asterisk 0010417]: [patch] T.38 with devices behind NAT does not work in all circumstances

[noreply at bugs.digium.com]

The following issue has been UPDATED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10417 
====================================================================== 
Reported By:                cstadlmann
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10417
Category:                   Channels/NewFeature
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0-beta4 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 78569 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-09-2007 09:42 CDT
Last Modified:              02-29-2008 11:55 CST
====================================================================== 
Summary:                    [patch] T.38 with devices behind NAT does not work
in all circumstances
Description: 
There is a conceptual problem in chan_sip.c in 'process_sdp' when it
processes UDPTL re-invites.

Let's look at the following scenario:

ATA1: IP 192.168.4.26, NAT IP 83.64.90.46
ATA2: IP 212.31.71.50

ATA1 send's a fax to ATA2, so ATA2 performs the reinvite within the RTP
session. When ATA1 responds to the re-invite, it transmits it's IP address,
which is of course not the NAT IP:

<--- SIP read from 83.64.90.46:10497 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.193.128.15:5060;branch=z9hG4bK2b3e0f4c;rport=5060
From: <sip:073261066060 at voip.mywave.at>;tag=as712ecf71
To: <sip:v205357an at voip.mywave.at>;tag=2135323211
Call-ID: 2073630983-10497-8 at 192.168.4.26
CSeq: 102 INVITE
Contact: <sip:v205357an at 192.168.4.26:10497>
Supported: replaces, path
User-Agent: Grandstream HT-502 V0.2A 1.0.0.44
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER,
UPDATE
Content-Type: application/sdp
Content-Length: 354

v=0
o=v205357an 8000 8001 IN IP4 192.168.4.26
s=SIP Call
c=IN IP4 192.168.4.26
t=0 0
m=image 54853 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:400
a=T38FaxUdpEC:t38UDPRedundancy
<------------->

The function process_sdp now evaluates the line 'c=IN IP4 192.168.4.26'
and sets sin.sin_addr accordingly. After 'ast_udptl_set_peer(p->udptl,
&sin);' (Line 5041) all UDPTL packets are transmitted to the wrong IP
address. Of course the NAT IP is stored when Asterisk receives the first
packet, which is handled in udptl.c (Line 662). But if Asterisk never
receives a packet, fax transmission fails because ATA1 never gets any
packets. Especially Patton devices do not send packets at all until they
receive ones.

To work around this issue, I implemented a very nasty patch to
chan_sip.c:

Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c	(revision 78416)
+++ channels/chan_sip.c	(working copy)
@@ -5037,6 +5037,7 @@
	/* Setup UDPTL port number */
	if (p->udptl) {
		if (udptlportno > 0) {
			sin.sin_port = htons(udptlportno);
+			sin.sin_addr = p->recv.sin_addr;
			ast_udptl_set_peer(p->udptl, &sin);
			if (debug)
				ast_log(LOG_DEBUG,"Peer T.38 UDPTL is at port
%s:%d\n",ast_inet_ntoa(sin.sin_addr), ntohs(sin.sin_port));

With that patch, the packets are transmitted to the NAT IP of the device,
and everything is fine. I know I should have implemented checks for NAT,
but all our devices are behind NAT, so this is no problem.

Now comes the point where I need assistance from a chan_sip guru because
that's not the only NAT issue. Although the packets are transmitted to the
correct IP address now, any NAT router rejects the packets because the
packtes come from a different port that the RTP packets were. So static
port forwarding of the udptl ports is the only solution for now (Maybe
Cisco routers with SIP fixup can handle it...), but only for ONE device.
Multiple devices are not supported of course. Anyway, after the ATA or
Patton received the packets from Asterisk, it starts transmitting packets
and NAT is fine again.

So my idea is the following:
If Asterisk could transmit the first packets to a device behind NAT with
ip:port from the RTP stream, the packets would arrive at the ATA without
static port forwarding because of the established session. After the ATA
transmits it's packets, we could use the port from the re-invite again.

So please guys think about that issue. Although it seems that I'm the only
one in the world that plays around with T.38, a proper solution would be
appreciated.
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-29-08 11:55  file           Asterisk Version          SVN => 1.6.0-beta4 
02-29-08 11:55  file           Category                 Channels/chan_sip/T.38
=> Channels/NewFeature
02-29-08 11:55  file           Summary                  T.38 with devices behind
NAT does not work in all circumstances => [patch] T.38 with devices behind NAT
does not work in all circumstances
======================================================================