#14 t38modem 2.0 does not receive fax

[sf4thg]

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

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

tcpdump of communication over port 6060

[sf4thg]

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: 1.2.3.7!=1.2.3.7 || 16216!=4880

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

[sf4thg]

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.

[sf4thg]

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]

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 1.2.3.7.5060 > 1.2.3.7.6060: UDP, length 852
E..p.)..@..-.............\..SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.7:6060;branch=z9hG4bKb0ba9ee1-249f-e011-915e-001517c8c649;received=1.2.3.7;rport=6060
From: <sip:0128700326092@1.2.3.7:6060>;tag=ce5dfce0-249f-e011-915e-001517c8c649
To: "012343279799" <sip:012343279799@1.2.3.7>;tag=as1aef71ca
Call-ID: 471971bc06babee4770f013a4030ac42@1.2.3.7:5060
CSeq: 2 INVITE
Server: Asterisk PBX 1.8.4.3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:012343279799@1.2.3.7:5060>
Content-Type: application/sdp
Content-Length: 238

v=0
o=root 276797480 276797481 IN IP4 1.2.3.7
s=Asterisk PBX 1.8.4.3
c=IN IP4 1.2.3.7
t=0 0
m=image 4127 udptl t38
a=sendrecv <----- missing attribute
a=T38FaxVersion:0
a=T38MaxBitRate:2400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:396
----------

[sf4thg]

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]

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

and

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

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