13 thoughts on - Res_fax T.38 Gateway With SpanDSP – Force ReINVITE?

• —– Original Message —

• I can’t help with your root problem (maybe check “core show function FAXOPT”?), but the spandsp site is up. Try using http://www.spandsp.org. Downloads are available here: http://www.spandsp.org/downloads/spandsp/

  -Dave

• No thoughts on your problem, I do think you will need a newer version of spandsp through – the site seems to be up now.

• What type of endpoint are you using which is originating the call and is it T.38 capable?

  Larry.

• Have you had a look at https://wiki.asterisk.org/wiki/display/AST/SIP+Direct+Media+Reinvite+Glare+Avoidance

  As an exercise you could disable T.38 on ‘Asterisk calling system’, if you have an ATA which is originating the call to ‘Asterisk calling system’ disable T.38 on that device too and disable in your sip.conf using t38pt_udptl=no.

  If you are using SendFax() on ‘Asterisk calling system’ ensure T.38 is not able to be used.

  If using an ATA connecting to ‘Asterisk calling system’ ensure you have set in your peer’s configuration canreinvite=no or directmedia=no, depending on the version of Asterisk you are running on this system.

  On Asterisk system in ‘(box in question)’ set directmedia=no for the peer which is connecting to ‘SIP Provider’ and also to ‘Asterisk calling system’, you may want to set setvar

• —– Original Message —

• —– Original Message —

• —– Original Message —

• —– Original Message —

• The canreinvite= option is an old setting, this is replaced by the directmedia= option in newer versions of Asterisk, it doesn’t prevent a re-invite, it keeps the audio going through asterisk rather than negotiating an audio channel directly with the other endpoint.

  The reason I suggested disabling udptl at that end is because my understanding of how the implementation of T.38 Gateway works on Asterisk is;

  1) it does not utilise any of the T.38 gateway features in spandsp

  2) the gateway will not step in if the originator negotiates T.38

  Considering the other post you sent, are you suing IAX between the two Asterisk boxes?

  To test the T.38 Gateway can work on your box in question set up an IAX
  modem and configure HylaFAX modem to use the iaxmodem on the box in question, test the gateway functionality.

  When I tested Asterisk 11 a little while back I configured HylaFAX on my current system to communicate with an IAX modem on my Asterisk 11 test box and was able to observe the T.38 gateway function.

  I can’t tell from the information you’ve provided if the old Asterisk box is on the same network or having to traverse a WAN link to make the connection out through to your SIP provider.

  Perhaps you could provide more information about your set up such as entries from your sip.conf, iax.conf, udptl.conf etc.

  Larry.

• IAXmodem (other host on network) -> Asterisk 1.2 (IAX) -> Asterisk 1.8
  with Fax Gateway Patch -> SIP provider -> PSTN Fax destination

  I have successfully sent a fax using a full page image via an Asterisk
  1.2 system which forwards the request to my Asterisk 1.8 over an IAX
  channel, Asterisk 1.8 has the T.38 Fax Gateway patch installed. The outbound call triggered the T.38 gateway and the fax was received without error. I have ECM disabled in my IAX modem configuration in Hylafax.

  I don’t have Asterisk 11 running to test with at this time however I
  confirmed the T.38 Gateway functions in Asterisk 11 when testing it.

  — Accepting AUTHENTICATED call from 192.168.54.18:
  > requested format = ulaw,
  > requested prefs = (ulaw|alaw|slin),
  > actual format = alaw,
  > host prefs = (alaw|ulaw),
  > priority = mine
  — Executing [@FAX-T30:1] Dial(“IAX2/faxgw-iax-1210”,
  “SIP/@itsp-fax,55″) in new stack
  == Using SIP RTP TOS bits 184
  — Called SIP/@itsp-fax
  — SIP/itsp-fax-0000000b is making progress passing it to IAX2/faxgw-iax-1210
  — SIP/itsp-fax-0000000b is making progress passing it to IAX2/faxgw-iax-1210
  == Using SIP RTP TOS bits 184
  — SIP/itsp-fax-0000000b answered IAX2/faxgw-iax-1210
  [Oct 25 23:24:11] NOTICE[27896]: channel.c:4220 __ast_read: Dropping incompatible voice frame on IAX2/faxgw-iax-1210 of format slin since our native format has changed to 0x8 (alaw)
  — Got Fax Tone CED Chan SIP/itsp-fax-0000000b [1] Sending T.38
  Params Peer Is IAX2/faxgw-iax-1210 [0]
  — Request on IAX2/faxgw-iax-1210 [0] Storing I:
  SIP/itsp-fax-0000000b [1]
  == Using UDPTL TOS bits 184
  — Negotiated on SIP/itsp-fax-0000000b [4] Ignoring I:
  IAX2/faxgw-iax-1210 [0]
  — T.38 Gateway starting for chan SIP/itsp-fax-0000000b and peer IAX2/faxgw-iax-1210

  pbx*CLI> iax2 show channels Channel Peer Username ID (Lo/Rem) Seq
  (Tx/Rx) Lag Jitter JitBuf Format FirstMsg LastMsg IAX2/faxgw-iax-1210 192.168.54.18 faxgw-iax 01210/00004
  00010/00005 00000ms -0001ms 0000ms alaw Rx:NEW Tx:ACK
  1 active IAX channel pbx*CLI> fax show sessions

  Current FAX Sessions:

  Channel Tech FAXID Type Operation State File(s)
  SIP/itsp-fax-0000000 Spandsp 1 T.38 receive Active
  (null)

  1 FAX sessions

  — Executing [h@FAX-T30:1] GotoIf(“IAX2/faxgw-iax-1210”, “0?2:3”)
  in new stack
  — Goto (FAX-T30,h,3)
  — Executing [h@FAX-T30:3] NoOp(“IAX2/faxgw-iax-1210”, “Finish if_FAX-T30_37”) in new stack
  — Executing [h@FAX-T30:4] NoOp(“IAX2/faxgw-iax-1210”, “Call/Fax Ended 2014-10-25 23:27:38 +0800”) in new stack
  — Connection Statistics
  Bit Rate :14400
  ECM : No
  Pages : 1
  == Spawn extension (FAX-T30, , 1) exited non-zero on
  ‘IAX2/faxgw-iax-1210’
  — Hungup ‘IAX2/faxgw-iax-1210’

• It would seem for Asterisk 11 and T.38 Gateway work for an IAX channel you require the following;

  IAX2 -> SIP -> T.38 Gateway -> ITSP (SIP)

  Where as it would be nicer if it would accept acting as a gateway for an IAX channel i.e.;

  IAX2 – T.38 Gateway -> ITSP (SIP)

  If an IAX2 channel is connected directly to a context with FAXOPT(t38gateway) enabled I see ‘ast_rtp_read: RTP Read too short’
  messages and a failed transmission, the same is observed if using SIP
  with udptl=no instead of IAX2 channel;

  SIP (udptl=no) -> T.38 Gateway -> ITSP (SIP).

  Not sure if this is by design!

  Maybe time for another friendly chat with your ITSP in the hope they can resolve the issue.

  Larry.

• Well, forgive me as I should have had an Asterisk 11 system up and running and performing tests before posting.

  It would appear there is a behavioural difference with the patch created for Asterisk 1.8 and the implementation applied to Asterisk 11.

  The observations as listed above relating to the fax gateway stepping in, occurs when an outbound fax call is made using either of the g711
  codecs, Asterisk detects the fax tones in the calling leg about 3
  seconds after the call has been answered and sends a T.38 re-invite to the ITSP.

  Using Asterisk 11, when an outbound call is made, the fax gateway detection feature does not do anything on the leg of the call (as you have observed) to the ITSP until it receives a T.38 re-invite from the ITSP, my observations show this occurs about 4 seconds after the call is answered. I suspect once the T.38 re-invite is received from the ITSP, the T.38 Gateway sends a T.38 re-invite on the leg of the caller to check if it is capable of T.38. I have not confirmed this definitively.

  I’m obviously fortunate my ITSP is correctly handling T.38.

  Larry.