SFTP Server

Network and UC engineers often need a SFTP server.  I've been using FreeFTPd for years due to it's small size and free.  However FreeFTPd's encryption algorithm was outdated and not supported by some version of Cisco UC appliances.  I have been looking for an alternative for quite some time with no luck.  Solarwinds' SFTP server is "Free" but with 4GB limit.  Other products are either too bukly or not free at all.

It turned out that Windows (Server or Desktop) has an "OpenSSH" option which works pretty well.

Go to Apps > Add optional features > Search for OpenSSH Server.  Once installed, there will be two services.  Start these two services.

By default, user has access to C:\, which is also the root directory of the SFTP server.  However, Cisco UC appliance cannot handle that (with the SFTP root as "/C:/").  To change the SFTP root, you may edit the %programdata%\ssh\sshd_config file.  Say, you want to make "C:\SFTP" as the SFTP root directory, add the following line to the file:

ChrootDirectory "C:\SFTP"

Restart the OpenSSH services to take effect.

Minimalist's SIP Lab (Part 2)

With may vendors going virtualization, it is possible to run virtual labs where it requires physical equipment before(such as Cisco ISR routers).  CML, VIRL, GNS3, EVE-NG, etc. we all heard about them.  But how can we run a meaningful lab with minimal resource?  That way, we don't have to fire up the lousy UCS servers?

Take the following diagram as an example.  I was working with a group of developers on a voice product, which require a lot of custom tagging in the SIP messages.  My job is to configure the routers to copy/modify/manipulate the SIP message.  (Yes, a lot of SIP profiles and regex).

It'd be great if I can run the lab on my laptop.  Did I mention that I have 2-3 production VMs (Virtual Machines) running on my laptop already?  Adding GNS3 and some virtual routers will definitely have impact on CPU and memory usage.

I achieved the goal with IOL (I86BI_LINUX-ADVENTERPRISEK9-M, Version 15.7(3)M2), which requires 384MB memory per each router.  The IOL image boots much faster than the CSR1000V or the C8000V virtual routers (which requires 4GB memory each).

I created 3 router instances.  Two of them are acting as CME, with MicroSIP softphone registered.  One of them is acting as a CUBE.  You don't actually need the CUBE license, nor the "mode border-element" command.  To test SIP profiles and SIP header manipulation, you just configure regular voip dial-peers.

As mentioned in the previous blog, Sandboxie comes handy when you need to run multiple softphones on the same computer.  The footprint is much smaller than launching multiple VMs.

With this lab, I can make test calls from CME1 to CME2 via the CUBE.  I can do all kinds of manipulations.

Minimalist's SIP Lab

SIP has become dominant in UC(Unified Communications) now.  If you're interested in learning/practicing SIP, CUBE, SBC, etc., here are some ideas.

Software lab is always better than hardware lab, because of cost, power consumption, noise, portability, etc.   Unless you want to test transcoding (which requires hardware DPS, like PVDM), software is sufficient for most cases.

If you are reading this, you are probably already familiar with lab software like GNS3, EVE-NG, Virl(CML), etc.  I'll use GNS3 as an example.

There are different virtual images on GNS3.  Each one has its pros and cons.  I personally like IOL (a.k.a. IOU) because it's lightweight (as little as 256MB per instance) and fast boot time.  Most of the L3 IOL image comes with CME(CallManager Express) function.  You may use CME as a IP PBX and register SIP phones to it.  Codec is limited to G.711 only.

! Global configuration for VoIP, with SIP sub-section
voice service voip
 allow-connections sip to sip
 sip
  bind control source-interface eth0/0
  bind media source-interface eth0/0
  registrar server expires max 1200 min 300
!
voice class codec 1
 codec preference 1 g711ulaw
!
! Global config for SIP registration(CME)
voice register global
 mode  cme
 source-address 192.168.28.10 port 5060
 max-dn 20
 max-pool 10
 authenticate register
!
! Create DNs to be used in later config
voice register dn  1
 number 2001
!
! Each register pool is a phone.  MAC address doesn’t matter
voice register pool  1
 id mac 0000.0000.0001
 number 1 dn 1
 dtmf-relay rtp-nte sip-notify
 voice-class codec 1
 username user1 password pass1

Then you may download SIP softphone apps, such as X-Lite(now known as "Bria", MicroSIP, etc.  Register SIP softphone to CME should be straightforward.  Make calls between two or three SIP phones and use debug commands (such as "debug ccsip message") to view the SIP messages is a good starting point.

Most of softphone allows single instance only.  You may work around that by using Sandboxie or virtual machines (such as VMware, VirtualBox, etc.)

If you want to explore the features of CUBE virtually, you may use CSR100v virtual router, which can also be run on GNS3.  There is no license needed.

If you want to play with codecs (such as g.729) or media resources (such as transcoding), you'll need a hardware router with DSPs.  You may get a Cisco ISR4K from eBay for about $200. And get a PVDM4-32 for about $100.  I'd get the routers comes with license (UC/K9 or VSEC/K9), though Cisco didn't seem to enforce CUBE license (yet).

Cisco Expressway (MRA) and AT&T Wireless Interoperability Issue

When deploying a Cisco Expressway MRA(Mobile Remote Access) solution, I ran into a weird interoperability issue with AT&T wireless.  The symptom was: MRA calls to AT&T Wireless numbers went straight to voicemail without ringing the cell phone at all.  The same MRA call doesn't seem to have problem with other carriers like Verizon, T-Mobile or even AT&T wired phones.

At the first glance, this seems to be a carrier issue and there is not much we can do unless the carrier tells us what's wrong.  The demarcation point is at the CUBE.  I don't have any visibility beyond the CUBE.

I decided to do some troubleshooting within my scope.  I noticed that non-MRA calls didn't seem to have this problem.

If it's only the MRA calls having the problem, it is unfair to point the finger to the carrier.  But on the other hand, this only happens with one carrier.  It must be an interoperability between MRA and that particular carrier.

Both MRA calls and non-MRA calls go through the same CUBE.  I looked at the INVITEs sent from CUBE to carrier.  They are very similar except that the MRA calls have "Max-Forwards: 12" in the SIP messages while non-MRA calls have "Max-Forwards: 69".

I'm not sure if that's the root cause of the problem but that is the only thing sticks out.  By looking at Cisco documentations, Expressway has default Max-Forwards of 15 and CUCM has default of 70.  These values are very close to 12 and 69 from the CUBE logs.

Max-Forwards tag was designed to prevent infinite loops in call routing, similar to the TTL in IP packets or hop-count in routing protocols.  The value will be decreased by 1 on each hop along the path.  If one of the hops has a different value on Max-Forwards, the lower value takes precedence.  The diagram below explains why the MRA calls have a value of 12 while the non-MRA calls have a value of 69.

Without seeing the AT&T Wireless logs, I cannot tell what happened within the cellular network.  But imagine there are 12 or more hops in the cellular network before the call reaches the wireless endpoints (cell phones).  What would happen?

When the Max-Forwards value decreased to 0 on the way, the call will be dropped.  If that happens, the call controller within the cellular network will think the cell phone is unreachable (like when the cell phone is powered off or out of signal).  The call controller will send a REFER (redirect) SIP message back to the originator.  The call will be redirected to the cell phone's voicemail.  This is exactly what happens when the cell phone is "unreachable".

• If it take less hops for the CUBE to reach the voicemail server (less than 12 hops), the call will be established.  The caller will hear voicemail greetings.
• If it takes 12 hops or more for the CUBE to reach the voicemail server, the caller will hear reorder tone (fast busy) or the carrier's error announcement.  Because the call will fail for the same reason (Max-Forwards decreased to 0).

In my case, it is the prior.  Again, all these are just my guess, but an educated guess.  Is there a way we can fix this problem without carrier involved?  Of course.

The solution is to change Expressway default value from 15 to 70.  It doesn't necessarily have to be 70.  It just needs to be a value large enough so that the SIP message can survive the number of hops before the Max-Forwards decreased to 0.  Since CUCM has a default value of 70 and it seems to work, I decided to set Expressway to 70 as well.  If you are one of those OCD (Obsessive-compulsive disorder) persons, you may set Expressway to 72.  Then both MRA and non-MRA calls will leave the CUBE with the same value of 69, making it "consistent" from carrier point of view.

After the change, MRA calls to AT&T wireless numbers work as expected.