SS7 + T1 on Asterisk?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



E1 0th channel is framing and alarm. On T1 framing and alarm uses extra 
8kbps (T1 raw speed is 64*24+8=1544 kbps).
Signaling on E1 usually goes on TS 16, for MFC R2 and ISDN. ISUP 
signaling can go on any TS.

Unfortunately SIGTRAN is not supported by any Asterisk SS7 we discuss 
here (if any at all). Before supporting SIGTRAN, it would be useful for 
many libss7 users to get full ss7 signaling routing (allowing a pair of 
signaling likes to 1 or 2 STPs to access dozens of switches, with proper 
failover handling). That's much simpler to implement than SIGTRAN.

Here in Brazil, all interconnects with land line carriers are done 
exclusively with E1, since we need the E1 for voice, the only cost is 
taking one TS for signaling.

Apparently cell phone carriers here allow for SS7 over IP interconnects, 
but then you need full IP interconnects, including supporting their 
voice codecs (gsm half rate, gsm full rate, enhanced full rate, 3g voice 
codecs). Voice is then transferred using RTP/IP. Asterisk is very far 
from being able to support that, even if you disregard the codecs other 
than gsm full rate which aren't supported with Asterisk.

Usually any soft switch which is able to interconnect using pure IP SS7 
is also able to talk SIP and/or H.323.

On 12/10/11 09:06, Michael Mueller wrote:
> On Sat, Dec 10, 2011 at 12:11 AM, Paul Timmins<paul at timmins.net>  wrote:
>> My switch does SS7 over T1 timeslots, but only supports 56k. I'd imagine
>> it's because DDS modems were used over copper pair for the original links,
>> and 56k timeslots are how DDS is transported over a T1. (Yes, you can have
>> 64k DDS links, but I've never seen em)
> 56 kb/s channel speeds in T1 comes from
> http://en.wikipedia.org/wiki/Robbed-bit_signaling
>
> in E carriers, the signaling was carried in the 0th channel and that
> why only 31 channels are available instead of 32
>
> robbery in both E and T
>
>> Also, the number of voice channels you can run over 56k SS7 links is
>> limitless, the call setup and teardown is what matters, not the number of
>> standing calls.
> voice channels supported between two unique point code pairs is
> limited by the size of the CIC field:
>
> // ITU
> ../common/ckt_def.h:#define MAX_CIC                             4095
> // (2^12)-1
> // ANSI
> ../common/ckt_def.h:#define MAX_CIC                             16383
> // (2^14)-1
>
> call setup/teardown rate depends on bandwidth of the linkset
>
> each link in the linkset is 64 kb/s or 8kB/s; running at 40% max
> utilization 3200 B/s; each call is estimated to be 160 B = (80 B IAM +
> 4*20 B ACM/ANS/REL/RLC)); 3200/160 = 20 calls per second
>
>> But I wanted to point out here that nothing stops you from using ANSI SS7
>> the same way you describe ITU SS7, there's technically nothing more or less
>> efficient about it. In fact, the north american setup is actually more
>> efficient, because you can signal an entire network over two 56k links to
>> your matched STP pairs, and that's all you need. I'm signaling trunks to
>> something like 10 tandems, with some trunkgroups as large as 20 DS1s,  in 4
>> LATAs over just two redundant 56k links to one STP pair. Contrast that to
>> your individual links per trunkgroup and tell me what's more efficient.
> The ANSI network evolved to serve a much larger network than the PTT
> networks using ITU networks.  I'd argue that meshing makes more sense
> for interconnecting many independent networks, and hub/spoke works
> well for a large monopoly needing to defend its position.
>
> A links to the hub/spoke network are expensive for small operators and
> have the effect of stifling low end competition.  SIGTRAN access
> didn't offer any cost advantages to operators in A link markets.
>
>> -Paul
>>
>>
>>
>> On Dec 9, 2011, at 3:57 PM, Marcelo Pacheco wrote:
>>
>> Typical North America SS7 signaling links use a dedicated v.35 link. STPs
>> and switches come with V.35 interfaces for signaling instead of using T1
>> timeslots.
>> Today the US basic digital links are 56kbps, I think 64kbps links never
>> caught up, due to RBS signalling.
>> In some ways, the North America way of doing things is much less efficient,
>> but its the way its done.
>> The true reason traces back to old times, when signaling links ran on
>> separate analog modems, and voice trunks were still analog, and signaling
>> links might run at 2400bps or lower speeds ! Those links were terminated to
>> the switches using v.35 interfaces, and speeds moved up to 56kbps, still
>> using those v.35 interfaces. The advantage is the same physical interface
>> can run at higher speeds (56kbps - 1544kbps and in between).
>>
>> In telco interconnect scenarios, multiples of two 56kbps links are used.
>> Usually between a pair of STPs on both sides, a small interconnect could
>> start with just two links, growing to four links. 4x56kbps links are
>> typically enough for around 4000 voice channels, even considering a 50%
>> failure.
>>
>> That contrasts with the extensive utilization of semi permanent digital
>> calls, using 64kbps timeslots on E1 land.
>> E1 land makes it so much easier. Just take time slot 16 of an already
>> existing voice trunks, and switch those time slots to STPs on both sides.
>> This makes the transport network a lot easier, interconnections only need E1
>> links between TDM switches, and on each side each TDM switch uses time slots
>> on existing E1 links to STPs.
>>
>> The term SS7 on BRI makes no sense. BRI lines are 144kbps (2x64kbps bearer
>> channels + 16kbps signaling link). Those are never used as SS7 transports.
>> BRI lines are switch to end user facilities, BRI lines never run between
>> carrier switches or STPs.
>>
>> Thanks for listening to my history lesson, useless rant.
>>
>> Marcelo
>>
>> On 12/09/11 15:36, Jan Berger wrote:
>>
>> http://en.wikipedia.org/wiki/Digital_Signal_1
>>
>> I believe it's BRI lines that uses 56kbps and your right that SS7 on BRI
>> have some usage in US.
>>
>> Jan
>>> Date: Wed, 7 Dec 2011 20:12:22 -0200
>>> From:marcelo at m2j.com.br
>>> To:asterisk-ss7 at lists.digium.com
>>> Subject: Re: [asterisk-ss7] SS7 + T1 on Asterisk?
>>>
>>> Typically T1 (american) signaling ss7 links run at 56kbps instead of
>>> 64kbps.
>>> If your switch can run 64kbps links over a T1 timeslot, than the only
>>> remaining variable is ITU versus ANSI ISUP. They are incompatible
>>> (different message formats due to different network address sizes and
>>> other details).
>>> We use ITU ISUP all over the place without trouble. If the switch can do
>>> 64kbps links and ITU ISUP, then you should be able to use all existing
>>> E1 direct connection samples (without STP), except for the obvious E1=31
>>> timeslots while T1=24 timeslots difference..
>>> ANSI might work. I won't go there because I have zero experience with
>>> ANSI SS7/ISUP (stability wise).
>>> With 2 T1 and a single signaling link it should allow for 47 voice
>>> channels and one signaling link.
>>>
>>> Search for libss7 ansi 56kbps for the most difficult scenario. But if
>>> you can do ITU ISUP + 64kbps links, I would suggest that instead.
>>> We hardly see people talking about ANSI ISUP setups on this list, so it
>>> could be far less stable (at least it seems to get less usage).
>>>
>>> On 12/07/11 16:25, Matt wrote:
>>>> In this case, our supplier is ourselves. We have a DMS100, but the
>>>> switch guy is someone other than myself - I am the IP guy.
>>>>
>>>> So basically if I understand you properly, I should be able to do the
>>>> SS7+T1 and get proper operation, provided the configuration on both
>>>> sides is right.
>>>>
>>>> On Wed, Dec 7, 2011 at 1:06 PM, Marcelo Pacheco<marcelo at m2j.com.br>
>>>> wrote:
>>>>> If the DMS100 switch can talk signalling directly with Asterisk,
>>>>> without an
>>>>> STP, it should be possible to use a single timeslot for ss7 signalling,
>>>>> so
>>>>> with 2 T1 you could have 47 voice calls and one signalling channel.
>>>>> This is
>>>>> common with E1 setups. Also with E1 its common for a timeslot to be
>>>>> statically switched over to an STP (semi permanent call), allowing for
>>>>> access to the signaling network without a dedicated physically separate
>>>>> signaling link, but that's not usual in T1 land.
>>>>>
>>>>> But what you ask is technically possible... However its important to
>>>>> PROPERLY LEARN SS7 terms to be able to communicate with your supplier.
>>>>> SS7 is a CARRIER LEVEL PROTOCOL. However people insist on winging it
>>>>> without
>>>>> proper training.
>>>>> Its like trying to become a backbone internet provider without properly
>>>>> learning inter and intra network routing protocols (like BGP and OSPF).
>>>>>
>>>>> If you knew the general SS7/ISUP knowledge, you could quickly find the
>>>>> information you're looking for on Google.
>>>>>
>>>>> PS: I live in E1 land... I'm just quoting information from the top of
>>>>> my
>>>>> head. I have no need for T1+SS7. E1+SS7 is a little simpler with
>>>>> Asterisk
>>>>> than T1+SS7 due to 56kbps data links, ANSI ISUP/SS7 and some other
>>>>> quirks.
>>>>>
>>>>> Good luck. You'll need it.
>>>>>
>>>>>
>>>>> On 12/07/11 14:47, Matt wrote:
>>>>>> If I were to get a 2 span T1 card for Asterisk... and connect it to a
>>>>>> Nortel DMS100... can I run call traffic over the T1 and run SS7
>>>>>> signaling FOR the T1 over the other port?
>>>>>>
>>>>>> Is there documentation on doing this anywhere?
>>>>>>
>>>>>> --
>>>>>> _____________________________________________________________________
>>>>>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>>>>>
>>>>>> asterisk-ss7 mailing list
>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>>>>>
>>>>> --
>>>>> _____________________________________________________________________
>>>>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>>>>
>>>>> asterisk-ss7 mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>>> --
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>>>
>>>> asterisk-ss7 mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>>
>>> asterisk-ss7 mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>
>> asterisk-ss7 mailing list
>> To UNSUBSCRIBE or update options visit:
>>     http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>
>> asterisk-ss7 mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>>
>> asterisk-ss7 mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-ss7
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-ss7
>




[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux