my ss7 crashed with the following error taking from the core dump.
the crash is noticed after the call reached a peak of 34 calls... and fter then I made max inbound on oh323 to 29 so that it will not go to the second ss7 and I disable the link and phyically removed it. my provider too get it blocked.

however, all the changes made by Kai and Kristian were followed.

I am running asterisk-1.2.5, chan_ss7-0.8.3 with zaptel 1.2.4

I have the follwoing from my dump
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
#0  0xf6a90f13 in t1_timeout (arg=0x82f11c0) at chan_ss7.c:765
765       isup_send_rel(pvt, pvt->hangupcause);

I have the core dump and the ss7 dump and I will be glad if someone can help.

the extract from my chan_ss7.c are as below

## FOR THE isup_send_rel(pvt, pvt->hangupcause);######

static int start_timer(int msec, int (*cb)(void *), void *data) {
  int id = ast_sched_add(monitor_sched, msec, cb, data);
  if(msec < MONITOR_FREQ) {
    wakeup_monitor();
  }
  return id;
}

static int t1_timeout(void *arg) {
  struct ss7_chan *pvt = arg;

  ast_log(LOG_NOTICE, "T1 timeout (waiting for RLC) CIC=%d.\n", pvt->cic);
  isup_send_rel(pvt, pvt->hangupcause);
  //isup_send_rel(pvt, pvt->owner->hangupcause);
  return 1;                     /* Run us again the next period */
}

/* This should be called with pvt->lock held. */
static void t1_clear(struct ss7_chan *pvt) {
  if(pvt->t1 != -1) {
    ast_sched_del(monitor_sched, pvt->t1);
    pvt->t1 = -1;
  }
}

/* This should be called with pvt->lock held. */
static void t1_start(struct ss7_chan *pvt) {
  t1_clear(pvt);
  pvt->t1 = start_timer(30000, t1_timeout, pvt);
}



### FOR t9_start(chan) #########
if(pvt->state != ST_SENT_IAM) {
    ast_log(LOG_NOTICE, "Got ACM message, but sent no IAM, on CIC=%d?!?",
            pvt->cic);
    /* Q.764 (2.9.5.1 f) error handling for the spurious ACM. */
    if(pvt->state == ST_IDLE)
      reset_circuit(pvt);
    return;
  }

  if(chan == NULL) {
    ast_log(LOG_NOTICE, "Missing chan pointer for CIC=%d, processing ACM?!?\n", pvt->cic);
    return;
  }

  t9_start(chan);

  /* Q.764 (2.1.4.6 a): Alert if called_party_status is "subscriber free". */
  if(inmsg->acm.back_ind.called_party_status == 1) {
    ast_queue_frame(chan, &ring_frame);
  }


Goksie


On 3/22/06, Kai Militzer <[EMAIL PROTECTED]> wrote:
Hello Kristian and rest,

Kristian Nielsen wrote:
> For a quick fix, try moving the this line in process_acm():
>
>   t9_start(chan);
>
> down to after this code, which checks for a NULL chan:
>
>   if(chan == NULL) {
>     ast_log(LOG_NOTICE, "Missing chan pointer for CIC=%d, processing ACM?!?\n", pvt->cic);
>     return;
>   }
>
> that should fix the crash, though I think the code is still not quite
> right (ie. no need to reset the circuit in this case).

> Would be great if you could try this change and send us the next crash!

That helped. I wasn't able to get it crashing again, but I'll try to
find something else ... ;)

> BTW, nice problem reports with backtraces and everything ...

You are welcome ... I want a usable version of chan_ss7 at the end of
june because I need to go into production then ;)

> Incidentally, I wonder if you are making calls faster than a single E1
> signalling time slot can handle? In any case it's very good that you
> do, you've already found us two crashing bugs :-).

What I do to test is the following:

I have an asterisk that dials out via iax to the asterisk with the ss7
which then dials out via ss7 to another external ss7 gateway which then
connects to another asterisk that starts an echo application. I start
this call with a .call file (or better: 60 of them) that I copy into the
spool dir. When the call is connected, I start playback of a MP3 file
via the dialplan. Because of this I have 60 parallel calls starting at
once. This is not what you will have in real life, but it helps to find
bugs and gives me an idea of what the max load is that my system can handle.

If you have any other ideas how/what else I can test, I am happy to give
it a try.

Best regards,
Kai

--
Kai Militzer                 WESTEND GmbH  |  Internet-Business-Provider
Technik                      CISCO Systems Partner - Authorized Reseller
                              Lütticher Straße 10      Tel 0241/701333-14
[EMAIL PROTECTED]               D-52064 Aachen              Fax 0241/911879

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-ss7

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-ss7

Reply via email to