[Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel-Constantin Mierla
miconda at gmail.com
Wed Apr 29 11:42:01 CEST 2009
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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto:miconda at gmail.com>
> <mailto:miconda at gmail.com <mailto:miconda at 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 at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>
> <mailto:77e4c600-147767fb at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>>
> <mailto:77e4c600-147767fb at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>
> <mailto:77e4c600-147767fb at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>>>][branch_route][1]
> ru=sip:CALLEE at 99.XX.XX.XX:5079
> fu=sip:CALLER at sip.example.com
> <mailto:sip%3ACALLER at sip.example.com>
> <mailto:sip%3ACALLER at sip.example.com
> <mailto:sip%253ACALLER at sip.example.com>>
> <mailto:sip%3ACALLER at sip.example.com
> <mailto:sip%253ACALLER at sip.example.com>
> <mailto:sip%253ACALLER at sip.example.com
> <mailto:sip%25253ACALLER at sip.example.com>>>
>
> tu=sip:CALLEE at sip.example.com
> <mailto:sip%3ACALLEE at sip.example.com>
> <mailto:sip%3ACALLEE at sip.example.com
> <mailto:sip%253ACALLEE at sip.example.com>>
> <mailto:sip%3ACALLEE at sip.example.com
> <mailto:sip%253ACALLEE at sip.example.com>
> <mailto:sip%253ACALLEE at sip.example.com
> <mailto:sip%25253ACALLEE at 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 at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>
> <mailto:77e4c600-147767fb at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>>
> <mailto:77e4c600-147767fb at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>
> <mailto:77e4c600-147767fb at 172.16.1.35
> <mailto:77e4c600-147767fb at 172.16.1.35>>>][branch_route][2]
> ru=sip:CALLEE at 99.XX.XX.XX:5062
> fu=sip:CALLER at sip.example.com
> <mailto:sip%3ACALLER at sip.example.com>
> <mailto:sip%3ACALLER at sip.example.com
> <mailto:sip%253ACALLER at sip.example.com>>
> <mailto:sip%3ACALLER at sip.example.com
> <mailto:sip%253ACALLER at sip.example.com>
> <mailto:sip%253ACALLER at sip.example.com
> <mailto:sip%25253ACALLER at sip.example.com>>>
>
> tu=sip:CALLEE at sip.example.com
> <mailto:sip%3ACALLEE at sip.example.com>
> <mailto:sip%3ACALLEE at sip.example.com
> <mailto:sip%253ACALLEE at sip.example.com>>
> <mailto:sip%3ACALLEE at sip.example.com
> <mailto:sip%253ACALLEE at sip.example.com>
> <mailto:sip%253ACALLEE at sip.example.com
> <mailto:sip%25253ACALLEE at 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 at cryy.com <mailto:brandon at cryy.com>
> <mailto:brandon at cryy.com <mailto:brandon at cryy.com>>
> <mailto:brandon at cryy.com <mailto:brandon at cryy.com>
> <mailto:brandon at cryy.com <mailto:brandon at 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 at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at 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 at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at pernau.at>
> <mailto:klaus.mailinglists at pernau.at
> <mailto:klaus.mailinglists at 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 at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>>>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at 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 at lists.kamailio.org
> <mailto:Users at lists.kamailio.org>
> <mailto:Users at lists.kamailio.org
> <mailto:Users at 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/
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com/
More information about the Users
mailing list