Hello!
sorry for taking so long to give a feedback to this, but thanks to a
fibercut I wasn't able to reach my ss7 test system yesterday. :(
I made the changes suggested and changed the one line in chan_ss7.c to
isup_send_rel(pvt, pvt->hangupcause);
But my asterisk still crashed for a lot of simultaneous outgoing calls.
gdb backtrace says:
#0 0x408622ac in t9_start (chan=0x0) at chan_ss7.c:903
#1 0x4086664f in process_acm (pvt=0x817d7f0, inmsg=0xbd1ffa34)
at chan_ss7.c:2337
#2 0x40865e5c in process_circuit_message (slink=0x40889600,
inmsg=0xbd1ffa34,
handler=0x4086661f <process_acm>) at chan_ss7.c:2156
#3 0x40868931 in process_isup_message (slink=0x40889600, inmsg=0xbd1ffa34)
at chan_ss7.c:3087
#4 0x40869180 in monitor_main (data=0x0) at chan_ss7.c:3303
#5 0x40027e51 in pthread_start_thread () from /lib/libpthread.so.0
#6 0x401ef92a in clone () from /lib/libc.so.6
The last words of asterisk were:
Mar 22 11:30:48 DEBUG[30288]: chan_ss7.c:3075 process_isup_message:
processing ISUP message, typ=ACM, CIC=20
I add a etherealdump of the calls to this mail.
In my opinion there is a generyl problem with the handling of the
timeouts, but I could be wrong.
Regards,
Kai
--
Kai Militzer WESTEND GmbH | Internet-Business-Provider
Technik CISCO Systems Partner - Authorized Reseller
L?tticher Stra?e 10 Tel 0241/701333-14
km@xxxxxxxxxxx D-52064 Aachen Fax 0241/911879
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t1_timeouts.pcap
Type: application/octet-stream
Size: 7522 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-ss7/attachments/20060322/c6e852e7/t1_timeouts.obj
|