488 Not Acceptable Here when T38Fax invite recieved

[Dan]

I'm running into an issue where Freeswitch is responding to SIP re-invites that offer an SDP of T38Fax to Freeswitch's external profile with 488 Not Acceptable Here.

This issue seems to affect inbound and outbound calls, its as though Freeswitch doesn't want to pass through the T38 stream to the Grandstream Fax Adapter on the other end (usually an HT802, HT813 or similar).

Here is the content type of the SDP that Freeswitch seems to dislike:
Content-Type: application/sdp v=0 o=- 1911056223 228477 IN IP4 redacted s=- c=IN IP4 redacted t=0 0 m=image 9288 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:262 a=T38FaxMaxDatagram:176 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv

I do have default settings set to permit faxing as well:



What things should I try to make Freeswitch more amenable to carrying these faxes? The ATAs on the other end are not recieving any T38 re-invite, but if I bypass Freeswitch they seem to happily accept this same style of re-invite.

 

[agree]

Can you post the SDP of your initial invite (before the Re-Invite)?

 

[Dan]

Sure, we send an invite to the provider:

INVITE sip:+DialedNumber@Provider SIP/2.0
Via: SIP/2.0/UDP FusionPBXIPv4:5080;rport;branch=z9hG4bKSF3BvNyam6F5H
Max-Forwards: 69
From: "Customers Name" <sip:+FusionPBXNumber@FusionPBXIPv4>;tag=mvrK0BmHN563B
To: <sip:+DialedNumber@Provider>
Call-ID: 16e1be22-a1da-123c-74b9-da96d7ceec93
CSeq: 70387644 INVITE
Contact: <sip:gw+b4d06b24-e720-4ae1-a3bb-7ff2bb5bf52b@FusionPBXIPv4:5080;transport=udp;gw=b4d06b24-e720-4ae1-a3bb-7ff2bb5bf52b>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 243
X-Grandstream-PBX: true
P-Access-Network-Info: IEEE-EUI-48;eui-48-addr=E6-38-83-46-99-FE
P-Emergency-Info: IEEE-EUI-48;eui-48-addr=GrandstreamMAC
X-accountcode: FusionPBXURL
X-FS-Support: update_display,send_info
Remote-Party-ID: "Customers Name" <sip:+FusionPBXNumber@FusionPBXIPv4>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1689851631 1689851632 IN IP4 FusionPBXIPv4
s=FreeSWITCH
c=IN IP4 FusionPBXIPv4
t=0 0
m=audio 31242 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSuppff - - - -
a=ptime:20

Then FusionPBX responds with a 100 Trying followed by a 200 OK (SDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP FusionPBXIPv4:5080;received=FusionPBXIPv4;branch=z9hG4bKSF3BvNyam6F5H;rport=5080
From: "Customers Name" <sip:+FusionPBXNumber@FusionPBXIPv4>;tag=mvrK0BmHN563B
To: <sip:+DialedNumber@Provider>;tag=gK0cca018a
Call-ID: 16e1be22-a1da-123c-74b9-da96d7ceec93
CSeq: 70387644 INVITE
Accept: application/sdp
Contact: <siprovider:5060;did=e33.2e87e7b3;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
Supported: replaces
Content-Length: 208
Content-Disposition: session; handling=required
Content-Type: application/sdp
X-Remote-IP: 67.231.5.112
X-Remote-SDP-Port: m=audio 33626 RTP/AVP 0
Require: timer
Session-Expires: 3000; refresher=uas

v=0
o=- 1366583992 633606 IN IP4 67.231.5.79
s=-
c=IN IP4 67.231.5.79
t=0 0
m=audio 33626 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

The provider sends another Invite with T38 as the SDP

INVITE sip:+FusionPBXNumber@FusionPBXIPv4:5080;transport=udp;gw=b4d06b24-e720-4ae1-a3bb-7ff2bb5bf52b SIP/2.0
Via: SIP/2.0/UDP Provider:5060;branch=z9hG4bKk15m4710dgs1lab2m591.1
From: <sip:+DialedNumber@Provider>;tag=gK0cca018a
To: "Customers Name" <sip:+FusionPBXNumber@FusionPBXIPv4>;tag=mvrK0BmHN563B
Call-ID: 16e1be22-a1da-123c-74b9-da96d7ceec93
CSeq: 80381 INVITE
Max-Forwards: 67
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS
Accept: application/sdp
Contact: <siprovider:5060;did=e33.2e87e7b3;transport=udp>
Supported: replaces,timer
Content-Length: 279
Content-Disposition: session; handling=required
Content-Type: application/sdp
Session-Expires: 3000; refresher=uac
Min-SE: 90

v=0
o=- 1366583992 633607 IN IP4 67.231.5.79
s=-
c=IN IP4 67.231.5.79
t=0 0
m=image 33626 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:176
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv

FusionPBX sends a 100 Trying followed by a 488 Not Acceptable Here

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP Provider:5060;branch=z9hG4bKk15m4710dgs1lab2m591.1
From: <sip:+DialedNumber@Provider>;tag=gK0cca018a
To: "Customers Name" <sip:+FusionPBXNumber@FusionPBXIPv4>;tag=mvrK0BmHN563B
Call-ID: 16e1be22-a1da-123c-74b9-da96d7ceec93
CSeq: 80381 INVITE
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Content-Length: 0

 

[agree]

You can set proxy_media=true in your dialplan when sending faxes so freeswitch wouldn't care about the media type. Also, freeswitch has clear logs on T38 negotiation and media re-negotiation. If you can post them here I can try to help you.

 

[Dan]

Thanks @agree , here are the logs! I will give proxy_media=true a try as well.

Edit: Cleaner logs

 

[agree]

The log shows freeswitch refusing T38. This means fax_enable_t38 isn't set on the channel.

 

[Dan]

Hmm, any ideas where this might be getting mis-set in the dialplan? I tried setting fax_enable_t38 as a global variable and also on the outbound route to no avail, and searching under Dialplans => Dialplan Manager only searches the Name field of each dialplan it appears.

 

[Dan]

Just tried setting action export fax_enable_t38=true in the global-variables and in the NANP outbound dialplan, then reloaded XML and cleared cache to retest, but still seeing 488 Not Acceptable here when placing an outbound call and trying to re-invite to T.38

 

[agree]

The dialplan logs should show why it doesn't get set. There's also a variable 'refuse_t38', but I doubt you set it somewhere.

 

[Dan]

Are these the logs your looking for? I added the following variables to the outbound dialplan too (as suggested by T38Fax), but no luck still.

Action	Export	fax_enable_t38=true
Action	Export	fax_enable_t38_request=false
Action	Export	t38_passthru=true
Action	Export	fax_use_ecm=true

 

[agree]

You have two outbound routes that match your dialed regex, BulkVS and NANP.1d10. You've set the t38 variables on the NANP.1d10 route, but the call gets routed to the BulkVS route.

 

[Dan]

I disabled the BulkVS.180033445566778829d6 route and retested (got 488 from Freeswitch again), but I'm unclear how to tell which route the call chose. Any guidance would be appreciated, trying to get more familiar with reading these logs.

 

[agree]

I think you sent the same logfile as before

 

[Dan]

Crumb, here is a newer logfile. I'm on IRC at dan0 as well in #fusionpbx on Libera.chat

 

[Dan]

Deleting the BulkVS Tollfree route got T.38 negotiation working, woo! Faxing FaxToy's local 213 number is a bit problematic though, it keeps failing (log attached).