Hello
I am following up on the improper sip dialog that has been fixed by storing contact details into a htable.
I am trying to delete the key at the end of the call, so the table doesnt grow exponentially.
I've added a event_route[dialog:end] {} block, but I see it is processed BEFORE the BYE is processed in the request_route(). Therefore, when I delete the data in the htable, I cant relay this BYE correctly.
Is there another event (or technique) I could use to purge the htable ? doing from a cron on the cmd line is not so nice, and can delete data still needed for current calls
thanks J.
Hello Any suggestions ? still struggling with this,
Rgds
On Fri, Jan 19, 2018 at 3:09 PM, Jean Cérien cerien.jean@gmail.com wrote:
Hello
I am following up on the improper sip dialog that has been fixed by storing contact details into a htable.
I am trying to delete the key at the end of the call, so the table doesnt grow exponentially.
I've added a event_route[dialog:end] {} block, but I see it is processed BEFORE the BYE is processed in the request_route(). Therefore, when I delete the data in the htable, I cant relay this BYE correctly.
Is there another event (or technique) I could use to purge the htable ? doing from a cron on the cmd line is not so nice, and can delete data still needed for current calls
thanks J.
Hello,
one option is to set the expire time in event_route to few seconds, so it is still available for handling the BYE.
You should also set an auto-expire for the table entries to the max dialog lifetime that you allow, as a safety backup.
Cheers, Daniel
On 22.01.18 13:59, Jean Cérien wrote:
Hello Any suggestions ? still struggling with this,
Rgds
On Fri, Jan 19, 2018 at 3:09 PM, Jean Cérien <cerien.jean@gmail.com mailto:cerien.jean@gmail.com> wrote:
Hello I am following up on the improper sip dialog that has been fixed by storing contact details into a htable. I am trying to delete the key at the end of the call, so the table doesnt grow exponentially. I've added a event_route[dialog:end] {} block, but I see it is processed BEFORE the BYE is processed in the request_route(). Therefore, when I delete the data in the htable, I cant relay this BYE correctly. Is there another event (or technique) I could use to purge the htable ? doing from a cron on the cmd line is not so nice, and can delete data still needed for current calls thanks J.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Many thanks, this works ! J.
On Tue, Jan 23, 2018 at 3:45 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
one option is to set the expire time in event_route to few seconds, so it is still available for handling the BYE.
You should also set an auto-expire for the table entries to the max dialog lifetime that you allow, as a safety backup.
Cheers, Daniel
On 22.01.18 13:59, Jean Cérien wrote:
Hello Any suggestions ? still struggling with this,
Rgds
On Fri, Jan 19, 2018 at 3:09 PM, Jean Cérien cerien.jean@gmail.com wrote:
Hello
I am following up on the improper sip dialog that has been fixed by storing contact details into a htable.
I am trying to delete the key at the end of the call, so the table doesnt grow exponentially.
I've added a event_route[dialog:end] {} block, but I see it is processed BEFORE the BYE is processed in the request_route(). Therefore, when I delete the data in the htable, I cant relay this BYE correctly.
Is there another event (or technique) I could use to purge the htable ? doing from a cron on the cmd line is not so nice, and can delete data still needed for current calls
thanks J.
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
On the other hand, as I thought about it, the event_route[dialog:end] is executed either by loose_route() or dlg_manage() -- which one is executed first in the config file, so you have the BYE in config before the event_route.
Only when the BYE is generated by Kamailio, there is no request_route execution.
Cheers, Daniel
On 23.01.18 14:13, Jean Cérien wrote:
Many thanks, this works ! J.
On Tue, Jan 23, 2018 at 3:45 AM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, one option is to set the expire time in event_route to few seconds, so it is still available for handling the BYE. You should also set an auto-expire for the table entries to the max dialog lifetime that you allow, as a safety backup. Cheers, Daniel On 22.01.18 13:59, Jean Cérien wrote:
Hello Any suggestions ? still struggling with this, Rgds On Fri, Jan 19, 2018 at 3:09 PM, Jean Cérien <cerien.jean@gmail.com <mailto:cerien.jean@gmail.com>> wrote: Hello I am following up on the improper sip dialog that has been fixed by storing contact details into a htable. I am trying to delete the key at the end of the call, so the table doesnt grow exponentially. I've added a event_route[dialog:end] {} block, but I see it is processed BEFORE the BYE is processed in the request_route(). Therefore, when I delete the data in the htable, I cant relay this BYE correctly. Is there another event (or technique) I could use to purge the htable ? doing from a cron on the cmd line is not so nice, and can delete data still needed for current calls thanks J. _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
-- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com <http://www.asipto.com> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com <http://www.kamailioworld.com>