I have an inbound route with an IVR destination. When the call is answered, however, the announcment of the IVR is not played. Moreover the digits associated with the IVR are not recognised if I press any of them. I can’t even play the announcment with a simple Play Annnouncment: no sound is received on the calling phone. If I set the inbound route to an extension audio works in both directions.
These are the logs when a call is received (when the IVR is set as inbound route dest):
You’ve only turned on chan_sip logging, but your actual call appears to be on chan_pjsip (“pjsip set logger on”).
The call seems to have terminated when being answered.
I assume the call with the invalid request URI is from an attacker.
here the log with pjsip logging activated.
Ideed there are attacks, for which I have to configure fail2ban.
But the log says the “SceltaLingua” announment and the wrong choice one are played while actually they are not.
The call is the one from +39123456789
You never get an ACK to the 200 OK. You’d need to find out if that is because the 200 OK never reached the caller, or because their ACK never reached you.
I can’t see any indications of NAT at play, which would normally be the usual suspect.
You might want to try setting a contact user for the endpoint, just in case the other side fails to allow for all well formed contact header possibilities.
Things to try in Inbound Route/ trunk:
Pause before answer: 2
Signal Ringing
Progress Inband
If NAT firewall, forward UDP ports 10000-20000 to PBX.
If you still have trouble, turn on sip debug retest and paste another log.
unfortunately none of these worked. Server is under a public IP with no NAT
Here’s another log with sip debug enabled: 1446802 [2023-01-02 15:36:56] VERBOSE[10041] chan_sip.c: 1446803 <--- SIP read - Pastebin.com
You are not getting ACKs and there is some indication that Trying isn’t being received by the other end.
You are complicating the logs by having both channel drivers enabled and not weeding out attacking requests. Are the genuine requests on the port used by chan_sip, or that used by chan_pjsip?
(I think you got asked to enable logging for chan_sip, last time, but the log you submitted had chan_sip handling the first logged request. I asked for chan_pjsip logging, for a similar reason, because of an earlier log.
Also, whilst this log did include the first INVITE, the previous two didn’t include the earliest INVITEs.)
OK, so when I call via the PSTN, I get two rings and then answer, but silence.
When I call via Messagenet (dialing the 5406 number), it answers normally, the IVR audio is heard, and DTMF is recognized. However, after pressing 1 “to speak in Italian” (I don’t actually speak Italian), it rang a few times and then went to an English announcement that no one was available to take my call.
Just a guess that the codecs you are presenting is confusing their server. Try enabling only alaw:
disallow=all
allow=alaw
and retest. If no luck, you could capture network traffic to see what audio is being sent and received.
Wow, something very strange is going on. There are two incoming INVITEs; I thought the second one was just a retransmission, but the URIs are different. The first goes to the +39 number and the second to the 5406 number. Do you possibly have two registrations in force? It appears that both calls are being sent to the IVR but with the same Call-ID Asterisk could be quite confused.
I tested calling my Messagenet DID (it’s a pjsip trunk so that may somehow make a difference) and I get only one INVITE with the +39 number in the URI. Do you have forwarding or another setting at Messagenet that could be causing the two calls?
I’d assumed that the Trying had been lost, but, yes, the call is being branched by 109.233.129.13 to the two addresses, with different branch IDs. It should be the responsibility of the branching proxy to resolve multiple acceptances. Asterisk should treat them as separate calls.
I was wrong in saying there were no ACKs in the last log, although what is happening is complex. The +3903 leg is getting a cancel before the ACK and a BYE after the ACK. That is presumably because 109.233.129.13 accepted the OK from the 5406 branch, which simply got an ACK, so is killing off the +3903 branch, but suffering colliding OK in the process.
Why is anonymous calling enable? Having that turned off would cut out most the garbage in these debugs.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.