PSTNgine – An Open-Platform PSTN Alternative

screen shot 2019-01-19 at 2.22.36 pm

Overview

One of the items that has long perplexed me in our industry is the stranglehold the carriers have on the market. In many market’s there is only one reasonable option for service and they all work in what feels like an archaic fashion. For instance, I’ve always found the idea of porting numbers between carriers to be strange and that I should be able to own my number and do what I please with it.

I’ve always thought there was big innovation to be had in this space. With the telecommunications market consolidation the past 15 years, they can charge whatever they want for what is essentially internet traffic. We have seen cord-cutting of cable providers in mass, and the PSTN will be next.

Last year, I had some long sleepless nights and I started building a small prototype of something I have been calling PSTNgine. It is powered by SIP and it’s more of a self-registration and ownership platform that lives in the public cloud. It works off current E.164 numbers and provides an alternative path home for the same numbers. Think of it like DNS for public phone numbers.

The general concept is the more companies and individuals who join the network, the more power the carrier loses over the PSTN. The apps and integration points integrate with the traditional PSTN making it seamless for users to adopt with no downside.

screen shot 2019-01-19 at 1.21.32 pm

Solution Benefits

I’m sure the first question your asking is, “Why would I even want this?”.

Lucky for you. I’ve compiled a short list of reasons which by no means represents every use case of the platform.

  • Flexibility: You own your numbers and what happens to them, there is no more ‘porting’ you just point your numbers to the IP address or endpoint you want, when you want. Think of it like an Open-Source PSTN or a DNS system for PSTN numbers.
  • Ease of use: Our mobile apps will let you register any number you can prove you own, including land-lines or small business toll-free, right to your cell phone.
  • Cost Savings: Since all traffic is sent over the public internet you’re using the bandwidth you already own, whether that call is going to Asia or a cell phone. We will obviously be charging for this service, but overall, way cheaper than using traditional PSTN for many types of calls such as international or toll-free. As the network grows everyone on it will save more.
  • Developer Friendly: Our platform is a full SIP Stack in the cloud including support for registration and WebRTC. Not only will we be kicking the PSTNs but you can register some devices and get the full power of a SIP Cloud with the phones you own today!
  • Cloud Apps: Imagine being able to use the full suite of services that were developer for the business user, on your PSTN/Toll-Free number. You’ll be able to power a deep SIP experience with APIs.
  • Open Platform: We don’t want to become the next carrier either, we want to build a new type of network, so we’ll offer access to our E.164 registration data for qualified partners who want to integrate into our SIP network. Terms and conditions will apply to prevent maliciousness.

See it in action:

Solution Design

SIP Core – Proxy

At the heart of PSTNgine is farm of SIP proxies which obviously may need to grow or adapt over-time but for this first couple million users will do just fine. Enough to prove the concept works. The general idea is simple you can send any E164 number to us by shooting a call to @proxy.pstngine.com (ie. +19802180991@proxy.pstngine.com) and we will try and get it home for you. If we can’t, you will get a 404 like normal.

Requirements

A requirement for the enterprise customers is that you must have a public termination point for SIP and RTP. This would be a Proxy or Gateway that has a public IP address or in Cisco, an expressway. Our service lives in the public internet and we expect your on-ramp to be public.

Our SIP registration platform does support NAT if your equipment is configured properly. We can help you determine this and easily give you free testing endpoints. 95% of NAT devices will work fine with no changes to routers.

Phone Number Registration

Anyone can stand up a SIP proxy but the trick here was making it scale and be manageable. At the core of this is a DNS like database that takes an E.164 number and figures out what IP to send the request to (and if any translations should be applied). For example when you call +19802180991@proxy.pstngine.com, it will eventually make its way home to 4002@cloverhound.com. The default without a translation would be +19802180991@. Your domain is defined at an organizational level in PSTNgine.

If you call my cell phone, +19803338415@proxy.pstngine.com you will eventually make it to my iPhone app running call kit. It’s a native IOS, nice experience. We will of course release a similar Android app.

Once you build an account on our site you can register numbers or ranges of numbers with some two-factor like auth. (We dial the numbers you put in and you enter in the code we tell you, to confirm you own it). For large enterprises, it will be easier to provide us with billing records from your carriers. We will configure it all per your requests and then give you access to your portal for management.

PBX Integrations

The unique opportunity here is for a Cisco PBX for example there is a single integration point to bring your entire network of phones and DID’s onto our network and enabling least-cost routing with out entire network of users. Let’s walk through it with Cisco.

Pre-Requisites with Cisco: 

  • Expressway
  • Communications Manager.
  • Register your egress/ingress point with PSTNgine.
  • DNS records for your endpoints (if using DNS).

Inbound: For any DID you own you will receive requests to your expressway in the format of @<yourdomain/ip>. It’s your job to get those URIs home to your phones just like normal PSTN calls.

Outbound: This is where we do a bit of magic. You’re going to route every single call that would normally go to the carrier to PSTNgine to see if it exists on the network. If we don’t have it we will respond with a 404 and you will go to your normal carrier, here is what that would look like.

  1. Create a Route Group with the trunk to Expressway.
  2. Create a Route Group with the trunk to your CUBE/Carrier.
  3. Create a trunk in your expressway with the creds we have given you.
  4. Create a translation in Expressway to append @proxy.pstngine.com and fire off the calls to PSTNgine.
  5. Create a Route List with the Expressway Route Group first, and your normal carrier second.

You may want to lower your SIP Retry timers to 250ms just in case our service ever has an issue, that would make an outage seamless to your users.

Every-time a company joins or a person registers a number, every other user on the network gets seamless access to cheaply calling them. The network will grow exponentially every-time a new business joins.

Mobile / Land Line integrations

At launch, an iOS and Android app will be available that sets your mobile phone up on the network with just a couple clicks. This will allow businesses to easily access their employees on the network as well as allowing any individuals access to the network for least-cost calling.

Businesses adopting this for Toll-Free numbers may see greatly reduced costs as the network grows.

SIP Registration

The platform also includes a full SIP Registrar which can support everything from Cisco Phones to WebRTC clients (SIP-WS, such as sip.js library), to our mobile clients. This means if you don’t have your own PBX or are looking to move to IP Phones or to cloud registration, you can use us directly as you voice backend. (Voicemail, transfer, conferencing, IVR, contact center available).

Carrier Access

We have brought a few carriers into our network for use on our platform. As our design calls for, our PBX / direct registered users would want access to the traditional PSTN for calling outside of our network. These services will be available for consumptions by our SIP registered users and for businesses who request access because it may be cheaper than their current carriers for some countries.

Security

Security on our platform will work very closely to how to how firewalls on AWS. You will be required to provide us with your public IP addresses and ports for receiving SIP and RTP. We also offer VPN services for customers trying to connect to our cloud more securely or with a private network

User Interface

Unlike every carrier, our system allows self-provisioning through an easy to use, web interface. This means you can build SIP Trunks or change your firewall settings without the help of us. You can register devices, build WebRTC clients and do mostly everything on the platform yourself.

The one thing that would be very time-consuming would be registering ranges of DID’s. You can register a few manually for testing and we recommend working with us over Email to get large blocks added.

Open Data and APIs

If we are going to change the PSTN game, we can’t set out to be the next carrier. We’ll provide access to the E.164 least-cost routing database through an open access API for other carriers or users who want to build services that are like-minded or work with our service.

API’s for call interactions will be capable on the platform. The including starting SIP sessions and controlling them from the cloud which should allow all types of neat integration. These will be powered by REST calls or Webhooks depending on activity required.

Conclusion

The future of the PSTN and of telecommunications is awesome and its pure cloud. There is just way more bandwidth out there then it takes to make a phone call nowadays. 15 years ago, having all this on your LAN mattered, but I argue it doesn’t anymore.

What this change is doing is breeding incredibly innovative solutions, because supporting the development of cloud solutions is just way more efficient. Support organizations get smaller and dev teams with innovation get bigger. What we’re doing is introducing this to the PSTN, an old archaic industry.

We are still building this out, but as we have, you get a feel that not only is the PSTN outdated, but SIP has much bigger dreams in the cloud, than behind your firewall.

I’d love to get your feedback and would be happy to let you use our cloud to do some least-cost routing or register some devices to do some test calling. We have a Cisco Phone builder for our cloud and Cloverhound has been using the platform for about a month for basic inbound and outbound. All of the above plans are not implemented yet so things are at best, an early alpha. Try at your own risk.

Twitter – @chadstachowicz
Email – chad@cloverhound.com
Phone – 980-333-8415

Standard

Cisco Spark Hybrid Services – Call Service Connect Deployment

Introduction

Undoubtedly we’ve all heard about Cisco Spark over the past year. Lumped in between the cloud and the cloud’s cloud, there is a component referred to as Hybrid Services. Hybrid Service is summed up as multiple components designed to bridge the preverbal gap between the Cisco Collaboration Cloud and your On-Prem UC (Unified Communications) infrastructure. For some of us, migrating to the cloud may not be an option for quite some time, if ever. Designed to introduce the customer to Cisco’s Cloud offerings, Hybrid Services aims to highlight the benefit of having a unified experience for all collaboration applications. This article is aimed at the engineer looking to deploy the Call Service Connect feature into their companies infrastructure, all the while helping us see a world that is Jabber-free. For instance, If I receive an incoming call on my 10 digit DID (Office number), Call Service Connect will allow me to receive that same incoming call through Cisco Spark on any of my mobile devices. Pretty cool, right? Likewise, outgoing calls to the PSTN are also routed out of your company’s gateway via SIP Trunk or PRI.

Preparation

Let’s make a few assumptions. The first being that you have a working CUCM (Cisco Unified Communications Manager) and the second being that you have read our deployment guide for Expressway located here and here, respectively. Strap yourselves in, it’s a two parter. Satisfying those requirements will help immensely with the configuration and troubleshooting in the next few sections.

The below diagram depicts what the Call Connector will look like in your environment.Screenshot 2016-08-15 12.56.21.png

Its important to note that you MUST and I mean MUST be running Expressway 8.7.1 or higher on your Expressway-C. The image below was taken directly from the deployment guide. Certain pieces will work on 8.7, but the guide specifically mentions that in order to take “full advantage” of the feature, you need 8.7.1. In addition, CUCM MUST be chugging along at 10.5(2)SU3. The guide(s) I used from Cisco are here and here.

Screenshot 2016-08-15 13.12.29.png

Configuration

Let’s start by agreeing CUCM and Expressway meet the version requirements for this to work. k? cool. Next let’s make sure we have DNS working as it should. Below you’ll see our SRV record we use. The Spark application uses this to route calls destined for your CUCM infrastructure to the correct host. Spark does an SRV lookup for the protocol sips using tcp as the transport protocol and sipmtls as the subdomain for this domain. In our case, we weight this record at 1 (lower value is more preferred) and priority at 10 (only relevant if we have more than one SRV record). The port we tell it to use is 5062 (Mutual TLS) and the target is our Expressway-E (expressway.cloverhound.com). Like B2B or MRA, this uses the same protocol with the exception of us having it use 5062 instead of 5061. If you are using 5061 for MRA today, changing the MTLS port will break connectivity.

➜ ~ nslookup
> set type=SRV
> _sips._tcp.sipmtls.cloverhound.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
_sips._tcp.sipmtls.cloverhound.com service = 1 10 5062 expressway.cloverhound.com.

Since we just declared that Cisco Spark should use 5062 on all inbound connections to our Expressway-E, we need to tell Expressway-E that. Below are our SIP settings. Ensure you have Mutual TLS mode set to On and its using 5062 as its Mutual TLS port.

Screenshot 2016-08-15 13.52.24.png

 

Once DNS is verified and the Expressway-E knows that port to use for MTLS, let’s hop over to CCM (Cisco Cloud Collaboration Management). From there, navigate to Services, Hybrid Call; Settings. Scroll down to the bottom and enable Connect. Under SIP Destination, enter in sipmtls.yourdomain.com. yourdomain will be the external DNS zone you used for your SRV entry above. This step ensures calls destined for your org make it to your Expressway-E. It does this by doing an SRV lookup against the sipmtls service offered by cloverhound.com. Another item involving DNS you will want to take care of while you’re here is Aware. Most notably, Aware makes Spark “aware” of all calls across your UC system enabling Spark to view recent call history. To verify your domain as a valid domain for your org, click Add Domain.

Screenshot 2016-08-15 13.57.59.pngScreenshot 2016-08-15 14.00.13.png

Enter in the domain you wish to add. After submission, the domain will go into a Pending state. Select Verify. In order for Cisco to verify you own that domain, it forces you to manually add a TXT record to your domain’s external DNS zone file. Simply go to your external DNS manager and create a new TXT record with the string below. This string will be unique to each domain.

Screenshot 2016-08-15 14.10.02.png

To verify, let’s look at our external DNS zone to ensure it created the record. For obvious reasons, we can not verify test.com since we don’t own it. Instead, we will use cloverhound.com.

➜ ~ nslookup
> set type=TXT
> cloverhound.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
cloverhound.com text = “7744b423ac3a7d45bb83103d9a645168f3e3db5d9e52880f197e6638c7eefa3c”

 

Once DNS is configured and we’ve verified that inbound Spark calls to our org will route to the correct place, we need to head over to our Expressway-C and configure the CUCM integration. From Application>Hybrid Services>Call Service select New and add the CUCM IP address. Select Verify CredentialsNOTE: This user must have AXL and CTI access permissions. 

Screenshot 2016-08-16 13.00.31.png

Once verified, the status on both CTI and AXL will change to up. If you run into issue with this part, verify application user permissions for the account you used, as well as the AXL Web Service. Ensure it is running.

Screenshot 2016-08-16 13.04.27.png

Once added, navigate to Application>Hybrid Services>Call Connector and toggle the Active radio button to Enabled. This will start the Call Connector.

Screenshot 2016-08-16 13.49.15.png

Now that we’ve enabled the Expressway-C, we need to start work on how we’re going to place and receive calls. As depicted by the diagram, the call originates from the endpoint signaling CUCM where the destination is. As we can see, both outbound and inbound calls traverse the Expressway-C and E through the Unified Communications traversal zone. Outbound calls from CUCM to URIs will look at the SIP Route Pattern. In our lab, we are using * to default route any domain not matching a specific one to the trunk towards the Expressway-C. As this is a lab, we ensure that all domains listed as a destination in a SIP header get routed. The official guide will have you use *.ciscospark.com as your SIP route pattern. Screenshot 2016-08-16 13.59.50.png

Once the destination is matched to a SIP route pattern, it routes to the Expressway-C.

Screenshot 2016-08-16 14.22.01.png

The Expressway-C then looks at its Search Rules and determines the best match for the destination to route the call. In our case, we again have a default rule to send anything not matching a specific domain towards the Expressway-E. We do this because during the selection process, it queries its local zone for the destination. As the destination *ciscospark.com doesn’t match any of the URIs on CUCM, it knows to send it on. Below is our rule we use to match.

Screenshot 2016-08-16 14.07.21.png

In our case, the TraversalZone is the Neighbor Zone to the Expressway-E. As this call enters the Expressway-E, it looks at its search rule to find where to go next. As you see by our outbound search rule towards CCM, we see it is matching any pattern string that contains @ciscospark.com and routing it out the DNS Zone Cisco Spark Hybrid ServicesScreenshot 2016-08-16 14.34.39.png

The Cisco Spark Hybrid Services DNS zone then makes a determination on where to send the call based on the configuration we have listed below. This configuration is similar to default DNS zone you most likely have on your Expressway-E with the exception of isolating the destination to look for. As this is a MTLS connection, we want to ensure TLS Verify mode is set to On as well as including the TLS Subject Verify Name of callservice.ciscospark.com. This ensures that all routes routed to this domain are encrypted using TLS.

 

Thats outbound. Let’s work on getting inbound calls. Since we have already completed the requisite steps above when we first started, all we need to do is ensure users have a Spark Remote CTI device in CUCM. Under your Unified CM Server setting on your Expressway-C there is an option for your Call Service Connect Configuration. For our lab, we opted for automatic provisioning. If you have thousands of devices, manual import may be better. Once you’ve done that, you will need to go into CCM and enable Connect for the users you want Call Service Connect enabled for. Toggle the switch to On and restart the Call Connector on the Expressway-C.

Screenshot 2016-08-16 14.52.38.png

Almost there. After Call Connector restarts, you should now see the Onboarded Users change to reflect the number of users you enabled for Call Service Connect.

 

Screenshot 2016-08-16 14.54.37.png

To verify, check CUCM to see the automatically provisioned device.

Screenshot 2016-08-16 15.01.02.png

From the Spark cloud, we can now work through getting calls inbound to our remote CTI device (Cisco Spark application). Caller A initiates a call to Caller B via their PSTN number (7048675309). Caller B will receive an inbound call to that PSTN number through the Spark application. It does this by matching inbound URI destinations. For example, when the Expressway-E receives a call, its destination will look like this:

sip:+17048675309@cloverhound.com;user=phone

Our Expressway-E has a Search Rule targeting the Traversal Zone. This is directing all incoming URI destinations towards the Expressway-C. Screenshot 2016-08-16 15.11.20.png

Once our Expressway-C receives the SIP packet from the Expressway-E, it then looks where to route calls with the destination +17048675309@cloverhound.com;user=phone. As you can see by the below figure, its matching any destination with the @cloverhound.com;user=phone suffix. The target destination to route this call is CUCM Neighbor. In this case, that is our CUCM. Screenshot 2016-08-16 15.17.13.png

One of the most time time consuming parts in all of this was the last part. I was able to get calls outbound and inbound but CM traces showed me that once the Expressway-C sent the calls to CUCM, it was stripping everything but 4 digits. If you are a victim of this nonsense, make sure to check the incoming allowed digits on the SIP trunk connecting CUCM to Expressway-C.

Screenshot 2016-08-16 15.19.28.png

We hope this guide can provide benefit in configuring Cisco Spark Hybrid Services for your organization. For any revisions, questions, or comments, feel free to contact myself directly (through Spark obviously) or drop a comment below.

2016-08-16 15.30.05.png

Standard

Tropo Log Tailing

Working with Tropo’s scripting API is a quick and easy way to get great call and SMS functionality into your applications. But while building with the scripting API is great, debugging your code can be very frustrating.

Currently, to get a peek into what’s happening on Tropo’s end, you need to download your logs from their application manager on Tropo.com. These log files can grow very large (over 100MB) and load very slowly in their in-app editor. It’s also highly difficult to parse through the logs to find information that is relavent to what you are doing at that moment.

Most apps today have great real-time logging, like Ruby on Rails which lets you dig into the details of your app and see it executed in real-time. To bring this kind of experience to Tropo development, I’ve created the tropo_tail gem.

Tropo Tail Gem

To install, from your terminal or command prompt, type:

gem install tropo_tail

Installing this gem will give you access to the

tropo_tail

command. Upon running it will ask you for your Tropo username and password. This is to login to Tropo’s FTP server. The gem will then feed the log file as it is generated on Tropo’s servers to your terminal in realtime!

You’ll notice that Tropo’s logs come with a lot of information, sometimes too much. To help with this during development you can use a flag:

tropo_tail --truncate

This will cut off a large portion of Tropo information such as the application ID and session ID, and let you see Tropo’s output and a timestamp.

In addition to helping debug issues with the scripting API, this will work for any Tropo applications including those using the webAPI to help get an inside track into what’s going on behind the scenes and help you develop higher quality apps in no time at all!

Standard

How to Click To Call Back With Tropo and Ruby on Rails

In this post, we’re going to build on our previous work on number masking. Let’s say you’ve created a mask for your number and someone called that mask. Now you want to call that person back. How do you do so without revealing your actual number?

Here’s how. Once again, we’ll be focusing on the Tropo back-end side of things.

 

Steps:

  1. Create a model for saving call history.
  2. Create a view that shows this history and allows you to click on a number, triggering call_back
  3. Have Tropo call you and add you to a unique conference
  4. Have Tropo call the other person and add them to the same conference

 

Reminder: number is your actual phone number, while a mask is the phone number that is made publicly available. Calls to the mask get transferred to your actual number, keeping it anonymous.

 

Create a model for saving call history and a view for triggering the call back

We want to keep track of all calls made to a mask. To achieve this, we create an inbound_calls model that stores the number of the person calling and the time that the person called. An inbound_call belongs to a mask, which allows us to also keep track of the mask that was called and the number associated with that mask. Remember from our previous blog that a mask belongs to a number. 

Here is example code that stores an inbound call before making the transfer.

def transfer

    from = params[:session][:from][:id]
    to = params[:session][:to][:id]
    timestamp = params[:session][:timestamp]

    mask = Mask.find_by mask: Phonelib.parse(to).e164
    number = mask.number.phone_number

    inbound_call = InboundCall.new(from: from, mask: mask, time: timestamp)
    if !inbound_call.save 
        puts "Creating inbound call failed: #{inbound_call.errors.to_json}"
    end

    t = Tropo::Generator.new  
    t.transfer(:to => number, :from => from)

    render :json => (t.response)
end

 

Note that Tropo provides the timestamp of the call in the session timestamp parameter. Here is an example view for triggering the call backs.

inbound_call

 

 

Have Tropo call and add people to a conference

def call_back(from, mask, number)
    conference_id = from.to_s + mask.to_s + rand(1000).to_s
    tell_tropo_to_invite_to_conference(conference_id, from, mask)
    tell_tropo_to_invite_to_conference(conference_id, number, mask)
end
def tell_tropo_to_invite_to_conference(conference_id, to, from) 
    token = APP_CONFIG['TROPO_CONFERENCE_INVITE_APP_TOKEN'] 
    tropo_params = {action: "create", conference_id: conference_id, to: to, from: from, token: token} 
    
    response = tell_tropo(tropo_params) 
    if response.code === '200' 
        puts "successfully invited #{to}" 
    else 
        puts "error: #{response.body}" 
    end 
end 

def invite_to_conference 
    from = params[:session][:parameters][:from] 
    to = params[:session][:parameters][:to] 
    conference_id = params[:session][:parameters][:conference_id] 
    puts "Inviting #{to} to conference #{conference_id} with callerid #{from}" 

    t = Tropo::Generator.new 
    t.call(to: to, from: from) 
    t.conference({ name: conference_id, id: conference_id}) 

    render json: t.response 
end 

def tell_tropo(tropo_params) 
    uri = URI.parse('https://api.tropo.com/1.0/sessions')   
    uri.query = URI.encode_www_form( tropo_params ) 
    http = Net::HTTP.new(uri.host, uri.port) 
    http.use_ssl = (uri.scheme == "https") 
    request = Net::HTTP::Get.new(uri.request_uri) 
    return http.request(request) 
end


These methods are in the controller. The call_back method starts the whole process. The from is the number of the person we’re calling back. The mask is the mask that the person called. And the number is the number associated with the mask, i.e., your number. We will use the conference_id to invite people to the conference. We create a unique conference_id each time the call_back method is ran, or else every one will be added to the same conference.

The tell_tropo_to_invite_to_conference method tells Tropo to start the Tropo application that we created for inviting people to conferences. The script link we provided in that app points to our invite_to_conference method. The invite_to_conference method calls in a person to the conference_id provided. We pass the conference_id and other parameters to the invite_to_conference method by including the parameters as part of the query. We then access these parameters in the invite_to_conference method via params[:session][:parameters]. Notice that when calling the other person, the callerId is set to the mask, keeping your number anonymous 🙂

The tell_tropo method simply makes a GET request to Tropo with the query parameters that are passed in.

Here are the Tropo docs for making a call, setting up a conference, and passing parameters:
https://www.tropo.com/docs/scripting/call
https://www.tropo.com/docs/webapi/quickstarts/controlling-calls/creating-conference-call
https://www.tropo.com/docs/scripting/quickstarts/making-call/passing-parameters

 

And that’s it! You can now call back people without revealing your phone number.

Standard

CiscoCSVToolkit

I’ve put together a collection of Ruby scripts for preparing exported CSV files from CUCM 7.x to import into CUCM 10.x and above. Download them here.

Background

When migrating configurations between CUCM 7.x and CUCM 10.x and above, a typical task involves using the Bulk Administration system to export phones and configurations as CSV files. One of the issues with importing these CSV files directly into CUCM 10.x is that there are many headers in the 7.x CSV file format that aren’t supported in CUCM 10.x and will cause a failed import. These files will help to clean up the exported CSV files as well as provide some basic filtering functionality to limit the import to certain users and phones (as the CSV files can be very large sometimes they can be difficult to work with in Excel). Before importing any files be sure that your new CUCM system has all referenced dependencies configured (device pools, partititions, etc) or the import will fail.

Usage

From your 7.x Cisco Unified CM Administration page, navigate to Bulk Administration > Phones > Export Phones > All Details. Select “All Phone Types”, add a name for your export, select “Run Immediately”, and then click “Submit”. Next go to Bulk Administration > Users > Export Users. Click “Find” to pull up all user accounts, and then click Next. Input a file name and select “All User Format” for the file format. Select “Run Immediately” and then click “Submit”. Both of these export jobs can be viewed in Bulk Administration > Job Scheduler and, once completed, can be downloaded from Bulk Administration > Upload/Download Files. After downloading rename the files from .txt to .csv and place them in the CiscoCSVToolkit folder.

Replace the importfile variable in the stripbadcolumns.rb script to match your exported phone CSV file. Next run the script from a command line (ruby stripbadcolumns.rb). It may take a little while to run. This will save a file called “forimport.csv” that you can upload to your 10.x system and run using Bulk Administration > Phones > Insert Phones.

If necessary you can use the filterbydevicepool.rb script on your forimport.csv file to limit which phones you want to import by device pool. You can also use the filteruserbypartition.rb script to filter your exported user CSV file by the primary extension’s partition.

Standard

Prime Collaboration 11.x Review – Part 1 – Deployment

Background

The Prime Collaboration Suite from Cisco consists of three components – Deployment, Provisioning, and Assurance. When these products were first released I didn’t hear a lot of good things about them (sorry Cisco), so I avoided them with most of my deployments. That said, it looks like Cisco has made a lot of updates in the last release and I wanted to get an unbiased review of each of these three products and if they are worth using in my upcoming projects. Prime Collaboration Standard is included with CUWL licensing since version 10.x – so if you have CUCM 10.x and higher, you can use these products. You can’t beat free, right?

This will be the first of three blog posts, each one focusing on one of the Prime Collaboration products. I’ll cover some Frequently Asked Questions, an overview of the benefits and drawbacks of using each product, and my experiences using it in the lab and in customer environments.

What is Prime Collaboration Deployment?

Prime Collaboration Deployment (or PCD) is meant to help manage installations, upgrades and migrations on to VMWare ESXi platforms. Cisco’s intention with these products seems to be making it easier for customer IT departments to manage Collaboration implementations once they are up and running, but it also can make some tasks much easier for partner consultants to initially set things up. Some of these things it does really well and can save you a lot of time, and some of these things may only be beneficial in certain situations. I’ll give my overall review and feedback of each function below.

How Do I Install PCD?

All Prime Collaboration images come preinstalled with any BE6k or BE7k installation, which can save some time with initial installs. In fact, Cisco has a new Config To Order Portal (CTOP) that lets you preconfigure a BE6k during the ordering process with IP addresses so it comes ready to go! Check out https://www.configtoorder.com for more information on this.

If you aren’t using a BE6k or need to install it from scratch the process is very similar to setting up a CUCM or other VM based UC server. Simply deploy the OVA and then mount the bootable ISO image and boot the VM. Sadly the bootable ISO image is not available from CCO, so contact your Cisco account rep if you need to get a copy of the bootable version. Non bootable upgrade images and OVA templates are available here.

One thing to note that I learned the hard way – do not change the IP address of the PCD server after installation. It will seem to work fine and load the admin page, but most tasks will fail without any helpful error messages. If you do have to change the IP, just reinstall the server. I would also recommend disabling LRO on any ESXi blade before running your VM install tasks to reduce failures due to time of installation.

What Licensing Is Required?

To me this is one of the really dumb things about PCD – the normal license that you would get from Cisco for ESXi does not actually support the VMWare features that you need to use PCD. During the initial 60 day evaluation period for ESXi all features are enabled, so you could use PCD during that time, but once you apply the license you would normally get with a BE6k or BE7k type server you can no longer mount the NFS stores from PCD. To me PCD should not only be for initial deployment of images but also for managing the system after that point for patches. If you want to do this be sure to purchase the higher license type. From the documentation:

The following are compatible with Cisco Prime Collaboration Deployment:

  • Cisco UC Virtualization Foundation (appears as “Foundation Edition” in vSphere Client)
  • VMware vSphere Standard Edition, Enterprise Edition, or Enterprise Plus Edition
  • Evaluation mode license

The following are not compatible with Cisco Prime Collaboration Deployment:

  • Cisco UC Virtualization Hypervisor (appears as “Hypervisor Edition” in vSphere Client)
  • VMware vSphere Hypervisor Edition

New Installations – 6/10

PCD can potentially save you some time in the initial deployment of UCM, CUC, and IM&P servers onto ESXi blades. Especially if you have a lot of servers to deploy. That said, I had issues deploying IM&P and couldn’t get an installation to successfully complete (this may have been related to an issue with my ESXi server, but I couldn’t get it to work after multiple attempts). It seems to take a lot longer than doing the installations manually, and on failed attempts it takes a long time to know that things failed, and the information provided isn’t as useful as it could be. I would like to see Cisco add diagnostic dump file information to failed installs automatically to assist in troubleshooting when this happens. Also once an install task starts running it is impossible to cancel it.

The process is pretty straightforward to get new installations running:

  1. Log in to the web interface using “globaladmin” account.
  2. Upload all bootable ISO images to the built in SFTP server in PCD under the /fresh_install folder. Note that you have to use the adminsftp account to connect to SFTP, which uses the same password as the globaladmin account you used on setup. PCD lets you set up external SFTP servers, but it doesn’t seem like you can use these for much of anything, so stick to the built in server for images and other ISOs.
  3. From your vSphere client, deploy the OVA templates for servers you want to install on your ESXi server but don’t start them or mount any ISO images.
  4. Set up all UC server records in DNS ahead of time. This will save you time in failed installs.
  5. Add your ESXi blades in PCD under Inventory > ESXi Hosts. This lets PCD use NFS to mount ISOs and manage the VMs on the server.
  6. Add your UC servers that you want to install under Inventory > Clusters. You can’t group CUC together with UCM and IM&P, so set up one cluster for UCM/IM&P and one for CUC. Be sure to select the “Publisher” task under both your UCM Publisher and also your IM&P primary server (this was a bit unintuitive for me at least). I have no idea why “Primary Voicemail” is an option for the server role in CUCM, so I didn’t check that box.
  7. Set up your install tasks under Tasks > Install. PCD will search the local datastore for the ISO image appropriate to your deployed OVA template. PCD will complete UCM publisher install tasks before running subscriber installs or IM&P, and it seems to add your server references to UCM for you, so you don’t need to do any of that.
  8. Expect to wait a while (6-8 hours potentially) for your install tasks to come back and say they are complete. As I mentioned, this is a bit slower than doing things manually, but the installations are completely unattended so you don’t have to sit there and enter any information or watch reboots. Which is nice.

Upgrades – 7/10

Upgrade tasks are pretty easy, whether it’s installing a patch or adding a locale file. Simply add the files to the /upgrade folder using SFTP and add a new upgrade task under Task > Upgrade. I can’t speak for doing major version upgrades using this feature, but doing minor release patches was very easy. I also like the capability of scheduling upgrades for later (such as during your maintenance window), and the option to reboot back into the same version you were running before. This would allow you to complete your upgrade but wait until a later maintenance window to actually make the upgrade live.

Migrations – 8/10

This is really where PCD might let you do things that there is just no clean way to do otherwise. I have recently had a few projects where I had to move a customer from UCM 7.x to 10.5 and had to do a lot of painful editing of CSV files to export/import configurations – and still had to do a lot of manual configuration on top of that because Import/Export just wouldn’t work. I now wish I had used PCD migration for these. That said, this function is only available during a fresh install – you can’t migrate configurations onto an already installed cluster. Also note that you can only do migration tasks for the last 3 versions of UCM, so if you installed PCD 11 and wanted to migrate from UC 7 this would not be possible (but would be if you were using PCD 10).

You can also use this task to migrate UCM running on non VM servers onto ESXi for the same version, and then upgrade to new versions on the ESXi servers. Or you can readdress servers, which is a common step during these sorts of projects.

I haven’t used the migration tasks for production customers yet, so when I do I will come back and update my review, but based on what I’ve seen so far I would definitely recommend using PCD for these sorts of projects, and will be doing so myself in the future.

 

Standard

Connect to console using Terminal on OSX

For longer than I  can remember, I’ve used SecureCRT for all of my console needs. By far, the easiest and most intuitive application for ssh/telnet/console. With that said, we’ve all at one time or another been in a situation where we had to make due with what we had. Recently, I did an upgrade of OSX rendering my SecureCRT unable to open. After countless reboots, it came back to life. This got me thinking…..What would I do without SecureCRT? I’ll tell you. Use my Mac in all its glory to achieve the same goal. This is where I am today. Connecting to the console using terminal.

  • Open ‘Terminal.app’ on your Mac running OSX . Yours should look similar to this.

Screenshot 2016-01-20 14.00.57.png

  • Change your working directory to /dev by entering the command below. You should see your working directory change.

Screenshot 2016-01-20 14.03.04.png

  • Next, we’re going to make sure our USB to DB9 adapter is plugged in by issuing the command below. This command tells Terminal.app to return any lines that match usb. As you can see, I have two devices available. Most commonly, yours will be cu.usbserial.

Screenshot 2016-01-20 14.08.23.png

  • Now that we’ve verified we can see the adapter, time to connect. Issue the screen command followed by the full path of the device, plus the baud rate. In most cases, 9600 baud rate will work fine, especially if it is a newer Cisco device. This number is issued as a command line argument after specifying the full path of the device. See example below.

Screenshot 2016-01-20 14.13.17.png

  • Press Return/Enter to connect.
  • As you can see, the tab has now changed to screen. This is because we are now in the application window. NOTE: Control+C will not work here. To exit the screen application, issue CTRL+A then CTRL+\ You will be prompted “Are you sure?.” Of course you are. type and then enter. This will drop you back into working directory you were in before.

Screenshot 2016-01-20 14.15.34.png

 

We hope this helps a few of you out there who, like me, struggled with finding an alternative to ol’ trusty SecureCRT. Let us know if this has saved you once or twice…or if this is your daily routing by dropping a comment below!

Standard