[asterisk-ss7] libss7 and IAM/ACM

[Anders Baekgaard]

> 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.

It is possible to use both chan_ss7 and chan_zap on the same hardware, 
provided that the ss7 and isdn traffic are on different timeslots or links.

On Thursday 19 June 2008 00:46:18 Kristian Nielsen wrote:


> Hm, I think this is a bug. From a quick reading of Q.764, we should not
> send CPG here, it should be ACM. I do not think it is valid to send CPG
> before the ACM or CON.

It is a bug, it is not allowed to send CPG before ACM or CON, according to 
Q.764. However, configuring use_connect for a linkset where you may receive 
ACM is not right either because there is no correct way for chan_ss7 to send 
CPG messages when waiting for ANM.

> >> 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.
>
The current behaviour of chan_ss7 where ACM is sent when there is a match in 
the dial plan is right in most cases. It allows chan_ss7 to automatically 
send REL with cause value UNALLOCATED when there is no math.

Christian's path will ensure that ACM is sent before any CPG or ANM is sent, 
if you also specify use_connect in the configuration file. However, the patch 
is wrong because it implicitly changes timeout values. If chan_ss7 does not 
receive CPG or ANM, and consequenly does not send ACM to the calling swith, 
then the calling switch, after sending IAM, will timeout waiting for ACM, 
rather than waiting for ANM or CON. These timeout values are different.

There is one more issue in the patch: the chunk

@@ -886,7 +886,13 @@ static int ss7_indicate(struct ast_channel *chan, int 
condition, const void* dat
   case AST_CONTROL_RINGING:
     ast_log(LOG_DEBUG, "Sending ALERTING call progress for CIC=%d in-band 
ind=%d.\n",
 	    pvt->cic, pvt->has_inband_ind);
-    ss7_send_call_progress(pvt, 0x01);
+    if (pvt->state == ST_GOT_IAM) {
+      isup_send_acm(pvt, 1);
+      pvt->state = ST_SENT_ACM;
+    } else {
+      ss7_send_call_progress(pvt, 0x01);
+    }
+

should be

@@ -886,7 +886,12 @@ static int ss7_indicate(struct ast_channel *chan, int 
condition, const void* dat
   case AST_CONTROL_RINGING:
     ast_log(LOG_DEBUG, "Sending ALERTING call progress for CIC=%d in-band 
ind=%d.\n",
 	    pvt->cic, pvt->has_inband_ind);
-    ss7_send_call_progress(pvt, 0x01);
+    if (pvt->state == ST_GOT_IAM) {
+      isup_send_acm(pvt, 1);
+      pvt->state = ST_SENT_ACM;
+    }
+     ss7_send_call_progress(pvt, 0x01);
+

otherwise chan_ss7 will not pass on the first received indication.

-Anders