[Home]

Summary:ASTERISK-20357: T.38 offer for peer that does not support T.38 fails to warn user on CLI
Reporter:Francesco Usseglio Gaudi (cecco)Labels:
Date Opened:2012-09-04 10:24:38Date Closed:2012-09-10 13:32:07
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.15.1 10.6.1 10.7.0 10.7.0-digiumphones Frequency of
Occurrence		Occasional
Related
Issues:
Environment:Debian 6.0 with kernel 2.6.32-5-amd64 sip trunk to a teles iSwitchAttachments:( 0) mydebuglog
Description:Incoming call from a sip channel doesn't work. With asterisk svn, 10.5 and 10.4 and 1.8 with same config and codecs it works without problem. Outgoing call on that sip channel always works (whatever version).
In 1.8.11.1-1digium1~squeeze it works.
I opened bug ASTERISK-20210 but for my delay it has been closed.
Comments:By: Francesco Usseglio Gaudi (cecco) 2012-09-04 10:25:11.575-0500

debug log
By: Matt Jordan (mjordan) 2012-09-04 10:59:26.304-0500

Your endpoint is offering T.38.  Is the peer configured to support T.38?  Based on the parsing in the log, it would appear as if it does not: the SDP parsing gets through the audio portion; hits the "Body 22 [ 23]: m=image 33712 udptl t38" line and bails, causing Asterisk to send a 488.
By: Francesco Usseglio Gaudi (cecco) 2012-09-04 11:11:48.435-0500

Thank you very much, i have changed sip.conf 38pt_udptl = yes. and now works!
But why does asterisk change beaviour in minor change version?
Thank you again
By: Matt Jordan (mjordan) 2012-09-04 11:26:00.783-0500

This was most likely changed by r368218, in which SDPs that include media streams that are not acceptable by Asterisk are rejected, as opposed to Asterisk accepting them.

In general, there were numerous situations in which a UA would present an offer to Asterisk that contained some media that Asterisk could not handle, and there were numerous code paths in which Asterisk would accept the INVITE request, along with whatever media it actually could not process.  This led to some interesting corner cases in which media that had been agreed upon would be sent to Asterisk, and Asterisk could not process it.

I do agree that if a 488 is sent back to the UA, something should indicate to the user on the CLI as to why that occurred.  In this case, the failure of initialize_udptl isn't being propagated to the CLI.  We can at least fix that.