[OpenSIPS-Users] Multiple branches for a single AOR
Ben Newlin
Ben.Newlin at genesys.com
Tue Jul 17 09:07:08 EDT 2018
Liviu,
Yes, I meant it in the more general sense of re-sending the request, but of course one must be mindful of wording when these terms have specific meanings as this one does! It would indeed be a new transaction. Thanks for catching that!
Ben Newlin
From: Users <users-bounces at lists.opensips.org> on behalf of Liviu Chircu <liviu at opensips.org>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Tuesday, July 17, 2018 at 9:03 AM
To: "users at lists.opensips.org" <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Multiple branches for a single AOR
Hi Ben,
Just for the sake of completeness, if we do decide to retry a request within a failure route, we will not do a "retransmission", but actually create a brand new transaction (with a unique ";branch=" param) on the SIP proxy's UAC side (the outgoing side).
Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 17.07.2018 15:54, Ben Newlin wrote:
Gerwin,
Specifically, it is the t_relay() call within your failure_route. t_relay() is used to send requests, not responses. The automatic action of failure_route if no retransmission is attempted is to send the reply back upstream [1]. So you don’t have to do anything if that is the functionality you desire.
[1] http://www.opensips.org/Documentation/Script-Routes-2-4#toc3
Ben Newlin
From: Users <users-bounces at lists.opensips.org><mailto:users-bounces at lists.opensips.org> on behalf of Liviu Chircu <liviu at opensips.org><mailto:liviu at opensips.org>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org><mailto:users at lists.opensips.org>
Date: Tuesday, July 17, 2018 at 8:50 AM
To: "users at lists.opensips.org"<mailto:users at lists.opensips.org> <users at lists.opensips.org><mailto:users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Multiple branches for a single AOR
Hi Gerwin,
Inside your failure route, you are always attempting a retry of any failed request. This logic conflicts with your initial statement that "The intent is to ensure that the response code gets sent through to A-party".
Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 17.07.2018 14:35, Gerwin van de Steeg wrote:
Folks,
I'm trying to narrow down a 482 Merged Request problem on calls from one SIP device to another via OpenSIPS 2.4.1. Yealink T41P SIP device (A-party), calls via OpenSIPS, to another AOR owned by a Zoiper5 device (B-party).
The intent is to ensure that when the B-party rejects the call with a 486 Busy Here, that the response code gets sent through to A-party. However what I'm seeing is the 486 gets sent to OpenSIPS which ACK's it, but doesn't go anywhere from there, and then something causes a second invite to be sent from OpenSIPS to the B-party which then responds of course with 482 Merged Request.
The call as it is progressing through the call flow seems to be starting a second branch to the AOR (only one SIP device registered using UDP per AOR).
What would be causing that second call so that I can eliminate it and get to the behaviour I'm expecting. Just using a slightly modified residential default config template with websocket support (the problem was noticed using SIP.JS but exists also in generic SIP device to SIP device calls).
Image containing sngrep of call: https://imgur.com/RCZXkO6
Subscribers are in the form of <username>@<domain>
With an alias setup for an extension number.
ie.
alfred.anderson at ... = 552
alice.bell at ... = 553
excerpt from opensips.cfg
if ($rU==NULL) {
# request with no Username in RURI
send_reply("484","Address Incomplete");
exit;
}
$acc_extra(src_ip) = $si; # source IP of the request
$acc_leg(caller) = $fu;
$acc_leg(callee) = $ru;
# apply DB based aliases
if (alias_db_lookup("dbaliases")) {
xlog("Alias lookup success [$fu/$tu/$ru/$ci]");
}
else {
xlog("Alias lookup failure [$fu/$tu/$ru/$ci]");
}
# do blind callforward lookup
if (avp_db_load("rU", "$avp(callfwd)")) {
t_reply("181", "Call Is Being Forwarded");
$ru = $avp(callfwd);
xlog("forwarded call to: $avp(callfwd)");
route(relay);
exit;
}
# apply transformations from dialplan table
dp_translate("0", "$rU/$rU");
# check if the call needs to be routed to freeswitch
route(freeswitch);
# here we would set the redirect URI if it had one
route(lookup);
}
route[lookup] {
script_trace(1, "$rm from $si, rur=$ru", "me");
xlog("route:lookup");
# do lookup with method filtering
if (!lookup("location","m")) {
xlog("lookup failure");
t_newtran();
if (!db_does_uri_exist()) {
xlog("$cfg_line: URI doesn't exist");
send_reply("420", "Bad Extension");
exit;
}
t_reply("404", "Not Found");
exit;
}
# when routing via usrloc, log the missed calls also
do_accounting("db","missed");
route(relay);
}
route[freeswitch] {
xlog("route:freeswitch");
if (!is_method("INVITE")) {
return;
}
# if the called number begins with the right dialplan redirect it to freeswitch
# here we take everythign prefixed with a *, strip it, and send it to freeswitch
if ($rU=~"^\*") {
strip(1);
$du = "sip:10.23.4.192:50600<http://10.23.4.192:50600>";
route(relay);
}
}
route[relay] {
xlog("route:relay: Relaying: method=$rm");
# for INVITEs enable some additional helper routes
if (is_method("INVITE")) {
t_on_branch("per_branch_ops");
t_on_reply("handle_nat");
t_on_failure("missed_call");
}
else if (is_method("BYE|CANCEL")) {
# cancel the rtpengine transcoding
rtpengine_delete();
}
if (!t_relay()) {
send_reply("500","Internal Error");
}
exit;
}
branch_route[per_branch_ops] {
script_trace(1, "$rm from $si, rur=$ru", "me");
xlog("[$ci/$T_branch_idx] branch_route:per_branch_ops: new branch at $ru\n");
# WebSocket specific handling with NORMAL SDP negotiation
# assumes SDP offer in the INVITE from the UAC, and SDP
# answer is in 200 OK from the UAS
if (!is_method("INVITE") || !has_body("application/sdp"))
return;
if (isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "ICE=force-relay DTLS=passive";
else if (isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
else if (!isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "UDP/TLS/RTP/SAVPF ICE=force";
else if (!isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
# only enable transcoding if websocket call for now
if (isflagset(SRC_WS) || isbflagset(DST_WS)) {
rtpengine_offer("$var(rtpengine_flags)");
}
}
onreply_route[handle_nat] {
script_trace(1, "$rm from $si, rur=$ru", "me");
xlog("[$ci/$T_branch_idx] onreply_route:handle_nat: $ru\n");
# WebSocket specific handling with NORMAL SDP negotiation
# assumes SDP offer in the INVITE from the UAC, and SDP
# answer is in 200 OK from the UAS
if (!has_body("application/sdp"))
return;
if (isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "ICE=force-relay DTLS=passive";
else if (isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "UDP/TLS/RTP/SAVPF ICE=force";
else if (!isflagset(SRC_WS) && isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
else if (!isflagset(SRC_WS) && !isbflagset(DST_WS))
$var(rtpengine_flags) = "RTP/AVP replace-session-connection replace-origin ICE=remove";
# only enable transcoding if websocket call for now
if (isflagset(SRC_WS) || isbflagset(DST_WS)) {
rtpengine_answer("$var(rtpengine_flags)");
}
}
failure_route[missed_call] {
script_trace(1, "$rm from $si, rur=$ru", "me");
xlog("[$ci/$T_branch_idx] failure_route:missed_call: incoming failure response to $rm <- $T_reply_code/$T_ruri");
if (t_was_cancelled()) {
xlog("[$ci/$T_branch_idx] was cancelled");
exit;
}
do_accounting("db", "missed");
if (!t_relay()) {
send_reply("500","Internal Error");
}
else {
xlog("[$ci/$T_branch_idx] Relay success $rm/$T_reply_code");
}
}
Cheers,
Gerwin
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180717/6025300e/attachment-0001.html>
More information about the Users
mailing list