Speaking of Standards

Are you unable to travel to Dublin this week to participate in IETF 72? If so here are steps to participate remotely:

---

1. SCAN THE OVERALL AGENDA: The overall meeting agenda is your key to knowing which workgroups are meeting when. Keep in mind that Dublin is currently on Irish Summer Time and is UTC+1 hour. For me here in the Eastern US timezone, Dublin is 5 hours ahead.

2. REVIEW THE WORKING GROUP AGENDAS: From that overall agenda, click on the links to the agendas for specific working groups. The agendas are created by the individual working group chairs and so the format varies from WG to WG, but usually they have links to the various Internet Drafts that will be discussed in the sessions. For example, here is the agenda for tomorrow’s meeting of the SIP Working Group. Note that, as indicated on that agenda, some Working Groups do in fact meet twice during the week while others only meet once.

3. DOWNLOAD THE MEETING MATERIALS: In preparation to participate in a session you can go to the Meeting Materials page and download the slides that will be presented during the session. Note that in many cases the slides may not be available until very shortly before the sessions begin, so you may need to refresh the page to see the slides.

4. TUNE INTO THE AUDIO: Once you know the time and name of the working group/BOF you want to monitor, find the audio streaming channel to join on the IETF audio streaming page. There are 8 channels of streaming audio. Find the column for the day. Each row in each cell is for a different timeslot. For the timeslot you want, find which channel is streaming the working group/BOF you want to monitor.

The audio stream is just a streaming MP3 channel, so you should be able to listen to it with iTunes, Quicktime, Windows Media Player, RealPlayer, winamp or basically any other media player. If you have can’t hear any audio, you may want to check the status page to see if there are other listeners. If you still can’t hear anything, you may want to post a question in the Jabber chat room (see below). The working group might have changed rooms at the last minute and so the audio streaming page may no longer be accurate.

5. JOIN THE JABBER CHAT ROOM: The audio stream only lets you hear what is going on. There is no way for you to ask questions via audio. For that, you need to join the Jabber “group chat room” for the working group or BOF. To do so, you can find information on the IETF Jabber page, but essentially it comes down to this:

• Launch a Jabber/XMPP client. (I recommend the Psi client if you don’t have one. Mac users may like to use Adium. GoogleTalk users can also use the GTalk client.)

• Login to Jabber. You do need to have an account on a Jabber server already set up. This could be your GoogleTalk account if you use GMail, or it could be any one of the public Jabber servers out there. (I use jabber.org.) Alternatively, it can be a Jabber server running on your own system/network. As long as the server is publicly accessible, you’ll be able to connect to the IETF chat rooms.
• Connect to the appropriate IETF chatroom. In your Jabber client, you need to find the command to join a “group chat”. Once there, the server (or “host”) you need to connect to is “jabber.ietf.org” and the room is the name of the working group or BOF. For instance, this screenshot shows how to join the room “sip@jabber.ietf.org” using the Psi Jabber client:
  

There should be someone in the Jabber chat room who is physically in the IETF meeting room and who can relay where the group is in the agenda, who is speaking at the microphone and can also relay your questions from the Jabber chat room back to the meeting. If there is a Jabber scribe, you can ask he/she to raise your questions and he/she will go up to the mic and ask the question on your behalf. Some working groups make sure to have Jabber scribes… others aren’t as diligent about this, but you can probably find someone else in the chat room who is there in the meeting room and might be able to ask your question.

The Jabber chat room is also a great way in general to stay connected to what is going on in the session.

---

With these steps, you should be able to participate remotely in the IETF meetings.

Technorati Tags: ietf, jabber, standards, conferences

The Squawk Box interview I mentioned yesterday about P2P SIP is now available for download. It was an enjoyable interview with David Bryan and I think you’ll learn a lot about P2P SIP from it. We talked about what P2PSIP is, why you might use it, where it might be applicable, what the security ramifications might be and how you might use P2PSIP. It’s quite a fascinating area of research and development and we’ll be curious to see how it all evolves.

Technorati Tags: squawk box, sip, p2psip, p2p, dan york, ietf

UPDATE: The podcast referenced here is now available for listening.

---

Given that I’ve written here before about Peer-to-Peer (P2P) SIP (and why it’s of interest to us), I thought I’d invite you to join in tomorrow (July 9, 2008) at 11am US Eastern time when I’ll be interviewing David Bryan, co-chair of the IETF’s P2PSIP Working Group and CEO of SIPpeerior Technologies, about P2P SIP… what it is, who might use it, and why it matters.  It should be an enjoyable and interesting call for those of us who are interested in the underlying networks that make VoIP possible.  

If you would like to join into the call and are a Facebook user, you can easily join the call through the Calliflower application for Facebook.  If you don’t use Facebook,  you can just go to the Calliflower.com website (you will need to create a free account there).  If you can’t join us at 11am US Eastern time tomorrow (Wednesday, July 9th), you will also be able to listen to the show later in the day when I post it to Alec Saunders blog at Saunderslog.com.

Here’s a brief video preview:

P.S. “Squawk Box” is a daily podcast on technical topics of the day hosted and produced by Alec Saunders and appearing on his Saunderslog blog. I often participate in the calls and as Alec is on vacation this month, he asked me to fill in as a host for him this week. Other than my involvement as a participant, there is no formal connection at all between Voxeo and the Squawk Box podcast.

So if we get to the point where we can truly “trust” the identity of the person calling us on the other end of a SIP connection, what will that look like to the end user? How will I know - easily - that I can trust that the “Caller ID” displayed on my IP phone is in fact who it says it is? Is there a “visual identifier” of some type that I could have on my IP phone (or softphone) that would clue me in? Kind of like the “lock” icon in web browsers that indicates a call is encrypted?

Those were the questions I was looking to address in a new Internet-Draft I submitted yesterday:

draft-york-sip-visual-identifier-trusted-identity-00

One of the things we focus on here at Voxeo is to ensure that the user experience is as simple and easy as possible. That’s why we rolled out our Designer tool a few years back. That’s why we spent a good amount of time looking to make Prophecy Log Search as simple to use as possible - and why we continue to improve it.

So in the discussions that have been going on within the IETF circles around the incredible need to nail down the ability to have “trusted identity” within communication based on SIP (which I wrote previously, one of the questions I’ve kept asking myself is “how will this appear to a regular end-user?” Based on some comments in the SIP mailing list the other day, I decided to write up this draft.

Feedback is welcome. I’ve already received the comments that I didn’t address the whole issue of PSTN interconnectivity, i.e. if it’s coming from a PSTN gateway, how do you deal with the fact that the Caller ID could have been spoofed on the PSTN side. I’m sure other comments will come in as well.

As I say in the draft, it’s not entirely clear to me that the IETF is the right place to have this discussion since ultimately it is about the user interface in vendor products… but at least it’s a place to start.

Technorati Tags: ietf, standards, sip, dan york, sip identity, identity

Do you trust the “Caller ID” you see on your phone when someone calls? Do you realize that it can be easily changed? Do you realize that spoofing that Caller ID gets even easier when we start communicating more over SIP?

Right now, one of the greatest challenges being addressed by the Real-time Applications and Infrastructure (RAI) area of the IETF is the whole concept of being able to trust the identity of the user who is calling you. You see, being able to trust the identity of the person on the other end of a SIP connection is incredibly hard. John Elwell recently summarized the issues well in his draft: “End-to-End Identity Important in the Session Initiation Protocol“. Getting “identity” right is one of the largest issues on the agenda of the various groups in the RAI area of the IETF.

Why? Given that we don’t have any way to trust the identity of a caller on the PSTN, why does it matter for SIP? I mean, Caller ID on the PSTN can be easily spoofed… either through any number of web sites or simply through hooking up your own IP-PBX to the PSTN (it’s even possible to do through applications built on our platform). Yet the vast majority of people I’ve asked still trust “Caller ID” on their PSTN phone.

I’d argue that this probably is mostly due to history… for the longest time, you couldn’t easily change your Caller ID. It was set within the carrier networks that make up the PSTN. People have grown to trust it. I expect that will change as unethical telemarketers will no doubt start to make more changes to get around all the call blocking users are doing. If it looks like the call is from your friend, you’re probably going to take the call.

The thing is that SIP makes this incredibly easy. Like SMTP for email, SIP is entirely text based and so just as you can change your email client to say you are sending mail from “elvis@heaven.gov”, you can change many SIP clients to say you are calling from whatever name or phone number you want. If you can’t change the client, you can set up and run your own SIP server.

The danger that many of us see is that if this capability gets widely abused, there is the strong potential that we could wind up in a situation where your identity over SIP is dismissed and not trusted… just like email addresses are today. Given the huge volume of email spam, how many of us actually trust that the “From” address on an email message is really who it is? We have to go into the email message to really see if it is someone we know… which is something you can’t really easily do with real-time communication like voice. You have to actually accept the call and start talking.

I don’t think we as an industry want to see SIP identity go that way… so we need to make sure that we get SIP identity right. We need to get to a state where users can trust that the “Caller ID” they see displayed on their IP phone, softphone, or other device is actually who it says it is.

From a Voxeo perspective, we’re interested because we’d like to see more and more communication occur over SIP. Our Prophecy product is a SIP application and media server. Our hosted platform allows inbound and outbound SIP connections to and from applications. On the back end, we’re a huge consumer of SIP trunks. We want to be able to trust the identity information we see.

Because we also host 10s of thousands of voice applications (55,000+ right now), we also are very interested to ensure that any identity mechanisms allow your SIP identity to be extended to a service provider. If you have pushed your voice applications out into our hosted cloud, right now your apps can set our PSTN Caller ID to be a number that is identified as you. We want to see the same capability within SIP - and want the recipients to be able to trust that the identity of the caller is in fact you - even if we may be actually hosting the infrastructure.

Obviously while most communication today occurs still over the PSTN, some of these issues aren’t immediate. But as we all go about building the great big SIP interconnect that lets us bypass the traditional PSTN, these issues become increasingly important.

We have to get SIP identity right - or risk being dismissed.

If you’re interested in getting more involved, I’d encourage you to subscribe to the IETF’s SIP and SIPPING mailing lists (but obviously be aware that “identity” is not the only topic being discussed there - and beware, they can be high volume lists). Here are some pointers to pieces to read for background:

• End-to-End Identity Important in the Session Initiation Protocol

• RFC 4474 - SIP Identity
• RFC 4916 - SIP Connected Identity
• RFC 3325 - P-Asserted-Identity
• SIP Identity Using Media Path
• Why SIP URIs Change Across Domains
• Adding Asserter Identification to P-A-I of RFC 3325

There will be a great amount of discussion in the weeks and months ahead… feel free to join in!

Technorati Tags: ietf, standards, sip, identity, sip identity, caller id, telephony, telecommunications, internet, voip

As I’ve written about before, we’re fans of the SIPit interoperability events that are sponsored by the SIP Forum as they provide a great way to test how well different vendors SIP implementations interoperate. We recently attended SIPit 22 at the University of New Hampshire and the feedback was extremely helpful in our continual effort to improve our products.

Anyway, SIPit 23 was recently announced for October 13-17 in Lannion, France. The event is hosted by the ETSI Interopolis Service and France Telecom-Orange Labs. ETSI has a website for the SIPit 23 event that is full of information about the event.

I don’t honestly know yet whether we’ll be attending, but I do encourage vendors to seriously take a look at attending. It’s a great place to learn how well your SIP implementation plays nice with others.

Technorati Tags: sip, sipit, sip forum, interop, interoperability, etsi