Subject: Re: [dispatch] Introducing ViPR: a new federation technology

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Nov 2009 08:30:58 +0000

Jonathan Rosenberg said:

"Do you not agree that the majority of voice connections are still being established to phone numbers today?"

[BA] Sure.  And I expect this will be the case for going forward too.  My question was more about the application of ViPR to media *other* than voice.

"Firstly, ViPR is equally applicable to video, specifically for cases where video endpoints aren't 'special' - they are the same endpoint I use for my voip calling. When video is just a feature of my pstn-reachable voice device, ViPR works well."

[BA] The question in my mind is whether video really is "special" (in the IM&P sense) or not.  That is, today we accept the idea that anyone should be able to complete a phone call to anyone else.  We also accept this for SMS.  However, we don't accept that idea for Instant Messaging (which typically requires being in the buddy list). Do we accept that principle for video?  I'm not sure.  There are some inherent disadvantages to accepting video calls from anywhere even if we have a verified phone number on the other end.

So even if video is a feature of a voice device, it still might be sufficient to control the ability to complete a video call via a "buddy list".  That's essentially the model for XMPP-based federation with Jingle.  Not good enough to provide telephony as we think of it today.  But this does provide a degree of spam control while retaining something more akin to the RFC 3261 federation model (though perhaps with some loosening).

"I believe there will be infrastructure enum, absolutely. However, I believe it will be used to create peering relationships amongst the carries which are similar to the ones that exist today - with small regional operators federating with larger international ones, which then federate again off to more local ones. IP federation follows a similar model. These federation agreements are likely in many cases to mirror the existing peering relationships on the PSTN. This is because the peering agreements are likely to include actual RTP transport to, along with the CAC/QoS features that are the IP equivalents of what is done in the PSTN today.

That means, in turn, that a call from company A to company B would go as follows:

a.com -> SP1 -> SP2 -> SP3 -> b.com

and, along the way, pass through the myriad of SBCs and SIP infrastructure in each of these providers:

a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress -> SP2-SBC-egress -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com

That eliminates the trapezoidal model of SIP, which I still believe is essential for feature transparency, feature velocity, and security, amongst many other reasons. The feature velocity one is really important. The more that we have intermediaries in the path, the less likely (exponentially so, in fact) it is that any kind of new feature will ever work. There is a ton of precedent for this.

With ViPR, you get:

a.com -> b.com

"

[BA] This seems like the crux of the matter.  Even if the costs are equal to the customer, a ViPR call could be more direct.  If all that's being provided is basic telephony minutes, it might not be very noticeable.  But if there are services involved, you end up with a more evolvable infrastructure.

"SIP trunking would still get you cost savings to non-vipr connected domains and non-voip installations - all of the rest of the existing PSTN endpoints. That'll continue to be useful for a really long time.

ViPR + SIP trunking then further optimizes (and cost reduces) for the domains that you can vipr federate with."

[BA] Infrastructure ENUM potentially can count in its camp phone numbers from the major consumer VOIP providers, as well as phone numbers provided by major SIP trunking providers (who are also presumably utilizing infrastructure ENUM).

While that seems like an advantage, if the SIP trunking provider still charges on a per-minute basis, even for calls which may be carried entirely over the Internet, then there will still be an incentive for a customer to deploy a direct alternative (ViPR, DUNDI, etc.) since that will allow calls made entirely over the Internet to be made for free.  Although we do see cellular operators throwing in "in-networking calling", this is a far cry from throwing in intra-domain or "out of network" calls as well.  This seems a lot less likely.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Nov 2009 15:52:25 -0500

Bernard Aboba wrote:

> [BA] The question in my mind is whether video really is “special” (in 
> the IM&P sense) or not.  That is, today we accept the idea that anyone 
> should be able to complete a phone call to anyone else.  We also accept 
> this for SMS.  However, we don’t accept that idea for Instant Messaging 
> (which typically requires being in the buddy list). Do we accept that 
> principle for video?  I’m not sure.  There are some inherent 
> disadvantages to accepting video calls from anywhere even if we have a 
> verified phone number on the other end.  

I don't think this has much of anything to do with buddy lists.
Even when my mother calls, whether I want to transmit video will vary 
depending on current state. (Am I dressed, is there anything/anybody in 
sight that I don't want her to see, ...)

There are mechanisms and conventions yet to be developed around this. 
There has been little motivation to do it so far because there has not 
been use cases that demand it.

It seems very likely to me that a simple answer is that a video phone 
will typically *answer* in video recvonly mode, and require some manual 
intervention to start transmitting. And when initiating a call from a 
video phone there of course must also be options as to whether to 
transmit by default.

Other more sophisticated features can evolve. But I think they are all 
compatible with a "call anybody" model.

It may however put more of a premium on accurate callerid and calleeid 
information.

	Thanks,
	Paul