from:"Gary Chen"

Re: [SR-Users] How to cleanup unconfirmed dialog in memory?

2013-07-07 Thread Gary Chen

I am unable to recreate the problem. I will keep eye on it. If it happen
again, I will report back here.
gary

On Fri, Jul 5, 2013 at 3:52 AM, Charles Chance
charles.cha...@sipcentric.com wrote:

Hi Daniel,

If someone can try it and confirm is working fine for sl replied dialogs
as well as for those forwarded, I will backport.

Seems to work fine for us in our test environment. So far, no unconfirmed
dialogs stuck in memory for statelessly replied transactions.

Cheers,

Charles

On 3 July 2013 17:25, Charles Chance charles.cha...@sipcentric.comwrote:

Hi Daniel,

Sounds perfect! I will try to test here tomorrow and let you know.

Cheers,

Charles

On 2 July 2013 22:44, Daniel-Constantin Mierla mico...@gmail.com wrote:

Hello,

I pushed a patch in master that detects when the dialog is created by
not getting to transaction due to a stateless reply.

http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=fa0339b1906690f009786fc9ed92c73a8c9e6520;hp=b4682cac2e2f151288a411018da077b6d1526eca

If someone can try it and confirm is working fine for sl replied dialogs
as well as for those forwarded, I will backport.

Cheers,
Daniel

On 7/2/13 4:22 PM, Carlos Ruiz Díaz wrote:

Now that you mention it, it makes perfect sense since this function
sends BYE to both legs which only makes sense with confirmed dialogs.

I run out of alternatives. Maybe patching the module is the only
solution.

Regards,
Carlos

On Tue, Jul 2, 2013 at 10:16 AM, Charles Chance
charles.cha...@sipcentric.com wrote:

That doesn't work I'm afraid. Also from
http://www.kamailio.org/docs/modules/3.1.x/modules_k/dialog.html#id2524783:

*Note: Works only for confirmed dialogs.*

It's something I've been meaning to look further into for a while,
but haven't yet had chance. I suspect a small patch will be required
though.

Regards,

Charles

On 2 July 2013 15:11, Carlos Ruiz Díaz carlos.ruizd...@gmail.comwrote:

Ok, I haven't noticed that, although I can't tell for sure whether it
will work or not.

If you can dump the dialogs using xmlrpc or rpc interface, maybe you
could parse the info and tear down those unconfirmed dialogs using
dlg_end_dlg:

http://www.kamailio.org/docs/modules/3.1.x/modules_k/dialog.html#id2524783

On Tue, Jul 2, 2013 at 10:02 AM, Charles Chance
charles.cha...@sipcentric.com wrote:

The parameter does not work for us. We have modparam(dialog,
default_timeout,7200), but it only has an effect on confirmed dialogs.
As
you can see from my previous example, there is not even a timestart
value
on the unconfirmed dialog, so how can Kamailio know when timeout is
reached?

On 2 July 2013 14:51, Carlos Ruiz Díaz carlos.ruizd...@gmail.comwrote:

There is, but for all dialogs, not only the unconfirmed ones.

http://www.kamailio.org/docs/modules/3.3.x/modules_k/dialog.html#default-timeout-id

On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance
charles.cha...@sipcentric.com wrote:

Hmm, I don't think there is even a timeout value set on unconfirmed
dialogs in memory.

Example (Kamailio 3.3.3):

dialog:: hash=1791:10106
state:: 1
ref_count:: 1
timestart:: 0
timeout:: 0
...

Whereas:

dialog:: hash=2963:2808
state:: 4
ref_count:: 2
timestart:: 1372772302
timeout:: 114829207
...

Therefore, the unconfirmed dialogs never get cleared
automatically, in my experience at least. I hope I'm wrong though :)

Cheers,

Charles

On 2 July 2013 14:31, Henning Westerholt h...@kamailio.org wrote:

Am Dienstag, 2. Juli 2013, 14:23:25 schrieb Charles Chance:
I don't think this will help at all, as regardless of DB mode,
unconfirmed
dialogs are not stored in DB anyway.

The important thing to remember is that if you are calling
dialog_manage()
in your config, to only do it once you are ready to forward the
request. If
you call it but then exit for some reason without actually
forwarding, you
will probably end up with a stuck dialog.

Maybe someone else can suggest other possible causes?

To my knowledge, there is no existing way to clear these without
restarting.

Hello,

AFAIK these stale dialogs are cleaned up after the dialog timeout.
There are
module parameter and also dialog specific parameter to control
this variable.
This stale dialogs needs a bit of memory, but are otherwise
harmless.

Best regards,

Henning

www.sipcentric.com

Sipcentric Ltd. Company registered in England Wales no. 7365592.
Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South,
Birmingham
B7 4EJ.

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--
Carlos
http://caruizdiaz.com
+595981146623

Re: [SR-Users] Load database table in memory

2013-07-03 Thread Gary Chen

I am using mtree for the same purpose and it works great. It never expire.
I had loaded about 7 millions records in mtree table and there is no
performance issue at all.

Gary


On Wed, Jul 3, 2013 at 7:57 AM, Alex Balashov abalas...@evaristesys.comwrote:

 Sure, you can do it that way.  However, htable and mtree accommodate
 relatively primitive data sets.

 Given sufficient table complexity and/or size, your best bet is to use an
 in-memory storage backend on the database side itself.

 In MySQL, this is called:


 http://dev.mysql.com/doc/**refman/5.7/en/memory-storage-**engine.htmlhttp://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html

 -- Alex


 On 07/03/2013 05:41 AM, Grant Bagdasarian wrote:

  Hello,

 I need to query a database for every SIP request coming into Kamailio,
 but I want this to be handled as fast as possible, so I was thinking of
 loading the data I need in memory using the HTABLE or MTREE modules.

 When the SIP request is coming from one of our carriers, the called
 number ($rU) must be used to get the data for this called number.
 Normally, I would query the database, using sqlops, and pass the value
 of $rU as the parameter and get the column values using the $dbr
 variable. Can this be accomplished with HTABLE or MTREE?

 Also, the autoexpire parameter in HTABLE; once expired, will the data be
 reloaded again from the database?

 Thanks,


 Grant



 __**_
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



 --
 Alex Balashov - Principal
 Evariste Systems LLC
 235 E Ponce de Leon Ave
 Suite 106
 Decatur, GA 30030
 United States
 Tel: +1-678-954-0670
 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

 __**_
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to cleanup unconfirmed dialog in memory?

2013-07-03 Thread Gary Chen

We need also have a way to timeout all the dead unconfirmed dialog. I have
a situation that the SIP message was perfect fine with Bye signal, yet the
dialog is still hang with state 1.

Gary

On Wed, Jul 3, 2013 at 12:25 PM, Charles Chance
charles.cha...@sipcentric.com wrote:

Hi Daniel,

Sounds perfect! I will try to test here tomorrow and let you know.

Cheers,

Charles

On 2 July 2013 22:44, Daniel-Constantin Mierla mico...@gmail.com wrote:

Hello,

I pushed a patch in master that detects when the dialog is created by not
getting to transaction due to a stateless reply.

http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=fa0339b1906690f009786fc9ed92c73a8c9e6520;hp=b4682cac2e2f151288a411018da077b6d1526eca

If someone can try it and confirm is working fine for sl replied dialogs
as well as for those forwarded, I will backport.

Cheers,
Daniel

On 7/2/13 4:22 PM, Carlos Ruiz Díaz wrote:

Now that you mention it, it makes perfect sense since this function
sends BYE to both legs which only makes sense with confirmed dialogs.

I run out of alternatives. Maybe patching the module is the only
solution.

Regards,
Carlos

On Tue, Jul 2, 2013 at 10:16 AM, Charles Chance
charles.cha...@sipcentric.com wrote:

That doesn't work I'm afraid. Also from
http://www.kamailio.org/docs/modules/3.1.x/modules_k/dialog.html#id2524783:

*Note: Works only for confirmed dialogs.*

It's something I've been meaning to look further into for a while, but
haven't yet had chance. I suspect a small patch will be required though.