|Anonymous | Login | Signup for a new account||2018-04-22 22:51 EEST|
|Main | My View | View Issues | Change Log | Roadmap | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000419||[Yate - Yet Another Telephony Engine] module||minor||always||2017-12-29 05:09||2018-01-02 05:06|
|Reporter||Marvin Zhai||View Status||public|
|Summary||0000419: ysipchan Memory(Thread) leakage|
SIP/TCP Call To Yate,When The Call is rejected with 404 ,The Thread(YSIP Worker) created by YateSIPTCPListener won't be realsed If The SIP/TCP Call don't sent FIN Tcp Packet.
1) Don't load route module Or callto an nonexistent destination, ysipchan will respond 404
2) SIP Client Will Send ACK when recived 404 From Yate, But The Client Won't Send FIN Tcp Packet
3) tags/RELEASE_6_0_0,tags/RELEASE_5_0_0,revision 6287 all have the issue
|Tags||No tags attached.|
I guess you didn't wait long enough.
The transports do not have an 1-to-1 relationship to the transactions. A transport can be reused for a new transaction. This is especially important when SIP proxies are used since they use one transport for many transactions of the SIP entities behind them.
Please take a look at the tcp_idle setting in section [general] of ysipchan.conf.sample:
; tcp_idle: integer: Interval (in seconds) allowed for an incoming TCP connection
; to stay idle (nothing sent/received)
; This parameter is applied on reload for new connections only
; It may be overridden in listener sections
; Defaults to 120
; Minimum allowed value is calculated from SIP 'B' timer (which is 64 * t1 timer value)
; expressed in seconds using the following formula: B * 3 / 2 (46 seconds for T1 default value)
; Maximum allowed value is 600
Note that a transport is not considered idle if it has active transactions even if no message is transferred. An INVITE transaction can take a long time waiting for the called party to answer. The idle timer starts when there are no more transactions for that transport.
For outbound TCP/TLS connections (Yate as UAC) the behavior is controlled by the tcp_keepalive and tcp_keepalive_first settings.
Marvin Zhai (reporter)
Thanks for Replay.
It's a feature of one sip client of Polycom that donot release the tcp SIP call even if it does not exist,reuse the tcp connection next time by sending tcp alive datas periodically,the interval time is less than tcp_idle of yate,so the thread always alive.
|2017-12-29 05:09||Marvin Zhai||New Issue|
|2017-12-29 13:12||paulc||Note Added: 0000620|
|2018-01-02 05:06||Marvin Zhai||Note Added: 0000621|
|Copyright © 2000 - 2008 Mantis Group|