[SR-Users] Apply changes made to sip reply in onreply_route

[Grant Bagdasarian]

It's for our logging. Each INVITE is pretty much a separate row in our logging table. Responses and in-dialog requests on the INVITE trigger an update on the row, where the state of the row is updated.
This allows us to see in which (custom) state each call is.

Each time the Dispatcher tries a destination, an INVITE goes out and is also captured. A row is then created in our logging table. When the destination replies with a 500, the state should be changed to "Failed".
When the Dispatcher tries the next destination, this should trigger a new row in the table.

I'm using custom headers to store and pass data around, which are used by our services to translate the SIP messages into our own format for logging.

From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Klaus Darilion
Sent: Tuesday, October 8, 2013 2:51 PM
To: sr-users at lists.sip-router.org
Subject: Re: [SR-Users] Apply changes made to sip reply in onreply_route

Am 08.10.2013 12:14, schrieb Grant Bagdasarian:
Hello,

I've setup two Kamailio machines, one which does all the processing and the second one which always replies with a 500 Server Internal Error, to test my Dispatcher fail-over.
When routing a call, the call is always routed to the second Kamailio first, to test the fail-over.

What happens in this scenario is the 500 is received by the main Kamailio and the 500 message is duplicated to the capture server. After this the failure_route kicks in and the 500 is obviously never sent back to the initiator.
The changes made to the 500 message  (adding a new header), in onreply_route, aren't present when the message is duplicated to the capture server, because the original 500 message is duplicated instead of the modified one.
Out of curiosity -why do you add a header to the response if it is likely to be dropped (depending of the response in the second branch)? Just to signal data to the capture server?

klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131008/464368fe/attachment.html>