[OpenSIPS-Users] mid_registrar work arround

Ben Newlin Ben.Newlin at genesys.com
Tue Aug 21 11:42:57 EDT 2018


Volga,

You can use shared variables as I suggested to get the proper VIPs into variables. Your keepalived script can change those values when failover occurs using the MI commands for shared variables.

When I suggested this you posed the question "How I can determine which vip ip address should be in use." I'm not sure what you mean by "in use" in this context. For inbound traffic it looks like you are currently accepting any of them. For in-dialog requests you would have to use the VIP of the original request, which it looks like you are achieving using dialog profiles.

So by "in use" do you mean the one that should be preferred for new outgoing traffic?

If so, I would suggest you do that with the same shared variable mechanism, managed by your keepalived script. Two options:
1. have the keepalived script manage the variables so that one of them, "vip1" perhaps, is always the currently active VIP for any given instance
2. have a separate variable, "active_vip" or something, that references the currently active VIP

Ben Newlin 

On 8/21/18, 11:27 AM, "volga629 at networklab.ca" <volga629 at networklab.ca> wrote:

    Hello Ben,
    The script bellow is to find the way define vips in variable so  if 
    failover happends on keepalived script can process traffic and set 
    proper vips (source ip)
    
    volga629.
    
    On Tue, Aug 14, 2018 at 4:38 PM, Ben Newlin <Ben.Newlin at genesys.com> 
    wrote:
    > Volga,
    > 
    > I must be misunderstanding. If you are able to determine the correct 
    > receiving interface in OpenSIPS and you are using the Path header to 
    > communicate that to the next hop destination, I'm not sure I'm clear 
    > on what the issue is you are still trying to solve?
    > 
    > Ben Newlin
    > 
    > On 8/14/18, 2:32 PM, "Users on behalf of volga629 at networklab.ca" 
    > <users-bounces at lists.opensips.org on behalf of 
    > volga629 at networklab.ca> wrote:
    > 
    >     Hello Ben,
    >     Yes, I create logic like this
    > 
    >             if(!has_totag() && is_method("INVITE")) {
    >                     create_dialog();
    > 
    >                     if($Ri== vip1 ip addr) {
    >                             set_dlg_sharing_tag("vip1");
    >                             $avp(vip) = "vip1 ip addr";
    >                     } else if($Ri== vip2 ip addr) {
    >                             set_dlg_sharing_tag("vip2");
    >                             $avp(vip) = "vip2 ip addr";
    >                     } else if($Ri == vip3 ip addr) {
    >                             set_dlg_sharing_tag("vip3");
    >                             $avp(vip) = "vip3 ip addr";
    >                     }
    >             }
    > 
    >     not sure if this correct approach. In theory $avp(vip) can be 
    > used for
    >     rtpengine or other operation require correct ip in body, but 
    > issue that
    >     call flow, because INVITE come from external interface first then 
    > it
    >     forwarded to LAN via dipatcher.
    > 
    > 
    >     volg629
    > 
    > 
    >     On Tue, Aug 14, 2018 at 2:51 PM, Ben Newlin 
    > <Ben.Newlin at genesys.com>
    >     wrote:
    >     > Volga,
    >     >
    >     > Sorry, I didn't fully understand your scenario. Even though you 
    > said
    >     > it was active/active, I was assuming an active/standby scenario 
    > where
    >     > only 1 IP would be active on a box at a time. I don't think this
    >     > approach would work for the scenario you are describing.
    >     >
    >     > Is there some reason you can't have each box listen on all 3 
    > IPs all
    >     > the time? Then from within the script you can use $Ri [1] to
    >     > determine which interface received the message.
    >     >
    >     > [1] - 
    > http://www.opensips.org/Documentation/Script-CoreVar-2-3#toc77
    >     >
    >     > Ben Newlin
    >     >
    >     > On 8/14/18, 1:39 PM, "Users on behalf of volga629 at networklab.ca"
    >     > <users-bounces at lists.opensips.org on behalf of
    >     > volga629 at networklab.ca> wrote:
    >     >
    >     >     Hello Ben,
    >     >     Do you mean for this
    >     >
    >     >     modparam("cfgutils", "varset", "init=i:1")
    >     >     modparam("cfgutils", "varset",
    >     > "gw=s:sip:11.11.11.11;transport=tcp")
    >     >
    >     >     or this
    >     >
    >     >     modparam("cfgutils", "shvset", "debug=i:1")
    >     >     modparam("cfgutils", "shvset", "pstngw=s:sip:10.10.10.10")
    >     >
    >     >     in my case will be something like
    >     >
    >     >
    >     >     modparam("cfgutils", "shvset", "vip1=s:192.168.10.100")
    >     >     modparam("cfgutils", "shvset", "vip2=s:192.168.10.101")
    >     >     modparam("cfgutils", "shvset", "vip3=s:192.168.10.102")
    >     >
    >     >     If vip relocated to antother node meaning on live node 1 
    > will be
    >     > two
    >     >     vip's ( example node 3 fail then it relocate ip address to 
    > node 1)
    >     >     How I can determine which  vip ip address should be in use.
    >     >
    >     >     volg629
    >     >
    >     >
    >     >     On Thu, Aug 2, 2018 at 9:44 PM, Ben Newlin
    >     > <Ben.Newlin at genesys.com>
    >     >     wrote:
    >     >     > M4 will process the file before OpenSIPS runs and will 
    > not be
    >     >     > changeable at runtime. It sounds like that will not work 
    > for
    >     > you if I
    >     >     > am understanding properly.
    >     >     >
    >     >     > My first thought would be to use the shared variables from
    >     > CFGUTILS
    >     >     > [1]. They can be accessed from inside the script, but can 
    > also
    >     > be set
    >     >     > via MI. So when your monitor detects a failure and 
    > switches the
    >     > IPs,
    >     >     > it could also use MI to change the value of the variable 
    > in
    >     > OpenSIPS
    >     >     > for future use.
    >     >     >
    >     >     > As a side note to OpenSIPS devs, it appears this module 
    > was
    >     > missed
    >     >     > when the Module Index page [2] was redesigned as I can't 
    > find it
    >     >     > there for 2.x, but the direct links to the 2.x versions 
    > still
    >     > work.
    >     >     >
    >     >     > [1]
    >     > http://www.opensips.org/html/docs/modules/2.4.x/cfgutils.html
    >     >     > [2] http://www.opensips.org/Documentation/Modules-2-4
    >     >     >
    >     >     > Ben Newlin
    >     >     >
    >     >     > On 8/2/18, 5:56 PM, "Users on behalf of 
    > volga629 at networklab.ca"
    >     >     > <users-bounces at lists.opensips.org on behalf of
    >     >     > volga629 at networklab.ca> wrote:
    >     >     >
    >     >     >     Hello Liviu,
    >     >     >     Yes, that correct.  Right now each node in cluster 
    > have own
    >     > vip
    >     >     > from
    >     >     >     keepalived on LAN side.
    >     >     >     The issue how to specify correct vip in case of 
    > failover,
    >     > so if
    >     >     > node 2
    >     >     >     fail and node 2 vip was relocated to node 1. All 
    > sessions
    >     > should
    >     >     > be
    >     >     >     process on node 1 and
    >     >     >     append_hf("Path:
    >     > <sip:$fU at MAIN_VIP:5060;transport=udp>\r\n");
    >     >     > should
    >     >     >     have correct ip's.  Same with rtpengine offer
    >     >     >     rtpengine_offer("replace-origin 
    > replace-session-connection
    >     >     >     in-iface=external out-iface=internal
    >     >     > media-address=$avp(media_addr)
    >     >     >     RTP/AVP ICE=remove") where need introduce 
    > media-address to
    >     > specify
    >     >     >     correct vip ip.
    >     >     >     Can you exapand on m4 ? I never used the templating.
    >     >     >     Might db avp  to predefine  cluster nodes vip ip, not 
    > sure.
    >     >     >
    >     >     >
    >     >     >     volga629
    >     >     >
    >     >     >
    >     >     >
    >     >     >     On Thu, Aug 2, 2018 at 10:50 AM, Liviu Chircu
    >     > <liviu at opensips.org>
    >     >     >     wrote:
    >     >     >     > Hi Volga,
    >     >     >     >
    >     >     >     > If I understood your problem correctly, one idea 
    > would be
    >     > to
    >     >     > use m4
    >     >     >     > over opensips.cfg and define a different MAIN_VIP
    >     > variable for
    >     >     > each
    >     >     >     > of your three servers:
    >     >     >     >
    >     >     >     > append_hf("Path:
    >     > <sip:$fU at MAIN_VIP:5060;transport=udp>\r\n");
    >     >     >     >  Liviu Chircu
    >     >     >     > OpenSIPS Developer
    >     >     >     > http://www.opensips-solutions.com
    >     >     >     > On 09.07.2018 07:34, volga629 at networklab.ca wrote:
    >     >     >     >> Hello Everyone,
    >     >     >     >>
    >     >     >     >> I have work around on this issue
    >     >     >     >> # Work arround for github issue #1109
    >     >     >     >> append_hf("Path: <sip:$fU at listen
    >     > ip:5060;transport=udp>\r\n"
    >     >     >     >>
    >     >     >     >>
    >     >     >     >> Right now we use 3 node cluster with 3 vips in
    >     > active/active
    >     >     > mode
    >     >     >     >> I need some idea how to determine path header 
    > listen ip
    >     >     > address from
    >     >     >     >> 3 vips.
    >     >     >     >>
    >     >     >     >>
    >     >     >     >> volga629
    >     >     >     >>
    >     >     >     >>
    >     >     >     >>
    >     >     >     >>
    >     >     >     >> _______________________________________________
    >     >     >     >> Users mailing list
    >     >     >     >> Users at lists.opensips.org
    >     >     >     >> 
    > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    >     >     >     >
    >     >     >
    >     >     >
    >     >     >     _______________________________________________
    >     >     >     Users mailing list
    >     >     >     Users at lists.opensips.org
    >     >     >     
    > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    >     >     >
    >     >     >
    >     >     > _______________________________________________
    >     >     > Users mailing list
    >     >     > Users at lists.opensips.org
    >     >     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    >     >
    >     >
    >     >     _______________________________________________
    >     >     Users mailing list
    >     >     Users at lists.opensips.org
    >     >     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    >     >
    >     >
    >     > _______________________________________________
    >     > Users mailing list
    >     > Users at lists.opensips.org
    >     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    > 
    > 
    >     _______________________________________________
    >     Users mailing list
    >     Users at lists.opensips.org
    >     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    > 
    > 
    > _______________________________________________
    > Users mailing list
    > Users at lists.opensips.org
    > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
    
    



More information about the Users mailing list