[SR-Users] /usr/sbin/kamailio - unresolvable destination error

Hi, Please help to sort the problem. Getting "Unresolvable destination" error in /var/log/messages. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org

Re: [SR-Users] Dropping non-provisional replies in onreply_route

Yes, transaction will be ended, onsend_route is executed after all transaction processing was done. There might be some error messages in the logs, but that can be eventually tuned with a small patch. Cheers, Daniel On 21/10/16 14:30, Alex Balashov wrote: > Thanks, that's a good idea! > > If I

Re: [SR-Users] Dropping non-provisional replies in onreply_route

Thanks, that's a good idea! If I use the onsend route, I can still expect the transaction life to come to an end at this point, right? If not, I need some other way of manually sunsetting transactions. On October 21, 2016 8:23:01 AM EDT, Daniel-Constantin Mierla wrote:

Re: [SR-Users] Dropping non-provisional replies in onreply_route

One addition that was done rather recent is execution of onsend_route for replies (it may require a core param to be set) and maybe you can drop there based on an avp -- it may be a solution if you don't care about transaction, but only not to send the sip response to the end point. Cheers,

Re: [SR-Users] Edge proxy / Registrar Script

Hi, Thanks. I used dispatcher example for proxy file , populated the dispatcher table and added modparam("path", "use_received", 1) to config file. And used the kamailio-basic.cfg for registrar with modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 1)

Re: [SR-Users] Dropping non-provisional replies in onreply_route

Yeah, I'm trying to avoid something complex like keeping state in htable. I did try it - the docs are correct. drop() on a >= 2xx reply does nothing in a named (TM) onreply_route[]. I really don't care if the transaction is completed internally. I just want to stop the reply going back to

Re: [SR-Users] Dropping non-provisional replies in onreply_route

You can try it, not sure if docs are really in sync there. On the other hand, could be that the transaction was matching the 2xx and then practically the state of transaction changed to completed, so even doing a drop of not sending out, the transaction is still ended. An alternative solution is

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

Hello, On 21/10/16 11:22, Jurijs Ivolga wrote: > Hi Daniel, > > After 8 days there is still small memory leak, 200MB of Ram wasn't > freed during this 8 days, please check diagram below. > > 1) Is this something usual? > 2) Memory leak seems very small, maybe I should never worry about > this?

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

Hi Daniel, After 8 days there is still small memory leak, 200MB of Ram wasn't freed during this 8 days, please check diagram below. 1) Is this something usual? 2) Memory leak seems very small, maybe I should never worry about this? What you think? [image: Inline image 2] Thank you! With kind

Re: [SR-Users] Basic TM suspend question

On 21/10/16 11:26, Alex Balashov wrote: > On 10/21/2016 05:22 AM, Daniel-Constantin Mierla wrote: > >> Also the timeout runs for it and failure_route can be executed in >> that case. > > Interesting. That brings up two more questions: > > 1. If fr_timer is set to 3000 but I suspend the

Re: [SR-Users] Basic TM suspend question

On 10/21/2016 05:22 AM, Daniel-Constantin Mierla wrote: Also the timeout runs for it and failure_route can be executed in that case. Interesting. That brings up two more questions: 1. If fr_timer is set to 3000 but I suspend the transaction for 4 seconds, does that mean that failure_route

[SR-Users] Dropping non-provisional replies in onreply_route

The core documentation says that in a named onreply_route[], only provisional replies can be drop()'d. To drop any reply, it is necessary to use a global onreply_route. Is there any workaround for this, i.e. so I can drop a 2xx reply from a specific TM transaction? The reason is, to know

Re: [SR-Users] Basic TM suspend question

Hello, On 20/10/16 21:51, Alex Balashov wrote: > Hi, > > If a transaction is currently t_suspended() and has not been > t_continued(), will t_check_trans() still find that transaction for > retransmission-dampening purposes, e.g. if a retransmission of the > same request as the original one is

Re: [SR-Users] Postgres: Exclusive Transaction Locks vs. Vacuumer

Hello, I haven't added that part of code, nor using postgres to be able to comment on specific points, but my blind guess is that there are many queries done in between the table locks, like a check if a record exist, followed by insert/update/delete/..., so just locking on a row might not

[SR-Users] Postgres: Exclusive Transaction Locks vs. Vacuumer

Hey everyone! We noticed that under high load of registrations and using the pua module we can reach a state where the PUA table bloats our Postgres to several GB. However, a SELECT on pua only shows a few hundred entries. The other half million or so entries are obsoleted but not cleaned up.