[asterisk-ss7] MATTF libss7

Kaloyan Kovachev kkovachev at varna.net
Thu Nov 19 05:10:38 CST 2009 

On Thu, 19 Nov 2009 11:35:21 +0100, Erik Wartusch wrote
> Hmm I dont actually see the 100 % relation to my problem.
> 
> I can call and got speech transmission during the tests in both ways and
> everthing is fine. The "ss7 show linkset 2" output don't show me an
> error or DOWN state.
> 
> The problem appears only if the other side is deactivating the link and
> they expect these SIO messages continously....
> 
> I'm not a SS7 expert so I don't know actually about all the timers,
> messages etc. (only some).
> 
> Does this "mtp3 t19 timer" setting solve something related to my
> problem?
> 

i think yes and no.
 It is not related to the SIO: in the log from my previous email you can see I
have received some, but none were sent from asterisk.
 The remote end here is also Siemens, so it looks something specific to that –
missconfiguration or interoperability problem. I got TRA, but the link does
not come UP, which (probably) will be in your case too if you disable T19 and
disconnect then reconnect the cable. With T19 after 63sec (by default) your
link goes UP without waiting for TRA, which was actually sent, but not
recognized from asterisk as it was to different SLS than 0. The provider will
see the link UP on its side always as they have received and accepted TRA from
asterisk, but asterisk has not accepted theirs.

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?

> 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

More information about the asterisk-ss7 mailing list