Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > Voxalot Forums > Voxalot Support

Voxalot Support Support for the Voxalot service.

 
 
Reply
Thread Tools Display Modes
Unread 03-28-2008, 11:55 AM   #11
emoci
 
Join Date: Jul 2007
Location: Toronto, Canada
Posts: 1,422
Thanks: 123
Thanked 369 Times in 282 Posts
emoci is a name known to allemoci is a name known to allemoci is a name known to allemoci is a name known to all
Default

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.....
emoci is offline   Reply With Quote
Unread 03-28-2008, 02:02 PM   #12
ptruman
Member
 
Join Date: Sep 2006
Posts: 94
Thanks: 1
Thanked 8 Times in 8 Posts
ptruman is on a distinguished road
Default

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.

Last edited by ptruman; 03-28-2008 at 02:42 PM.
ptruman is offline   Reply With Quote
Unread 04-01-2008, 11:02 AM   #13
ptruman
Member
 
Join Date: Sep 2006
Posts: 94
Thanks: 1
Thanked 8 Times in 8 Posts
ptruman is on a distinguished road
Default

Any clues?
ptruman is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:38 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.