Hi Andrew,
just ran a timeout scenario with 1.6 :
proxy sends call to destination A
A gives no final reply
proxy gives timeout
proxy sends CANCEL to A
proxy sends call to new destination B
proxy receives 200 OK for CANCEL and 487 for call from A.
.
So, what is the
Hi,
Perhaps someone could chime in on this..
Andrew Pogrebennyk wrote:
> Bogdan,
> You are correct. But the thing is that when fr_inv_timer hits, OpenSIPS
> (prematurely) sends INVITE on the next branch and only after that
> CANCELs the previous one. And if the gateway receives different branch
Hi Andrew,
Andrew Pogrebennyk wrote:
> Bogdan-Andrei Iancu wrote:
>>> http://www.mail-archive.com/users@lists.opensips.org/msg07999.html
>>> but Bogdan didn't reply yet.
>>>
>> Sorry - missed that one :D
>> It is interesting what you are saying, but I wouldn't say it is a bug
>> in OpenSI
Bogdan-Andrei Iancu wrote:
>> http://www.mail-archive.com/users@lists.opensips.org/msg07999.html
>> but Bogdan didn't reply yet.
>>
> Sorry - missed that one :D
> It is interesting what you are saying, but I wouldn't say it is a bug in
> OpenSIPS, but rather a bug in the GW - even if the f
Hi Andrew,
Andrew Pogrebennyk wrote:
> Hello,
>
> I have a similar setup. It could be that you just need to call
> append_branch() somewhere in the failure_route[3], unless you do it in
> route[4]. At least it works for me.
>
That is true for versions older than 1.5 . Starting with 1.5, in fa
Hi Indiver,
hard to evaluate the behaviour based only on the pieces of script you
posted. What is important to check is:
1) you arm the failure route when processing the initial INVITE - place
an xlog just before the t_on_failure() to be sure it is done.
2) place another xlog just in the begin
Hello,
I have a similar setup. It could be that you just need to call
append_branch() somewhere in the failure_route[3], unless you do it in
route[4]. At least it works for me.
However I have faced another problem that you can't use the same
gateway/UA several times as a target for sequential
hi bodgan,
Thanks for your reply. I made some changes and call is now going to
destination. But when no answer or busy it is not going to failure route.
here are the changes i did.
#unconditional call forward
if(avp_db_load("$ruri/username","$avp(s:callfwd)"))
{
