Hi,
I have some questions for you as we have used suspend/continue quite a lot
in the IMS code and don't have any leaks.
Firstly, why are you using pkg_mem for your hash_id and label? Remember
that you will be in 2 different processes in the suspend and continue
portions of the code... so pkg_mem will not work - you should use shm_mem
instead.
Secondly, how are you using top to tell that you have a leak? Kamailio's
memory is internally managed.
Cheers
Jason
On Mon, Jan 13, 2014 at 1:29 PM, Shankar <shankar.rk(a)plintron.com> wrote:
> Re-sending without the attachment.
>
>
>
> *From:* Shankar [mailto:shankar.rk@plintron.com]
> *Sent:* Monday, January 13, 2014 4:57 PM
> *To:* 'sr-users(a)lists.sip-router.org'
> *Subject:* Regd. t_suspend() and t_continue()
>
>
>
> Hi,
>
>
>
> We are trying out the t_suspend() and t_continue() in our test setup. We
> are facing memory leak ( both shm and pkg as per top command results).
>
>
>
> Please find below the scenario,
>
>
>
> 1) Do a t_newtran()
>
> 2) Allocate pkg memory for hashid and label.
>
> 3) Call t_suspend()
>
> 4) Do t_continue() when async result is available
>
> 5) De-allocate pkg memory reserved for hashid and label
>
> 6) Do a t_relay() which forwards the sip message to another sip node.
>
>
>
> In the step (6) above, we see t_newtran() allocates one more time shared
> memory for the same transaction.
>
>
>
> We tried t_release() after step (4) to release the transaction as
> t_relay() anyways allocates new shared memory. Nothing helped.
>
>
>
> Please let me know what are the logs you would require to debug the same.
> I am attaching syslog for this run.
>
>
>
> Regards,
>
> Shankar
>
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
*Jason Penton**Senior Manager: Applications and Services**Smile
Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:*
jason.barry.pentonjason.penton(a)smilecoms.com <name.surname(a)smilecoms.com>
www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
Re-sending without the attachment.
From: Shankar [mailto:shankar.rk@plintron.com]
Sent: Monday, January 13, 2014 4:57 PM
To: 'sr-users(a)lists.sip-router.org'
Subject: Regd. t_suspend() and t_continue()
Hi,
We are trying out the t_suspend() and t_continue() in our test setup. We are
facing memory leak ( both shm and pkg as per top command results).
Please find below the scenario,
1) Do a t_newtran()
2) Allocate pkg memory for hashid and label.
3) Call t_suspend()
4) Do t_continue() when async result is available
5) De-allocate pkg memory reserved for hashid and label
6) Do a t_relay() which forwards the sip message to another sip node.
In the step (6) above, we see t_newtran() allocates one more time shared
memory for the same transaction.
We tried t_release() after step (4) to release the transaction as t_relay()
anyways allocates new shared memory. Nothing helped.
Please let me know what are the logs you would require to debug the same. I
am attaching syslog for this run.
Regards,
Shankar
Hi,
We are trying out the t_suspend() and t_continue() in our test setup. We are
facing memory leak ( both shm and pkg as per top command results).
Please find below the scenario,
1) Do a t_newtran()
2) Allocate pkg memory for hashid and label.
3) Call t_suspend()
4) Do t_continue() when async result is available
5) De-allocate pkg memory reserved for hashid and label
6) Do a t_relay() which forwards the sip message to another sip node.
In the step (6) above, we see t_newtran() allocates one more time shared
memory for the same transaction.
We tried t_release() after step (4) to release the transaction as t_relay()
anyways allocates new shared memory. Nothing helped.
Please let me know what are the logs you would require to debug the same. I
am attaching syslog for this run.
Regards,
Shankar
Hello There,
We are detecting errors quite often on our kamailio servers log:
/usr/local/sbin/kamailio[17527]: CRITICAL: dialog [dlg_hash.c:782]: bogus
event 5 in state 4 for dlg 0
x7fe0269a8be0 [1004:10921] with clid
'034e8c8f-07daa8c0-001b56a3(a)192.168.210.2' and tags '07daa8c0-33aeaec-t-1'
'9304808465080725853
'
After analyzing the issue We found that the root cause for those errors is
when kamailio gets PRACK message after 200 OK (CSeq INVITE) in the same
CALLID.
To mention that those calls are successfuly established.
This is due a complecated voice network.
As for today we are getting around 100 errors per kamailio server every
day. The number will increase to around 1000 errors per day in the near
future.
Two questions please:
1. Can Kamailio safety deal with those errors with no service effect
2. Is there a way to decrease the level of those errors from CRITICAL to
INFO? As for today we are working in debug level 0 so no INFO written is
written to the log in general.
I will appriciate for any assistant on this topic please.
Thanks,
Arik.
Hello everyone:
I want to know what is the parameter for the RPC function "tm.cancel" in the TM module ?
I input the parameters such as :
tm.cancel d90be24a4553d076@Yml5cC5oYWlnzs5uZXQ 2
but it can accept the only parameter,and inform me "error 400-Callid and CSeq expected as parameters " .
The context of the Callid.s is "d90be24a4553d076@Yml5cC5oYWlnzs5uZXQ".
But the context of the CSeq.s is "if you get this string, you don't check rpc_scan return code!!!(very bad)".
Could you give me an example ?
Hi,
I'm just wondering if anybody has used JSCommunicator with Kamailio yet
and if anybody has any feedback?
http://jscommunicator.org/
If anybody publishes a dedicated blog about using them together I'll be
happy to link to it
I'm also looking for any feedback from anybody who may be able to take
the CSS a little bit further. On the one hand, it would be nice to make
it look a little bit more slick but on the other hand, the intention is
for other people to drop it into their own sites where they have
existing styles as well, so I'd prefer not to have it themed so
aggressively that users have more work to do removing things.
Regards,
Daniel
Hello,
Using Kamailio 4.1.
I'm having some problems with the Max-Forwards header being decremented by almost 50 when Kamailio relays the INVITE to the next hop.
The INVITE is received by Kamailio with the value of 65, but when sent to the next hop it has the value of 16.
I'm not altering the max-forwards header value in any way in the config script. At least not explicitly.
Are there any known constructs which indirectly affect the Max-Forwards header?
10.0.0.16 is the Kamailio server.
U 10.0.0.10:5060 -> 10.0.0.16:5060
INVITE sip:3110123456@10.0.0.16:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.0.0.10;rport;branch=z9hG4bKeg5g6U4Dc5HeS.
Max-Forwards: 65.
From: "31765123456" <sip:31765123456@10.0.0.10>;tag=9Z7avj87Bc2gm.
To: <sip:3110123456@10.0.0.16:5060>.
Call-ID: e089c971-f3a8-1231-c2bb-000c2941b070.
CSeq: 54291565 INVITE.
Contact: <sip:mod_sofia@10.0.0.10:5060>.
User-Agent: CM Carrier SBC.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, NOTIFY.
Supported: timer, precondition, path, replaces.
Allow-Events: talk, hold, conference, refer.
Content-Type: application/sdp.
Content-Disposition: session.
Content-Length: 205.
U 10.0.0.16:5060 -> 10.0.0.31:5060
INVITE sip:3110123456@10.0.0.25:5060 SIP/2.0.
Record-Route: <sip:10.0.0.16;lr=on>.
Via: SIP/2.0/UDP 10.0.0.16;branch=z9hG4bKe501.5459c149e5fa2c6c723149661017aa3d.0.
Via: SIP/2.0/UDP 10.0.0.10;rport=5060;branch=z9hG4bKeg5g6U4Dc5HeS.
Max-Forwards: 16.
From: "31765123456" <sip:31765123456@10.0.0.10>;tag=9Z7avj87Bc2gm.
To: <sip:3110123456@10.0.0.16:5060>.
Call-ID: e089c971-f3a8-1231-c2bb-000c2941b070.
CSeq: 54291565 INVITE.
Contact: <sip:mod_sofia@10.0.0.10:5060>.
User-Agent: CM Carrier SBC.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, NOTIFY.
Supported: timer, precondition, path, replaces.
Allow-Events: talk, hold, conference, refer.
Content-Type: application/sdp.
Content-Disposition: session.
Content-Length: 205.
Hi,
Any idea what attrs are in dispatcher.cfg?
When I do a kamctl fifo ds_list, I can put some strings in this field.
Is it used for labelling of the SIP URIs?
The documentation is a bit obscure for me.
If I put hello as the last item on dispatcher.cfg, I see it when I do a ds_list:
$ kamctl fifo ds_list
SET:: 99
URI:: sip:127.0.0.1:5060 flags=AP priority=0 attrs=hello
Best,
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
Hello,
Kamailio SIP Server v4.1.1 stable release is out.
This is a maintenance release of the latest stable branch, 4.1, that
includes fixes since release of v4.1.0. There is no change to database
schema or configuration language structure that you have to do on
installations of v4.1.0. Deployments running previous v4.x.x versions
are strongly recommended to be upgraded to v4.1.1.
For more details about version 4.1.1 (including links and guidelines to
download the tarball or from GIT repository), visit:
* http://www.kamailio.org/w/2014/01/kamailio-v4-1-1-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda