I can only concur with you.
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.
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.
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.
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.
I wish everyone who starts a SIP business for scratch does not make
the mistakes many did in the hype VoIP era.
Adrian
On Dec 11, 2008, at 9:36 AM, Brett Nemeroff wrote:
Having a single point of connectivity to the customer, topology
masking, and potentially CALEA compliance. You can get by without
it.. It's a matter of preference of sorts. Some people have more luck
with nat traversal with them. I'd being interested in hearing other's
experiences with them.
On the other hand, it IS a fixed bottleneck. I can't tell you how many
times I've had a provider's overloaded SBC kill the QOS on my calls..
-Brett
On Thu, Dec 11, 2008 at 2:25 AM, Adrian Georgescu <[EMAIL PROTECTED]
projects.com> wrote:
Robert,
NAT traversal is solved by OpenSIPS/MediaProxy combination for both
signalling and media. Cost is important for an operator and any
intermediate
like an SBC, which does not bring any value to end customer is not
likely to
remain there for long.
What I am trying to figure out is if there are other good reasons
besides
the NAT issue for which the insertion of the SBC justifies its cost
for an
operator.
Regards,
Adrian
On Dec 11, 2008, at 2:02 AM, Robert Dyck wrote:
You are right, these terms are used in a rather casual manner. Also
privacy
and security can never be absolute. However there are reasons why an
individual or organization may want to hide their topology. Those
with bad
intentions may look for clues so that they may subvert the system.
Perhaps a stronger case can be made when we consider that NAT is
perhaps the
biggest headache with SIP. Different service providers have
different ideas
how they might overcome the problem. If a UA on a LAN or an
extension on a
PBX appears as a simple UA with a public address then the chance of
success
improves.
OpenSBC may be the way to go. It will act as a proxy or B2BUA. The
nice
thing
about OpenSIPS is its light weight if you don't need a lot of
modules. I am
not a programmer but it seems to me that it would not be too
difficult to
hide the private VIAs and CONTACTs. It already supports mediaproxy/
rtpproxy.
On Wednesday 10 December 2008, Adrian Georgescu wrote:
Robert,
Could you expand on what you mean by:
1. Privacy
2. Extra security
These seem to be highly abused terms while there is no proper
description available of what they mean and for whom they provide the
benefit.
Adrian
On Dec 10, 2008, at 9:32 PM, Robert Dyck wrote:
I see a need for a very basic proxy-like B2BUA. This would
completely hide the
local topology. This would provide privacy and extra security as
well as
working around the bad behaviour of some service providers.
Rob
On Wednesday 10 December 2008, Brett Nemeroff wrote:
For what it's worth, I've had problems doing this with some [broken]
carriers. Namely they see a private address in one of the Vias and
they assume it's NAT.. Pretty messy. If you look through the archive
you'll see what happened to me.
That being said, I think it's pretty unusual that this happens.
-Brett
On Wed, Dec 10, 2008 at 8:14 AM, Giuseppe Roberti <[EMAIL PROTECTED]>
wrote:
Hi.
I have an opensips server running "between" a man local area and
internet. This mean that UAC comes from local area and gateways
are on
internet.
The local interface (eth0) ip is not reachable from internet.
Opensips server can traverse the nat using add_local_rport(), can
mediaproxy do the same ?
Regards.
--
Giuseppe Roberti
<[EMAIL PROTECTED]>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
