Voxalot routing & forwarding from other voip.

[PriToX]

Hi.

As voxalot does not seem to work with video, i can not solely rely on voxalot for my needs.

However, I am having problems forwarding calls from sip2sip.info to my voxalot. I can call from my sip2sip to my voxalot, and it rings. And other way around works to, calling voxalot > sip2sip.

I have sucessfully called my opensips.org and it did forward correctly to my voxalot, 2 or 3 times atleast..

I am currently using the eu cluster, but i have reasons to belive it doesnt work as intended..

I read somewhere, that when using sipbroker, it shouldnt matter if ones used *010 or *031 *0xx (dont remeber the au one).. All i can say, is that it does matter. Using *010 when connected to eu cluster wont work, 031 does.

Can you please verify, that all routing whether internal or external actually do work as intended?

The other day for example, i couldnt connect to eu cluster, but i could connect to us cluster, now, i cant connect to us cluster but i can connect to eu cluster.. I did never change my preffered cluster (eu) on homepage though..

Other than the tiny issues i am having, voxalot works great and i am actually quite surprised of the functionality ones do get from just a basic account. If it wouldnt for the video part, I myself, would not have to use any other provider.

Are you planning on supporting video either directly, or by the use of "external" providers? Either as part of basic or as upgraded account, or maybee a "addon subscription" or something. This, and xcap (server stored adress books).

Okey, Now i am going OT in my own topic :/ *slaps himself*

Let's deal with the routing issues first shall we? xD

Contact me, by either PM or by using my subscribed email. I would prefer email actually, as i check that alot more often..

Cheers from Sweden.

My Device: SE XPERIA X10 mini pro.
3cx phone (avaible from market) Works great, most stable client.
imsdroid (not avaible from market) Works okey.
uwho dialer (avaible from market) Somewhat works. (built on sipdroid)
sipdroid (avaible from market) Does NOT work or works really BAD. Beware!

Theese, are my experiences using SIP on my android phone. As my phone, does not have a camera, i dont really need a client what supports that so for me, 3cx client is indeed the best choice. (err, ofcourse my phone has a camera.. on the _back_ )

[majo]

Hi,
I am also connected to eu.voxalot.com and I tried all *010XXXXXX, *031XXXXXX and *061XXXXXX successfully from another voxalot account. In my view sipbrocker access is working fine.

Very soon i will get andriod smartphone, then may be I can test your other scenario.

regards.

Majo

[PriToX]

Originally Posted by majo

Hi,
I am also connected to eu.voxalot.com and I tried all *010XXXXXX, *031XXXXXX and *061XXXXXX successfully from another voxalot account. Reply: Well, I should be able to recieve calls from <other> -> voxalot, right?. In my view sipbrocker access is working fine.

regards.

Majo

Okey. Well, when i tryed it, a couple of days ago by calling my local sipbroker PSTN gateway, it did not work as intended.

and opensips.org (unconditional forward) > XXXXXX@voxalot.com worked only 2-3 times for me yesterday.. Infact, it worked and i disconnected and connected voxalot.com and it did not work (withouth changing things). I get the feeling, it works or does not work "whenever it feels like doing so" :\ Something is weird

This is why i want it verified, that all routing (internal/external/whatever) really does work as intended. I can only confirm, that i can make calls out to echo, and my other sip accounts. Also, I can call my voxalot from my other sip accounts, however, forwarding does seem to be not fully working, which is weird. Also the sipbroker issues about the {us,eu,au} prefixes is weird.

As i was not able to connect to eu cluster a couple of days ago, but to us and now, i cant connect to us but to eu tells me something is going on somewhere.. The only thing i do know, is that i am using the correct username/password and other things or i wouldnt be able to make/recieve calls _at all_.

If im going to throw off a wild guess, it may be, that eu.voxalot.com doesnt tell voxalot.com that "hey! XXXXXX@voxalot.com is over here"..

Majo, The fact that it is working for you, and not for me makes it even more of a proof, that something "fishy" is going on. Whether or not, it's actually on my side, or on voxalot's side or someone elses side well, that's what im am trying to figure out. (btw, thanks for you reply)

[emoci]

The gist of things (ideally) is as follows:

-Your Device or SoftPhone should be registered with the specific cluster that you have selected in your acct. (you must use xx.voxalot.com rather than just voxalot.com-- where xx is us, eu or au--)

Question: When you say you could not reach a server...do you mean you could not perform a registration to it ... or you could not reach it as in you could not call from SipBroker?

Sidenote: If you are doing a lot of on/off regostration between clusters expect some oddities...changes across all proxies can take sometime to propagate. If you wanna monitor the registration VoXalot is seeing (and which server it sees you registered to) go to http://voxalot.com/action/deviceRegistrations ... after you've logged in to your VoXalot acct.


-Incoming SIP URI calls to your acct. should preferrably be sent to: user@xx.voxalot.com (this form of forwarding should work most of the time... xx must match the cluster you've set in your acct. and to which your device/softphone is registered).

One issue that may arise here is due to a combination of the "Failover" strategy (http://forum.voxalot.com/voxalot-tip...lemention.html) and the fact that the US and EU clusters each involve two different proxies (http://scopezoom.com/vox.php). If one of the proxies is having issues, and the calling-party provider is not performing a DNS SRV lookup reliably issues may arise with calls reaching you.


-Calls to user@voxalot.com should also work (one catch is that if the calling-party service does not do an DNS SRV lookup reliably you may come accross issues here ... even if it is not a failover situation).


-As far as SipBroker goes... *010 should work reliably (and has more or less been tested) to reach most of the user accounts, regardless of their cluster. Theoretically the other two *xxx codes for eu and au should also be interchangeable...however there hasn't been too much testing from the user community in that front.


Issues with incoming calls can also be possible NAT issues... here's a few quick crash-test things to try:

-Try calling a SIPBroker number (SIPBroker - PSTN Numbers), then *010123456 , 123456 replaced with your VoXalot number. Do you receive this call, and is this also suffering from audio problems?

-Try entering your voxalot URI 123456@voxalot.com in the link below. Instead of you calling Echo, echo will call you so you can see how it behaves when it is an incoming call: SIPBroker - EziDial

-If your router has UPnP I would suggest activating that rather than DMZ

-Preferably make sure you have STUN set up (stun.voxalot.com:3478)

-This is optional, but it may help to open these port ranges and forward them to your ATA's IP:

5050-5064
5000-5005
16300-16500 (for PAP2/SPA3102...this maybe slightly different for your ATA, there should be an RTP port range setting on your ATA, if it is different, note the range and open that range instead in your router...)
For some background on this see: http://forum.voxalot.com/12685-post20.html

-Make sure there are no Internet Connection problems. Run a SpeedTest, or maybe VoIP test at TestYourVoIP.com

-If Nat Symmetric Hanlding is set to NO and Optimize audio to YES (these are both settings in your VoXalot account), try setting Nat Symmetric Handling to YES and Optimize audio to NO

-Make sure that the codec string used for providers (personally I've had good results with this string) is: ulaw;alaw;g726;g729;ilbc;gsm

-Another good resource for info: Main Page - Voxalot FAQ

[PriToX]

Question: When you say you could not reach a server...do you mean you could not perform a registration to it ... or you could not reach it as in you could not call from SipBroker?

I meant i could not register with it. I could apparently reach it, as my client tryed to register, but got status: "failed to register".

-Incoming SIP URI calls to your acct. should preferrably be sent to: user@xx.voxalot.com (this form of forwarding should work most of the time... xx must match the cluster you've set in your acct. and to which your device/softphone is registered).

This, well, while it does make sense, it doesnt make sense As it currently is, i am not sure as it seems, whether or not i will be connecting to us or eu cluster.. As i mentioned, my cluster settings have always been set to eu, and i always connected to eu.voxalot.com.. Altough, i belive it was 2-3 days ago, i got this "failed to register" error trying to connect to eu cluster, so i simply changed my clients settings to us instead, and all was well.

What happens if i am connected to us cluster, and my settings at voxalot account is eu, and i forward calls to eu cluster, will they still reach me? Or, should i rather forward to voxalot.com and let the "routing mechanism" do the work?

-Calls to user@voxalot.com should also work (one catch is that if the calling-party service does not do an DNS SRV lookup reliably you may come accross issues here ... even if it is not a failover situation).

This, has worked for me. Infact, that is how i always have called myself, and is also how i enter my number in forwarding settings.

-As far as SipBroker goes... *010 should work reliably (and has more or less been tested) to reach most of the user accounts, regardless of their cluster. Theoretically the other two *xxx codes for eu and au should also be interchangeable...however there hasn't been too much testing from the user community in that front.

This, did not work so well for me.. *031 (eu) did work for me, when *010 did not.

Issues with incoming calls can also be possible NAT issues... here's a few quick crash-test things to try:

*here be suggestions*

I will try to forward some ports through my NAT and see what happens.. upnp is at the moment a nogo for me, i did try to enable it last night and quite frankly, it "broke" my router.. *ehum* I have since, reflashed it and i will not attempt to enable upnp again untill i have heard from dovado.com support..

-If Nat Symmetric Hanlding is set to NO and Optimize audio to YES (these are both settings in your VoXalot account), try setting Nat Symmetric Handling to YES and Optimize audio to NO

My settings are set as suggested, never had any reason to change them..

I will try to use the codec string what you provided and see if well, something happens By ATA, I reckon you mean one of thoose uhm telephone -> SIP devices..
(Err, This i can not seem to do.. I can only change codec settings for my external providers for outgoing calls.. Not for voxalot itself (for incomming) or did i not see where to do that?)

I do not own a telephone, nor any ATA devices

If anything, i do know that _i_ might have some DNS SRV lookup issus from my side, but that shouldnt affect forwarding calls from <voip provider> right?

I will do some further testing, try some of the things you mentioned and i will get back with the results.

Thanks all for lending a hand. Appreciated.

[PriToX]

I have now done some testing here, and it does seem that the main "issue" is about whether i forward to eu.voxalot.com or just voxalot.com.

EziDial calls my up just fine and it works as expected and it doesnt matter if i use the cellphone client or client in the computer.

opensips.org redirects just fine if i make it redirect to XXXXXX@eu.voxalot.com. And, well, now i didnt try with the sip2sip.info one but i figure it will work aswell, will try that later..

2 things to notice, it didnt matter whether or not i had a stunserver put in in my cellphone client, all went with no issues without aswell as with it. However, enabling NAT in the advanced settings for the 3CXPhone client _will_ make it not work. ie no sound.

Might be worth noting, specially if ones uses 3CXPhone.. I am not sure of, what that settings does, all i do know, is that it makes it not work. Please observe, that this does NOT go for the 3CXPhone software for windows, as it does not have the same settings.

The 3CXPhone for Windows, works pretty much straight as it is. I will see if i can write up a small guide on how-to configure atleast theese 2 clients for use with voxalot

I didnt change any NAT settings for this "trial and error run", apparently, it worked anyway

To sum it up, what seems too have been or is, the issue, is whether ones forward calls to xxxxxx@voxalot.com or xxxxxx@{us,eu,au}.voxalot.com.

However, i did have no problems initiating a call myself, using my client to dial xxxxxx@voxalot.com..

Now, all is well and it seems to work, and I am one very happy user now \o/

Thanks alot SIP Gurus

(altough, i still dont get the "issue" with us,eu,au or not when calling to voxalot.. Who does the SRV lookups when dialing "manually"? dialer or operator? In the later case, there is no reason why a forward directly should not work.. In the first case, im surprised it works at all (for me) as i do have SRV lookup issues..)

[emoci]

As far as I understand....

With @voxalot.com ...the associated A adress (IP) is actually the webserver. Which means if te calling end does not do an SRV lookup ... the call is unlikely to get anywhere ... it is by default hitting a web server ...

With @xx.voxalot.com... the associated A adress (IP) corresponds to one of the actual proxies (I believe it is proxy 1 in each of the us and eu). That means even if the calling party does not do well with SRV lookups...the call will end up in a server that is voice-aware. (there could still issues if for some reason one of the proxies is not working and SRV lookup is not being done...because the failover mechanism would not be able to compensate automatically).

From my experience: Most SipPhones, ATAs, SoftPhones when being used to make direct SIP Calls do pretty well with DNS SRV. Doing DNS SRV lookups when it comes to registration to a specific server seems to be a beast of its own though (so those same software/devices can do well on the first but fail miserably on the second).

When you're actually forwarding a call from OpenSips or Sip2Sip ... then the SRV lookup rests with the provider itself rather than the SoftPhone.

One alternative to overcome SRV issues (especially when forwarding from a third party provider) is to try forwarding to *010123456@sipbroker.com (where 123456 is your VoXalot number). The SipBroker.com server is actually both web and voice on the same server... and SipBroker itself is pretty good at doing SRV lookups for failover situations from there...
(I personally tend to avoid this unless it is an extreme case, I feel like it adds some unneccessary extra latency--but I must admit this assumption of extra latency is based on no real proof on my end except for a gut feeling--)

If you do put a setup guide together...let me know...I'd be happy to add it to the Wiki...

[PriToX]

Well, as it currently is, i most likely will not need to use a third party provider, as voxalot offers everything i need. And as far as i am concerned, it does sound like voxalot is indeed providing all needed information for calls to be "routeable".

Basically, it all nails down to as i understand it, if the forwarding provider "looks for the information" or not. And it they dont, it's hardly a fault of voxalot.

I have mailed sip2sip about the 'issue' with their forwarding, and now, when i know bit more about what actually might be the problem, it should be easy enough to get fixed.. If not, there are other providers around than sip2sip

To be frank about it, i couldnt care less if they do choose to 'fix' or not, as i can manage just fine without the video part, i mean, who by their right mind would want to look at me anyways XD It's bad enough have to listen to me hehe