try to change mtp2_setstate(link, MTP_IDLE); to to_idle(link); in t2_expiry() On Mon, 2009-11-23 at 16:15 +0100, Erik Wartusch wrote: > Hi, > > I modified now for a try the mtp2.c for libss7 and recompiled/installed > it. I did this: > "so try put > link->state = MTP_IDLE; before calling mtp2_setstate() in t2_expiry. > I think it will solve the problem..." > > Not successful. > Statement of the provider regarding the T2 timer test: > "When we deactivate the link, it results in signal SIOS from our side - > to inform your side that link is down; from this moment our side is > dead. > Your side should react by SIO; then, when you don?t get any SIO answer > from our side (of course, because link is down)you should sent SIOS > after some period, immediately followed by next SIO - and then > periodically repeat this sequence until SIO from our side appears (in a > moment, when link is acivated) > The time interval between your SIO and your SIOS should be in duration > from 5 to 150sec and this is Timer2 definition. (For example, our system > has defined this value to 30sec)" > > The statement to this after I did this change Attila suggested: > > "The only change in your system behaviour, that you (when we deactivate > the link) send 3 times SIO; no SIOS." > > Currently I have the default MTP2 T2 setting = 50 seconds thats in the > range of their specifiactions (they have 30). > > Kind Regards, > > Erik > > > > > > > Am Montag, den 23.11.2009, 14:02 +0200 schrieb Kaloyan Kovachev: > > > > Erik, > > > > can you check with your provider how often they expect to have SIO transmitted? > > > > ITU_TIMER_T2 (5-150 sec according to Q.703 12.3) is currently set to 50sec > > > > (in mtp2.h), but if they expect it to be the minimum 5sec you may need to > > > > change that value. > > > > Also according to Q.703 7.3 (note 4): > > > > > > > > If automatic allocation of signalling terminals or signalling data links is > > > > applied at both ends of a > > > > signalling link, it must be ensured that the values of this time-out are > > > > different at each end of a signalling > > > > link (see clause 12/Q.704). In this case T2 low (see 12.3) is allocated to the > > > > signalling point with the lower > > > > point code and T2 high to the signalling point with the higher point code. In > > > > all other cases, the value of > > > > time-out T2 can be the same at both ends of the link. > > > > > > > > So you may need to set it to either of: > > > > T2 low = 5-50 s > > > > T2 high = 70-150 s > > > > > > > > Otherwise the code seems fine > > > > > > > > On Mon, 23 Nov 2009 11:00:48 +0100, Erik Wartusch wrote > > > > > Hi, > > > > > > > > > > Good to hear about the progress. > > > > > Would be really great If you can solve this MTP2 problem and merge to > > > > > the trunk. > > > > > My boss asked us allready to switch the two lines from libss7 to the > > > > > commercial ss7box (Sangoma) we also use for other carriers. Would be sad > > > > > (and expensive for several reasons) to do so... > > > > > > > > > > Regards, > > > > > Erik > > > > > > > > > > Am Freitag, den 20.11.2009, 20:37 +0100 schrieb Domjan Attila: > > > > > > Thanks the test, next weak I will merge to the trunk and examine the > > > > > > mtp2 problem, first of all I read the itu standard... > > > > > > > > > > > > On Fri, 2009-11-20 at 19:08 +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 > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > Positive! The link came up immediately, got CIC resets (remotely blocked at > > > > > > > the moment) and T19 started then expired at time. > > > > > > > > > > > > > > > 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 > > > > > > > > > > _______________________________________________ > > > > > --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 > > > > > > Mit freundlichen Gr??en > > Erik Wartusch > > > > _______________________________________________ > --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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part Url : http://lists.digium.com/pipermail/asterisk-ss7/attachments/20091123/c3afd7d3/attachment-0001.pgp