[Home]

Summary:ASTERISK-16306: T.38 UDPTL Port Negotiation Fails
Reporter:Chris T Miller (scratchspace1)Labels:
Date Opened:2010-06-30 20:58:10Date Closed:2011-06-07 14:00:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk_debug.log
Description:
T.38 calls into SIP provider (Broadvox Sonus switch) result in UDPTL data being sent to Asterisk instead of T.38 peer (Linksys 2102 ATA firmware 5.2.10). Asterisk server and ATA have public non-NAT IP addresses with no firewall.

The peers appear to negotiate T.38, with messages from Asterisk indicating that it knows the correct IP addresses and UDPTL ports of both peers, but asterisk returns a reinvite to the SIP provider with it's own IP address rather than the IP address of the ATA.

t38state never gets beyond state 4 (successful T38 would get to state 5). After several seconds, the ATA terminates the call due to lack of T.38 data stream.

Same result with Grandstream ATA.

****** ADDITIONAL INFORMATION ******

Same results with 1.4.32 and 1.4.26. Tried various versions to rule out other reported bugs.
Comments:By: Matthew Nicholson (mnicholson) 2010-07-09 14:18:53

Please upload a pcap file demonstrating this issue.  You can generate a pcap file by running the following command on the asterisk machine:

tcpdump -s1500 -w debug.pcap -vv

The resulting file will be named 'debug.pcap'

By: Leif Madsen (lmadsen) 2010-07-16 13:11:40

Looking for feedback from reporter in order to move this issue forward.

By: Paul Belanger (pabelanger) 2010-08-04 11:50:03

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines