Subject: [VIPR] Renewal of VIPR ticket

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 02 Sep 2011 16:05:05 -0700

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 to to use 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 revalidate the route, based for
example on the frequency of calls to this number and the remaining validity of
the ticket.  The Call Agent 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 Call Agent 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 th e48 hours after the
expiration of the ticket).  If the remote Call Agent 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 +14085551234
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 Call Agent check 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 Call Agent 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 uploaded to the VIPR server as for an initial call.  The local
party marks the route as been under revalidation, 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.

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