Richard wants feedback, so here it comes.
This document is a _lot_ better than -01. Much more consistent.
Overall impressions:
-
This is a telco design. Basic bell-head thinking with only some marginal sprinkling of Internet ideas. This is a document which describes how one might carry over the telco provisioning, interconnection and call routing approaches to the VoIP world.
All fine and good, but to be provocative: why is this an IETF WG document and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a most use-cases are almost straight from the PSTN playbook.
- This is way too ambitious on one hand. Defining all this in a single protocol and implementing the registry which actually does all these things is a herculean task.
Layering, folks. Layering.
Divide the problem into discrete, clearly separated sub-problems (see the speermint LUF/LRF split for a good one) and the complexity can be brought under control.
- This is way too conservative on the other hand. There is little dynamic routing. There is no integration of enterprise VoIP routing with carrier routing. There no possibility of ad-hoc peering.
Okay, some specifics:
SED Record: A SED Record contains much of the session establishment data or a ‘redirect’ to another registry where the session establishment data can be discovered. SED Records types supported are NAPTRs, CNAME, DNAME, and NS Records.
What about TLS parameters, Source IP addresses of SBEs, Codec constraints, SIP profiles, …
This is far too DNS focussed.
SED is typically created by the terminating SSP and consumed by the originating SSP.
Careful here: in the case of multi-hop routing, the SED towards the next hop are relevant, and these may have little to do with whatever the terminating SSP has created. See 4.2.2. of the speermint terminology draft.
For scalability reasons SED is rarely exchanged directly between the intended parties. Instead, it is exchanged via intermediate systems – termed Registries within this document. Such registries receive SED via provisioning transactions from other SSPs, and then distribute the received data into Local Data Repositories.
This is true for anything dealing with TNs. Once these are mapped to something amenable to aggregation, this argument falls completely down.
We have a serious mistake in the base assumptions here. If we do proper layering, then the routing information does *not* need these intermediate registries. The registries are only needed for the TN -> Destination-Group mapping.
Yes, that’s the way it has been done in the PSTN and thus it would be easy to integrate VoIP into the same provisioning processes.
That’s one of the fundamental design question: do we design an incremental update to the way carriers have been operating, or do we design an addition to the IETF SIP world which enables scalable multihop routing based on TNs?
These are two very different goals.
—
o Registries are the authoritative source for provisioned session establishment data (SED) and related information.
Eeek.
SED includes what the next hop is. In a dynamic network, this can change quickly as SBEs or links fail, congestion makes paths unavailable or some business decisions make a different path more attractive.
I cannot fathom that
- these real-time routing information is exchanged via the registry,
- carriers outsource the business decision part of the call routing algorithm to third parties.
—
o Aggregation of public Identifiers: The initial input “key” to a SED lookup is a public identifier. Since many public identifiers will share similar (or identical) destinations, and hence return similar (or identical) SED, provisioning the same set of SED for millions of public identifiers is inefficient, especially in cases where the SED needs to be modified. Therefore, an aggregation mechanism to “group” public identifiers is proposed. This
aggregation is called a “destination group”.
This is very good.
(and I’m tempted to say that this is all the registries should handle. Everything else can be done bi-laterally.)
—
Minor nit: please define the acronyms RN and TN. The latter is trivial (or not, once you leave the E.164 world), but the former might have country-specific meanings.
—
– A Public Identity is associated with zero or more SED Records
uhh, please don’t go there.
—
The actual use-cases aren’t that exciting for me, as the overall architecture decisions I criticize are not a consequence of the use-cases, but rather seem to come from a “that’s the way we do things around here” argument.
That’s a bit thin.