[OpenSIPS-Users] Old question about mediaproxy "bridge" mode between public and private networks

Adrian Georgescu ag at ag-projects.com
Thu Dec 11 09:54:07 CET 2008


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 <ag at ag- 
> 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 <jnod at jnod.org>
>>
>> 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
>>
>> <jnod at jnod.org>
>>
>> _______________________________________________
>>
>> Users mailing list
>>
>> Users at lists.opensips.org
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>>
>> Users mailing list
>>
>> Users at lists.opensips.org
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>>
>> Users mailing list
>>
>> Users at lists.opensips.org
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20081211/e8eb793c/attachment-0001.htm 


More information about the Users mailing list