Hello,
you have to use append_hf() in the onreply route.
Cheers,
Daniel
On 7/18/12 7:20 AM, Uri Shacked wrote:
Hi
I tried the "change_reply_status".
The problem with it is that i need to do "append_to_reply" as well.
The first one can be called only on the "on reply" route, and the
second
Hi
I tried the "change_reply_status".
The problem with it is that i need to do "append_to_reply" as well. The
first one can be called only on the "on reply" route, and the second on the
"on failure" route.
And as i notice, doing "append_to_reply" with no "t_reply" does not really
append anythi
Hello,
sending a >=300 reply is for an not-established dialog, which eventually
can be forked by proxy, meaning many 1xx replies can get to caller, then
many >=300 replies can get to the proxy which will chose which one to
use for sending back to the caller.
Doing a t_reply(...) with a diffe
Hi,
Here is the problem with the solution to sending different reply then the
once I receive:
I check if the reply is 603. If so, i did t_drop_replies and then t_reply
with the reply i wanted to send back. 500 with append_to_reply something
The problem is that on the 500 that i send back
Hello,
this 503 to 500 is a requirement from RFC, to prevent propagation of
blacklisting/disabling destination hosts. I don't remember right now any
configuration option for it, but you can try to enforce it from the
failure route, like:
t_reply("503", "...");
Cheers,
Daniel
On 6/24/12 4:3
I just read the topic - "*Copy reason field from 503 to 500. * "
Is there a way to change it if i want to send back the original leg 2 503
reply?
On Sun, Jun 24, 2012 at 4:17 PM, Uri Shacked wrote:
> Hi,
>
> Kamailio server is behind our company's softswitch and acts as a sip
> application serv
