Ask Mr. Andrews: Setting Up SIP Ports

July 29, 2008 by Garrett Smith

Dear Mr Andrews:

Can you explain how to set SIP ports on modern popular hardware phones such as the medium priced (or are they entry level these days) Sipura/Linksys/Cisco line?

Why would you not use 5060? If you have several phones behind NAT on the same LAN, is there a logical way to set these? How does the other endpoint see this? Enquiring minds and all that… I shall wait here on ICE for a STUNning discussion in a future article.

Part of the problem with NAT is that there are several competing mechanisms for negotiating it, and the industry cannot seem to get behind a single, unified methodology. Until this happens, dealing with NAT will likely continue to be a pain in the butt.

STUN, ICE and TURN are three examples of solutions to issues inherent with SIP + NAT. STUN is not 100% reliable depending on the type of NAT you are dealing with. ICE builds upon STUN by allowing the device to use a range of ports and STUN techniques. However, ICE is not well supported. Media relay solutions like TURN can cause latency/QoS issues with VoIP, and are generally difficult to scale.

If you are behind NAT, you can set up port forwarding on your router/firewall to allow VoIP traffic to pass through. For SIP, use ports 5060 to 5070. For RTP audio, use port 8766 to 35000.

There are definitely some security concerns with port forwarding. Hacking tools such as SIPFlanker http://tinyurl.com/sipflanker are available as well as public posts detailing the default login credentials for many Sip devices http://tinyurl.com/sippasswords

When configuring Linksys devices behind NAT, there are a few things you want to be particular about. In the configuration UI, in the “SIP” Tab, make sure you have the following options set:
*******************************************************************
Substitute VIA Addr: yes
STUN Enable: yes
STUN Server:

In the “Ext 1” Tab, make sure you have the following options set:

NAT Mapping Enable: yes
*******************************************************************
Double check the NAT Keep Alive Interval setting on your Linksys phone and make sure it is set to a low value, ideally around 10-15 seconds. For more information on configuring Linksys phones for NAT, refer to (starting) page 59 of the phone administration guide here http://tinyurl.com/linksysspa.

Faxing and VoIP at a Near Flawless Success Rate

Well for those of you in the VoIP industry, and for those of you just starting to learn about it, you will hear many horror stories about VoIP and faxing. Often you will hear how unsuccessful it is, and some will hear more vulgar words in conjunction with it. But what if you had that magic wand to make it work? Would you trust it? Would you try it? To what extent would you try it before tossing it out the window? What if I told you that there is technology out there that can fix Faxing over VoIP that is notorious for not being successful and being the cause of many long days and even longer nights?

These are all questions that the great VoIP thinkers at Sangoma have put onto the drawing board and now have come up with a solution: The Sangoma Faxing Synch Cable. This was first introduced to us by Konrad Hammel, a Field Applications Engineer with Sangoma that visited VoIP Supply for Training on the newest PCI cards.

Wondering how it works, and what you need for a near flawless success rate?

Well let’s start off with an IP PBX. The Phonebochs appliance, trixbox appliance, or a blank chassis using Plain Jane Asterisk will do to start.

From there, PCI cards. More Specifically Sangoma analog and digital PCI cards. Which ones you ask? Well you will need two of them. A digital PCI card, like the A101D, or A102D (T1 Digital PCI card), and then an Analog card to hook your fax machine up to. (A20100D (2 Port FXS), A20200D (4 Port FXS)) Cards are good, but you can go to a bigger FXS card if you wish. The only limit to the amount of ports is that of your IP PBX and its limitations; however I do recommend using echo cancelation on both cards, and trust me, it is well worth it.

FoIP

From here it doesn’t look like anything special–some of you may already have this and could possibly be drooling at this setup because it is easy. Well there is one more piece. And at this point you are probably thinking that it will be expensive and that now it’s not worth it to read on, but please keep reading, because what I am about to tell you will blow you away. The key to this is only $10. That’s right, for $10 you can have a near perfect success rate with LITTLE configuration of the cards and codecs. But how do you use it? Well this small cable will connect to a two prong section on the top of the Digital card, then the other end will hook up to a similar spot on the Analog card. From there, the cable will automatically start the synch and make it work. That’s it. Go figure. For decades this has been hindering businesses, and all it took was a small cable to fix it.

Sangoma and Open Source’s Double Edge Sword

July 28, 2008 by Garrett Smith

A Game of Open Source Cat and Mouse

As open source telephony continues to make its ascension as a legitimate threat to legacy systems vendors an interesting game of cat and mouse is developing between the various PSTN connectivity vendors.

Not a press release goes by without an eventual answer from a competing company and I doubt that the latest announcement from Sangoma that they will be powering FreeSWITCH, an open source telephony platform designed to facilitate the creation of voice and chat driven products scaling from a soft-phone up to a soft-switch, will go unanswered by their competitors. Now most consider hardware to be a bit of a yawn (and I tend to agree), however this announcement marks another notch in the belt for Sangoma. Sangoma, who just a few short years ago was a distant number two in the open source PCI card space to Digium, now finds themselves a gobbling up market share thanks in large part to partnerships with the various open source telephony platforms – all of which was created, thanks in large part to Digium.

(more…)

Partnership extends IP Camera Supply’s installation and support footprint

July 24, 2008 by Garrett Smith

IP Camera Supply has partnered with Celergy Networks, Inc. of Carlsbad, Calif.  The partnership will allow IP Camera Supply to extend its current regional installation footprint nationwide through Celergy’s network of over 4,000 installer partners, allowing IP Camera Supply to continue its rapid growth without geographic limitations.  In addition to installation services, Celergy will also enable IP Camera Supply to provide customers with comprehensive site surveys and solutions analysis.

“We are very excited about the partnership with Celergy,” said Cory Andrews, Director of New Business Initiatives. “After months of conducting research to find an installation partner with an established field engineering staff and efficient tools to manage the installation process, we decided Celergy’s offerings best fit the needs of IP Camera Supply customers.  Celergy’s core IP Video knowledge was also a huge plus for us.”

IP Camera Supply’s current process for installation includes a comprehensive site survey and analysis to determine optimal IP camera placement and will now include other site-specific details such as the mounting and configuration of IP cameras. These services will now be available for customers across the country with the assistance of Celergy. This means that any customer, regardless of geographic location, will be eligible to receive all of the physical installation services that IP Camera Supply provides regionally; making IP Camera Supply one of the few IP Surveillance solution providers that can effectively meet the needs of customers across the country.

Partnership extends IP Camera Supply’s installation and support footprint

IP Camera Supply has partnered with Celergy Networks, Inc. of Carlsbad, Calif.  The partnership will allow IP Camera Supply to extend its current regional installation footprint nationwide through Celergy’s network of over 4,000 installer partners, allowing IP Camera Supply to continue its rapid growth without geographic limitations.  In addition to installation services, Celergy will also enable IP Camera Supply to provide customers with comprehensive site surveys and solutions analysis.

“We are very excited about the partnership with Celergy,” said Cory Andrews, Director of New Business Initiatives. “After months of conducting research to find an installation partner with an established field engineering staff and efficient tools to manage the installation process, we decided Celergy’s offerings best fit the needs of IP Camera Supply customers.  Celergy’s core IP Video knowledge was also a huge plus for us.”

IP Camera Supply’s current process for installation includes a comprehensive site survey and analysis to determine optimal IP camera placement and will now include other site-specific details such as the mounting and configuration of IP cameras. These services will now be available for customers across the country with the assistance of Celergy. This means that any customer, regardless of geographic location, will be eligible to receive all of the physical installation services that IP Camera Supply provides regionally; making IP Camera Supply one of the few IP Surveillance solution providers that can effectively meet the needs of customers across the country.

IP Telephony VARs….Selling IP Video Surveillance Yet? What Are You Waiting For?

If you have established a business or consultancy around VoIP and IP Telephony, expanding your product/service offerings to include IP Video Surveillance should be easy. If you are selling your customers IP PBX and/or hosted IP Centrex services, many of these same customers will have needs for surveillance. The surveillance industry, much like telephony, is moving away from legacy CCTV (Closed Circuit Television – Analog) to IP based platforms….which plays right into your sweet spot.

If you have experience deploying, administering and maintaining IP Communications platforms such as Asterisk, FreeSwitch, Switchvox, Trixbox, etc….picking up the fundamentals of IP Video Surveillance will be a snap.

First Off – Pick an NVR (Network Video Recorder) Platform. There are literally dozens of vendors offering both Windows and Linux based platforms. A few of the more popular products include:

Axis Camera Station
Milestone
ONSSI
Mobotix MX Control Center
Exacq
ZoneMinder (Open Source!)

ZoneMinder is the closest thing to an “Asterisk equivalent”, OSS project….and it is a capable platform that runs on a Linux footprint….but lacks the huge, vibrant developer community that surrounds Asterisk.

Second – Download eval software. All of these vendors offer trial-ware. Zoneminder, as mentioned, is completely free and open source.

Third – Build an NVR Server. A standard Intel based PC or server is all you need. P4 or better, Gig of RAM and a decent amount of hard drive storage. One Note of Interest – there are a number of video formats supported by platform and camera vendors. MJPEG and MPEG4 are most prevalent, but many vendors are moving to H.264 as it offers more compression while maintaining image quality. Many IP cameras support both MJPEG and MPEG4 video codecs, and they are user selectable. Video cameras supporting H.264 are just now coming to market. H.264 offers several advantages in that it cuts down on bandwidth requirements (much like G.729 versus G.711) and storage requirements for archiving video footage. A handy Bandwidth and Disk Size Calculator is available for free download here.

Next – Get an IP Camera. There are a wide variety of IP Video Camera manufacturers, offering a range of products. Cameras come in fixed view or PTZ (Pan, Tilt and Zoom) varieties, as well as a range of resolutions and advanced features + form factors depending upon your application. Leading IP Video Camera manufacturers include:
Axis
Mobotix
Panasonic
Vivotek

Interesting Note – Similar to analog FXS gateways in the VoIP world which allow for integration of legacy telecommunications gear like analog phones and fax machines….Video Servers (Encoders) are available to facilitate the integration of legacy CCTV (Analog, Closed Circuit Television) cameras with an IP based NVR platform. If your customer has a significant investment in analog security cams, why not supplement their existing solution by integrating it with a more feature rich, IP-Based NVR platform? This “Hybrid” approach should be familiar to you from the VoIP world. You can take a look at some of these video server / gateway products here. Similar to VoIP gateways, video servers come in 1, 2, 4, 8, 16 and 24 port densities (channels), depending upon the number of analog cameras you want to attach. They also encode analog video to MJPEG, MPEG4 or H.264 depending on the model you choose. Refer to the manufacturer specification to see the codecs supported.

Finally – Get busy learning the in’s and out’s of the solution. If you have a solid grasp of TCP/IP networking fundamentals, you’re 90% of the way there. IP Video Surveillance utilizes the same Client / Server relationship you are accustomed to with VoIP / Telephony. The NVR Sofware is installed on a server or PC on your network, and accessed via a GUI from a browser or on the local machine.

Configuring the video camera is as easy as plugging the camera into your LAN, letting it get an initial IP address via DHCP, and then logging into the camera itself (via the built-in webserver in the camera) and resetting it to a fixed IP address. Next, in much the same fashion as you would create an extension on an IP PBX and provision an IP phone….log into the NVR server and configure the camera server-side.

Once you have the camera configured, there are a range of other features you can play with, such as motion detection, software PTZ controls for manipulating cameras remotely, alarms, notifications and even advanced software video analytics on some platforms.

In a post-911 world, demand for video surveillance is exploding. Businesses….Local, State and Federal Government Agencies, Educational Institutions, and even private residential users are all driving demand for next generation, IP based surveillance solutions.

Like I said….What are you waiting for?

Setting up an Audiocodes MP-114/118 FXO with Asterisk and FreeSwitch

Audiocodes is one of the better, if not the best, SIP PSTN gateways available on the market. Problem has always been its most unfriendly user interface. They sure don’t make it easy. When they say you have to pay for quality one doesn’t consider both literally and figuratively. Any wrong setting can throw the whole thing off. You WILL RTFM!!! Not to say that I’m not the better for all that reading, just my eyes kind of hurt now. If you’re the type, like me, that doesn’t give up easily then Audiocodes may be for you. Quitters should stop reading now.

This is an FXO unit with 4 ports. The setup would be pretty much the same for a 118. I am using a standard vanilla Asterisk 1.4 install. I’ve always preferred a lunchbox Asterisk setup to a user friendly GUI because I find it much easier to troubleshoot when things aren’t working as advertised. This will be the first part in a continuing series on setting up these gateways in different scenarios. My FreeSwitch setup is using the vanilla default profile setup.

We only need to configure sip.conf and extensions.conf to get a working setup on the asterisk end.
Asterisk Setup:

sip.conf : We can use one (type=friend) or two (type=user & type=peer ) entries.

Single or Friend Settings

[pstn]
type=friend
context=inbound
dtmfmode=inband
host=192.168.xxx.xxx ; IP address of MP-114
nat=no
canreinvite=no

Paired or User/Peer Settings

[pstn-out] ; used for dialing out
type=peer ; peers help deliver the calls for us.
allow=ulaw
context=outbound ;not necessary to, but lets us know its function
dtmfmode=inband
host=192.168.xxx.xxx ; (This is the IP of the MP-114)
nat=no
qualify=no
[pstn-in]
canreinvite=no
context=inbound ; Where to deliver the inbound calls in extensions.conf
dtmfmode=inband
host=192.168.xxx.xxx
nat=never
type=user ;we are a user of MP-114 FXO

extensions.conf ; Doesn’t matter much here whether it’s friend or user/peer model

[outbound] ; Context for Outgoing Calls
exten => _NXXXXXX,1,Dial(SIP/${EXTEN}@pstn) ; @pstn-out if you’re using the user/peer model
exten => _NXXNXXXXXX,1,Dial(SIP/${EXTEN}@pstn)
[inbound] ; this is our telephone number
exten => _2125551212,1,Answer() ; let the gateway know we’ll handle it from here
exten => _2125551212,n,Wait(1) ; give a sec to get any passed info
exten => _2125551212,n,Dial(SIP/1001,25) ; or point it to your IVR

FreeSwitch Setup: I’m still a noob here. Originally I really completely over thought this one and made far it more complex than needed be. Failed, of course. Then I went super simple with it. Worked! I hope I don’t get flamed for poor design, but it works!
I needed to create an unauthenticated extension in the directory (extensions for asterisk users). This could dicey /unsafe, but it is internal.

/usr/local/freeswitch/conf/directory/default/pstn.xml:



Now for the dialplan settings that make it actually work . There are two place under the dialplan directory I needed to edit.

1. Let FreeSwitch know we have a number for the public to reach.

/usr/local/freeswitch/conf/dialplan/public.xml

2. Make sure the DID is in the default dialplan so FreeSwitch knows how to handle the calls

/usr/local/freeswitch/conf/dialplan/default.xml

First let’s receive calls.


Now let’s make calls. This is for 7 digit calls, but would apply to long distance also.


AudioCodes Setup
Quick Setup:

IP configuration: If you can’t figure this one out there’s little or no chance you’ll get this working. Put on dunce cap and sit in corner.

SIP parameters:
Gateway Name: I use it’s IP address so no dns issues.
Working with Proxy = Yes
Proxy IP address= the IP of the Asterisk box.
Proxy Name= the IP of the Asterisk box.

Protocol Management:
Protocol Definition ->
General Parameters:

Channel Select Mode=Ascending

And make sure SIP ports are set for 5060

Proxy and Registration:
Proxy Name and Proxy IP Address= Asterisk Server

Enable Registration: I didn’t .

Gateway Name and Registration Name: MP-114 IP address

Subscription and Registration Mode: Per Gateway (don’t remember if this matters).

Coders:make sure ulaw’s there

DTMF & Dialing: Max digits-> put a high number like 32

Routing Tables:
Tel -> IP routing and IP-> Tel routing = I used

Dest IP/Phone Prefix =*

Source IP/Phone Prefix =*

Dest/Source IP Address = Asterisk IP Address

Endpoint Phone Numbers: Match channels to phone numbers.
Channels= 1 -4
Phone numbers = your phone numbers

Hunt Group Settings:
I used Cyclical Ascending

End Point Settings:
Automatic Dialing:Destination Phone Numbers should match the numbers you have in inbound context in extensions.conf. In our example -> exten => _ 2125551212,1,Answer()

Advanced Applications:
FXO Settings: Dialing Mode should be set to One Stage.
That should get you up and running. Although little differences in setups can cause major headaches and frustrations, I hope that this gives you a good starting reference point. We’ll be putting this and other guides on our wiki when it becomes available (with screencaps).

Guest Post: It’s So Easy To Write Apps for Asterisk

July 23, 2008 by Garrett Smith

One of the most powerful things about Asterisk is the relative ease of developing and integrating new applications.   Historically, the telephony world has been a “walled-garden”, with proprietary technologies, arcane configuration methods, and non-trivial integration hurdles.  Asterisk is a pure software application, and an open source one at that.  It’s highly configurable, and through various interfaces (such as AGI and the manager API), it’s easy to write new applications.  And most importantly, Asterisk doesn’t dictate the implementation language or technology — you can develop your app in any language you want (e.g. Python, Ruby, Java, C, etc.)

I’ve built a number of simple applications for our home Asterisk system.  For example, we have one that’s used on school-day mornings.

First, the system rings scheduled wakeup calls in each of the kid’s bedrooms.  Next, as the school bus time approaches, the system announces five minute and two minute warnings on the kitchen phone.  It takes advantage of the auto-answer feature on many Ethernet phones (such as the Linksys SPA942 in our kitchen).  Pre-recorded announcements (e.g. “the bus is coming in 5 minutes“) announce automatically out of the phone’s speakerphone, without anyone having to pick up the phone.

I wrote the entire application in a few hours (most of which was spent learning how to get Asterisk to initiate outgoing calls).  The app is a simple Python script that runs early each morning (using cron) on the server hosting the Asterisk system.  It first checks to see if it’s a weekday (i.e. school day), and if it is, it queues up the wakeup calls and the two announcement calls.

Future versions will include the holiday calendar to omit the calls and announcements on school holidays, and will automatically check the local news Web site to see if school has been cancelled or delayed.

Try doing that with your Nortel PBX! DISCLOSURE: Andy Payne is an investor in Digium.

More from: Asterisk Garrett Smith

New Product Lines Featured on IPCameraSupply.com

July 22, 2008 by Garrett Smith

The IP camera world is always expanding, and so are the offerings from IP Camera Supply!  We now feature products from manufacturers Bosch, Pelco and Speco Technologies.  You can find their product lines here:

To welcome our new friends, we will be doing one week of free ground shipping (starting July 28 through Aug. 4) for the following products:

Bosch:

VEZ-021-HCCS

VEZ-021-HWCS

VG4-161-CC0

VG4-161-EC0

VG4-161-ETE

VG4-162-CTE

VG4-163-CC0

VG4-163-EC0

VG4-164-CC0

VG4-524-PTS

 

Pelco:

13FA2.3

13FD2.3

13VA1-3

13VD1-3

13ZD5.5X30

C10CH-6

DF5-0

DF5-PB-0

EH8106L

PS20

 

Speco:

WH-927

VL-6WMTDV

HT-7815DNV

VL-634

HT-650PTDZ

HT-7715DNV

CVC-627B

CVC-627W

CVC-927PTZ

VL-62

  • Featured Posts

  • Popular Posts

  • Read Our Feed

  • Latest

  • VoIP Post Categories

  • Archives