Single Point Code across Multiple * Boxes.

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

 



> Yeah, that's probably going to be something we'll have to deal with.  A 
> lot of switches I have seen don't cross T1/E1 boundaries on group 
> messages, but Asterisk's SS7 implementation has situations where it does 
> cross T1/E1 boundaries on group messages.
> 

But I think not enough make the stuff for only the most switches have to
pass the tests. I have not found any limitation in the itu-t standards.
Btw would be better if we don't send any group messages overlapping the
E1/T1s.

> For A links, I think it won't be a problem though because the CICs
> are 
> going to line up correctly.  For F links (signaling and bearers on same 
> T1/E1) you'll have problems with lining up group messages with T1/E1 
> boundaries.
> 


> > When I have time I'll test your new stuff.
> 
> It's actually in the svn branches I posted earlier which contain 
> Domjan's changes... I'm going to have to merge those into trunk anyways, 
> I just haven't done it yet, so eventually they'll be in trunk.
> 
> http://svn.digium.com/svn/libss7/branches/mattf/bug13495
> 
> http://svn.digium.com/svn/asterisk/branches/mattf/bug13495
> 
> Matthew Fredrickson
> Digium, Inc.
> 
> > 
> > Regards,
> > Attila
> > 
> >> Well, to have a fully redundant setup, you would have separate boxes 
> >> terminating each signaling link.  These routing machines can masquerade 
> >> ISUP traffic over to other machines via IP protocol based links.  Each 
> >> of these IP connected boxes has an IP link to each box with a physical 
> >> signaling link.  If a machine with a physical link goes down, it reports 
> >> it to the IP links that are hooked up to it and the machines using those 
> >> IP links use their alternate IP links instead of that link, providing 
> >> for redundancy in times of link failure.
> >>
> >> There are going to be other problems to think about as well, but I think 
> >> that the basic logic is sound and will work.
> >>
> >> I actually just got masqueraded ISUP messages passing correctly back and 
> >> forth over IP, but I still have some technical hurdles as far as what to 
> >> do as IP links go in and out of service.  This list will definitely know 
> >> what I have something I'm interested in testing :-)
> >>
> >> Matthew Fredrickson
> >> Digium, Inc.
> >>
> >>
> >>
> >> _______________________________________________
> >> --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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-ss7/attachments/20090109/ea583605/attachment.pgp 


[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