On Fri, 20 Nov 2009 16:52:56 +0100, Attila Domjan wrote
> I looked in the mtp2 code
> to_idle() set state to MTP_IDLE, send SIOS, and call
> mtp2_setstate(link, MTP_NOTALIGNED);
>
> mtp2_state() start T2 timer if the current state is IDLE.
>
> if the t2 expired, the current state NOT_ALIGNED, so try put
>
> link->state = MTP_IDLE; before calling mtp2_setstate() in t2_expiry.
> I think it will solve the problem...
>
This what i though initially, which is equal to calling to_idle(), but it is
still called from inside mtp2_setstate, so that not the reason ... calling
to_idle() from t2_expiry will just save the call to setstate
> A
>
> On Fri, 2009-11-20 at 17:15 +0200, Kaloyan Kovachev wrote:
> > On Fri, 20 Nov 2009 16:01:07 +0100, Attila Domjan wrote
> > > welcome, the mtp2 problem is not clear, I have not touch too much to
> > > mtp2 layer...
> > > what is the current state of the mtp2???
> > >
> > > I think, try put
> > >
> > > link->state = MTP_IDLE;
> > >
> > > before calling mtp2_setstate(
> > >
> > > in t2_expiry, t3_expiry....
> > >
> >
> > I will look a bit more at this, but it should switch between IDLE (send SIO,
> > start t2) and NOTALIGNED (send SIOS, start t3)
> >
> > > On Fri, 2009-11-20 at 16:46 +0200, Kaloyan Kovachev wrote:
> > > > On Fri, 20 Nov 2009 15:36:49 +0100, Attila Domjan wrote
> > > > > Hi, I made a test branch...
> > > > >
> > > > > svn co
> > > > > https://observer.router.hu/repos_pub/libss7/accept_any_sls_tfp_tfa
> > > > > libss7
> > > > >
> >
> > diff -u trunk/mtp3.c accept_any_sls_tfp_tfa/mtp3.c
> > on your svn returned just
> >
> > - if (!winner) {
> > + if (!winner && *headerptr != (NET_MNG_TRA) && *headerptr !=
> > (NET_MNG_TFA) && *headerptr != (NET_MNG_TFP) && *headerptr != (NET_MNG_TFR)) {
> >
> > but then on TFP (and TFA respectively) there is:
> > mtp3_add_set_route(winner->adj_sp, pc2int(ss7->switchtype, paramptr), TFP);
> >
> > so winner can't be NULL here. As am not sure on 100% is ignoring sls the right
> > think to do i have started adding a new configurable option to chan_dadhi.conf
> > 'ignore_mng_sls' and update slc_to_mtp2() passing as third option the result
> > of the above and this flag
> >
> > > >
> > > > Thank you very much again. You were faster than me, but while looking
at the
> > > > code my self i think i have also found why there are no repeating SIO
SIOS ...
> > > >
> > > > on t2 expire there is just a call to mtp2_setstate while it should call
> > > > to_idle() or else the t3 is not started
> > > >
> > > > could you confirm my observation please and update it in case it is
correct.
> > > >
> > > > > We accept TRA, TFP, TFA, and the not impelented yet TFR with any SLS.
> > > > > Please test, if it's work I will merge into my trunk.
> > > > >
> > > > > A
> > > > >
> > > > > On Thu, 2009-11-19 at 16:35 +0200, Kaloyan Kovachev wrote:
> > > > > > On Thu, 19 Nov 2009 12:32:58 +0100, Attila Domjan wrote
> > > > > > > On Thu, 2009-11-19 at 13:10 +0200, Kaloyan Kovachev wrote:
> > > > > > > Hi,
> > > > > > > >
> > > > > > > > Domian, do you know which ITU specs I should look at to
confirm (or
> > > > not), that
> > > > > > > > in case of a single link SLS != 0 should be accepted?
> > > > > > > >
> > > > > > > not...
> > > > > > >
> > > > > > > Q.704 2.2.4
> > > > > > > ........
> > > > > > >
> > > > > > > In the case of Message Transfer Part level 3 messages, the
signalling
> > > > > > > link selection field exactly
> > > > > > > corresponds to the Signalling Link Code (SLC) which indicates the
> > > > > > > signalling link between the
> > > > > > > destination point and originating point to which the message refers.
> > > > > > >
> > > > > >
> > > > > > Thank you very much for the pointer. I am looking at Q.704 and it
> > seems that
> > > > > > the provider (or Siemens) might also be right about SLS being
ignored on a
> > > > > > single link:
> > > > > >
> > > > > > 2.2.4 The Signalling Link Selection (SLS) field is used, where
> > appropriate, in
> > > > > > performing load sharing (see 2.3).
> > > > > >
> > > > > > That 'where appropriate' makes me think so, but not sure. I will keep
> > reading,
> > > > > > but at least for TFA/TFP messages that i got (to SLS 4, 6, 13... ), it
> > seems
> > > > > > to be true (in 13.3.1):
> > > > > >
> > > > > > Transfer-allowed messages are always addressed to an adjacent
signalling
> > > > > > point. They may use any
> > > > > > available signalling route that leads to that signalling point.
> > > > > >
> > > > > >
> > > > > > > > > Thanks in advance.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Erik
> > > > > > > > >
> > > > > > > > > Am Mittwoch, den 18.11.2009, 20:56 +0100 schrieb Domjan Attila:
> > > > > > > > > > Hi,
> > > > > > > > > > I think u got TRA with wrong SLS, the stp which are u
> > connected 2 is
> > > > > > > > > > missconfigured...
> > > > > > > > > > workaround: set mtp3 t19 timer to 1ms....
> > > > > > > > > >
> > > > > > > > > > On Wed, 2009-11-18 at 18:30 +0200, Kaloyan Kovachev wrote:
> > > > > > > > > > > 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
> > > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > --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
> > > > > > > > > > _______________________________________________
> > > > > > > > > > --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
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > --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
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > --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
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > --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
> > > >
> > > >
> > > > _______________________________________________
> > > > --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
> >
> >
> > _______________________________________________
> > --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
|