[asterisk-ss7] libss7 and IAM/ACM

[Barry O'Donovan]

Hi Kristian and thanks for the detailed replay.

Comments follow below:

On Wednesday 18 June 2008 08:38:11 Kristian Nielsen wrote:
> Why do you prefer libss7 over chan_ss7?

<snip>

You summed it up quite well. In my case I like the fact that it's the same 
interface as ISDN/PRI via Zap (especially as we may run some ports as 
ISDN/PRI and others as SS7 on the same server). We also currently do not 
require clustering with MTP3 and failover.

> > libss7 sends an ACM packet after it receives the IAM. The ACM means that
> > a channel has been reserved for the call but we are trying to indicate
> > conjestion. But, also, in any application such as operating a SS7 to VoIP
> > gateway, we need to verify the available of channels/bandwidth/etc before
> > sending the ACM.

<sniped interesting discussion on ACM>

> So my point is that probably the sending of ACM should actually be under
> the control of the dialplan in Asterisk, as it is the dialplan that
> determines when the address can be considered complete.

Sounds like an excellent solution all around.

> SIP and other similar protocols do not have the notion of incomplete address
> and partial routing (the destination address is always available as a
> whole), so this aspect of SS7 does not fit in well with Asterisk as it is...
>
> I do not know how libss7 works in this respect, and I do not fully remember
> how chan_ss7 handles it either (sorry).

I can't generate a pcap trace now as I'm on libss7 but I have one lying around 
from a previous test. The scenario here is that rather than rejecting with 
cause code 34 (congestion) we are accepting the call and switching it back 
out the same C7 link. Inbound calls come in the higher cics and outbound 
prefer the lower cics.

The call is connected and answered and then hung up.

The packets were as follows (Asterisk point code = 1, DMS = 14768):

1. [CIC 63] From 14768 To 1: IAM  (onbound call to Asterisk)
2. [CIC 1]  From 1 to 14768: IAM  (outbound call from Asterisk)
3. [CIC 1]  From 14768 To 1: ACM
4. [CIC 63] From 1 To 14678: CPG  
5. [CIC 1]  From 14768 To 1: ANM
6. [CIC 63] From 1 to 14768: CON

Packets 7 through 10 are the REL and RLCs.

So you can see that chan_ss7 doesn't actually send an ACM to the DMS. However 
an issue we had with this (with the ACM issue with libss7 we tried chan_ss7) 
was that the caller (the first leg coming in cic 63 above) does not get a 
ringing tone. We suspected this was the lack of an ACM but I'm not sure about 
this.

> Another option is to not send ACM at all, but send CON directly (this is
> probably what you were using when working with chan_ss7).

Yes - that lines up with the above. A CPG and then a CON.

> Probably what needs to be implemented for your scenario (in libss7 and
> chan_ss7) is to either have an explicit dialplan command that sends ACM, or
> alternatively to delay sending ACM/CON until the first ringing/answer
> indication (which would also make good sense).

Yes possibly. I think we need the ACM to over come the lack of ringing above.

Thanks again for the detail response. Any comments you have on the above would 
also be welcome.

 - Barry