Re: [Kamailio-Users] Multiple SIP Proxy Environment / Socket Information

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