Posts categorized "SIP"

I'll be in Miami next week speaking at ITEXPO, Cloud Communications Summit, etc.

itexpo.jpgIf any of you will be in South Beach, Miami, next week I'll be there speaking as part of the Cloud Communications Summit and SIP Trunking Workshops. I've got a page up on Voxeo's site that shows my schedule at:
http://blogs.voxeo.com/events/itexpo-east-2011/

I know a good number of other folks from the VoIP/UC/Cloud Telecom/Voice Mashups/SIP/etc. world are all going to be down there, so I'm looking forward to catching up with some folks there.

If you are down in Miami for ITEXPO, the Cloud Communications Summit, Digium/Asterisk World or any of the other events, please do stop by and say hello... or find me down at one of the sessions I'm in (my schedule is online). You can always email me or ping me on Twitter.


If you found this post interesting or useful, please consider either:



Want to Learn About SIP? Attend the SIP Tutorial at ITEXPO (50% Discount Code)

SIP-Tutorial.jpgDo you want to learn more about the Session Initiation Protocol (SIP) and how it enables Voice over IP (VoIP) and Unified Communications? Want to learn how it works? What it does? How it can be used? How secure it is? How does SIP relate to HTML5 and what is going on with the "real-time web"?

If so, consider attending the SIP Tutorial at ITEXPO next week in South Beach, Miami, Florida, on Friday, February 4, 2011.

Taught by Dr. Alan Johnston and Dr. Henry Sinnreich, two veterans of SIP and IETF work, the day-long session covers a wide range of topics. In speaking to Alan Johnston, he said that for the first time this session next week will particularly get into some of the real-time communication coming into HTML5 and related technologies.

If you would like to attend the session you can still register. Alan passed along that the priority code "SIP" will get you a 50% discount.


If you found this post interesting or useful, please consider either:



Android 2.3 Includes SIP Stack, Near Field Communications, More

android23-sip.jpgVery cool to see that the Android 2.3 release includes a SIP stack:

The platform now includes a SIP protocol stack and framework API that lets developers build internet telephony applications. Using the API, applications can offer voice calling features without having to manage sessions, transport-level communication, or audio — these are handled transparently by the platform's SIP API and services.

The SIP API is available in the android.net.sip package. The key class is SipManager, which applications use to set up and manage SIP profiles, then initiate audio calls and receive audio calls. Once an audio call is established, applications can mute calls, turn on speaker mode, send DTMF tones, and more. Applications can also use the SipManager to create generic SIP connections.

Naturally this SIP stack is only available if the carrier and manufacturer allow it:

The platform’s underlying SIP stack and services are available on devices at the discretion of the manufacturer and associated carrier. For this reason, applications should use the isApiSupported() method to check whether SIP support is available, before exposing calling functionality to users.

Call me cynical, but I could see a number of carriers NOT allowing the SIP stack.

The Android team has also very helpfully provided a SIP demo application.

I also am intrigued by the "Near Field Communications" addition (if you don't know what NFC is, the Wikipedia entry is a good start). Looking forward to seeing what people do with that!

All in all Android 2.3 looks like a decent evolution of the platform... I'm definitely interested to see what people do with with SIP / VoIP capability. If you are an Android developer working with communications, what are you planning to do with it?


If you found this post interesting or useful, please consider either:



Today's VUC call at noon US Eastern: FREETALK Connect - Skype-connected IP-PBX

VUCIn about 40 minutes, this week's VoiP Users Conference call will start with Jim Courtney talking about the new FREETALK Connect IP-PBX. It includes:
  • Skype connectivity for all phones.
  • Auto-provisioning works with almost all models of desktop and conference IP phones
  • Install wizard configures all basic networking, telephony system and user functionality on the FREETALK Connect
  • Remote administration capabilities that enable the system to be administered from anywhere Internet access is available.

I'm intrigued by the system because it integrates an Asterisk-based IP-PBX with Skype - and is "certified" by Skype. I'm looking forward to hearing what Jim has to say about it.

If you'd like to listen live, there are regular, SIP and Skype contact phone numbers to dial into the VUC. You can also jump on #vuc on IRC to join in the text backchannel.

If you can't join live, a recording of the call will be posted to the episode's web page sometime in the next few days.


If you found this post interesting or useful, please consider either:



A Brief Primer on the Tech Behind Skype, P2PSIP and P2P Networks

Relationships between "top 50" UK PR twitterers

What is an overlay network? What's a DHT? How does a node compare to a supernode? What differentiates a "pure" peer-to-peer (P2P) system from a "hybrid" system?

UPDATE: Unfortunately, this post is no longer accurate with regard to Skype's infrastructure. After the massive Skype outage in December 2010, it was expected that Skype was exploring ways to make their system more stable and resilient. In early 2012, Skype (at that point now owned by Microsoft) was reported to have replaced much of the P2P supernode infrastructure with supernodes hosted in Microsoft data centers. Since that time we've understood that additional changes have been made for resiliency's sake. Given all that, it's hard to know exactly how Skype's infrastructure exists today. This article below does, though, provide some background into the basics of peer-to-peer (P2P) infrastructure.

I have a series of posts planned over the next few weeks related primarily to Skype and some of the changes brought about in Skype 5.0 for Windows that are interesting from a technology point-of-view - but in order to write those posts, I need to build a bit of a foundation of some of the issues and terminology used in peer-to-peer (p2p) networks.

If you are not familiar with peer-to-peer (p2p) networks and the terminology associated with them, my goal is to give you a basic background.  If you are familiar with P2P technology, well, you can probably skip this and wait for the next post :-)

Peer-to-peer vs. Client/Server Networks

For starters, let's differentiate between "peer-to-peer networks" (p2p) and more traditional networks. If you think about running, say, AOL Instant Messenger (AIM), on your computer, you install the AIM client software on your computer. When you launch the software, it connects you to the AIM servers running somewhere out on the Internet. When you send a message to another AIM user, that message goes from your client up to the AIM servers and then from there down to the recipient's client.

This is "client/server" networking and is how the majority of the Internet-based services we use are structured. We operate web servers, mail servers, file servers, etc., etc. and have local clients installed on our computers that connect to those servers. Even in many of the "cloud" services out there, we are still using a client (typically a web browser) to access services running on some big set of servers out on the Internet. (And the services may in fact be client/server-based, but with all of that being hidden in internal infrastructure.)

Peer-to-peer networks are completely different in that:

There are NO servers.

(Well... at least in "pure" P2P networks. We'll talk about hybrids later.)

Instead, every "node" on the network is a "peer" - it is both a client and a server. It acts as a client accessing resources from other peers - and acts as a server providing resources to other peers. The computers that are running the p2p software are all participating in a "p2p network" connecting the computers (nodes) together.

Overlay Network

While I've heard people lately talking about that p2p network as a "p2p cloud", the technical term is to refer to it as an "overlay network" (or "network overlay" or just "overlay"). The idea is pretty straightforward... you are running software on your computer that "joins" a network that exists on top of the actual Internet connections. Here's a picture of how it might look:

overlaynetwork.jpg

The "Internet" is in fact a collection of top level Internet Service Providers ("ISPs") who run the "backbone" of the Internet and connect out to 2nd tier ISPs who connect to 3rd tier ISPs who connect to... etc., etc. until you actually get down to the network drop or wireless service you use to get access for you PC (using "PC" generically here for a computer... could be Windows, Mac, Linux, whatever). Everything is all interconnected via IP addresses and running the TCP/IP protocol suite at the networking layer.

The "overlay network" is created on top of that IP network by PCs running the P2P software. They connect to each other and communicate with each other regardless of what the underlying network infrastructure actually looks like.

Now, I've shown it in the drawing as a nice somewhat circular ring because it was convenient to do so. In reality the picture would undoubtedly be a whole lot messier - but logically it would still function a lot like a ring in most P2P networks. (And note that some people do talk about an overlay networking being a "p2p ring".)

Distributed Hash Tables (DHTs)

A question, of course, is ... how do those peers know where each other are? If the overlay network is on top of the IP network... still, ultimately the data connections have to happen over IP - how does a peer know where to send packets?

Now this topic gets into a whole area of research that network geeks like me may find absolutely fascinating... but everyone else may find their eyes glazing over.

Suffice it to say that there are a whole number of different algorithms for building p2p networks, and most today use some form of a distributed hash table (DHT). The idea is that you have some piece of information, like my user name, for which you want to look up other information such as how to reach me. Your P2P software performs a "hash" on that info (called the "key") and winds up at an address for that information inside the overlay network. It then queries the overlay network and the node responsible for that "address" responds back with the requested information (the "value").

Think of a DHT as a giant distributed database of "key / value pairs". (And in fact some large distributed database systems use DHTs.)

There is a LOT more I could get into... but that would quickly take this out of "A Basic Primer". Those wanting more info should check out the DHT entries on Wikipedia and the P2P Wiki, both of which are good. I mention DHTs here primarily because any time you go looking for P2P info on the net, you pretty soon wind up reading about DHTs.

Service/Resource Discovery

If every peer can act as a server, how do other peers know what services a given peer can offer? In our real-time communication world, one peer might have a PSTN gateway connected to it. Or maybe an automated attendant... or a voicemail server. Or maybe it's running on a mobile client with reduced capabilities.

One challenge in a P2P network is to learn what resources each node has. This is typically referred to as "resource discovery" and again, different P2P networks have different methods of solving this issue.

Directory

Related to resource discovery is the whole "directory" issue - how do you find other users? If you think of Skype - or any P2P communication system - if I want to call or IM someone, how do I know where they are in the P2P network?

Enrollment / Authorization / Authentication

There are two security-related issues that come up (well, there are many but two key ones). One is - how does a new node join the p2p network? And the second is - how does an existing node that dropped out of the p2p network (perhaps going offline) get authorized to re-join the network?

Some P2P systems refer to this first issue as one of "enrollment." How does a node "enroll" in the p2p overlay network?

The second question is one of authorization / authentication of the node that it is allowed to join the p2p network.

Again, there are multiple ways to solve this issue including, at least in Skype's case, of adding in some servers to the mix to perform these functions.

Churn

A fundamental challenge of any P2P network is how to deal with the "churn" of nodes dropping in and out of the overlay network. For instance, as computers go offline and then come back online, they leave the overlay network and then rejoin. Different overlay network topologies have different strategies for coping with churn and minimizing its impact.

Nodes vs "Supernodes"

A second fundamental challenge for P2P networks is our dear old friend "Network Address Translation" (NAT) and all the related firewall fun. Given that a node behind a firewall cannot directly communicate with a node behind another firewall, how do they get connected?

The idea is that you have another network node that is not behind a firewall that can act as a relay between the two nodes behind firewalls. In Skype's terminology, these relay nodes are referred to as "supernodes".

simplesupernode.jpg

UPDATE: Shortly after I published this post, several friends suggested that I was making this perhaps too basic with regard to Skype. In fact, several deep and long posts could easily be written about Skype's supernode architecture as it is quite fascinating.

The point I was trying to make was that for nodes behind NAT/firewalls to communicate with other nodes behind NAT/firewalls, there needs to be some node outside of firewalls - on the public Internet - that can broker the communication between the endpoints.

In the case of Skype, we typically refer generically to those public nodes as "supernodes". In fact, the nodes known as "supernodes" perform the somewhat limited functions of connecting nodes together, providing a distributed database and choosing appropriate nodes to act as "relay nodes" when necessary.

These "relay nodes" are, in turn, the ones that perform the actual relaying of calls, messages, packets when direct connection is not possible. It is possible that these relay nodes could be located behind a NAT/firewall as the supernodes are connected to them and using them essentially to offload processing. Skype provides more info (including how to specify that your systems not be used as supernodes) in the IT Administrator's Guide I link to in the resources below.

In the IETF world of SIP, this external connection function is performed by either STUN or TURN servers (and that, too, could take up several blog posts).

"Pure" vs Hybrid P2P Networks

In an ideal world, a "pure" P2P network has no servers whatsoever. Every node on the network is a peer and functions as both a client and a server.

Sometimes, though, reality intrudes. Sometimes servers may need to be introduced into the mix in order to provide specific services for performance, security or other reasons. For instance, in Skype's case the general understanding is that servers are used for enrollment (to have a Skype client join the P2P overlay network for the first time), for some degree of authentication and also for connections out to the PSTN.

Networks that introduce some level of servers are typically called "hybrid" p2p networks.

That should be enough...

... for me to get started with my articles. I hope this was helpful - and if you have questions about items here or additional points you think I should mention, please feel free to leave them as comments.


Resources

Lots of good info out there about P2P networks in general... here are some you may find useful:

If you have other suggestions, please feel free to send them along.


Flickr credit: porternovelli - and yes, this image really has nothing to do with P2P networks - it's a graph of top PR Twitterers - but it could be for a P2P network... and in a way all of those Twitterers are an overlay network ;-)


If you found this post interesting or useful, please consider either:



NetworkWorld interviews SIP pioneer and now Skyper Jonathan Rosenberg

jdr.jpg This week Network World ran a great interview with Jonathan Rosenberg about his new role at Skype. Jonathan is now the "Chief Technology Strategist" at Skype, but he's known in the industry as one of the co-authors of the original RFC 3261 that defines the Session Initiation Protocol (SIP) and also for his many years working at Cisco. He's been extremely active within the IETF, writing a seriously large quantity of Internet-Drafts. I think, in fact, I first met JDR at an IETF meeting... and subsequently was on at least one panel with him (I think a VoiceCon or Interop in New York).

It's been interesting to watch Skype accumulate more and more people with strong SIP backgrounds, and hiring Jonathan was definitely an interesting - and good - move on Skype's part.

I don't know that the Network World interview broke any amazing new ground for those of us who have been watching Skype closely, but if you haven't been paying attention to Skype, Jonathan gives a great view into what the company has been doing lately and where it is going. It is definitely worth a read.


If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.



CounterPath launches SIP/VoIP softphone for iPhone/iPad and brings enterprise to mobile

Have you wished you could easily extend your corporate IP-PBX to your iPhone? Or have you wanted a good SIP softphone for your iPhone that you could use for testing systems? Or do you just like new shiny iPhone and iPad apps?

This week long-time softphone maker CounterPath Corp. released their "Bria iPhone Edition" and for $3.99 it's a great app to have! Ever since I learned about it a couple of days ago, I've been playing with it and this morning I posted a video review as Emerging Tech Talk #51. I show how I've connected the app to Voxeo's corporate IP-PBX, how I can use it to make calls to both regular phone numbers and also SIP URIs, how it works with the iPhone's address book and also how I can use it on the iPad. You can view the 7-minute video here:

Now my friend Alec Saunders spoke with someone at CounterPath and published a great post yesterday discussing some of the limitations and the future plans that CounterPath has. Definitely worth a read - and I'm looking forward to some of those plans! (Like wideband codecs and multi-tasking support.)

As he notes, this Bria app is not specifically designed for the iPad, but as I show in the video it can be used on the iPad, subject to the standard pixelation that happens with iPhone apps on the iPad. (And in tomorrow's video podcast, I'll talk about how you can connect a USB headset to the iPad! ;-)

Here are some screenshots from the app:

bria-iphone-registration.jpg bria-iphone-keypad.jpg bria-iphone-incallcontrols.jpg bria-iphone-incomingcall.jpg bria-iphone-callhistory.jpg bria-iphone-settings.jpg

So far I'm quite impressed! You can get the Bria softphone from the AppStore on your iPhone or iPad.


If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.



Speaking at ITEXPO / Cloud Communications Summit Jan 20-22 in Miami...

itexpo.jpgOn Monday I'm heading down to Voxeo's corporate headquarters in Orlando, FL, but the week after that I'll be heading down to ITEXPO in Miami Beach, FL, where several of us from Voxeo will be speaking

Ironically, I won't be speaking actually at the formal "ITEXPO", but rather at the Ingate SIP Trunking Seminars and then at a new "Cloud Communications Summit" coordinated by Thomas Howe. Somehow my sessions wound up back-to-back... I'm just hoping the rooms aren't too far apart!

Voxeo will also have a couple of exciting announcements, so it should be a great event. Here's my speaking schedule:

Wednesday, January 20, 2010

11:30-12:00, Ingate SIP Trunking Seminars, Dan York

“The Enterprise Edge and Security”

Representing the VoIP Security Alliance (VOIPSA), Dan York will give an overview of security concerns related to Unified Communications and VoIP with a focus on SIP trunking.

12:00-1:30pm, The Cloud Communications Summit, Dan York

“Cloud Telephony for the Enterprise”

This session discusses tradeoffs in deploying communications applications behind the firewall, with a hosted partner or through elastic mechanisms such as Amazon’s EC2.

Other speakers planned for this session are Troy Davis, CEO of CloudVox, and Evan Cooke, Co-Founder and CTO of Twilio. Thomas Howe will moderate the session.

If you are going to be at ITEXPO, drop me a line. I'll have some of my podcasting gear and other equipment, so I intend to be producing some content from the show floor. I'll of course be tweeting, both as @danyork and @voxeo

See (some of) you there..


If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.



Of Skype, SIP, P2P and P2PSIP...

skype_logo.pngOver on Voxeo's Speaking of Standards blog, I put up a post today on:
Could Skype realistically replace its P2P algorithm with P2PSIP?

I decided to write it after reading the comments on Phil Wolff's post last week over on Skype Journal... mostly to talk a bit more about what P2PSIP is and how it compares to what Skype is using now.

While it's interesting to talk about on a technical level - and I admit to a complete fascination with the technology behind P2P networks - the reality is that none of us really know anything about what Skype is up to. :-)


If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.



Skype takes a SIP of Cisco with UC500 Skype For SIP certification

skypeforsip.jpgIt's been a busy month for the folks in the Skype For SIP project. First, back on September 9, Skype announced ShoreTel interoperability. Then last week on September 17, Skype announced interop with the open source SIPFoundry sipXecs product.

Today, though, is Skype's biggest announcement yet - they are announcing the certification of Cisco's Unified Communications 500 Series for Small Business as interoperable with Skype For SIP.

Beyond simply the interop, what's perhaps more interesting is to note the direct Cisco involvement with this news release (through a quote). Looking at the overall industry, it's interesting to see Cisco and Skype connecting. I admit that I haven't studied Cisco's UC500 product much at all, although per the news release it sounds like they are doing some interesting things with it:

The Cisco Unified Communications 500 Series platform is part of Cisco’s Smart Business Communications System which continues to expand having just added a new set of IP phones with high definition audio, a unified threat management device as well as support for third party application integration, including products from healthcare, automotive and insurance industries.

Congrats to both Skype and Cisco on this announcement. I expect we'll be seeing more of these announcements in the weeks and months ahead as Skype continues to aggressively court partners. The Skype For SIP offering does provide some useful functionality for on-premise IP-PBX systems:

  • Ability to receive inbound calls from Skype users
  • Ability to receive inbound calls from PSTN users through "online numbers" (formerly SkypeIn)
  • Ability to place outbound calls to PSTN users

The Online Number functionality is particularly interesting as you can easily set up any series of numbers in other parts of the world that ring back into your IP-PBX. Sure, you can do that with any other SIP trunking provider, too, but Skype makes it incredibly easy to provision those numbers - and for a very low annual cost, too. Making your IP-PBX accessible to all the Skype users, too, is quite powerful.

Now if only you could make outbound calls to Skype users... (NOT possible with Skype For SIP, but possible with Skype For Asterisk).

Anyway, congrats again to Skype and Cisco on this announcement.


If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.