<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I can only concur with you.<div><br></div><div>In my experience the trend was always the same. In the beginning the operator works hard to implement an SBC for all kind of reasons that are not related to his business. After some relative small effort everything seem to work in a test environment with a few calls and types of phones.</div><div><br></div><div>Once real traffic starts flowing, then problems, which were not visible in the beginning start to emerge. Once they emerge they only expand in scope and multiply in size, which is fine for the SBC manufacturer as they have infinite work to process.</div><div><br></div><div>The operator then consumes infinite resources navigating around the problems introduced by the SBC. In the end everyone wishes to take it out but is too late because the architecture is already in place, nobody want to admit it was a mistake in the first place, after all it was a gigantic vendor selection process where everyone was involved and nobody wants to go through the pain of fixing it. Profitability has gone done the drain due to over-engineering of the network.</div><div><br></div><div>The lesson is to keep the infrastructure simple, make sure you are 'complying' with whatever regulation is required but don't embed that requirement to deep into your product or it will kill it long term.</div><div><div><br></div></div><div>I wish everyone who starts a SIP business for scratch does not make the mistakes many did in the hype VoIP era.</div><div><br></div><div>Adrian</div><div><br></div><div><br><div><div>On Dec 11, 2008, at 9:36 AM, Brett Nemeroff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Having a single point of connectivity to the customer, topology<br>masking, and potentially CALEA compliance. You can get by without<br>it.. It's a matter of preference of sorts. Some people have more luck<br>with nat traversal with them. I'd being interested in hearing other's<br>experiences with them.<br><br>On the other hand, it IS a fixed bottleneck. I can't tell you how many<br>times I've had a provider's overloaded SBC kill the QOS on my calls..<br><br>-Brett<br><br><br>On Thu, Dec 11, 2008 at 2:25 AM, Adrian Georgescu <<a href="mailto:ag@ag-projects.com">ag@ag-projects.com</a>> wrote:<br><blockquote type="cite">Robert,<br></blockquote><blockquote type="cite">NAT traversal is solved by OpenSIPS/MediaProxy combination for both<br></blockquote><blockquote type="cite">signalling and media. Cost is important for an operator and any intermediate<br></blockquote><blockquote type="cite">like an SBC, which does not bring any value to end customer is not likely to<br></blockquote><blockquote type="cite">remain there for long.<br></blockquote><blockquote type="cite">What I am trying to figure out is if there are other good reasons besides<br></blockquote><blockquote type="cite">the NAT issue for which the insertion of the SBC justifies its cost for an<br></blockquote><blockquote type="cite">operator.<br></blockquote><blockquote type="cite">Regards,<br></blockquote><blockquote type="cite">Adrian<br></blockquote><blockquote type="cite">On Dec 11, 2008, at 2:02 AM, Robert Dyck wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">You are right, these terms are used in a rather casual manner. Also privacy<br></blockquote><blockquote type="cite">and security can never be absolute. However there are reasons why an<br></blockquote><blockquote type="cite">individual or organization may want to hide their topology. Those with bad<br></blockquote><blockquote type="cite">intentions may look for clues so that they may subvert the system.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Perhaps a stronger case can be made when we consider that NAT is perhaps the<br></blockquote><blockquote type="cite">biggest headache with SIP. Different service providers have different ideas<br></blockquote><blockquote type="cite">how they might overcome the problem. If a UA on a LAN or an extension on a<br></blockquote><blockquote type="cite">PBX appears as a simple UA with a public address then the chance of success<br></blockquote><blockquote type="cite">improves.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">OpenSBC may be the way to go. It will act as a proxy or B2BUA. The nice<br></blockquote><blockquote type="cite">thing<br></blockquote><blockquote type="cite">about OpenSIPS is its light weight if you don't need a lot of modules. I am<br></blockquote><blockquote type="cite">not a programmer but it seems to me that it would not be too difficult to<br></blockquote><blockquote type="cite">hide the private VIAs and CONTACTs. It already supports mediaproxy/rtpproxy.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Wednesday 10 December 2008, Adrian Georgescu wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Robert,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Could you expand on what you mean by:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">1. Privacy<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">2. Extra security<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">These seem to be highly abused terms while there is no proper<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">description available of what they mean and for whom they provide the<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">benefit.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Adrian<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Dec 10, 2008, at 9:32 PM, Robert Dyck wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I see a need for a very basic proxy-like B2BUA. This would<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">completely hide the<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">local topology. This would provide privacy and extra security as<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">well as<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">working around the bad behaviour of some service providers.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Rob<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Wednesday 10 December 2008, Brett Nemeroff wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For what it's worth, I've had problems doing this with some [broken]<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">carriers. Namely they see a private address in one of the Vias and<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">they assume it's NAT.. Pretty messy. If you look through the archive<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">you'll see what happened to me.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That being said, I think it's pretty unusual that this happens.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Brett<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Wed, Dec 10, 2008 at 8:14 AM, Giuseppe Roberti <<a href="mailto:jnod@jnod.org">jnod@jnod.org</a>><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I have an opensips server running "between" a man local area and<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">internet. This mean that UAC comes from local area and gateways<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">are on<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">internet.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The local interface (eth0) ip is not reachable from internet.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Opensips server can traverse the nat using add_local_rport(), can<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">mediaproxy do the same ?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Giuseppe Roberti<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><<a href="mailto:jnod@jnod.org">jnod@jnod.org</a>><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote></div></blockquote></div><br></div></body></html>