[VIPR] Agenda & Handout for 2011/09/30

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A. Agenda

- - Security section of -overview (5 min)
- - SIP Intermediaries (10 min)
- - Capabilities (10 min)
- - RELOAD registration (5 min)
- - PVP privacy (10 min)
- - PVP method priority and registration (10 min)
- - PVP method entropy (10 min)
- - Replacement ticket by client certificate (10 min)
- - Ticket renewal (10 min)
- - Infrastructure overlays (5 min)

Note that the sum of the time allocated to each topic exceeds the time allocated
to the whole call.  The topics that cannot make it to the discussion will be
postponed to the next conference call if they are not subsequently decided in
the mailing-list.

Because the conference bridge as a limited capacity, an individual invitation to
the conference will be sent shortly after this email to each member of the
design team.  Please send me an email if you are not on this list and want to
receive an invitation.

Note that the design team conference call is not a way to short-circuit the
normal process, but a way to accelerate it by increasing face to face time.  All
decisions made must be confirmed on the mailing-list.

This conference call is subject to the rules of RFC 5378 and RFC 3979 (updated
by RFC 4879).


B. Handout (reading time: 15 min)

B.1 VIPR Overview - Security section

An updated version of -overview has been submitted but the security section may
need some more work.  We want to submit -overview as soon as possible, so
finishing this spec has the highest priority. Here's the current text:

"6.  Security Considerations

   Security is incredibly important for VIPR.  This section provides an
   overview of some of the key threats and how they are handled.

6.1.  Attacks on the DHT

   Attackers could attempt to disrupt service through a variety of
   attacks on the DHT.

   Firstly, it must be noted that the DHT is never used at call setup
   time.  It is accessed as a background task, solely to learn NEW
   numbers and routes that are not already known.  If, by some tragedy,
   an attacker destroyed the P2P network completely, it would not cause
   a single call to fail.  Furthermore, it would not cause calls to
   revert to the PSTN - calls to routes learned previously would still
   go over the IP network.  The only impact to such a devastating
   attack, is that a domain could not learn *new* routes to new numbers,
   until the DHT is restored to service.  This service failure is hard
   for users and administrators to even notice.

   That said, VIPR prevents many of these attacks.  The DHT itself is
   secured using TLS - its usage is mandatory.  Quota mechanisms are put
   into place that prevent an attacker from storing large amounts of
   data in the DHT.  Other attacks are prevented by mechanisms defined
   by RELOAD itself, and are not VIPR specific.

6.2.  Theft of Phone Numbers

   The key security threat that VIPR is trying to address is the theft
   of phone numbers.  In particular, a malicious domain could store,
   into the DHT, phone numbers that it does not own, in an attempt to
   steal calls targeted to those numbers.  This attack is prevented by
   the core validation mechanism, which performs a proof of knowledge
   check to verify ownership of numbers.

   An attacker could try to claim numbers it doesn't own, which are
   claimed legitimately by other domains in the VIPR network.  This
   attack is prevented as well.  Each domain storing information into
   the DHT can never overwrite information stored by another domain.  As
   a consequence, if two domains claim the same number, two records are
   stored in the DHT.  An originating domain will validate against both,
   and only one will validate - the real owner.

   An attacker could actually own a phone number, use it for a while,
   validate with it, and build up a cache of routes at other domains.
   Then, it gives back the phone number to the PSTN provider, who
   allocates it to someone else.  However, the attacker still claims
   ownership of the number, even though they no longer have it.  This
   attack is prevented by expiring the learned routes after a while.
   Typically, operators do not re-assign a number for a few months, to
   allow out-of-service messages to be played to people that still have
   the old number.  Thus, the TTL for cached routes is set to match the
   duration that carriers typically hold numbers.

   An attacker could advertise a lot of numbers, most of which are
   correct, some of which are not.  VIPR prevents this by requiring each
   number to be validated individually.

   An attacker could make a call so they know the call details of the
   call they made and use this to forge a validation for that call.
   They could then try to convince other users, which would have to be
   in the same domain as the attacker, to trust this validation.  This
   is mitigated by not sharing validations inside of domains where the
   users that can originate call from that domain are not trusted by the
   domain.

6.3.  Spam

   Another serious concern is that attackers may try to launch SIP spam
   (also known as SPIT) calls into a domain.  As described in
   Section 5.3.3, VIPR prevents this by requiring that a domain make a
   PSTN call to a number before it will allow a SIP call to be accepted
   to that same number.  This provides a financial disincentive to
   spammers.  The current relatively high cost of international calling,
   and the presence of national do-not-call regulations, have prevented
   spam on the PSTN to a large degree.  VIPR applies those same
   protections to SIP connections.

   VIPR still lowers the cost of communications, but it does so by
   amortizing that savings over a large number of calls.  The costs of
   communications remain high for infrequent calls to many numbers, and
   become low for frequent calls to a smaller set of numbers.  Since the
   former is more interesting to spammers, VIPR gears its cost
   incentives away from the spammers, and towards domains which
   collaborate frequently.

   It is important to note that VIPR does not completely address the
   spam problem.  A large spamming clearing house organization could
   actually incur the costs of launching the PSTN calls to numbers, and
   then, in turn, act as a conduit allowing other spammers to launch
   their calls to those numbers for a fee.  The clearinghouse would
   actually need to transit the signaling traffic (or, divulge the
   private keys to their domain name), which would incur some cost.  As
   such, while this is not an impossible situation, the barrier is set
   reasonably high to start with - high enough that it is likely to
   deter spammers until it becomes a highly attractive target, at which
   point other mechanisms can be brought to bear.  This is, again, an
   example of the incremental deployability philosophy of VIPR."

B.2 SIP intermediaries

One of the things that was discussed in the last conference call was about VIPR
domains that are not directly connected to the PSTN, but that are using
intermediaries (e.g. SIP trunk).  The problem is that an intermediary will
probably use VIPR for toll bypass, whereas the main use case for VIPR is to be
able to use enhanced features (wideband audio, video, text, etc...) between VoIP
islands.

So I would like to present a proposal to solve this issue, but as this is a
little bit unorthodox, I'll present it progressively.

This first diagram depicts the routing process as described by the current spec:

    ,~~~~~~~~~~~~~~~~~~~~~>
UAC<
    `--------------------->

In this diagram, the UAC is directly connected to the PSTN, and use the route
database to choose if the call is using the PSTN (top arrow) or if the call is
using SIP and enhanced features (bottom arrow).  We will probably need in the
future to define a profile for this SIP connection, but for now let's just
define a SIP profile that supports wideband speech and audio, video, text, file
exchanges, games, etc... and call it SIPbeyond (in reference to "SIP beyond
VoIP" by Sinnreich and al.).

In some VIPR domains, the PSTN connection would still be inside the domain, but
would be physically separated from the UAC, using a connection between the UAC
and the PSTN gateway, which gives us the following diagram:

   PSTN~~~~~~~~~~~~~~~~~~>
   /
  /
UAC---------------------->

Here the link between "UAC" and "PSTN" uses SIP but with a different profile.
This time there is an existing profile SIPconnect, so we'll use it for the
remaining of the discussion.  The UAC still decides based on the content of the
route database and will use SIPbeyond if a route is found, and SIPconnect to the
PSTN gateway if no route is found.

Now there is nothing that prevents moving the PSTN gateway outside the VIPR
domain, and still using the SIPconnect profile.  The issue is that the entity
managing the PSTN gateway can decide to also be a VIPR domain itself, but
because the SIP connection is using the SIPconnect profile, it cannot do more
than using VIPR as a toll pass, as the direct SIP route created will never be
able to use enhanced features, thus defeating the main goal of VIPR.

One solution would be to merge the SIPconnect and SIPbeyond profile when sending
the request to the PSTN gateway, but that will complicate things and in the end
nobody will implement this. My proposal is to send *both* profiles to the
upstream VIPR domain, in a multipart/alternate body, as shown in this diagram:

     PSTN~~~~~~~~>
     /
    /
  Proxy---------->
  //
 //
UAC-------------->

In this diagram, the UAC uses the route database to choose if the call is direct
and using SIPbeyond (bottom arrow) or if the call is sent to an external domain
for processing (the double link above the UAC).  The SIP request contains two
SDPs, one for SIPconnect, one for SIPbeyond.  The SIP proxy in the upstream VIPR
domain uses its own route database to choose between a direct route (by
stripping the SIPconnect SDP from the request and adding the ticket) or using
the PSTN (by stripping the SIPbeyond SDP).  Note that an external domain that
does not support multipart would simply reject the SIP request with a 415, so
the UAC can resend the request with only the SIPconnect SDP, knowing now that
the external domain is not a VIPR domain.

We can now extend the mechanism to multiple levels of VIPR domains, and even use
this mechanism inside the VIPR domain closest to the user (so the network
elements choosing how to route is separated from the UAC), as shown in this diagram:

                PSTN~~~~~>
                /
               /
             Proxy------->
             //
            //
          Proxy---------->
          //
         //
UAC===>Proxy------------->

Here's an example of a SIP INVITE body that contains the two SDPs:

- --boundary
Content-Type: application/sdp

v=0
o=- 1 1 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 8000 RTP/AVP 0 96 97
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G729/8000
a=rtpmap:97 telephone-event/8000
- --boundary
Content-Type: application/sdp

v=0
o=- 2890844526 2890842807 IN IP6 2001:DB8::1
s=
c=IN IP6 2001:DB8::1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 54312 RTP/SAVP 101
b=RS:0
b=RR:0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
a=rtpmap:101 opus/48000
a=fmtp:101 maxcodedaudiobandwidth=16000; maxaveragebitrate=20000;stereo=1;
useinbandfec=1; usedtx=0
a=ptime:40
a=maxptime:40
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998
m=video 49170 RTP/SAVPF 98
b=RS:0
b=RR:0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
a=rtpmap:98 VP8/90000
a=fmtp:98 version=0
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998
m=text 11000 RTP/SAVP 98 100
b=RS:0
b=RR:0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000
a=fmtp:100 98/98/98
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998
- --boundary--

We would need to define a convention in the order of the SDPs so a proxy knows
which SDP is SIPconnect, and which SDP is SIPbeyond.  Also, as for SIPconnect
and SIPbeyond, the INVITE containing the alternative SDPs must use TLS.

B.3. Capabilities

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

Bottom line is that in this case two routes are learned,
1 -- Being advertized by the Enterprise
2 -- The route from providerA.

Ideally we would like to use the route advertized by Enterprise as it is nearest
to the endpoint and the probability of getting all the IP services (voice,
video, SMS etc) on this route has much higher likelihood. On the other hand
ProviderA's route is a valid route too. The issue is as to how the "learning
entity" ProviderB in this use case is capable of making decisions that offer the
best capability (video etc) for calls between PhoneB and PhoneA.

Option 1:- During the publication of the number the entities publishing the
number also publish the capabilities of the endpoint, possibly read from the
registrar or learned by other means. So when issuing a ticket based on the
publication the the route includes the capabilities also, for example:

  (& (sip.audio=TRUE)
      (sip.video=TRUE)
      (sip.mobility=fixed)
      (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
         (sip.methods=ACK) (sip.methods=CANCEL)))

Again relies on trust that the publisher (or the issuer of the route and ticket)
is not lying about the capabilities. Based on the the capabilities received in
the Route the originator of the call can pick a route that is optimal in terms
of capabilities. Now the issue is that ProviderA which is SIP capable could
provide similar capabilities as it is connected via SIP to the endpoint.

Option2: Learn all the routes and recommend use them in some policy based
fashion ( round robin etc) and eventually mark the routes based on what
capabilities these routes provided the endpoints for future usage -- Work at the
SIP layer.

B.4. RELOAD registration

Let's now move to the interactions between the VIPR domain and the RELOAD
overlay.  The current specification states that a phone number must be
registered 3 times, which with the underlying replication done by the CHORD
RELOAD algorithm, means that the mapping between a PVP server and a phone number
is stored 9 times.  The problem discussed in Quebec City was what to do when the
3 copy retrieved from the overlay are not identical, and the proposal was to use
the copy that appears at least twice, so no peer can alone create a denial of
service for a specific number.  The discussion moved to the reasons for having 3
copies in the first place.

The proposal is to drop the requirement for the 3 copies from VIPR, but to add
the requirement that the node requesting the phone number MUST also fetch (or
stat) the 2 additional replicas and use the value that matches at least one
other copy (using a majority vote prevents a rogue peer to block the access to
the phone numbers currently stored here).  If not all 3 copies are equals, then
an incident must be logged.  The PVP client must retrieve the 2 replicas in
addition to the original registration and use the voting algorithm to choose one
and log an incident if all 3 are not equal.

B.5. Ticket vs Client certificate

In the current specification, the PVP server builds and signs a VIPR ticket, and
sends it back to the PVP client, which passes it to the SIP element.  The SIP
element will insert this ticket in the next SIP method to the remote SIP
element, which will check the validity of the ticket and the domain of the TLS
client.

There is multiple problems with this process:

- - The verification of the ticket use HMAC-SHA1, and so the same password has to
be provisioned in both the SIP element (to verify the ticket) and the PVP server
(to generate the ticket).
- - The ticket can be used without TLS, and we all know that implementers think of
MUST as SHOULD and SHOULD as MAY.

So the proposal would be to replace the ticket by a client certificate, which
could work like this:

Instead of using a symmetrical key, the local PVP server generates an RSA key
pair, with the public key distributed to the SIP element(s).  After a successful
PVP connection, the remote PVP client sends a PKCS#10 certificate request,
containing the domain name and signed with a private key.  The local PVP server
generates a new certificate, sign it with its private key and send it back to
the remote PVP client, which pass it back to the remote SIP element.

The remote SIP element will use the certificate received to establish the TLS
connection for the SIP transactions to the local SIP element, which will use a
standard CA based certificate for its own domain.  The local SIP element will be
able to verify with the PVP server public key that it issued the certificate,
then will validate the standard parts of the certificate (expiration date and so
on).

There is multiple advantages to this proposal:

- - The private key is stored only in the PVP server, or better in a physical token.
- - VIPR does not work without TLS for the SIP connection.
- - There is plenty of commercial or free TLS and X.509 implementations that have
years of experience and testing, which is not the case for the ticket proposal.
- - Security agility is provided by TLS.
- - No additional SIP Header.
- - Because the ticket verification process is folded into the client certificate
verification, less processing resources are needed.

B.6. PVP Privacy

As reported by Michael Procter, there is ways with the current PVP methods to
discover valuable information about a competitor.  But first let's add some
common vocabulary related to PVP:

- - The PVP selector is a list of parameters that are sent by the PVP client side
to retrieve a set of call records in the PVP server side.  The resulting set can
be empty, in which case the validation fails, can contain one element, or can
contain multiple elements in which case the method description must also defines
what call record should be selected (e.g. in the case of method "a", the most
recent call record is selected).  One important point is that the selector is
always passed from the PVP client to the PVP server in clear, and so this is
where the privacy leakage happens.

- - The PVP parameter is a list of name/value pairs that are passed in clear
between the PVP client and PVP server to aid the verification.  Examples are the
rounding value and the vservice id for methods "a" and "b".

- - The PVP secret is the information that each side of the PVP transaction tries
to verify.  The algorithm used (SRP) uses a zero-knowledge password proof, so
neither side can deduce the secret if the verification fails.  In the case of
methods "a" and "b" the secret is the rounded start and end time for the call,
but there is a lot of other possible secrets that can be used in new methods
(DTMF, UUIE, fingerprint, SMS hash, etc...).

In the privacy issue, the problem is that callee number and caller numbers are
disclosed in the PVP selector for method "a" and the callee number is disclosed
in the PVP selector for method "b".

One proposed solution would be to hash these numbers, but finding the phone
numbers would still be trivial for a determined competitor.  Passing the hash
salt as a PVP parameter and using an adaptive hash method like bcrypt will force
the PVP server to rehash all the current terminating call record, but will force
a competitor to rehash probably half of the total E.164 space to find the
numbers.  This is still possible but can provide an adequate privacy protection
level.

Another possibility would be to invert the selector and the secret.  After all
the star/stop time of a call is not as sensitive as the caller/callee phone
numbers.  In this method the PVP selector would be the start/stop time and the
secret would be the caller/callee numbers.  The problem is that it will be more
difficult to design an algorithm to select a unique call record if the returned
set contains more than one.  One solution could be to add more data in the PVP
selector, for example by adding the call initiation time and the direction of
the termination.

We do not even need to decide - we can define these two algorithms as different
methods (in addition to "a" and "b") and let the VIPR domain choose (see PVP
registry proposal).

B.7. PVP Methods Registry

On the PVP subject, The VIPR specification currently 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 methods.  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 succeeds or all
fail.  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 that the PVP client tries all the methods available
each time.  So the second part of this proposal is to have each VIPR domain
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 real-time).  But it can
query them in the background using the history of calls or just before
scheduling a re-validation.

I would also propose to move the description of the generic PVP algorithm to the
- -framework document, to add a section in -framework explaining how to register a
new method on a IANA registry and to keep the two existing methods ("a" and "b")
into the -pvp draft.

B.8. PVP Entropy

A second issue related to PVP is the management of entropy (Section 10.1 of the
- -pvp draft).  The idea is that the fact that one validation succeeds is not
always enough for a remote VIPR server to give back routes and ticket for this
destination.  For example a VIPR domain could decide that at least 3 different
calls validated with method "b" are needed to let a SIP call reach the endpoint.

This proposal describes a mechanism for PVP to implement this.  The idea is that
when a PVP validation succeeds, the PVP server will return a ticket but may not
return the list of routes if the entropy threshold is not reached.  The ticket
will contain an opaque value set by the PVP server that contain the level of
entropy that this caller has reached.  The PVP client stores the ticket but does
not notify the call agent as there is no routes available.  The next time the
PVP client has a successful validation with the same destination, it sends the
saved ticket in addition to the domain.  The PVP server then evaluates the
ticket, increases the entropy value stored and sends back a new ticket.  If the
threshold has been reached, then the PVP server sends back the routes at the
same time, routes that the PVP client can now send with the ticket to the SIP
element.

When renewing the routes/ticket, the PVP client also sends the existing ticket,
so the PVP server can decide to lower the threshold based on the entropy
collected the previous time and the date of the ticket.

This can be combined with the proposal for method priority.  If multiple methods
are available for a destination but the first that succeeds does not return the
routes then the PVP client can use the next available methods in the list to try
to increase the entropy and receive them.

A PVP server may even use different thresholds, depending on the domains to
validate.  This then becomes an extension to the white/black list, where a
blacklist is implemented as a default threshold of X and an infinite threshold
for the domains blacklisted, and where a whitelist is implemented as a default
infinite threshold and a threshold of X for the domains whitelisted.

B.9. Ticket renewal

Another thing that was discussed in Quebec City was the "First Call Problem",
i.e. the problem that it takes up to 48 hours to verify a call and been able to
use enhanced media.  I think the conclusion of the discussion was that it was
not too annoying for the first call, as it did not degrade the user experience.
On the other hand, the cryptographic ticket granted after the first has an
expiration date and so need to be renewed, and that will degrade the user
experience as it would mean that for each destination, the end-user will
periodically not be able to use enhanced media for the duration of a call.

There was multiple proposals at the microphone to solve this problem, but I
would like to detail the one I proposed.

The idea is, sometimes before the expiration of the ticket, to make in parallel
a PSTN call and a SIP call using the existing SIP route and ticket for the
enhanced media (let's say video for the remaining of this discussion).  There is
already an existing I-D that can be use for this, draft-ietf-mmusic-sdp-cs.  The
way it could work is that the call agent, after retrieving the SIP route and
ticket for a destination, will decide that it is time to re-validate the route,
based for example on the frequency of calls to this number and the remaining
validity of the ticket.  The SIP element then adds an additional m= line to the
SDP that contains a PSTN address.  The offered SDP then looks something like this:

v=0
o=- 2890844526 2890842807 IN IP4 10.47.16.5
s=
c=IN IP4 10.47.16.5
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 9 PSTN -
c=PSTN - -
a=setup:active
a=connection:new
a=cs-correlation: uuie callerid dtmf
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

The SIP element on the other side verifies the ticket then starts to process the
SDP.  If it does not support this feature then, as per the rules in RFC 3264, it
will reject the second m= line by using port 0 in the answer SDP (In this case
the end user will have to have PSTN only calls for the 48 hours after the
expiration of the ticket).  If the remote SIP element supports this extension
then it will send back an offer like this:

v=0
o=- 0 1 IN IP4 192.168.2.1
s=
c=IN IP4 192.168.2.1
t=0 0
m=audio 8000 RTP/AVP 0
m=audio 9 PSTN -
c=PSTN E164 [phone]
a=setup:passive
a=connection:new
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3
m=video 9000 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

The local SIP element checks that the c= line contains the right number, then
establishes the audio and video media over IP, as usual, but also starts a PSTN
call following the rules in draft-ietf-mmusic-sdp-cs (i.e. sending the
correlation value as needed).  The remote SIP element will receive the PSTN
call, and correlate it with the existing SIP connection.  Both parties must send
audio on both the IP and the PSTN side, but the receivers can choose to play the
audio coming from either the IP or PSTN connection (this is because we may want
to use in the future fingerprint methods for the validation).  The PSTN call is
ended at the same time than the IP connection if the methods used for validation
are based on the call duration (other methods may permit to end the call
before), so the VCRs are processed as for an initial call.  The local party
marks the route as been under re-validation, so to not use the renewal method
for the next 48 hours.  The VIPR server will send a notification before the end
of the 48 hours if there is still a PSTN route to this destination.

B.10. Infrastructure overlays

A new draft to discuss infrastructure overlays has been submitted to DISPATCH.

"[RELOAD] is a peer to peer protocol developed by the P2PSIP Working
 Group.  Each RELOAD instance has a unique name, which is used by the
 process in section 10.2 of this specification to find the
 configuration servers, enrollment servers and bootstrap servers
 needed to join the overlay.  The process assumes that the RELOAD
 instance name is a FQDN, and uses the process in [RFC2782] (SRV RR)
 to find the IP address of the HTTPS server that serves the
 configuration document for this overlay.

 This process is adequate when the management of the overlay does not
 need to be distinguished from the owner of the FQDN used as the
 instance name, which is the case most of the time.  But there is a
 special class of overlays that, by definition, requires to be unique
 on the Internet and for which having the possibility of create
 instances would defeat their very purpose.  This specification calls
 the kind of overlays that are not domain specific, but application
 specific "infrastructure overlays".

 [VIPR] is a technology that is being standardized in the VIPR Working
 Group and that aims to build bridges between SIP islands by
 automatically provision SIP routes after the "ownership" of a PSTN
 phone number has been verified by an actual PSTN phone call.  This
 technology uses an RELOAD overlay as a distributed database where
 mappings between phone numbers and servers responsible for the
 validation process are stored.  The promise of VIPR to bridge these
 SIP islands cannot be fulfilled if there is more than one distributed
 database storing these mappings."

- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6ElZwACgkQ9RoMZyVa61fCLgCfY7b+Go3epz6jxNWM+DxaLaJv
sL0An1+11Gt2d+nZE1riW7wBbbBOQAgZ
=KNPf
-----END PGP SIGNATURE-----