[asterisk-ss7] Combined linksets and mtp3d

[German Becker]

Thanks Michael, but this is not possible in our scenario: A1 and A2 are in
different locations and stp1 only connects to a1 and stp2 only connect to
a2. I guess I will need some custom development...

On Thu, Jan 12, 2012 at 20:26, Michael Mueller <ss7box at gmail.com> wrote:

>
> Better chance of working without doing additional development. ssp to stp1
> would be primary. ssp to stp2 would be alternative.
>
> A1------------stp1----------ssp
>  |                 |               |
>  |         +-----+              |
>  |         |                      |
> +---------------+               |
>           |       |                |
>  +------+       |                |
>  |                |                |
> A2------------stp2-----------+
>
>
> On Thu, Jan 12, 2012 at 9:50 AM, German Becker <german.becker at gmail.com>wrote:
>
>> HI Michael, thanks for the reply. By hosts I mean asterisk boxes, that
>> would make them SSPs Both of them are connected with one signalling link to
>> one STP (different STP for each host) wich in turn will connect to the
>> destination STP(s). I'll try to sketch the scenario
>>
>> -------------
>> | Asterisk1 |--voice trunks-
>> | mtp3d     |----------------|STP 1|----------|SSP| (destination point
>> code)
>> -------------                            /
>>     | (tcp)                             /
>> ------------                           /
>> |Asterisk2  |--voice trunks           /
>> |mtp3d      |----------------|STP 2|--
>> ------------
>>
>> As for the variant. it is ITU. And weather it would be primary/alternate
>> or "load balanced" is under discussion with the connected party. However
>> load bancing is a possibility.
>>
>> What I would like to achieve is for incomming messages, both mtp3d route
>> them to the corresponding host (according to cic and ord opc); and for
>> outgoing messages, each asterisk deceide on which link (or linkset) send
>> it.
>>
>> I thought something like these could be achieved, based on this part of
>> the below(l4isuop.c), However, I don't get how should i configure it.
>>
>>     switch (link->linkset->loadshare) {
>>         case LOADSHARE_NONE:
>>             if (!link->schannel.mask)
>>                 slink = link;
>>             break;
>>         case LOADSHARE_LINKSET:
>>             if (linkset->n_slinks)
>>                 slink = linkset->slinks[cic % linkset->n_slinks];
>>             break;
>>         case LOADSHARE_COMBINED_LINKSET:
>>             {
>>                 int n_slinks = 0;
>>                 int six;
>>                 for (lsi = 0; lsi < n_linksets; lsi++)
>>                     if (linksets[lsi].enabled)
>>                         if (&linksets[lsi] == linkset ||
>>                                 (is_combined_linkset(linkset,
>> &linksets[lsi])))
>>                             n_slinks += linksets[lsi].n_slinks;
>>                 if (n_slinks) {
>>                     six = cic % n_slinks;
>>                     n_slinks = 0;
>>                     for (lsi = 0; lsi < n_linksets; lsi++)
>>                         if (linksets[lsi].enabled)
>>                             if (&linksets[lsi] == linkset ||
>>                                     (is_combined_linkset(linkset,
>> &linksets[lsi]))) {
>>                                 if (six - n_slinks <
>> linksets[lsi].n_slinks) {
>>                                     slink = linksets[lsi].slinks[six -
>> n_slinks];
>>                                     break;
>>                                 }
>>                                 n_slinks += linksets[lsi].n_slinks;
>>                             }
>>                 }
>>             }
>>             break;
>>     }
>>
>>
>>
>> On Thu, Jan 12, 2012 at 11:29, Michael Mueller <ss7box at gmail.com> wrote:
>>
>>> are those 2 "hosts" STPs or SSPs? what you describe could be a combined
>>> linkset if connected to STPs and using ANSI SS7; if using ITU then this
>>> might be a primary/alternate linkset scenario; my experience says the
>>> combined linkset concept exists in ANSI SS7 and not in ITU
>>>
>>> On Thu, Jan 12, 2012 at 8:15 AM, German Becker <german.becker at gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a scenario with 2 hosts, 2 links on each host, one of the links
>>>>  with signaling on each host and the DPC for all the voice TS reachable
>>>> through both signaling links.
>>>>
>>>> I'm not sure if I need to create a single linkset with two signaling
>>>> links on it (one per host), or two combined linksets.
>>>> I tried the 2 links aproach, but when one of the links is down (i.e.
>>>> asterisk lose connection with the remote mtp3d), all the TS are set to
>>>> block, instead of singnaling through the other link.
>>>>
>>>> Has anyone set up a similar scenario?
>>>>
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20120113/33b3bef9/attachment.htm>