Hello, the request sent out by Kamailio's dispatcher module should be visible inside kamailio.cfg via: event_route[tm:local-request] { ... } Note that this route block is executed for the requests generated by kamailio (apart of nat keepalives), so if there are other modules sending out new requests (like msilo, presence, ...), be sure you do proper conditions there, like: if(is_method("OPTIONS")) You can also do checking on From header address, there is a parameter for dispatcher to set that address, so you know what to match. Cheers, Daniel On 27.12.18 17:02, Duarte Rocha wrote: -- 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

Hey. I have another question regarding this. 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, i only have access to the 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 Na(o) quinta, 27/12/2018, 16:02, Duarte Rocha <duarterocha91(a)gmail.com> escreveu: