Kamailio 3.3.3
I am using dialog module to do the concurrent call limit. Once a while I got a dead unconfirmed dialog hung in memory. The only way I know to cleanup this is to restart kamailio. So my questions are: 1) Does anybody know a better way to cleanup the dead dialog without having to restart the kamailio server? This is a production server. I really really hate to restart the server. 2) How easy to modify the source code to timeout the dead unconfirmed dialog in memory?
Gary
Hi, Gary. I had same problem. Try to use "db_mode" parameter of dialog module with 1 value.
1 - REALTIME - any dialog information changes will be reflected into the database immediatly.
Then you can kill the dead dialogs through database.
From: sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Gary Chen Sent: Tuesday, July 02, 2013 4:14 PM To: Kamailio (SER) - Users Mailing List Subject: [SR-Users] How to cleanup unconfirmed dialog in memory?
Kamailio 3.3.3
I am using dialog module to do the concurrent call limit. Once a while I got a dead unconfirmed dialog hung in memory. The only way I know to cleanup this is to restart kamailio. So my questions are: 1) Does anybody know a better way to cleanup the dead dialog without having to restart the kamailio server? This is a production server. I really really hate to restart the server.
2) How easy to modify the source code to timeout the dead unconfirmed dialog in memory?
Gary
Thanks for suggestion. I will give it try. Since every call will have to check database, will this effect the performance of Kamailio for high volume server?
Gary
On Tue, Jul 2, 2013 at 8:55 AM, I.Pavlov ip@izhnet.ru wrote:
Hi, Gary. I had same problem. Try to use “db_mode” parameter of dialog module with 1 value.****
*1 - REALTIME* - any dialog information changes will be reflected into the database immediatly.****
Then you can kill the dead dialogs through database.****
*From:* sr-users-bounces@lists.sip-router.org [mailto: sr-users-bounces@lists.sip-router.org] *On Behalf Of *Gary Chen *Sent:* Tuesday, July 02, 2013 4:14 PM *To:* Kamailio (SER) - Users Mailing List *Subject:* [SR-Users] How to cleanup unconfirmed dialog in memory?****
Kamailio 3.3.3****
I am using dialog module to do the concurrent call limit. Once a while I got a dead unconfirmed dialog hung in memory. The only way I know to cleanup this is to restart kamailio. So my questions are:
- Does anybody know a better way to cleanup the dead dialog without
having to restart the kamailio server? This is a production server. I really really hate to restart the server.****
- How easy to modify the source code to timeout the dead unconfirmed
dialog in memory? ****
Gary ****
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
Hi,
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.
Regards,
Charles
On 2 July 2013 14:10, Gary Chen gchen3203@gmail.com wrote:
Thanks for suggestion. I will give it try. Since every call will have to check database, will this effect the performance of Kamailio for high volume server?
Gary
On Tue, Jul 2, 2013 at 8:55 AM, I.Pavlov ip@izhnet.ru wrote:
Hi, Gary. I had same problem. Try to use “db_mode” parameter of dialog module with 1 value.****
*1 - REALTIME* - any dialog information changes will be reflected into the database immediatly.****
Then you can kill the dead dialogs through database.****
*From:* sr-users-bounces@lists.sip-router.org [mailto: sr-users-bounces@lists.sip-router.org] *On Behalf Of *Gary Chen *Sent:* Tuesday, July 02, 2013 4:14 PM *To:* Kamailio (SER) - Users Mailing List *Subject:* [SR-Users] How to cleanup unconfirmed dialog in memory?****
Kamailio 3.3.3****
I am using dialog module to do the concurrent call limit. Once a while I got a dead unconfirmed dialog hung in memory. The only way I know to cleanup this is to restart kamailio. So my questions are:
- Does anybody know a better way to cleanup the dead dialog without
having to restart the kamailio server? This is a production server. I really really hate to restart the server.****
- How easy to modify the source code to timeout the dead unconfirmed
dialog in memory? ****
Gary ****
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
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
What if you set the default dialog timeout to a value much less than 12/14 hours, maybe 2 hours. It's very unlikely that a session last that long.
On Tue, Jul 2, 2013 at 9:23 AM, Charles Chance < charles.chance@sipcentric.com> wrote:
Hi,
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.
Regards,
Charles
On 2 July 2013 14:10, Gary Chen gchen3203@gmail.com wrote:
Thanks for suggestion. I will give it try. Since every call will have to check database, will this effect the performance of Kamailio for high volume server?
Gary
On Tue, Jul 2, 2013 at 8:55 AM, I.Pavlov ip@izhnet.ru wrote:
Hi, Gary. I had same problem. Try to use “db_mode” parameter of dialog module with 1 value.****
*1 - REALTIME* - any dialog information changes will be reflected into the database immediatly.****
Then you can kill the dead dialogs through database.****
*From:* sr-users-bounces@lists.sip-router.org [mailto: sr-users-bounces@lists.sip-router.org] *On Behalf Of *Gary Chen *Sent:* Tuesday, July 02, 2013 4:14 PM *To:* Kamailio (SER) - Users Mailing List *Subject:* [SR-Users] How to cleanup unconfirmed dialog in memory?****
Kamailio 3.3.3****
I am using dialog module to do the concurrent call limit. Once a while I got a dead unconfirmed dialog hung in memory. The only way I know to cleanup this is to restart kamailio. So my questions are:
- Does anybody know a better way to cleanup the dead dialog without
having to restart the kamailio server? This is a production server. I really really hate to restart the server.****
- How easy to modify the source code to timeout the dead unconfirmed
dialog in memory? ****
Gary ****
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
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 hw@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
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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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.ruizdiaz@gmail.com wrote:
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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
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.chance@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.ruizdiaz@gmail.com wrote:
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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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.ruizdiaz@gmail.com wrote:
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.chance@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.ruizdiaz@gmail.com wrote:
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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
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.chance@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.ruizdiaz@gmail.com wrote:
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.chance@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.ruizdiaz@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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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=fa0...
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.chance@sipcentric.com mailto:charles.chance@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.ruizdiaz@gmail.com <mailto:carlos.ruizdiaz@gmail.com>> wrote: 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.chance@sipcentric.com <mailto:charles.chance@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.ruizdiaz@gmail.com <mailto:carlos.ruizdiaz@gmail.com>> wrote: 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.chance@sipcentric.com <mailto:charles.chance@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 <hw@kamailio.org <mailto:hw@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 <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592 <tel: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 <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Carlos http://caruizdiaz.com +595981146623 <tel:%2B595981146623> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- *Charles Chance* Managing Director t. 0121 285 4400 m. 07932 063 891 www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592 <tel: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 <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Carlos http://caruizdiaz.com +595981146623 <tel:%2B595981146623> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592 <tel: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 <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Carlos http://caruizdiaz.com +595981146623
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
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 miconda@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=fa0...
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.chance@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.ruizdiaz@gmail.com wrote:
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.chance@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.ruizdiaz@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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
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.chance@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 miconda@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=fa0...
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.chance@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.ruizdiaz@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.chance@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.ruizdiaz@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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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 > > Follow us on twitter @sipcentric http://twitter.com/sipcentric > > 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
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
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
Hi Gary,
Are you looking at the correct dialog? Before the BYE message, an ongoing dialog will have already moved from state 1 through 2, 3, 4 and finally state 5 after the BYE, before being cleared automatically after a few seconds.
Perhaps there are two dialogs being created for the same initial request? Maybe due to retransmissions or an error in config? If you can supply your config we may be able to get a better idea.
Regards,
Charles
On 4 July 2013 04:09, Gary Chen gchen3203@gmail.com wrote:
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.chance@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 miconda@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=fa0...
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.chance@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.ruizdiaz@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.chance@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.ruizdiaz@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-tim... > > > On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < > charles.chance@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 hw@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 >> >> Follow us on twitter @sipcentric http://twitter.com/sipcentric >> >> 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 > > _______________________________________________ > 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 > >
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
I added a timer process in dialog module to clean all unconfirmed dialogs that are older than 5min (timer runs every 90 secs -- later i will add mod params to tune these values).
But, in your case, is the BYE coming before 200ok for INVITE or after?
Cheers, Daniel
On 7/4/13 5:09 AM, Gary Chen wrote:
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.chance@sipcentric.com mailto:charles.chance@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 <miconda@gmail.com <mailto:miconda@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.chance@sipcentric.com <mailto:charles.chance@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.ruizdiaz@gmail.com <mailto:carlos.ruizdiaz@gmail.com>> wrote: 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.chance@sipcentric.com <mailto:charles.chance@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.ruizdiaz@gmail.com <mailto:carlos.ruizdiaz@gmail.com>> wrote: 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.chance@sipcentric.com <mailto:charles.chance@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 <hw@kamailio.org <mailto:hw@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 <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592 <tel: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 <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Carlos http://caruizdiaz.com +595981146623 <tel:%2B595981146623> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- *Charles Chance* Managing Director t. 0121 285 4400 m. 07932 063 891 www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592 <tel: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 <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Carlos http://caruizdiaz.com +595981146623 <tel:%2B595981146623> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592 <tel: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 <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Carlos http://caruizdiaz.com +595981146623 <tel:%2B595981146623> _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> 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 <mailto:sr-users@lists.sip-router.org> http://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
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.chance@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 miconda@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=fa0...
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.chance@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.ruizdiaz@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.chance@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.ruizdiaz@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-tim...
On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < charles.chance@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 hw@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 > > Follow us on twitter @sipcentric http://twitter.com/sipcentric > > 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
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
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
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.chance@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.chance@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 miconda@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=fa0...
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.chance@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.ruizdiaz@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.chance@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.ruizdiaz@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-tim... > > > On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance < > charles.chance@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 hw@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 >> >> Follow us on twitter @sipcentric http://twitter.com/sipcentric >> >> 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 > > _______________________________________________ > 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 > >
-- *Charles Chance* Managing Director
t. 0121 285 4400 m. 07932 063 891
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
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 Ruiz Díaz -
Charles Chance -
Daniel-Constantin Mierla -
Gary Chen -
Henning Westerholt -
I.Pavlov