[mid_]registrar: add missing file from commit ad37cac

Author: rvlad-patrascu

lib/reg/doc/save_common_flags.xml

@@ -0,0 +1,93 @@
+<listitem>
+	<para><emphasis>'memory-only'</emphasis> - (old <emphasis>m</emphasis> flag)
+	save the contacts only in memory cache without no DB operation;
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'no-reply'</emphasis> - (old <emphasis>r</emphasis> flag)
+	do not generate a SIP reply to the current REGISTER request.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'max-contacts=[int]'</emphasis> - (old <emphasis>c</emphasis>
+	flag) this flag can be used to limit the number of contacts for this
+	AOR (Address of Record) in the user location database.
+	Value 0 disables the check. This parameter overrides the
+	global "max_contacts" module parameter.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'force-registration'</emphasis> - (old <emphasis>f</emphasis>
+	flag) this flag can be used to force the registration of NEW contacts
+	even if the maximum number of contacts is reached. In such
+	a case, older contacts will be removed to make space to the
+	new ones, without exceeding the maximum allowed number.
+	This flag makes sense only if "max-contacts" is used.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'matching-mode=[val]'</emphasis> - (old <emphasis>M</emphasis>
+	flag) How the matching should be performed between the uploaded
+	contacts (by the currently handled REGISTER) and the
+	already know contacts (in memory or DB). This options will
+	be used only for the current operation and can be:
+	<itemizedlist>
+	<listitem>
+		<para><emphasis>'0'</emphasis> - contact URI matching
+		only</para>
+	</listitem>
+	<listitem>
+		<para><emphasis>'1'</emphasis> - contact URI and
+		SIP Call-ID matching</para>
+	</listitem>
+	<listitem>
+		<para><emphasis>'&lt;param_name&gt;'</emphasis> - only
+		the value of the given URI param will be used for
+		matching (for example &lt;rinstance&gt;)</para>
+	</listitem>
+	</itemizedlist>
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'path-off'</emphasis> - (old <emphasis>p0</emphasis> flag)
+	(Path support - 'off' mode) - The Path header is saved into usrloc,
+	but is never included in the reply.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'path-lazy'</emphasis> - (old <emphasis>p1</emphasis> 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 <quote>path</quote> option
+	of the <quote>Supported</quote> header.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'path-strict'</emphasis> - (old <emphasis>p2</emphasis> flag)
+	(Path support - strict mode) - The path header is only saved into usrloc,
+	if path support is indicated in the registration request by the
+	<quote>path</quote> option of the <quote>Supported</quote>
+	header. If no path support is indicated, the request is
+	rejected with <quote>420 - Bad Extension</quote> and the
+	header <quote>Unsupported: path</quote> is included in
+	the reply along with the received <quote>Path</quote>
+	header. This mode is the one recommended by RFC-3327.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'path-received'</emphasis> - (old <emphasis>v</emphasis> flag)
+	if set, the <quote>received</quote> 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 <quote>received</quote>
+	parameter in it's Path uri.
+	</para>
+</listitem>
+<listitem>
+	<para><emphasis>'only-request-contacts'</emphasis> - (old <emphasis>o</emphasis>
+	flag) Only include the REGISTER request's Contacts in the 200 OK
+	reply, in case the registration is successful.  While this
+	is against RFC 3261, it may be useful in certain scenarios.
+	</para>
+</listitem>