VOIP etc > Voice Over IP - VOIP > VOIP Tech Chat > Future Nine and IPKall

Future Nine and IPKall

Please give it a try with incoming.future-nine.com (both on your ATA/softphone and IpKall) - that should work better.
--
Nitzan Kon, CEO
Future Nine Corporation

I just checked, my IPKALL account is still pointing to sip.future-nine.com and seems to work fine. Is there an advantage / difference between sip.future-nine.com and incoming.future-nine.com?
--
"People demand freedom of speech as a compensation for the freedom of thought which they seldom use."

reply to nitzan
NItzan, mine still doesn't work

reply to pandora
It depends on your router and ATA. sip may load balance between servers, while incoming goes to one server only. Some routers & ATA combo are OK with ATA being registered to server A, call coming from server B - but some reject those calls.

incoming.future-nine.com has DNS failover, so if the server goes down it will switch to a backup server within a few minutes.

Overall, for best reliability, I'd recommend using incoming.future-nine.com instead of sip if you have an incoming DID with us or use IpKall. If you use FN for outgoing only, it doesn't matter.

reply to nitzan
Mine still doesn't work. Donot know why. Ipkall works well with callcentric and inphonex

reply to waway

Nitzan. I've sent my information to you. Please check. I've played the future-nine the whole afternoon. I don't like that I cannot customize the password for the ATA, although I understadn that it is in Beta version, so I cannot expect more.

reply to nitzan
In my experience IPKall works fine with sip.future-nine.com but fails every times the ATA connected to sip2.future-nine.com. It doesn't matter if you have setup your proxy server for sip.future-nine.com or even IP address of the server at Future Nine still logs to one of 2 servers, I am not sure about the rules. If connected to sip.future-nine.com the calls come through without any issues but if it is connected to sip2 then based on amount the time that you setup your IPKall the person who called hears no ring tone on his or her end until it goes to VM. I hope this help Nitzan and his crew to figure out sip2 server.

reply to nitzan
Nitzan, would you recommend all users to use incoming.future-nine.com in their ATAs? (I receive most of my inbound calls on my FN DID, not from IPKALL.)

FYI, I tried incoming.future-nine.com, and it was LESS reliable than sip.future-nine.com. Just about all calls from sip.future-nine.com get through, sporadic connections were my experience with incoming.future-nine.com.

I switched back to sip.future-nine.com. If it isn't broke, I'm not going to try and fix it.
--
"People demand freedom of speech as a compensation for the freedom of thought which they seldom use."

reply to nitzan
Here, I am providing more info based on what I wrote earlier. port1 of ATA is setup for Future Nine Proxy server to begin was sip.future-nine.com later due to issue for my IPKall incoming going to VM, I changed it Later for last month or so to the IP address, I don't have any issue for calling out form line 1 and (the 2nd port is setup for GP/GC with no issue for incoming or outgoing calls and calls don't go to VM without ringing my phone 1st) I made 3 calls today from my cell to IPKall number 1st 2 calls made 1 after the other due to no ring and after about 20 second the call routed to VM, after looking at firewall log found out the calls coming from sip2.future-nine.com even in my ATA proxy server is setup for 64.251.23.244 which is sip.future-nine.com. I know you use load balancing for your registered users so spread them between these 2 servers.

13:14:32 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:14:33 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:14:34 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:14:36 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:14:40 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:14:48 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:15:04 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
********************************************************
13:15:35 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:15:36 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:15:37 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:15:39 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:15:43 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:15:51 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
13:16:07 SRC=65.111.186.2:5060 DST=71.117.211.xxx:5060 PROTO=UDP
****************************************************
20:43:29 SRC=64.251.23.244:17100 DST=71.117.211.xxx:16400 PROTO=UDP

As you can see 1st call was at 13:14:32 and 2nd was 13:15:35 both of these call came from sip2 regardless of my proxy was setup for 64.251.23.244 and both without ringing went to VM, then later this evening I changed the proxy to incoming.future-nine.com and made call from my cell the phone ranged which is the 3rd call. In the past was more and less the same it worked after changing the proxy to sip.future-nine.com or the IP address but then next day I will be connected to sip2 on your end and the calls fails to ring and go to VM. I am sure that you are going to tell me that problem is on my side due to those IP address that coming form your side but you also look at the other side of it too, whenever the calls comes from sip.future-nine.com there no issue and the phone rings.

Your IpKall must be set to sip.future-nine.com. Please set it to either incoming.future-nine.com and set your ATA to that too - or set it to sip2.future-nine.com and your ATA to that too. Basically, they have to match.

Are you saying my IPKALL has to be set up to incoming.future-nine.com AND the ATA set up to incoming.future-nine.com for it to work?
--
"People demand freedom of speech as a compensation for the freedom of thought which they seldom use."

reply to nitzan
I setup sip.future-nine.com as proxy server on IPKall when I setup my account with them and never changed it, my ATA already was using sip.future-nine.com yet the incoming calls were trying to use sip2. I believe The change happens on your end when trying to load balance and force the users to use sip2 server. I never wanted to use nor set my proxy for sip2 due to it is 23 hops away from me verses sip is only 13 hops. I set them up last night on incoming.future-nine.com on both end and it is working after 15 hours.