CUBE Configuration Step-By-Step. Part 2

This is a second post in the series of CUBE configuration. You can find the first one here.

In this post, I’ll cover some of the more advanced issues and scenarios that most of us are facing with CUBE configuration.

 

Edit: I recommended using the CUBE Config Utility in conjunction with this post

In the first post, the last step that we were going through was CUBE authentication and registration with ITSP so we’ll pick it up from there.

The next step in our deployment will be the codec selection.

Step 7: Media & Codec selection. The common denominator

Codec Selection

Now, this part can be very straight forward or a complete mess, depends on the complexity of your deployment and the generosity of the ITSP.

What do I mean by that? Well, let’s say you have a single site deployment with CUBE. Your best option is to configure g711 for all VOIP communication and you are done. But what happens if you have a centralized, multi-site deployment (with one CUBE to rule them all) with g729 provisioned as the inter-site codec? And what if your ITSP only supports g711?}

Well, there are probably endless variations and topologies, so let’s define some house rules to make it easier.

First of all, you have to understand what media parameters your ITSP supports.

That’s the easy part. SSH to your CUBE and enable SIP message debug by typing debug ccsip messages. Now, make an inbound call and watch the ITSP’s SDP portion in the INVITE message.

You should be looking at something like that:

 v=0
 o=- 25678 753849 IN IP4 192.0.2.1
 s=
 c=IN IP4 192.0.2.1
 t=0 0
 a=creq:med-v0
 m=audio 3456 RTP/AVP 0 18
 a=tcap:1 RTP/SAVP RTP/AVP
 a=rtpmap:0 PCMU/8000/1
 a=rtpmap:18 G729/8000/1
 a=fmtp:18 annexb=yes
 a=rmcap:1,4 G729/8000/1
 a=rmcap:2 PCMU/8000/1
 a=rmcap:5 telephone-event/8000
 a=mfcap:1 annexb=no
 a=mfcap:4 annexb=yes
 a=mfcap:5 0-11

The a=rtpmap is the parameter you are looking for.

In this example, we can see that both g711 (PCMU) and g729 are supported.

Now, if your ITSP is not using early offer, you’ll have to hardcode g729 on CUBE’s side and watch the SDP included a response from ITSP.

Now that we know what to expect from our ITSP, we can go ahead and decide on the codec distribution in the enterprise.

If your ITSP does support g729, it should be pretty straight forward.

First create your regions in CUCM, as you would normally. In CUBE, have in both ITSP and CUCM facing Dial-Peers, the option to negotiate both g711 and g729. CUBE configuration should like similar to this:

Voice class codec 1
 codec preference 1 g711a
 codec preference 2 g711u
 codec preference 3 g729r8

Dial-peer voice 1 voip
 Description Incoming/Outgoing ITSP
 Voice-class codec 1
 .
 .
 .

If your ITSP doesn’t support g729, some modifications would be required.
Simply put, you are going to have to make a calculated decision regarding what is more costly: adding more bandwidth, in order to support g711 over the WAN or adding more PVDM for transcoding and conference bridging.

If you choose the letter, do remember that you want the transcoding to take place on the CUBE. The recommended configuration would be to use CUBE LTI (local transcoding interface) rather than CUCM SCCP registration.

Basically, LTI has the same features as SCCP based transcoding so do not hesitate to use it. Moreover, it works better for CUBE environments and it will save you some good troubleshooting hours.

Use the following CUBE configuration for LTI based transcoding:

dspfarm profile 1 transcode
 codec g711alaw
 codec g711ulaw
 codec g729r8
 codec g729ar8
 maximum sessions 20
 associate application CUBE

MTP

MTP has several roles which mainly focus on bridging between incompatible media capabilities. Among them are: Early Offer/ Delayed Offer, DTMF, uLaw/aLaw, etc.

Early Offer

Whenever your ITSP requires you to use Early Offer, it is best to use CUBE build in EO capability rather than needlessly introducing an MTP into the call flow. You can achieve this by setting the following parameters in CUBE configuration:

Voice service voip
 SIP
  early-offer forced

Or within a specific dial-peer:

Dial-peer voice 1 voip
 voice-class SIP early-offer forced

As a rule of thumb, avoid using MTP whenever possible as it uses resources and changing the media path. Take some time and design the solution in order to avoid invoking MTP.

If you must, co-locate it with CUBE to optimize the media path. In most cases, software MTP will do the job. Software and hardware MTP are configured the same with one change of parameter:

sccp local GigabitEthernet0/0
 sccp ccm 192.168.1.10 identifier 1 priority 1 version 7.0
 sccp ccm 192.168.1.11 identifier 2 priority 2 version 7.0
 sccp
 !
sccp ccm group 1
 associate ccm 1 priority 1
 associate ccm 2 priority 2
 !
dspfarm profile 2 mtp
 Codec g729r8
 Codec pass-through
 maximum sessions hardware/software 200
 associate application SCCP

If you have a specific scenario that you need assistance with, let us know in the comments and we’ll be happy to help.

FAX

Fax Over IP is a known troublemaker in our community. Ask me and I’ll say that it should have been out the door for a while now, but humankind just can’t seem to let this dying bastard go. Thus, for the time being, we’ll have to learn to live with it.

Since our communication to the provider is IP based, some extra considerations have to be made when using FoIP.

For example, moving to the IP world introduces latency and packet loss towards the provider, flaws which have a great influence on fax transmission. These flaws could be handled on the LAN side and weren’t an issue on TDM links, but on WAN links it’s a different story. Another issue is the g729 codec, which can’t properly encode fax transmissions. Luckily there is a solution.

The solution to both of the above problems is the T.38 protocol. You can think of it as the TCP of faxing. It negotiates, controls and verifies (and re-transmits) the fax transmission.

Once again, our first step would be to check whether our ITSP supports T.38. We can do it the good old way, by just asking the ITSP reps. But, if we want to be on the safe side, debug ccsip messages can give us all the info we need. Just send an incoming fax and watch the SDP from ITSP. And again, if your ITSP is not using early offer you’ll have to hard-code T.38 on CUBE side and watch the response from ITSP. In regards to CUBE configuration, you can achieve this by enabling T.38 on the dial-peer level or in global config. For example:

Voice service voip
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

T.38 version may vary between 0 and 3, so keep your eyes open.

You should be looking at something similar to this in the SDP:

 m=image 17682 udptl t38
 c=IN IP4 192.168.1.60
 a=T38FaxVersion:0
 a=T38MaxBitRate:7200
 a=T38FaxFillBitRemoval:0
 a=T38FaxTranscodingMMR:0
 a=T38FaxTranscodingJBIG:0
 a=T38FaxRateManagement:transferredTCF
 a=T38FaxMaxBuffer:200
 a=T38FaxMaxDatagram:180
 a=T38FaxUdpEC:t38UDPRedundancy

This outcome, as you might have guessed, suggests that T.38 is supported.

Unfortunately, this might not be the end of the road for our FAX adventures. Depending on what you use for faxing in your organization, solutions may vary from Fax Servers and Fax2Mail to analog gateways with physical fax machines. Needless to say that they might not all be happy with our new T.38 friend.

Whenever the ITSP does not support T.38, g711 codec will have to be used end-to-end. Assuming g729 is used towards your over-the-wan site, a specific Device Pool will have to be provisioned for the fax devices to allow g711 negotiation. In CUBE configuration, apply the fax protocol pass-through g711u on the Dial-Peer level or globally under Voice Service Voip similarly to this:

Voice service voip
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

dial-peer voice 1 voip
 fax protocol pass-through g711u

Once you understand your options and what you are up against, you can go with one of the solutions or even both. To allow both T.38 and g711, where T.38 is the first choice and g711 is your backup option, the following CUBE configuration is required:

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback fallback pass-through g711a

Since fax over IP is not the main purpose of this post, I’ll stop here. If you need any help or want to know more, please feel free to write in the comments.

Step 8: SIP compatibility. Dig deeper.

Since ITSPs are vendor agnostic, they will not always fit like a glove. There are several compatibility issues that you might encounter, that would introduce the need for changing SIP headers. It might sound a bit overwhelming at first, but once you get the hang of it, you’ll have a very powerful tool in your hands.

I have already written about two common issues here and here.

You can find the more common examples here.

Step 9: CUBE Configuration. Secure the perimeter.

We’ve already established the fact that CUBE is not an information security device. Having said that, it does have some security features. Most of these features are related to layer 7 UC applications that you should implement to secure your environment.

IP Address trust list.

Having a SIP-UA that fronts the internet with access to the PSTN is an obvious security issue. You wouldn’t want every SIP client out there to send invites to your CUBE, using it as a proxy to call whoever he wishes. To avoid that, Cisco had implemented a “white list” feature to filter out unwanted leeches.

The rules are basic. Every IP address that appears under a session target ip within a dial-peer, is trusted by default. All of the other addresses must be manually entered.

For example, if your ITSP provides you with a hostname for his SIP proxy, resolve the name to IP and place it in your trust list. It is recommended that you send an inquiry to the ITSP to get all of his active SIP servers IP addresses.

CUBE configuration should look like this:

Voice service voip
 ip address trusted list
  ipv4 81.1.1.1
  ipv4 81.2.1.0 255.255.255.0

After you are done with building the trust list you can add another layer of defense from TDoS attacks by adding the command silent-discard untrusted. This command will just ignore incoming messages from unauthorized entities instead of responding with a 403 error. If your router is above 15.3.3M this option is enabled by default.

Voice service voip
 SIP
  silent-discard untrusted

Another thing you want to consider would be disabling the local registrar feature. Since in most scenarios, no one is going to be registering to your CUBE, it’s a good practice to disable it altogether.

Voice service voip
 SIP
 no registrar server

Let me know if you find this helpful and need any help with your deployment!

Image Designed by Freepik

---