PJSIP and T38 fax Issue - T38 wont start

Hello. Im running Asterisk 20.3.0. The system and dial plans run fine on chan_sip but we are migrating to pjsip. I am running chan_sip on port 5060 udp and pjsip on port 5061 udp. The asterisk system in question is a core phone switch connecting over 20 other Freepbx systems via simple sip trunks. Both chan sip and pjsip are operating fine in unison and I have two phone system trunks converted to PJsip. All voice calls work fine on pjsip. I just found out that T38/fax is not working at all but ONLY on pjsip. All the chan_sip trunks work completely fine and I see T38 on all those trunks with a udpctl debug and sip debug etc. Only the pjsip trunks are broken for fax/t38.

  • When a fax call comes in from the PSTN and hits the asterisk box in question the call is made outbound towards the Freepbx system (Freepbx is running Asterisk 16.30.0 w/chan_sip).
  • Freepbx starts sip setup, detects fax via spandsp and faxdetect and issues a re-invite for T38 and fax. Freepbx sends three re-invites in a row (I dont know why it feels like it has to send 3 re-invites/why asterisk 20.3.0 isnt responding to the first re-invite).
  • after three re-invites asterisk 20.3.0 system sends back a 200 OK for T38 on UDP port 4942 and Freepbx sends back an ACK
  • Freepbx system sends a handful of UDPT38 packets towards Asterisk 20 system then dies with a generic fax error
  • The next SIP message is a re-invite to go back to PCMU audio from Freepbx, asterisk 20 says OK, Freepbx Acks that ok. Then Freepbx says BYE/ends the call normally with code 16.

So for some reason there are three re-invites but finally asterisk 20 negotiates T38 on udp port 4942 from what I can see, Freepbx sends UDP to asterisk 20 but on asterisk 20 via udptl debug on I dont see any udp packets. Then freepbx detects the problem, falls back to PCMU and tears down the call.

If I switch back to chan_sip all works fine. There are no firewall issues between systems as its an any any rule both directions while I work through this issue.

I’ll paste the trunk config below, then the udptl.conf file (that works in chan_sip) and finally the call flow from the asterisk 20 side.

I really appreciate any feedback/assistance as Im at a loss especially with things looking ok config wise and it functioning perfectly with chan_sip if converted back. Im missing something clearly.

udptlfecentries = 3
udptlfecspan = 3
udptlchecksums = yes

type = transport
protocol = udp
bind =

type = aor
contact = sip:
qualify_frequency = 30

type = identify
endpoint = ccisdremc1pbx
match =

type = endpoint
context = Remc1CCISD
accountcode = 1
dtmf_mode = rfc4733
disallow = all
allow = ulaw
direct_media = no
aors = ccisdremc1pbx
fax_detect = yes
t38_udptl = yes
t38_udptl_ec = redundancy
t38_udptl_maxdatagram = 400

OK here is a pjsip show endpoint ccisd

Endpoint: ccisdremc1pbx In use 1 of inf
Aor: ccisdremc1pbx 0
Contact: ccisdremc1pbx/sip: acd646c7f5 Avail 0.542
Identify: ccisdremc1pbx/ccisdremc1pbx
Channel: PJSIP/ccisdremc1pbx-0000004a/Dial Up 00:04:29
Exten: 15174820188 CLCID: “” <>

ParameterName : ParameterValue

100rel : yes
accept_multiple_sdp_answers : false
accountcode : 1
acl :
aggregate_mwi : true
allow : (ulaw)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
allow_unauthenticated_options : false
aors : ccisdremc1pbx
asymmetric_rtp_codec : false
auth :
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid :
callerid_privacy : allowed_not_screened
callerid_tag :
codec_prefs_incoming_answer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_incoming_offer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_answer : prefer:pending, operation:intersect, keep:all, transcode:allow
codec_prefs_outgoing_offer : prefer:pending, operation:union, keep:all, transcode:allow
connected_line_method : invite
contact_acl :
context : Remc1CCISD
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : false
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_auto_generate_cert : No
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : true
fax_detect_timeout : 0
follow_early_media_fork : true
force_avp : false
force_rport : true
from_domain :
from_user :
g726_non_standard : false
geoloc_incoming_call_profile :
geoloc_outgoing_call_profile :
ice_support : false
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
incoming_call_offer_pref : local
incoming_mwi_mailbox :
language :
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : false
message_context :
moh_passthrough : false
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : no
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : false
one_touch_recording : false
outbound_auth :
outbound_proxy :
outgoing_call_offer_pref : remote_merge
overlap_context :
pickup_group :
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : false
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : false
rtp_timeout : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
security_mechanisms :
security_negotiation : no
send_aoc : false
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : false
send_rpid : false
srtp_tag_32 : false
stir_shaken : off
stir_shaken_profile :
sub_min_expiry : 0
subscribe_context :
suppress_q850_reason_headers : false
t38_bind_udptl_to_media_address : false
t38_udptl : true
t38_udptl_ec : redundancy
t38_udptl_ipv6 : false
t38_udptl_maxdatagram : 400
t38_udptl_nat : false
timers : yes
timers_min_se : 90
timers_sess_expires : 1800
tone_zone :
tos_audio : 0
tos_video : 0
transport :
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no

(ok I had the sip flow in a pcap file but now I see its not possible to upload a file so I did a new sip debug as a normal text flow and am pasting below)

OK hmm well now the forum is giving me an error that new users can only put two links in a post even though I havent put any links in the post… so my guess is the forum is mis-interpreting the debug paste as URL links in certain locations… Oof… I’ll try a second post for as much debug as it will allow.

I tried uploading an attachment but new users are not allowed. I now have text markup icons so I’ll try pasting the debug again.

Nope wont let me “only two links allowed per post for new users”

Here is a link to a google doc with the debug

Well I feel like a fool. It was a firewall rule. The rule was titled properly with proper alias names but hiding the incorrect IP address behind the name.

Anyways the fact that chan_sip functioned really threw me off the sent too. I suppose it functioned because the sip _helpers/sip_alg were/was enabled on the firewall and that possibly handled punching pin-holes in the firewall. For some reason it didnt allow chan_pjsip to function (difference in the sip handshake maybe idk not worth investigating) but fixing the firewall rule fixed everything. Sorry to bother.

1 Like

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