<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>