Subject: [VIPR] PVP methods priority

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 04 Sep 2011 11:43:10 -0700

The VIPR drafts defines two methods for the PSTN validation:  Method "a", which
is used when the caller-id is available and method "b", which is used when it is
not.  The PVP draft also permits to define new validation methods, but it does
not explain when and how to use this extended methods.

This proposal is in two parts.  First we need to establish a IANA registry for
the PVP methods, and to assign a priority to each of these method.  Let's say
for now that the priority is between -∞ (lowest priority) to +∞ (highest
priority) and that priorities should be assigned by steps of 100.  With this
scale, we could assign priority 0 to method "b" and priority 100 to method "a".
 Then we say in the spec that a VIPR server must try available methods starting
from the highest priority to the lowest priority, until one succeed or all
fails.  This implements the same algorithm that is currently in -pvp ("a" first,
then "b").

Now the problem with this is that the number of methods will increase in the
future, but we may not want having the VIPR server trying all the methods
available each time.  So the second part of this proposal is to have each VIPR
server publishing the list of methods supported by each of its phone numbers in
the RELOAD distributed database, in the existing VIPR-REGISTRATION resource record.

With this information, the PVP client immediately knows what methods to try from
the VIPR-REGISTRATION record, and the order to try them from the IANA registry,
and can also accumulate statistics on the usage of unsupported methods.

The PVP server can use this mechanism to simplify the process.  For example if
it knows that it will never receive the Caller-ID, it just have to never
advertize the "a" method.  Another example is with analog FXO ports that cannot
be used with either method "a" or "b".  In this case the VIPR server can still
advertize a new method using DTMF or fingerprint.

Note that because the methods supported per phone number are stored in the
RELOAD distributed database, the SIP call agent cannot retrieve them to decide
what method to use when starting a call, as it would take too much time to
retrieve it (same reason the validation is not done in realtime).  But it query
them on the background using the history of calls or just before scheduling a
revalidation.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org