Tuesday, November 29, 2005
Monday, November 28, 2005
Well, he (they?) is (are?) also in Tele?communications ;-)
Sunday, November 27, 2005
Michael was showing around Rich in Vienna on Thursday, while I was busy in the office during the day and met co-blogger Andy Abramson and Helen for dinner. Andy is also currently travelling in Europe and just arrived from Nice. Andy loves excellent food and he is also a wine expert, so it was a very enjoyable and also interesting evening for me.
On Friday, ISPA (Internet Service Providers Association) took the chance having Richard Shockey and also TImothy Jasionowski from Nokia at the same time in Vienna and invited the locals to have an ad-hoc meeting with the two. I offered Andy to join in and he obviously enjoyed it, having a long conversation with Tim.
The session started with Richard explaining the locals ENUM in a nutshell ;-)
Tim continued with showing off the new Nokia 60-series phones with WiFi and SIP stacks built in, followed by a very interesting discussion..
The day ended after Tim's parents and Joanna joined with another dinner.
Thursday, November 24, 2005
Belgium Belgacom: 7,23/MB
Belgium Base: 10,44 Euro/MB
and the winner is:
Canada - Rogers Wireless: 16.98/MB
and it is practically impossible to find this out beforehand.
Hey, this would be a case for consumer protection agencies
Sony starts IVE, Yak Communications launches yakForFree, Fairytel launches in Austria. For several months in beta now: VoipBuster. BroadVoice was elected No. 1 VoIP provider by Wired Magazine. Finally, iPhone2 wants to move to the NASDAQ.
Regarding Sony's IVE: Sony's IVE? Pardon me while I yawn
Reed Hastings, chief executive of Netflix: Web 2.0 is broadband. Web 3.0 is 10 gigabits a second.
and James: Calling Dr. Orwell citing:
"Telephone networks are made up of regional, domestic networks united together in agreement of the ITU framework. A similar situation may start with the internet." (?)
implying that after taking the Internet apart you need the ITU to put it together again - nice try ;-)
A message from down under:
The CableLabs issues RFI for VoIP peering caused also some stir-up at the ENUM Summit.
The Sony DRM mess is still not over OPINION://Land of the setting Sony by Martin Geddes.
Martin also had again the funniest post of the week:
Web 1.0: “Please enter your username and password.”
Web 3.0: “Please select your federated identity provider. Please wait whilst you are being redirected. Please enter your username and password. Please wait whilst you are being redirected.”
Web 4.0: “Hello, Martin.”
Web 5.0: “Hello, Boris.” Hey, I’m not Boris!
Web 6.0: “Welcome to IMS:HyprTxt-Global. You have 287 web page credits remaining. Select your destination web page from the drop-down menu of approved secure partners.”
The funniest? BTW, talking about IMS:
The idiots guide to IP-based Converged Services - how to build and launch them?
On Monday I gave again an ENUM Tutorial (the slides can be retrieved from here) and Jim Reid presented a quite useful DNS Tutorial.
The conference itself was two days. Approx. 50 participants showed up, only half the size of the May ENUM Summit in Miami. It seems that the awareness in Europe on ENUM and VoIP peering has not yet reached the same level like in the US.
Anyway, the audience and also the presentations where a good mix of manufacturers, operators and service providers, registries and regulators. The common consensus was that the conference was very useful and provided also a good possibility for networking.
I chaired the first day and also gave the first presentation. The keynote from Richard Shockey was reviewing the current status of RFC3761 and the re-chartering of the ENUM WG in IETF and a general view on the future of ENUM.
The rest of the day dealt with status reports and lessons learnt on ENUM in Spain, UK, Germany, Poland and Switzerland, so the audience got a excellent overview.
The second day, chaired by Rich Shockey, concentrated on ENUM, VoIP interconnection and implementation issues with presentations from Sipgate, XConnect, Nominum, Verizon, Netnumber and Evlolving Systems. It was closed by two presentations on security and privacy by Telio and Toplink.
I consider this as a very useful event and I am already looking forward for the next ENUM Summit in Spring in the US (date and site to be announced).
Thursday, November 17, 2005
All sides claimed victory after more than 100 nations agreed to leave control of the core network resources under the direction of the US.
In the end, the power of ICANN (and of the DoC) was left untouched.
The European Union worked behind the scenes in drafting key and subtle language in the Internet governance policy statement that allowed the delegates to reach an accord:
"We recognize that all governments should have an equal role and responsibility for international Internet governance and for ensuring the stability, security and continuity of the Internet."
This language put into concrete expression the interests of other governments in the critical (core) infrastructure of the Internet as a more important outcome for the US critics then the Global Internet Governance Forum that was also created by the document.
The new forum is free to take up any Internet issue, whether cyber crime, spam, or freedom of expression, but the forum will have no power beyond the ability to bring together the "stakeholders" in the Internet, from consumers to governments or businesses:
77. The IGF [Internet Governance Forum] would have no oversight function and would not replace existing arrangements, mechanisms, institutions or organisations, but would involve them and take advantage of their expertise. It would be constituted as a neutral, non-duplicative and non-binding process. It would have no involvement in day-to-day or technical operations of the Internet.
Also the place of the meeting was IMHO not selected very carefully, because Tunesia is one of the most autocratic regimes in the Arabic world.
I personally also have some problems with the US governance over the Internet, but to cite Churchill freely: "I do not know of any better solution."
See also Susan Crawford's oversight.
And the ITU News:
The final documents submitted to the second phase of WSIS being held 16-18 November 2005 in Tunis have been posted. They are:
In The Tunis Agenda for the Information Society, paragraphs 3-28 related to Financial Mechanisms for Meeting the Challenges of ICTs for Development, paragraphs 29-82 relate to Internet Governance, and paragraphs 83-122 relate to Implementation and Follow-up.
Telstra's new US CEO Solomon Trujillo unveiled a 5-year investment plan valued at $7.3 billion that places heavy emphasis on broadband and services while trying to slash costs.
He wants to transform Telstra from a lumbering fixed-line monopoly to a market leader for for the latest wireless services (from his US West and Orange background). He is also taking up the fight against the regulator "hurting" the companies prospects. Good luck ;-)
Solomons basic statement: "The cost structure of this business is too high. Period. End of story"
Tuesday, November 15, 2005
Interesting also that Spanish Telecom Telefonica partners with Skype to bring SkypeIn numbers to Germany. This was announced in the German media early today.
The data one must provide will be verified, so the process may take 1 or 2 working days, a warning on the Skype subscription page says, but according to Tony a friend got the number within 10 minutes!
I just wonder if the Austrian regulator will start to reconsider the weird requirement of a fixed network termination for geographic numbers in Austria. Currently the only way to get an Austrian geographic number for Skype would be to nail the PC running Skype to the wall.
It is not within the duties and responsibilities of a regulator to hinder national providers minding their business and compete with extraterritorial providers.
I would like to mention here only a side remark in Ray Ozzie's mail:
Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration. Moving forward, within all parts of the organization, each of us should ask “What’s different?”, and explore and embrace techniques to reduce complexity.I am seriously considering to post this statement on the ETSI TISPAN mailing list for contemplation about their IMS spezifications ;-)
It was the ususal group of suspects: Michael Haberler, Kai Miao, Adrian Georgescu, Erik Lagerway, Henry Sinnreich, Willi Wimmreuter and myself (not visible).
Erik has a nice plate on his car ;-)
The agenda can be retrieved from the above link, currently no slides are available there yet, except the excellent presentation from John Buford: P2P Overlay Design Overview.
My take from the meeting was the following:
On the plus side: The presentations and the discussions gave a good introduction and overview and also on the open issues.
On the minus side: The discussions still are going and circles and seem to lead nowhere. The IETF gurus clearly deposited that also at the next meeting no final BoF can be expected.
I consider this as a serious problem, because a P2P solution is obviously needed and if not done at the IETF, it will be done (or is already done) elsewhere. So urgent action is required and no further academic discussions.
My proposal out of the loop is the following:
We need one solution for small networks and one for large networks
The small networks (e.g. up to 10000 users) have the following primary use cases:
- small PBX-like implementations for small and medium enterprises (SME) (same market as Linkys Onephone)
- adhoc networks e.g. for meetings, conferences, buddy groups and also for disaster theatres, e.g. to set up an onsite adhoc communication for rescue teams of different organisations.
So why not start with these scenarios and leave the large networks and use cases for later.
Security should be the choice of the network:
- a locally known key (e.g. such as a WEP key advertised on-site similar to the SecureIETF), or even better, the same key)
- a centralized administered solution for PBX-like applications
In these cases most of the proposed (presented, mentioned) DHT schemes at the BoF would work.
Additional minimum requirements for such networks could be:
- the P2P network must be able to interoperate with client-server SIP networks
- and also provide UA that allow to connect normal SIP Softclients and Terminal Adapters.
A last remark: I would prefer the solution with a separate protocol for P2P.
If the scope for a P2PSIP WG is chartered and restricted along these lines, it should be possible to launch a IETF WG at the next IETF.
Thursday, November 10, 2005
The BoF was very well attended (approx 200), showing the interest of the community.
To start with the only clear outcome first, the name of to be established WG was discussed, and since the scope will be beyond VoIP and also real-time communications and on the other hand the scope will be restricted to SIP Peering, a proposal from Jonathan Rosenberg was accepted to call it:
Willi Wimmreuter noted on the side that he likes this acronym because it also includes Skype Peering ;-)
The discussion on the charter took the most time and was very confusing and going somewhat around in circles. The easy part was what is out-of-scope (see slides), the complicated part was what is within the scope.
I hope the scribe will be able to get this confusing discussion correctly into the minutes and also that the chairs get the correct information into the updated charter.
I have a problem with excluding the policy issues out of the scope completely. I agree that SPEER should not define protocols, but at least what is required for determining the policy, similar to the decision on requirements for user identity (callerId) and accounting.
It was also decided to concentrate first on L5 peering and leave L2/3 issues for later re-chartering.
I will comment further on this after the minutes are available
The debates on internet governance have highlighted conflicting statements and visions on how the internet's domain name system (DNS) root server system should be managed.
The Internet Corporation for Assigned Names and Numbers (ICANN) is an internationally organized, non-profit corporation that has responsibility for .... root server system management functions.
From the Root Server FAQ by Daniel Karrenberg
ICANN does not control root name server operations?
A: No. Neither the IANA nor ICANN have any executive authority over the operation of root name servers. The establishment of such authority has been on ICANN's agenda from the start. It is mentioned in various guises in the MoU between ICANN and the US DoC. However none of this has ever been implemented. I do not believe ICANN, or anyone, should have control over the operation of all root name servers. So this goal should be removed from ICANN's agenda.
Computer Business Review Online is reporting that the US government is said to be planning to open the IANA contract to manage the internet's addressing systems, currently held by ICANN, for competitive bidding. But an US official yesterday denied a report that such a move has been discussed publicly.
I wonder whats going on here.
Wednesday, November 09, 2005
Note: all presentations gvien at the meeting can be retrieved from here.
The charter proposed in the agenda was approved.
ENUM Implementation Issues and Experiences draft-ietf-enum-experiences-03.txt and ENUM Requirements for EDNS0 Support draft-conroy-enum-edns0-01.txt
Regarding EDNS0: after some prior discussions on the list, consulting with dns-experts and also a discussion at DNSOPS it was decided to modify the draft to a very short and precise document, let it check by dnsops and submit it as BCP. The experiences draft will undergo one update to reflect this and will go immediately to WGLC afterwards. Further experiences to come up will be dealt with in another document.
IANA Registration for Enumservice vCard draft-mayrhofer-enum-vcard-00.txt and IANA Registration for IAX Enumservice draft-guy-enumiax-00.txt where both presented and accepted as WG items. The IAX ENUMservice will be treated similar to ENUMservice H323. The URI definition is contained in the IAX protocol specification to be contained in an Informational RFC. The I-D will show up after the shadow period.
An ENUM Library API draft-sajitha-enum-api-00.txt was considered out-of-scope and not dealt with.
Infrastructure ENUM issues, ongoing work:
Infrastructure ENUM Requirements draft-lind-infrastructure-enum-reqs-01.txt
Combined User and Carrier ENUM in the e164.arpa tree draft-haberler-carrier-enum-01.txt
IANA Registration for an Enumservice Containing PSTN Signaling Information draft-ietf-enum-pstn-01.txt
where presented. It was decided to finalize the requiremnets with high priority. The other two I-Ds will move on in the meantime. Regarding the draft-haberler-carrier-enum-01 it was proposed to move the definitions and terminology over to the the requirements I-D and concentrate on technical issues. We had some side discussions here at IETF how to put the information where to branch off the infrastructure part within the e164.arpa tree in the DNS and by which means (e.g. with a new RR record). The results will be incorporated in the next issue of the I-D.
The basic idea is to have within the country code zone (e.g. in 3.4.e164.arpa or in 1.e164.arpa) in predefined context containing a RR with the following information:
- number of digits where the branch occurs
- the name of top label of the branch tree
- the apex of the tree where the information is contained (this allows eventually also to point to other trees
infra IN BLR "4" "carrier" "e164.arpa"
The NAPTRs for number +1-234-567-8900 will then be found in domain
The data contained in the BLR is a national decision by the NRA.
BTW, the definition of User ENUM in this terms would be
user IN BLR "0" "" "e164.arpa"
An ENUM client capable of querying Infrastucture ENUM needs only to know the Country Codes (as already described in the draft) and then must retrieve at bootstrap time (or when he first queries a number from a specific country code) this information once (for the Time-To-Live of the BLR, which can be set very long).
Validation issues, ongoing work
ENUM Validation Architecture draft-ietf-enum-validation-arch-00.txt
ENUM Validation Token Format Definition draft-ietf-enum-validation-token-00.txt
ENUM Validation Information Mapping for the Extensible Provisioning Protocol draft-ietf-enum-validation-epp-01.txt
The three drafts where presented. There are still some minor isssues, but the work seems to be finished soon.
... My fear is that, as written, this bill would do great damage to the Internet as we know it. Enshrining a rule that broadly permits network operators to discriminate in favor of certain kinds of services and to potentially interfere with others would place broadband operators in control of online activity. Allowing broadband providers to segment their IP offerings and reserve huge amounts of bandwidth for their own services will not give consumers the broadband Internet our country and economy need.
I am confident that we can build a broadband system that allows users to decide what websites they want to see and what applications they want to use – and that also guarantees high quality service and network security. That network model has and can continue to provide economic benefits to innovators and consumers -- and to the broadband operators who will reap the rewards for providing access to such a valued network.
It is very ironically, as James Enck points out, Vint himself won't be at the hearing because he will be receiving a Presidential award for creating TCP-IP.
The young muslims causing these riots are basically stating, when interviewed by TV stations: "We just want to be treated at human beings".
Well, ok, no problem with this.
Just one remark: Maybe it would be helpful to behave as a human being and also to treat fellow citizens as human beings.
The young male muslims could also as a starter treat their own sisters as human beings.
See: Dans l'enfer des tournantes (by Samira Bellil)
Monday, November 07, 2005
For the upcoming Global Symposium for Regulators (GSR) to be held in Hammamet, Tunisia, 14-15 November 2005, just before the second phase of the World Summit on the Information Society (WSIS), the ITU has released a paper by Tracy Cohen, Olli Mattila and Russel Southwood, entitled VoIP and Regulation, which will be presented at the GSR.
I have not read the paper yet (I only got a peek preview by Olli 2 weeks ago at the conference in Brussels), but on the title page is stated:
Comments are welcome and should be sent by 5th December 2005 to GSR05@itu.int
Maybe I will do.
But I think they will miss this one too:
... You remember the first days of the Internet, where a few people knew about it and interconnected with one another? VoIP peering is becoming the same sort of phenomenon. I would imagine it is analogous to the way e-mail and websites were about a decade ago.
As more and more service providers, government agencies and corporations join peering networks the cost of long-distance will plummet even faster than it is dropping now. VoIP peering really is the ultimate application of Metcalfe's Law. If you recall, this law says the power of the network becomes exponentially greater as more users are connected to it. Think of the power of a single fax machine and then think of the power of a million interconnected fax machines and you'll see what Metcalfe was talking about.
... but more interesting was the incumbent telcos I spoke with. These companies know that the future is peering but in general are trying to figure out how to make money from this phenomenon. They want to interconnect but aren't sure how to generate revenus from interconnecting.
That is where VoIP 2.0 comes in. The companies who make a living in communications tomorrow are going to have to be 100% committed to coming up with new applications that consumers and businesses will pay for.
But the mentality of incumbent providers is woefully inadequate to come up with new revenue models. For example, everyone in telecom knows the mobile market has turned ring tones into a multi-billion dollar market. This has been a massively profitable market for many years and yet the wireline incumbents don't seem to be in this space.
For a decade I have spoken about how service providers need to focus on selling services and not minutes and a decade later they aren't but new players such as Skype and Vonage are.
It is a culture issue that incumbents need to change. If the incumbents in every country want to be around in ten years they need to drastically change the way they do business. They cannot live life as usual. They must understand that VoIP, p2p networks and peering are going to erode their core business faster than they ever thought possible.
If the RBOCs don't act quickly they are toast. The longer they wait the less wiggle-room they will have. I just hope the executives who head up the LECs are reading this and every time they overhear "Wake up Jeff," they start thinking about how they can roll out new revenue-generating services to consumers in the upcoming months and years.
Rich, I do not think the Telcos can compete with providing services.
The new service (aka applications) providers are already here. It is Skype, Google, Yahoo! et al
These "providers" are already working on a global scale. Every telco is only existing on a local scale. Even giants like BT, Verizon or SBC are only locals.
What's left is access, and this is becoming a commodity and also here is competition. This is the reason why Whitacre is weeping about his "pipes".
And also here they are sqeezed from below by BYO FTTH suppliers.
Sunday, November 06, 2005
... This isn’t about freeloaders; it’s about tollbooths. As local access monopolies, the baby Bells have been able to maintain tollbooths for voice traffic for years. Voice over IP (VoIP) got much of its original impetus by providing a bypass around those tollbooths. Even though they’ve done better than their long distance rivals (whom they are now buying), it’s getting harder and harder for the baby Bells to increase or even maintain profits. They could have been leaders in Internet access but they weren’t. Now they are providing DSL – great. Now they would like to erect new tollbooths on what used to be called the Information Super Highway – that sucks.
... Whitacre’s arrogance led him to take on too many opponents at once. He might have gotten away with considerable pressure on the VoIP providers. But he chose to take on Google, Microsoft, and Yahoo at the same time. Although these companies are just learning how to lobby, they have the money to do it successfully. Jeff Pulver – who has been doing a great job of FCC watch – chronicles some recent successes in Congress here and does a very thoughtful examination of the larger issues here.
Even IMS-Insider is wondering:
The most striking thing is how limited their company's focus is on 'value added services' (IMS-enabled or otherwise).
Bold emphasis by me.
Question One: What's your position on 'FMC'?
Major Mobile Operator: “With no fixed network, we see FMC as a clear threat to our business since converged operators can offer things we can’t at present. We are currently seeing this most on the Business side and are looking for creative solutions to negate this threat.
Essentially, we see lower prices plus higher bandwidth plus, over time, increased mobile functionality (presence, IP-Pbx etc.) as the tools to ensure that fixed connectivity becomes less relevant. For example, HSDPA offers 8MBS bandwidth which means that we can offer basic broadband connectivity for laptops and PC’s and so attack this market.”
Full Service Fixed/Mobile Operator: “We are only just starting to scratch the surface of this. It clearly gives us a big advantage over fixed-only or wireless-only players. Currently, most of our development in this area is simple pricing bundles – for example, discounts for mobile taken with fixed internet access.
However, going forward we believe that the real interest for consumers is in FMC services. Clearly, communications will be the starting point – like BT’s Fusion offering ( http://www.btfusion.bt.com/ ), but over time we see other ways in which we bring the fixed and mobile world’s closer together.
Take music, for example, why not have the mobile handset being the tool whereby you download or stream songs which are then played on your handset OR by your home hi-fi equipment? You could download over-the-air (HSDPA/3G) or via Wi-Fi – the bearer wouldn’t matter. What makes this appealing to consumers is (1) the personalisation associated with mobile (we can log preferences and push relevant music to them), (2) the convenience of anytime, anywhere music, (3) the bandwidth and quality associated with the traditional fixed network. The same could easily be true for TV.”
Question 2: What's your current thinking around converged IP-based Services?
Major Mobile Operator: “At the moment, to be brutally honest, this is not the priority for us. We are on 3-6 month time horizons in marketing. IP services that leverage presence and SIP are not top-of-mind because we don’t see them as something that will be widely deployed for 18+ months.”
Full Service Fixed/Mobile Operator: “Internally I have painted a very bold picture about the future but sometimes I feel that I am a lone voice in thinking 24 months out. (I like this statement because I can feel symphaty with this guy, being in a similar position ;-)
We have dabbled with IP-services but really the focus of the business at the moment is cost-saving.
Management believe, perhaps justifiably, that there is more money to be made in getting our handset supply-chain sorted than in worrying about “peripheral” services. What is likely to happen is that in 12 months time we will all be told that the time has come for us to make a bold statement and we will need to rush out some exciting services in 6 months. (Good luck) Given that our development cycle is 12+ months, this should be interesting!
I liked the services prioritisation [in IMS Insider, October edition - www.ims-insider.com ] because it gives us a simple framework to start thinking about IP/IMS-enabled services NOW.”
So they maybe start thinking NOW?
Question 3: And, how is IMS seen generally in your organisation?
Major Mobile Operator: “We are making all the right noises about IMS. However, it is being driven exclusively out of Technology and R&D – there is little interest in Marketing. Why? Because we don’t see the need. We believe, rightly or wrongly, that most of the things IMS offers can be done without it and any new capabilities are hardly justified by the required investment. The numbers don’t seem to add up.
Now this is very interesting. Finally we have somthing in common. But why are these operators then supporting the IMS standardization work so vehemently?
So we have a situation where the Technology and Marketing roadmaps are largely produced independently of each other. Crazy, but similar to most operators, I think.”
Full Service Fixed/Mobile Operator: “There is wide split between the technical functions and marketing on this. Technical are working hard to deploy IMS and ensure that we have the functionality in the network for FMC and the next generation of IP-Services. We are looking to deploy SIP-enabled devices across the business from next year.
However, if you ask anyone in Marketing about IMS they will either look blankly at you or give you a hundred reasons why it is not relevant! I think this is a wider symptom of the problems we have of managing the interface between Technical and Marketing.”
Again, this point of view by the marketing people is not new to me ;-)
It would also be interesting to add the view of a senior marketing manager of a fixed operator on FMC.
ICANN announced today that I have been nominated to serve on its board, along with Njeri Rionge (who has been reappointed).
I am deeply honored to have the opportunity to work with the ICANN community, and I look forward to digging in and helping out.
I'm going to need your help over the next three years. I'll do my best to keep the lines of communication open, and I'll be urging ICANN to do better at explaining its limited mission to the world and opening its processes to view.
On Thursday the Internet Voice Coalition, a working group of the VON Coalition launched a campaign to help educate consumers about VoIP. News about these efforts was picked up by some of the trade press including: America's Network, New Telephony, Computer Business Review, PC Pro, CNET and well as BusinessWeek and the International Herald Tribune and the UPI.
Jon Arnold is posting and commenting on this.
The founders of this initiative are Sonus, Google, EarthLink, Skype, Pulver.com, the VON Coalition and USA Datanet.
Jon is wondering about the mix - who is partizipating and who is not (e.g. Vonage)
Friday, November 04, 2005
In todays Washington Post article SBC Head Ignites Access Debate I got the reply that I misinterpreted Mr. Whitacre and a clarification:
SBC spokesman Michael Balmoris said Whitacre was not talking about charging companies for letting customers access their Web sites. Rather, he said, Whitacre was referring to access Internet companies may want to the "managed and secure" portions of the fiber-optic network SBC is building largely to deliver video to customer homes.
"SBC has not and will not block or limit access to lawful content or applications on the Internet," he said. "Mr. Whitacre's comments are being misinterpreted. They were not made in the context of the Internet, but rather SBC's $4 billion investment in its new fiber network to provide Internet-based video services," Balmoris said.
The spokesman said SBC might strike commercial agreements with companies such as Google, Yahoo and Vonage to give them access to that part of its network.
Whatever Whitacre meant, critics said his remarks strengthened their hand.
Kevin Werbach now gets even more suspicious:
Ahh, so broadband over fiber isn't going to be "the Internet." It's going to be a private, tolled garden controlled by the phone companies. The network operators are building the network, so they believe they can control what applications and content appear on the network, at what price. Tell me again how this is different from the narrowband Internet of yesteryear, and the DSL/cable modem broadband Internet of today?
The clarification only makes me more worried about the broadband future.
Thursday, November 03, 2005
VOIPEER is closely related to ENUM, as already has been pointed out at IETF#63 in Paris.
The separation in scope is shown in the figure below. A description of this figure can be found in draft-meyer-voipeer-terminology-01.txt
E.164 number <--- Peer Discovery
| <--- ENUM lookup of NAPTR in DNS
| ENUM Working Group Scope
| VOIPEER Working Group Scope
SIP URI <--- Call Routing Data (CRD)
| <--- Service Location (Lookup of SRV in DNS)
| Hostname <--- VoIP addressing and session establishment
| <---- Lookup of A and AAAA in DNS
| <---- Routing protocols, ARP etc
According to the agenda, the main part of the BoF is dedicated to the discussion of the charter and the quite extensive goals and milestones (see below). As we have already seen in Paris, the only common consensus is that a VOIPEER WG is required and necessary, in the details the opinions differ substantually, or as Rich Shockey pointed out in a discussion at the Fall VON: "There have been about 200 participants at in the room in Paris and 250 opinions".
My take is that we should at least agree on the charter, so a workgroup can be established and work can start immediately, because it is urgently needed. I only have some concerns about number of work items and the lenght of the timeframe. March 2007 for the minimum requirements is too late.
The remainder of the BoF is dedicated to the discussion of the terminology draft mentioned above.
The proposed charter and the proposed goals and milestones:
Description of Working Group:
The term "VoIP Peering" has historically been used to describe many different aspects of provider interconnect and the delivery of SIP call termination over that interconnection. Further, since VoIP peering focuses on how to identify and route calls at the application level ("Layer 5"), it does not (necessarily) involve the exchange of packet routing data. In particular, "layer 5 network" is used here to refer to the interconnection between SIP servers (as opposed to interconnection at the IP layer).
The voippeer working group focuses on call-routing architectures for delay-sensitive ("real-time") interpersonal communications using the SIP protocol, such as VoIP. More specifically, voipeer focuses on call routing architectures for layer 5 networks and their instantiations (i.e., use cases). This includes the specification of the various types of packet flows in such networks, including both VoIP trunking and peer-to-peer flows. In addition, voipeer considers requirements for the feedback of operational conditions (e.g., congestion control) that enable the application of dynamic policy.
In addition, voipeer develops best current practices regarding exchange of calls (more generally, real-time sessions) among VoIP providers, and in particular, how such calls are routed, both between Internet connected sites and between the Internet and the Public Switched Telephone Network (PSTN). The voipeer work-plan is also intimately related to the work-plan being pursued by ENUM working group. In particular, while the ENUM Working Group is primarily concerned with the structure (and lookup) of data for the translation of E.164 numbers into SIP URIs (RFC3761), voipeer is concerned with the use of that data for use in signaling and routing real-time sessions.
Note that the properties of networks underlying the "interconnecting links", such as IP access and transit networks (including admission control), are out of scope for voipeer. Further issues that are out of scope for voipeer include:
o Interoperability, and NITS/profiling of existing protocols such as SIP, RTP, and SRTP,
o SPIT prevention,
o Routing of sessions which are not signaled using SIP. In particular, voipeer is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs or E.164 (public telephone number) addresses. By extension, national and private formats numbering formats are out of scope for voipeer.
--- Goals and Milestones:
Mar 06 Submit voipeer terminology I-D
Mar 06 Submit I-D defining the voipeer routing architecture to the IESG (Informational)
Dec 06 Submit I-D defining the call flows associated with the voipeer routing architecture
Jan 07 Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP)
Jan 07 Submit I-D on the use of DNS SRV and NAPTR
Jan 07 Submit I-D on the minimum set of requirements for VoIP interconnection
Mar 07 Submit I-D specifying the use of addressing forms and provides strong identities (BCP)
Jun 07 Submit I-D(s) on use cases (BCP)
Jun 06 Submit voipeer terminology document to IESG (Informational)
Mar 07 Submit document to the IESG on the minimum set of requirements for VoIP interconnection
Mar 07 Submit document defining the call flows associated with the voipeer routing architecture to the IESG (Proposed Standard)
Jul 06 Submit document defining the voipeer routing architecture to the IESG (Informational)
Mar 07 Submit document to IESG specifying the use of addressing forms and the provision of strong identities (BCP)
Jun 07 Submit document to IESG on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP)
Jun 07 Submit document(s) to IESG on use cases (BCP) (ongoing)
Wednesday, November 02, 2005
The ENUM WG is scheduled on Tuesday, November 8th, in the afternoon sessions III and IV from 1740 to 1950.
The first and most important item on the agenda is the recharter discussion to include "Carrier or Infrastructure" ENUM. The current proposal is contained in the agenda.
The discussion will concentrate mainly on the issues related to Carrier ENUM:
... There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services.
Working Group Revised Goals and Scope:
2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing.
4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data.
And the new:
Goals and Milestones:
March 06 Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard
April 06 Requirements for Carrier Interconnection using ENUM as an Informational
June 06 Carrier Interconnection using ENUM as a Proposed Standard
July 06 ENUM Privacy and Security Considerations as an Informational
August 06 Advancement of RFC 3761 to Draft Standard
Next on the agenda are the ready to go items:
ENUM Implementation Issues and Experiences
This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol.
ENUM Requirement for EDNS0 Support
This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support ENUM query resolution (as defined in RFC3761). This requirement is needed as DNS responses to ENUM-related questions return larger sets of Resource Records than typical DNS messages. Without EDNS0 support in all the involved entities, a fallback to TCP transport for ENUM queries and responses would typically occur. That has a severe impact on DNS Server load, and on latency of ENUM queries. This document updates RFC3761 only in adding this requirement.
New Work Items:
IANA Registration for Enumservice vCard
This memo registers the Enumservice "vCard" using the URI schemes "http" and "https" according to the IANA Enumservice registration process described in RFC3671. This Enumservice is to be used to refer from an ENUM domain name to the vCard of the entity using the corresponding E.164 number. Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before he picks up the call.
IANA Registration for IAX Enumservice
This document registers the IAX2 Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761.
An ENUM Library API
This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number.
Carrier/Infrastrucure ENUM Requirements
This document provides requirements for "infrastructure" or "carrier" ENUM, defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoI
Combined User and Carrier ENUM in the e164.arpa tree
ENUM as defined now in RFC3761  is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes a minimally invasive scheme to provide both end-user and carrier data in ENUM.
IANA Registration for an Enumservice Containing PSTN Signaling Information
This document registers the Enumservice “pstn” and subtype “tel” using the URI scheme ‘tel:’,
as well as the subtype “sip” using the URI scheme ‘sip’ as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists.
ENUM Validation Architecture
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure.
ENUM Validation Token Format Definition
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion.
ENUM Validation Information Mapping for the Extensible Provisioning Protocol
This document describes an EPP extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names.
IANA Registration for Enumservice Voice
is in last call
IANA Registration for Enumservice VOID
is in IESG Evaluation
IANA Registration for Enumservices email, fax, mms, ems and sms
still slumbering quietly in the Editor queue, awaiting a normative reference to be resolved.
Also for completeness, two related I-D are currently in treated in IPTEL WG, not meeting at IETF#64:
The ENUM Dip Indicator parameter for the "tel" URI
draft-ietf-iptel-tel-enumdi-01.txt (a version 02 will show up after the shadow period)
New Parameters for the "tel" URI to Support Number Portability
Since these two I-D and also
Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs) draft-ietf-iptel-trunk-group-04.txt
require additional parameters to the tel URI defined in RFC3966. it was proposed to create an IANA registry for these parameters. This registry will be defined in:
The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry draft-jennings-iptel-tel-reg-00.txt
also available after the shadow period.
On Monday the ITU TSB approved the request for ENUM delegation of CC +350 (Gibraltar) by Sapphire Networks (coming soon ;-). Here also Afilias seems to be involved.
Yesterday also a seemingly serious request was received from Japan for CC +81 submitted from the Ministry of Internal Affairs and Communications (MIC), providing JPNIC as tech contact.
The request has not been approved yet by ITU TSB, but this seems only be a matter of days.
Welcome all to the world of ENUM, especially to Hiro, Yoshiro and Ohashi.
Tuesday, November 01, 2005
How exact this calculation is one can see from the evaluation of James Enck's blog, which is worth nothing, as James points out. The reason is of course that James has no Technorati ranking.
What is the (market) price of a blog? Is there a blog exchange where you can buy and sell blogs? As long as not some idiot out there is willing to pay at least $25.000 for my blog, it is prizeless ;-)
Offers accepted ;-)
Or should I try it at EBay?