Merge pull request #3318 from vladpaiu/usrloc_remove_branch_filtering

Add remove() filtering by bflags

modules/registrar/README

@@ -53,7 +53,7 @@ registrar Module
               1.4.1. save(domain[, flags[, aor[, ownership_tag]]])
 
               1.4.2. remove(domain, AOR[, [contact][, [next_hop][,
-                      [sip_instance]]]])
+                      [sip_instance], [bflags]]]])
 
               1.4.3. remove_ip_port(IP,Port, domain, [AOR])
               1.4.4. lookup(domain [, flags [, aor]])
@@ -158,9 +158,9 @@ Chapter 1. Admin Guide
      * off - stores the value of the Path headers into usrloc
        without passing it back to the UAC in the reply.
      * lazy - stores the Path header and passes it back to the UAC
-       if Path-support is indicated by the “path” param in the
+       if Path-support is indicated by the "path" param in the
        Supported HF.
-     * strict - rejects the registration with “420 Bad Extension”
+     * strict - rejects the registration with "420 Bad Extension"
        if there's a Path header but no support for it is indicated
        by the UAC. Otherwise it's stored and passed back to the
        UAC.
@@ -335,7 +335,7 @@ modparam("registrar", "default_q", 1000)
    The parameter specifies the message flag to be used to control
    the module behaviour regarding TCP connections. If the flag is
    set for a REGISTER via TCP containing a TCP contact, the
-   module, via the “save()” function, will set the lifetime of the
+   module, via the "save()" function, will set the lifetime of the
    TCP connection to the contact expire value. By doing this, the
    TCP connection will stay on as long as the contact is valid.
 
@@ -825,23 +825,23 @@ modparam("registrar", "pn_enable_purr", true)
           + 'path-lazy' - (old p1 flag) (Path support - lazy mode)
             The Path header is saved into usrloc, but is only
             included in the reply if path support is indicated in
-            the registration request by the “path” option of the
-            “Supported” header.
+            the registration request by the "path" option of the
+            "Supported" header.
           + 'path-strict' - (old p2 flag) (Path support - strict
             mode) - The path header is only saved into usrloc, if
             path support is indicated in the registration request
-            by the “path” option of the “Supported” header. If no
+            by the "path" option of the "Supported" header. If no
             path support is indicated, the request is rejected
-            with “420 - Bad Extension” and the header
-            “Unsupported: path” is included in the reply along
-            with the received “Path” header. This mode is the one
+            with "420 - Bad Extension" and the header
+            "Unsupported: path" is included in the reply along
+            with the received "Path" header. This mode is the one
             recommended by RFC-3327.
-          + 'path-received' - (old v flag) if set, the “received”
+          + 'path-received' - (old v flag) if set, the "received"
             parameter of the first Path URI of a registration is
             set as received-uri and the NAT branch flag is set for
             this contact. This is useful if the registrar is
             placed behind a SIP loadbalancer, which passes the
-            nat'ed UAC address as “received” parameter in it's
+            nat'ed UAC address as "received" parameter in it's
             Path uri.
           + 'only-request-contacts' - (old o flag) Only include
             the REGISTER request's Contacts in the 200 OK reply,
@@ -881,7 +881,7 @@ modparam("registrar", "pn_enable_purr", true)
 
    This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.
 
-   If you plan to use the “save()” function in reply route, please
+   If you plan to use the "save()" function in reply route, please
    refer to mcontact_avp module parameter.
 
    Example 1.30. save usage
@@ -907,8 +907,8 @@ own "vip"
 save("location", , , "vip");
 ...
 
-1.4.2.  remove(domain, AOR[, [contact][, [next_hop][,
-[sip_instance]]]])
+1.4.2.  remove(domain, AOR[, [contact][, [next_hop][, [sip_instance],
+[bflags]]]])
 
    Explicitly remove contacts behind a given address-of-record.
 
@@ -926,6 +926,8 @@ save("location", , , "vip");
        Hostnames are resolved before matching.
      * sip_instance (string, optional) - a "+sip.instance" value
        to be used for filtering purposes.
+     * blfags (string, optional) - a Branch flags to be used for
+       filtering purposes.
 
    IMPORTANT: the IP address of each contact (for matching
    purposes) is computed as follows:
@@ -1241,7 +1243,7 @@ if (is_method("REGISTER")) {
 1.4.8.  add_sock_hdr(hdr_name)
 
    Adds to the current REGISTER request a new header with
-   “hdr_name” which contains the description of the received
+   "hdr_name" which contains the description of the received
    socket (proto:ip:port)
 
    This makes sense only in multiple replicated servers scenarios.
@@ -1340,67 +1342,67 @@ Chapter 2. Frequently Asked Questions
 
    2.1.
 
-   What happened with the old “append_branch” module parameter?
+   What happened with the old "append_branch" module parameter?
 
-   It was removed as global option, as the “lookup” function takes
+   It was removed as global option, as the "lookup" function takes
    this option via the flag "b" (append Branches) See the
-   documentation of the “lookup” function.
+   documentation of the "lookup" function.
 
    2.2.
 
-   What happened with the old “method_filtering” module parameter?
+   What happened with the old "method_filtering" module parameter?
 
-   It was removed as global option, as the “lookup” function takes
+   It was removed as global option, as the "lookup" function takes
    this option via the flag "m" (Method filtering) See the
-   documentation of the “lookup” function.
+   documentation of the "lookup" function.
 
    2.3.
 
-   What happened with the old “sock_flag” module parameter?
+   What happened with the old "sock_flag" module parameter?
 
-   It was removed as global option, as the “save” function takes
+   It was removed as global option, as the "save" function takes
    this option via the flag "s" (Socket header) See the
-   documentation of the “save” function.
+   documentation of the "save" function.
 
    2.4.
 
-   What happened with the old “use_path” and “path_mode” module
+   What happened with the old "use_path" and "path_mode" module
    parameters?
 
-   They were removed as global option, as the “save” function
+   They were removed as global option, as the "save" function
    takes these options via the flag "px" (path support) See the
-   documentation of the “save” function.
+   documentation of the "save" function.
 
    2.5.
 
-   What happened with the old “path_use_received” module
+   What happened with the old "path_use_received" module
    parameter?
 
-   It was removed as global option, as the “save” function takes
+   It was removed as global option, as the "save" function takes
    this option via the flag "v" (path receiVed) See the
-   documentation of the “save” function.
+   documentation of the "save" function.
 
    2.6.
 
-   What happened with the old “nat_flag” module parameter?
+   What happened with the old "nat_flag" module parameter?
 
    It was removed, as the module internally loads this value from
-   the “USRLOC” module (see the “nat_bflag” USRLOC parameter).
+   the "USRLOC" module (see the "nat_bflag" USRLOC parameter).
 
    2.7.
 
-   What happened with the old “use_domain” module parameter?
+   What happened with the old "use_domain" module parameter?
 
    It was removed, as the module internally loads this option from
-   the “USRLOC” module. This was done in order to simplify the
+   the "USRLOC" module. This was done in order to simplify the
    configuration.
 
    2.8.
 
-   What happened with the old “save_noreply” and “save_memory”
+   What happened with the old "save_noreply" and "save_memory"
    functions?
 
-   There functions were merged into the new “save(domain,flags)”
+   There functions were merged into the new "save(domain,flags)"
    functions. If a reply should be sent or if the DB should be
    updated also is controlled via the flags.
 
@@ -1466,10 +1468,10 @@ Chapter 3. Contributors
    Ancuta Onofrei, Elena-Ramona Modroiu, Peter Lemenkov
    (@lemenkov), Dan Pascu (@danpascu), Sergio Gutierrez, Carsten
    Bock, Jeffrey Magder, Kobi Eshun (@ekobi), Marcus Hunger,
-   Julián Moreno Patiño, Phil D'Amore, Klaus Darilion, Irina-Maria
+   Juli�n Moreno Pati�o, Phil D'Amore, Klaus Darilion, Irina-Maria
    Stanescu, Dmitry Semyonov, Konstantin Bokarius, Jesus
-   Rodrigues, Dusan Klinec (@ph4r05), Ruslan Bukin, Saúl Ibarra
-   Corretgé (@saghul), @jalung, Tolga Tarhan, Edson Gellert
+   Rodrigues, Dusan Klinec (@ph4r05), Ruslan Bukin, Sa�l Ibarra
+   Corretg� (@saghul), @jalung, Tolga Tarhan, Edson Gellert
    Schubert.
 
    (1) DevScore = author_commits + author_lines_added /
@@ -1503,9 +1505,9 @@ Chapter 3. Contributors
    9.  Ovidiu Sas (@ovidiusas)             May 2011 - Mar 2017
    10. Ionut Ionita (@ionutrazvanionita)   Jul 2015 - Feb 2017
 
-   All remaining contributors: Julián Moreno Patiño, Dusan Klinec
-   (@ph4r05), Nick Altmann (@nikbyte), Tolga Tarhan, Saúl Ibarra
-   Corretgé (@saghul), Ruslan Bukin, Irina-Maria Stanescu, Kobi
+   All remaining contributors: Juli�n Moreno Pati�o, Dusan Klinec
+   (@ph4r05), Nick Altmann (@nikbyte), Tolga Tarhan, Sa�l Ibarra
+   Corretg� (@saghul), Ruslan Bukin, Irina-Maria Stanescu, Kobi
    Eshun (@ekobi), Phil D'Amore, Sergio Gutierrez, Klaus Darilion,
    Henning Westerholt (@henningw), Daniel-Constantin Mierla
    (@miconda), Konstantin Bokarius, Edson Gellert Schubert, Jesus
@@ -1525,8 +1527,8 @@ Chapter 4. Documentation
    Last edited by: Liviu Chircu (@liviuchircu), Vlad Patrascu
    (@rvlad-patrascu), Razvan Crainea (@razvancrainea), Vlad Paiu
    (@vladpaiu), Bogdan-Andrei Iancu (@bogdan-iancu), Peter
-   Lemenkov (@lemenkov), Ionut Ionita (@ionutrazvanionita), Julián
-   Moreno Patiño, Nick Altmann (@nikbyte), Ovidiu Sas
+   Lemenkov (@lemenkov), Ionut Ionita (@ionutrazvanionita), Juli�n
+   Moreno Pati�o, Nick Altmann (@nikbyte), Ovidiu Sas
    (@ovidiusas), Irina-Maria Stanescu, Kobi Eshun (@ekobi), Sergio
    Gutierrez, Klaus Darilion, Daniel-Constantin Mierla (@miconda),
    Konstantin Bokarius, Edson Gellert Schubert, Jesus Rodrigues,
@@ -1535,6 +1537,6 @@ Chapter 4. Documentation
 
    Documentation Copyrights:
 
-   Copyright © 2003 FhG FOKUS
+   Copyright � 2003 FhG FOKUS
 
-   Copyright © 2020 OpenSIPS Solutions
+   Copyright � 2020 OpenSIPS Solutions

modules/registrar/doc/registrar_admin.xml

@@ -571,7 +571,7 @@ save("location", , , "vip");
 
 	<section id="func_remove" xreflabel="remove()">
 		<title>
-		<function moreinfo="none">remove(domain, AOR[, [contact][, [next_hop][, [sip_instance]]]])</function>
+		<function moreinfo="none">remove(domain, AOR[, [contact][, [next_hop][, [sip_instance], [bflags]]]])</function>
 		</title>
 		<para>
 		Explicitly remove contacts behind a given address-of-record.
@@ -611,6 +611,12 @@ save("location", , , "vip");
 				"+sip.instance" value to be used for filtering purposes.
 			</para>
 		</listitem>
+		<listitem>
+			<para>
+				<emphasis>blfags (string, optional)</emphasis> - a
+				Branch flags to be used for filtering purposes.
+			</para>
+		</listitem>
 		</itemizedlist>
 		<para>
 			<emphasis role='bold'>IMPORTANT: </emphasis>the IP address of each

modules/registrar/reg_mod.c

@@ -154,6 +154,7 @@ static const cmd_export_t cmds[] = {
 		{CMD_PARAM_STR, 0, 0},
 		{CMD_PARAM_STR|CMD_PARAM_OPT,0,0},
 		{CMD_PARAM_STR|CMD_PARAM_OPT,0,0},
+		{CMD_PARAM_STR|CMD_PARAM_OPT,0,0},
 		{CMD_PARAM_STR|CMD_PARAM_OPT,0,0}, {0,0,0}},
 		REQUEST_ROUTE|ONREPLY_ROUTE},
 	{"remove_ip_port", (cmd_function)_remove_ip_port, {

modules/registrar/save.c

@@ -911,17 +911,18 @@ int save(struct sip_msg* _m, void* _d, void* _f, str* _s, str* _owtag)
  * @contact_gp:      contact URI to be deleted
  * @next_hop_gp:     IP/domain in front of contacts to be deleted
  * @sip_instance_gp: delete contacts with given "+sip_instance"
+ * @bflags:          delete contacts which the specific branch flags
  *
  * @return:      1 on success, negative on failure
  */
 int _remove(struct sip_msg *msg, void *udomain, str *aor_uri, str *match_ct,
-            str *match_next_hop, str *match_sin)
+            str *match_next_hop, str *match_sin, str* bflags_s)
 {
 	struct hostent delete_nh_he, *he;
 	urecord_t *record;
 	ucontact_t *contact, *it;
 	str aor_user;
-	int ret = 1;
+	int ret = 1,bflags=0;
 	unsigned short delete_port = 0;
 
 	if (extract_aor(aor_uri, &aor_user, 0, 0, reg_use_domain) < 0) {
@@ -939,7 +940,7 @@ int _remove(struct sip_msg *msg, void *udomain, str *aor_uri, str *match_ct,
 	}
 
 	/* without any additional filtering, delete the whole urecord entry */
-	if (!match_ct && !match_next_hop && !match_sin) {
+	if (!match_ct && !match_next_hop && !match_sin && !bflags_s) {
 		if (ul.delete_urecord((udomain_t *)udomain, &aor_user, record, 0) != 0) {
 			LM_ERR("failed to delete urecord for aor '%.*s'\n",
 			        aor_user.len, aor_user.s);
@@ -950,6 +951,11 @@ int _remove(struct sip_msg *msg, void *udomain, str *aor_uri, str *match_ct,
 		goto out_unlock;
 	}
 
+	if (bflags_s) {
+		bflags = get_flag_id_by_name(FLAG_TYPE_BRANCH, bflags_s->s, bflags_s->len);
+		bflags = 1<<bflags;
+	}
+
 	if (match_ct)
 		LM_DBG("Delete by contact: [%.*s]\n", match_ct->len, match_ct->s);
 
@@ -1018,6 +1024,11 @@ int _remove(struct sip_msg *msg, void *udomain, str *aor_uri, str *match_ct,
 				continue;
 		}
 
+		if (bflags != 0) {
+			if ((contact->cflags & bflags) == 0)
+				continue;
+		}
+
 		ul.delete_ucontact(record, contact, NULL, 0);
 	}
 

modules/registrar/save.h

@@ -45,7 +45,7 @@
 int save(struct sip_msg* _m, void* _d, void* _f, str* _s, str* _owtag);
 
 int _remove(struct sip_msg *msg, void *udomain, str *aor_gp, str *contact_gp,
-            str *next_hop_gp, str *sip_instance);
+            str *next_hop_gp, str *sip_instance, str *bflags);
 
 int _remove_ip_port(struct sip_msg *msg, str *ip, int *port, void *udomain, str* aor);