Hi All,
I spent a few hours this afternoon setting up a Homer SIP Capture server today. The build went well, good example setup howto's. My setup is a single kamailio/sipcature/homer node sitting on a LAN with 2 NIC's, eth0 for network access ssh/web, eth1 is the capture port connected to switch mirrored port. On the switch I have a kamailio proxy server being monitored.
All SIP traffic through the proxy server is logged to the homer server, but the homer server is receiving SIP packets on the capture interface and sending out SIP messages through the network access eth0 port. The messages are being processed from the on_reply route. The default config for the capture node is to capture all SIP packets, but this seems to create the problem. Here is the route and onreply_route default config:
route { sip_capture(); exit; }
onreply_route { sip_capture(); exit; }
If I replace the onreply_route exit; with drop; then the capture server no longer sends SIP messages out the eth0 interface and everything seems to work as expected.
So my question; what is the difference between a drop; and exit; within the on_reply route and how the hell is the capture server sending messages out the eth0 network interface when the server is 100% bound to eth1 capture interface?
Any insight or guidance is appreciated.
Thanks.
JR
On 01/16/2012 09:11 PM, JR Richardson wrote:
So my question; what is the difference between a drop; and exit; within the on_reply route
Remember that an onreply_route is a callback that allows you to intercept a reply, but the reply is forwarded by default afterward (if using stateful forwarding). This is different from a request route, where it's up to you to marshal everything, and to explicitly forward the message.
Thus, exiting an onreply_route has null effect. It doesn't do anything to stop the reply from being forwarded, because forwarding is the behaviour--the onreply_route is just a hook. In contrast, 'drop' explicitly drops the message and prevents further forwarding of the reply from taking place.
This is different than in a request route, where exiting precludes any forwarding action, because forwarding action must be taken explicitly -- e.g. t_relay().