Speaking of Standards

One of the ironies of the language we use in this space is that we all have been talking about “SIP trunks” for a few years now, but nowhere has there actually been a formal definition of what exactly a SIP trunk really is!

Leaping into the fray now is Jonathan Rosenberg, author of a zillion Internet-Drafts and multiple RFCs, with his new I-D titled, appropriately “What is a Session Initiation Protocol (SIP) Trunk Anyway?” Here is the abstract:

The term “Session Initiation Protocol (SIP) Trunk” has become almost commonplace amongst vendors and SIP providers. Even though the notion of a ‘trunk’ has a well defined meaning in circuit switched systems, it has never been defined for SIP. This document provides a formal definition for a SIP trunk, discusses its scope and applications, and establishes best practices for identification and security of SIP trunks.

The document makes for good reading even if you are not overly familiar with the concepts behind SIP trunks. Jonathan is looking for feedback and there will I’m sure be continued discussion on this topic.

Technorati Tags: sip, sip trunks, ietf, jonathan rosenberg

In the list of recently published RFCs, I was intrigued to see RFC 5118, “Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)“. This is really a companion document to RFC 4475 that provides IPv6-related messages you can use while testing SIP. From the overview:

This document is informational, and is *not normative* on any aspect of SIP.

This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as defined in [RFC3261].

This document is expected to be used as a companion document to the more general SIP torture test document [RFC4475], which does not include specific tests for IPv6 network identifiers.

This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that may cause interoperability problems in IPv6 deployments.

As IPv6 continues to move (slowly) along, it’s great to see an example like this RFC 5118 that can aid people who are developing SIP apps for IPv6.

Technorati Tags: ietf, ipv6, standards, sip

If you are the considering attending the 71st IETF meeting March 10-14 in Philadelphia, you may want to also visit the IETF-71 micro-site put up online by Comcast, the host of IETF-71. They’ve done a good job providing information about the hotel, restaurants, the social event and more. (And yes, they of course have a link to where to find the best cheese steaks… )

Over on the EComm2008 blog, Lee Dryburgh posted the transcript of a fascinating interview with Jonathan Christensen, general manager of audio and video at Skype. The interview is well-worth a read as Jonathan provides a preview of his upcoming keynote at EComm 2008 with his view of Internet-based communication and talks about advances they have made at Skype with regard to wideband audio and echo cancellation. I do definitely agree with his statement around the improvements they’ve made with echo cancellation on the Mac. Ever since upgrading to the latest Skype, I’ve made many calls with it from my MacBook Pro without any headset whatsoever and have been told the quality has been excellent (and it has been for me when I’m talking to other headset-free Skype users).

Much more relevant to this blog, though, were Jonathan’s statements regarding SIP. At the beginning Jonathan mentions how he originally got very excited by the vision of SIP and ran around stirring up interest at Microsoft where he worked then. But at the end of the interview, Lee asked Jonathan to elaborate on his earlier comments about SIP. This is what Jonathan said:

Yes, so just one clarification - we use SIP. Where, by comparison to the other operators, we are one of the largest SIP users in the world. All of our SkypeOut minutes and SkypeIn minutes traverse the PSTN via SIP interfaces, basically. So, we use it as an interop protocol where we need to.

I think that the vision of the early SIP founders has been largely unrealunrealized [See comments] in the SIP world. SIP is typically just used for these very mundane trunking applications, like the one that we have, or sending calls between two networks and it’s just calls. The vision of multi-modal communications and rich end points has largely failed within the same. I think that a big part of this is that they didn’t pragmatically just solve basic problems like NAT traversal, for example. They also evolved the specification to the point that it no longer had its lightweight appeal. So, we’ll see, SIP will continue to be [the] dominant protocol in terms of this sort of narrowly defined scenarios but I think that, when it comes to rich communications, you are going to see more of this fragmentation. You’re going to see some islands of providers who are just solving the problems. Just making it work for the user and not being religious about the protocol for example.

Has the vision of rich communication over SIP been “largely unrealized”? What do you think? Are his statements true? Or exaggerated?

FYI, if you are attending EComm 2008 you’ll have a chance to hear Jonathan Christensen’s keynote directly. And if you aren’t yet attending EComm 2008, why not?

P.S. For the record, we, too, are huge users of SIP for our connections to/from the PSTN and also throughout our hosted Evolution platform as well as our on-premise Prophecy product. Developers on our hosted platform also get by default SIP *and* Skype dial-in numbers for their applications.

Technorati Tags: skype, sip, ecomm, ecomm2008, conferences, jonathan christensen

Although I haven’t discussed it much here on this site, one of my passionate interests is in the whole space of “online identity” and what we need to do to have a better sense of “identity” online. There’s a number of levels to my interest but one very basic one is the ability to have a single “identity” that you can use while logging into different websites. Or perhaps not a single identity, but at least a small number of “identities” such as one online identity to login to “work” sites and another to login to “personal” sites. OpenID has emerged as a leading contender in this space and as I noted on our Behind the Blog blog , I have now enabled this site as an OpenID provider so that those of us who write here can use this site as an OpenID URL to login to sites. (And yes, I’m working on making the site a user of OpenID as well.)

In any event, while I will write more about OpenID in the future, over on his blog, Hannes Tschofenig writes about a new document “Technical Comparison: OpenID and SAML” that compares OpenID with the Security Assertion Markup Language (SAML). Here is the abstract:

“This document presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language (SAML) Web Browser SSO Profile and the SAML framework itself. Topics addressed include design centers, terminology, specification set contents and scope, user identifier treatment, web single sign-on profiles, trust, security, identity provider discovery mechanisms, key agreement approaches, as well as message formats and protocol bindings. An executive summary targeting various audiences, and presented from the perspectives of end-users, implementors, tna deployers, is provided. We do not attempt to assign relative value between OpenID and SAML, e.g., which is ‘better’; rather, it attempts to present an objective technical comparison.”

It’s great to see this kind of technical research now coming out in the field. The more we have of this kind of work the closer we will be to having solid and secure forms of online identity. If you are interested in reading the paper, it can be found here.

Technorati Tags: identity, openid, authentication, security, research

And so the real use of IPv6 on the public Internet begins. In a BBC article “Overhaul of net addresses begins“, the writer notes this:

On 4 February the master or root servers for the net will have a small number of records added that are written in IP version 6 (IPv6) added to them.

This means for the first time that computers using IPv6, typically a PC and a server, can find each other without involving any IPv4 technology.

Yes, indeed, IPv6 is now live in a useful way.

You have, of course, been able to use IPv6 for quite some time, but only really between sites that knew the address of the other end. The global DNS system for resolving names to IP addresses only supported IPv4 at the top-level root name servers. So if you tried to connect to any other site out there via DNS, you were always getting IPv4 addresses through what are called “A” records in DNS parlance. Now, as of yesterday, you can also get back IPv6 addresses through “AAAA” records.

IPv6 is still a long way from being commonly deployed, but at least with this step the people out there who want to use it, or at least experiment with using it, can now actually resolve addresses through parts of the global DNS infrastructure. Of course, DNS only returns an IPv6 address for sites that have such an address entered into DNS, so it won’t truly start being useful until more people: a) have IPv6 addresses assigned to their servers, etc.; and b) enter those addresses in their DNS tables. Still, this is definitely a step in the right direction.

FYI, those of us who subscribe to the IETF discussion list were told about this impending change back on January 4th, and if you would like to really understand how all this works on a technical level, a report is available from ICANN’s Root Server System Advisory Committee and Security and Stability Advisory Committee that goes into intricate detail about the impacts of this move. For those not familiar with how the DNS system works at a technical level, Appendix A starting on page 19 is well worth a read.

Technorati Tags: ietf, ipv6, dns, icann

Over on the Voice of VOIPSA blog today I posted about a new session has been approved for the IETF 71 meeting coming up in Philadelphia in March called “Reducing Unwanted Communications using SIP” a.k.a. “RUCUS”.Hannes Tschofenig, who submitted the proposal, has created a RUCUS web page and is looking for feedback. I’m planning to be at the RUCUS session at IETF 71 and would encourage others who want to talk about voice spam / SPIT to join in as well!

Technorati Tags: rucus, spit, spam, voice spam, voip, voip security, security, ietf, standards