• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

IVR/wav Issues

Status
Not open for further replies.

edokim

Joined
Nov 29, 2017
Messages
49
Reaction score
1
After uploading new wav files for use in the IVRs, the rules are no longer working properly. The DIDs are being routed to what seem like random IVRs.

We did get a format error when initially trying to upload higher-quality wavs. We went back and resampled the wavs per specifications, and re-uploaded the files successfully. Then we configured the IVRs to use the new files, and they worked perfectly.

Now a day later, we get some of the old wavs playing (apparently randomly), instead of the new wavs. We checked the configuration and indeed we are pointing to the correct files, but no joy.

Also, how to delete the old wav files (to reduce clutter)? We have Google Cloud installation.
 
To delete .wav files, currently you must log onto the actual machine and delete them from the filesystem.
Also, I am not sure how you uploaded the new files, was it from the Management Console or just replaced the files on disk? If it was the latter, you may need to restart the services to get the new .wav files loaded, but I'd do this anyway.

Regarding the routing, now I am going to go out on a limb and say that the new .wav files are not the reason, maybe though as some prompts did not change, you just now noticed it.
You may want to check the routing logic using the Activity Log form the Dashboard. Are incoming calls going to the correct destinations? Ignore the .wav files that are being played as they may confuse you, use the Extension Numbers of the Extensions, Ring Groups, Digital Receptionists, etc instead and make sure that calls are being routed to the right internal numbers.
 
@NickD_3CX, I uploaded the files via the Management Console.

I have noticed the following behavior.

1. If the incoming calls route to the correct IVR/wav, then the calls will route to the correct extensions and everything works perfectly. This is an example of the log at connection:

Code:
12/11/2017 3:25:38 PM - [CM500002]: Call(C:107): Info on incoming INVITE from Line:10000<<15623662941:
Invite-IN Recv Req INVITE from 204.11.192.135:5080 tid=-583681324098d0714ad2b3bc4789eabd [email protected]:
INVITE sip:[email protected]:5060;rinstance=1ca5f05929521f36 SIP/2.0
Via: SIP/2.0/UDP 204.11.192.135:5080;branch=z9hG4bK-583681324098d0714ad2b3bc4789eabd
Max-Forwards: 13
Contact: <sip:[email protected]:5080;transport=udp>
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=3721994737-727010
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 271

v=0
o=NexTone-MSW 833290 969082 IN IP4 204.11.192.135
s=sip call
c=IN IP4 204.11.192.135
t=0 0
m=audio 59024 RTP/AVP 0 101
a=ptime:20
a=sendrecv
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=rtpmap:0 PCMU/8000
a=silenceSupp:eek:ff - - - -
a=setup:actpass

2. If the incoming calls route to the 'wrong' IVR/wavs, then the calls will not route correctly to the extensions dialed. This is an example of that connection log:

Code:
12/11/2017 3:26:34 PM - [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
Invite-UNK Recv Req INVITE from 185.107.94.121:14057 tid=pdi9vg6yqjx2rymp Call-ID=omzhjoZntKy6xQkNslykal..:
INVITE sip:[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 15.118.78.7:5060;branch=z9hG4bK-524287-1---pdi9vg6yqjx2rymp;received=185.107.94.121
Max-Forwards: 70
Contact: <sip:%E2%80%98hi%27or%E2%80%98x%E2%80%99=%27x%27;@15.118.78.7:5060;transport=UDP>
To: <sip:[email protected];transport=UDP>
From: <sip:‘hi'or‘x’='x';@35.227.169.79;transport=UDP>;tag=8l33x6l7
Call-ID: omzhjoZntKy6xQkNslykal..
CSeq: 1 INVITE
Content-Type: application/sdp
User-Agent: Z 3.14.38765 rv2.8.3
Allow-Events: presence, kpml, talk
Content-Length: 284

v=0
o=Z 0 0 IN IP4 15.118.78.7
s=Z
c=IN IP4 15.118.78.7
t=0 0
m=audio 8000 RTP/AVP 18 3 110 8 0 97 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:110 speex/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Whether the calls route to the correct IVR/wav seems completely random. In the first scenario, the To and From fields are perfect. On the second, those same fields are populated by garbage(?). The PBX is installed on GCP, and all calls are coming in through a single Callcentric trunk.
 
try restarting the 3cx services
 
I re-started the services as suggested. The problem seemed solved for a little while, then reappeared. It seems completely random as to when the calls will go through correctly and when not. The only thing that is consistent is that when routed 'correctly,' the logs show a recognizable address and everything works. And when they are routed 'incorrectly', the logs show a To: address that seems like garbage and the extensions also cannot be reached.

Any other thoughts?
 
...and you pointed out the problem precisely right, in the second INVITE the From/To fields are indeed garbage, and that is why you are getting the line "Unidentified incoming call. Review INVITE and adjust source identification". This means in free translation "I don't understand what number you are calling and I don't know what I'm supposed to do....".

So, find the device/service provider with User-Agent "Z 3.14.38765 rv2.8.3" and ask them this precise question, why are they sending an invalid number in the "to" and/or "RURI" fields?

Assuming this is an incoming call from a the SIP Trunk service provider, these 2 fields are used and matched against the DIDs on your system and it is expected to find a match.
 
Status
Not open for further replies.
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.