Summary:	ASTERISK-08156: T.38 passthru not invoked when using a Local channel
Reporter:	Alex lake (alexlake)	Labels:
Date Opened:	2006-11-20 12:16:45.000-0600	Date Closed:	2006-12-27 13:32:08.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) failed_t38.cap ( 1) T38-01Dec06-001.log ( 2) t38Log-Nov21-001.txt
Description:	Unsupported SDP media type in offer: image 28326 udptl t38 We use a carrier with a Cisco PSTN gateway (please let me know what details you need of this equipment) that detects fax tones and attempts to switch to T.38 protocol. The idea is that calls flow from PSTN-Cisco(IN)-Asterisk-Cisco(OUT)-PSTN I'm hoping that Asterisk will trigger a reinvite to bridge the Ciscos, but it doesn't (throwing the above error). Attached is the SIP log (ethereal/pcap)
Comments:	By: Alex lake (alexlake) 2006-11-20 12:18:47.000-0600 Sorry - forgot to include system details - it's Ubuntu 5.10 "Breezy Badger" running on a Dell SC430 By: dea (dea) 2006-11-20 12:20:34.000-0600 This should be fixed already in recent SVN (>47512).  There are a number of open T38 bugs with the same 'symptoms'.  Can you check-out the current SVN branches/1.4 and see if the problem has been resolved? By: Ronald Chan (loloski) 2006-11-20 18:45:58.000-0600 alexlake: please visit http://bugs.digium.com/view.php?id=7844 and help us on this along the way :) By: Alex lake (alexlake) 2006-11-21 04:35:03.000-0600 DEA - Upgraded to r47866 and the problem persists (but it did fix another problem in Zaptel we were having!) loloski - Will do... By: Joshua C. Colp (jcolp) 2006-11-21 13:21:59.000-0600 We also need to see a sip debug as well - and your sip.conf so we can confirm your settings are correct. By: Alex lake (alexlake) 2006-11-22 03:19:51.000-0600 Administrator - I've decamped to loloski's 7844 issue and posted all logs and the relevant part of sip.log there. As a bugs newbie, I'm not sure how it works, but we could do with a bit of official/developer feedback over there. Should I mark this issue as subsumed into 7844? By: Alex lake (alexlake) 2006-11-22 03:21:49.000-0600 Here's the bit of sip.conf: [gamma-OUT] type            = peer context         = from-gamma host            = 83.245.6.83 allow           = alaw t38pt_udptl     = yes canreinvite     = yes SIPdebug in file list By: Serge Vecher (serge-v) 2006-11-29 08:40:07.000-0600 7844 seems to be dealing with endpoints behind a nat -> according to your debugs you are not using a nat, so I'd assume the issues are separate. By: Alex lake (alexlake) 2006-11-29 09:59:36.000-0600 Mnay thanks for resuscitating this issue. Before proceeding I would just like to check that I'm testing what I think I'm testing. For this, I need the specification of what T.38 passthru is supposed to do (an example of it working successfully with SIP logs and verbose console logs would also be good). For the life of me, I can't find any sensible spec or documentation! By: Alex lake (alexlake) 2006-12-01 03:55:24.000-0600 T38-01Dec06-001.log now uploaded. It would appear that the Cisco is issuing the INVITE but without a media stream that Asterisk can do anything with. Perhaps I need to add something to the "allow" bit of sip.conf or else get the carrier to modify the way in which the Cisco is configured? Either way, a log (and sip.conf) from a good T38 reinvitation (SOMEONE must have one!!!) would be a very useful point for comparison. By: dea (dea) 2006-12-01 13:13:20.000-0600 I think this is related to your use of the Local channel. Following the log flow, the '488' error follows 'This Call is UP' in handle_request_invite(). We send a '488' in a number of situations, but the log flow points to a test to see if the target peer (bridgepeer) is using SIP for it's channel tech. At the point of the failure, I think that 442070605610 is set to Local and will fail. I think I can get you a small patch to test this, but if you can modify your dialplan to not use the Local channel for calls to/from 442070605610 we can prove or disprove this theory. This is not suggested as a perminant change, just a debugging step, and will provide the same validation as a patch. By: Joshua C. Colp (jcolp) 2006-12-22 11:37:58.000-0600 As DEA indicated please try without a Local channel. There is a very good possibility that when chan_sip checks the bridged channel it will see the Local channel and NOT the SIP channel, in which case T.38 would not be present and stuff would fail. By: dea (dea) 2006-12-22 12:44:39.000-0600 The reporter confirmed that not using the Local channel works (in bug 7844). OEJ has commited changes to the sample sip.conf that document the current limitation that both legs of a T38 call be SIP, and a small patch to chan_sip that logs a warning if one leg is not SIP. There are three or four open T38 bugs, but they (almost) all were due to the same issues in the code.  I say were, as I think that the bulk of the issues have been identified and resolved, or at least had work-arounds documented. Hopefully Alexlake will respond here so this bug can be closed. By: Serge Vecher (serge-v) 2006-12-27 13:32:08.000-0600 alright, since the issue has been narrowed down, resolution confirmed in another bug report and documentation committed to 1.4 branch (which are in 1.4.0 release), we can safely close the bug. alexlake: if additional problems with t.38 beyond the use of local channel arise, please either continue looking for a solution in one of the open bug reports (if symptoms are similar) or open a new bug report. Thanks.