[asterisk-ss7] chan_ss7 - T22 timeout (No'circuitgroup resetacknowledge' from peer)
Low Yu Siang
yusiang at yahoo.com
Tue Jul 22 02:32:09 CDT 2008
Hi!
After days of trial & errors on my side, finally the telco guy told me that they didn't enable the acknowledgement which are just some mouse clicks on their web admin interface. OMG.
Now I can get idle CIC and able to make calls/release circuit. However the 'group reset' doesn't seem to work all the times, sometimes it only reset the first specified CIC. For example, it only reset CIC1 & CIC17(two 'group reset' were sent) but not the rest of 2-15,18-31 channels.
--- On Mon, 21/7/08, Low Yu Siang <yusiang at yahoo.com> wrote:
> From: Low Yu Siang <yusiang at yahoo.com>
> Subject: Re: [asterisk-ss7] chan_ss7 - T22 timeout (No'circuitgroup resetacknowledge' from peer)
> To: asterisk-ss7 at lists.digium.com
> Date: Monday, 21 July, 2008, 7:05 PM
> I modified t22_timeout() in l4isup.c so that it would
> pretend as received GRA and reset the circuit to idle. I
> tried making an outgoing call and it is working(my phone
> rings), but I cannot hear anything. When I ended the call
> on my phone, asterisk doesn't get anything from the
> other side and therefore holding the circuit as busy. If I
> end the call on the asterisk side, the call is ended on the
> phone properly and asterisk will get T1 timeout(waiting for
> RLC).
>
> static int t22_timeout(void *arg) {
> struct ss7_chan *pvt = arg;
>
> ast_log(LOG_NOTICE, "T22 timeout (No
> \"circuit group reset acknowledge\" from
> peer) CIC=%d.\n", pvt->cic);
> //isup_send_grs(pvt, pvt->grs_count, 0);
>
> /* hack start */
> stop_timer(pvt->t22);
> pvt->t22 = -1;
> stop_timer(pvt->t23);
> pvt->t23 = -1;
> pvt->grs_count = -1;
> pvt->reset_done = 1;
> /* hack end */
>
> return 1; /* Run us again the next
> period */
> }
>
> Another thing that I noticed, is that it seems so far I
> have never received any ISUP message from the switch
> side(therefore getting timeout), although the switch seems
> to be able to receive message from asterisk(else my phone
> wont ring). I am suspecting that right now the ISUP traffic
> only work one-way(from asterisk to switch) but the telco guy
> told me that they have checked the SS7/ISUP configuration on
> their side and doesn't find any problem. Does anyone has
> any idea about what possibly went wrong with the
> configuration(on the telco side)? I am not familiar with
> how the telco/switch environment works.
>
> Thanks again.
>
> --- On Sun, 20/7/08, Jakub Klausa <j.klausa at ss7.pl>
> wrote:
>
> > From: Jakub Klausa <j.klausa at ss7.pl>
> > Subject: Re: [asterisk-ss7] chan_ss7 - T22 timeout
> (No'circuitgroup resetacknowledge' from peer)
> > To: asterisk-ss7 at lists.digium.com
> > Date: Sunday, 20 July, 2008, 3:55 AM
> > On Sat, Jul 19, 2008 at 08:49:20PM +0200, Pawel
> Ratajewski
> > (Forweb) wrote:
> >
> > => i call 'fine' if I'm able to
> > block/unblock one or group of channels :)
> >
> > Either you're using different chan_ss7, or we
> differ on
> > the definition
> > 'working fine'. The fact that the 'ss7
> show
> > channels' shows you what you
> > expects it to doesn't mean the other side of the
> link
> > sees the same. That's
> > what interconnect signalling tests are for, and if
> > you're using stock
> > chan_ss7 they shouldn't have passed. First of all,
> you
> > can't invoke BLOs
> > from the chan_ss7 interface, which is what you could
> and
> > should use for a
> > single CIC blocking. That's Q.784 tests 1.3.2 -
> the
> > whole group. Second, the CGB/CGUs sent by stock
> chan_ss7
> > are always sent with range=32, no matter what
> > you'll give it as an input option. Here you should
> have
> > failed on tests
> > 1,3,1 - the whole group again. And it definetly should
> have
> > been tested,
> > because it's used in everyday operations.
> >
> > => It works fine for me :) The range is always
> shown as
> > 32, but it's really
> > => different. But the problem is, chan_ss7 sends to
> many
> > octets - the last is
> > => empty, but some od DGT does not recognize its as
> > empty.
> >
> > Well, if it works fine, and you insist on the fact
> that the
> > chan_ss7 'ss7
> > block/unblock' works allright, then the other end
> has
> > some serious problems
> > sending the CGAs with range=32 everytime.
> >
> > But seriously, belive me, it's chan_ss7's
> fault. It
> > even got mentioned here
> > on the list once or twice. It was supposed to get
> fixed,
> > but i'm not
> > entirely sure it did.
> >
> > Anyway - there's an easy way finding out - either
> put
> > your protocol analyzer
> > up to the task, or contact the other end for a test
> run to
> > see if they see
> > what that you're supposedly sending towards them.
> >
> > --
> > Jakub Klausa | j.klausa at ss7.pl | http://www.ss7.pl/ |
> > http://www.ngpbx.pl/
> > Dane rejestrowe ->
> >
> http://kontakt.ss7.pl_______________________________________________
> > --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
>
>
>
> __________________________________________________________
> Not happy with your email address?.
> Get the one you really want - millions of new email
> addresses available now at Yahoo!
> http://uk.docs.yahoo.com/ymail/new.html
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
More information about the asterisk-ss7
mailing list