
Are you running with an SBC? Darren Schreiber <d at d-man.org> wrote:
So do how do we get to where we "don't tweak"? Again, as Packet8 being the reference point, they seem to run into this problem very infrequently now from what I can tell...
- Darren
On Aug 21, 2010, at 11:16 AM, Jim Gurol wrote:
Darren,
I had a similar issues when moving customers from one platform to another. One had an SBC, one didn't. The one with SBC controller handled these NAT problems without any tweaks, while the one without the SBC, sometimes needed tweaking on customer CPE.
Jim Gurol California Telecom www.californiatelecom.com<http://www.californiatelecom.com>
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Darren Schreiber Sent: Saturday, August 21, 2010 10:15 AM To: VoiceOps at voiceops.org Subject: [VoiceOps] "...but it works with Packet8"
Hi folks, We provide a fully redundant VoIP service to our customers where they hook up two cheap Internet connections to our special little box and we load-balance / failover across them. We have been running into periodic issues with SIP ALG and such typical VoIP crippling technologies when hooking up our equipment, requiring us to get into the client's router and turn off SIP ALG (or Cisco "fix-up" features). Specifically we have issues with 2Wire devices, which are very very popular. We've been assuming this is standard/par-for-the-course behavior.
We have a partner who is reselling our service and he has asked me a few times why our service requires any tweaks at all. He is literally replacing Packet8 phones with our service. We are utilizing the old Packet8 phones so it is not a model and unlikely a firmware issue. Something we are doing in our way of configuring these phones is fundamentally different then Packet8. The reseller feels we should not have to mess with the clients router. I'm starting to think he has a valid point.
So, my question is, why does Packet8 work so well behind so many firewalls? I don't think their Aastra firmware is all that different then stock Aastra firmware. So my thoughts are: - They might be using TCP signaling for SIP call setup instead of UDP? - They might be ignoring the contents of SIP packets and rewrites and using rather "aggressive" settings on the switch side to figure out routing based solely on network headers (we use the actual SIP packets) - They force rport?
I'm just guessing at this point, but the reseller has a valid point - we should be able to compete with this directly.
Let me know your thoughts or if you have any advice on best-practices for setting up Aastras (and other phones) to behave nicely across firewalls that have SIP ALG *enabled*. Sorry if this is a lame or too broad a question. Any tips & tricks you've used are helpful.
Thanks much,
Darren Schreiber Co-Founder - VoIP, Inc. - (415) 886-7900 www.2600hz.org - Free VoIP Software www.voipkb.com - FreeSWITCH Trainings
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (1)
-
jim@californiatelecom.com