All three sessions are being held in St. Georges 108 (in the atrium of the Gaylord Palms)
Pre-registration is requested – Register Me!
]]>Far exceeding the organizer’s expectations, the Lync Conference sold out weeks before the event with over 1,000 paid attendees. (Based on the badge swapping in the hotel foyer, there must have been another 300 people “around the fringes”.) The event was an interesting mix of roughly 1/3 end-customers, another 1/3 resellers/partners and 1/3 vendors, analysts and press - all mixed into hours of great sessions, keynotes and exposition space. What does this mean? Lync has arrived and it is HOT.
We at AudioCodes used the event to kick-off our One Voice for Microsoft Lync branding campaign, featuring a new informational video that was hard to miss on our giant video screen. Feedback from the analysts and customers was very positive – the value of one source for the network elements, services and support is clear.
The AudioCodes 420HD, 430HD and 440HD IP phones were quite the hit with the attendees. Most notably was a “phone premonition” by the popular blogger Matt Landis foreseeing the arrival our 440HD phone. (I’m personally pitching to our executives that we informally call our 440HD “the Landis Phone” going forward.)
My session titled “Avoiding the Pilot Trap” was a hit at the show. Featuring an end-customer presentation from Jeff Bryngelson, Network Manager at American Axle & Manufacturing and a partner perspective from Benjamin Tosado, Principle at Conquest Technology Services, the session discussed some of the challenges that IT Managers and Administrators run into when their Lync pilot projects run into troubles and some first-hand tips on how to avoid a similar fate. Even the critical consultant Sheila McGee-Smith gave us a “best session of the conference” twitter nod for including real customers to share their stories. You can view a recording of the session on YouTube.
AudioCodes, Plantronics, Intelepeer and ScanSource Communications collaborated to organize the first ever “Voice LyncUP”, a social event that cruised the San Diego harbor on Tuesday evening. The event brought together close to 300 end-customer, partners and sponsors out on a cool and windy evening for an opportunity to socialize and share their Lync experiences. We’re looking forward to a bigger and better event next year with more sponsors and attendees.
And most importantly, the event gave us an opportunity to meet, collaborate and listen to a number of our current and prospective customers. Having real eye-to-eye discussions about the needs and wants for business adoption of Lync is impossible to put into words. We left with a new appreciation of what has been accomplished and what is to come from some of the early adopters and highly innovative community that makes up the Lync ecosystem.
One final thought – for those of us that attended this first-ever Lync Conference event, I suspect there will be a day in the future when we say “I was there when….” Looking forward to next year.
You can reach Alan at: alan.percy@audiocodes.com
]]>Image via Wikipedia
When thinking about the education market, it's easy to envision a lab full of graduate students, building "the next Google" in their labs - tirelessly coding and tweaking their invention for the masses. Often these young fresh minds develop incredible new technologies (including much of our communications infrastructure we use every day). However, the reality of communications infrastructure within education is often very different. Most educational institutions are strapped for cash, being sensitive to spend the public or private funding very carefully. It's not uncommon to find schools and universities still using 20 year old telephone equipment and beige wall phones in the class rooms.Image via Wikipedia
I just had the pleasure of wrapping up another great case study with Experient, who are developing the ever-important 9-1-1 emergency services application for small governments.http://www.audiocodes.com/case-studies/experient-case-study
As a result of these issues and the need to integrate SIP-based communications systems with a wide range of SIP Trunking service providers, a whole new category of customer premise equipment has recently evolved--the Enterprise Session Border Controller (E-SBC). The E-SBC is designed to be located on the customer premise and sit between the Local Area Network and the external Wide Area Network. Unlike the larger and more complex carrier-oriented Session Border Controller (SBC), the E-SBC is "right-sized" for a range of medium and large enterprises.
Unique functions of an E-SBC include:
Security: Often the first attribute to get mentioned about any SBC. Unlike a firewall, both carrier-class and enterprise-SBCs operate at OSI layers 3 and 4, interpreting the SIP messages and using the information gleaned from the session negotiation, to make intelligent decisions about which request is valid and which message is part of an attack. E-SBCs offer a "front guard" that protects the business network from possible attacks that originate from outside the business (the Internet), elsewhere on the WAN (the carrier) or within the business (an inside job). Stateful packet inspection, Access Control Lists, Topology hiding and Application Layer Firewall functions help keep the bad guys out and let the trusted parties in. Other facets of security include encryption--allowing the SIP sessions outside the business to be fully encrypted without the cost of having encryption on every device or system within the network.
Interoperability: sometimes forgotten, but equally important is the ability to integrate different SIP-based systems from different vendors or vintages with a range of SIP Trunking carriers. As a result of the wide range of protocol options within the RFC-3261 SIP specification, two systems can be completely within specification, but unable to communicate. SIP mediation is often required to convert from one vendor's version of SIP to another. This is especially important as larger enterprises integrate numerous different SIP systems together due to acquisitions, or that may have been bought at different times. An E-SBC eliminates this issue by implementing a back-to-back user agent, essentially terminating one SIP session (using one set of rules) and establishing another session (with a different set of rules), interconnecting previously incompatible systems. Having an interoperability solution is key in maintaining choice for the business and eliminating vendor "lock-in" commonly found with large "standard, but closed" communications systems.
NAT Traversal: one of the big benefits of SIP based communications systems is the ability to put phones in employees' home offices, hotel rooms, etc. for anywhere-anytime communications. To do this, the communications system must be able to traverse the Network Address Translation (NAT) function found at the far end--a built feature found in most home and small business routers. Enabling the remote phones and workstations requires logic to deal with the IP address changes and port number re-assignments that are the result of the far-end router NAT.
Survivability: this is a new twist that some early market trials identified as an issue with decision makers. Basically, buyers need a "CYA" or back-up plan that will allow the business to continue to operate if there are issues with the SIP Trunks. This may be just during the cut-over period, or part of a longer-term disaster recovery plan. The most logical back-up to SIP Trunks are TDM trunks. Not necessarily a one-for-one backup, but a reduced number of TDM trunks that would be able to stand in and allow for emergency or limited service calling. Until recently, this required a separate media gateway that was installed next to the E-SBC and a SIP Proxy to make decisions about when and where to direct the traffic to the TDM trunks. Fortunately, appliances that combine the three capabilities (E-SBC, Gateway and Proxy) together in one device are now appearing on the market, eliminating the costs and shelf space needed for the three separate devices.
As the adoption of SIP-based IP-PBXs and Unified Communications systems grows along with SIP Trunking, an Enterprise Session Border Controller (E-SBC) will become a common tool that network designers use to protect and interconnect their communications.
This is why the time was right for AudioCodes to launch our E-SBC product line, based on the popular Mediant 800, Mediant 1000 and Mediant 3000 hardware platforms.
For a more detailed look at the E-SBC and it's role in enterprise communications, view the on-demand webinar titled "SIP Trunking - Security, Survivability and Interoperability"
For more information on the products, see: www.audiocodes.com/e-sbc
So how do we break the almost infinite cycle of continuous interoperability testing between the growing number of hardware vendors, software applications and carriers?
One approach that immediately comes to mind is to define a "gold standard" that each of the market participants can test against, and create a predictable level of interoperability assurance between systems. As one of my readers duly noted, this is the driving vision of the SIP Forum, and their SIPconnect effort, trying to make SIP Trunking interoperability more predictable. The SIPconnect Technical Recommendation 1.0 specifies the interface between a SIP-enabled Service Provider to a SIP-enabled Enterprise Network (aka "SIP Trunks"). The specification essentially narrows the hundreds of valid options within SIP to a defined set for one application, the replacement of legacy PRI circuits. So far so good, but don't get too comfortable quite yet.
The down-side of SIPconnect (or any other interoperability standard) is as a side effect, it limits the services and options available to users of the systems. Think SIP handcuffs--great as long as you aren't the one wearing them. Features like security, network call transfers, voice messaging, fax, hosted PBX functions, dealing with NAT and other areas were in many cases outside the 1.0 specification and thus not supported. So back to the drawing board, extending the SIPconnect specification to 1.1, which is an ongoing development effort trying to add these important capabilities without ruining the simplicity of the 1.0 specification.
But remember that SIPconnect is only focused on SIP Trunking and doesn't address interoperability between SIP systems within an enterprise or service provider. We've already seen cases where enterprises have one vendor for their SIP-based IVR and another vendor for their IP-PBX, and legacy TDM messaging systems, and are trying to integrate all these together. (Acquisitions and mergers have a funny way of making strange bed-fellows.) In this particular case, they couldn't even get the vendors of these systems to talk to each other, let alone actually fix protocol compatibility issues.
With pure SIP-based applications expanding in market share and perfectly good legacy TDM systems that are too new to replace, I believe intra-enterprise interoperability issues will become much more common. In the end, I envision that enterprises will need a on-premise network element from an independent vendor that will provide interoperability and security between their legacy systems, SIP systems and SIP Trunks they depend on for connectivity. Right now, it appears a Session Border Controller (security and SIP interoperability) and/or a Media Gateway (TDM interoperability) is the best way to solve many of the difficult interoperability issues facing SIP. Trying to get competing vendors to talk seems to be an exercise in futility.
Next we'll discuss who should be responsible for interoperability and security with SIP Trunking--the service provider or the enterprise?
Let's move past the technical issues with SIP Interoperability and talk about a far more difficult challenge - the politics of SIP Interoperability.
To make things even more politically complex, many of the vendors are starting to compete in the marketplace, vying for the same markets and customers. In this competitive environment, interoperability is a double-edge sword.
SIP is supposed to be a standard and eliminate many of the challenges with integrating systems from various vendors together, right? If my IP-PBX is RFC 3261 compliant and my SIP Trunking service provider is RFC 3261 compliant, they should just work, correct? Well--maybe or maybe not. Most likely there will be interoperability issues.
Today I thought it would be good to start a multi-part series of posts to explore why SIP interoperability seems to be as challenging as it appears, how the vendors are dealing with it and solutions you can use to solve difficult interoperability challenges.
The Root Cause
Let's start with a discussion on the root causes that make SIP interoperability difficult. The problem starts not with technology, but with the way that IETF Requests For Comments (RFCs) are developed. As opposed to the old ITU specifications that the Telecommunications Industry has lived with for the last four decades, IETF RFCs and Drafts are developed in an open and communal environment, using committees and consensus to craft the specification. This has very many positive benefits, but also a few predictable negative side effects. The problem is that RFC 3261 that defines SIP has become "everything to everyone" and bloated in both size and in flexibility.
Performing a simple word count on RFC 3261 yields some interesting insight into the problem:
Weak Terms
Can = 475
Option = 144
Should = 344
May = 381
Strong Terms
Shall = 4
Must = 631
As you can see, the number of weak terms "May," "Should," "Option" and "Can" outnumber the stronger "Shall" and "Must," which results in a very loose specification that allows the developers of SIP-based systems to make plenty of decisions on features of functions. The byproduct of this is that two systems can be completely RFC 3261 compliant and completely incompatible.
Examples
In our experience, there are no fewer than five "correct" ways to transport DTMF tones from one end point to another:
Another example that is causing a lot of grief right now whether to transport the SIP messages over UDP or TCP. The RFC indicates that either is okay and recommends supporting both, but few manufacturers actually do support both. The vast majority of equipment and application developers chose SIP-over-UDP. Microsoft chose SIP-over-TCP. Again, both are within specification and completely incompatible.
And this my friends is only the tip of the iceberg.
While these technical challenges may seem difficult to overcome, they can be solved. However, the political issues are another story. I'll discuss these in the next post.