[asterisk-ss7] Better than MGCP for controlling other Asterisks and Cisco

[Marcelo Pacheco]

Hello,

This is in reply to a fairly old e-mail from Matt Frederickson,
Dated Wed Sep 27 13:41:03 MST 2006
Subject: Libss7 Status Update

I managed to figure out most of the Cisco RLM protocol. It's actually 75%
documented on:

http://www.cisco.com/en/US/products/hw/vcallcon/ps2152/products_tech_note09186a0080226e14.shtml

It uses UDP port X for RLM, and UDP port X+1 for ISDN signalling
The idea is to treat all remote bearer channels as a ISDN NI2 NFAS bundle,
where the data channel is fed through UDP. RLM is used for redundancy, to
allow for 2 or more soft switches.

the sole purpose of RLM is so the NAS (Cisco GW) monitor the soft switch.

RLM is so simple, it's just:
struct rlm
{       uchar version; // Always version 2
        uchar type; //
        ushort unk1;
        ushort trx; // Transaction number, just increment between sent
packets, and send replies with the same number
        ushort pri; // Priority
} rlm;
#define RLM_START_REQ (0x01) //Used to initiate an RLM link. Only
generated by the NAS.
#define RLM_START_ACK (0x02) //Generated by the PGW 2200 to acknowledge
the start of an RLM link.
#define RLM_STOP_REQ (0x03)  //Generated by either the PGW 2200 or the NAS
to stop a link.
#define RLM_STOP_ACK (0x04)  //Acknowledgement to a stop request.
#define RLM_ECHO_REQ (0x05)  //Used by the NAS only to periodically ping
the PGW 2200 in order to verify link integrity. Used on both an active
link and all standby links.
#define RLM_ECHO_ACK (0x06)  //Acknowledgement of an echo request.
#define RLM_SWITCH_REQ (0x07) //Used to switch from a lower weighted
active RLM link to a higher weighted available link.
#define RLM_SWITCH_ACK (0x08) //Acknowledgement of a switch request.

When sending an echo ACK, reply pri = 1 if this should be the primary soft
switch, or pri = 2 or 3 if this is a secondary/tertiary soft switch.

It would be interesting to find out if Cisco has a patent on this before
proceeding. But it's such a simple protocol, it's essentially trivial, so
pretty much any heartbeat protocol works almost the same.


So we would have:

SS7 Link 1 -> Asterisk/SS7 capable Cisco -> RLM + ISUP -> soft switch
  -> RLM + ISDN NFAS over UDP connection to each NAS with bearer trunks

SS7 Link 2 -> Asterisk/ss7 Capable Cisco -> RLM + ISUP -> soft switch
  -> RLM + ISDN NFAS over UDP connection to each NAS with bearer trunks


This would allow Asterisk, or a separate soft switch process to become the
dchannel feeder for the remote GWs, which could also be Asterisks.

This way we could have an Asterisk soft switch, as a separate process from
regular Asterisks, having only to implement the RLM client into Asterisk
as it is, perhaps adding the capability of having only MTP2 built into
Asterisk, and MTP3+ISUP/other protocols processed on the soft switch. Not
sure where MTP3 is processed though.

>From what I heard, AS5350 can do RLM+MTP3 in a similar way.


I only have IMT capable Ciscos, I don't have the ability to test RLM+ISUP.

So I managed to figure out guessing the RLM behavior and writing 'C' code
to answer to the messages. If someone on the list has a Cisco soft switch
talking to a Cisco GW using RLM+ISDN and/or RLM+SS7, if you could generate
a tcpdump binary capture of the UDP control packets (RLM + ISDN/SS7), it
would be extremely usefull towards making this a reality. I would need the
capture of a severing/reconection of a RLM/ISDN link then a
severing/reconection of a SS7 and/or an IMT trunk, to check that all my
interpretation of the fiels are correct. Perhaps someone can do this at
the wee hours with no traffic being lost.

We need to do this anyways, because it will be cheaper than purchasing a
certified SS7 NGN switch in Brazil, then certify it for Brazilian use. I
hope we can get enough traction to colaborate and make this into a
stable/certifiable NGN platform (Asterisk/Cisco as the Media Gateway + the
soft switch as the call distribution agent).

Here we use the ITU way of doing things, without indirect point code
routing and so far we only need ISUP, as LNP isn't quite here yet (should
be up and running in about 18 months).
-- 
Regards,

Marcelo Pacheco
Systems & Technology Dir - FaleVOIP Telecom
Com: (27)2127-9791
Cel: (27)9945-3993
Fax: (27)2127-9799
E-mail: marcelo at falevoip.net
MSN: marcelo at falevoip.net / marcelo at macp.eti.br
Site: www.falevoip.net