OpenSip SIP, SIP-I e SIP-T

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSip SIP, SIP-I e SIP-T

Daviramos Roussenq Fortunato
Hi List.

  I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens is that?
How should be my opensip.cfg?
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
Not possible, Asterisk doesn't understand SIP-T.

What do you mean by that, anyway?  Only a device that supports ISUP
interworking will support SIP-T.

Secondly, as is often repeated here, SIP-T is a specification for a
_PAYLOAD_ - an extension - of SIP.  It is not a different protocol.

Daviramos Roussenq Fortunato wrote:

> Hi List.
>
>   I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
> is that?
> How should be my opensip.cfg?
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Daviramos Roussenq Fortunato
Hi Alex.

If a different protocol is not to say that you can connect directly to Asterisk and will work, just taking the resources of ISUP?

SIP-T is not talking with SIP protocol are different, after all SIP-T carries information that the SIP can not interpret.

The Problem is the following I get a SIP-T trunk and Asterisk to deliver precise, how best to do.

2009/2/19 Alex Balashov <[hidden email]>
Not possible, Asterisk doesn't understand SIP-T.

What do you mean by that, anyway?  Only a device that supports ISUP interworking will support SIP-T.

Secondly, as is often repeated here, SIP-T is a specification for a _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.

Daviramos Roussenq Fortunato wrote:

Hi List.

 I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens is that?
How should be my opensip.cfg?


------------------------------------------------------------------------

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
SIP-T *is* SIP.  Anything that processes SIP can "interpret" the SIP
part.  What it can't do is interpret the SIP-T part, so it's passed
through, ignored, or stripped, depending on what type of SIP agent it
is.  If it's a proxy (like OpenSIPS), it's conservative and passes
everything it receives in terms of message bodies and additional
parameters.  If it's a B2BUA, who knows.

Daviramos Roussenq Fortunato wrote:

> Hi Alex.
>
> If a different protocol is not to say that you can connect directly to
> Asterisk and will work, just taking the resources of ISUP?
>
> SIP-T is not talking with SIP protocol are different, after all SIP-T
> carries information that the SIP can not interpret.
>
> The Problem is the following I get a SIP-T trunk and Asterisk to deliver
> precise, how best to do.
>
> 2009/2/19 Alex Balashov <[hidden email]
> <mailto:[hidden email]>>
>
>     Not possible, Asterisk doesn't understand SIP-T.
>
>     What do you mean by that, anyway?  Only a device that supports ISUP
>     interworking will support SIP-T.
>
>     Secondly, as is often repeated here, SIP-T is a specification for a
>     _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.
>
>     Daviramos Roussenq Fortunato wrote:
>
>         Hi List.
>
>          I have a trunk SIP-T must deliver it to the Asterisk in SIP.
>         The Opens is that?
>         How should be my opensip.cfg?
>
>
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         Users mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>     --
>     Alex Balashov
>     Evariste Systems
>     Web    : http://www.evaristesys.com/
>     Tel    : (+1) (678) 954-0670
>     Direct : (+1) (678) 954-0671
>     Mobile : (+1) (678) 237-1775
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Brett Nemeroff
In reply to this post by Daviramos Roussenq Fortunato
From what I understand about SIP-T it's SIP + ISUP params in the
message. The required bits such as RURI and SDP all work as expected.

Group, feel free to correct me there. Depending on your specific setup
and network architecture, it should work. However, you may not be able
to do anything with the ISUP components of the messaging.

-Brett



On Thu, Feb 19, 2009 at 11:14 AM, Daviramos Roussenq Fortunato
<[hidden email]> wrote:

> Hi Alex.
>
> If a different protocol is not to say that you can connect directly to
> Asterisk and will work, just taking the resources of ISUP?
>
> SIP-T is not talking with SIP protocol are different, after all SIP-T
> carries information that the SIP can not interpret.
>
> The Problem is the following I get a SIP-T trunk and Asterisk to deliver
> precise, how best to do.
>
> 2009/2/19 Alex Balashov <[hidden email]>
>>
>> Not possible, Asterisk doesn't understand SIP-T.
>>
>> What do you mean by that, anyway?  Only a device that supports ISUP
>> interworking will support SIP-T.
>>
>> Secondly, as is often repeated here, SIP-T is a specification for a
>> _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.
>>
>> Daviramos Roussenq Fortunato wrote:
>>
>>> Hi List.
>>>
>>>  I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
>>> is that?
>>> How should be my opensip.cfg?
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> --
>> Alex Balashov
>> Evariste Systems
>> Web    : http://www.evaristesys.com/
>> Tel    : (+1) (678) 954-0670
>> Direct : (+1) (678) 954-0671
>> Mobile : (+1) (678) 237-1775
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
That is accurate.

Brett Nemeroff wrote:

> From what I understand about SIP-T it's SIP + ISUP params in the
> message. The required bits such as RURI and SDP all work as expected.
>
> Group, feel free to correct me there. Depending on your specific setup
> and network architecture, it should work. However, you may not be able
> to do anything with the ISUP components of the messaging.
>
> -Brett
>
>
>
> On Thu, Feb 19, 2009 at 11:14 AM, Daviramos Roussenq Fortunato
> <[hidden email]> wrote:
>> Hi Alex.
>>
>> If a different protocol is not to say that you can connect directly to
>> Asterisk and will work, just taking the resources of ISUP?
>>
>> SIP-T is not talking with SIP protocol are different, after all SIP-T
>> carries information that the SIP can not interpret.
>>
>> The Problem is the following I get a SIP-T trunk and Asterisk to deliver
>> precise, how best to do.
>>
>> 2009/2/19 Alex Balashov <[hidden email]>
>>> Not possible, Asterisk doesn't understand SIP-T.
>>>
>>> What do you mean by that, anyway?  Only a device that supports ISUP
>>> interworking will support SIP-T.
>>>
>>> Secondly, as is often repeated here, SIP-T is a specification for a
>>> _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.
>>>
>>> Daviramos Roussenq Fortunato wrote:
>>>
>>>> Hi List.
>>>>
>>>>  I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
>>>> is that?
>>>> How should be my opensip.cfg?
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> --
>>> Alex Balashov
>>> Evariste Systems
>>> Web    : http://www.evaristesys.com/
>>> Tel    : (+1) (678) 954-0670
>>> Direct : (+1) (678) 954-0671
>>> Mobile : (+1) (678) 237-1775
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Brett Nemeroff
One question that I'm not sure of.. Are there any extensions in epru
SIP-T that specify remote interface to use, such as used in
H.248/Megaco? ie: dial 123 on TCIC 000010012
-Brett


On Thu, Feb 19, 2009 at 11:27 AM, Alex Balashov
<[hidden email]> wrote:

> That is accurate.
>
> Brett Nemeroff wrote:
>
>> From what I understand about SIP-T it's SIP + ISUP params in the
>> message. The required bits such as RURI and SDP all work as expected.
>>
>> Group, feel free to correct me there. Depending on your specific setup
>> and network architecture, it should work. However, you may not be able
>> to do anything with the ISUP components of the messaging.
>>
>> -Brett
>>
>>
>>
>> On Thu, Feb 19, 2009 at 11:14 AM, Daviramos Roussenq Fortunato
>> <[hidden email]> wrote:
>>>
>>> Hi Alex.
>>>
>>> If a different protocol is not to say that you can connect directly to
>>> Asterisk and will work, just taking the resources of ISUP?
>>>
>>> SIP-T is not talking with SIP protocol are different, after all SIP-T
>>> carries information that the SIP can not interpret.
>>>
>>> The Problem is the following I get a SIP-T trunk and Asterisk to deliver
>>> precise, how best to do.
>>>
>>> 2009/2/19 Alex Balashov <[hidden email]>
>>>>
>>>> Not possible, Asterisk doesn't understand SIP-T.
>>>>
>>>> What do you mean by that, anyway?  Only a device that supports ISUP
>>>> interworking will support SIP-T.
>>>>
>>>> Secondly, as is often repeated here, SIP-T is a specification for a
>>>> _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.
>>>>
>>>> Daviramos Roussenq Fortunato wrote:
>>>>
>>>>> Hi List.
>>>>>
>>>>>  I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
>>>>> is that?
>>>>> How should be my opensip.cfg?
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>> --
>>>> Alex Balashov
>>>> Evariste Systems
>>>> Web    : http://www.evaristesys.com/
>>>> Tel    : (+1) (678) 954-0670
>>>> Direct : (+1) (678) 954-0671
>>>> Mobile : (+1) (678) 237-1775
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (678) 237-1775
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Adrian Georgescu
For my understanding. Translating ISUP into SIP signalling is usually done in a gateway. Carrying ISUP within SIP defies the reason for the existence of both protocols. Is like using SMTP to carry web pages or vice versa. Or storing MP3 in the DNS.

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

Adrian


On Feb 19, 2009, at 6:30 PM, Brett Nemeroff wrote:

One question that I'm not sure of.. Are there any extensions in epru
SIP-T that specify remote interface to use, such as used in
H.248/Megaco? ie: dial 123 on TCIC 000010012
-Brett


On Thu, Feb 19, 2009 at 11:27 AM, Alex Balashov
<[hidden email]> wrote:
That is accurate.

Brett Nemeroff wrote:

From what I understand about SIP-T it's SIP + ISUP params in the
message. The required bits such as RURI and SDP all work as expected.

Group, feel free to correct me there. Depending on your specific setup
and network architecture, it should work. However, you may not be able
to do anything with the ISUP components of the messaging.

-Brett



On Thu, Feb 19, 2009 at 11:14 AM, Daviramos Roussenq Fortunato
<[hidden email]> wrote:

Hi Alex.

If a different protocol is not to say that you can connect directly to
Asterisk and will work, just taking the resources of ISUP?

SIP-T is not talking with SIP protocol are different, after all SIP-T
carries information that the SIP can not interpret.

The Problem is the following I get a SIP-T trunk and Asterisk to deliver
precise, how best to do.

2009/2/19 Alex Balashov <[hidden email]>

Not possible, Asterisk doesn't understand SIP-T.

What do you mean by that, anyway?  Only a device that supports ISUP
interworking will support SIP-T.

Secondly, as is often repeated here, SIP-T is a specification for a
_PAYLOAD_ - an extension - of SIP.  It is not a different protocol.

Daviramos Roussenq Fortunato wrote:

Hi List.

I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
is that?
How should be my opensip.cfg?



------------------------------------------------------------------------

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
In reply to this post by Brett Nemeroff
Any standard ISUP attribute has a corresponding map into SIP-T.  So,
yes, any bearer-related information is going to be in there as well.

Brett Nemeroff wrote:

> One question that I'm not sure of.. Are there any extensions in epru
> SIP-T that specify remote interface to use, such as used in
> H.248/Megaco? ie: dial 123 on TCIC 000010012
> -Brett
>
>
> On Thu, Feb 19, 2009 at 11:27 AM, Alex Balashov
> <[hidden email]> wrote:
>> That is accurate.
>>
>> Brett Nemeroff wrote:
>>
>>> From what I understand about SIP-T it's SIP + ISUP params in the
>>> message. The required bits such as RURI and SDP all work as expected.
>>>
>>> Group, feel free to correct me there. Depending on your specific setup
>>> and network architecture, it should work. However, you may not be able
>>> to do anything with the ISUP components of the messaging.
>>>
>>> -Brett
>>>
>>>
>>>
>>> On Thu, Feb 19, 2009 at 11:14 AM, Daviramos Roussenq Fortunato
>>> <[hidden email]> wrote:
>>>> Hi Alex.
>>>>
>>>> If a different protocol is not to say that you can connect directly to
>>>> Asterisk and will work, just taking the resources of ISUP?
>>>>
>>>> SIP-T is not talking with SIP protocol are different, after all SIP-T
>>>> carries information that the SIP can not interpret.
>>>>
>>>> The Problem is the following I get a SIP-T trunk and Asterisk to deliver
>>>> precise, how best to do.
>>>>
>>>> 2009/2/19 Alex Balashov <[hidden email]>
>>>>> Not possible, Asterisk doesn't understand SIP-T.
>>>>>
>>>>> What do you mean by that, anyway?  Only a device that supports ISUP
>>>>> interworking will support SIP-T.
>>>>>
>>>>> Secondly, as is often repeated here, SIP-T is a specification for a
>>>>> _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.
>>>>>
>>>>> Daviramos Roussenq Fortunato wrote:
>>>>>
>>>>>> Hi List.
>>>>>>
>>>>>>  I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
>>>>>> is that?
>>>>>> How should be my opensip.cfg?
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> [hidden email]
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>> --
>>>>> Alex Balashov
>>>>> Evariste Systems
>>>>> Web    : http://www.evaristesys.com/
>>>>> Tel    : (+1) (678) 954-0670
>>>>> Direct : (+1) (678) 954-0671
>>>>> Mobile : (+1) (678) 237-1775
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> --
>> 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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
See:

http://tools.ietf.org/html/draft-jfp-sip-isup-header-00

Grep for "CIC" / "cic".

Alex Balashov wrote:

> Any standard ISUP attribute has a corresponding map into SIP-T.  So,
> yes, any bearer-related information is going to be in there as well.
>
> Brett Nemeroff wrote:
>
>> One question that I'm not sure of.. Are there any extensions in epru
>> SIP-T that specify remote interface to use, such as used in
>> H.248/Megaco? ie: dial 123 on TCIC 000010012
>> -Brett
>>
>>
>> On Thu, Feb 19, 2009 at 11:27 AM, Alex Balashov
>> <[hidden email]> wrote:
>>> That is accurate.
>>>
>>> Brett Nemeroff wrote:
>>>
>>>> From what I understand about SIP-T it's SIP + ISUP params in the
>>>> message. The required bits such as RURI and SDP all work as expected.
>>>>
>>>> Group, feel free to correct me there. Depending on your specific setup
>>>> and network architecture, it should work. However, you may not be able
>>>> to do anything with the ISUP components of the messaging.
>>>>
>>>> -Brett
>>>>
>>>>
>>>>
>>>> On Thu, Feb 19, 2009 at 11:14 AM, Daviramos Roussenq Fortunato
>>>> <[hidden email]> wrote:
>>>>> Hi Alex.
>>>>>
>>>>> If a different protocol is not to say that you can connect directly to
>>>>> Asterisk and will work, just taking the resources of ISUP?
>>>>>
>>>>> SIP-T is not talking with SIP protocol are different, after all SIP-T
>>>>> carries information that the SIP can not interpret.
>>>>>
>>>>> The Problem is the following I get a SIP-T trunk and Asterisk to deliver
>>>>> precise, how best to do.
>>>>>
>>>>> 2009/2/19 Alex Balashov <[hidden email]>
>>>>>> Not possible, Asterisk doesn't understand SIP-T.
>>>>>>
>>>>>> What do you mean by that, anyway?  Only a device that supports ISUP
>>>>>> interworking will support SIP-T.
>>>>>>
>>>>>> Secondly, as is often repeated here, SIP-T is a specification for a
>>>>>> _PAYLOAD_ - an extension - of SIP.  It is not a different protocol.
>>>>>>
>>>>>> Daviramos Roussenq Fortunato wrote:
>>>>>>
>>>>>>> Hi List.
>>>>>>>
>>>>>>>  I have a trunk SIP-T must deliver it to the Asterisk in SIP. The Opens
>>>>>>> is that?
>>>>>>> How should be my opensip.cfg?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>> --
>>>>>> Alex Balashov
>>>>>> Evariste Systems
>>>>>> Web    : http://www.evaristesys.com/
>>>>>> Tel    : (+1) (678) 954-0670
>>>>>> Direct : (+1) (678) 954-0671
>>>>>> Mobile : (+1) (678) 237-1775
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> --
>>> 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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
In reply to this post by Alex Balashov
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).  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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Adrian Georgescu
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).  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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Alex Balashov
Oh, I don't.  :)  I didn't take it that way.  I have no personal
investment in it whatsoever.

Just trying to help identify the relevance.

Adrian Georgescu wrote:

> 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>
>>>> <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
>


--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Jiri Kuthan
In reply to this post by Alex Balashov
So it is -- trunking, be it sigtran, SIP-T, SIP-I is in fact one
of the largest volume VoIP applications outthere. The key motivation is in
fact the IP transport, even though my personal choice is SIP-T on top of it
as well.

-jiri

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.
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSip SIP, SIP-I e SIP-T

Brett Nemeroff
In reply to this post by Alex Balashov
I think it's very relevant. SIP-T is very real.

I agree that, at least in the US CLEC market, SS7 isn't though of as
being legacy. But at the same time SIP interconnections arn't
completely absent. There are a few SIP Interconnection tariffs in the
works. There are, however, huge political barriers to preventing this
from happening. A lot of people would argue that these political
barriers are simply anti-competitive strategies on behalf of the
incumbents and don't bear any relevance to the quality of the
technology. Remember, a lot of the ISUP signaling is used for
inter-carrier compensation which is still, all over the board, a total
mess. So to suggest that you're going to flip that system, which is
horribly complicated on it's ear with a new protocol gets a lot of
feathers ruffled.

Hey look, if the ILEC allowed for SIP Interconnection, then anyone
would be able to start up their own phone company.. now we don't want
THAT do we? </sarcasm>

-Brett




On Thu, Feb 19, 2009 at 4:00 PM, Alex Balashov
<[hidden email]> wrote:

> Oh, I don't.  :)  I didn't take it that way.  I have no personal
> investment in it whatsoever.
>
> Just trying to help identify the relevance.
>
> Adrian Georgescu wrote:
>
>> 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>
>>>>> <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
>>
>
>
> --
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (678) 237-1775
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users