chan_ss7 1.4.3 bug with overlapping CIC numbers on combined linksets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gregory,

Op 06-01-11 16:11, Gregory Massel schreef:
> Hello
>
> I seem to have picked up a bug in chan_ss7 (version 1.4.3) and I was 
> wondering if anyone else can confirm the same experience or assist in 
> developing a fix.
>
> The problem arises when there are multiple combined linksets with 
> overlapping CIC numbers. This was supported from chan_ss7 version 1.4 
> (and described as "Dutch ISUP" in the NEWS file) through the inclusion 
> of a patch developed by Robert Verspuy.
>
I'm running 2 asterisk servers (although still with chan_ss7 1.2.1 with 
my own patches backported).

> The only unusual messages that I pick up are the following:
> NOTICE[1467] l4isup.c: Trying to remove CIC=68 from idle list, but not 
> found?!?.
I don't see that kind of message in my logfiles,
But I do see the following:

[Jan  6 09:52:08] NOTICE[29584] l4isup.c: Got call progress, but call 
setup not active, CIC=95, state=5?!?

I don't know if this is related somehow.

>
> So it seems that the patch is effective at matching the CICs in one 
> section, but perhaps some else in the code something else also needs 
> to be patched to allow clean-up of the CICs once used.
This could be.
I don't know the code very well, and this was my first patch to get 
everything working on our systems.
>
> Eventually, something exhausts itself and everything falls apart with 
> the following message flooding repeatedly:
> NOTICE[8513]: mtp.c:413 mtp_put: Full MTP receivebuf, event lost, 
> type=15.
I don't see any log messages like that,
But I do see:
[Jan  6 12:53:18] NOTICE[14044] l4isup.c: Write buffer full on CIC=99 
(wrote only 160 of 240), audio lost (suppress 13).

This could also be related.
We have mainly inbound calls, so it could be a bit of the same issue, 
but with the call setup the other way around.

I did look into the buffer problems before, but did not find any cause 
on the server (not very busy).
So I assumed this was likely be caused by transferring the call from SS7 
to SIP.

With a bit extra latency through SIP, and a bit too much jitter, I think 
it's possible that chan_ss7 can not fill the write buffer,
or when the rtp packets from sip suddenly arrive, the writesbuffer can 
be filled to much?

But all my issues seem only temporary.
After these log messages, the CIC's are still usable and I see a few 
minutes later calls on those CIC's with problems.
And we had no crash eiter of a running system.

Both servers are now running for a 6 weeks and 5 hours (sinds the last 
maintenance).
And handled together a bit more than 600.000 inbound SS7 and 10.000 
outbound SS7 calls.
Totally processed around 900.000 calls.

 From last februari until september (8 months) the servers had their 
longest time without any problems.
The system had to be restarted for maintenance and adding a few extra 
SS7 links.

With kind Regards
Robert Verspuy

-- 
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110106/b7f89b86/attachment.htm>


[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux