Incoming Fax Issue With Asterisk 11.7 And Digium Fax

Home » Asterisk Users » Incoming Fax Issue With Asterisk 11.7 And Digium Fax
Asterisk Users 8 Comments

Hi, im using a Asterisk Server which is not behind NAT. First i had problems with the fax detection. But this is now solved after adding a wait(2) at the correct place. But i’m still unable to receive a fax due to res_rtp_asterisk.c:3548 ast_rtp_read: RTP Read too short after the Fax session has started.

My sip.conf includes

[general]
allowguest=no alwaysauthreject=yes

sendrpid=rpid trustrpid=yes language

8 thoughts on - Incoming Fax Issue With Asterisk 11.7 And Digium Fax

  • Hi, changing

    faxdetect=cng and t38pt_udptl=no

    helped making it work.

    Thanks

    Am 03.02.2014 11:57, schrieb Larry Moore:

  • Hmm, the fax will be received as an audio call rather than T.38, setting t38pt_udptl=no has turned off T.38.

    Do you know if your upstream provider supports T.38?

    Larry.

  • as He is describing it he should actually provide t.38. but i don’t know why it is not working thus im now getting

    Feb 3 12:32:55] WARNING[9942][C-00000004]: chan_sip.c:10353
    process_sdp: Failed to initialize UDPTL, declining image stream
    [Feb 3 12:32:55] WARNING[9942][C-00000004]: chan_sip.c:10497
    process_sdp: Insufficient information in SDP (c=)… and then the fax session starts recording data

    Am 03.02.2014 12:34, schrieb Larry Moore:

  • In udptl.conf set use_even_ports=yes and then issue a reload.

    You can confirm the settings have been applied by performing udptl show config.

    Change the the t38 line to read as;

    t38pt_udptl=yes,redundancy,maxdatagram=400

    Reload sip and test.

  • Am 03.02.2014 12:56, schrieb Larry Moore:
    after that i started udptl debug as well and now i’m getting lots of

    UDPTL (SIP/sipcall.ch-00000007): packet to 212.117.203.76:24492 (seq
    152, len 11)

    and in between

    [Feb 3 13:18:30] WARNING[26313][C-00000007]: res_rtp_asterisk.c:3548
    ast_rtp_read: RTP Read too short

    and in the end

    [Feb 3 13:18:37] WARNING[9942]: chan_sip.c:4409 __sip_autodestruct:
    Autodestruct on dialog ’24d15e0d-28df847a-9fae13c-7ace@sip.iforb.com~1o’
    with owner SIP/sipcall.ch-00000007 in place (Method: BYE). Rescheduling destruction for 10000 ms
    [Feb 3 13:18:41] ERROR[26313][C-00000007]: res_fax.c:1535
    generic_fax_exec: channel ‘SIP/sipcall.ch-00000007’ FAX session ‘7’
    failure, reason: ‘fax session timed-out’ (TIMEOUT)
    == Spawn extension (fax-rx, receive, 11) exited non-zero on
    ‘SIP/sipcall.ch-00000007’

    Thx, Jakob

  • The T.38 connection will be attempted when ReceiveFax is called.

    The port number to use should be in the SDP information, yes, allow udp ports 4000-4999 in and out. If your firewall can be so configured you could set it to allow traffic in and out based upon the user ID Asterisk is running as, assuming it is using a unique unprivileged id.

    You may like to try the following to see if your SIP provider will initiate a T.38 re-invite.

    sip.conf

    [general]
    faxdetect=t38

    [sipcall.ch]
    directmedia=no

    In extensions.conf change Wait(2) to Wait(5), if your VSP sends you a T.38 re-invite this will trigger the switch to the Fax extension.

    If this proves successful you can work on removing the Wait() from your dialplan as Asterisk will remain in the audio path and should successfully switch to the fax extension if extension 200 or 201 answer a call that happens to be a fax.

    Larry.

  • Larry Moore omninet.net.au> writes:

    Hi to all

    Sorry to bump this old thread. Well, I found a while ago finally the reason why T.38 doesn’t work in conjunction with Swiss VoIP provider sipcall.

    Despite T.38 is stated as “supported”, that provider does NOT support T.38. Their T.38 gateway has some fundamental negotiation problems, – it “exceeds the T4 timer of the T.30 protocol”. Therefore, T.38 faxing does not work. http://wiki.innovaphone.com/index.php?title=Howto:Sipcall_business_-_SIP_Provider_Compatibility_Test

    Sipcall has confirmed me that they work now on a solution. Will see…

    Kind regards,

    Clemens