Posts Tagged ‘IETF’

Want an IETF-branded T-shirt? hat? coffee mug?

Tuesday, August 17th, 2010

ietft-shirt.jpg

Have you wanted a T-shirt, hat or mug to help promote the IETF and your support of the organization?  Now you can buy one, courtesy of a new online store the Internet Society has opened up:

http://www.cafepress.com/ietf

I think it’s very cool to see because many people who attend IETF meetings have wanted to help promote the great work of the IETF… but haven’t been able to have an easy way to do so like wearing a shirt (except for the shirts they receive at IETF events).

Not being a personal fan of white T-shirts (I have young kids), I naturally wanted to see a black shirt… and while they are not there yet, I’m sure they will be at some point.  It’s from Cafe Press and all created “on-demand”, so the number of items is really only limited by ISOC’s choices as well as their ability to upload appropriate graphics (for example, black shirts do need a special image).

I’m sure they’ll be getting all sorts of feedback in the next few weeks with requests for products.  Kudos to ISOC for setting this up!

 


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


Registration opens for IETF 79, Nov 7-12, in Beijing, China

Friday, August 13th, 2010

ietf-shadow.jpg

News came out yesterday that registration is now open for the 79th meeting of the Internet Engineering Task Force (IETF) to be held November 7-12, 2010, in Beijing, China.  You can find out more and register at:

http://www.ietf.org/meeting/79/

The announcement contains more information and pricing (as does the web site).

Tsinghua University, the host of the meeting, also put together a dedicated website providing more information and including a video promoting Beijing:

http://www.ietf79.cn/

This is a milestone for the IETF in that it is the first IETF meeting to be held in China.


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


Two new SIP-related IETF Working Groups: LSD and SALUD

Thursday, July 15th, 2010

ietf-shadow.jpgThis past week brought the announcements of two new SIP-related Working Groups out of the IETF. In the long-standing tradition of having entertaining names, they are naturally “LSD” and “SALUD”.

The first announcement was for the “Loosely-coupled SIP Devices” Working Group (LSD) covering a topic of personal interest to me – disaggregated media. From the charter description:

Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session.

Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session.

There are a number of existing mechanisms that can be used to coordinate different devices under user’s control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in “tightly coupled” scenarios. The use of all those mechanisms requires the presence of a “master” device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the “master” device is supposed to remain involved in the user’s session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible.

The objective of this working group is to develop a framework for disaggregated media in “loosely-coupled” scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. The framework may identify the need for new (non-device-coordination) mechanisms to enable the implementation of loosely-coupled scenarios. In case the need for such new mechanisms is identified, the working group will specify them.

For those interested in participating or monitoring the discussion, there is a LSD mailing list to which anyone can subscribe.

The second announcement was for the “Sip ALerting for User Devices” (SALUD) Working Group. This group is looking to tackle an area of interoperability around the semantics behind one part of SIP signaling. The description provides these examples:

RFC 3261 allows a user agent server to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone.

RFC 3261 also allows a user agent client to provide a reference to a specific alerting tone, which can be played to the called user (e.g., tones for emergency announcements sent over PBX systems or over the local telephone network). As in the previous examples, in some situations, the calling user may not be able to understand the meaning of the alerting tone being played.

This Working Group is going to be working to define a standardized set of URNs that can be used in the Alert-Info SIP header to pass along the meaning rather than a specific URI of a media file to be played (for instance). This would allow different systems to provide the most appropriate alert to the user based on local or personal settings.

Again, there is a mailing list available for anyone interested in participating in or monitoring the developments of the WG.


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


IETF 78 registration open – July 25-30 in The Netherlands

Friday, June 11th, 2010

ietflogo-2.jpgThe 78th meeting of the IETF is coming up July 25-30 in Maastricht, Netherlands. Registration is open. As was the case for IETF 77, there is also a day pass option available for people who just want to attend for the day.

It does not look like my schedule will allow me (Dan York) to participate directly in IETF 78… it’s the week right before SpeechTEK New York and for us at Voxeo SpeechTEK is really the largest show we participate in… and so I expect I and my team will be quite busy that week. Schedule permitting, I’m hoping to at least catch a few of the sessions remotely.


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


RFC1 was 41 years old yesterday…

Thursday, April 8th, 2010

ietf-shadow.jpgA colleague pointed out that yesterday, April 7, marked 41 years since the very first “Request For Comments” was issued! RFC 1, titled simply “Host Software, was issued on April 7, 1969. With the latest RFC being number 5841, we’ve come a long way…

So “Happy Birthday” to the RFC system!

rfc1.jpg

Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


NoJitter.com adds IETF coverage with David Bryan

Monday, April 5th, 2010

ietf-shadow.jpgOver on the NoJitter.com site, David Bryan provides a good wrap-up of some of the activities at the IETF 77 meeting last month in California. For those new to the IETF, he also provides some background on the IETF process.

Personally, I’m delighted to see David start writing over at NoJitter. For two reasons, really. First, David’s been a friend of mine for several years and has a lot of great insight to share, particularly related to the P2P space. (I interviewed David on video about P2PSIP and he was once a guest contributor on this blog about P2PSIP and Skype.) I’m glad for him that he’s found a writing home over at NoJitter.

Second, I’m pleased that NoJitter will be increasing their “standards” coverage by having David write there. I’ve personally been a longtime fan of what Eric Krapf and his team have been doing with the site ever since they shut down their BCR print magazine and moved into publishing only online. They continue to do a real nice job attracting excellent quality people to write there. While there has been some commentary about standards and interoperability, it will be good to have someone with David’s level of IETF experience writing there… I look forward to seeing what all he’ll write. (No pressure, David, okay? :-) )

We need more blogs and sites that are talking about open standards. Good to have another one out there.

P.S. David, you might want to talk to Eric Krapf about letting you buy a few more vowels… titling you a “Int’net Cmc Str’gist” seems rather abusive to the English language…


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


Skype releases source code for SILK super wideband audio codec – the details…

Thursday, March 11th, 2010

skypelogo-shadow.pngWant to implement Skype’s SILK super wideband audio codec? You know, the software that makes Skype’s audio calls sound so rich and like you are “right there”?

If so, just check out Appendix A of this massive Internet-Draft:

http://tools.ietf.org/html/draft-vos-silk

Coming in at 566 pages, this I-D is what the word “ginormous” was meant for… but if you look closer, you’ll see that the first 26 pages describe the SILK codec and provide the usual IETF language. The remaining 540 pages are the C source code for a reference implementation of SILK!

This is part of the work of the IETF’s “CODEC Working Group” (see “MOVING INTO THE IETF” below) to standardize on a new wideband audio codec and essentially upgrade the audio quality of the Internet. Let me lay out some background…


LAUNCHING SILK

Last year at eComm 2009, Skype’s Jonathan Christensen announced the SILK codec and that it was being released for free licensing to third-party software and hard developers. Skype made available a developer site focused on the codec:

https://developer.skype.com/silk

Christensen trumpeted these items as the strengths of SILK:

  • improving audio bandwidth going from 8 kHz to 12 kHz, meaning that a SILK conversation sounds like you are in the same room as the person you are speaking with
  • providing real-time bandwidth scalability to deal with degraded network conditions
  • balancing codec optimization between voice, music and background noise, each of which can have an impact on the overall user experience
  • delivering a robust solution that delivers a more consistent audio experience, regardless of network conditions and an individual user’s voice signature

You can watch his eComm announcement here:

or view his slides here:

As a heavy user of Skype, I can personally attest to the fact that the SILK codec, available in all the latest versions of Skype, really does provide an outstanding audio experience.


MOVING INTO THE IETF

With the SILK codec available, folks at Skype started to look at how the codec could be made an open standard so that more folks would implement it. In May 2009, Skype’s Jason Fischl started a discussion around forming a new IETF working group to produce a standardized wideband audio codec. Much discussion and several meetings followed that did lead to the creation of the CODEC Working Group within the IETF. The group, created in January 2010 and co-chaired by Peter Saint-Andre and Michael Knappe, is open to the public – anyone can join the mailing list – and the problem statement is very clear:

According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions:

1. Are optimized for use in interactive Internet applications.

2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control.

3. Can be widely implemented and easily distributed among application developers, service operators, and end users.

There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications.

There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications.

There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications.

According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience.

Now, here is a critical point:

The CODEC Working Group is *NOT* just about Skype’s SILK codec!

The CODEC WG is working to identify and standardize a wideband audio codec that could be widely used over the Internet. Skype’s SILK codec is one of the potential codec candidates, as shown on this matrix of codecs from the CODEC WG. Another strong contender is the CELT codec from the Xiph.org team. There is a Internet-Draft out now for discussion that specifies the requirements for a standardized codec:

http://tools.ietf.org/html/draft-ietf-codec-requirements

The goal of the CODEC WG is to either identify an existing codec that meets those requirements or create a new codec. Either way, the goal is to have a standardized high quality audio codec that we can all use.

For those interested, the CODEC working group will be holding its first official face-to-face meeting at IETF 77 in Ananheim, California, on March 22nd. A draft agenda has been posted.


SKYPE’S SILK SOURCE CODE

So back on Monday, March 8, a new version of the SILK Internet-Draft was published and announced on the codec mailing list. As the draft notes:

The source code for the reference implementation of the SILK codec is provided in Appendix A. This fixed-point source code is the normative specification of the codec. The corresponding text description in this document is provided for informative purposes. For more information about SILK, the patent licensing terms, and to download the source code in a convenient format, please visit [silk-website]. For any additional questions, please send an email to SILKSupport@skype.net.

This particular phrase is interesting and amusing to me:

This fixed-point source code is the normative specification of the codec.

I translate that as “the source code is the specification”.

If you do read the source code, you see Skype’s license on the code is rather open:

Copyright (c) 2006-2010, Skype Limited. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, (subject to the limitations in the disclaimer below)
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of Skype Limited, nor the names of specific
contributors, may be used to endorse or promote products derived from
this software without specific prior written permission.
NO EXPRESS OR IMPLIED LICENSES TO ANY PARTY'S PATENT RIGHTS ARE GRANTED
BY THIS LICENSE.THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Essentially it is a Skype version of the permissive “Simplified BSD License“, which I would summarize as a non-lawyer as essentially “keep the copyrights intact, don’t use Skype’s name for endorsement, and Skype is in no way responsible if bad things happen from using this code”.

Still to be seen is if there are any additional licensing terms from Skype, but overall this is a great step forward for those of us who want to see better overall audio quality on the Internet. Obviously it’s in Skype’s interest to do this so that the CODEC WG might consider SILK as the codec to standardize on versus the others or creating a new one… but still… it’s great to see. What do you all think?


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


New version of P-Charge-Info (08) Internet Draft available

Wednesday, March 3rd, 2010

FYI, a new version -08 of my P-Charge-Info Internet-Draft is now available:

http://www.ietf.org/id/draft-york-sipping-p-charge-info-08.txt

For an understanding of what P-Charge-Info is all about, read why I first wrote it, P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP, and then my update last year on the -07 draft.

Version -08 really only has a minor tweak to the ABNF notation for the “npi-value” and then a new Appendix A clarifying the npi-values and their relation to ANSI T1.113.

I am hoping that I can very shortly request IESG consideration to move this document along the path to being an RFC. The only remaining issue is that my co-author, Tolga Asveren, has brought forward a proposal for simplifying the parameters a bit. I’ve forwarded that proposal to several people I know are very interested in this draft. We’ll see where it goes from there. I’d very much like to move this along soon, so we’ll see.


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


OAuth 1.0 to be issued as an Informational RFC

Friday, February 19th, 2010

oauthlogo.pngAs a “security guy“, I have been pleased to watch the emergence of the OAuth Working Group within the IETF and the work that is underway to create an actual IETF specification for OAuth. I haven’t had time to participate, but I’m glad to see that work going on.

If you aren’t aware of OAuth, it’s basically a way that you can authorize a application or service to interact with another application or service on your behalf without giving that first application or service your user ID and password for the second service or app.

For example, if you were a Twitter user in its earlier days, every time you wanted to use another application or web service with your Twitter account, you had to give that app or service your Twitter user ID and password. There’s a security issue here in that you are entrusting your credentials to some other company or application – and trusting that they won’t share those credentials. There’s also a configuration issue in that if you change your password you then have to go to all the other services and provide the updated info. Now, with OAuth support in Twitter, when you want to add a new service to interact with your Twitter account, you are prompted to login to your Twitter account and authorize or deny the access for the new service. The key point is that the new service or application never gets your Twitter credentials. (And as another example, OAuth is what our IMified service uses to allow an automated bot to interact with your Twitter account.)

Anyway, OAuth emerged out of the developer community and now there is work underway in the IETF to create official standard specifications to help in promoting OAuth implementation. As a first step, it was announced this week that OAuth 1.0 will be published as an Informational RFC. As noted in the announcement:

The OAuth protocol was originally created by a small community of web developers from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007, and revised in June 2009 (revision A) as

published at <http://oauth.net/core/1.0a>.

This specification provides an informational documentation of OAuth Core 1.0 Revision A, addressing several errata reported since that time,

as well as numerous editorial clarifications. While this specification is not an item of the IETF’s OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track, it has been transferred to the IETF for change control by authors of the original work.

This first step will get a base level spec out so that people looking to implement OAuth will have an IETF specification they can use. The RFC hasn’t been published yet, but the draft that will be an RFC is here:

http://tools.ietf.org/html/draft-hammer-oauth

It’s good to see this work going on within the IETF and I look forward to seeing further work there. From my perspective, OAuth is a great step in helping secure connections betweens apps and services over the web… which is good for all of us as more and more moves into the cloud.


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.


IETF 77 registration now open – also includes day pass option

Monday, January 4th, 2010

ietflogo-2.jpgRegistration for the 77th meeting of the Internet Engineering Task Force (IETF) is now open. The IETF 77 event will take place March 21-26 in Anaheim, California (home of Disneyland).

Sadly, it looks like I personally will be missing this IETF meeting as I’ll be across the continent in the other home of Disney, Orlando, for VoiceCon Orlando 2010. I somehow don’t think the cross-country travel will work that week. The good news, though, is that the timezone will be such that I will be able to participate remotely. Remote participation wasn’t really an option for me with the recent IETF 76 in Japan.

One interesting point in the email announcement was that the IETF is offering essentially a “day pass” again for people who either want to just see what IETF is all about or who only care about sessions happening on a particular day. Per the email, for $200 you get:

1. Attend all sessions during any one day of the Meeting, and partake of the food and beverage during the breaks
2. You select which day to attend when you show up onsite to check-in
3. Payments may be made onsite without a late fee
4. Pass can be upgraded to a full Meeting Registration, however, late fee may apply if initial one-day payment not made before Early Bird deadline
5. Attend Sunday Tutorials at no additional charge
6. Attend Sunday Welcome Reception at no additional charge
7. Attend Wednesday and Thursday Plenaries at no additional charge

Seems like a nice option if all you just want to go to a day of sessions.

In any event, more information and the registration form can be found in links from the IETF 77 meeting page.


Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.