Hi Anton, do you have any SS7 traces for this interconnect circuit? It would be easier to interpret what is happening if we could see a trace of one of the "ghost" calls from the IAM onwards. (I read somewhere that you can capture the signalling from chan_ss7 and decode it using Ethereal but I haven't tried it for myself yet...) Regards Darren On 13/05/06, Anton <anton.vazir@xxxxxxxxx> wrote: > > Hi Darren, > > Thank you for advice! > > If you could help me with a little more info on that issue: > In the calls Ie given below there is the same mobile > subscriber calling the same destination in 3x overlapping > sessions. Destinations are Afghanistan, so there are old > stupid analogue PSTN, that may not release the call. > So clearly he cannot do it himself, and either Erricson AXE > 10 switch did not send RELEASE, or Asterisk have not > received it, or just did not handle it. But as the result - > there are sessions which can last forever, or while some > party in the middle would time it out. Do you have any idea > of avoiding such cases? Is there are some sort of SS7 > messagers to syncronyze the CIC states periodically? > > Thanks in advance, > Anton. > > On 13 May 2006 04:01, Storer, Darren wrote: > > Hi Anton, > > > > the state of CICs can become unsynchronised between SS7 > > nodes although it doesn't happen too often. Sometimes > > Node A thinks that a particular CIC is "In Service Free" > > whilst Node B thinks that Node A didn't handle the last > > call correctly and places the same CIC into a blocked > > state at a higher application layer. > > > > When this situation occurs we normally use MML to "flex" > > the CICs by manually taking each suspect CIC out of > > service and then returning it back to service. I have > > seen that chan_ss7 appears to support these maintenance > > messages but I haven't used them myself. > > > > When an SS7 node is started for the first time (cold > > start) it has no knowledge of the state of the CICs as > > maintained by another SS7 node that it is connected to. > > To synchronise the state of the CICs after a cold start > > it is common to see many block and unblock messages > > (including Circuit Group Resets) after the signalling > > links are aligned but before the route starts to handle > > live traffic. > > > > Regards > > > > Darren > > > > On 12/05/06, Anton <anton.vazir@xxxxxxxxx> wrote: > > > Guys, > > > > > > Does anyone know, if it is possible for timeslots to > > > hang, with SS7 signalling? > > > For example if REL message is missing (did not received > > > in time by Asterisk) - > > > would the accured timeslot hang (be active on Asterisk > > > side, but released in the TELCO side?) I've strange > > > issues with one of my telco's. The sessions just timed > > > out, and released by the Asterisk itself, since there > > > is 3600s duration limit. > > > > > > Any help is highly appreciated! > > > > > > ,"SS7/15","IAX2/axsoftsw1-16389","Hangup","","2006-04-2 > > >1 23:04:54","2006-04-21 23:05:00","2006-04-22 > > > 00:04:59",3605,3599,"ANSWERED","DOCUMENTATION" > > > ,"SS7/19","IAX2/axsoftsw1-16392","Hangup","","2006-04-2 > > >1 23:05:23","2006-04-21 23:05:29","2006-04-22 > > > 00:05:28",3605,3599,"ANSWERED","DOCUMENTATION" > > > ,"SS7/11","IAX2/axsoftsw1-16393","Hangup","","2006-04-2 > > >1 23:46:00","2006-04-21 23:46:07","2006-04-22 > > > 00:46:07",3607,3600,"ANSWERED","DOCUMENTATION" > > > _______________________________________________ > > > --Bandwidth and Colocation provided by Easynews.com -- > > > > > > asterisk-ss7 mailing list > > > To UNSUBSCRIBE or update options visit: > > > http://lists.digium.com/mailman/listinfo/asterisk-ss7 > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-ss7 mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-ss7 > -- Darren Storer Comgate Telco|Internet|Broadcast -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20060514/0abac8ce/attachment.htm