IVR and CallPark

Arturo J Garcia Jmz

unread,

Dec 12, 2022, 5:15:35 PM12/12/22

to sipxcom-users

I have a set up like the one in the PDF, but seems the call park does not return the call to the originator.

Also have some trouble with the schedules, I set some schedules on the phantom extension, but is not acting as I assume should be.

Any suggestion, I already read the wiki for the call park and the dialing rules but can find any key point I had missing or if there is any relation on the schedules and the dialing plans for the IVR´s.

IVR_Schedules.pdf

Matt Keys

unread,

Dec 14, 2022, 8:39:50 AM12/14/22

to sipxcom-users

Call park timeout is in the advanced settings of the park, see attached. The default on the timeout is unchecked, so maybe you're missing that?

As for the schedules issue it's hard to troubleshoot call flows without reviewing the log data of the call example. If the proxy log is at INFO or DEBUG, you can see the signaling like ..

cd /var/log/sipxpbx/

grep "call id goes here" sipXproxy.log | syslogviewer --no-pager > ~/call_id_goes_here.log

Replace the "call id goes here" with the actual Call-ID: header value. If there's an @ in it, just enter in the first (left) part before the @.

The above will filter the sipXproxy.log for the Call-ID: header value, which remains unique through the entire dialog. The syslogviewer utility escapes all the line breaks and makes it easier to read. The > redirects the output to a text file in root's home.

Regards,

Matt

park_timeout.PNG

Arturo J Garcia Jmz

unread,

Dec 21, 2022, 10:08:25 PM12/21/22

to sipxcom-users

Thanks, Matt, yes I checked that, it already mark it, but the call is sent back to the audiocodes instead the phantom extension where the audiocodes send the call.

Thanks for the image

Matt Keys

unread,

Dec 24, 2022, 12:36:43 PM12/24/22

to sipxcom-users

It's hard to troubleshoot or assist without log data of the call example.

I'm guessing you're routing the inbound call directly to the park rather than a real user/extension answering the call, then (blind) transferring to park? If yes that will never work properly as there is not a real user in the call flow to transfer it back to.

If the goal is to keep a inbound call active and on hold while waiting for someone to answer the call, consider the use of call queue / agents.