[OpenSIPS-Users] OpenSip SIP, SIP-I e SIP-T

[Adrian Georgescu]

So far SIP-T occurred sporadically on this mailing list. I simply try  
identify the relevance of it in this context do not take personally mu  
comments.

On Feb 19, 2009, at 10:39 PM, Alex Balashov wrote:

> The problem is that outside of the VoIP cottage industry, this stuff  
> isn't "legacy" by any stretch of the imagination, in any way, shape,  
> or form.  We're just used to fancifully imagining that it is.
>
> Adrian Georgescu wrote:
>
>> Hm,
>> It is very hard to judge the benefits of performing all the nice to  
>> have feature at a higher level protocol while still having to  
>> support legacy expensive infrastructure underneath.
>> Now, last time I heard about SIP-T was by an ECMA standard a few  
>> years ago. ECMA is a sort of inverse pyramid European standards  
>> body that nobody listens to. Basically, they are sponsored by  
>> vendors to endorse 'standards' because they posses an EU stamp. The  
>> word here in Europe goes that if something went to the extent of  
>> geting an ECMA official endorsement, one knows that it is a  
>> standard with no future and no company invests in it anymore.
>> Maybe I am wrong and this has much more sense in the US.
>> Adrian
>> On Feb 19, 2009, at 8:43 PM, Alex Balashov wrote:
>>> To expand on this just a little bit:
>>>
>>> While here in the VoIP cottage industry we mostly deal with SIP to  
>>> begin with, in that we use ISDN gateways for connecting to  
>>> carriers, get SIP trunking from our carriers/ITSPs, and so on, the  
>>> reality is that most stuff in the PSTN carrier space is still done  
>>> with big-iron TDM equipment, at least here in the US.  If you want  
>>> to be a competitive carrier, you *must* interconnect with the  
>>> incumbent telco using SS7;  no ands, buts, ors.
>>>
>>> That doesn't mean there aren't a lot of opportunities to deploy  
>>> SIP internally inside the service delivery core.  The main benefit  
>>> SIP provides there is that it is so high-level and easy to  
>>> manipulate.  As a result, a lot of mediation, logging, billing,  
>>> analysis, translation, LCR  can be done easily and inexpensively.   
>>> Before SIP and H.323 came along, doing this kind of stuff required  
>>> a box that did all that and spoke SS7 or, at the very least ISDN Q. 
>>> 931, and that is much more expensive, inflexible, and difficult to  
>>> manipulate.
>>>
>>> Promoting this traffic to a higher-level protocol stack that has  
>>> more applications and tools to deal with it allows the development  
>>> of solutions for doing sophisticated telco-world stuff using  
>>> commodity hardware and open methodologies, open-source style.   
>>> That has triggered a wave of new products and paradigms in the  
>>> telco space in a way that is analogous to how Asterisk et al have  
>>> revolutionised the PBX space.
>>>
>>> One example of this is TransNexus' NexOSS/NexSRS product (www.transnexus.com 
>>>  <http://www.transnexus.com>).  They use the OSP (Open Settlement  
>>> Protocol) module for OpenSER and/or for Asterisk (depending on  
>>> whether a B2BUA is required) internally inside their product to  
>>> perform a lot of neat AAA and routing functions (e.g. the NexSRS  
>>> route server).  Their ability to do this benefits precisely from  
>>> the fact that the traffic can be moved onto a higher-level  
>>> protocol plane and away from proprietary, expensive, closed and  
>>> inflexible stuff that has been a defining feature of the telco  
>>> world.  If you can turn the traffic into SIP or H.323, they can  
>>> deal with it, but if it's SS7 or PRI, they can't.  The world is  
>>> going more "soft[ware]."
>>>
>>> At the same time, the telco space is not a SIP world right now;   
>>> the network edges are still SS7, and the market really hasn't  
>>> settled on a good private SIP interconnection/peering strategy and  
>>> implementation for intercarrier settlement. So, for the most part  
>>> SIP trunking is used for customer access only.  The SS7  
>>> information must be conserved in this type of setup, and that's  
>>> one of the reasons the sort of thing that SIP-T is exists.
>>>
>>> Alex Balashov wrote:
>>>
>>>> Adrian Georgescu wrote:
>>>>> Why should SIP-T still exist? Is it cheaper than having a  
>>>>> gateway? What is the practical use case for investing in such  
>>>>> technology?
>>>>>
>>>>> I am eager to learn
>>>> We've used it extensively in work with CLECs that operate TDM  
>>>> switches such as the Metaswitch, Lucent LCS/Telica, etc.
>>>> When a carrier operates more than one switch, SS7 interconnection  
>>>> between them is generally required so, for the same basic reasons  
>>>> an internal iBGP mesh or partial mesh (confederation) between two  
>>>> border routers is required for IP.   One switch must be aware of  
>>>> numbers routed or ported into the other switch, and so on.
>>>> The reason for its existence is that if both network elements  
>>>> support SIP-T, it allows you to replace an SS7 IMT (inter-machine  
>>>> trunk) with an IP-based mechanism for this interconnection.  This  
>>>> allows you to move the traffic over a data network and get all  
>>>> the benefits that this brings;  economies of scale through  
>>>> decreased facilities, oversubscription, etc.  The main benefit is  
>>>> the elimination of TDM trunk exhaust;  SS7 IMTs are physically  
>>>> bundles (trunk groups/TCICs) of DS0s, usually consisting of one  
>>>> or more T1s, and sometimes DS3s or more.  That means that when a  
>>>> large volume of calls is running between the two switches, you  
>>>> could burn up all your SS7 trunks.  Running the calls as SIP-T  
>>>> allows you to use something like a gigabit network core to make  
>>>> that problem go away somewhat -- a key benefit of VoIP in most  
>>>> other scenarios with which you are familiar with.
>>>> At the same time, the switches still need ISUP attributes carried  
>>>> in SS7 IAMs and ACMs for billing, because that's just the  
>>>> information they operate on internally.  SIP-T provides an IP- 
>>>> based way to encapsulate that information.
>>>> SIGTRAN (essentially, SS7-over-IP) is another way to do this.   
>>>> However, SIP-T is lightweight and easier to deploy.  It also  
>>>> allows you to use existing SIP network elements (proxies, session  
>>>> border controllers, etc.) to route and manage the traffic.   For  
>>>> example, if you were using OpenSIPS + ACC + FreeRADIUS as a CDR  
>>>> catcher, you could run the "SS7" calls between two switches and  
>>>> log the appropriate information as custom attributes.  There are  
>>>> no good open-source implementations for SIGTRAN - nothing as turn- 
>>>> key as Kamailio or OpenSIPS.  SIP is high-level and much easier  
>>>> to deal with and manipulate using a far wider range of tools.
>>>> SIP-T is also becoming an attractive external interconnect option.
>>>
>>>
>>> -- 
>>> Alex Balashov
>>> Evariste Systems
>>> Web    : http://www.evaristesys.com/
>>> Tel    : (+1) (678) 954-0670
>>> Direct : (+1) (678) 954-0671
>>> Mobile : (+1) (678) 237-1775
>
>
> -- 
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (678) 237-1775

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