VoIP and ENUM

Today I gave a presentation (in German) at the ÖVE in Vienna about "Zukunft der Notrufe". The presentation is available here.

Now even the pope has a blog.

Well, he (they?) is (are?) also in Tele?communications ;-)

After the busy ENUM Europe Summit in Frankfurt I flew back to Vienna on Wednesday evening with Michael Haberler and Robert Schischka, having an eye on Richard Shockey that he did not get lost on Franfurt airport. Rich was spending the rest of the week in Vienna.

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.

I just got the monthly data roaming bill from my mobile operator:

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

After a busy weekend and also after the busy conference on ENUM in Frankfurt, I checked my FeedDemon what I missed on the blogs last week- it is a nice collection, here are the highlights:

The last three days I was in Frankfurt at the IQPC ENUM Summit Europe 2005. Since my Internet connectivity was again somehow limited (no broadband in the Arabella Sheraton, except a T-Mobile WiFi in the lobby I did not even try, because T-Mobile hotspots do not work for me, so I was reduced to Vodafone UMTS), I stopped blogging. Another reason was that the three days where quite busy.

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

This was a political event. So the outcome is like with any political election: there are only winners.

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.

Regarding freedom of expression: I considerer it very curious that some of the countries (no need to name them) opposing the US governance itself have problems with freedom of speech.

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:

From the International Herald Tribune (paper version) yesterday: Telstra, the dominant telco in Australia, plans to cut 10.000 jobs over the next 5 years as part of a restructuring plan aimed at reviving earnings while the goverment prepares to sell its majority stake.

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"

How true.

The slides and meeting notes from the P2PSIP AdHoc BoF held at November 11th, 2005 near the IETF #64 in Vancouver are available here.

... before you rush in to get a Munich number, hold on, it is only for residents. Guest blogger Tony Steinegger from Austria is explaining detailed how it works on Skype Journal: SkypeIn in Germany with a Twist ...

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.

Much has been written and blogged about Microsoft's Web 2.0 Manifesto in the "Live" e-mails sent by Bill Gates and Microsoft CTO Ray Ozzie (provided by Dave Winer).

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

After the P2PSIP AdHoc BoF some of closed the IETF#64 with a dinner at Gotham Steakhouse by the much appreciated invitation from Erik. Thank you, it was excellent.

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

Erik Lagerway from Eyeball Networks was so friendly to sponsor the meeting venue for the P2PSIP AdHoc BoF at the IETF#64 on Friday. Erik is also well known in the blogosphere as SIPthat.com

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.
- etc.

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:
- none
- 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.

This morning the VOIPEER BoF took place at IETF#64 in Vancouver. The agenda and the proposed charter can be found here, the slides presented by Dave here.

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:

SPEER

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

On the ITU-T Strategy and Policy blog there are Conflicting Statements and Visions on DNS Root Server Management: And a bit later: US to open internet root to bids?
I wonder whats going on here.

Important things first: At the meeting the issue was raised that the mixed usage of the terms "Carrier ENUM" and "Infrastructure ENUM" is confusing and the meeting should decide on the term used in future documents. This was done by hum and there was a slight preference for "Infrastructure ENUM". So Jon Peterson put his A-D hat on and decided:

Infrastucture ENUM

In detail:
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

and

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
  

If this is done with a new DNS RR (called Branch Location Record), the information could e.g. look like:

$ORIGIN 1.e164.arpa
infra IN BLR "4" "carrier" "e164.arpa"

The NAPTRs for number +1-234-567-8900 will then be found in domain
0.0.9.8.7.6.5.carrier.4.3.2.1.e164.arpa

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.

Vint Cerf (Google) sent in a letter related to the hearing the Congress is holding today, Wednesday, November 8th, on "network neutrality" and a big new telecommunications bill affecting the Internet, stating clearly:

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

There are riots in Paris against "the authorities" since nearly two weeks, spreading over France and also spilling over to Belgium and Germany.

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)

From todays ITU-T News Feed:

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.

Rich Tehrani is trying to make another wake-up call to the telcos, this time about VoIP Peering. This fits nicely a previous post of mine on FMC where I missed a statement from the fixed-line operators.

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.

Game over.

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.

Tom Evslin has an excellent analysis on robber-baron Whitacre: Don’t Buy DSL From This Man (If You Can Help It)

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

I start to like the IMS Insider Blog because it provides interesting in-sights into the thinking of mobile operators (and also fixed-operators dealing now with IMS). The last entry: IMS Services - what Marketing functions really think provides the view of senior marketing managers of two major operators about fixed-mobile convergence (FMC), IP-based services and IMS. One was a pure-play mobile operator, the other a full-service fixed/mobile operator.

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.

I wonder.

Her message to the readers:

Dear friends:

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.

I wish Susan good luck and congratulations to ICANN.

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)

Me too.

Russel Shaw and Jeff Pulver point to this job description on the Skype website for "Product Manager- Skype for Business."

No comment.

Obviously SBC got nervous about my post ;-) and others commenting on the statements of Mr. Whitacre in last weeks BusinessWeek Online interview: "At SBC, its all about Scale and Scope"

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.

The VOIPEER (VoIP Peering and Interconnect) BoF is taking place on Thursday, November 10th, in morning session I, 0900-1130.

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
|
Ip address
|
| <---- Routing protocols, ARP etc
|
Mac-address

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)

Talking about busy weeks, the next week in Vancouver at the IETF#64 will be also very busy.

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
draft-ietf-enum-experiences-03.txt

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
draft-conroy-enum-edns0-01.txt

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
draft-mayrhofer-enum-vcard-00.txt

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
draft-guy-enumiax-00.txt

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
draft-sajitha-enum-api-00.txt

This draft defines a library API for ENUM. The API takes telephone number as input and returns the URI associated with that telephone number.

Ongoing items:

Carrier/Infrastrucure ENUM Requirements
draft-lind-infrastructure-enum-reqs-01.txt

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
draft-haberler-carrier-enum-01.txt

ENUM as defined now in RFC3761 [1] 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
draft-ietf-enum-pstn-01.txt

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
draft-ietf-enum-validation-arch-00.txt

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
draft-ietf-enum-validation-token-00.txt

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
draft-ietf-enum-validation-epp-01.txt

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.

For completeness:

IANA Registration for Enumservice Voice
draft-ietf-enum-voice-01.txt

is in last call

IANA Registration for Enumservice VOID
draft-ietf-enum-void-02.txt

is in IESG Evaluation

IANA Registration for Enumservices email, fax, mms, ems and sms
draft-ietf-enum-msg-05.txt

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)

and

New Parameters for the "tel" URI to Support Number Portability
draft-ietf-iptel-tel-np-07.txt

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.

The ITU TSB approved today the request for ENUM delegation of CC +39 (Italy) by Consorzio Voipex and the Italian Ministry of Communications.

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.

I have it now "in writing", my blog is worth $26,533.38. This is calculated by a nice gadget, somehow derived from the Technorati ranking, for more information see here. So Martin Geddes blog is worth $71k, Jeff's blog is worth $94,278.18 and of course Om Malik's blog is worth $1.15m

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?