VoIP and ENUM

Monday was basically not a good day at the IETF. After the morning session featuring the somewhat problematic ENUM WG (these problems have been solved in the meantime), in the afternoon the next WG session with serious problems took place. This was the first official SPEERMINT session after chartering the WG in quite a long BoF process, and as it seems, there are still many issues what these WG is about to do.

The discussion is still circling around the terms IP network, VoIP peering and Interconnect and proponents from all sides try to misunderstand each other. There are on one side the end-to-end (P2P?) Internet advocates raising the (valid) question what the whole WG is for and on the other extreme end the NGN, 3GPP and IMS walled garden advocates (bell-heads) trying to take over the IETF and make it a better ITU-T(?).

A typical proponent is my friend Sohel Khan with his presentation IP Service Peering Architecture, not even mentioning the Internet.

When I mentioned the ITU-T above, this was on purpose. At ITU-T in Geneva yesterday and today a workshop took place: What Rules for IP-NGN enabled NGNs?

Looking at some of the presentations I finally got the impression that I am in the wrong place, because some of the speakers there are taking the end-to-end principle and the separation of transport and services more seriously into account then some participants here.

I want to draw your attention especially to the presentations from Ernst Langmantel (RTR), John Horrocks (CEPT ECC TRIS/DTI), Wolfgang Reichl (OeFEG/ETP), but also Robert Frieden (Pennsylvania State University) on Net Neutrality, Patrick Xavier (Australia) on USO and of course the excellent presentation and the background paper from Scott Marcus on Interconnection in an IP-enabled NGN Environment(!). This does not imply that the others are not interesting, but I was not able to look at all of them (yet).

So I raised some questions on the SPEERMINT mailing list:

I have some questions for clarification regarding the SPEERMINT charter (or in ITU-T speak: Mr Chairman, I am confused)

"SPEERMINT focuses (on) architectures to identify, signal, and route delay-sensitive (real-time) communication sessions. These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer,or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations."

First question: the term IP networks seems to need clarification:

IP networks is a generic term valid for both the Internet and private (walled garden) IP networks, but

I had always the opinion that this is the INTERNET Engineering Task Force (IETF) and the PRIMARY goal is to define architectures to identify, signal and route ... sessions on the public INTERNET.

This does not prevent anybody to use these architectures and related protocols also on private IP networks, as it is done with other protocols and architectures (e.g. the DNS).

But is is NOT the task of the IETF to define such architectures and protocols PRIMARILY for the use in private IP networks.

So I understand that the primary goal of SPEERMINT is to enable peering between two or more administrative domains on the INTERNET and also to establich trust, security and resistance to abuse and attacks on the Internet.

I consider it therefore curious that some say the I-Ds draft-lendl-domain-policy-ddds-00 and draft-lendl-speermint-federation-00 are out of scope (presentation). If these drafts are out-of-scope then maybe somebody would be so nice to explain to me what is in scope of SPEERMINT.

I am also confused about the statement from Rohan Mahy that nobody will use this because no provider will make it public to which federation he belongs to.

Since this I-Ds are modelled along the quite sucessful model of BGP peering, I wonder.

Michael Haberler added to this more details:

I'd be very interested what people believe to be a viable alternative to runtime policy discovery - in particular visavis the fact that the draft-lendl-domain-policy-ddds-00 proposes to pubish a unique ID for a policy to enable runtime matching, but NOT requiring to publish what that policy ID actually stands for.

In BGP speak this amounts to: "Here is my AS number. You might find that AS number tacked to other domains if you scan a lot of them, but no, we are not publishing our peering and transit relations in an RIR database". As for the BT example, saying that the sip.bt.com ingress point supports the BT IP interconnect policy, which is likely to be found on a BT website as their Reference Interconnect Offer in the first place. So much for the danger of "private parts exposure".

I have a hard time believing we are back to static local configuration as the "preferred" solution, be that bilateral setup or "everything goes to my peering shop".

Here's a paper exercise for you to tinker with alternatives:

With SIP capabilites as they stand today, please emulate the GSM association - that's 600+ operators with some 23.000 interconnect agreements.

In the first attempt, try to avoid the "big SIP hub" scenario for extra intellectual challenge.

After done with defining pathetic access lists and local routing tables, I assume you're motivated to think about alternatives. Then again, if one has gobs of staff managing interconnect relations, that staff could well eventually be retrained to edit access control lists and tables.

From a commercial point of view, there likely is a business case for the SIP hubs/peering providers. I think they have real value asSIP/RTP cleansing shops. I'm not sure that approach should be the IETF entropy solution to fabric discovery.

And, while lashing out at the unsuitability of draft-lendl-domain-policy-ddds-00 for current service provider mindsets, keep in mind it does not limit itself to "carriers" - it does address groups of users, and in fact the user-service provider interface policy discovery problems just as well.

Bonus value: it also includes "go to my peering shop" - besides keeping the end-to-end option open.

It is true that SPEERMINT is special (optional?) within the IETF, because to peer between SIP proxies on the Internet all you need is SIP AoRs and RFC 3263 NAPTR and SRV, and I also understand that the major problem of the VSP starts with the SIP URI giving away their identity (some peering fabrics make a living on this ;-)

Nobody seems to have a problem with this with e-mail.

Voice is really a special application, seemigly infecting anybody with bell-headism.