#14 t38modem 2.0 does not receive fax


Hi, I'm using T38Modem 2.0.0 with HylaFAX+ 5.5.0 and Asterisk

I call t38modem with:
/usr/local/sbin/t38modem -tttt -o /var/log/t38modem0.log --no-h323 -u T38modem0 --sip-listen udp$ --sip-t38-udptl-redundancy '2:I,9:L,32767:H' --ptty +/dev/ttyT380 --route modem:.*=sip:<dn>@ --route sip:.*=modem:<dn>

After a fax call, the connection with t38modem is established, HylaFAX reports "ANSWER: FAX CONNECTION DEVICE '/dev/ttyT380'", but a fax is never received.

In the tcpdump I see the correct handshaking between Asterisk and T38Modem, but finaly T38Modem switches to "recvonly" and Asterisk answers with "SIP/2.0 488 Not acceptable here" and the call ends shortly after that (see attached dump-file).

I applied the small fix from Request ID: 3317275 that made it possible to establish the connection at all.

Thanks a lot, sf4thg


  • sf4thg

    sf4thg - 2011-06-27

    tcpdump of communication over port 6060

  • sf4thg

    sf4thg - 2011-06-29

    Some additional info:

    - the INVITE with G711 from Asterisk with T38Modem is successfull
    - T38Modem makes a REINVITE with T38 "sendrecv"
    - Asterisk changes the port from rtp to udtpl and tells T38Modem the new port
    - finally T38Modem makes an other REINVITE with T38 "recvonly"

    Why there is the second REINVITE and why with "recvonly"?

    In the t38modem.log there is an entry:

    Pool:0xb7c79b90 SIP Remote changed IP address:!= || 16216!=4880

    And after this there comes the second REINVITE instead of accepting the new port.

  • sf4thg

    sf4thg - 2011-07-01

    Again some more info:

    - after the initial handshake, Asterisk initiates a bidirectional T38-connection
    - t38modem, as receiving device, wants to switch to "recvonly" but this is not allowed by Asterisk
    - with the "return" before t38modem is closing the channel to reopen it unidirectional this problem is "solved", but for sure only works in this environment

    Change in src/sip/sipcon.cxx:

    2473: // Check if we had a stream and the remote has either changed the codec or
    2474: // changed the direction of the stream
    2475: OpalMediaStreamPtr sendStream = GetMediaStream(rtpSessionId, false);
    2476: if (sendStream != NULL && sendStream->IsOpen()) {
    2477: if (!remoteChanged && m_answerFormatList.HasFormat(sendStream->GetMediaFormat()))
    2478: sendStream->SetPaused((otherSidesDir&SDPMediaDescription::RecvOnly) == 0);
    2479: else {
    2480: return true;
    2481: //sendStream->GetPatch()->GetSource().Close(); // Was removed from list so close channel
    2482: //sendStream.SetNULL();
    2483: }
    2484: }

  • Vyacheslav Frolov

    RFC 3264 says:

    If the offerer wishes to both send and
    receive media with its peer, it MAY include an "a=sendrecv"
    attribute, or it MAY omit it, since sendrecv is the default.
    If an offered media stream is
    listed as sendrecv (or if there is no direction attribute at the
    media or session level, in which case the stream is sendrecv by
    default), the corresponding stream in the answer MAY be marked as
    sendonly, recvonly, sendrecv, or inactive.

    Does "MAY be marked" means "MAY omit it"? If so what is the default value?
    RFC 3264 does not say about default value for not marked answer.
    Asterisk omits "a=sendrecv" in the answer and suppose default value is sendrecv.
    opal-24174 suppose default value is recvonly so it sends opposite recvonly offer.

  • Vyacheslav Frolov

    • status: open --> pending
  • sf4thg

    sf4thg - 2011-07-07
    • status: pending --> open
  • sf4thg

    sf4thg - 2011-07-07

    The problem seems no to be the "recvonly", because we patched OPAL to send "sendrecv" instead and it didn't worked neither. I think the problem is the second REINVITE and this is what our workaround does, it avoids the closing of the connection and thus the second REINVITE.

    But probably this workaround is not the propper way to solve this problem.

  • Vyacheslav Frolov

    • status: open --> pending
  • Vyacheslav Frolov

    The OPAL sends second REINVITE because the response ("200 OK") from Asterisk is ambiguous.
    Asterisk does not include "a=sendrecv" to the response.

    The correct response from Asterisk should be:

    14:15:57.571495 IP > UDP, length 852
    E..p.)..@..-.............\..SIP/2.0 200 OK
    Via: SIP/2.0/UDP;branch=z9hG4bKb0ba9ee1-249f-e011-915e-001517c8c649;received=;rport=6060
    From: <sip:0128700326092@>;tag=ce5dfce0-249f-e011-915e-001517c8c649
    To: "012343279799" <sip:012343279799@>;tag=as1aef71ca
    Call-ID: 471971bc06babee4770f013a4030ac42@
    CSeq: 2 INVITE
    Server: Asterisk PBX
    Supported: replaces, timer
    Contact: <sip:012343279799@>
    Content-Type: application/sdp
    Content-Length: 238

    o=root 276797480 276797481 IN IP4
    s=Asterisk PBX
    c=IN IP4
    t=0 0
    m=image 4127 udptl t38
    a=sendrecv <----- missing attribute

  • sf4thg

    sf4thg - 2011-07-07
    • status: pending --> open
  • sf4thg

    sf4thg - 2011-07-07

    As far as I understand, the default behaviour is not defined in the RFC.

    So it seems that the default value for "sendrecv"/"recvonly" is defined differently in Asterisk and OPAL. Asterisk is a common solution for PBX, so it would be fine to get a soltution for this.

    Would it be possible to have some kind of command line flag to handle this?

    If this is not possible, where we can change the default in the OPAL-sources?

    Thanks a lot for your great support!

  • Vyacheslav Frolov

    • status: open --> pending
  • Vyacheslav Frolov

    It seems opal-24174 suppose default value is sendrecv too. So it's not a problem.

    IMO the problem is that Asterisk changes port for media sream:

    > m=audio 10218 RTP/AVP 8 3 0 112 5 10 7 111 9 118 101
    > ...
    > m=image 4127 udptl t38


    > Pool:0xb7c79b90 SIP Remote changed IP address:!= || 16216!=4880

    AFAIR there was a discussion in OPAL community where someone say that RFC requires the same port.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks