[asterisk-ss7] SS7 + T1 on Asterisk?

Sat Dec 10 05:06:07 CST 2011

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 by http://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 by http://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 by http://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 by http://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 by http://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 by http://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 by http://www.api-digital.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-ss7