|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:38||Date Closed:||2012-09-10 13:32:07|
|Versions:||220.127.116.11 10.6.1 10.7.0 10.7.0-digiumphones||Frequency of|
|Environment:||Debian 6.0 with kernel 2.6.32-5-amd64 sip trunk to a teles iSwitch||Attachments:||( 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 18.104.22.168-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|
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.