T.38 and 488 Not Acceptable Here error

Asterisk Asterisk Fax
1

Hi all.

I have a Sip trunk with a voip provider (TWT, Italy) used to send faxes. It should provide T.38 capability and in fact I see they offer it. But my machine always refuses the offer with 488 Not Acceptable Here.
I read all the suggestions I could find, the problem seem to be quite common (at least, the final message “488 Not Acceptable Here” is common) but nothing changes, my machine always refuses to switch to T.38.

I simply would like to try to use T.38 since most times, the transmission goes on with G.711 and no real problem is found; but sometimes, I don’t wnow why, when we refuse the T.38 offering, the peer closes the connection.

I attach the full log with SIP messages and debug enabled, the config except and some show commands output that may be related to the problem.

I’m using Asterisk 18.20 on a CentOS Stream 8 machine. The configuration was made with the popular FreePBX web interface. It divides the config in various included files, che snippet I attach is a flattened version of them.

full.txt (120.7 KB)
config.txt (1.3 KB)
show.txt (13.4 KB)

Thank you for any suggestion.

2

I made some tests. I argue that the problem could be the providers offering T38 in an UPDATE message, rather than in an (re)INVITE. And I think that the problem is due to the fact that pjsip allows the UPDATE method, but then dislikes it if T38 is offered in an UPDATE message. In fact, Asterisk sends (not the Allow: .* UPDATE header):

[2023-11-28 10:21:35] VERBOSE[2109697] res_pjsip_logger.c: <--- Transmitting SIP request (1245 bytes) to UDP:77.239.128.7:5060 --->
INVITE sip:059876543@voip.twt.com:5060 SIP/2.0
Via: SIP/2.0/UDP 1.23.456.789:5060;rport;branch=z9hG4bKPj95db9ffa-e151-4e16-874f-a3a640069799
From: <sip:50250012345@voip.twt.com>;tag=473af9bf-ee43-45df-a154-a347b6b2faaf
To: <sip:059876543@voip.twt.com>
Contact: <sip:50250012345@1.23.456.789:5060>
Call-ID: ea444522-b296-450e-8e56-c959090ae468
CSeq: 17071 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-16.0.40.7(18.20.0)
Proxy-Authorization: Digest username="50250012345", realm="Realm", nonce="MTcwMTE2MzI4NDA4Mzk2ZTQ5YmMyMDgxYmNmOGI1NzQ2ZGRmYmE3M2UxYTJi", uri="sip:059876543@voip.twt.com:5060", response="7bd230fdde84cf677789f95fe62a8e6c", algorithm=MD5, cnonce="722ac245171643c4b38d042dabd2591a", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length:   259

and the SIP provider offers the UPDATE:

[2023-11-28 10:21:41] VERBOSE[1907737] res_pjsip_logger.c: <--- Received SIP request (865 bytes) from UDP:77.239.128.7:5060 --->
UPDATE sip:50250012345@1.23.456.789:5060 SIP/2.0
Via: SIP/2.0/UDP 77.239.128.7:5060;branch=z9hG4bKac2056013839
Max-Forwards: 19
From: <sip:059876543@voip.twt.com>;tag=1114663338
To: <sip:50250012345@voip.twt.com>;tag=473af9bf-ee43-45df-a154-a347b6b2faaf
Call-ID: ea444522-b296-450e-8e56-c959090ae468
CSeq: 1 UPDATE
Contact: <sip:059876543@77.239.128.7:5060>
Supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,x-nortel-sipvc,sdp-anat,gin
User-Agent:  Nortel SESM 21.0.26.2
Content-Type: application/sdp
Content-Length: 312

I argue this because I made these tests:

  1. on the same machine if I use a trunk of another SIP provider, that provider for some reason offers T38 in INVITE (and not UPDATE), my Asterisk likes it and the transaction is completed using T38.
  2. If I use the original failing trunk with a non-asterisk machine which does not allow UPDATE (it alows only Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH), than the provider uses INVITE to offer T38, and again the fax is completed using it.

I read in another answer on this blog (Customizing Allow header with PJSIP) that the list of Allow-ed methods is fixed. Meanwhile, I’d like to add a +1 to that request.
But I’d like to ask if there might be a way to modify the Allow header on the fly maybe with PJSIP_HEADER(update,Allow). I had a look to PJSIP_HEADER and saw examples online to modify custom header, but I don’t know if it could be applicable to the Allow: header.

Another thing I could try, may someone suggest how to remove the UPDATE handling (and Allow-ing) in the source code? I would be willing to try this too.

3

It seems I solved my problem. I just disabled Allow-ing the UPDATE methond in pjsip source and rebuilt Asterisk. Now my provider (TWT, Italy) offers T.38 via a normal re-INVITE and my Asterisk accepts and uses it. Just delete { “UPDATE”, 6} in the allowed array in sip_inv.c.

Obviusly this is not an optimal solution. It is acceptable for me because my box only sends/receives faxes. But it would be more desirable, in my opinion, to be able to decide abbout Allow-ing UPDATE or not in the config, either global or for single trunks.

4

Feature requests go on GitHub[1].

[1] GitHub - asterisk/asterisk-feature-requests: A place to submit feature and improvement requests for the Asterisk project. Contains no code.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.