Call connection, voicemail and amusing routing :)

[emoci]

You only have one incoming provider right?

So adjust your rules a bit, adding one more in this order:

1. CID based rule
2. Rule based on your incoming provider to ensure all calls ring VoXalot
3. Any rule to ensure all calls ring VoXalot

I guess anything is possible, but if there was a loop scenario happening it would affect calls coming over VoXalot too.....

[ptruman]

There are four ways I can be contacted :

1) Direct IP dialling (i.e. direct to ATA)
2) PSTN (i.e. direct to ATA)

The above two rules will use the ATA forward rule (and thats the only way I'm going to get them to forward anywhere. The above rules forward calls to my Voxalot Premium number, but are forwarded using the Voxbasic number

3) VSP (which goes to my Voxalot SIP URI -> ATA)
4) Voxalot SIP URI -> ATA

In *theory*, if my Voxalot VM delay is SHORTER than the ATA delay, then anything coming in on (3) or (4) should go to Voxalot VM. If it gets as far as going back to my ATA delay time then it would loop (as they are trying to come in on, and then potentially back to, the same number)

Logs would be VERY useful in diagnosing this sort of thing (esp. when combined with SNMP traps from users own hardware) - and probably cut down on some of the requests here

I'm considering playing with the VoxConnect API to see if I can get it to show me the logs.

[EDIT]

It is a timing issue.

Voxalot VM cutover was 20 secs, my ATA fwd was 25 secs - obviously something in the call handling/switching isn't quite up to speed, as if I reduce Voxalot VM to 5 secs, calls to my VSP suddenly go to VM.

If I set the Voxalot VM delay to 20 seconds and my ATA to 30, I still get an issue though....but it's random.

My test case is PSTN -> VSP PSTN -> Voxalot -> ATA
From the last digit dialled on the 1st leg, the call can take anything from 1 to 7 or so seconds to start audibly ringing.

If the ATA has received a signal and started counting before Voxalot, I can see an issue there - does Voxalot start counting from when it receives a SIP request, or when it receives an ACK from the end ATA?

Latency between my VSP and Voxalot seems to be the main sticking point.

[EDIT x 2]
If I ring my VSP DDI PSTN number, there is the above delay before ringing.
I also get this if I ring the local SipBroker PSTN access gateway and dial *031XXXXXX# for my VoxPremium URI.

Is there an issue with the eu gateway? (I've not tried the other ones yet)

Given my Voxalot VM delay is now 19 secs, and my ATA31, theres some big chunky gaps in there. I wondered if it maybe codec related, but I'm not getting silence, it's actually canning the call.

[ptruman]

Any clues?