Subject: [VIPR] PVP validation

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 09 Aug 2011 16:02:15 -0700

During my presentation in Quebec City, I promised more explanations on the PVP
slide.

Let's imagine that an Enterprise is using ProviderA to route its calls (e.g.
with a SIP trunk).  The following diagram shows what happen in this case.  Note
that the RELOAD overlay is shown as one network element as the only feature that
we care about here is its distributed database and that I used different lines
symbols for different protocols:

  PhoneA    Enterprise     ProviderA       RELOAD       ProviderB   PhoneB
    |           | Store        |              |             |         |
1   |           |---------------------------->|       Store |         |
2   |           |              | Store        |<------------|         |
3   |           |              |------------->|             |         |
    :           :              :              :             :         :
    | INVITE    |              |              |             |         |
4   |==========>| INVITE       |              |             |         |
5   |           |=============>| SETUP        |             |         |
6   |           |              |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| INVITE  |
7   |           |              |              |             |========>|
    :           :              :              :             :     BYE :
8   |           |              |              |        DISC |<========|
9   |           |          BYE |<~~~~~~~~~~~~~~~~~~~~~~~~~~~|         |
10  |       BYE |<=============|              |             |         |
11  |<==========|              | Fetch        |             |         |
12  |           | Fetch        |------------->|             |         |
13  |           |---------------------------->|             |         |
    |           |              | ValExchange  |             |         |
14  |           | ValExchange  |:::::::::::::::::::::::::::>|         |
    |           |::::::::::::::::::::::::::::::::::::::::::>|         |
    :           :              :              :             :         :
    | INVITE    |              |              |             |         |
15  |==========>| INVITE       |              |             |         |
16  |           |==========================================>| INVITE  |
17  |           |              |              |             |========>|
    |           |              |              |             |         |

Independently, Enterprise and ProviderA decide to deploy VIPR, so they both
register (1, 3) the same phone number for PhoneA in the RELOAD distributed
database.  Separately ProviderB also registers (2) the phone number of PhoneB in
the RELOAD database.

PhoneA makes a call (4) which is not in the route database of Enterprise, so it
is proxied (5) to ProviderA.  ProviderA does not have a route either, so the
call is routed through the PSTN (6) to ProviderB and over IP to PhoneB (7).

After some time the call ends, so PhoneB sends a BYE (8) that is routed over the
PSTN (9) and IP (10, 11) to PhoneA.  ProviderB uploads a terminating VCR and
*both* Enterprise and ProviderA upload an originating VCR, which *both* will
trigger the establishment of a PVP connection and a ValExchange transaction.

In the example above both PVP transactions succeed because the text now says
that the terminating VCR must not be removed until the end of the 48 hours
period, even if a PVP transaction succeeded.  In this case, the route stored by
Enterprise is used for the next call (15, 16, 17) because it is the first call
agent in the path, but if for some reason this route would fail the call would
still be VoIP end to end, thanks to the route stored in ProviderA.

Without this rule, we cannot predict which one of the two ValExchange
transaction will start first (and we do not want create a race to who's win by
using priorities), so we now are sure that it is always the closer route to the
caller that will be used and that the others routes will be used as backup.

Note that if only ProviderA route is created (as it would happen in 50% of the
case with the old text), the Enterprise route will still be created on the
second call.  Using the new text permits to have only one PSTN call (from the
point of view of the Enterprise) and maximize the number of backup routes at all
times (we probably want to set the ticket expiration value to the same for all
VIPR servers to be sure that the next PSTN call will revalidate all the routes).

Now let switch to the scenario in the other direction.

  PhoneA    Enterprise     ProviderA       RELOAD       ProviderB   PhoneB
    |           | Store        |              |             |         |
1   |           |---------------------------->|       Store |         |
2   |           |              | Store        |<------------|         |
3   |           |              |------------->|             |         |
    :           :              :              :             :         :
    |           |              |              |             |  INVITE |
4   |           |              |              |       SETUP |<========|
5   |           |       INVITE |<===========================|         |
6   |    INVITE |<=============|              |             |         |
7   |<==========|              |              |             |         |
    : BYE       :              :              :             :         :
8   |==========>| BYE          |              |             |         |
9   |           |=============>| DISC         |             |         |
10  |           |              |~~~~~~~~~~~~~~~~~~~~~~~~~~~>| BYE     |
11  |           |              |              |       Fetch |========>|
12  |           |              |              |<------------|         |
    |           |              |              | ValExchange |         |
13  |           |              |<:::::::::::::::::::::::::::|         |
    |           |              |              | ValExchange |         |
14  |           |<::::::::::::::::::::::::::::::::::::::::::|         |
    :           |              :              :             :  INVITE :
15  |           |              |              |      INVITE |<========|
16  |           |       INVITE |<===========================|         |
17  |    INVITE |<============ |              |             |         |
18  |<==========|              |              |      INVITE |         |
19  |           |<==========================================|         |
    |    INVITE |              |              |             |         |
20  |x==========|              |              |             |         |
    |           |              |              |             |         |

The first 3 steps are identical to the first diagram, but now PhoneB calls
PhoneA, call that goes through the PSTN and reaches ProviderA before Enterprise
(4, 5, 6,7).  The call ends the same way than in the previous diagram (8, 9, 10,
11), excepted that now it is ProviderB that initiates the verification.  When it
fetches the Node-Ids responsible for PhoneA (12), it receives two, which is not
an abnormal case.  As per the rules in VIPR, it will initiates a PVP connection
to both of them, but what is new is that *both* will succeed.  Per the current
rules, only the last one will be kept, but again there is a 50% chance that the
route kept is not the best.  Instead I suggest to keep *both* and to use *both*
for the subsequent call, by forking it to the two destinations (15, 16 and 19).
 In best case, both requests will reach PhoneA (17, 18, 20), but the second will
be rejected (20), thanks to the "Merged Requests" rule in RFC 3261 section 8.2.2.

An additional problem that need to be fixed in the spec is that we need to
clearly defines which SIP error codes are used to simply signal that the route
does not work at the time of the call, and which one are used to remove a route
from the VIPR database.

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