[VIPR] Upstream VIPR domains

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

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

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[1].

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[2], 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
m=audio 54312 RTP/SAVP 101
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
m=video 49170 RTP/SAVPF 98
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN
a=rtpmap:98 VP8/90000
a=fmtp:98 version=0
m=text 11000 RTP/SAVP 98 100
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
- --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.



[1] In reference to "SIP Beyond VoIP" by Henry Sinnreich, Alan B. Johnston and
Robert J. Sparks.
[2] http://www.sipforum.org/sipconnect

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

iEYEARECAAYFAk6AsrQACgkQ9RoMZyVa61dr2ACeK7cQmnO/BGkjwTzw9MO5bnP2
cDEAniUm0SK2Ie1dStDJ1b9NgBUp8Opw
=gtBy
-----END PGP SIGNATURE-----