Hi Andrew,
Just to refresh me - what is the failure that trigger the failure_route?
a timeout on the ongoing branch?
I can take a look in TM to see how difficult will be to revert the
CANCEL and the INVITE, but I was not sure about the failure scenario you
had (to investigate).
Regards,
Bogda
I have put b2bua between OpenSIPS and Cisco, but still no luck. The
point here is that when fr_inv_timer hits, OpenSIPS prematurely sends
INVITE per the next branch and only after that CANCELs the previous one.
I don't think this is the correct behavior actually, and there was a
similar issue m
Bogdan,
Thanks. I'm using 1.5.3. I sort of got stuck with this serial forking
scenario. I mean, OpenSIPS does what is supposed to do. The problems is
the call needs to be sent to (and is originated by) the Cisco AS5300.
When one destination fails OpenSIPS sends the call to the next
destination
Hi Andrew,
Noticed you fixed the problem, but here are some ideas/questions:
1) what version on opensips do you use?
2) keep in mind that all the changes you do before creating the
transaction (which is typically done by the first t_relay()) are
inherited by all the following branched (you cre
Andrew Pogrebennyk wrote:
> failure_route[2]
> {
> # forward on busy
> if(t_check_status("(486)|(408)") && avp_pushto("$ru",
> "$avp(s:callfwd)")) {
> append_branch();
I have fixed my problem, of course I had to use the append_branch()
after prefix() in the scr
Andrew Pogrebennyk wrote:
> Nov 12 21:59:29 sip2 /usr/local/sbin/openser[53183]: Request leaving
> server, D-URI='sip:40089165438...@xx.yy.zz.ww' - M=INVITE
> RURI=sip:40089165438...@xx.yy.zz.ww F=sip:84957978...@xx.yy.zz.ww
> T=sip:4953801...@aa.bb.cc.dd IP=XX.YY.ZZ.WW
> id=e9c3fa8b-ced411de-b
Hi,
I'm trying to put together some configuration for unconditional call
forwarding. The carrier requires me to send the call with prefix "400"
in R-URI. Here are the relevant routes:
route[6]
{
if(avp_db_load("$ru/username","$avp(s:callfwd)")) {
avp_pushto("$ru", "$avp
