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

Daniel-Constantin Mierla miconda at gmail.com
Wed Apr 29 16:39:20 CEST 2009


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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto:miconda at gmail.com>
>         <mailto: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>>
>                <mailto: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>>>
>                       <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
>         <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>>>
>                       <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>>
>                       <mailto:sip%253ACALLER at sip.example.com
>         <mailto:sip%25253ACALLER at sip.example.com>
>                <mailto:sip%25253ACALLER at sip.example.com
>         <mailto:sip%2525253ACALLER 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>>>
>                       <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>>
>                       <mailto:sip%253ACALLEE at sip.example.com
>         <mailto:sip%25253ACALLEE at sip.example.com>
>                <mailto:sip%25253ACALLEE at sip.example.com
>         <mailto:sip%2525253ACALLEE 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>>>
>                       <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
>         <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>>>
>                       <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>>
>                       <mailto:sip%253ACALLER at sip.example.com
>         <mailto:sip%25253ACALLER at sip.example.com>
>                <mailto:sip%25253ACALLER at sip.example.com
>         <mailto:sip%2525253ACALLER 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>>>
>                       <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>>
>                       <mailto:sip%253ACALLEE at sip.example.com
>         <mailto:sip%25253ACALLEE at sip.example.com>
>                <mailto:sip%25253ACALLEE at sip.example.com
>         <mailto:sip%2525253ACALLEE 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>>>
>                       <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 <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>>>
>                          <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:
>
>
>
>                              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>>>>
>                                  <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
>         <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>>>>
>                                  <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
>         <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>>
>                <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
>
>
>                   --    Daniel-Constantin Mierla
>                   http://www.asipto.com/
>
>
>
>            --    Daniel-Constantin Mierla
>            http://www.asipto.com/
>
>
>
>     -- 
>     Daniel-Constantin Mierla
>     http://www.asipto.com/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 Users mailing list