- Joined
- Sep 23, 2010
- Messages
- 6
- Reaction score
- 0
Hello All,
I think I may have found a problem in 3cx (tested with v10-sp6) when setting up an IVR prompt to connect to a call queue.
We have three call queues setup using the queue numbers 001, 002 and 003.
We have setup an IVR that prompts the caller to connect to any of these queues.
i.e.;
Press 1 for Queue 1
Press 2 for Queue 2
Press 3 for Queue 3
However upon doing so the caller is told that the call could not be transferred and the IVR prompt repeats.
If we change the queue numbers to 101, 102 and 103 respectively it works fine.
From checking the logs it appears that when the 3cx server receives the queue number it truncates the leading zero's, so transfering the caller to queue '002' becomes transferring to queue '2' etc (which does not exist, hence the failed transfer). By changing the queue numbers to 101,102 and 103 there are no leading zero's to truncate and it works perfectly.
Could someone please confirm, as it maybe something I've done or missed in my setup!
Kind reagrds,
Mark.
I think I may have found a problem in 3cx (tested with v10-sp6) when setting up an IVR prompt to connect to a call queue.
We have three call queues setup using the queue numbers 001, 002 and 003.
We have setup an IVR that prompts the caller to connect to any of these queues.
i.e.;
Press 1 for Queue 1
Press 2 for Queue 2
Press 3 for Queue 3
However upon doing so the caller is told that the call could not be transferred and the IVR prompt repeats.
If we change the queue numbers to 101, 102 and 103 respectively it works fine.
From checking the logs it appears that when the 3cx server receives the queue number it truncates the leading zero's, so transfering the caller to queue '002' becomes transferring to queue '2' etc (which does not exist, hence the failed transfer). By changing the queue numbers to 101,102 and 103 there are no leading zero's to truncate and it works perfectly.
Could someone please confirm, as it maybe something I've done or missed in my setup!
Kind reagrds,
Mark.