Voxalot / SIP Broker Support Forums

Voxalot / SIP Broker Support Forums (https://forum.sipbroker.com/index.php)
-   Voxalot Support (https://forum.sipbroker.com/forumdisplay.php?f=4)
-   -   SIP Register (if unsure set to NO) - what effect? (https://forum.sipbroker.com/showthread.php?t=1180)

occamsrazor 03-07-2007 04:04 PM

SIP Register (if unsure set to NO) - what effect?
 
Hi,

Can someone please explain what effect the following choice makes in the provider setup:

SIP Register (if unsure set to NO)

Thanks,

Ben

affinity 03-07-2007 05:08 PM

If you set SIP Register to "YES", then you can receive incoming calls from that provider once the registration is succesful -- if you are only intending to make outgoing calls, then you need not set it to "YES" although some providers require registration before you can make a call though, most do not).

Now, if your VSP offers SIP URI forwarding, then there is even less likelihood that you will need to actually register the account. The forwarded SIP URI can point to your voxalot account directly.

Hope things are clearer for you now.

occamsrazor 03-07-2007 06:04 PM

So if Sip Register is set to "NO", then you definitely won't be able to receive any incoming calls? This would explain the problem I was having here:

http://forum.voxalot.com/showthread.php?t=1181

Perhaps I am just being dumb, but I think that's a bit confusing... The "if unsure set to NO" makes one think not to set it to yes unless you understand what it does, of which there was nothing in the FAQ I could find e.g. here:

http://voxalot.com/action/static?tas...lay&itemOID=22

Perhaps the "if unsure set to NO" should be changed to ""if unsure set to NO, unless you will be receiving incoming calls" or such like.

Anyway, thank you very much for helping me to fix the problem I was having...

Cheers, Ben

maxalot 03-08-2007 03:17 AM

Quote:

Originally Posted by occamsrazor (Post 6389)
Perhaps the "if unsure set to NO" should be changed to ""if unsure set to NO, unless you will be receiving incoming calls" or such like.

Or perhaps we could just cut to the chase and have "To receive incoming calls set to YES"

affinity 03-08-2007 11:38 AM

"To receive incoming calls directly from this provider, set to YES".

If you can fwd using SIP URI from the VSP, then do that in preference.

occamsrazor 03-08-2007 02:49 PM

"If you can fwd using SIP URI from the VSP, then do that in preference."

Could you explain what exactly you mean & why this is preferential to using "Sip Register = YES"?

Thanks for all the help,

Ben

affinity 03-08-2007 03:10 PM

Well it's like this.

One of the most significant resource hungry requirements of voxalot is the registration of VSP accounts for users; if users are able to lessen the load on voxalot by not registering accounts just because they can, then it has got to help voxalot cope better with resource requirements.

This could be a problem if:
  • your provider requires the account to be registered for you to make calls or
  • your provider does not offer any form of SIP URI forwarding.

Outgoing calls are setup with the credentials of your provider (as supplied by you) at the time of making the authenticated call; this is far more efficient that doing constant registrations and the renewals required to remain registered.

Another potential issue, and this has caused problems with at least one provider, is having too many registrations come from the same IP address. In such cases, the VSP may block voxalot either via flood control mechanisms which makes it's use with voxalot less reliable or they may choose to ban voxalot's IPs completely thus making the VSP fail to work with voxalot at all.

tomblandford 03-08-2007 03:23 PM

Thanks for that interesting explanation affinity. I'm going to remove the registration on one of my accounts that I never use for incoming. I just put it there coz it has an incoming number, even though I never use it!

I tried PBXes before voxalot but it didn't work coz they had already been blocked by Betamax. So I would suggest to anyone with Betamax as a provider, who doesn't have an incoming number in use:

SET SIP REGISTER TO NO FOR ALL BETAMAX PROVIDERS (VoipDiscount, VoipCheap, VoipBuster, SipDiscount etc etc).

otherwise voxalot might get blocked by them too :eek: :mad:

occamsrazor 03-08-2007 04:09 PM

I have my Betamax (Poivy) account already set to "NO", but my SipGate account set to "YES" in order to get calls on an incoming number.

Are you just saying set it to "NO" for all non-incoming accounts?
Or are you also saying there is a way to set it to "NO" for an incoming account by using SIP URI forwarding at the incoming provider end.... in which case can you advise how to do this (sorry I don't understand what SIP URI forwarding actually is) and whether you know if it is possible with SipGate.

Cheers,

Ben

tomblandford 03-08-2007 04:55 PM

I was only saying that for Betamax accounts so that they don't go and block voxalot like they did with pbxes.com. It's only my view - don't take it as gospel!

No, I don't know how to get SIP URI forwarding with Sipgate, but I would hope that Sipgate would be more responsible and not block voxalot. I still have my Sipgate account registered.

affinity 03-08-2007 05:22 PM

Call forwarding via the Internet using a SIP URI .

eg SIP:123456@eu.voxalot.com

If Sipgate have a way of setting up call forwarding to a URI as per the example, then that is what you want to do. Some providers only let you forward to a real number, then they charge you for the call to that number. You don't want to forward to a number, but rather to a SIP URI as above.

I don't know if Sipgate offer SIP URI forwarding, but it appears they don't.... :(

maxalot 03-09-2007 12:08 AM

Quote:

Originally Posted by occamsrazor (Post 6455)
are you also saying there is a way to set it to "NO" for an incoming account by using SIP URI forwarding ...

Yes, If any of your VSP's support forwarding then you just need to enter the details in the place provided by your VSP.

If you look at the call forward form on VoXalot you will see an example of how to setup SIP forwarding.

Open an account with FWD and you will see a different way of setting up call forwarding. This feature on FWD is under "Extra Features"

Quote:

Originally Posted by occamsrazor (Post 6455)
it is possible with SipGate.

I couldn't find anywhere to do this on my Sipgate account.

Essentially, it is better to only set to yes those VSP's that do not have call forwarding and those that require registration in order to make a call. This has the effect of reducing the load on VoXaLot servers.

ie. I have 7 accounts with different providers but I only need to have 2 registered at the moment and that is because sometimes URI forwarding works on one provider and the other does not have URI forwarding.

None of the providers that I use require registration before I can make a call.

affinity 03-09-2007 09:00 AM

Response from Sipgate Support.
 
I signed up for a sipgate account to see what I could find and it wasn't much, so I sent an email to support and this was their response:
Quote:

Originally Posted by Sipgate support
unfortunately, we don't offer sip-uri forwarding.


tomblandford 03-14-2007 02:58 PM

Quote:

Originally Posted by tomblandford (Post 6456)
I was only saying that for Betamax accounts so that they don't go and block voxalot like they did with pbxes.com.

Looks like I spoke too soon. They've done it. :mad:

236267 03-16-2007 02:09 PM

Need for registration with Sipgate
 
Just to contribute my own experience with Sipgate......I have tried with registration set to "no" and using the new call-forwarding to a SIP-uri, specifying "all calls". Now, I only left things this way for about 24hrs. but no calls were received.
Once setting registration "yes" though, within minutes I received a call, so it appears that with this provider we cannot save processor-resources....sorry!

Regards,

Mike.

affinity 03-16-2007 02:24 PM

Do you mean that sipgate has now implemented URI call forwarding?


All times are GMT. The time now is 01:50 PM.

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