Hello,
On 11/12/10 3:17 AM, JR Richardson wrote:
On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz Castilloibc@aliax.net wrote:
2010/11/11 JR Richardsonjmr.richardson@gmail.com:
I was thinking about including this in my failure route:
if (t_check_status("486")) { append_branch(); t_relay(); }
Would that do any good?
The above code instructs Kamailio to create a new branch to the same destination upon receipt of hte 486 response. So obviously it's wrong. What do you want to achieve with the above code??
-- Iñaki Baz Castillo ibc@aliax.net
Hello,
The idea is to receive the 486 from the carrier and not send the INVITE SDP back to the carrier, this is causing the carrier to send a 482 loop detected.
First, if you create a new branch and send to same SIP gateway and you get loop detected, then the gateway is broken. It does not see that there is a different branch value in the top Via header.
I would like to recognize the 486 response from the carrier as a busy and relay it to the original INVITE server then exit, so then another route can be processed by the INVITE server and not handled as a loop and dropped.
I don't understand why kamailio would send an ACK then an INVITE SDP to the carrier after receiveng a 486 Busy?
So the append_branch should not be used, ok, what about just the t_relay and exit?
if (t_check_status("486")) { t_relay(); exit; }
Would this work?
t_relay() is only for SIP __requests__, not for SIP __replies__.
If you want to let the 486 go back to the initiator of INVITE, just exit the failure route:
if (t_check_status("486")) { exit; }
In case you want to change the reply code to something else, then you can use t_reply() to overwrite the reply received, for example, change the 486 is 404:
if (t_check_status("486")) { t_reply("404", "Not found"); exit; }
This is a production system, so I can't just throw trial and error code at it and hope it works. I'm not sure how to mock up and test the various codes I'm seeing from the carrier. My test lab works great with basic functionality and execution, I'm only seeing some of these scenarios in production.
So far, I haven't seen a better testing suite than a production environment ;-)
Cheers, Daniel
Thanks for your suggestions.
JR