Skinny, you guys really need a low user option. Something in the 10-25GB per month range.

What would service in a 'fair' coverage area be like typically? I guess 10-20mbit?

See my previous comment. 20Mbps on two bars (Martinborough), 40Mbps on four bars (Johnsonville, Whitby).

YMMV.

40 down 20 up, 4 bars here in little ol' Hoki

I can live with that...

Hi All,

Has anyone else managed to maintain VoIP for incoming calls longer than a day or two?

If you have had success in this area I would be interested in how you have configured VoIP. The only combination I have not tried is using STUN with SiP ALG, mainly  because I have never used STUN in the past even though I have used 4G accounts behind CGNAT with different overseas carriers for over 12 months (for each carrier) without issue. I am away from home at present so I cannot change the configuration (only test the one I have by calling it).

I have two SIP providers which I have tried independently (i.e. only one connected to the router at a time, not both) and both maintain registration 27/7 such that I can always make outgoing calls (audio both ways) using the SIP ALG. However after 1 to 2 day's max (usually about 24 hours) I am unable to receive incoming calls (i.e. the phone will not ring and call goes to the answering phone service at the SIP server). Hence you would never know looking at the ATA or making a test call using the VoIP phone that incoming calls have failed (because the ATA is still registered and outgoing calls work fine).

When this occurs, as I explained in my previous post, but will state again for clarity, changing the router to place the ATA into the DMZ zone and switching off SIP ALG allows the incoming call to ring the phone, but the incoming RTP gets lost (i.e. no incoming voice, only outgoing voice). Switching off the firewall and/or attempting to use STUN does not solve this issue. Rebooting the ATA does not solve this issue.

Rebooting the router with the SIP ALG enabled (and DMZ disabled) allows the router to establish full functionality until the iP address changes. I suspect the SIP ALG does not update. Disabling SIP ALG does not solve the issue because of the way the router handles IP address in DMZ etc. which does not allow the ATA to pick up the correct IP addresses etc. to establish RTP.

I have another 4G router setup (totally different to the B315) that I have placed a Skinny mobile SIM into on 4G and opened up the VoIP port ranges (even though I am behind CGNAT, it allows the ATA to establish correct communications). I have had this running for about 3 days now and it continues to work as expected. I expect the 4G data to work in the same way as Skinny broadband hence the only difference is the router. Thus I conclude that the problem lies with the B315 router in my opinion, in that it must handle IP address differently and not allow the ATA to determine the correct external IP address to route the call without the SIP ALG (a casual look at the SIP logs also suggests this is correct, and there are no configuration settings I have tried on the ATA that will correct this to working state, including STUN settings with a STUN server). If I am correct I expect all VoIP users to experience the same issues with incoming calls using the B315 router. If you are not then I would be very interested to know what you are doing differently (assuming you are using SIP and not IAX or Skype etc).

QSX

I used a Cisco SPA112 auto provisioned with 2talk. I haven't done any long phone calls, but other testing has been fine. It's been on solid probably a couple of weeks and I can still call it anytime and it rings and I can answer without fail.

coffeebaron:

 

I used a Cisco SPA112 auto provisioned with 2talk. I haven't done any long phone calls, but other testing has been fine. It's been on solid probably a couple of weeks and I can still call it anytime and it rings and I can answer without fail.

 

Thanks for your reply. The only difference I can see looking at 2talks SPA122 setup is the use of STUN server (optional) and an aggressive retry and long expiry interval. The SPA122 is basically the same as a SPA112 but also has a Ethernet port and DHCP router. 

I looked at 2talks SPA122 page a week ago and that is why I commented that the only thing I have not tried is using STUN with the SIP ALG. 2talk state this is optional and I have never needed to use STUN in the past to make a reliable system, however I will try it with the SIP ALG (I did try it without SIP ALG to try and get rid of the SIP ALG but not suprisingly I had no success). I don't believe the short retry and long expiry intervals will have any impact because restarting the ATA does not fix the issue.

VoIP on Spark/XT has never worked well historically and there are many threads on here discussing this. It's probably not surprising it still doen't work well.

Port forwards in the VoIP world should not be used and post a significant security risk. If they are needed a setup is broken, so you need to fix the setup. If your house door breaks you fix it, you don't leave your door wide open as your means of getting in.

A SIP registration is typically for inbound calls, not outbound (it's basically just saying "here's my IP to send calls to"). 99% of VoIP providers will allow an outbound call regardless of the registration state as your user credentials are sent in the call setup. You can quite easily have a registration that's still up but inbound calls fail particularly in the CG-NAT/double NAT world.

sbiddle:

 

VoIP on Spark/XT has never worked well historically and there are many threads on here discussing this. It's probably not surprising it still doen't work well.

 

Port forwards in the VoIP world should not be used and post a significant security risk. If they are needed a setup is broken, so you need to fix the setup. If your house door breaks you fix it, you don't leave your door wide open as your means of getting in.

 

A SIP registration is typically for inbound calls, not outbound (it's basically just saying "here's my IP to send calls to"). 99% of VoIP providers will allow an outbound call regardless of the registration state as your user credentials are sent in the call setup. You can quite easily have a registration that's still up but inbound calls fail particularly in the CG-NAT/double NAT world.

 

 

Thanks for the information, and clarifying SIP registration. I did not realise that there was a historic issue with VoIP on Spark/XT (its hard to be across every post on a forum, especially when one is new and not reading the forum every day). 

QSX

QSX:

Hi All,

Has anyone else managed to maintain VoIP for incoming calls longer than a day or two?

If you have had success in this area I would be interested in how you have configured VoIP. The only combination I have not tried is using STUN with SiP ALG, mainly  because I have never used STUN in the past even though I have used 4G accounts behind CGNAT with different overseas carriers for over 12 months (for each carrier) without issue. I am away from home at present so I cannot change the configuration (only test the one I have by calling it).

I have two SIP providers which I have tried independently (i.e. only one connected to the router at a time, not both) and both maintain registration 27/7 such that I can always make outgoing calls (audio both ways) using the SIP ALG. However after 1 to 2 day's max (usually about 24 hours) I am unable to receive incoming calls (i.e. the phone will not ring and call goes to the answering phone service at the SIP server). Hence you would never know looking at the ATA or making a test call using the VoIP phone that incoming calls have failed (because the ATA is still registered and outgoing calls work fine).

When this occurs, as I explained in my previous post, but will state again for clarity, changing the router to place the ATA into the DMZ zone and switching off SIP ALG allows the incoming call to ring the phone, but the incoming RTP gets lost (i.e. no incoming voice, only outgoing voice). Switching off the firewall and/or attempting to use STUN does not solve this issue. Rebooting the ATA does not solve this issue.

Rebooting the router with the SIP ALG enabled (and DMZ disabled) allows the router to establish full functionality until the iP address changes. I suspect the SIP ALG does not update. Disabling SIP ALG does not solve the issue because of the way the router handles IP address in DMZ etc. which does not allow the ATA to pick up the correct IP addresses etc. to establish RTP.

I have another 4G router setup (totally different to the B315) that I have placed a Skinny mobile SIM into on 4G and opened up the VoIP port ranges (even though I am behind CGNAT, it allows the ATA to establish correct communications). I have had this running for about 3 days now and it continues to work as expected. I expect the 4G data to work in the same way as Skinny broadband hence the only difference is the router. Thus I conclude that the problem lies with the B315 router in my opinion, in that it must handle IP address differently and not allow the ATA to determine the correct external IP address to route the call without the SIP ALG (a casual look at the SIP logs also suggests this is correct, and there are no configuration settings I have tried on the ATA that will correct this to working state, including STUN settings with a STUN server). If I am correct I expect all VoIP users to experience the same issues with incoming calls using the B315 router. If you are not then I would be very interested to know what you are doing differently (assuming you are using SIP and not IAX or Skype etc).

QSX

I found a easy fix for me last week. Add another 0 to port 5060, lol, so easy. My iTalk works well now, incoming calls OK for a few days, no problems. I don't know about my 2talk , its registered on the modem, but I don't use it, so I don't know if it works or not.
Or you can try 5060 --- 5070, or whatever voip port. And Please post the results here. I tried everything else, but nothing works, except this method.