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-0600Date Closed:2006-12-27 13:32:08.000-0600
Versions:Frequency of
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:

type            = peer
context         = from-gamma
host            =
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.