Baby stuff

here’s a list of our stuff, might be useful for new parents:

1. Stokke Tripp Trapp chair with Newborn Set: a must with more than one kid, and very useful with one too.
2. Stokke My Carrier: quite useful, although it’s still not the full freedom that you want
3. Red Castle Babynomade blanket: very useful, available in two variations(winter and summer), Size 2 is recommended from the beginning — the baby is not lost in it, and you have it useful for longer time
4. C&A sells baby bodysuits, CHF 12 for 5 pieces, with only small funny graphics and no Disney. Excellent price and quality, sizes available for the first 12 months.
5. Bebeconfort Amplitude changing table.  Most of changing tables are too low, and your back will hurt very soon. This one is adjustable and can be brought up to the waist  level of a basketball player.
6. Stokke Bounce ‘n’ Sleep Daybed: very convenient to carry the child around your apartment and let them sleep beside you.
7. Red Castle Cocoonababy: lets your newborn sleep in the most convenient position, and it also passes perfectly into the Stokke daybed.
8. Philips Avent SCD 525/00 DECT: a perfect babyphone, works like charm, convenient and long-lasting. The base station can be powered by normal or rechargeable AA batteries (normal Alkaline batteries will last for few weeks).

Also for twins:

1. TFK Twinner Twist Duo is so far the best twin stroller that we tested. It passes in every standard door, and very easy to handle. It also has a mounting option for baby car seats, but this construct becomes bulky and does not pass most of doors and lifts.
2. the Pro Baby shop has 15% discount on twin purchases

DOCSIS troubleshooting: pinging and sniffing

A customer DOCSIS network had some strange issues with modem and MTA performance, and here are some simple scripts that were used for troubleshooting.

Summary on domains and profiles in FreeSWITCH

A brief and very useful summary of FreeSWITCH’s author in the mailing list:

[Freeswitch-users] Domains and profiles
Anthony Minessale
Mon Nov 12 22:16:50 MSK 2012

Activating Touchpad in Xfce (Debian Wheezy)

Xfce is a lightweight display manager available in debian wheezy out of the box. It looks like a perfect alternative to a default Gnome3 to run on old hardware. Also in Gnome3 (as well as in Ubuntu 12.04/12.10), I could not find an easy way to prevent the notebook from sleeping when I close the lid (Power settings apply only to the  user settings, but not globally). Xfce does not have this problem, and my notebook can continue running with the lid closed.

The only annoying problem is that the touchpad is not activated by default. Also the Xfce mouse settings do not cover touchpad behavior. But the problem is actually solved  quite easily. Under root, create a file “/usr/share/X11/xorg.conf.d/70-synaptics_custom.conf”, with the following content:

Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Option "TapButton1" "1"
        Option "VertEdgeScroll" "1"
        Option "HorizEdgeScroll" "1"
EndSection

Reboot the PC, and voila, tapping and scrolling works everywhere.

xlab1 project: SBC requirements

A Session Border Controller as a gateway between back-end vPBX servers and ITSP is needed in the scope of xlab1 project, with the following functionality:

1. Called and Caller ID normalization:
   • Various SIP trunk providers require different number formats (national, e.164, or some special format)
   • Different customers vPBX’es may require national number formats for different countries
2. Codec normalization: SIP providers are typically limiting the choice of codecs, and customer vPBX’es may require to support a bigger variety of codecs.
3. Security: SIP trunk providers may require authorization, and SBC should perform it, screening the global route selection and authorization from back-end systems.
4. Admission control: ITSP trunk overload should be avoided
5. Where possible, public VoIP should be used for route selection (enum).
6. For incoming calls, caller’s name should be looked up if possible (Switzerland).

Kamailio as a pass-through proxy

In the scope of the xlab1 project, a Kamailio server is built to work as a pass-through SIP proxy: it forwards all SIP messages, including REGISTER, and also passes all RTP traffic through Rtpproxy. This allows to use only a minimal set of public IP addresses, while having unlimited room for back-end servers.

I placed relevant files on Github for public use:

• kamailio.cfg from the live server
• README with detailed description of internal logic

Git revision control for system configuration files

This short tutorial explains how to utilize Git for managing the changes in system configuration files, such as daemon configuration (Kamailio, FreeSWITCH and such).

The essential part is the “–shared=group” option in “git init” command. It sets setguid on .git directory and also sets “core.sharedRepository” in the repository config.

VoIP lab design

I’m designing a network layout for IP telephony testing lab. Codename: xlab1 (xlab0 is a Xen machine at my home, and xlab1 is a Xen server hosted at a partner company).

The server has only 4 public IP addresses (one for management, two for redundant SIP front-ends, and one for web front-end), and the goal is to have the flexibility to test any telephony scenario, from a standalone vPBX to a 2600hz’s Kazoo installation.

Physically it’s a 1U server with Intel Core2Quad and 8GB RAM, running Xen hypervisor.

The primary application is a multi-tenant virtual PBX. All Internet communication is done with the two front-end servers, and all the telephony handling, media termination and applications are done by the back-end servers. NAT is only used for software installation on the back-end virtual machines.

On the front-end servers, Kamailio+RTPproxy will accept registrations from UAC’s in the public Internet, and also perform flood protection and topology hiding. They would forward all SIP messages to the back-end servers, based on a DNS-based domain map based on a local dispatcher database. The SIP authentication will be handled by back-end servers.

Also the front-end servers will run a FreeSWITCH process each, used only as an SBC for communication with ITSP trunks.

Also need to think how load-balancing and failover would be organized. Especially that many ITSP’s expect only one IP address at the customer end of the trunk.

Here is the concept drawing of the service components and communication flows:

The project is intended to be open-source, open-design, and open-documentation, so more technical details will follow.

UPD: the front-end kamailio configuration, work in progress

Setting up a conference bridge with FreeSWITCH

Here is a short description how I set up my conference bridge with FreeSWITCH (All PIN numbers and extensions are made up). The requirements were as follows:

1. Multiple conference rooms for different projects. Each room has its own moderator credentials.
2. The same access phone numbers for all rooms.
3. Regular users have to enter 4 digits to get into a conference (Moderator can dial more digits, as he or she is usually more prepared).
4. International access at local call rates.
5. Automatic call recording. Recordings are stored in separate folders for each room, so that simple Apache authentication can be used for selected rooms.

Learning 2600hz Kazoo platform: videos

Thanks to Kikill Sysoev (onnet.su), here are useful videos which (should) help to understand how the Kazoo platform of 2600hz.com works internally:

1. James Aimonetti – Building VoIP Applications (whApps) in Whistle
2. Handling a Polyglotten WAN: Karl Anderson

more to come…