Reply route
An onreply_route runs for replies travelling back towards the caller. Unlike a failure route it
sees every reply, provisional as well as final, and it cannot change where the request goes — it can
only inspect the response and edit its headers before OpenSIPS forwards it.
Like failure routes, a reply route belongs to a transaction and so needs the tm module. It is
armed on the request before relaying:
route {
if (!lookup("location")) {
send_reply("404", "Not Found");
exit;
}
# arm a reply route to see the incoming replies
t_on_reply("inspect_reply");
t_relay();
}
The block then branches on the status code:
onreply_route[inspect_reply] {
if (t_check_status("1[0-9][0-9]")) {
xlog("provisional reply $T_reply_code received\n");
} else if (t_check_status("2[0-9][0-9]")) {
xlog("successful reply $T_reply_code received\n");
remove_hf("User-Agent");
} else {
xlog("non-2xx reply $T_reply_code received\n");
}
}
$T_reply_code holds the code of the reply currently being processed, and remove_hf() strips a
header on its way out, which is a common way to hide which software the callee is running.
Worth keeping in mind:
- Provisional replies pass through the route repeatedly, once per 18x, so anything expensive here runs more than once per call.
- The route sees replies per branch. With forking, several branches may report back before a winner is chosen.
- A reply route cannot relay, retry or redirect. Use a failure route when the goal is to try another destination.