I was looking for a way to use CCD to simplify a CUCM deployment with Tail-End Hop Off (TEHO).
What I found out was that, in the end, there was no real configuration savings. I just ended up defining the patterns on the router instead of the CUCM.

Hopefully Cisco will, in future versions, provide additional options that will increase the flexibility of this technology.

So, to get started we need to build our SAF network. A couple of things to keep in mind:

• SAF requires IOS 15.0
• If your interconnecting network does not support SAF, you will need loopback interfaces on your SAF routers.
• SAF is an extension of EIGRP, but you do not need to run EIGRP as your routing protocol, it will work even if you use static routing since it operates in a separate instance.

Enabling SAF on routers


router eigrp saf
service-family ipv4 autonomous-system 10
topology base
neighbor 10.0.0.10 Loopback 10 remote 10

Take not that the eigrp instance does not have to be named saf and the AS does not have to be 10.  But keep track of these values, whatever you make them.

To connect to a CUCM system, you will also need to configure an external client login on the system.  This is fairly straightforward.


service-family external-client listen ipv4 5050
external-client CUCM
username safuser
password safpassword123
keepalive 360000


Again, CUCM was chosen at random, you can make it whatever you want, just keep track of the value.  You should note that the external client password must be at least 14 characters long.

You will also need to attach it to the eigrp instance.


router eigrp saf
service-family ipv4 autonomous-system 10
topology base
external-client CUCM


So with that our SAF networking is complete.  There are some other considerations if your network has point-to-multipoint connections in it.  Please reference the Cisco whitepapers for this as I am not going into detail on it.

Now for the CCD portion.  Remember,if you’re running 15.1 or higher to either disable the toll-fraud feature, or configure it properly, otherwise calls will fail.


voice service voip
no ip address trusted authenticate


Now for the CCD portion… Really this time.

First we need to enable the CCD service on the router.

voice service saf

Then we create a trunk profile.  This tells other devices what protocol to contact us with.

profile trunk-route 1
session protocol sip interface Loopback 10 transport udp port 5060

Next we need to define the “routes” to advertise.

profile dn-block 1
pattern 1 type global 1206XXXXXXX

Still pretty straightforward right?

Next step is to build a callcontrol profile to tie them all together.  Note that the numbers next to dn-block and trunk-route match the ones defined above.

profile callcontrol 1
dn-service
trunk-route 1
dn-block 1

Finally we need to associate the callcontrol profile(s) to our SAF instance as a channel.  Here’swhere we need to remember what we called our EIGRP instance and what AS we used.  I know this may seem pretty obvious, but it’s not entirely clear in Cisco’s whitepapers.

channel 1 vrouter saf asystem 10
subscribe callcontrol wildcarded
publish callcontrol 1

The subscribe line tells the router to listen to all (wildcarded) advertisements.  You can set this to only listen to specific ones.

The publish line advertisesour callcontrol profile to the SAF network.

With all that done, we can go to the CUCM.

First setup the SAF Security Profile

Advanced Features → SAF → SAF Security Profile

Create a new profile, give it a name.  Enter the username and password we used in the IOS external-client config above.

Save it.

Advanced Features → SAF → SAF Forwarder

Create a new Forwarder.  Give it a name.  Again use the external client config parameters for Client Label, SAF Forwarder Address, SAF Forwarder Port.  In the above example, this would be: CUCM, 10.0.0.5 (Loopback Addr), 5050.

Select the security profile you just created.  Save it.

Now go to : Call Routing → Call Control Discovery → Hosted DN Group

Create a group, give it a name, save it.

Next : Call Routing → Call Control Discovery → Hosted DN Pattern

This is our internal extension “route”.  Add your pattern as you expect it from the PSTN.  (i.e. 1XXX).  Assign it to your Hosted DN Group.  Save it.

Do this for all your internal DID blocks.

Whew!  Almost Done!

Go to Device → Trunk.

Create a new trunk.

Trunk Type: SIP

Service Type : Call Control Discovery

Configure this trunk as you would any other gateway.  Save it.

Now go to : Call Routing → Call Control Discovery → Advertising Service

Give it a name, select your SIP trunk (or H323) and the Hosted DN group you configured.

Save it.

Now we’ve advertised our routes into the SAF network, we just need to receive routes now.

Call Routing → Call Control Discovery →Requesting Service

Set the name and move the trunk from the Available box to the Selected box.

Save it.

All done!

You won’t see any of the learned routes in the CUCM.  But you can verify that it’s working by using RTMT.

There’s a lot more that can be done, but this is the basic configuration to get you going.  On most dial-plans you will want to make sure the patterns are placed into a certain partition, or take advantage of the AAR/PSTN failover features.

Good luck in your endeavors.

If any of you find this helpful and wish to make a donation to the support and further development of this software, please use the donation button on the right sidebar.

If you have any questions or requests or ideas for future releases, you may post them here.

Thank you,

Download

Just add the files to your existing (or new) PHP enabled web server, update the creds.php file to your liking and you’re ready to go.  The software is not particularly secure, so make sure it’s behind a firewall please.

You will need to configure a user on your Communications Manager and associate it to all phones you want to be able to control.

Good luck!

-S

The App uses Adobe Air and can be downloaded here.
I will be building Android and iOS versions soon.

So here’s where you find the option :

Go to Device -> Device Settings -> SIP Profile.  Select the profile you want to edit (If you use the default profile, you will need to make a copy of it).

Scroll down to the bottom section (Trunk Specific Configuration) and find the SIP Rel1XX Options parameter.  Change it to Send PRACK if 1xx Contains SDP.

As I mentioned in the other post, this parameter tells the Communications Manager to send ACK packets back in response to 100 series SIP message received that contains an SDP section.

Press the Save button and you’re done.

If you had to copy the SIP Profile, you will now need to apply the profile to your SIP trunk, then reset it to apply the changes.

Remember! Resetting the SIP Trunk will DROP all active calls.

Good luck!

If you do a debug, you will see the following messages:

Router# debug ccsip messages


SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=4gsi4lsi84o57osh7j6ps
From: <sip:1000@192.168.1.10>;tag=91837ae4-cf98-d1ae-7f23-95fe870ab193-d4875345
To: <sip:5000@192.168.2.1>;tag=92FE84D7-CB6
Date: Wed, 25 Aug 2010 22:00:00 GMT
Call-ID: fe1edf80-c7519084-a9be7-5ff1bac@192.168.1.10
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0


This SIP message tells the CUCM that the number has been forwarded. By default, the CUCM will not know what to do with this and so will return a reorder tone.

This is an easy problem to fix, though probably hard to describe in a few words.
You could disable this SIP feature in IOS, but that would route all voice traffic for those users (to voicemail) out to the remote site and then back to the VM server. It works if your system doesn’t support this feature… but it’s not the best solution.

Instead we can just configure CUCM to reroute calls when it receives these messages.

Start by adding a new SIP profile if you use the Standard SIP Profile.
Go to : Device -> Device Settings -> SIP Profile
Click on Find and select the Standard SIP Profile
Click the Copy button to create a copy, then give the copy a new name. Something like Custom SIP Profile or Enhanced SIP Profile is fine or use your own naming standard.
Then before you save it, check the box that says Redirect by Application… this allows the CUCM system to process redirect messages on SIP devices using this profile.
Then click Save.

Next we go configure our SIP Trunk
Device -> Trunk
Click the Find button and click on your Trunk name.
Scroll all the way down. The second to the last line is your SIP profile. Change this to the custom profile we just created.
Lastly we need to tell the trunk where to reroute calls to… look a few lines farther up and you’ll see a Rerouting Calling Search Space field. Set that to your outgoing CSS. (Or a CSS that provides access to your VM or other required services)
Save the changes and Reset the trunk.

That’s it! The CUCM system will now process the SIP redirection messages and reroute the caller accordingly.

This should be a last resort though, since, without properly shutting down your VMs, it WILL seriously anger the VMWare server and probably screw up any virtual machines running on the iSCSI drive.

Inherited Settings

When a DHCPDISCOVER message is received by the router, Cisco IOS matches it against the list of DHCP pools and returns the DHCP options based on which pools matched the subnet the request came from.
Did you catch that? I said pools… plural… if the pools overlap, it is possible for more than one DHCP pool to match a DHCPDISCOVER message. In this case the options are cascaded down through the matching pools with the more specific pool taking priority. Here’s an example:
ip dhcp pool GLOBAL
 network 192.168.0.0 /22
 dns-server 192.168.1.10 192.168.1.11
ip dhcp pool DATA
 network 192.168.1.0 /24
 default-router 192.168.1.1
ip dhcp pool VOICE
 network 192.168.2.0 /24
 default-router 192.168.2.1
dns-server 192.168.2.10
Assuming we get a DHCPDISCOVER request on the DATA VLAN, the request will be matched against the pools above. As you can see, the 192.168.1.0 network will match both the GLOBAL and the DATA pools. Since none of the options overlap, the DHCPOFFER will contain an IP address on the 192.168.1.0/24 network with 192.168.1.1 as the gateway router and dns servers of 192.168.1.10 and 192.168.1.11.
However if the DHCPDISCOVER request was received on the VOICE VLAN, the result would be different. The DHCPOFFER would still contain an address on the 192.168.2.0/24 network with it’s proper gateway. However, the more specific matched pool (VOICE) would override the DNS server settings in GLOBAL. So the DHCPOFFER would only contain one DNS server (192.168.2.10).

Manual Host Bindings

What if we always want a specific host to get a certain IP address?
We can create a manual binding for that host like this :
ip dhcp pool COMPUTER_NAME
 hardware-address 0012.3456.789A
 host 192.168.1.100 mask 255.255.255.0
 client-name COMPUTER_NAME

If you have a lot of these, it helps to minimize the configuration if you use inheritance as discussed above. The DHCP pool name does not have to match the computer name, I just find it helpful if it does.  Also, the client-name command is not required except where network devices learn their hostname via DHCP.
It should also be noted that Microsoft DHCP clients send a client identifier rather than the MAC address of their network card. The client identifier includes a media identification byte at the beginning of the value. The value for ethernet media is 1. Therefore the above DHCP pool configuration for a Microsoft Windows client would look like this
ip dhcp pool COMPUTER_NAME
 client-identifier 0100.1234.5678.9A
 host 192.168.1.100 mask 255.255.255.0
 client-name COMPUTER_NAME

See how the client-identifier command includes the media type for ethernet (01) followed by the device MAC address?
Both hardware-address and client-identifier can be configured at the same time.

Persistance

What happens when our router dies due to power failure or some other unfortunate event?  We would lose all of our precious DHCP bindings… ok maybe not that big a deal, they are dynamic and all…  But this can cause issues, especially on larger networks.  If there is no binding table, then the DHCP server will take longer as it tries to find an unused IP address.  In a densely populated network, it could take a long time before the server finally found an available IP address.  To cause the DHCP binding table to be stored in a more permanent location we can use the following commands.

ip dhcp database ftp://user:password@192.168.1.10/data-dhcp

This tells the system to store the DHCP binding table on an FTP server at 192.168.1.10 using the username ‘user’ and the password ‘password’. The name of the file will be data-dhcp.
By default, this file will only be updated every 5 minutes.  And will wait for up to 5 minutes for the FTP transaction to complete.  Both of these settings can be adjusted with optional parameters to the ip dhcp database command.

In the above example FTP was used as the transport protocol, but TFTP and RCP are supported as well.

To get started let’s do a quick review of DHCP functionality.

When a new host connects to the network, the first IP related action it takes (assuming DHCP here folks) is to request an address from the server. It does this by sending an unaddressed broadcast IP packet out to the network (DHCPDISCOVER). The packet still has the system’s MAC address attached to it, so the server knows which device is making the request. In most cases, the server (or servers) see this request and respond with an assigned IP address (DHCPOFFER).
At this point the DHCP client will choose one of the offers that it received and send out another broadcast (DHCPREQUEST) which notifies all DHCP servers that an offer has been accepted. Any offer that was not accepted is invalidated on the server. The server that sent the accepted offer will then send out an aknowledgement to the client (DHCPACK).

All DHCP packets are sent via UDP with a port number of 68 on the client and 67 on the server.

So, how do we setup a simple DHCP server on IOS?

ip dhcp pool MYNETWORK
 network 192.168.1.0 /24
The name of the DHCP pool can be whatever you want, you just need to make sure it’s unique.
And that’s it! Pretty worthless though without a default router or dns…
Let’s add that in
 default-router 192.168.1.1
 dns-server 192.168.1.10 192.168.1.11
At this point we have a fairly usable DHCP scope.
Lets say that we want to reserve the first 10 addresses in the scope for servers, routers, switches, etc.
We can do so like this
ip dhcp excluded-address 192.168.1.1 192.168.1.10
If you only wanted to exclude one address, you would enter the one address in twice like this
ip dhcp excluded-address 192.168.1.10 192.168.1.10
There are a few other commands that should be configured for basic DHCP. First is the domain name.
 domain-name mydomain.com
This command should be entered inside the ip dhcp pool block, so if you left dhcp pool configuration you’ll need to reenter that command.
This assigns a domain name to your clients. Usage of this domain name is application specific. One example would be for DNS queries though. If your software is only given a hostname it may assume that the fully qualified name of the host is host.(dhcp assigned domain)
The other command actually activates the DHCP server, without it the router will not respond to DHCP messages.
service dhcp
Some may argue that this is a default command… Most of the time you’d be correct, but I’ve worked on some devices where this is not the case. So remember to enter this command if for some unknown reason your router doesn’t appear to be accepting DHCP packets.

That about wraps it up for basic DHCP. I’ll be following up with two other posts for Advanced DHCP Settings and DHCP Tuning

You should load at least 8.1.13 or higher firmware on the system.

Don’t forget to setup the tftp-server and load commands so that your phone updates.