Asterisk T.38 Pass-Through Doesn’t Work

Home » Asterisk Users » Asterisk T.38 Pass-Through Doesn’t Work

What I have is:
* Asterisk 1.8.10.1~dfsg-1ubuntu1,
* SPA112 ATA with analog fax in 1-st FXS port connected,
* SIP trunk with provider supporting T.38.

My network looks like this:
* spa112 (192.168.33.200/24) and Asterisk (192.168.5.253/24) in neighbouring LANs,
* Asterisk connects to the provider (80.75.130.136) via router
(82.200.7.184). Router has full DNAT to Asterisk server.

What happens?
* The fax from SPA112 to Asterisk cmd ReceiveFax works well,
* The fax from Asterisk cmd SendFax to PSTN fax works well,
* However, the fax from SPA112 to PSTN fax doesn’t work. Using udptl debug, I can see packets between Asterisk and both sides (SPA112 and PSTN fax) but it seems that faxes can’t agree how to send image.

== sip.conf:
[general]
tcpenable=yes videosupport=yes transport=udp,tcp dtmfmode=rfc2833
qualify=yes directmedia=no allowguest=no alwaysauthreject=yes rtcachefriends=yes rtupdate=no callcounter=yes t38pt_udptl=yes,redundancy,maxdatagram 0
t38pt_rtp=no t38pt_tcp=no ignoresdpversion=yes disallow=all allow=alaw allow=ulaw externip

16 thoughts on - Asterisk T.38 Pass-Through Doesn’t Work

  • I don’t have access to one of these devices though some suggestions you could try;

    1) On SPA112 set “FAX T38 Redundancy” = 3
    2) Add t38pt_usertpsource=yes in [mtt] section
    3) Change maxdatagram=200 to maxdatagram=1400
    4) In udptl.conf change T38FaxMaxDatagram to a value of 1400
    5) In udptl.conf change use_even_ports to yes

    You don’t appear to list the sip.conf entry for the SPA112.

    Where did t38pt_rtp & t38_tcp come from?

    You may also want to experiment with the SPA112 setting “FAX T38 ECM Enable”

    Cheers,

    Larry.

  • Thank you for reply, Larry!

    I have tried to change this value with no effect. This option take no positive effect for me, asterisk continues to use ports from udptl.conf range. But in the oser side, I think, that there are no problems with network, because:
    * on router, that provide internet for asterisk configured full DNAT
    from white IP to asterisk server,
    * fax between asterisk cmd SendFax and PSTN fax works great. This settings doesnt help me. I`m sorry, spa112 peer settings are in mysql extconfig, config file analogue:
    [297]
    context=office secret=xxx host-dynamic nat=yes type=friend callerid=297
    disallow=all allow=alaw This settings I have googled on some forum and then add to my config with despair. This option doesnt help me too :(.

    Additional info: fax between two SPA112 works perfect! Now I returned settings to original state as described in first letter.


    Андрей Половов, ведущий инженер ЗАО «Флант». http://www.flant.ru/
    +7 (495) 721-10-27, доб. 412
    +7 (925) 816-66-83

  • Have you checked the installed version of firmware against the latest available from Cisco?

    Looking at your SIP information when your ITSP initiated a T.38 session it did not indicate a maxmimum bitrate, it would appear your spa112
    attempted to negotiate a connection at 2400bps.

    Do you have a sip debug session when you sent a fax from your Asterisk box to the PSTN, it would be interesting to see if it sends it as a t.38
    or reverts to G711 audio.

    You will only want to experiment with the ECM option once you have t.38
    working.

    Larry.

  • Oh! I didn’t guess to check. The firmware was not fresh, but upgrading doesn’t help. Whether there is a way to force my provider to indicate maximum bitrate?
    I have collect a set of debugs (with fresh SPA112 firmware) and actual config files:

    == spa112

  • I would suggest you test the SPA112 directly against your SIP provider however ensure you have the latest firmware, there appear to have been some FAX related fixes in recent versions.

    To do this change the following (based upon the screen shot you made available);

    Nat Mapping Enable: yes

    Call Waiting Serv: no MWI Serv: no

    Proxy: 80.75.130.136

    Register: no Make Call Without Reg: yes Ans Call Without Reg: yes

    User ID: 74957777777
    Password:

    FAX T38 Redundancy: 3
    FAX Tone Detect Mode: callee FAX T38 Return to Voice: no

    When you get this working you can then look at making it work through Asterisk – this is how I got my SPA8800 working.

    I am assuming your network configuration is set up correctly on the spa112.

    You may want to look at enabling the following options, on my SPA8800
    they are located under the SIP tab in the section headed NAT Parameters:

    Handle via rport: yes Insert via rport: yes Send Resp to Src Port: yes

    In addition, once it is working and providing your SIP provider permits ECM through a T.38 service I would encourage one to enable options such as FAX T38 ECM Enable.

    If you are still experiencing problems you may want to perform a packet capture (set the snap size to 1500) of the communications between the spa112 and the other end point and run it through Wireshark and examine the VoIP calls in the captured packets.

    Good luck.

    Larry.

  • Hi!

    I have exactly the same problem on asterisk 1.8.22.0 and also on separate
    11.2.1 when sending fax to PSTN. Tryed with spa-3102, spa-2102, Patton Smartnode 4634, and Zoiper softphone. SpanDsp also works without any problem on my box.

    As I remember it was a bug in 1.8.1.x that the a=T38MaxBitRate paramater was sent as “maxBitRate”. Without capital “M”.

    Are you closer to the solution?
    I have tryed almost anything and I don’t understand why sends the T38MaxBitRate:2400 parameter.

    regards,

    Blaxy

  • Could it be because the remote endpoint does not supply the T38MaxBitRate attribute in its reply which then leads to Asterisk applying the Minimum Rate to your ATA!?

    I am referring to the information around lines 403 & 404 of https://gist.github.com/anonymous/5701207.

    Do you know what the Fax Rate was for the connection in https://gist.github.com/anonymous/5701150.

    What happens if you insert in your dialplan something like

    Set(FAXOPT(minrate)=4800)

    Cheers,

    Larry.

  • VGhlIGE9VDM4TWF4Qml0UmF0ZSBpc3N1ZSB5b3UgcmVmZXIgdG8gd2FzIG9uZSB0aGF0IHdhcyBh Y3R1YWxseSANCmRpc2NvdmVyZWQgYXQgbXkgY29tcGFueSBhbmQgc3VibWl0dGVkIGJ5IGEgY29s bGVhZ3VlLiBJdCB3YXMgZml4ZWQgaW4gDQoxMS4zLjAgYW5kIDEuOC4yMS4wLiBIb3dldmVyLCBJ
    IHRoaW5rIHRoYXQgaXQgd291bGRuJ3QgaGVscCBiYXNlZCBvbiB0aGUgDQpkZXNjcmlwdGlvbiBi ZWxvdyBiZWluZyB0aGF0IHRoZSBwYXJhbWV0ZXIgd2FzIG1pc3NpbmcgYWx0b2dldGhlci4gSSB0
    aGluayANCmlmIHRoYXQgcGFyYW1ldGVyIGlzIG1pc3NpbmcsIHRoZW4gdGhlIGNvZGUgd291bGQg aW4gZmFjdCBkZWZhdWx0IHRvIDI0MDAgDQphcyBhIHNhZmUgdmFsdWUuDQoNCktldmluIExhcnNl biAtIFN5c3RlbXMgQW5hbHlzdCANCg0KDQoNCkZyb206ICAgWm9sdMOhbiBGZWtldGUgPGJsYXh5
    QGd5b3ouaW5mbz4NClRvOiAgICAgYXN0ZXJpc2stdXNlcnNAbGlzdHMuZGlnaXVtLmNvbSwgDQpE
    YXRlOiAgIDA3LzIxLzIwMTMgMDQ6NDAgUE0NClN1YmplY3Q6ICAgICAgICBbYXN0ZXJpc2stdXNl cnNdIEZ3ZDogUmU6IEFzdGVyaXNrIFQuMzggUGFzcy1UaHJvdWdoIA0KZG9lc24ndCB3b3JrDQpT
    ZW50IGJ5OiAgICAgICAgYXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tDQoN
    Cg0KDQoNCkhpIQ0KSSBoYXZlIGV4YWN0bHkgdGhlIHNhbWUgcHJvYmxlbSBvbiBhc3RlcmlzayAx LjguMjIuMCAgYW5kIGFsc28gb24gc2VwYXJhdGUgDQoxMS4yLjEgd2hlbiBzZW5kaW5nIGZheCB0
    byBQU1ROLg0KVHJ5ZWQgd2l0aCBzcGEtMzEwMiwgc3BhLTIxMDIsIFBhdHRvbiBTbWFydG5vZGUg NDYzNCwgYW5kIFpvaXBlciANCnNvZnRwaG9uZS4NClNwYW5Ec3AgYWxzbyB3b3JrcyB3aXRob3V0
    IGFueSBwcm9ibGVtIG9uIG15IGJveC4NCkFzIEkgcmVtZW1iZXIgaXQgd2FzIGEgYnVnIGluIDEu OC4xLnggdGhhdCB0aGUgYT1UMzhNYXhCaXRSYXRlIHBhcmFtYXRlciANCndhcyBzZW50IGFzICJt YXhCaXRSYXRlIi4gV2l0aG91dCBjYXBpdGFsICJNIi4gDQpBcmUgeW91IGNsb3NlciB0byB0aGUg c29sdXRpb24/DQpJIGhhdmUgdHJ5ZWQgYWxtb3N0IGFueXRoaW5nIGFuZCBJIGRvbid0IHVuZGVy c3RhbmQgd2h5IHNlbmRzIHRoZSANClQzOE1heEJpdFJhdGU6MjQwMCBwYXJhbWV0ZXIuDQpyZWdh cmRzLA0KQmxheHkNCj4gT24gMDYvMDMvMjAxMyAwNTowMyBQTSwgTGFycnkgTW9vcmUgd3JvdGU6
    DQo+ID4gSGF2ZSB5b3UgY2hlY2tlZCB0aGUgaW5zdGFsbGVkIHZlcnNpb24gb2YgZmlybXdhcmUg YWdhaW5zdCB0aGUgbGF0ZXN0IA0KPiA+IGF2YWlsYWJsZSBmcm9tIENpc2NvPw0KPiBPaCEgSSBk aWRuJ3QgZ3Vlc3MgdG8gY2hlY2suIFRoZSBmaXJtd2FyZSB3YXMgbm90IGZyZXNoLCBidXQgdXBn cmFkaW5nIA0KPiBkb2Vzbid0IGhlbHAuDQo+ID4gTG9va2luZyBhdCB5b3VyIFNJUCBpbmZvcm1h dGlvbiB3aGVuIHlvdXIgSVRTUCBpbml0aWF0ZWQgYSBULjM4IA0KPiA+IHNlc3Npb24gaXQgZGlk IG5vdCBpbmRpY2F0ZSBhIG1heG1pbXVtIGJpdHJhdGUsIGl0IHdvdWxkIGFwcGVhciB5b3VyIA0K
    PiA+IHNwYTExMiBhdHRlbXB0ZWQgdG8gbmVnb3RpYXRlIGEgY29ubmVjdGlvbiBhdCAyNDAwYnBz Lg0KPiBXaGV0aGVyIHRoZXJlIGlzIGEgd2F5IHRvIGZvcmNlIG15IHByb3ZpZGVyIHRvIGluZGlj YXRlIG1heGltdW0gYml0cmF0ZT8NCj4gPiBEbyB5b3UgaGF2ZSBhIHNpcCBkZWJ1ZyBzZXNzaW9u IHdoZW4geW91IHNlbnQgYSBmYXggZnJvbSB5b3VyIEFzdGVyaXNrIA0KDQo+ID4gYm94IHRvIHRo ZSBQU1ROLCBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBzZWUgaWYgaXQgc2VuZHMgaXQgYXMg YSANCj4gPiB0LjM4IG9yIHJldmVydHMgdG8gRzcxMSBhdWRpby4NCj4gSSBoYXZlIGNvbGxlY3Qg YSBzZXQgb2YgZGVidWdzICh3aXRoIGZyZXNoIFNQQTExMiBmaXJtd2FyZSkgYW5kIGFjdHVhbCAN
    Cj4gY29uZmlnIGZpbGVzOg0KPg0KPiA9PSBzcGExMTIg4oCUIGNtZCBSZWNlaXZlRmF4DQo+IGh0
    dHBzOi8vZ2lzdC5naXRodWIuY29tL2Fub255bW91cy81NzAxMDMyDQo+DQo+ID09IGNtZCBTZW5k RmF4IOKAlCBQU1RODQo+IGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2Fub255bW91cy81NzAxMTUw DQo+DQo+ID09IHNwYTExMiDigJQgUFNUTg0KPiBodHRwczovL2dpc3QuZ2l0aHViLmNvbS9hbm9u eW1vdXMvNTcwMTIwNw0KPg0KPiA9PSBzaXAuY29uZg0KPiBodHRwczovL2dpc3QuZ2l0aHViLmNv bS9hbm9ueW1vdXMvNTcwMTIzMQ0KPg0KPiA9PSB1ZHB0bC5jb25mDQo+IGh0dHBzOi8vZ2lzdC5n aXRodWIuY29tL2Fub255bW91cy81NzAxMjQ3DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMg ZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBieSB0aGUgU3ltYW50ZWMgRW1haWwgU2VjdXJpdHkuY2xv dWQgc2VydmljZS4NCkZvciBtb3JlIGluZm9ybWF0aW9uIHBsZWFzZSB2aXNpdCBodHRwOi8vd3d3
    LnN5bWFudGVjY2xvdWQuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fLS0NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KLS0gQmFu ZHdpZHRoIGFuZCBDb2xvY2F0aW9uIFByb3ZpZGVkIGJ5IGh0dHA6Ly93d3cuYXBpLWRpZ2l0YWwu Y29tIC0tDQpOZXcgdG8gQXN0ZXJpc2s/IEpvaW4gdXMgZm9yIGEgbGl2ZSBpbnRyb2R1Y3Rvcnkg d2ViaW5hciBldmVyeSBUaHVyczoNCiAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuYXN0ZXJpc2su b3JnL2hlbGxvDQoNCmFzdGVyaXNrLXVzZXJzIG1haWxpbmcgbGlzdA0KVG8gVU5TVUJTQ1JJQkUg b3IgdXBkYXRlIG9wdGlvbnMgdmlzaXQ6DQogICBodHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9tYWls bWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVzZXJzDQoNCg=

  • The Case Insensitive checking of the T.38 attributes was introduced in these versions.

    Looking at the ITU-T T.38 Implementors’ Guide (11 May 2012)in Table H.2, if the T38MaxBitRate attribute is omitted they suggest using the default value, they indicate a default value of 14400.

    Larry.

  • Another suggestion might be to set the variable in the peer configuration like;

    setvar=FAXOPT(minrate)=4800

    Larry.

  • Thank You Larry!

    I have discussed with my provider. They are not able to insert the T38MaxBitRate value into the sip answer. 🙁
    https://gist.github.com/anonymous/6120148 (line 559)

    That means we are not able to passtrough T38 Faxes with any asterisk version at all?
    What do you mean? Am I able to modify and compile the source? Is it compicated? (I’m not a developer)

    Regards, Blaxy

    2013/7/23 Larry Moore

  • It would seem that having a configurable option would be an idea for this scenario.

    My testing with Asterisk 1.8 and T.38, I obserevd that setting FAXOPT(minrate) or FAXOPT(maxrate)had no effect, I concluded that when Astrerisk is receiving it uses hard coded values – is this a sane thing to do?!

    If Asterisk T.38 reception could be configured to use the values defined in FAXOPT(minrate) or FAXOPT(maxrate)this would be a good starting point for situations like this one.

    Cheers,

    Larry.

  • Larry Moore wrote:

    That implies it would solve the problem, which my gut and experience tells me… it wouldn’t. I think the T.38 implementation is just cobbled together and without knowing exactly how it behaves getting it to work would likely be a nightmare (trust me, I’ve spent time in those deep dark reaches). Throwing assumptions and defaults at it to try to make it work is of course an option.

    When Asterisk is receiving the stack implementation offers what it wants, with the ability to override. So Asterisk doesn’t hard code those values, the stack provides them. What is hard coded is the default values if none are received.

    I would even say it’s a bug that the negotiation doesn’t fail, since the remote side isn’t providing a mandatory attribute.

  • 2013/8/1 Joshua Colp

    Yes you’re right! As I know FAXOPT() value affect only when asterisk woks as gateway. We need passtrouh because my endpoints and also my provider supports T38.

    https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway
    “Using T.38 Gateway mode

    T.38 Gateway mode should be used when one leg of a call is not capable of T.38 mode. In the event that both legs are capable and Gateway mode is configured, then the Gateway will step out of the way, allowing *transparent T.38 passthrough*.”

    The main problem is that I can’t use G711 for the entire fax session because the endpoints has 20-30ms response time.

    When I try to use my Asterisk as FAXOPT gateway (endpoint leg T38 and provider leg G711) can I force somehow to not accept the T38 re-INVITEs from the provider?
    They have ~1ms response time, so G711 on that leg would be fine but they also detect fax CED tones and sends the re-INVITEs.

    Regards,

    Blaxy

  • Have you tried setting in your sip.conf for your provider t38pt_udptl=no whilst having the gateway option enabled?

    Sorry I cant test this myself.

    Cheers,

    Larry.