Hello Domian,
i have a similar (almost sure _the same_) problem:
at least in my case i got TRA, but instead of:
"OPC XXX DPC YYY SLS 0" it was to "OPC XXX DPC YYY SLS 2" also i get some TFP
and TFA to diferent SLS like 4, 6, 11, 13
while STD_TEST messages are correctly replied to "OPC XXX DPC YYY SLS 0", so
the link remained as:
"Adjecent SP PC: XXX STATE: DOWN"
but
"State: INSERVICE, UP"
unfortunately i can't find the full debug log right now, but will keep
searching where it was saved :(
On Wed, 18 Nov 2009 17:14:43 +0100, Attila Domjan wrote
> interesting, have u got TRA messages?
> The linkset was in operational state?
> please send me the current chan_dahdi.conf
>
> On Wed, 2009-11-18 at 17:05 +0100, Erik Wartusch wrote:
> > Hello Attila!
> >
> > I can send you what happend if they switched off the link via software
> > command (Siemens EWSD). (see txt attached).
> >
> > Im afraid I dont have the output of "ss7 show linkset 1". but Im pretty
> > sure it was like this (when the link was set to down from their side):
> >
> > ss7 show
> > calls cics linkset
> > srv27*CLI> ss7 show linkset 1
> > SS7 flags: 0x0
> > SS7 linkset 1 status: Down
> > SS7 calling nai: -1
> > SS7 called nai: -1
> > SS7 nationalprefix:
> > SS7 internationalprefix:
> > SS7 unknownprefix:
> > SS7 networkroutedprefix:
> > SS7 subscriberprefix:
> > Switch type: ITU
> > Our point code: 4297
> > SLS shift: 0
> > numlinks: 1
> > numsps: 1
> > ---------------------------------
> > Adjecent SP PC: 5921 STATE: Down
> > TRA: GOT SENT T19: not running T21: not running
> > Routes:
> > DPC State T6 T10
> > Link SLC: 0 NetMngSLS: 0
> > State: INSERVICE, UP
> > STD Test: passed
> > Got, sent :
> > Inhibit:
> > Changeover: NO
> > Tx buffer: 0
> > Tx queue: 0
> > Retrans pos 0
> > CO buffer: 0
> > CB buffer: 0
> > Last FSN: 71
> > MTP3timers: Q707_T2(12s) [here im not sure this was running)
> >
> > So sadly we got today again a negative result (test not passed) of the
> > czech telco so we can not go live with the SS7 link...
> >
> > Kind Regards,
> > Erik
> >
> >
> > Am Mittwoch, den 11.11.2009, 16:10 +0100 schrieb Attila Domjan:
> > > Hmm, it is interesting...
> > >
> > > static void t2_expiry(void * data)
> > > {
> > > struct mtp2 *link = data;
> > >
> > > mtp2_setstate(link, MTP_IDLE);
> > >
> > > return;
> > > }
> > >
> > >
> > > int mtp2_setstate(struct mtp2 *link, int newstate)
> > > ....
> > > case MTP_IDLE:
> > > link->t2 = ss7_schedule_event(link->master, link->timers.t2,
> > > t2_expiry, link);
> > > if (mtp2_lssu(link, LSSU_SIO)) {
> > > mtp_error(link->master, "Unable to transmit initial LSSU\n");
> > > return -1;
> > > }
> > > link->state = MTP_NOTALIGNED;
> > > return 0;
> > >
> > > it is coded, periodically send SIO....
> > >
> > > what is the link state in this case? (ss7 show linkset ...)
> > >
> > > A
> > >
> > > On Wed, 2009-11-11 at 15:46 +0100, Erik Wartusch wrote:
> > > > Hi Attila!
> > > >
> > > > I like your version. Thanks. Still I have problems to pass a MTP level 2
> > > > test wanted by a czech telco.
> > > >
> > > > It's regarding sending SIO / SIOS messages when the other sites link is
> > > > down (during the specified T2 timer). They claim we sending not
> > > > periodically the SIO messages (just once) until the T2 timer is running
> > > > out.
> > > >
> > > > Any experience with that?
> > > >
> > > > Kind Regards,
> > > > Erik
> > > >
> > > > Am Dienstag, den 10.11.2009, 11:30 +0100 schrieb Attila Domjan:
> > > > > Hi, don't mix the libss7/asterisk(chan_dahdi) versions, there are some
> > > > > api changes.
> > > > >
> > > > > My version (many additional features) are working from my svn.
> > > > >
> > > > > Regards,
> > > > > Attila
> > > > >
> > > > > On Mon, 2009-11-09 at 17:35 +0100, Erik Wartusch wrote:
> > > > > > Hello ss7 list!
> > > > > >
> > > > > > Installing libss7 and asterisk from
> > > > > > http://svn.digium.com/svn/libss7/team/mattf/bug13495
> > > > > >
> > > > > > http://svn.digium.com/svn/asterisk/team/mattf/bug13495
> > > > > >
> > > > > > as well as:
> > > > > > http://svn.digium.com/svn/dahdi/tools/trunk dahdi-tools
> > > > > > http://svn.digium.com/svn/dahdi/linux/trunk dahdi-trunk
> > > > > >
> > > > > > (this order: dahdi, dahdi-tools, libss7 and then asterisk)
> > > > > >
> > > > > > leads to the follwing error doing a "make" for the Asterisk
version (see below).
> > > > > > Did I made any mistake or is this a bug?
> > > > > >
> > > > > > Kind Regards,
> > > > > >
> > > > > > Erik
> > > > > >
> > > > > > [CC] chan_dahdi.c -> chan_dahdi.o
> > > > > > chan_dahdi.c: In function ?ss7_linkset?:
> > > > > > chan_dahdi.c:10921: error: ?ss7_event_iam? has no member named
> > > > > > ?cot_performed_on_previous_cic?
> > > > > > chan_dahdi.c:10921: error: ?ss7_event_sam? has no member named
> > > > > > ?cot_performed_on_previous_cic?
> > > > > > chan_dahdi.c:10929: error: ?ss7_event_iam? has no member named
> > > > > > ?cot_performed_on_previous_cic?
> > > > > > chan_dahdi.c:10947: error: ?ss7_event_cot? has no member named
> > > > > > ?cot_performed_on_previous_cic?
> > > > > > chan_dahdi.c: In function ?process_dahdi?:
> > > > > > chan_dahdi.c:16660: error: ?SS7_ISDN_ACCESS_INDICATOR? undeclared
(first
> > > > > > use in this function)
> > > > > > chan_dahdi.c:16660: error: (Each undeclared identifier is reported
only
> > > > > > once
> > > > > > chan_dahdi.c:16660: error: for each function it appears in.)
> > > > > > make[1]: *** [chan_dahdi.o] Error 1
> > > > > > make: *** [channels] Error 2
> > > > > > srv27:/usr/src/UNSTABLE_libss7/asterisk-patched# cd ..
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > --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
> > > >
|