Archive for the ‘SIP’ Category

SIPit 27 announced for Nov 15-19, 2010, in Taiwan

Tuesday, August 31st, 2010

SIPit27.jpgThe SIP Forum today announced that the next SIPit interoperability test event will be held November 15-19, 2010, in Taiwan, Taipei.  A website for the event is now up at:

http://www.etsi.org/plugtests/SIPit27/SIPit27.htm

As I’ve written about in the past and recorded a video interview about, these SIPit events are critical, in my opinion, to helping drive the overall adoption of SIP and open standards in communication systems.

If you are a creator of software or hardware devices that use the SIP protocol, SIPit events are a great way to test how well your equipment works with other SIP implementations. There is a fee, but it’s small for the week-long testing you get to do. More info can be found on the registration page.

P.S. You’ll note that this SIPit event is the week following IETF 79 in Beijing, China… so if you can make the travel work, it’s a great way to combine two weeks of open standards / SIP – related events.


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.


SIPit 26 happens May 17-21 in Stockholm, Sweden – SIP interop testing… and IPv6, too!

Tuesday, April 27th, 2010

sipit26logo.jpgDo you create hardware or software that uses the SIP protocol? If so, what are you doing the week of May 17-21, 2010? Over in Stockholm, Sweden, many vendors will be gathering for the SIPit 26 interoperability testing event – and registration is still open if you are interested in attending. I’ve written in the past about SIPit events and even recorded a video interview last fall about why SIP interop matters. These events are important… and if you develop SIP-related software, I strongly encourage you to attend.

This SIPit26 event is, as always, organized by the SIP Forum and hosted by Edvina in cooperation with Tandberg, Intertex, Ingate and .se! More info can be found at the SIPit 26 site at:

http://sipit.edvina.se/

Courtesy of organizer Olle Johansson, this SIPit 26 event can also be found on Twitter, Facebook and LinkedIn. Olle, coming out of the Asterisk community, also wrote up a great post on “why SIP testing is important to Asterisk and to you“… the reasons he lays out are the same for really any of us working with SIP-related products and services.

This particular SIPit 26 event will have an additional aspect to it… the SIP Forum has partnered with the IPv6 Forum to promote testing of SIP over IPv6. Actually, the partnership is larger than that… but a specific outcome is that part of the drive of SIPit 26 will be to test how well SIP implementations work over IPv6. All good stuff… and help move along real-time communication over the Internet.

If you do have a SIP-based product or service, check out SIPit 26 and get there if you can… it’s a great opportunity to test your products and see how they work with other SIP-based products and services.


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.


Yes, I *DO* want a Universal Presence API! (re: my VoiceCon panel)

Tuesday, April 20th, 2010

In our panel last month at VoiceCon titled “Challenges in Achieving the Promise of Presence“, there came a point that Jon Alperin of Avaya, sitting in the audience, nicely summarized in a tweet:

voiceconpresence.jpg

Yes, I DO want a “universal API” for presence!

You see, here’s the thing… I was sitting on stage with representatives of the providers of enterprise presence systems. There was Microsoft (with OCS), IBM (with Sametime), Cisco (with various products) and Avaya (with Aura). I was the only representative of a consumer of the presence information from those systems.

Here’s the simple case of what I want to do – I want to take our Prophecy platform and install it on the premise of an enterprise. In the real simple case, Prophecy might provide the inbound IVR for the enterprise. A call comes in, an application runs on Prophecy. At some point it is time to transfer the caller to a live person… perhaps the caller requested it, perhaps they completed a series of questions that gathered initial data. For the next step of my application running on Prophecy…

I want to route the caller to an appropriate person based on rich presence information!

I want to build my app so that I can identify who might be available, what skills they might have, etc., and then connect the caller to that person. Provides better customer service, gets customers the info they want quicker, makes happier customers… it’s a win for everyone.

And I can do this today… if I am willing to dive deep and write the app for a specific system. I could make it work with Microsoft’s OCS… or IBM’s Sametime… or Cisco’s Jabber products… or Avaya Aura… I could do this.

But here’s the issue:

I don’t want to have to write to separate APIs to consume presence from each vendor’s system!

I want ONE presence API or protocol that I can use to interoperate with ALL of the various enterprise presence providers.

Yes, we have SIP/SIMPLE and XMPP today… and we can and do support those in our platforms. And if all the aforementioned vendors completely supported those open standards, well, it would be a wonderful world…. but while the vendors do support SIP/SIMPLE and XMPP to varying degrees, it’s not clear that I can really get all the info I want and need to make the kind of routing decisions I want to do.

And that’s just the simple case… imagine that I want to use our Prophecy Hosting platform to have an app in the cloud that then interacts with an enterprise premise IP-PBX and consumes presence info from that system. How do you securely consume the premise presence in the hosted cloud?

Or what if I want to go multi-channel and fire an IM message to someone based on information provided by a caller? (Perhaps to find someone to call the person back.) In our platform, how can I consume presence information from across different modes of communication from within the enterprise?

So, yes, I want a universal API for presence that makes this all easy to do within a platform and using communication services from multiple vendors.

How about you? Do you want a universal presence API to?


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.


Slides from SIP Tutorial at VoiceCon Orlando 2010

Tuesday, March 30th, 2010

voiceconsiptutorial.jpgLast week at VoiceCon Orlando 2010 I had a great time giving a 3-hour tutorial on the Session Initiation Protocol (SIP). Over 200 people attended and made it a very interactive session with lots of great questions and comments. The abstract for this session was:

SIP (Session Initiation Protocol) has become the dominant protocol for IP communications. This workshop explains SIP — how it works, the major issues impacting deployments and how SIP will evolve in the future.

The session focuses on the technical aspects of SIP and how it is used. It analyzes in detail the major components of SIP architecture, SIP addressing and registration, session establishment, SIP message routing and connecting SIP across the PSTN. You will learn about SIP extensions and how SIMPLE works for IM/presence. The workshop also examines some of the challenges SIP faces, including NAT traversal (and the tools developed to cope with it: STUN, TURN and ICE) and security. The tutorial concludes with an assessment of how SIP may evolve and its role in peer-to-peer environments. You will receive an inventory of SIP resources—books, papers and organizations.

The slides from the session are available at SlideShare and embedded below – I do want to note that my slides were based on a presentation that David Bryan originally created (and are used with his permission). David has taught this tutorial in the past, but was out at IETF 77 last week as a Working Group chair. I built off of David’s slides, added a good number of network diagrams, tweaked a bunch of his text, changed/modified/deleted slides and generally made it into the presentation I gave.

Enjoy the presentation…


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.


Want to learn about SIP? Come to my SIP Tutorial at VoiceCon March 22

Thursday, March 4th, 2010

Want to learn about the Session Initiation Protocol (SIP)? Would you like to understand how the SIP protocol works and why it is the dominant open standard for communication today? Want to understand the challenges SIP faces and what’s being done to overcome them?

If so… and if you will be attending VoiceCon in Orlando, FL, March 22-25, you’ll be able to join my (Dan York) 3-hour tutorial on “SIP Fundamentals and Prospects” on Tuesday, March 23rd, from 2-5pm. The abstract VoiceCon has posted is this:

SIP (Session Initiation Protocol) has become the dominant protocol for IP communications. This workshop explains SIP — how it works, the major issues impacting deployments and how SIP will evolve in the future.

The session focuses on the technical aspects of SIP and how it is used. It analyzes in detail the major components of SIP architecture, SIP addressing and registration, session establishment, SIP message routing and connecting SIP across the PSTN. You will learn about SIP extensions and how SIMPLE works for IM/presence. The workshop also examines some of the challenges SIP faces, including NAT traversal (and the tools developed to cope with it: STUN, TURN and ICE) and security. The tutorial concludes with an assessment of how SIP may evolve and its role in peer-to-peer environments. You will receive an inventory of SIP resources—books, papers and organizations.

I’m very much looking forward to the session… although I still do have some work to finish up on the materials. For the past while my friend David Bryan has given these tutorials at VoiceCon events, but given that he also chairs IETF working groups he would need to clone himself since this VoiceCon is the same week as IETF 77 in Anaheim, California. It’s a wee bit hard to flip between coasts… and as anyone who has ever been to an IETF event knows, the meetings are intense and he is needed out there.

If you can’t attend VoiceCon this year, I’ll probably do some SIP tutorial webinars in the future and perhaps you’ll see something popping up over at Voxeo University… stay tuned. And if you are at VoiceCon, please do stop by and say hello… or send me an email in advance letting me know.


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.


Ars Technica launches article series introducing the SIP protocol

Monday, January 25th, 2010

arstechnica.jpgOver at Ars Technica, author Gilad Shaham has started a series of posts about the SIP protocol. So far the two installments are:

The first article gives some background about SIP and goes on to explain how SIP prevailed over H.323 as the dominant standard for VoIP traffic today. The second article goes through the details of basic SIP messaging and explains how SIP proxy servers and registrars fit into the picture, complete with some diagrams that nicely explain call flows. The author indicates that the next article in the series will dive into SIP calls in more detail.

If you are new to VoIP or to the SIP protocol, both of these articles are great tutorials that will help you learn more about what SIP is all about. If you are familiar with SIP, you still may find some interesting tidbits mixed into the text. The articles are good to see and I’m looking forward to reading the next installments!


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.


Guest post: David Bryan responds on P2P, P2PSIP and Skype

Monday, October 26th, 2009

NOTE: David Bryan, co-chair of the IETF’s P2PSIP Working Group, left this text as a comment to my earlier post about P2PSIP and Skype. Given it’s length and great content, I thought it should run as a guest post and David was fine with that. The text below is entirely his.


So a few points, in no particular order:

Lee mentioned (as have others before) that P2PSIP is “copy-cat Skype”. This always bothers me, not because we came first (we certainly didn’t) but because it wasn’t my vision for P2PSIP (although others certainly had that view) . When I came up with P2PSIP and brought it to the IETF, I wanted to do things SIP couldn’t do at all. SIP can theoretically build a system that looks like Skype. To me, the interesting areas for P2PSIP were distributed softswitches/corporate IM (config-free small office, etc.), rapid response (quickly set up a communications system after a natural disaster), ad-hoc clusters for IM/app sharing (think Google wave away from the Internet), and vendors adding voice to apps without becoming an ISP. You could do a Skype-like service with P2PSIP (sort of: see below) but that wasn’t really the idea that got me started creating P2PSIP.

To me, Skype’s success was solving the NAT issue and getting the user experience right. P2P was a means to an end/efficiency multiplier, but not the reason for the success. Skype just worked. SIP’s major flaw is embedded IP addresses. Skype avoids this, uses media relays (P2P, but could have been centralized) and “falls back” (in the worst case) to tunneling over port 80. Users love this. Administrators and protocol purists hate it as it breaks traffic characterization, shaping, etc. Skype’s closed garden (one protocol stack) also ensured things just worked. Closed gardens and HTTP tunnels are at odds with the SIP goal of vendor/carrier interoperability. The two achieve different goals. (Today, many folks believe ICE with ISP-provided relays has addressed the SIP NAT problem. It looks promising, but until we have a Skype-sized Internet deployment, some say the jury is out. Time will tell.)

You could theoretically deliver a Skype-like experience with either a SIP or P2PSIP solution. Pure P2PSIP is very decentralized (every node is a peer and central servers are only used for obtaining a certificate), so you would need a hybrid approach if you want to maintain customer control. You could also use regular SIP with ICE, and many, many servers if you could solve the scalability problems. The best approach might be conventional SIP between the endpoints and a cloud of servers, with the servers sharing information using P2P. This ends up looking much like a SIP version of Skype’s super-peer model, executed in the cloud.

All this still begs the question of what happens to the Skype ecosystem of hardware, etc. If you go SIP, what do you break in the process? As Dan York and Shidan Gouran point out, Skype has many options, lots of great engineers, and lots of cash, but nobody outside of Skype knows what they will do.

As an aside to Lee’s comment on P2PSIP as a standard (it is fair to say adoption in product has been very slow, I’m sorry to say): The standard is moving, just at the (glacial) pace of standards, which can be frustrating for idea guys like Lee or I. In the early days, P2PSIP had lots of ideas, chatter, and excited non-standards folks, so work moved quickly. Today, with an accepted draft in progress and a more mainstream standards audience, iterations have slowed. That said, things are moving, there is strong interest, and a lot of hard work by the editors and participants.

My biggest worry is the protocol becoming too cumbersome. We are building a very flexible, universal DHT protocol with mandatory ICE and TLS/DTLS security. This is great for some scenarios, but overkill for others (ad-hoc, for example), and I worry the bulk may make it unsuitable for some of the scenarios I first imagined. I think many of these may migrate to the cloud. DHTs will be used, but as a means to distribute data among servers, not all the way to the edge as I first anticipated. Things change. Progress is good. I’m very excited to see how DHT principals in the cloud might solve many of the problems posed of a pure P2P approach. (eComm talk for SF, Lee?)


David Bryan is co-chair of the IETF P2PSIP Working Group and maintainer of http://www.p2psip.org/ More about David can be found at http://www.ethernot.org/ or on Twitter at @davidbryan.



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.


Could Skype realistically replace its P2P algorithm with P2PSIP?

Monday, October 19th, 2009

skypelogo.jpgCould Skype realistically replace its proprietary peer-to-peer (P2P) algorithm with P2PSIP?

Over on his Skype Journal site, Phil Wolff shows another example of why I’ve always followed the mantra “Never put online, in any form, anything you don’t want to appear on the front page of a news site” when Phil shows what was obviously intended to be a private email about ideas of what to do with Skype. (This has all surfaced as part of Skype’s ongoing legal battles on a number of different fronts, which I’m not going to dive into here.)

Per Phil’s article, the idea was this:

- buy skype, replace p2p with SIP (standard-based, open, can interwork with other VoIP systems – like the Cisco phones)

What’s perhaps most interesting about Phil’s post, though, were the comments that started with Lee Dryburgh of eComm fame weighing in saying that it makes ZERO sense (technically) and then went on from there. Lee and Shidan Gouran then got into a bit of a discussion in the comments.

Leaving the personal jabs aside, it’s actually an interesting discussion to consider. (And knowing both Lee and Shidan, I’m sure that they actually agree on way more than they disagree on.)

WHAT IS P2PSIP?

Lee’s right that there’s a difference between “SIP” as a protocol and all the overlays, DHTs and everything else that goes with “P2P” protocols. To Lee’s points about the difference, though, that is precisely what the “P2PSIP” work happening within the P2PSIP Working Group of the IETF is addressing. For those who want to read the proposed P2PSIP protocol itself, the latest draft is here in two parts:

http://tools.ietf.org/html/draft-ietf-p2psip-base
http://tools.ietf.org/html/draft-ietf-p2psip-sip

The first draft defines a P2P protocol called “REsource LOcation And Discovery (RELOAD)”. The second draft explains how RELOAD can be used with SIP.

To Lee’s points, RELOAD is a separate protocol from “SIP”. Now, RELOAD does indeed use a Chord-based DHT… though, the best place to start is probably the Architecture section at the beginning to understand how the pieces fit together.

So what is being called “P2PSIP” within the IETF is more this:

P2PSIP = SIP + P2P-protocol

More info about all things related to P2PSIP can be found at a great site maintained by David Bryan, co-chair of the IETF P2PSIP Working Group:

http://www.p2psip.org/

I’ve also written more about “P2PSIP” here on this blog, including this piece back in May 2008 about why I believe P2PSIP is important.

BUT COULD SKYPE REALLY USE P2PSIP?

Probably.

The question is really –

Could Skype swap out it’s proprietary P2P protocol for the P2P protocol proposed as part of P2PSIP?

That’s the larger issue. As Lee points out, SIP is “just” a signaling protocol for setting up communication sessions. The decentralized P2P nature of Skype is due to its proprietary P2P algorithm, not its session signaling.

That’s the key point, really – there are two different layers of communication going on here:

  1. networking between the endpoints (the P2P layer)
  2. call and chat signaling setup, modification, tear-down, etc.

The P2P layer is probably the hardest one to replace. The signaling layer is probably easier as there are any number of choices out there today, including SIP, XMPP and others.

Plus, as Shidan Gouran accurately points out, Skype’s current system is NOT entirely decentralized/P2P. It is much more of a hybrid system. There are centralized enrollment/authentication servers (as we learned in the multi-day outage a few years back), a centralized directory (although pieces of that could potentially be spread across the P2P overlay) and of course centralized PSTN interconnectivity.

Could all that be replaced with a different P2P protocol? Probably… although certainly not without a lot of work – and also the severe headaches of dealing with backward compatibility and getting the huge installed base of Skype users to upgrade to a new client.

Could that protocol be P2PSIP? Again, probably. The advantage would be that the SIP layer would give Skype interoperability with other systems, networks, devices, etc.

THE OTHER OPTION

I’d note, too, that the email Phil quotes says “replace p2p with SIP”. It does not say “replace p2p with p2psip”. There very well could be folks thinking of dumping the whole proprietary P2P protocol and dumping P2P in general and migrating to be a “standard” kind of SIP system like Gizmo (yes, which Skype has been rumored to be buying) or any of the other SIP-based consumer softphone services out there.

Sure, I’m sure they could technically do it. As an open standards guy, it would be great on one level in that it would help move us along toward the great big “interconnect” many of us so want to see. It would, though, require a much different architecture than what Skype has used so successfully today.

SO….

Will Skype replace their proprietary protocol with P2PSIP?

Ha… I haven’t a clue… nor does anyone else outside those walls. All we can do is have moments of technical amusement like this speculating on the possibility.

As I’ve noted before, Skype has been hiring in this year some great folks with lots of SIP experience… but… Skype is also a HUGE user of SIP on its backend for PSTN interconnectivity… plus they rolled out their Skype for SIP program this year…. so they have lots going on related to SIP.

We’ll see… all we can really say is that the time ahead will continue to be an interesting one for all things related to Skype…


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.