New Patton US Tone Set for 5.2 and 5.3 firmware

Got this new US Tone Set from Patton...

profile call-progress-tone US_Dialtone
play 1 1000 350 -13 440 -13

profile call-progress-tone US_Alertingtone
play 1 1000 440 -19 480 -19
pause 2 3000

profile call-progress-tone US_Busytone
play 1 500 480 -24 620 -24
pause 2 500

profile call-progress-tone US_Releasetone
play 1 250 480 -24 620 -24
pause 2 250

profile tone-set US
map call-progress-tone dial-tone US_Dialtone
map call-progress-tone ringback-tone US_Alertingtone
map call-progress-tone busy-tone US_Busytone
map call-progress-tone release-tone US_Releasetone
map call-progress-tone congestion-tone US_Busytone

sipXecs and Skype

Caught this on the SIPFoundry web site ...

When Skype announced Skype for SIP beta applications were available we knew we had to apply. Fortunately we received our acceptance tonight and within minutes sipXbridge was making calls out the Skype for SIP network. Look for more on this when we release sipXecs 4.0 very soon.

Skype could be a major connectivity player... it certainly has become a household term!

sipXecs 4.0 Draws Near...

Picked up on a post to the SipFoundry web site...

After a ton of development it's getting real close. sipXecs release 4.0 has been in its final testing phase now for a while and there are only a few issues left that need to be resolved before release. It's a big release, probably the biggest ever. sipXecs turned into a fully distributed system with centralized management.

Read the rest: SipFoundry

VoIP Trouble Shooter

Found a great on-line resource for diagnosing Voice Traffic Problems.

VoIP Troubleshooter.com provides free online diagnostic tools and information for network managers. The site was originally created and sponsored by Telchemy Incorporated with Acterna joining as a sponsor in 2005.

Check it out: http://www.voiptroubleshooter.com/diagnosis/index.html

Make Aastra plugins work in sipXecs 3.10.3

We're looking at putting sipXecs into a customer that already has a bunch of Aastra 5x series phones. Problem is that Aastra managed phone support isn't coming to sipXecs until version 4.0.

However, it is possible to take the plugins from the development version of sipXecs (currently 3.11.

Built a 3.11.9 box and grabbed aastra-phones.jar from the \usr\share\java\sipXecs\sipXconfig folder.

Copied aastra-phones.jar to \usr\share\sipxpbx\lib folder on 3.10.3 box.

Copied all files from http://sipxecs.sipfoundry.org/ViewVC/sipXecs/main/sipXconfig/plugins/aastra/etc/ to /etc/sipxpbx/aastra.

Changed owner of files and folder to sipxchange ( 'chown sipxchange:sipxchange /etc/sipxpbx/aastra' and 'chown sipxchange:sipxchange /etc/sipxpbx/aastra/*' )

Restarted sipxpbx services (service sipxpbx restart).

What to do when sipXecs ISO installer doesn't have the proper network card drivers...

Installing sipXecs on BioStar Motherboard with Integrated Realtek RTL8110SC/8169SC Network Adpter

CentOS 5.2 with Realtek RTL8110SC/8169SC network adapter

The CentOS installed from the sipXecs 3.10.2 ISO did not have the drivers for this particular motherboard / network adapter so I was forced to do some digging. So others can benefit from my pain I documented my solution..

I downloaded kmod-r8169-2.3LK_NAPI-1.el5.i686.rpm from http://centos.toracat.org/ajb/CentOS-5/r8169 to a USB drive on my laptop.

Plugged the USB drive into the server and waited for the 'up' message.

Made a directory to mount the usb drive to (mkdir /media/usbdisk1 )

Mounted the drive (mount /dev/sda1 /media/usbdisk1 )

Changed to the directory (cd /media/usbdisk1 )

Installed the RPM (rpm -ivh kmod-r8169-2.3LK_NAPI-1.el5.i686.rpm )

Rebooted machine.

After boot, login as root.

Run linux setup command (setup)

Set the static IP address on the network card that was specified at sipXecs installation.

Save and exit setup.

Restart network services (service network restart)

Restart sipX services (service sipxpbx restart)

Rules for Vyatta to pass XBox Live Traffic

Here are the NAT, Firewall and Interface rules required to pass XBox Live traffic for an XBox 360. My inside interface is eth0 and my outside interface it eth1. Tweak accordingly...

yyy.yyy.yyy.yyy = IP Address of the xbox

NAT stuff:

rule 10 {
destination {
port 88
}
inbound-interface eth1
inside-address {
address yyy.yyy.yyy.yyy
}
protocol udp
type destination
}
rule 11 {
destination {
port 3074
}
inbound-interface eth1
inside-address {
address yyy.yyy.yyy.yyy
}
protocol udp
type destination
}
rule 12 {
destination {
port 3074
}
inbound-interface eth1
inside-address {
address yyy.yyy.yyy.yyy
}
protocol tcp
type destination
}

Rules to apply inbound to outside interface:

rule 30 {
action accept
destination {
port 88
}
protocol udp
}
rule 31 {
action accept
destination {
port 3074
}
protocol udp
}
rule 32 {
action accept
destination {
port 3074
}
protocol tcp
}

The MTU settings on the Interfaces:

ethernet eth0 {
address xxx.xxx.xxx.xxx/24
description inside
firewall {
in {
name OUTBOUND
}
}
hw-id xx:xx:xx:xx:xx:xx
mtu 1500
}
ethernet eth1 {
address dhcp
firewall {
in {
name INBOUND
}
local {
name TO-ROUTER
}
}
hw-id xx:xx:xx:xx:xx:xx
mtu 1500
}

And, give your XBOX a static IP address:

static-mapping XBOX360 {
ip-address yyy.yyy.yyy.yyy
mac-address xx:xx:xx:xx:xx:xx
}

DNS Concepts with Session Border Controllers

Published another document today on configuring internal / external DNS for use with Session Border Controllers. It's got a bit of a sipXecs slant to it but should be useful for others looking for redundant and load balanced SBC setup help.

It is available HERE and HERE2

YMMV with Asterisk & FreeSwitch installations and SRV based authentication methods... Most of the setups I have seen are A records pointing to the PBX.

Use Microsoft DNS Servers with sipXecs

Alright, so you want to maintain one set of DNS servers for your organization and it's just easier for you to do it with Microsoft's DNS servers?

I made public a document I wrote a couple years ago and published it on the sipX Wiki. Located here.

OpenSBC on Vyatta Firewall How-To published

After toiling for many hours I was finally able to get OpenSBC running properly on Vyatta. This solution builds a firewall that allows for Inbound SIP calling, Outbound SIP calling and far-end NAT traversal for remote users.

The paper is published HERE and HERE2

Many thanks to Joegen, Eric and Raymond over on the OpenSBC site for their help and patience with me in getting this going.