[SR-Users] Logging from cfg file
Hi everyone,
I have recently started working on Kamailio, I am trying to learn the
basics. For "Register" route, I am trying to print the log but log is not
appearing in log file. Other logs are there, only this one is missing.
*if(is_method("REGISTER")){*
* log(2, "Register request");*
*}*
I will be really helpful if you can help me with this.
Thanks & Kind Regards
*Regards,*
*M.Allaudin*
*Software EngineerNowtel GroupPhone # +92-333-8291874Blogger @
allaudin.github.io *
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dispatcher probing
On 12/28/18 7:49 AM, Duarte Rocha wrote: In this case ( using Options for probing), i only have access to the destination IP ($dd) and Port ($dp). I need to know the SAP associated to the gateway that is currently being probed, in order to force the correct socket in the OPTIONS request. Is there any way to get more info about the db line that is being read by dispatcher for the probing? Take a look at xavp_dst_mode: https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html#dispatcher.p.xavp_dst_mode As well as ds_db_extra_attrs: https://www.kamailio.org/docs/modules/stable/modules/dispatcher.html#dispatcher.p.ds_db_extra_attrs Both of these allow you to set the socket. I've used the db extras in the past without issue. --fred ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Dispatcher probing
Hey. I have another question regarding the Dispatcher Probing. In my SBC, a Gateway is defined by it's IP, Port and SAP (Kamailio's IP used for signaling). Those 3 parameters are defined in the Gateway table. In this case ( using Options for probing), i only have access to the destination IP ($dd) and Port ($dp). I need to know the SAP associated to the gateway that is currently being probed, in order to force the correct socket in the OPTIONS request. Is there any way to get more info about the db line that is being read by dispatcher for the probing? If that's not possible i was thinking about querying my db for the Ip:Port pair and if i got more than one result, do forking using the the SAPs in the results, sending multiple OPTIONS through the multiple sockets. In this case, if only one of the OPTIONS is answered, will the gateway still appear as "Active" ? Best Regards, Duarte Rocha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
On Fri, 28 Dec 2018 at 10:32, Daniel-Constantin Mierla wrote: > I just pushed a series of commits trying to rework how loading (and > reloading) of rtpegines list is done, to avoid that sync'ed probing, > which can take long if any of the rtpengines is down. > I just want to thank you for this great new year gift. :-) ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > I just pushed a series of commits trying to rework how loading (and > reloading) of rtpegines list is done, to avoid that sync'ed probing, > which can take long if any of the rtpengines is down. Daniel, Thanks for the commit. Now K starts responding immediately also in db mode even if some rtp proxies are not responding to ping. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
I just pushed a series of commits trying to rework how loading (and reloading) of rtpegines list is done, to avoid that sync'ed probing, which can take long if any of the rtpengines is down. Now, building the local (per process) structures/sockets for rtpengines during kamailio start up is done without locking. This is guarded by the fact a reload command can be executed only after all children were initialized (added also with these commits). Moreover, the probing of rtpeningesis done only by child process 1, because the status is stored in shared memory list, so it is visible in all children. Based on my understanding there, doing probing from all processes is useless now, that was probably kept from the time when the list was not stored in shared memory, from the early rtpproxy times. There is also a restriction on how often the rtpengine list can be reloaded, now having a 10 seconds interval guard. I added this because the reload is done over the old list, not building a new list to swap with the old one. So it requires some time to walk through the existing list and update based on the new records. I went this way for now, even building a new list may be better/safer in long term, but it would require more work. I also wanted to avoid being very intrusive right now, given that those patches would need to be backported. The last relevant change was to use a version number to discover when a reload was done. So far, as I understood, it was relying on the number of rtpengines, but one may trigger a reload with same rtpengines, but different attributes (e.g., disabled or not). Having a version number is better in detecting when each worker needs to rebuild its local list of sockets, as well as for troubleshooting, because a value is increased with each reload, so easier to track if it was done or now. I didn't have time for any tests, so it would be good if you can test and report if works as expected. All related commits are in master, if they prove to work fine, we can backport all those patches. Cheers, Daniel On 26.12.18 12:46, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > >> I pushed a quick fix for the case when db support is not enabled, >> because these locks are useless in that case, so all children will do >> the rtpengine init at the same time, without waiting for the others: > Still took in rtpengine db mode about 2 minutes before kamailio became > responsive after start. > > -- Juha -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Indeed I stopped at the wrong param for the timeout, should have been
another one:
modparam("rtpengine", "rtpengine_tout_ms", 500)
Cheers,
Daniel
On 26.12.18 12:16, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Maybe you would also want to tune the timeout with the modparam:
>>
>> modparam("rtpengine", "rtpengine_disable_tout", 5)
>>
>> So detection of unavailable rtpproxy is fast, otherwise it is 60 sec by
>> default, so you may still experience some slow start per child
>> process.
> I understand from the param description that it tells how to behave
> AFTER rtp proxy has been marked disabled:
>
> Once an RTP proxy was found unreachable and marked as disabled, the
> rtpengine module will not attempt to establish communication to that
> RTP proxy for rtpengine_disable_tout seconds.
>
> The problem that I have experienced is that it takes long time (2
> minutes or so) before rtpengine modules disables a non-responding
> rtp proxy.
>
> Also, no matter what the module does, it must not make the whole sip
> proxy non-responsive for any number of seconds.
>
> -- Juha
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in
Washington, DC, USA -- www.asipto.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
