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
|