I try to fork a call to another user registered at the same proxy as the caller. I figured out that the easiest method would be to use the append_branch() function, something like
route[0] {
if (method=="REGISTER") { save("location"); exit; }
if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }
# if someone calls test2@domain, fork call to test4@domain # (test2 and test4 are both registered at domain) if (avp_check("$rU", "eq/test2")) { append_branch("sip:test4@127.0.0.1"); }
if (!t_relay()) { sl_reply_error(); }; exit; }
I know that this could also be achieved by adding permanent location records, but I'd like to load the forking targets from a DB in the future. So my first question would be if using
append_branch("sip:test4@127.0.0.1");
is the correct way to do parallel forking to a local user.
I'm asking because this method does not work for me as expected. It seems that the two UAC state machines running on the same proxy host that are involved in a forking call do somehow not work well together.
Forking the INVITE to both test2 and test4 works well, but when I pick up test2 the call gets terminated after a few seconds. Further investigations have revealed that canceling the second call leg does not work correctly. There is a message flow diagram available at http://www.unc.edu/~cschlatt/openser.html .
For some reason, the proxy process sending from 127.0.0.1 is retransmitting the 487 "Request Terminated" although it receives ACKs from the upstream proxy. And this causes the upstream proxy to send a 487 back to the caller (time 15.360), which then terminates the call established between caller and test2.
And this only happens if I fork to the same proxy, if I use two proxy hosts everything works fine (??).
Any advice is highly appreciated,
Christian
Hi Christian,
the parallel fork looks ok (as design) - on a first look, the problem seams to be related to some ACK-matching which leads to the 487 retransmission - could you please send me (privately) the pcap or ngrep of the whole calls? it will be easier for me to debug.
regarding your question about loading new branches form DB, you can use avp_db_load() or avp_db_query() to load the branches and avp_pushto("$br",..) to push the loaded avps as new branches. See: http://www.openser.org/docs/modules/1.2.x/avpops.html
regards, bogdan
Christian Schlatter wrote:
I try to fork a call to another user registered at the same proxy as the caller. I figured out that the easiest method would be to use the append_branch() function, something like
route[0] {
if (method=="REGISTER") { save("location"); exit; } if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; } # if someone calls test2@domain, fork call to test4@domain # (test2 and test4 are both registered at domain) if (avp_check("$rU", "eq/test2")) { append_branch("sip:test4@127.0.0.1"); } if (!t_relay()) { sl_reply_error(); }; exit;
}
I know that this could also be achieved by adding permanent location records, but I'd like to load the forking targets from a DB in the future. So my first question would be if using
append_branch("sip:test4@127.0.0.1");
is the correct way to do parallel forking to a local user.
I'm asking because this method does not work for me as expected. It seems that the two UAC state machines running on the same proxy host that are involved in a forking call do somehow not work well together.
Forking the INVITE to both test2 and test4 works well, but when I pick up test2 the call gets terminated after a few seconds. Further investigations have revealed that canceling the second call leg does not work correctly. There is a message flow diagram available at http://www.unc.edu/~cschlatt/openser.html .
For some reason, the proxy process sending from 127.0.0.1 is retransmitting the 487 "Request Terminated" although it receives ACKs from the upstream proxy. And this causes the upstream proxy to send a 487 back to the caller (time 15.360), which then terminates the call established between caller and test2.
And this only happens if I fork to the same proxy, if I use two proxy hosts everything works fine (??).
Any advice is highly appreciated,
Christian
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu writes:
the parallel fork looks ok (as design) - on a first look, the problem seams to be related to some ACK-matching which leads to the 487 retransmission - could you please send me (privately) the pcap or ngrep of the whole calls? it will be easier for me to debug.
this may be the same ACK matching problem that i noticed a week ago. i just made some more tests and the problem can be repeated using openser and any SIP UA (i used twinkle in my tests) as follows:
1) register a twinkle SIP UA using, for example, AoR sip:twinkle1@domain, where domain is a domain OpenSER proxy under test is responsible for.
2) add a permanent usrloc contact sip:twinkle2@domain for the same AoR using same q value as in above. this creates a two-way fork when sip:twinkle1@domain is called.
3) register another twinkle SIP UA using AoR sip:twinkle2@domain and on that one, press "do not disturb" icon (the one with x), which causes twinkle to respond to INVITE with 480.
4) from a third SIP UA, place call to sip:twinkle1@domain and wireshark will show you that the second instance of OpenSER (the one that t_relayed INVITE to twinkle2) does not match the ACK to 480 from the first OpenSER instance (the one that forked the INVITE to twinkle1 and the second instance).
-- juha
Hi Juha,
Thanks for the description, thanks to which I was able to reproduce and fix the bug. The fix is on the CVS, both devel and 1.1.0 version.
Please reports if any side-effects popup.
Thanks and regards, Bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
the parallel fork looks ok (as design) - on a first look, the problem seams to be related to some ACK-matching which leads to the 487 retransmission - could you please send me (privately) the pcap or ngrep of the whole calls? it will be easier for me to debug.
this may be the same ACK matching problem that i noticed a week ago. i just made some more tests and the problem can be repeated using openser and any SIP UA (i used twinkle in my tests) as follows:
- register a twinkle SIP UA using, for example, AoR
sip:twinkle1@domain, where domain is a domain OpenSER proxy under test is responsible for.
- add a permanent usrloc contact sip:twinkle2@domain for the same AoR
using same q value as in above. this creates a two-way fork when sip:twinkle1@domain is called.
- register another twinkle SIP UA using AoR sip:twinkle2@domain and on
that one, press "do not disturb" icon (the one with x), which causes twinkle to respond to INVITE with 480.
- from a third SIP UA, place call to sip:twinkle1@domain and wireshark
will show you that the second instance of OpenSER (the one that t_relayed INVITE to twinkle2) does not match the ACK to 480 from the first OpenSER instance (the one that forked the INVITE to twinkle1 and the second instance).
-- juha