[VoiceOps] "...but it works with Packet8"

[Darren Schreiber]

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