On Fri, 20 Nov 2009 16:24:25 +0100, Attila Domjan wrote
> mtp3:
> you mixed the bversions, in my current version:
right, sorry ... am still at matff-bug13495 r238
> case NET_MNG_TFP:
> mtp3_add_set_route(mtp2->adj_sp, pc2int(ss7->switchtype, paramptr),
> TFP);
> return 0;
> case NET_MNG_TFR:
> return 0;
> case NET_MNG_TFA:
> mtp3_add_set_route(mtp2->adj_sp, pc2int(ss7->switchtype, paramptr),
> TFA);
> return 0;
>
> mtp2 refer the link the message came from.
>
> MTP2:
> what should happen if the t2 timer expired and what is the current state
> of the link, please explain again.
>
I was wrong about that too ... the link is going from inservice to idle, so
starting from here ... at the end it calls 'return to_idle(link);' where:
link->state = MTP_IDLE;
if (mtp2_lssu(link, LSSU_SIOS)) {
mtp_error(link->master, "Could not transmit LSSU\n");
return -1;
}
mtp2_setstate(link, MTP_NOTALIGNED);
then we go to setstate with old state IDLE and start T2, send SIO and set the
state to NOTALIGNED.
now t2 expires ... T2 is removed, but because new state is IDLE we are back to
'return to_idle(link);' and all starts over again
the only reason for this to stop is when mtp2_lssu() returns an error, which
seems inpossible, but why it is checked then?
> 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
|