Some numbers don't dial using call to dial.whtm

Hello,
I’m hoping I can get some insight as to if there were any changes between V4 and V5 with the dial.whtm url calls.
We use a call similar to the following in our call centre to initiate dials from the pabx

https://pabx/dial.whtm?number={phone number}&user={user}&auth={MD5 hash of user and password}

This will return a status and dial the users extension for a call back to the number specified and has worked fine until recently.
Some numbers now only get a dead line tone but will connect when dialling manually or when hitting redial on the handset.
There doesn’t appear to be any correlation between the numbers that fail, it fails for landlines and mobiles and it doesn’t fail for every number.
Could this be a pabx problem or is this more likely to lie with our phone line provider.

Thanks

Hi Matt,

There is very little difference between a dial originated via an API call, and one originated from the handset, and if any of them are working then your code is presumably correct. The only things I can think of to look at are:

  1. CLI: if your CLI settings on the PBX are not set to 100% sanitise CLI to a correct value for the trunk and you are under some circumstances presenting a CLI that your provider doesn’t recognise then they may reject the call for that reason. This isn’t generally an issue for ISDN and most SIP trunk providers as they will normalise to a CID that is valid for your account on ingress, but some SIP providers will simply reject the call if they don’t like the CID.
  2. Invalid characters in the called number in the API call, if these are being dialed from some sort of directory and you have something subtly injected into the broken numbers (unlikely and I’m sure you have checked this, but just stating for completeness).
  3. Something timing related in the difference between handset and API dialed calls. Could you be triggering more calls at the same time than your trunk capacity can handle, or maybe some code path is executing multiple dials for the same number.

You may want to investigate using the Javascript API, rather than the much older HTTP based interface as it can give you much more control over how the calls are placed (which device/line, autoanswer etc).

The only suggestion there that makes any sense is the CLI settings. I had been checking for invalid characters but couldn’t find any and dismissed this when the redial last number completed the dial, meaning the phone had received the correct number to dial in the first place.
We did have an issue with trunk capacity but we solved this by purchasing more lines. We now have 90 and very rarely go above 20 in and 20 out simultaneously but at least we know we have the capacity to do so.

Thanks for your help, I have gone back to my service provider with this to see if they can help with the cli settings as they seem to me to not have been altered.

CLI is certainly worth looking at, but it doesn’t make too much sense if some destination numbers always work and some never work.

Don’t discount the number character pollution theory too quickly, the dial command may well dial as presented, but the phone ends up with a normalised version through COLP or whatever mechanism it is ending up on the history.

Maybe a better way of doing this if your unit is under a support contract is to get your reseller involved in tracing a ‘good’ manual and bad ‘autodialled’ call and look if a) the provider is rejecting it for good reason or b) if there is some clue in the differences if they both look fine.