VOIP etc > Voice Over IP - VOIP > VOIP Tech Chat > Does IPKall direct to ATA make a difference?

Does IPKall direct to ATA make a difference?

It's easy enough to try for youself. I think the direct connection is faster than going through a provider, but I don't have Callwithus. You may encounter problems with the CID using IPKall.

reply to jbs
I use CallWithUs for my outgoing calls and IPKall for my DID. IPKall connects directly to my ATA (SPA3102). People reach me via my GV number which forwards to my IPKall number.

I've never had my incoming calls setup any other way than direct to my ATA, so I can't say if whether there is a noticable difference vs. forwarding IPKall through another number. I can tell you that latency seems very good to me--at least as good as when I was using HyperDog (which I was perfectly satisfied with most of the time) for incoming and outgoing. I do get pretty bad lag when talking to my mom who uses Comcast Digital Voice, but that was a problem when I was with HyperDog and to some degree when I was still using POTS.

Setting it up is easy enough that there's no good reason not to give it a shot. Just login to your IPKall account and enter your ATA's IP (or if you have a DNS resolvable address you can use that) in the "SIP Proxy" field and set the "SIP Phone Number" field to your CallWithUs number. On the ATA (I'm assuming the SPA-2102R has these options) set it to answer without registering. If you already have it set up to register with CallWithUs then that should do it.

You don't have to register with CallWithUs, btw if you'll only use it for outgoing. I have my CallWithUs SIP credentials entered and have register set to no (and "Make/Ans Call Without Reg" fields set to yes).

In my experience, IPKall directly to my softphone is 7 hops while Gizmo5 is 12 hops and the first 4 hops is inside the ATT network so really its 3 hops from IPKall vs 8 from Gizmo5. That's a significant improvement going with the direct route. Of course your network path may be different. Also call quality will not be affected by Gizmo5 since it will not be touching their server.

reply to jbs
I have my IPKall number forwarded to my ATA using the free No-IP service. Before this current configuration I use to forward my IPKall number to a Callcentric account which worked well. I do notice better audio quality and prefer latest configuration compared to the previous one. I know CallWithUs has very good reputation but if it were my decision I would remove the additional link in your work flow attempting to increase reliability and decrease the failure rate.

reply to jbs
I have one IPKALL number going directly to an ATA, just to see if I could do it. Basically what I did is give my ATA a fixed internal IP, set the port for it to 5062, in my Linksys router set it to direct any port requests to 5062 to forward to the IP of the router, and in my IPKALL settings, set it to forward to: anynumber@12.34.56.78:5062, where "12.34.56.78" is my internet IP. One way audio problems can usually be solved by adding a STUN server. If your ISP gives you a dynamic IP, you'll need to keep changing that every time your IP changes.

reply to jbs
Thanks. Last night I checked my ip and changed my IPKall information. setting the proxy to ipnumber:5060. I set my ata to make and answer without reg. This morning the phone rang, but I couldn't answer it at all, much less experience one way audio.

There must be some other things I need to set on my ata. I haven't had a stun server enabled before, but after doing so I still get nothing.

This is promising if I can get it to work!

I believe the SPA2102R has 2 FXS ports. If so, does this problem occur on both ports? Do you have separate user ID settings for each port and was the phone you tried to answer on a port with a user ID matching the SIP Phone Number setting from IPKall?

reply to jbs
You are experiencing one of the big problems that can be encountered using direct ip calling. The problem is NAT transversal. The problem is caused by the router that you are using. When you use an voip provider they often have several techniques available to avoid the problem. Just using your ata, you only use the techniques built into the ata. Using a STUN server along with the NAT Support Parameters usually solves the problem, not not always.

Dogface05 had a recent posting outline the best settings for NAT transversal on a Linksys/Cisco adapter.
»Re: Different providers for inbound and outbound on same ATA?

reply to jbs
Do you possibly have a port conflict? Is 5060 being used by another VoIP device? Try moving it to 5082 or some other port.
--
The difference between genius and stupidity is that genius has its limits.

reply to jbs
jbs, rather than setting your ATA not to register at all, try letting it register to whatever provider you plan to use for outgoing. I don't know why this should make a difference, but it did for me using a different adapter.

Also, what do you mean when you say the phone rang but you could not answer?

reply to jbs
If I use my cellphone to call my IPKall number, my ATA phone ring just fine. However, when I answer the ATA phone I hear nothing on the other end. BUT, the cellphone continues ringing as if the IPKall never picked up and its still ringing through. Its like there is no "take off the hook" action.

I have two lines and forwarded 5060 and 5061 TCP/UDP as well as 16384-16482 UDP. I never had any problems with my Gizmo5 setup (other than them just being unreliable). In IPKall I have my proxy set to mydomain:5060. The number is the Callwithus number.

Heh, being the novice that I am with this I was just happy to get it ringing directly. Obviously I have IPKall pointed to my ATA, but I can't get the ATA to pick up the call.

It sounds like the initial SIP invite is finding your ATA, and the 180/Ringing message is finding its way back to IPKall and the calling UA. However, the 200/OK from your ATA is getting lost somewhere between your ATA and the calling UA. This does not look like the classic NAT Traversal problem that results in one-way audio. You could trouble shoot it by setting up a syslog or debug log on your ATA and seeing where the OK is being sent. I'm guessing the OK is being sent to the Callwithus proxy rather than to IPKall.

Just for testing, try removing the Callwithus info from your ATA so that it doesn't register, and set it to answer without registering. In IPKall, the "SIP Phone Number" should be the username in the ATA's user tab, and "SIP Proxy" should be "yourdomain:port," where "yourdomain" is an IP address or dyndns address, and "port" is the local port used by your ATA.

reply to jbs
Thanks everyone... I'm trying to digest what you're saying, but all of a sudden...

It works! Problem is I don't know what I did to make it work. I've been ticking this on and ticking that off, putting my ATA in DMZ, etc. Now I'm going backwards step by step to get it NOT to work. I need to solidify the solution so I can set up line 2 the same way (line 2 is my wife's line).

EDIT - ... and now all by itself, its broke

Does anyone know if IPKall to voxalot would basically be the same as direct since I connect all my calls through it anyway?

Another thing to try is to put your external (Internet) IP address in the "EXT IP" field. This will populate the SDP message with the external ip address that is neded to pass audio rather populating it with your local IP. Set your router so that the service provider IP or requested port is forwarded to your ATA. Wireshark works really well for solving this type of problem.