IP Office Technical Tip (Region: Global)

079: Redialing Fails to Connect when using Least Cost Routing (LCR)

8th July 2005 - Full PDF Text Version


It has come to our attention that some customers may experience issues with redial when used in conjunction with Least Cost Routing (LCR)

The key symptom of this is that users can dial an external number using LCR and connect, but if the user presses the redial key the external number fails to route and the call is rejected.

For example, a short code could be configured as follows:


Here, the user dials 0 then first digit of N, the IP Office then calls 1666 (a third party LCR service) and receives a connect message (this can happen so quickly that the user is unable to dial all or possibly any subsequent digits). The rest of the short code is processed, and all digits after 1666 are sent as post-connect DTMF

The problem here is that any subsequent redial will only attempt to redial pre-connect digits. On redial the number displayed is only a few digits long and fails to route correctly.

In the above case the digits will be 0 plus any subsequent digits the user may have managed to dial prior to connecting (usually none), plus any digits added by the short code (1666). Consequently, the full digit sequence originally dialled by the user is not submitted to the short code second time around.

The only way to fix this would be to allow post-connect digits to be submitted to redial. However, this poses a general security/privacy risk which opens up the possibility of redial being used to replay sensitive data which should only ever be entered manually (e.g. PIN numbers, account numbers, security codes etc). In addition, there are risks with the possibility of toll fraud.

For these reasons, numbers dialled using LCR cannot be redialed.