January 23rd, 2008

SIP Forum approves V1.0 of SIPConnect Technical Recommendation

Posted by Russell Shaw @ 11:33 pm

Categories: Enterprise IP/VoIP, Internet Telephony Expo-Jan 2008, Research, SIP

Tags: SIP, SIP Forum, Session Initiation Protocol (SIP), Telephony, VOIP, Telecommunications, Emerging Technologies, Networking, Russell Shaw

 

At the Internet Telephony East Expo here in Miami Beach, the SIP Forum has announced it has formally and unanimously ratified version 1.0 of the SIPconnect Technical Recommendation.

“Huh,” you ask.

OK you have come to the correct place for answers.

First, though let us catch our breaths. SIP=Session Initiation Protocol. Here’s a link to a good and credible explanation.

“The Rec,” as I will call it, constitutes a standards-based approach for management of direct IP peering between VoIP service provider networks and SIP-enabled IP PBXs in the enterprise.

The big plus here is that once implemented in specific, branded solutions, this would eliminate the need for VoIP gateways in the enterprise. Added plusses: improved VoIP call quality and more flexible configurability for applications and rich media services.

July 31st, 2006

Asterisk basics: in six quick slides

Posted by Russell Shaw @ 12:45 am

Categories: General, OSCON 2006, Research, SIP

Tags:

I am not  a technical expert on Asterisk, but being fully aware of its gathering momentum as an is a free software / open-source software implementation of a telephone private branch exchange (PBX), I decided to hang out with some Asterisk code jocks for the better of an afternoon.

I was much looking forward to a walkthrough of Asterisk, which when implemented, allows multiple attached telephones to make calls to each other, as well as to connect to the Public Switched Telephone Network.

The setting was an Asterisk tutorial presented last Monday at the Open Source Conference in my hometown of Portland. The cerebral and witty Brian Capouch, assistant professor and chair of the Department of Computer Science at Saint Joseph’s College in Rensselaer, Indiana, was the MC.

Brian, who is finishing "Inside and Out: Do-it-yourself Open Source Telephony" for Addison-Wesley, walked us through a series of conceptual slides about telephony, IP telephony, and then Asterisk. And as you have probably guessed by now, that is a basic Asterisk schematic at the top of this post.

Now let us look at some of the slides, and how they come together in a code string for a specific Asterisk-enabled application.

Read the rest of this entry »

July 13th, 2006

Tutorial shows how to configure P2P SIP dialing on your Asterisk PBX

Posted by Russell Shaw @ 5:45 am

Categories: General, SIP, Softphones, Vonage

Tags:

Barrett Lyon has created a don’t miss resource that shows you how to configure P2P SIP URI (Uniform Resource Identifier) dialing on your Asterisk-based PBX.

"There are thousands of people that operate their own Asterisk based PBX systems, yet they do not enable any method to allow for p2p sip URI dialing," Barrett explains. "These SIP ‘targets’ are very easy to enable and allow you to dial anyone that has also enabled the function.

"Dialing with SIP URI completely avoids toll calling and forces your Asterisk server to create P2P SIP connections when you dial someone’s SIP URI," he points out. "It makes a less complex phone call without a system administrator configuring a peer and best of all: It gets rid of phone numbers and your telco!

So how does this work? As Brad explains:

By creating a SRV record in DNS for your domain you can help remote PBX systems establish P2P calls for a specific extensions. For example, when someone calls me, my URI is resolved to my PBX (sip.blyon.com). When the call comes into my Asterisk box, blyon is setup as a extension, and that extension is connected to a phone or a context. As a result, if someone uses something like Xten to call blyon@blyon.com, I get a normal ring and phone call. When I use my Cisco 7960 phone and dial someone’s SIP URI it completes like a normal phone call.

Brad then goes on with a fairly sophisticated code-based tutorial on how to make this happen. He has sections that walk you through Configuring the DNS SRV Record, Creating a whitepage TXT record, Configuring Asterisk to accept inbound URI calls and Configuring Asterisk to accept outbound URI calls.

He’s also provided walk-thrus on Dialing with a free Soft Phone,Using Xten without any provider or special settings to call a SIP URI, SIP URI and Vonage, and Dialing URI with an ATA.

May 23rd, 2006

Gizmo's Robertson: new Gizmo 2.0 will "displace" ConnectPath, SJLabs softphones

Posted by Russell Shaw @ 11:20 pm

Categories: General, SIP, Softphones

Tags:

 

SIPphone CEO and chairman Mike Robertson wrote me yesterday to tell me that Gizmo 2.0 is now live, and I should try it.

I just have, and I like its attractive User Interface and general ease of use.

But what’s more interesting is something Mike told me.

He views this build as in essence, a SJLabs and CounterPath-softphones killer. 

"I think it will quickly displace xten (actually CounterPath-ed.) and sjlab’s products because it has very good call connect reliability which has always been an issue trying to send/receive Asterisk calls outside of your local network," Mike writes.

The key to Gizmo 2.0, he says, is Asterisk compatibility. 

"We now have Asterisk support which is great because it connects to Asterisk servers, but still uses Gizmo backend smarts to navigate firewalls/routers/NATs if necessary to make sure that media is successfully relayed," he tells me. "This makes it a superior user experience to other standard SIP clients which don’t have a back end network to leverage."

But Gizmo 2.0 is not just an Asterisk-only, one trick pony.

"Besides Asterisk, users can connect to any other SIP network. And again, they will leverage Gizmo Project’s network navigation system which will select UDP and fallback to TCP if unsuccessful, use a media relay when required as well as identifying the user’s geographic location so it will use the closest media relays," writes Mike, who adds that SIPphone has data centers around the world to insure low latency for calls."
 

May 17th, 2006

NAT breaks VoIP: so here's what to do

Posted by Russell Shaw @ 8:35 am

Categories: General, Research, SIP

Tags:

 

Interesting set of findings from an Interop Labs’ test of VoIP gear run on the Interop Las Vegas show’s earlier this month.

Network Address Translation, or NAT, for short, (as shown on th Cisco site, above) can break VoIP. NAT does this by its nature as a procedure that masks private IP addresses from public view. Yet by doing this, NAT makes it impossible to set up Internet-delivered, SIP-based calls to devices with private IP addresses.

Interop Labs said the best solution is to get rid of NAT. If that isn’t feasible, there are two basic alternatives:

Install a server outside the NAT device. This would be a server that can keep track of where packets are initiated from and then move them through the NAT.

The other practical approach would be to install a SIP proxy server capable of "ignoring" the public addresses of VoIP packets while, at the same time, detecting the actual addresses within those packets. 

March 6th, 2006

Welcome to SIP, Cisco!

Posted by Russell Shaw @ 1:13 pm

Categories: BlackBerry, Cisco, General, News, Products, SIP, Software, trends

Tags:

 

Today as expected, Cisco announced they have finally embraced SIP (Session Initiation Protocol). The platform for doing so will be Cisco Unified CallManager5.0, the call-processing component of the Cisco Unified Communications system.

As the last major IP systems and equipment vendor to accept SIP, it does kind of seem that Cisco was dragged kicking and screaming into the SIP camp. Well, maybe not "dragged kicking and screaming," but more like biding their time before they could not do so anymore because of SIP’s potential and customer demand.

Cisco has finally realized they just can’t make IP phones, boxes and routers anymore. As Cisco vice-president of IP Communications tells my colleague Marguerite Reardon today, "IP telephony isn’t just about toll bypass anymore.  "It’s about improving productivity and allowing people to do their jobs more effectively. And people need to be able to communicate and collaborate through the means that suits them best." 

For Cisco, the move into SIP had to be a grudging calculation that customer demand for SIP compliance outweighed the risk of cannibalization that SIP poses.

That risk is in the nature of SIP itself- as a protocol that oversees how VoIP phones establish contact and perform essential services. Cisco SIP compliance could, in far more than theory, enable customers to combine Cisco SIP phones with other systems from rival vendors. For example,the SIP support contained in the new Call Manager could enable compatibilty with non-Cisco IP phones- most of which are far less expensive than the $500 for some Cisco phone models.

But concurrently, the beefed up CallManager will now be able to handle presence awareness and multimedia applications seamlessly.

Already, we are starting to see announcements from Cisco vendor partners. Microsoft says it will work with Cisco to integrate the SIP-based Microsoft Live Communications Server with the now SIP-enabled Cisco Unified Communications System of which Call Manager is a key component. 

And also today, BlackBerry-maker Research In Motion said its BlackBerry Wireless LAN Solution will integrate with Call Manager 5.0 via SIP to facilitate VoIP calls via enterprise networks to the BlackBerry 7270.

I am sure we will be seeing more such announcement in the weeks and months to come.

Couldn’t end this post without a key point Andy Abramson made in his blog today: that Cisco has already had SIP capability via Linksys.

"What’s ironic is their subsidiary, Linksys, was SIP compliant from the time they bought SIPURA, and got a bottom up strategy going, rather than a top down," Andy writes. "The Linksys IP PBX called the 9000 provides a lot of really cool CallManager like features for fractions of the price of what a Call Manager can deliver."

That makes me wonder about the thoroughness of how Cisco has, or has not, integrated Linksys. Heck, they bought Linksys back in 2003!