On Thu, Apr 30, 2009 at 1:16 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,

On 04/29/2009 08:35 PM, Brandon Armstead wrote:

Daniel,

You are correct it is not set for this usrloc. Should I be able to just not modify $du in this case?

I do not understand what you mean now?!?!

Cheers,
Daniel

Thanks!

On Wed, Apr 29, 2009 at 7:39 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote:

Hello,

$du is set by usrloc only if there is a received value in the
location record. Can you check if you have it in db?

Cheers,
Daniel

On 04/29/2009 11:45 AM, Brandon Armstead wrote:

Daniel,

Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of
branch_route[] i.e.:

branch_route[2]
{
if(isbflagset(4)){
# thats me!
} else {
# at this point X-Duri is null, so we are not saving it
from the lookup?
# we need to save this to pass onto Proxy B, however
the value is NULL at this point, and at the point of Proxy B
(when received).
append_hf("X-Duri: $avp(s:duri)\r\n");
if(isbflagset(6)){
$du = "sip:PROXY_B;transport=udp;";
}
}

xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru
fu=$fu tu=$tu si=$si flag=$bF du=$du");
}

Then when X-Duri reaches Proxy B, if I see the INVITE comes
from Proxy A, I take X-Duri and restore "$du" with the correct
value.

However this is causing issues now as the value is <null>,
I've tried saving $du into avp after looking up usrloc, I've
tried simply calling $du in branch_route[], and I've tried
saving $du in loose_route() into an avp, all to no avail.

What am I missing here as far as passing the value of $du from
branch route to header, to pass along to Proxy B.

Thanks again!

On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote:

On 04/29/2009 11:32 AM, Brandon Armstead wrote:

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.

I may not followed all discussion branch - the X-Duri is a
header
you append to the message? If yes, it is not visible
immediately
in the script, but you can see it when the messages is ent
to the
network.

Do I need to save this value into an AVP after
lookup("location")?

What you need to do with it? Where is its values taken from?

Cheers,
Daniel

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
<miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote:

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@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>
<mailto:miconda@gmail.com
<mailto:miconda@gmail.com> <mailto:miconda@gmail.com
<mailto:miconda@gmail.com>>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>>> wrote:

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@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>>
<mailto:77e4c600-147767fb@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>>>
<mailto:77e4c600-147767fb@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>>
<mailto:77e4c600-147767fb@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>>>>
<mailto:77e4c600-147767fb@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>>
<mailto:77e4c600-147767fb@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>>>
<mailto:77e4c600-147767fb@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>>
<mailto:77e4c600-147767fb@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
<mailto:sip%3ACALLER@sip.example.com>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>
<mailto:sip%2525253ACALLER@sip.example.com
<mailto:sip%252525253ACALLER@sip.example.com>>>>>

tu=sip:CALLEE@sip.example.com
<mailto:sip%3ACALLEE@sip.example.com>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>
<mailto:sip%2525253ACALLEE@sip.example.com
<mailto:sip%252525253ACALLEE@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@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>>
<mailto:77e4c600-147767fb@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>>>
<mailto:77e4c600-147767fb@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>>
<mailto:77e4c600-147767fb@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>>>>
<mailto:77e4c600-147767fb@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>>
<mailto:77e4c600-147767fb@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>>>
<mailto:77e4c600-147767fb@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>>
<mailto:77e4c600-147767fb@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
<mailto:sip%3ACALLER@sip.example.com>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>
<mailto:sip%2525253ACALLER@sip.example.com
<mailto:sip%252525253ACALLER@sip.example.com>>>>>

tu=sip:CALLEE@sip.example.com
<mailto:sip%3ACALLEE@sip.example.com>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>
<mailto:sip%2525253ACALLEE@sip.example.com
<mailto:sip%252525253ACALLEE@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@cryy.com
<mailto:brandon@cryy.com> <mailto:brandon@cryy.com
<mailto:brandon@cryy.com>>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>
<mailto:brandon@cryy.com
<mailto:brandon@cryy.com> <mailto:brandon@cryy.com
<mailto:brandon@cryy.com>>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>
<mailto:brandon@cryy.com
<mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>
<mailto:brandon@cryy.com
<mailto:brandon@cryy.com> <mailto:brandon@cryy.com
<mailto:brandon@cryy.com>>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@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@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>>>
<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
<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>
<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
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@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@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>>>
<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
<mailto:klaus.mailinglists@pernau.at>>>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:
...

[Message clipped]