Daniel,<br><br> It looks like you helped me find part of the problem, apparently Proxy A was sharing same branch flag as the one I used to distinguish which proxy it was. I corrected this and now branch flag for branch 1 is 00000060, and branch 2 is 00000040, however now both branches are routed appropriately to the correct server, however the X-Duri (to restore to in the INVITE) is null. Do I need to save this value into an AVP after lookup("location")? Or should it be readily available in branch_route[], and for some reason my variable is null?<br>
<br>P.S. (recap)<br>Proxy A NAT Branch Flag: 5<br>Proxy B NAT Branch Flag: 5<br><br>(Problem existed as used Flag 5 to distinguish "itself" as proxy) -- changed this to 4 so now:<br><br>Proxy A NAT Branch Flag: 4<br>
Proxy B NAT Branch Flag: 6<br><br>Calls are routed to Proxy B<br><br>X-Duri: <null> (as it is null in Proxy A). I'm append_hf(X-Duri: $du) inside of branch_route[].<br><br>Thanks!<br><br><div class="gmail_quote">
On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
On 04/29/2009 11:11 AM, Brandon Armstead wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Daniel,<br>
<br>
No that would be the UAC (I have two clients behind the same NAT). The problem is it looks like the branch flag is not being set for both for some reason (when comparing) even though in the database it is the same?<br>
</blockquote>
<br></div>
So you have the brach flag for nat and branch flags for next proxy, right? What is the value of branch flag? The value are different indeed, but some flags you are looking for might be set. It is easier spot if you print the hexa format of the flags rather than decimal one.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
Take a look at the flag= value from each of those logs (this is one call) to a UAC with two registrations line1/line2.<br>
<br></div><div class="im">
On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a> <mailto:<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>>> wrote:<br>
<br>
Hello,<br>
<br>
<br>
On 04/29/2009 10:53 AM, Brandon Armstead wrote:<br>
<br>
Hey guys,<br>
<br>
Still facing a few challenges and seeing if any further<br>
input, I'm specifically trying inaki's suggestions / method,<br>
but here are the current problems:<br>
<br>
sip:/etc/kamailio/m4cfgs# tail -f /var/log/openser.log | grep<br>
-v -E 'non-local|repeated' | grep branch_route<br>
Apr 29 07:38:05 db06 /sbin/kamailio[21279]:<br>
[<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a><br>
<mailto:<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a>><br>
<mailto:<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a><br>
<mailto:<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a>>>][branch_route][1]<br>
ru=sip:CALLEE@99.XX.XX.XX:5079 fu=<a href="mailto:sip%3ACALLER@sip.example.com" target="_blank">sip:CALLER@sip.example.com</a><br>
<mailto:<a href="mailto:sip%253ACALLER@sip.example.com" target="_blank">sip%3ACALLER@sip.example.com</a>><br>
<mailto:<a href="mailto:sip%253ACALLER@sip.example.com" target="_blank">sip%3ACALLER@sip.example.com</a><br></div>
<mailto:<a href="mailto:sip%25253ACALLER@sip.example.com" target="_blank">sip%253ACALLER@sip.example.com</a>>><div class="im"><br>
tu=<a href="mailto:sip%3ACALLEE@sip.example.com" target="_blank">sip:CALLEE@sip.example.com</a><br>
<mailto:<a href="mailto:sip%253ACALLEE@sip.example.com" target="_blank">sip%3ACALLEE@sip.example.com</a>><br>
<mailto:<a href="mailto:sip%253ACALLEE@sip.example.com" target="_blank">sip%3ACALLEE@sip.example.com</a><br></div>
<mailto:<a href="mailto:sip%25253ACALLEE@sip.example.com" target="_blank">sip%253ACALLEE@sip.example.com</a>>> si=99.XX.XX.XX<div class="im"><br>
flag=96 du=<null><br>
<br>
<br>
This call is not sent to Proxy B (this is a result of bflag<br>
not being set) ???<br>
<br>
is the proxy B at 99.XX.XX.XX:5079? If not, then set $du to the<br>
address of that proxy. It is null in the log above.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
My question is "Why", I look at the AOR / usrloc and they both<br>
have the "same exact flags set", this call is rather sent<br>
directly to UAC endpoint.<br>
<br>
---<br>
<br>
Apr 29 07:38:05 db06 /sbin/kamailio[21279]:<br>
[<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a><br>
<mailto:<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a>><br></div><div class="im">
<mailto:<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a><br></div><div class="im">
<mailto:<a href="mailto:77e4c600-147767fb@172.16.1.35" target="_blank">77e4c600-147767fb@172.16.1.35</a>>>][branch_route][2]<br>
ru=sip:CALLEE@99.XX.XX.XX:5062 fu=<a href="mailto:sip%3ACALLER@sip.example.com" target="_blank">sip:CALLER@sip.example.com</a><br>
<mailto:<a href="mailto:sip%253ACALLER@sip.example.com" target="_blank">sip%3ACALLER@sip.example.com</a>><br></div><div class="im">
<mailto:<a href="mailto:sip%253ACALLER@sip.example.com" target="_blank">sip%3ACALLER@sip.example.com</a><br></div>
<mailto:<a href="mailto:sip%25253ACALLER@sip.example.com" target="_blank">sip%253ACALLER@sip.example.com</a>>><div class="im"><br>
tu=<a href="mailto:sip%3ACALLEE@sip.example.com" target="_blank">sip:CALLEE@sip.example.com</a><br>
<mailto:<a href="mailto:sip%253ACALLEE@sip.example.com" target="_blank">sip%3ACALLEE@sip.example.com</a>><br>
<mailto:<a href="mailto:sip%253ACALLEE@sip.example.com" target="_blank">sip%3ACALLEE@sip.example.com</a><br></div>
<mailto:<a href="mailto:sip%25253ACALLEE@sip.example.com" target="_blank">sip%253ACALLEE@sip.example.com</a>>> si=99.XX.XX.XX<div class="im"><br>
flag=64 du=sip:PROXY_B;transport=udp;<br>
<br>
<br>
This call is sent to Proxy B (however Proxy B) - however the<br>
X-Duri (is null) as it is not existant in Proxy A's branch<br>
route? should I save this from right after the<br>
lookup("location") result into an avp?<br>
<br>
<br>
Again, thank you for all and any help, thanks!<br>
<br>
On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead<br>
<<a href="mailto:brandon@cryy.com" target="_blank">brandon@cryy.com</a> <mailto:<a href="mailto:brandon@cryy.com" target="_blank">brandon@cryy.com</a>><br></div><div class="im">
<mailto:<a href="mailto:brandon@cryy.com" target="_blank">brandon@cryy.com</a> <mailto:<a href="mailto:brandon@cryy.com" target="_blank">brandon@cryy.com</a>>>> wrote:<br>
<br>
Klaus, Inaki, Daniel,<br>
<br>
Thanks! Sorry I did not see this email come through, I'm<br>
going to go ahead and give this method a go, and I'll<br>
update with<br>
the results, I have optimistic views.<br>
<br>
As for the reason I was rewriting $ru and setting $du to<br>
null, is<br>
because originally when I just changed $du to the 'destination<br>
proxy' it did not seem to work at all (I do not even recall<br>
what<br>
exactly what was happening) however I decided to just<br>
change $ru,<br>
and have the other proxy just "lookup" the usrloc information<br>
again. Again, this method looks interesting and I'll let<br>
you guys<br>
know how it goes, thanks for all the input and help!<br>
<br>
Sincerely,<br>
Brandon.<br>
<br>
<br>
On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion<br>
<<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>>>> wrote:<br>
<br>
<br>
<br>
Brandon Armstead schrieb:<br>
<br>
Klaus,<br>
<br>
So I took you and Inaki's input and essentially<br>
constructed a setup like so after the<br>
lookup("location") call:<br>
<br>
if(isbflagset(1)){<br>
$du = null;<br>
$rd = "P1";<br>
} else if(isbflagset(2)){<br>
$du = null;<br>
$rd = "P2";<br>
} else if(isbflagset(3)){<br>
$du = null;<br>
$rd = "P3";<br>
} else if(isbflagset(4)){<br>
$du = null;<br>
$rd = "P4";<br>
}<br>
<br>
<br>
1. The above code has to be in the branch_route block -<br>
otherwise multiple registrations of a single user are not<br>
handled correctly.<br>
<br>
2. you are rewriting the RURI. You should not do that<br>
as some<br>
clients wants to the in the RURI the Contact provided<br>
during<br>
REGISTER.<br>
<br>
3. probably you use fix_nated_register() to store the<br>
public<br>
IP:port of the client too. After lookup, this<br>
information is<br>
written to DURI. Thus, by setting $du you overwrite<br>
this info.<br>
You should put it into a special header so that you can<br>
restore it in the other proxy.<br>
<br>
Here a snippet how it should work (untested, no<br>
warranty): ( I<br>
use the term "originating" proxy for the proxy which<br>
received<br>
the INVITE and the term "serving" proxy for the proxy which<br>
handles the connection/registration of a certain SIP<br>
client).<br>
<br>
e.g:<br>
Alice -----INVITE-----> P1------->P2----->Bob2<br>
/ \<br>
/ \<br>
/ V<br>
V P3---->Bob3<br>
Bob1<br>
<br>
Bob's client Bob1 is connected to P1.<br>
Bob's client Bob2 is connected to P2.<br>
Bob's client Bob3 is connected to P3.<br>
<br>
So, P1 is the originating proxy. P2 is the serving proxy of<br>
Bob2. ....<br>
<br>
We do NAT traversal (note: we must not call<br>
fix_nated_contact() for messages sent between the<br>
proxies!):<br>
the originating proxy for the call-leg to the caller, the<br>
serving proxy for the call-leg to the callee.<br>
The RTP proxy will be managed by the originating proxy<br>
only.<br>
<br>
<br>
<br>
route{<br>
if (loose_route()) {<br>
... additional loose route processing...<br>
if (check_route_param("rtpproxy=yes")) {<br>
force_rtp_proxy();<br>
setbflag(7);<br>
}<br>
<br>
# downstream: in-dialog request is in the same<br>
direction as the<br>
# initial request<br>
if ( (check_route_param("nat=caller") &&<br>
is_direction("downstream"))<br>
|| (check_route_param("nat=callee") &&<br>
is_direction("upstream"))) {<br>
fix_nated_contact();<br>
} else if (check_route_param("nat=both") {<br>
fix_nated_contact();<br>
setbflag(8);<br>
} else {<br>
setbflag(8);<br>
}<br>
<br>
t_on_reply("1");<br>
t_relay();<br>
exit();<br>
}<br>
...<br>
<br>
# I am proxy 1<br>
if ((src_ip=ip.of.proxy.2) || (src_ip=ip.of.proxy.3)...) {<br>
# request comes from other proxy, that means I am the<br>
# serving proxy<br>
# do not lookup(), RURI is already set and<br>
# DURI is provided in our X-DURI header<br>
$du = $header(X-DURI);<br>
# we do not care about an RTP proxy because that's the<br>
task<br>
of the<br>
# proxy which performed the lookup() (the originating<br>
proxy)<br>
# add some record-route cookie to mark that we should<br>
perform<br>
# SIP NAT traversal for the callee<br>
add_rr_param(";nat=callee");<br>
# activate reply_route to fix_nated_contact of callee<br>
setbflag(8); # flag 8 = fix contact<br>
t_on_reply("1");<br>
record_route();<br>
t_relay();<br>
exit;<br>
}<br>
<br>
...<br>
# a new request - thus I am the originating proxy<br>
<br>
if ($dU looks like phone number) {<br>
... route to Gateway....<br>
exit;<br>
}<br>
<br>
if (!lookup("location")) {<br>
sl_send_reply("404","not found");<br>
exit;<br>
}<br>
# activate branch route to have dedicated routing per<br>
branch<br>
t_on_branch("1");<br>
<br>
# activate reply route to activate RTP proxy<br>
t_on_reply("1");<br>
<br>
# NAT traversal<br>
fix_nated_contact();<br>
<br>
record_route();<br>
t_relay();<br>
exit;<br>
}<br>
<br>
branch_route[1]{<br>
if(isbflagset(1)){<br>
# oh, that's me<br>
<br>
# add some record-route cookie to mark that we should<br>
perform<br>
# SIP NAT traversal for the callee and caller<br>
add_rr_param(";nat=both");<br>
<br>
# add some record-route cookie to mark that we are<br>
# in charge for the RTP proxy<br>
add_rr_param(";rtpproxy=yes");<br>
<br>
force_rtp_proxy();<br>
setbflag(7); # flag 7 = RTP proxy<br>
} else {<br>
# add some record-route cookie to mark that we should<br>
perform<br>
# SIP NAT traversal for the caller<br>
add_rr_param(";nat=caller");<br>
<br>
# we have to route the request to the serving proxy<br>
# write DURI in the header<br>
append_hf("X-DURI: $du");<br>
if(isbflagset(2)){<br>
$du = sip:ip.of.proxy.2;transport=udp;<br>
} else if(isbflagset(3)){<br>
$du = sip:ip.of.proxy.3;transport=udp;<br>
} else if(isbflagset(4)){<br>
$du = sip:ip.of.proxy.4;transport=udp;<br>
}<br>
}<br>
}<br>
<br>
reply_route[1]{<br>
if (isbflagset(7) && has_body("application/sdp")) {<br>
force_rtp_proxy()<br>
}<br>
if (isbflagset(8)) {<br>
fix_nated_contact()<br>
}<br>
}<br>
<br>
<br>
<br>
Note: this code does not care about the received socket<br>
of the<br>
proxy. Thus it works if the proxy listens only on one port.<br>
<br>
regards<br>
klaus<br>
<br>
<br>
On each Proxy, I changed the code appropriately<br>
excluding<br>
the Proxy from itself (so it does not forward to<br>
itself).<br>
I'm noticing weird behavior however as it seems as if<br>
what is happening is it created other issues such as:<br>
<br>
[INCOMING SERVER] -> P1 -> P2 -> P1 -> (loop?)<br>
<br>
Also I setup this test amongst two development<br>
servers (in<br>
which case it worked without issues). Once I<br>
included in<br>
more development instances into the ring it seemed<br>
as if<br>
the flags were being set when they should not be?<br>
<br>
I.e. I placed a call FROM UA1 (with bflag 5 SET)<br>
From the<br>
above example configuration ^ code. If you notice<br>
(flag<br>
5) is missing. To UA2 (Flag 3), again this looked<br>
to be<br>
doing some strange things such as acting as if another<br>
flag was set when it should not have been, thus<br>
forwarding<br>
to the wrong proxy or the wrong proxy order. Do<br>
you guys<br>
have any further thoughts or input on this? Thanks!<br>
<br>
On Thu, Apr 23, 2009 at 12:31 AM, Klaus Darilion<br>
<<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>>><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a><br>
<mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>>>>> wrote:<br>
<br>
Hi Brandon!<br>
<br>
Back to the original email ....<br>
<br>
Brandon Armstead schrieb:<br>
<br>
Hello guys,<br>
<br>
Is there a method upon using<br>
lookup("location")<br>
to also pull<br>
out the "socket" information for the original<br>
location the UAC<br>
registered to, for scenarios of this example:<br>
<br>
P1 & P2 share same usrloc database.<br>
<br>
UA1 registers to P1<br>
UA2 registers to P2<br>
<br>
UA1 calls UA2<br>
<br>
UA1 invites -> P1 -> INVITES -> UA2<br>
(bypassing P2<br>
-- where the<br>
actual nat binding is).<br>
<br>
Now upon P1 looking up usrloc for UA2, I<br>
would like<br>
to recognize<br>
that P1 is not the Proxy to deliver the<br>
call, and<br>
forward the<br>
request to P2 to send to UA2.<br>
<br>
So currently I have:<br>
<br>
UA1 INVITE -> P1 INVITE -> UA2<br>
<br>
I wish to have:<br>
<br>
UA1 INVITE -> P1 INVITE -> P2 INVITE -> UA2<br>
<br>
Is there an easy method to do this? I have been<br>
looking at the<br>
new nat traversal module it looks like it is<br>
doable<br>
with this<br>
(any further input as far as that?). Also is it<br>
possible with<br>
the classic Nat Helper module? Any input is<br>
appreciated, thanks!<br>
<br>
<br>
I think the nat_traversal module can not help you in<br>
this case, nor<br>
nathelper.<br>
<br>
One possibility would be to spoof at P1 the IP<br>
address<br>
of P2 -<br>
nevertheless this would cause the reply sent back to<br>
P2, but the<br>
transaction is created in P1. (and you need to hack<br>
Kamailio for IP<br>
spoofing).<br>
<br>
Another easy solution would be: In P1 set a certain<br>
branch-flag when<br>
the client registers, e.g. bflag 1. In P2 set a<br>
certain<br>
branch-flag<br>
when the client registers, e.g. bflag 2.<br>
<br>
Now, if a user is called, just make a lookup() and<br>
t_relay. Further<br>
in the branch_route check if:<br>
in P1: isbflagset(2) --> forward to P2<br>
in P2: isbflagset(1) --> forward to P1<br>
<br>
klaus<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Kamailio (OpenSER) - Users mailing list<br>
<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>>><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a><br>
<mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>>>><br>
<br>
<a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br>
<a href="http://lists.openser-project.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.openser-project.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
Kamailio (OpenSER) - Users mailing list<br></div></div>
<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a> <mailto:<a href="mailto:Users@lists.kamailio.org" target="_blank">Users@lists.kamailio.org</a>><div class="im"><br>
<a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br>
<a href="http://lists.openser-project.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.openser-project.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br></div><div class="im">
-- Daniel-Constantin Mierla<br>
<a href="http://www.asipto.com/" target="_blank">http://www.asipto.com/</a><br>
<br>
<br>
</div></blockquote><div><div></div><div class="h5">
<br>
-- <br>
Daniel-Constantin Mierla<br>
<a href="http://www.asipto.com/" target="_blank">http://www.asipto.com/</a><br>
<br>
</div></div></blockquote></div><br>