My understanding is that it would be the former - you can't really reply to a reply. :-) Besides, this technique is used in other contexts; for example, final failure is signaled out of failure routes to the calling party when dispatcher rollover runs out of gateways to serially fork across.
-- Sent from mobile device
On Nov 10, 2009, at 8:49 PM, Geoffrey Mina geoffreymina@gmail.com wrote:
One question on this...
In my scenario, would using t_reply in failure_route send the response to the party who sent the INVITE or the party who sent a message which caused Kamailio to end up in failure_route?
On Tue, Nov 10, 2009 at 10:38 AM, Alex Balashov abalashov@evaristesys.com wrote:
geoffreymina@gmail.com wrote:
Hello, I have a need to translate a 486 from my asterisk server to a 600 when sending upstream to my carrier. The problem I am seeing is that when I return 486, the carrier re-presents the call to my next server in the SRV rotation... I really want the 486 to be a final disposition, so I am assuming sending a 600 would solve my issue.
I am not sure how to go about forwarding the message, but modifying the SIP code... is that even allowed?
This would be something like what I'm trying to do:
failure_route[1]{ if(t_check_status("
Sure, you can do that. It is not a good idea to do so in principle because it violates how proxies should behave; proxies are very thin interoperation layers that are designed to statefully pass requests and replies back and forth more or less strictly as intended by the endpoints involved, and a B2BUA would more ideally fit your goal. Nevertheless, it is possible.
failure_route[1] {
if(t_was_cancelled()) exit; if(t_check_status("486")) { t_reply("603", "Declined"); exit; }}
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671