If the SIP trace shows a pjsip problem, we could consider chan_sip, but IMO that’s very unlikely.
REGISTER 11 headers, 0 lines
Reliably Transmitting (no NAT) to 10.200.42.121:5060:
REGISTER sip:fmc.stc.com.sa SIP/2.0
Via: SIP/2.0/UDP 20.46.137.72:5060;branch=z9hG4bK7e4f438f
Max-Forwards: 70
From: sip:[email protected];tag=as0545dd16
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 104 REGISTER
Supported: replaces, timer
User-Agent: DSL-G2452GE
Expires: 120
Contact: sip:[email protected]:5060
Content-Length: 0
[2023-02-22 19:11:50] ERROR[24722]: chan_sip.c:4294 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data
what could be the issue?peer details on my tunk config?
Whether or not the SIP driver send 180 RINGING depends on the Asterisk core and not on the channel driver. It is perfectly legal for a SIP implementation to respond 200 OK to INVITE with no provisional status replies. It is not particularly uncommon for a SIP implementation to send 183 Progress, rather than 180 RINGING.
The ISDN interworking RFC indicates that, even in an ISDN gateway situation, it is perfectly legal to go direct from INVITE to 200 OK.
If you use chan_sip, you are using software that will not have bugs fixed, and for which expertise on how it works will be dying out. You might want to note that most of the provider provided chan_sip configurations are of poor quality.
ok thanks…i will try your suggestions
This is generally a very low level network socket error (see the man page for the sendto system call). The most likely one here would be there is no route to 10.200.42.121. For UDP, I wouldn’t expect any information not already in the trace to be relevant to the cause. Unfortunately, the code doesn’t log the underlying system call error number, and getting that information might involve a level of debugging that only a Linux expert would attempt.
Please explain why, given that you had a repeatable one-way audio issue, probably easy to diagnose and fix, you suddenly decided to change to another SIP driver?
When you tried Signal Ringing and Pause Before Answer, did you hear ringback tone but not the Announcement? Or, was it completely silent? Any errors in the Asterisk log? If you still have the log with SIP trace, please paste it.
Another thought: Use a Misc Application to assign an internal number to your IVR. Try calling that from a local extension. If you still don’t hear the Announcement, that eliminates anything related to trunk or firewall as the source of the problem.
tried that and everything works internally,but when I call my voip line through my cell ,i hear nothing but when i set my inbound route to my sip extension, ringback tone was present…
i will update my freepbx with astetrisk…
hi got a free time today to upgrade my freepbx/asterisk…but same issue , i can hear ringback tone when my inbound route for my line is set to my sip extension, but when set to ivr , I cant hear the recording…internally no issue when playing my announcement/recording…
<PJSIP/5555-00000034> Playing ‘en/custom/f088bf11-9133-45f2-94a4-28202444f6d0-8khz.slin’ (language ‘en’)
also my provider only accept alaw/ulaw/g729 codecs
Playing ‘custom/f088bf11-9133-45f2-94a4-28202444f6d0-8khz.ulaw’ (language ‘en’)
converted my recoding to ulaw,click signal ringing and force answer with the same silent issue
stc_sip-00000043 00:00:09 ulaw 468 0 0 0.000 468 0 0 0.001 0.000
With the Inbound Route set with Signal Ringing on, Force Answer off, and Pause Before Answer set to 10, do you hear ringback tone? Is there a 10 second delay before the call shows as answered on your mobile? Do you hear the announcement?
yup i hear a ringback tone but i didn’t hear the announcement.
– Executing [s@ext-did:16] NoOp(“PJSIP/stc_sip-0000004a”, “”) in new stack
– Executing [s@ext-did:17] Wait(“PJSIP/stc_sip-0000004a”, “10”) in new stack
– Executing [s@ext-did:18] Set(“PJSIP/stc_sip-0000004a”, “__CALLINGNAMEPRES_SV=allowed_not_screened”) in new stack
– Executing [s@ext-did:19] Set(“PJSIP/stc_sip-0000004a”, “__CALLINGNUMPRES_SV=allowed_not_screened”) in new stack
– Executing [s@ext-did:20] Set(“PJSIP/stc_sip-0000004a”, “CALLERID(name-pres)=allowed_not_screened”) in new stack
– Executing [s@ext-did:21] Set(“PJSIP/stc_sip-0000004a”, “CALLERID(num-pres)=allowed_not_screened”) in new stack
– Executing [s@ext-did:22] NoOp(“PJSIP/stc_sip-0000004a”, “CallerID Entry Point”) in new stack
– Executing [s@ext-did:23] Goto(“PJSIP/stc_sip-0000004a”, “app-announcement-1,s,1”) in new stack
– Goto (app-announcement-1,s,1)
– Executing [s@app-announcement-1:1] GotoIf(“PJSIP/stc_sip-0000004a”, “0?begin”) in new stack
– Executing [s@app-announcement-1:2] Answer(“PJSIP/stc_sip-0000004a”, “”) in new stack
0x7feb680f4980 – Strict RTP learning after remote address set to: 10.154.15.57:40546
0x7feb680f4980 – Strict RTP switching to RTP target address 10.154.15.57:40546 as source
– Executing [s@app-announcement-1:3] Wait(“PJSIP/stc_sip-0000004a”, “1”) in new stack
[2023-02-25 16:04:08] NOTICE[24409]: res_pjsip_geolocation.c:195 handle_incoming_request: PJSIP/stc_sip-0000004a: Endpoint has no geoloc_incoming_call_profile. Done.
– Executing [s@app-announcement-1:4] NoOp(“PJSIP/stc_sip-0000004a”, “Playing announcement ivr”) in new stack
– Executing [s@app-announcement-1:5] Playback(“PJSIP/stc_sip-0000004a”, “custom/f088bf11-9133-45f2-94a4-28202444f6d0-8khz,noanswer”) in new stack
– <PJSIP/stc_sip-0000004a> Playing ‘custom/f088bf11-9133-45f2-94a4-28202444f6d0-8khz.ulaw’ (language ‘en’)
0x7feb680f4980 – Strict RTP learning complete - Locking on source address 10.154.15.57:40546
I’m fairly sure that pfSense is not working as you expect, even though you have port forwarding in place and disabled source port rewriting. So, time to look at what is actually going wrong. Capture traffic on the WAN interface of the firewall (the connection to the ONT) for a failing call.
Move the capture file to your computer and open it in Wireshark. Look at the RTP being sent to the trunk when the announcement should be playing. Things to check for:
- The destination address and port should match what was sent in the SDP of the incoming invite.
- The source address should match your public IP and the source port should match the port in the SDP of the 200 OK that Asterisk sent.
- The codec and packetization should match the SDP of the 200 OK that Asterisk sent.
- If you play the RTP stream, you can actually hear the announcement.
BTW, is you still have trouble, paste the Asterisk log (not the console output) for the entire inbound call attempt, with pjsip logger on, at pastebin.freepbx.org and post the link here. Also report what you found with the packet capture.
thanks but my ont was in bridge mode going to pfsense and then bridge interface again going to my freepbx…i set packet filtering off to my pfsense bridge interface facing freepbx port and rules are allowed all to isolate firewall issues, no one way audio both inbound/outbound calls…all calls are normal except this ivr/announcement audio…anyway I’ll try you suggestions…
Thank you so much david and stewart for helping me , got my problem solved by adjusting my provider network mask from /24 to /16 oo my pfsense routing table
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.