T38 gateway 488 error

we have sip trunk with Kamailio and asterisk 16.9 and we have kazoo-HPBX, when we send a fax from one H-PBX to another H-PBX directly without trunk (asterisk) everything is ok but when using sip trunk with asterisk Set(FAXOPT(gateway)=yes) in extensions.conf.

my sip.conf:
t38pt_udptl=yes,redundancy,maxdatagram=400
directmedia=no
canreinvite=no

extensions.conf
exten => _+9821XXXXXXXX,1,NoOp(**** FAX DETECTED ****)
same => n,Set(FAXOPT(gateway)=yes)
same => n,Dial(SIP/{EXTEN},100) same => n,Verbose({FAXOPT(statusstr)})
same => n,Hangup()

I give 488 error in sngrep and these are logs in asterisk CLI :

== Using SIP RTP CoS mark 5
> 0x7f94d40858d0 – Strict RTP learning after remote address set to: 172.16.3.72:31946
– Executing [+982191079724@public:1] NoOp(“SIP/+982191079726-0000002a”, “**** FAX DETECTED ****”) in new stack
– Executing [+982191079724@public:2] Set(“SIP/+982191079726-0000002a”, “FAXOPT(gateway)=yes”) in new stack
– Executing [+982191079724@public:3] Dial(“SIP/+982191079726-0000002a”, “SIP/+982191079724,100”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/+982191079724
== Using UDPTL CoS mark 5
> 0x7f94bc04d0a0 – Strict RTP learning after remote address set to: 172.16.3.72:31954
– SIP/+982191079724-0000002b answered SIP/+982191079726-0000002a
– Channel SIP/+982191079724-0000002b joined ‘simple_bridge’ basic-bridge <7389ff19-4154-4d77-91de-302808b65bbf>
– Channel SIP/+982191079726-0000002a joined ‘simple_bridge’ basic-bridge <7389ff19-4154-4d77-91de-302808b65bbf>
> 0x7f94bc04d0a0 – Strict RTP switching to RTP target address 172.16.3.72:31954 as source
> 0x7f94d40858d0 – Strict RTP switching to RTP target address 172.16.3.72:31946 as source
[Jul 18 07:50:13] NOTICE[7377][C-00000017]: chan_sip.c:8749 sip_read: FAX CNG detected but no fax extension
== Using UDPTL CoS mark 5
– Channel SIP/+982191079726-0000002a left ‘simple_bridge’ basic-bridge <7389ff19-4154-4d77-91de-302808b65bbf>
== Spawn extension (public, +982191079724, 3) exited non-zero on ‘SIP/+982191079726-0000002a’
– Channel SIP/+982191079724-0000002b left ‘simple_bridge’ basic-bridge <7389ff19-4154-4d77-91de-302808b65bbf>

You need to set “faxdetect = no” in your sip.conf, at least for the peers which you want to have T.38 capabilities.

Thank you, dear friend,
I changed faxdetect to no (faxdetect = no) in sip.conf but my problem doesn’t solve.
Asterisk CLI:
== Using SIP RTP CoS mark 5
> 0x7f3e0c03e080 – Strict RTP learning after remote address set to: 172.16.3.72:32786
– Executing [+982191079724@public:1] NoOp(“SIP/+982191079726-00000006”, “**** FAX DETECTED ****”) in new stack
– Executing [+982191079724@public:2] Set(“SIP/+982191079726-00000006”, “FAXOPT(gateway)=yes”) in new stack
– Executing [+982191079724@public:3] Verbose(“SIP/+982191079726-00000006”, “gateway operation started successfully”) in new stack
gateway operation started successfully
– Executing [+982191079724@public:4] Dial(“SIP/+982191079726-00000006”, “SIP/+982191079724,100”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/+982191079724
== Using UDPTL CoS mark 5
> 0x7f3e0005f600 – Strict RTP learning after remote address set to: 172.16.3.72:32806
– SIP/+982191079724-00000007 answered SIP/+982191079726-00000006
– Channel SIP/+982191079724-00000007 joined ‘simple_bridge’ basic-bridge <6ac5be95-38f5-4af1-97da-ad6bfe34d998>
– Channel SIP/+982191079726-00000006 joined ‘simple_bridge’ basic-bridge <6ac5be95-38f5-4af1-97da-ad6bfe34d998>
> 0x7f3e0c03e080 – Strict RTP switching to RTP target address 172.16.3.72:32786 as source
> 0x7f3e0005f600 – Strict RTP switching to RTP target address 172.16.3.72:32806 as source
== Using UDPTL CoS mark 5
– Channel SIP/+982191079726-00000006 left ‘simple_bridge’ basic-bridge <6ac5be95-38f5-4af1-97da-ad6bfe34d998>
== Spawn extension (public, +982191079724, 4) exited non-zero on ‘SIP/+982191079726-00000006’
– Channel SIP/+982191079724-00000007 left ‘simple_bridge’ basic-bridge <6ac5be95-38f5-4af1-97da-ad6bfe34d998>

  1. Please mark your logs and configuration as preformatted text, using the forum </> button.

  2. The message sequence chart is of no real use on its own. You need to provide the full text of the transaction, as output by “sip set debug on”.

  3. Why are you using chan_sip, which now only has limited support, rather than chan_pjsip (I’m not a T.38 user, so I may not be aware of limitations in this area, but a quick google suggests that T.38 support exists)?

From the log you see, that UDPTL is used, but then after you have this entry

There is still something in your sip.conf which lets Asterisk doing Fax detection.
When I set up my system with T.38 gateway I noticed, that as soon Asterisks Fax detection barges in, T.38 has been disabled.

Hello dear friend, Thank you
you can see my logs here:

logs.txt (19.6 KB)

Please mark the logs as pre-formatted.

You need to fix the problem with the NOTIFY’s, as they are making id difficult to find the relevant parts of the log.

I see this in my logs:

Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x0 (nothing), combined - 0x0 (nothing)
Got T.38 Re-invite without audio. Keeping RTP active during T.38 session.

In my HPBX I used freeswitch and in trunk I use asterisk for t38 gateway

The reason for the failure seems to be the invalid number response that Asterisk received.

Number A —> freeswitch 1 (HPBX1)
Number B —> freeswitch 2 (HPBX2)
trunk(kamailio as a registrar and asterisk as switch )
I send fax with freeswitch1 (from number A to number B) then send sip message to my trunk(asterisk) when asterisk set to t38 gateway then send a sip message to freeswitch2, then freeswitch2 create an INVITE message and send again to my trunk (asterisk) then asterisk give 488 error.

The 488 is to A, and is because B has returned 404. A has re-invited to T.38 and Asterisk is trying to pass the re-invite to B, but B has refused it with a 404 response, even though the address in the INVITE is that which it provided in its Contact header, and therefore the correct address for re-INVITEs; sip:mod_sofia@172.22.132.235:11000;alias=172.22.132.235~11000~1

Again, please edit your postings to mark the logs, etc., as pre-formatted text, and, preferably, either fix the problem with the NOTIFY, or edit out the NOTIFY transactions.

The 488 has a Reason header citing Q.850 cause 1, which is the no such number reason.

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