[Home]

Summary:ASTERISK-18489: Asterisk 10 Beta - T38 NAT not working
Reporter:Josh Zeitz (netsteller)Labels:
Date Opened:2011-09-09 00:16:06Date Closed:2011-09-14 12:30:03
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:10.0.0-beta1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Virtual machine running Centos 5 and Asterisk 10 beta- using Grandstream ATAs on extensions and also running virtual extensionsAttachments:( 0) debug.pcap
( 1) putty.log
Description:I did a extension to virtual extension T38 test.

1. Remote server with NAT and ATA with NAT

fax machine <-> ATA(nat) extension on PBX <-> Internet <-> PBX(nat) virtual extension

Does not work with T38, but

2. Local server with no nat and ATA with no nat

fax machine <-> ATA extension on PBX <-> PBX virtual extension

Now this works. When there is no NAT involved it seems to work fine. The only difference is the firewalls on both sides but they are set to pass all traffic and the correct ports are forwarded on the PBX side of the connection.

It seems that the T38 does not like the NATed connection for some reason.

More Testing,

Setup
PaIF server (IP 192.168.1.195)(no nat)
Linksys Router (external IP 192.168.1.128)
ATA (IP 10.0.0.100)(nat)

PaIF <-> internet port on Linksys <-> lan port on Linksys <-> ATA (nat)

Made a call from the ATA which is extension 2000 on PaIF to a virtual extension (1001) and the fax failed.

Here is the T38 part of the log:

<------------->
[Kpbx*CLI>
[0K--- (12 headers 0 lines) ---
[Kpbx*CLI>
[0Kset_destination: Parsing <sip:2000@192.168.1.128:5060> for address/port to send to
set_destination: set destination to 192.168.1.128:5060
Reliably Transmitting (NAT) to 192.168.1.128:5060:
INVITE sip:2000@192.168.1.128:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.195:5060;branch=z9hG4bK1bbbff96;rport
Max-Forwards: 70
From: <sip:1001@192.168.1.195>;tag=as16a99fae
To: <sip:2000@192.168.1.195>;tag=a53766addc54cd34
Contact: <sip:1001@192.168.1.195:5060>
Call-ID: ff7f808f328f936f@10.0.0.100
CSeq: 102 INVITE
User-Agent: FPBX-2.9.0(10.0.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Type: application/sdp
Content-Length: 271

v=0
o=root 1374969850 1374969851 IN IP4 192.168.1.195
s=Asterisk PBX 10.0.0-beta1
c=IN IP4 192.168.1.195
t=0 0
m=image 4974 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:849
a=T38FaxUdpEC:t38UDPFEC

---
[Kpbx*CLI>
[0K
<--- SIP read from UDP:192.168.1.128:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.195:5060;branch=z9hG4bK1bbbff96;rport
From: <sip:1001@192.168.1.195>;tag=as16a99fae
To: <sip:2000@192.168.1.195>;tag=a53766addc54cd34
Call-ID: ff7f808f328f936f@10.0.0.100
CSeq: 102 INVITE
User-Agent: Grandstream HT287 1.1.0.42 DevId 000b82307614
Contact: <sip:2000@192.168.1.128:5060>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SU BSCRIBE,UPDATE
Content-Type: application/sdp
Supported: replaces, timer
Content-Length: 262
v=0
o=2000 8000 8002 IN IP4 10.0.0.100
s=SIP Call
c=IN IP4 5004128
t=0 0
m=image 5004 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy

I can see the request from the server in the first section to invite to T38. When the ATA replies with the OK (wireshark) it gives its internal IP in the T38 "owner/creator". The ATA then starts to transfer to PaIF but it nevers gets a reply because PaIF is trying to reply to the internal IP of the ATA (10.0.0.100).

This is why the T38 is failing as far as I can tell. I believe this is an issue with Asterisk and not just version 10. It was tried on version 1.4 yesterday with the same results.

I did find the same issue on another website with Asterisk 1.4 but they said it was patch/solved with 1.6.
Comments:By: Matthew Nicholson (mnicholson) 2011-09-12 15:37:03.148-0500

Please upload a pcap of a failed fax session and also the corresponding output from asterisk after enabling sip debug (sip set debug on).

You can capture a pcap as follows:
{noformat}
tcpdump -s1500 -vv -w/tmp/debug.pcap
{noformat}

You may want to use wireshark to sanitize the pcap file before uploading it.
By: Josh Zeitz (netsteller) 2011-09-13 18:33:55.699-0500

Here the pcap capture and putty log during an ATA to virtual extension fax.
By: Leif Madsen (lmadsen) 2011-09-14 10:57:30.225-0500

Assigned to Matt Nicholson to see if this is the information required to move this issue forward.
By: Matthew Nicholson (mnicholson) 2011-09-14 12:29:46.083-0500

This doesn't look like a bug in asterisk. Your ATA is instructing us to send UDPTL traffic to address "5004128" on port 5004 in its 200 OK message response to our T.38 reinvite. I can't tell from the trace, but I assume we attempt to do that. The address "5004128" evaluates to ip {{0.76.91.96}} which obviously is not correct.

Find out why your ATA is placing that "5004128" in the "c" line of your T.38 SDP and that should help you solve your issue.