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
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 -----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
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
The formula for successful far-end NAT traversal is: 1. CPE with symmetric NAT capability (most CPE these days). 2. Far-end media relay and draft-comedia style media source port detection. This one is really key. It is critical for the service provider to ignore the media ports advertised in the customer-side SDP and "listen" to the media stream for the "actual" source port that is translated by the NAT gateway. This requires a media gateway and/or relay that has the intelligence to wait at least one packetisation cycle for RTP received from the customer end before sending media back to it, and does assume symmetric RTP. Most higher-end commercial SBCs can do this, but the option has to be explicitly turned on. The default behaviour here may account for the difference you see. There is pretty much no way to solve this problem without media relay at the service provider end, i.e. in case you were hoping for a purely proxy-based solution. 3. Yes, force rport. 4. Yes, aggressive override of network and transport-layer identifying information in SIP headers. 5. Disable all SIP ALGs on any firewalls and routers on the customer side. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
So we do most of what's below... The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy. The problem is that, in our tests, our SIP Proxy properly "fixes" NAT packets from phones, but then when they hit the DSL router w/ SIP ALG, it goes and mucks them up again. At which point we've lost control cause the packet is on it's way to the carrier directly. We DO NOT want to proxy or take on media if we can avoid it - this is critical to our design, and probably the fundamental root of our problems :-) I suspect the reality is Packet8 takes on all media so #2 is possible, where-as we must do this at the proxy level BEFORE it leaves the network. I am trying to take an alternative approach and having our router/proxy get smarter. I think we may just start ignoring everything after the @ symbol when re-mapping devices and calls from the outside. I'm otherwise out of ideas for this strategy without constantly turning off SIP ALG... - Darren On Aug 21, 2010, at 11:27 AM, Alex Balashov wrote:
The formula for successful far-end NAT traversal is:
1. CPE with symmetric NAT capability (most CPE these days).
2. Far-end media relay and draft-comedia style media source port detection.
This one is really key. It is critical for the service provider to ignore the media ports advertised in the customer-side SDP and "listen" to the media stream for the "actual" source port that is translated by the NAT gateway. This requires a media gateway and/or relay that has the intelligence to wait at least one packetisation cycle for RTP received from the customer end before sending media back to it, and does assume symmetric RTP.
Most higher-end commercial SBCs can do this, but the option has to be explicitly turned on. The default behaviour here may account for the difference you see.
There is pretty much no way to solve this problem without media relay at the service provider end, i.e. in case you were hoping for a purely proxy-based solution.
3. Yes, force rport.
4. Yes, aggressive override of network and transport-layer identifying information in SIP headers.
5. Disable all SIP ALGs on any firewalls and routers on the customer side.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 08/21/2010 02:36 PM, Darren Schreiber wrote:
The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy.
Sure, we mostly deploy proxy-based ITSP solutions. I definitely understand the idea here. Unfortunately, for far-end NAT traversal vis-a-vis media streams, it simply doesn't work. You're going to have to relay media for the reason I mentioned. There's no way around it - *unless* you can get *ALL* of your vendors to turn on COMEDIA-style media source port detection on their edge equipment/SBCs. The likelihood of that, in our experience, is virtually zero.
The problem is that, in our tests, our SIP Proxy properly "fixes" NAT packets from phones, but then when they hit the DSL router w/ SIP ALG, it goes and mucks them up again. At which point we've lost control cause the packet is on it's way to the carrier directly. We DO NOT want to proxy or take on media if we can avoid it - this is critical to our design, and probably the fundamental root of our problems :-) I suspect the reality is Packet8 takes on all media so #2 is possible, where-as we must do this at the proxy level BEFORE it leaves the network.
Yep, yep and yep.
I am trying to take an alternative approach and having our router/proxy get smarter. I think we may just start ignoring everything after the @ symbol when re-mapping devices and calls from the outside. I'm otherwise out of ideas for this strategy without constantly turning off SIP ALG...
You don't really have a choice in this area. Trust me, we are in the proxy-based service delivery element business full time. Proxies are all we do. When it comes to solving NAT traversal for media, there is no other way but to take the media. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
We've noticed that most devices that have a SIP ALG, simply look at packets on port 5060, generally they're not doing any sort of layer 7 packet inspection. So in order to avoid any SIP ALG issues, we generally use a random unused port for all the SIP traffic (both UAS and UAC side) so we don't have to worry about messing with the SIP ALGs at every site. Cheers, Gabe On Sat, Aug 21, 2010 at 11:36 AM, Darren Schreiber <d at d-man.org> wrote:
So we do most of what's below...
The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy.
The problem is that, in our tests, our SIP Proxy properly "fixes" NAT packets from phones, but then when they hit the DSL router w/ SIP ALG, it goes and mucks them up again. At which point we've lost control cause the packet is on it's way to the carrier directly. We DO NOT want to proxy or take on media if we can avoid it - this is critical to our design, and probably the fundamental root of our problems :-) I suspect the reality is Packet8 takes on all media so #2 is possible, where-as we must do this at the proxy level BEFORE it leaves the network.
I am trying to take an alternative approach and having our router/proxy get smarter. I think we may just start ignoring everything after the @ symbol when re-mapping devices and calls from the outside. I'm otherwise out of ideas for this strategy without constantly turning off SIP ALG...
- Darren
On Aug 21, 2010, at 11:27 AM, Alex Balashov wrote:
The formula for successful far-end NAT traversal is:
1. CPE with symmetric NAT capability (most CPE these days).
2. Far-end media relay and draft-comedia style media source port detection.
This one is really key. It is critical for the service provider to ignore the media ports advertised in the customer-side SDP and "listen" to the media stream for the "actual" source port that is translated by the NAT gateway. This requires a media gateway and/or relay that has the intelligence to wait at least one packetisation cycle for RTP received from the customer end before sending media back to it, and does assume symmetric RTP.
Most higher-end commercial SBCs can do this, but the option has to be explicitly turned on. The default behaviour here may account for the difference you see.
There is pretty much no way to solve this problem without media relay at the service provider end, i.e. in case you were hoping for a purely proxy-based solution.
3. Yes, force rport.
4. Yes, aggressive override of network and transport-layer identifying information in SIP headers.
5. Disable all SIP ALGs on any firewalls and routers on the customer side.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I think Gabriel is right on the money here. If you are complaining about CPE with ALG's messing with traffic, then just dodge the ALG's. Linksys, Cisco, D-link, 2-Wire, Actiontek etc are all including SIP ALG's in their products these days and they all suck and just break things. The easiest solution is to make your traffic look like something they shouldn't mess with. We have seen this problem too, and the solution is to just dodge it with unusual ports on UAS and UAC. On Sat, 2010-08-21 at 12:22 -0700, Gabriel Kuri wrote:
We've noticed that most devices that have a SIP ALG, simply look at packets on port 5060, generally they're not doing any sort of layer 7 packet inspection. So in order to avoid any SIP ALG issues, we generally use a random unused port for all the SIP traffic (both UAS and UAC side) so we don't have to worry about messing with the SIP ALGs at every site.
Cheers, Gabe
On Sat, Aug 21, 2010 at 11:36 AM, Darren Schreiber <d at d-man.org> wrote:
So we do most of what's below...
The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy.
The problem is that, in our tests, our SIP Proxy properly "fixes" NAT packets from phones, but then when they hit the DSL router w/ SIP ALG, it goes and mucks them up again. At which point we've lost control cause the packet is on it's way to the carrier directly. We DO NOT want to proxy or take on media if we can avoid it - this is critical to our design, and probably the fundamental root of our problems :-) I suspect the reality is Packet8 takes on all media so #2 is possible, where-as we must do this at the proxy level BEFORE it leaves the network.
I am trying to take an alternative approach and having our router/proxy get smarter. I think we may just start ignoring everything after the @ symbol when re-mapping devices and calls from the outside. I'm otherwise out of ideas for this strategy without constantly turning off SIP ALG...
- Darren
On Aug 21, 2010, at 11:27 AM, Alex Balashov wrote:
> The formula for successful far-end NAT traversal is: > > 1. CPE with symmetric NAT capability (most CPE these days). > > 2. Far-end media relay and draft-comedia style media source port > detection. > > This one is really key. It is critical for the service provider to > ignore the media ports advertised in the customer-side SDP and > "listen" to the media stream for the "actual" source port that is > translated by the NAT gateway. This requires a media gateway and/or > relay that has the intelligence to wait at least one packetisation > cycle for RTP received from the customer end before sending media back > to it, and does assume symmetric RTP. > > Most higher-end commercial SBCs can do this, but the option has to be > explicitly turned on. The default behaviour here may account for the > difference you see. > > There is pretty much no way to solve this problem without media relay > at the service provider end, i.e. in case you were hoping for a purely > proxy-based solution. > > 3. Yes, force rport. > > 4. Yes, aggressive override of network and transport-layer identifying > information in SIP headers. > > 5. Disable all SIP ALGs on any firewalls and routers on the customer side. > > -- > Alex Balashov - Principal > Evariste Systems LLC > 1170 Peachtree Street > 12th Floor, Suite 1200 > Atlanta, GA 30309 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Aug 21, 2010, at 2:36 PM, Darren Schreiber wrote:
So we do most of what's below...
The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy.
That's undoubtedly 95 to 100% of your problem right there. Have you bothered to take packet traces to see what Packet8 devices do compared to yours? I'm sure you'll find that they proxy all media. You can either save bandwidth or take control of the situation for compatibility reasons, or train your support to to a bit of both. Its really simple: you give everyone sip1.abc.com. If they have problems, you set them up with sip2.abc.com which is set to not reinvite.
Simply put, if you want to do NAT traversal at the CPE, you must be 100% certain that there is nothing that can even possibly considered an ALG or Firewall in front of your NAT traversal device. Many of the "SOHO" routers that the RBOCs deploy for business customers have ALG's, and I have seen some (such as the Netopia's) where the ALG is basically undocumented and cannot even be controlled via the GUI. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Darren Schreiber Sent: Saturday, August 21, 2010 2:37 PM To: Alex Balashov Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] "...but it works with Packet8" So we do most of what's below... The one thing that's a bit different about our service is we want to stay out of the media path and, "under the hood", send the customer direct to the carrier for most calls. That's the point of our "router" - it's also a SIP proxy. The problem is that, in our tests, our SIP Proxy properly "fixes" NAT packets from phones, but then when they hit the DSL router w/ SIP ALG, it goes and mucks them up again. At which point we've lost control cause the packet is on it's way to the carrier directly. We DO NOT want to proxy or take on media if we can avoid it - this is critical to our design, and probably the fundamental root of our problems :-) I suspect the reality is Packet8 takes on all media so #2 is possible, where-as we must do this at the proxy level BEFORE it leaves the network. I am trying to take an alternative approach and having our router/proxy get smarter. I think we may just start ignoring everything after the @ symbol when re-mapping devices and calls from the outside. I'm otherwise out of ideas for this strategy without constantly turning off SIP ALG... - Darren On Aug 21, 2010, at 11:27 AM, Alex Balashov wrote:
The formula for successful far-end NAT traversal is:
1. CPE with symmetric NAT capability (most CPE these days).
2. Far-end media relay and draft-comedia style media source port detection.
This one is really key. It is critical for the service provider to ignore the media ports advertised in the customer-side SDP and "listen" to the media stream for the "actual" source port that is translated by the NAT gateway. This requires a media gateway and/or relay that has the intelligence to wait at least one packetisation cycle for RTP received from the customer end before sending media back to it, and does assume symmetric RTP.
Most higher-end commercial SBCs can do this, but the option has to be explicitly turned on. The default behaviour here may account for the difference you see.
There is pretty much no way to solve this problem without media relay at the service provider end, i.e. in case you were hoping for a purely proxy-based solution.
3. Yes, force rport.
4. Yes, aggressive override of network and transport-layer identifying information in SIP headers.
5. Disable all SIP ALGs on any firewalls and routers on the customer side.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Packet8 is clearly big enough to write their own SIP stack for both the client and core devices. Don't know if they did, but I would not dismiss the possibility. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
On 08/23/2010 11:09 AM, Hiers, David wrote:
Packet8 is clearly big enough to write their own SIP stack for both the client and core devices. Don't know if they did, but I would not dismiss the possibility.
This is extremely unlikely, unless they inherited one via licensing from an acquisition. Developing a SIP stack is a surprisingly capital-intensive endeavour, at least, when it comes to working out interop issues and bugs, as well as natural race conditions arising from a literal interpretation of RFC 3261. All that testing and R&D is hard to afford. That's why the only good SIP stacks have been around for at least ten years (though, from this it does not follow that just because a SIP stack has been around for ten years means it's any good). Generally, the only ones with the resources to do it are major softswitch and/or SBC vendors, not service providers, because of the level of engineering and software development core competency required. For service providers development may be important, but is ultimately rather ancillary to their principal business functions, especially at the protocol stack level. Successful ITSPs like Packet8 are ultimately sales/marketing/fulfillment-dominated machines, first and foremost, above all else. Even then, much commercial gear today licenses the Radvision or Aricent stack. I know Cisco has their own, as does Siemens and did CopperCom, and certainly, Alcatel-Lucent. But there aren't that many of them, ultimately; well-worn commercially viable SIP stacks are a small family. Venturing outside of that family is where a lot of problems are found. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
Alex Balashov wrote:
This is extremely unlikely, unless they inherited one via licensing from an acquisition.
Developing a SIP stack is a surprisingly capital-intensive endeavour, at least, when it comes to working out interop issues and bugs, as well as natural race conditions arising from a literal interpretation of RFC 3261. All that testing and R&D is hard to afford. That's why the only good SIP stacks have been around for at least ten years (though, from this it does not follow that just because a SIP stack has been around for ten years means it's any good).
I wouldn't say it's trivial to do it, but one of our partners has a 100% custom-written and RFC-compliant stack and softphone which goes to great lengths to penetrate any NAT--they guarantee it. Licensing starts at $42,000, however for a company the size of Packet 8 that would be trivial. -- Carlos Alvarez TelEvolve 602-889-3003
How is the Sofia SIP Stack, it is open sourced, developed by Nokia and claims to be compliant with RFCs http://sofia-sip.sourceforge.net/ ----- Original Message -----
From: "Carlos Alvarez" <carlos at televolve.com> Cc: voiceops at voiceops.org Sent: Monday, August 23, 2010 11:56:16 AM Subject: Re: [VoiceOps] "...but it works with Packet8"
Alex Balashov wrote:
This is extremely unlikely, unless they inherited one via licensing from an acquisition.
Developing a SIP stack is a surprisingly capital-intensive endeavour, at least, when it comes to working out interop issues and bugs, as well as natural race conditions arising from a literal interpretation of RFC 3261. All that testing and R&D is hard to afford. That's why the only good SIP stacks have been around for at least ten years (though, from this it does not follow that just because a SIP stack has been around for ten years means it's any good).
I wouldn't say it's trivial to do it, but one of our partners has a 100% custom-written and RFC-compliant stack and softphone which goes to great lengths to penetrate any NAT--they guarantee it. Licensing starts at
$42,000, however for a company the size of Packet 8 that would be trivial.
-- Carlos Alvarez TelEvolve 602-889-3003
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760
From packet8's most recent 10K filing:
### We developed the core software associated with the Virtual Office product line including the call control engine, protocol stacks and network address translation (NAT) traversal firmware for the customer premise equipment. As a result, we are able to update the software functionality of our services without third party assistance and limit the distribution of our unique customer premise equipment features such as NAT traversal to customer premise equipment that is sold in conjunction with our services. ### There is no way they could do what they do if they limited themselves to configuring existing devices. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez Sent: Monday, August 23, 2010 8:56 AM Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] "...but it works with Packet8" Alex Balashov wrote:
This is extremely unlikely, unless they inherited one via licensing from an acquisition.
Developing a SIP stack is a surprisingly capital-intensive endeavour, at least, when it comes to working out interop issues and bugs, as well as natural race conditions arising from a literal interpretation of RFC 3261. All that testing and R&D is hard to afford. That's why the only good SIP stacks have been around for at least ten years (though, from this it does not follow that just because a SIP stack has been around for ten years means it's any good).
I wouldn't say it's trivial to do it, but one of our partners has a 100% custom-written and RFC-compliant stack and softphone which goes to great lengths to penetrate any NAT--they guarantee it. Licensing starts at $42,000, however for a company the size of Packet 8 that would be trivial. -- Carlos Alvarez TelEvolve 602-889-3003 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Hiers, David wrote:
From packet8's most recent 10K filing:
### We developed the core software associated with the Virtual Office product line including the call control engine, protocol stacks and network address translation (NAT) traversal firmware for the customer premise equipment. As a result, we are able to update the software functionality of our services without third party assistance and limit the distribution of our unique customer premise equipment features such as NAT traversal to customer premise equipment that is sold in conjunction with our services. ###
There is no way they could do what they do if they limited themselves to configuring existing devices.
8x8 owns many, many VoIP patents
I had guessed that, too, until I discovered that Packet8's phones are accessible via the web GUI when their firmware on it. Guess what's different after you login? The logo. I suspect, at some point, the firmware might have been different but from what I can tell all the stock features are still built-in. Even the RCS server is shown and can be changed (on their firmware). I'm not sure they did much with the firmware, though I agree that the above is not conclusive evidence of anything. - Darren On Aug 23, 2010, at 8:09 AM, Hiers, David wrote:
Packet8 is clearly big enough to write their own SIP stack for both the client and core devices. Don't know if they did, but I would not dismiss the possibility.
David Hiers
CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277
-----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
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
I believe Alex was referring to the SIP stack on their proxies or "SBC" devices at the core, not the devices at the customer's site. Trying to (or wanting to) write a custom firmware for a phone is a whole different ballgame. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Darren Schreiber Sent: Monday, August 23, 2010 12:05 PM To: Hiers, David Cc: VoiceOps at voiceops.org Subject: Re: [VoiceOps] "...but it works with Packet8" I had guessed that, too, until I discovered that Packet8's phones are accessible via the web GUI when their firmware on it. Guess what's different after you login? The logo. I suspect, at some point, the firmware might have been different but from what I can tell all the stock features are still built-in. Even the RCS server is shown and can be changed (on their firmware). I'm not sure they did much with the firmware, though I agree that the above is not conclusive evidence of anything. - Darren On Aug 23, 2010, at 8:09 AM, Hiers, David wrote: > Packet8 is clearly big enough to write their own SIP stack for both the client and core devices. Don't know if they did, but I would not dismiss the possibility. > > > > David Hiers > > CCIE (R/S, V), CISSP > ADP Dealer Services > 2525 SW 1st Ave. > Suite 300W > Portland, OR 97201 > o: 503-205-4467 > f: 503-402-3277 > > > -----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 > > > This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Well regardless, thanks all for your input. All your answers have pointed me in the direction we were already going anyway. I think we will continue to instruct people to turn off ALG and other nastyness "for best call quality" but we will also program our SBC software and our server to negotiate some test packets and auto-detect when packets are crippled, then adjust routing automatically. Fun times. - Darren On Aug 23, 2010, at 9:11 AM, Scott Berkman wrote: > I believe Alex was referring to the SIP stack on their proxies or "SBC" > devices at the core, not the devices at the customer's site. Trying to (or > wanting to) write a custom firmware for a phone is a whole different > ballgame. > > -Scott > > -----Original Message----- > From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] > On Behalf Of Darren Schreiber > Sent: Monday, August 23, 2010 12:05 PM > To: Hiers, David > Cc: VoiceOps at voiceops.org > Subject: Re: [VoiceOps] "...but it works with Packet8" > > I had guessed that, too, until I discovered that Packet8's phones are > accessible via the web GUI when their firmware on it. Guess what's different > after you login? The logo. > > I suspect, at some point, the firmware might have been different but from > what I can tell all the stock features are still built-in. Even the RCS > server is shown and can be changed (on their firmware). > > I'm not sure they did much with the firmware, though I agree that the above > is not conclusive evidence of anything. > > - Darren > > > On Aug 23, 2010, at 8:09 AM, Hiers, David wrote: > >> Packet8 is clearly big enough to write their own SIP stack for both the > client and core devices. Don't know if they did, but I would not dismiss > the possibility. >> >> >> >> David Hiers >> >> CCIE (R/S, V), CISSP >> ADP Dealer Services >> 2525 SW 1st Ave. >> Suite 300W >> Portland, OR 97201 >> o: 503-205-4467 >> f: 503-402-3277 >> >> >> -----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 >> >> >> This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > >
Darren Schreiber wrote:
Well regardless, thanks all for your input.
All your answers have pointed me in the direction we were already going anyway. I think we will continue to instruct people to turn off ALG and other nastyness "for best call quality" but we will also program our SBC software and our server to negotiate some test packets and auto-detect when packets are crippled, then adjust routing automatically.
Fun times.
I can't help, but I will tell you that this is the path we've taken for the BYOI customers. In particular the Qwest DSL customers are told to call Qwest and request a "VoIP compatible" router to replace whatever they have before they even get our phones. Believe it or not, Qwest reps recognize that and just send a new modem. -- Carlos Alvarez TelEvolve 602-889-3003
Do you know what modem they were using and which ones Qwest is replacing it with? On 8/23/2010 11:29 AM, Carlos Alvarez wrote:
Darren Schreiber wrote:
Well regardless, thanks all for your input.
All your answers have pointed me in the direction we were already going anyway. I think we will continue to instruct people to turn off ALG and other nastyness "for best call quality" but we will also program our SBC software and our server to negotiate some test packets and auto-detect when packets are crippled, then adjust routing automatically.
Fun times.
I can't help, but I will tell you that this is the path we've taken for the BYOI customers. In particular the Qwest DSL customers are told to call Qwest and request a "VoIP compatible" router to replace whatever they have before they even get our phones. Believe it or not, Qwest reps recognize that and just send a new modem.
-- Lee Riemer Director of Technical Operations Bestline Communications, L.P. Voice: 1+512.328.9095 Fax: 1+512.328.0038
Lee Riemer wrote:
Do you know what modem they were using and which ones Qwest is replacing it with?
It varies on both sides. The old ones were mostly Actiontec but there have been many over the years. The new ones seem to be mostly Netopia, but also some Actiontec. We've paid no attention to the models because it's been 100% successful to just have the customer call and tell them they need a modem that works with VoIP phones. -- Carlos Alvarez TelEvolve 602-889-3003
On Mon, Aug 23, 2010 at 09:45:10AM -0700, Carlos Alvarez wrote:
Lee Riemer wrote:
Do you know what modem they were using and which ones Qwest is replacing it with?
It varies on both sides. The old ones were mostly Actiontec but there have been many over the years. The new ones seem to be mostly Netopia, but also some Actiontec. We've paid no attention to the models because it's been 100% successful to just have the customer call and tell them they need a modem that works with VoIP phones.
I've always pushed Qwest DSL customers to the Actiontec M1000 series when possible. If there's a failure, they can get replacements at Best Buy and Wal-Mart. Never had any issues (in general) with the Actiontec gear. They've got rudimentary QOS to avoid upstream congestion.
participants (13)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
carlos＠televolve.com -
d＠d-man.org -
daryl＠introspect.net -
David_Hiers＠adp.com -
gkuri＠ieee.org -
jim＠californiatelecom.com -
josmon＠rigozsaurus.com -
lriemer＠bestline.net -
matthew＠corp.crocker.com -
peter＠4isps.com -
scott＠sberkman.net