Speaking of Standards

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

Do “intrastate” versus “interstate” billing rates make any sense whatsoever in the world of SIP where geography ceases to be relevant?

There is a fundamental disconnect today between the legacy world of PSTN billing practices and this new world of SIP-based interconnection that we are all building. The Internet ignores geography. We can connect to any random points in the cloud, regardless of where they are physically located.

But until the day when we have truly built the IP-interconnect and can all be bypassing the PSTN, we do have to deal with the PSTN… and all the legacy tariff/billing infrastructure that goes with it. How do you mesh the two worlds?

Consider this case within the US:

• A company in Massachusetts with phone number 617-555-1111 calls a customer
  also in Massachusetts with phone number 617-555-2222.

• The Caller ID presented to the receiving party is 617-555-1111.

• The company calling is billed the intrastate rate because the call appears
  to have originated and terminated within Massachusetts. For this
  example, and purely picking a number out of the air, let’s say the call at intrastate rates would have cost $5.

• However, the company in MA was actually using a hosted telephony service
  and while the call appears to have originated from Massachusetts based
  on the CallerID presented to the user (and transmitted as “6175551111@sipgw.carrier.com” in the SIP From
  and/or P-Asserted-Identity headers), the number actually entered the PSTN
  from a data center in New York with the number 212-555-1111.

• Had the calling company presented their billing identifier as 212-555-1111, they
  would have been billed the interstate rate for calling and for this
  example let say that the call would have only cost $3. (And yes, for those of you outside the US, this is true, calls within a state are more expensive than calls between states!)

• Naturally, the calling company wants to present its Caller ID to the
  end user as its own number of 617-555-1111 but it is contracting with the
  SIP telephony hosting provider in part to get cheaper rates. The hosting provider would
  naturally like to be billed at the interstate rate versus the intrastate rate
  when the calls enter the PSTN from their data centers.

There is the disconnect. PSTN billing is still tied to the identity of the originating number as seen through the carrier’s billing systems. Yet with SIP, the caller identity can be different from the identity of the PSTN interconnect point. (And yes, “Caller ID” can be spoofed on the PSTN but there are still underlying billing identifiers in the PSTN signaling.) As long as we continue to have tariffs in North America that have different rates based on geography, we’ll continue to have this problem.

A few years back, the folks over at Sonus Networks came up with an idea to address this disconnect - pass a custom SIP header called “P-Charge-Info” in the SIP INVITE that sets up the call and include in that header the SIP address to which to charge the call. They added this header to some of their equipment and some carriers started using it. So in the case above, the SIP headers might include headers like these:

From: <sip:617555111@sipgw.carrier.com>
P-Charge-Info: <sip:2125551111@proxy.hostingprovider.com>

To the person receiving the call, nothing has changed. The “Caller ID” that is presented on their phone is the same identity they saw before. But inside the cloud, the billing identity has been changed.

[Do note that there's a double-edged sword here. If the hosting provider and the carrier agree to use P-Charge-Info as the authoritative header for billing purposes, and then in my example above the Massachusetts customer starts making a lot of calls into New York they will wind up being charged the higher intrastate rate based on the P-Charge-Info header. So some analysis of calls needs to be done before agreeing to use this special header.]

Anyway, as one of the largest providers of VoiceXML/CCXML hosting, we are always looking at ways to ensure our customers receive the fairest billing. Late last year after one of our carriers suggested we look at using the P-Charge-Info header, we did so and were quite pleased with the results. Subsequently we have now started using this with multiple carriers.

Being strong proponents of open standards, we noticed that P-Charge-Info was not yet registered on IANA’s list of SIP parameters and so we approach Sonus Networks about going through the RFC 3427 process of registering a custom P-header. They agreed and so Tolga Asveren from Sonus Networks and I submitted an Internet Draft defining the P-Charge-Info header. We received a good bit of feedback/critique and our fourth version (-03) was just posted today.

Why are we going through this registration process, which can be quite lengthy? Several reasons:

• Expanded Usage - We would like to use this with other carriers but until this draft there was no specification for exactly how the header should be used. We would like this to be available as something to point other carriers/service providers to.

• Prevention of Further P-header Proliferation - Right now, if someone is looking for a SIP header to pass billing information, odds are they will look at IANA’s registry to see what headers have been added to SIP. Today the only billing headers are those of the 3GPP defined in RFC 3455 which do differ in intent from what P-Charge-Info does. If they don’t like the RFC 3455 P-headers, they may very well go off and invent their own P-header (anyone can) to deal with passing billing information.

  Our concern is that as we all in the industry continue building this IP interconnect, sooner or later we’re going to want to find ways to exchange billing information and if we have six different headers in production use it’s going to be a real headache. In the ideal world we would have a standard header (not a P-header) for passing billing information and probably we eventually will… but that will take some time to get developed and then deployed. In the meantime, let’s document and register what’s out there now so that people can see the choices they have and not necessarily go right off creating yet another billing information header.

• Prevention of Identity Conflict - It’s very possible that someone going off and creating their own SIP P-header could very well choose to call their header “P-Charge-Info”. One would hope that someone creating a new P-header might use Google to search for the header name they are planning to use (in which case they would discover this existing usage of P-Charge-Info), but someone might not and start using it. It could then happen that some day someone out there would wind up needing to interoperate with two different pieces of equipment that both use a “P-Charge-Info” header, but in different ways. IANA registration is designed to help prevent this.

• It’s The “Right Thing” To Do - If you read section 4.2 of RFC 3427 it states very clearly:
  

  Any P-header
  used outside of a very restricted research or teaching environment
  (such as a student lab on implementing extensions) MUST meet those
  requirements [of section 4.1] and MUST be documented in an RFC and be IANA registered.

  Now obviously no one is enforcing this. There are many P-headers in common usage today that are not documented. No one will slap you down and revoke your right to use SIP if you don’t. But it’s the right thing to do for the reasons outlined above as well as to respect the process defined in RFC 3427.

So where is P-Charge-Info in the RFC 3427 process of IANA registration? Well, Tolga and I now have a fourth revision of our Internet Draft out (it’s the fourth because the first was “-00″) and we would very definitely like comment on the draft. Please do send them in via email (or leave them as comments here). Once the document has gone through more review (perhaps another draft or two) we will then continue the steps in section 4.1 of RFC 3427 and request “expert review”. Ultimately the goal is to have the document published as informational RFC so that it can be registered with IANA.

As I said, comments and feedback are definitely welcome. What do you think of the document? of the problem we are trying to solve?

Technorati Tags:
ietf, sip, standards, voxeo, sonus networks, p-charge-info, voip, telecommunications, telephony, pstn

Have you ever wanted to send information between two applications using SIP that didn’t fit into one of the existing “headers” that are using in the SIP communication exchange? Did you look through the various headers in RFC 3261 (and associated RFCs) and find that none fit exactly what you were seeking to send?

If so, what you can use instead is what is called a “private header” or “P-header” for short.

Before we jump into P-headers, let’s first take a moment to switch to the world of email. With email, there are so-called “experimental headers” that are sent in the SMTP exchange that all start with “X-”. Here are some examples:

X-Priority: 	Normal
X-Mailer: 	Apple Mail (2.753)
X-Authentication-Warning: 	blogs.voxeo.com: apache set sender to wordpress@blogs.voxeo.com using -f
X-Spam: 	exempt
X-Mail-From: 	<wordpress@blogs.voxeo.com>
X-Source-Ip: 	[(unknown)]

These “X-” headers are added by various programs to email messages that are sent and share the common characteristic that they are all informational. They do not indicate any action that has to occur. They are not SMTP commands. Each of these X-headers are purely containers of information that is passed along in the SMTP message. On the receiving end, the application accepting the SMTP connection can look at those X-headers and then potentially decide to take some action on the received message based on the contents of those X-headers. If a receiving application doesn’t no what to do with an X-header it receives, it simply ignores the header. With regard to the “informational” nature of X-headers, the idea is that if an application ignored all X-headers, the email message should still be able to be delivered. X-headers add extra information and capabilities, but don’t block the basic existing SMTP.

These “experimental” headers are now widely used by mail programs, by anti-spam software and basically all sorts of other programs that interact with email. They are a way to pass along extra information about the email message. Companies, vendors and individuals can all define and use their own X-headers to try out new services and offerings. They don’t need to check with anyone. They can just go ahead and create a new header to try it out. (Presumably checking first to see that their new name didn’t conflict with existing X-headers on their network.)

Back in the world of SIP, the IETF defined a process in RFC 3427 for extending SIP that was similar to the experimental headers of email. The fundamental difference was that in SIP instead of beginning with an “X-” the headers begin with a “P-”, as in “P-Asserted-Identity”. Otherwise, they are very similar. P-headers in SIP must, like the X-headers of email, be purely informational. They cannot be used to create new commands and must not interfere/block the regular transmission of SIP messages. They merely pass extra information that the receiving application can choose to do something with (or not).

Here are some examples:

P-Asserted-Identity: "Dan York" <sip:dan@company2.com>
P-Charge-Info: <sip:proxy1@company2.com>
P-Charging-Vector: icid-value=1234bc9876e;
                   icid-generated-at=192.0.6.8;
                   orig-ioi=home1.net
P-Visited-Network-ID: "Visited network number 1"
P-I-Made-This-Up: "Pretty silly, isn't it?"

Here is how a couple of these would look in an actual SIP message:

INVITE sip:1234@company2.com SIP/2.0
Via: SIP/2.0/UDP proxy.company2.com:5060;branch=z9hG5bK21ghi7ab34
Via: SIP/2.0/UDP sip.company1.com:5060;branch=z9hG4bKnashds7
To: sip:1234@company2.com
From: sip:dan@company1.com;tag=451248
Call-ID: 324817637683475998ababcc10
CSeq: 1 INVITE
Contact: sip:dan@company1.com
Max-Forwards: 50
P-Asserted-Identity: "Dan York" <sip:dan@company2.com>
P-Charge-Info: <sip:proxy1@company2.com>

The application receiving this SIP message can then choose to read these headers and potentially perform some action based on the contents of the headers. (If you are developing your application on our platform and using CCXML, we’ve provided instructions for how to access those SIP headers.) For instance, the “P-Asserted-Identity” header is very often used as the “Caller ID” that is displayed on the end user’s phone or other SIP device.

So what should you do if you want to start using a P-header to pass information via SIP between two applications?

First, you should head over to the IANA registry of SIP headers to see if someone has already defined a P-header that might do what you are looking to do. For instance, P-Asserted-Identity has been defined in RFC 3325. The 3GPP has defined several P-headers related to IMS in RFC 3455.

Second, if you don’t see any defined P-headers, you might want to search the IETF database of Internet-Drafts to see if there are any P-headers in a proposal stage that might work for you. The process of registering a P-header with IANA (so that people know about it and to prevent naming conflict) is documented in RFC 3427 and first involves the creation of an Internet-Draft document. For instance, I have an Internet-Draft submitted on the P-Charge-Info header that we are seeking to register with IANA.

Third, while in the IETF database you might also just want to search for the general type of information you are seeking to pass between applications. It may be that there is some work underway in an IETF Working Group that would wind up creating standard headers (versus P-headers) to pass the information you are seeking to pass.

Finally, if you are unable to find any current or in-progress P-headers, you can create your own. Keep in mind that it should start with “P-” and the general convention has been to put a dash between any words in the name and to use initial capitals, as in “P-Asserted-Identity”.

For more information about creating P-headers, please do read RFC 3427.

Technorati Tags:
sip, ietf, standards

Did AOL, the historical king of walled gardens, just become the biggest public advocate for SIP and open standards for VOIP?

That’s the point David Beckemeyer makes in his blog post challenging my view of the launch of AOL’s “Open Voice Program” as of questionable value. David counters:

However, it is significant for SIP - we now have a household brand not referring just to “VoIP” but referring to “SIP” - the standards-based protocol for VoIP, something neither Skype nor Vonage has done. SIP means interoperability and that’s a good thing for users and the VoIP ecosystem at large. A brand as big as AOL providing awareness for SIP and promoting interoperability is terrific - nobody else is doing it.

He goes on:

It’s important to note that we have never been able to do this so with Skype, even though the service has been out for four years or more - they could have offered this years ago.

Indeed… point taken, David.

While many of us in the VoIP industry have been trumpeting SIP as the VoIP protocol of choice for years, and work of groups like the SIP Forum has helped in that, outside the walls of our telecommunications/networking community a poll of people would probably find that pretty much no one has heard of “SIP” as it relates to VoIP.

On one level, why should they? It’s just a protocol and at the end of the day it shouldn’t really matter. People just want their phone to work… and SIP and other protocols are just the underlying plumbing.

But for those of us who passionately want to see that plumbing be based on open standards like SIP, David’s right… putting the AOL brand behind SIP is a good thing to help raise awareness of SIP and the need for interoperability. AOL is letting users connect any SIP device to their network. Any device. Not just “certified” ones… not “recommended” ones… any device.

It’s a beautiful thing.

And maybe, just maybe, the people who do start using the service will enjoy the freedom of choice that comes with interoperable open standards and maybe… maybe… they’ll start asking for that interoperability in other services. <rosecoloredglasses>Is that too much to hope for?</rosecoloredglasses>

And so while I still may wonder how many people will really use AOL’s service, as a huge believer in open standards… working for Voxeo, a company who bases its existence on open standards… as a believer in the messy but open process of the IETF to create SIP standards… as an advocate for open protocols and interoperability… as all of that I have to join David in applauding AOL’s move. Thank you, AOL, for jumping behind SIP and helping, in some small way, to help tear down the walls that have locked in telephony for way too long.

Go AOL! Go SIP!

Technorati Tags:
aim, aim call out, aol, aol open voice, sip, ietf, standards, voip, telephony, telecommunications

It’s hard these days to escape news about peer-to-peer (P2P) applications and the concerns raised by service providers about those P2P apps. With recent FCC hearings about Comcast “delaying” P2P traffic, the topic is getting a great amount of discussion across the blogosphere and in the media in general. To look at the issue from a technical point-of-view and see if there are technical solutions that could help in the area, the IETF recently announced a “workshop on P2P Infrastructure” to be held on May 28th on the campus of MIT in the Boston area.

From a voice perspective, any kind of latency / delay is something to be avoided at all costs. As researchers look at P2P SIP as a future deployment model, getting the infrastructure right is a key factor in the future success of P2P SIP. Now, serious deployments of P2P SIP won’t happen for some time now (probably a few years), but the reality is that it will also take some time for any technical solutions to: 1) work their way through IETF; 2) be incorporated into vendor equipment; and 3) actually be deployed in service provider networks. So now is really a good time to get started.

If you are interested in P2P applications in general and are in the Boston area (or can get there), please do consider attending this workshop. There is a wiki page for the workshop that will be updated as the workshop gets closer and a ‘p2pi’ mailing list that is open to anyone to join.

Here is part of the announcement that explains what the workshop will be about:

---

The Real-time Applications & Infrastructure (RAI) Area Directors, Jon
Peterson and Cullen Jennings, would like to announce an IETF workshop on
P2P Infrastructure to be held on May 28, 2008 at 50 Vassar St, Room
34-101 on the MIT campus in Cambridge, MA USA.

Several large ISPs have encountered issues with P2P traffic. The
transfer of static, delay-tolerant data between nodes on the Internet is
a well-understood problem, but traditional management of fairness at the
transport level has largely been circumvented by applications designed
to achieve the best end-user transfer rates. This results, at peak
times, in networks running near absolute capacity, and in which all
traffic incurs delays; the applications that bear the brunt of this
additional latency are real-time applications like VoIP and Internet
gaming. This has led to need for further discussion of the proper
approaches to P2P application development, and infrastructure management
in environments where P2P is commonly used. This workshop intends to
discover where additional IETF standards work is needed, or existing
work might be reapplied, to alleviate these difficulties. In particular,
the workshop will draw on the experiences of Comcast and BitTorrent,
representatives of both of whom will present their perspectives on the
problem space.

Example solution discussions might include, but are not limited to:
deployment of application servers or caches to reduce network load; new
rendez-vous mechanisms to optimize P2P network topology; enabling
applications to signal their bandwidth needs (and priority or lack
thereof) to networks; enabling networks to signal bandwidth constraints
to elastic and inelastic applications; and, new approaches to fairness
that are coupled with incentives for applications. Contributions from
subject matter experts in the problem and solution space are
welcome. The primary outcome should be a direction for one or more IETF
efforts exploring the best practices for addressing these challenges.

The organizers would like to stress that this is a technical workshop
exploring engineering issues and practices. The public policy
implications of P2P applications are not in the scope of this workshop.

---

If you would like more information about how to participate in the workshop, please read the full announcement.

Technorati Tags:
ietf, standards, p2p, peer-to-peer, p2psip, sip, voip, comcast, bittorrent, Internet, networking

It’s been a long and exhausting week… There are so many things I have wanted to write about… the RUCUS BOF… the MEDIACTRL session… the IPv6 experiment in the first plenary… the P2P video presentation in the technical plenary… the SIPPING and SIP sessions… the SPEERMINT and PEPPERMINT sessions… meeting the co-author of a draft I wrote who I had never met… the VERY lively P2PSIP session this morning… my challenges streaming video with hot laptops… cheese steaks and random strangers… the 100 Gbps network that Comcast brought in (yes, you read that correctly!)… so many sessions… so many great conversations… so many great people… so much great work going on… so many great stories to tell…

Alas, those stories will have to wait for late Sunday or Monday (or next week)… right now it’s time for me to head offline for some family time before I head out Sunday afternoon to Orlando for VoiceCon!

Technorati Tags:
ietf, ietf71

If you would like to listen to what is going on at the IETF-71 sessions in Philadelphia the sessions will be streamed in real-time courtesy of the Network Startup Resource Center at the University of Oregon. (Tip to Comcast’s IETF71 site for the link.)

You can also join in the IETF group chatrooms to see commentary during the sessions and also to ask your own questions. Each working group typically has someone acting as Jabber “scribe” during the session who will type updates into the chat room and also pose questions from chatroom members.

So here’s how you can participate remotely:

1. LOOK AT THE OVERALL AGENDA - Browse the meeting agenda and find the session(s) you want to attend.

2. FIND THE WORKING GROUP ABBREVIATION AND/OR ROOM - This is the important part. You need the “Working Group” or BOF abbreviation to go on to the next steps. Let’s say that on the agenda you want to following the “Multiparty Multimedia Session Control WG” on Monday morning at 9:00am. The working group abbreviation is “mmusic” and it is going to be in room “Franklin 3/4″.

3. FIND THE AUDIO STREAM FOR THE SESSION - Go to the audio streaming page and look at the row for the room and the column for the day. You should see the Working Group abbreviation there. Click on the audio link for that room. For instance, MMUSIC tomorrow morning at 9am is on audio channel “ietf71-ch2“.

4. JOIN THE IM GROUP CHATROOM - To join the group chatrooms you’ll need a Jabber-based IM client which could be something as simple as GoogleTalk. If you are on a Mac, Adium works great with your GMail/GoogleTalk account. Connect to the Jabber server “jabber.ietf.org” and join the “room” of the working group abbreviation. For instance, MMUSIC would be “mmusic” (and the full Jabber name of the room will be “mmusic@jabber.ietf.org”).

5. LOOK AT THE SESSION AGENDA / MEETING MATERIALS - Look at the session agenda / materials list to see what is specifically being talked about and what slides might be available for you to view. NOTE: Session materials are often not posted until the session is ready to start (or sometimes afterward).

If you’ve followed these steps, you should now be listening to the audio for the session and also connected into Jabber where you can potentially find out who is at the microphone and - if you want - ask your own questions. If you have a questions, the “Jabber scribe” for the session can get to the microphone and ask the question for you.

A couple of notes:

• Philadelphia is in the US Eastern timezone. Note that we just shifted to Daylight Savings Time so there’s an hour timezone difference from yesterday.

• Jabber chat rooms will probably be empty until there is an actual session going on.
• There are Jabber chat rooms for the working groups but not necessarily for BOFs. It’s not always clear what Jabber chat room a BOF will use.
• When you join a Jabber chat room, if no one identifies themself as the scribe, feel free to ask. (Hint: It’s probably the person typing a lot.)
• Note that Jabber chat sessions are archived, so please realize that everything you say in them will be public.

All in all it’s a great way for remote participants to join in to what is going on down at IETF…. so check it out!

Technorati Tags:
IETF, standards

On Sunday night I head down to Philadelphia for the IETF-71 meeting for the whole week. It will be a crazy week full of discussions and conversations about all the various standards under development. The RUCUS BOF I’ve mentioned before will be on Monday as is the SIPPING Working Group. MEDIACTRL Working Group (of key interest to us here at Voxeo) is on Wednesday as is SPEERMINT and PEPPERMINT (Hey, it’s IETF, you have to have cute names!). Thursday brings SIP, BEHAVE, AVT and ENUM and Friday morning winds it all up with the P2PSIP working group.

Being who I am, I’ll pretty much sit in all of the “Realtime Applications and Infrastructure” (RAI) working groups as sometimes activity in one group turns out to have great relevance to work in other groups (or to work here at Voxeo). I’ll be online the Jabber chat rooms probably much of the whole time as well.

If you’ve never seen the full agenda for an IETF meeting, it’s pretty incredible (at least to me!). In any given timeslot there are typically eight simultaneous meetings of various working groups, BOFs, research groups, etc. This makes sense if you remember that the IETF is developing standards for pretty much all aspects of the Internet. While I usually never leave the world of RAI, there are groups dealing with security, DNS, email, IPv6, network routing, time (seriously!), host configuration and pretty much every other subject you can imagine relating to the Internet. Take a look!

And yes, the days do begin with a breakfast at 8am and meetings that go until 7pm (often with additional ad hoc meetings afterwards). The good news is that the breaks between sessions usually have food and drink to keep you recharged.

For those attending who wish to stalkfind me, here below is the agenda I think I’ll be following (subject to the fact that it can, of course, change). Like I said earlier, it’s pretty much all of the RAI area.

---

MONDAY, March 10, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

mmusic

Multiparty Multimedia Session Control WG

1300-1500 Afternoon Session I

RAI

rucus

Ruducing Unwanted Communications using SIP BOF

1520-1720 Afternoon Session II

RAI

ecrit

Emergency Context Resolution with Internet Technologies WG

1740-1950 Afternoon Session III

RAI

sipping

Session Initiation Proposal Investigation WG

TUESDAY, March 11, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I
One of these:

IRTF	rrg	Routing Research Group
OPS	v6ops	IPv6 Operations WG
RAI	geopriv	Geographic Location/Privacy WG

1300-1500 Afternoon Session I

RAI

bliss

Basic Level of Interoperability for SIP Services WG

1520-1720 Afternoon Session II

RAI

avt

Audio/Video Transport WG

1740-1840 Afternoon Session III
One of these:

IRTF	asrg	Anti-Spam Research Group
RAI	simple	SIP for Instant Messaging and Presence Leveraging Extensions WG

1850-1950 Afternoon Session IV

RAI

xcon

Centralized Conferencing WG

WEDNESDAY, March 12, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

mediactrl

Media Server Control WG

1300-1500 Afternoon Session I

RAI

speermint

Session PEERing for Multimedia INTerconnect WG

1510-1610 Afternoon Session II

RAI

peppermint

Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF

1610-1700 PGP Session
(Yes, I’m one of those people who does actually go to PGP key signings.)

pgp

PGP Key Signing

1700-1930 IETF Operations and Administration Plenary - Salon G/H

THURSDAY, March 13, 2008
0800-1700 IETF Registration - Franklin Hall Foyer

0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

sip

Session Initiation Protocol WG

1300-1500 Afternoon Session I
One of these:

IRTF	hiprg	Host Identity Protocol
SEC	saag	Security Area Open Meeting
TSV	behave	Behavior Engineering for Hindrance Avoidance WG

1510-1610 Afternoon Session II
One of these:

RAI	avt	Audio/Video Transport WG
RAI	enum	Telephone Number Mapping WG

1700-1930 Technical Plenary - Salon G/H

FRIDAY, March 14, 2008

0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

p2psip

Peer-to-Peer Session Initiation Protocol WG

---