[Kamailio-Users] Multiple SIP Proxy Environment / Socket Information
Daniel-Constantin Mierla
miconda at gmail.com
Thu Apr 23 21:59:47 CEST 2009
Hello,
On 04/23/2009 09:54 PM, Brandon Armstead wrote:
> 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";
> }
>
> 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?)
you can use a special header that accumulates the id's of the servers
the request has been through. You check when choosing next destination.
Cheers,
Daniel
>
> 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>>
> 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>
> 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
> 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/
More information about the sr-users
mailing list