[Home]

Summary:ASTERISK-15780: [patch] t38pt_udptl=no on a peer isn't respected (can't disable t38 negotiation on a per-peer basis)
Reporter:mdu113 (mdu113)Labels:
Date Opened:2011-01-20 16:01:29.000-0600Date Closed:2012-09-25 08:16:01
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c-t38respectconfig.diff
( 1) debug.log
Description:sip.conf:

[general]
t38pt_udptl = yes
...

[sipp1]
type=friend
username=pbxtest
permit=a.b.c.0/255.255.255.0
deny=0.0.0.0/0.0.0.0
host=a.b.c.d
context=sipp1
sendrpid=yes
dtmfmode=auto
t38pt_udptl = yes

[spa2102_01]
type=friend
username=spa2102_01
md5secret=3f52e70189bb315f222c04f92eeb6d86
context=xyz
host=dynamic
dtmfmode=rfc2833
callerid=
call-limit=3
mohsuggest=xyz
allowsubscribe=yes
subscribecontext=xyz
t38pt_udptl=no

T38 pass-through is still successfully negotiated on call between peer spa2102_01 (Linksys SPA2102 with T38 enabled) and peer sipp1 (ITSP)

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

Attached is asterisk debug.log
The problem is showing up on the line 862 of the log when spa2102_01 reinvites with t38 enabled and asterisk passing it to sipp1 while it should reject it with "488 not acceptable here" since spa2102_01 config says "t38pt_udptl=no"
Comments:By: mdu113 (mdu113) 2011-01-24 10:43:01.000-0600

here's the patch that seems to fix it for me.
i'm not sure i do it in the right place though, but it seems to work
By: Joshua C. Colp (jcolp) 2012-09-25 08:16:01.137-0500

This was taken care of long ago with reworking the UDPTL stuff. Tested and confirmed this!