[Home]

Summary:ASTERISK-24210: T.38 UDPTL Frames are sent to wrong destination IP
Reporter:Daniel Steglich (steglicd)Labels:
Date Opened:2014-08-12 08:21:41Date Closed:2014-08-13 08:22:48
Priority:MajorRegression?
Status:Closed/CompleteComponents:Resources/res_fax
Versions:11.11.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Linux vargas 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux compiled asterisk from here: http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gzAttachments:( 0) asterisk-cli-debug.txt
( 1) asterisk-fax-env.txt
( 2) extensions.conf
( 3) sip.conf
Description:I configured a Fax2Mail extension (details see extensions.conf)

Now I delete the following lines from sip.conf (see attached)
nat=comedia
t38pt_usertpsource=yes

Then send a Fax from my peer 550000 to 429 (with T.38 enabled).
Asterisk is sending re-invite and switching to T.38 which works fine.
But the "connection information" from the "200 OK with SDP" from the client will be ignored.

This means, when I start network trace on ethernet Interface connected to my peer, I do not see any udptl frames. When I start network trace on "lo" Interface of debian Server, I can see the udptl Frames (destination IP = IP where asterisk is bound to i.e. IP adress of eth1) which are rejected with icmp port unreachable.

when adding the lines from above:
nat=comedia
t38pt_usertpsource=yes

udptl is sent correctly.
Comments:By: Matt Jordan (mjordan) 2014-08-12 09:25:41.107-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Daniel Steglich (steglicd) 2014-08-12 09:52:18.854-0500

sorry, forgot to attach the file
By: Daniel Steglich (steglicd) 2014-08-12 09:53:12.709-0500

attached requested files
By: Joshua C. Colp (jcolp) 2014-08-13 08:22:48.448-0500

This does not appear to be a bug with Asterisk.

Asterisk correctly sends a re-invite to T.38 to the remote endpoint. It informs the endpoint that it would like to receive UDPTL traffic on IP address 192.168.115.27 port 4473.

The remote endpoint accepts the re-invite and tells Asterisk it would like to receive UDPTL traffic on IP address 192.168.115.27 port 10002. This is incorrect as that is the IP address of Asterisk. It should instead be saying it wants UDPTL traffic on IP address 192.168.125.102. It does not do this.

Asterisk respectively sends to where it is told, which is the incorrect IP address. Until any traffic is received from the device (since comedia is on) this is the only address that Asterisk can send to.
By: Daniel Steglich (steglicd) 2014-08-13 08:49:16.331-0500

Hi Joshua, you are right - the "connection Information" is used twice within the SDP Part of the "200 OK" and the second one is filled with asterisk IP.
When I was debuggin, I have only noticed the first "connection Information" field. On first view It seems like client causes the issue.

But one thing is strange:
The re-Invite (sent from asterisk to SIP Peer) already contains connection information twice. The SIP client simply clones the SDP Part of the SIP Message and replaces the "Connection Information Field" by his own IP address Information. During this operation he replaces only the first occurrence of connection Information.

So the question is, why is the connection information sent twice within the re-Invite (from asterisk)?

BTW: We previously used asterisk 1.8 and never had this issue with our SIP client. Also Network traces from this older asterisk instance does not show this connection information twice.
By: Daniel Steglich (steglicd) 2014-08-13 08:56:55.372-0500

update:
seems like first "Connection Information" is related to session description and second one to media description - so asterisk seems to behave correct.