29 Apr
2009
29 Apr
'09
11:53 a.m.
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][branch_route][1]
ru=sip:CALLEE@99.XX.XX.XX:5079
fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com>tu=
sip:CALLEE@sip.example.com <sip%3ACALLEE(a)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)
??? 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][branch_route][2]
ru=sip:CALLEE@99.XX.XX.XX:5062
fu=sip:CALLER@sip.example.com<sip%3ACALLER@sip.example.com>tu=
sip:CALLEE@sip.example.com <sip%3ACALLEE(a)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 <brandon(a)cryy.com> wrote:
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 <
klaus.mailinglists(a)pernau.at> wrote:
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 <
> klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>>
> wrote:
>
> 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>
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
>
>