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.

• Call Preservation – When network connectivity to the system goes down, it would be nice if all active calls didn’t drop
• Centralized Management – Being able to configure everything from one place and not have to duplicate settings on a per device basis
• Distributed Call Management – Calls routed optimally while maintaining a reasonably small configuration that can scale well

I know there are other issues here, but these were the important ones for me.  MGCP provides the centralized management, but not the other features.  Most importantly Call Preservation.  This is why I rarely use MGCP for VoIP deployments.

To configure a SIP gateway for a Cisco Unified Communications Manager there are two steps.

1. Configure the Gateway
2. Configure the Communications Manager

Configuring the Gateway

This part is fairly easy.  Here I’m assuming that you already have your PRI configured.

voice rtp send-recv
!
dial-peer voice 1000000 voip
incoming called-number .
dtmf-relay rtp-nte
!
dial-peer voice 9000100 pots
 destination-pattern [2-9]……
 no digit-strip
 port 0/0/0:23
dial-peer voice 9000200 pots
 destination-pattern 1[2-9]..[2-9]……
 no digit-strip
 port 0/0/0:23

You could have more dial-peers, but this is enough to get started.

Configuring the Communications Manager

Go to the Device -> Trunk menu.

Click on the Add New button

Select SIP Trunk as the type and click the Next button.

There are a few fields here that need to have information in them:

• Device Name – This can be anything, but should be descriptive
• Device Pool – Appropriate device pool for your deployment
• Location – Again use the appropriate location in your system
• SIP Trunk Security Profile – Default should be fine unless you have some special requirements
• SIP Profile – Again, Default should be fine for most users.

There are two other settings here to be aware of:

Media Termination Point Required

This should be unchecked.  While some SIP gateways may require this, it’s my experience that it causes more headaches than anything else.  It also causes all outbound calls to consume an MTP resource or Transcoder in some configurations.

DTMF Signaling Method

You might be wondering why DTMF signaling makes any difference… here’s why:  On a Cisco Unified Communications Manager even if you have MTP requirements disabled, if the DTMF relay types do not match (or are not compatible) the trunk will dynamically allocate an MTP resource which will act as a DTMF translator converting one method to another.  For maximum compatibility use : RFC 2833.  You’ll see that the gateway configuration above uses RFC 2833 for it’s DTMF relay with the following command : dtmf-relay rtp-nte

The Problem with this is…

Now that our system is configured, we can make calls out.  You’ll find that everything seems to work fine.  There are a few cases however where it will not.  An example of this is when the telco sends an announcement message prior to connecting the call.  A few common uses of this method are prompts for account codes, incorrect dialing messages, etc.

SIP Trunks on Cisco’s Communications Managers create ringback locally and wait for the ISDN Connect message before actually connecting the IP media stream.  So if you receive a message from your telco before their switch sends you the Connect message, you will only continue to hear ringback on the phone until the telco terminates the connection.

An easy way to fix this is to require that all calls use a Media Termination Point.  I pointed out above that I don’t recommend this.  It drives cost up, makes troubleshooting more difficult and can cause issues with faxing.

The better way to fix this is simple, but I’m going to go into a little background explaining the why.

Whenever your telco sends an announcement message, they will flag the Progress Indicator of the Q.931 message with an 8 (Usually.  Some telcos may do this a little differently)  Your Cisco gateway will take this indicator and generate a SIP 183 Session Progress message which contains an SDP with connection parameters.  This tells the Communications Manager that there is possibly some in-band data that the user may be interested in.  The problem is that the Communications Manager will ignore this and continue to play the ringback tone instead of letting you hear the message.

To allow the Communications Manager to react to the 183 messages go into System -> Service Parameters, select your server then select the CallManager service.  Scroll down and find the Clusterwide Parameters (Device – SIP) section.  Find the SIP Rel1XX Enabled parameter and set it to True.  This parameter tells the Communications Manager to send ACK packets back in response to any 100 series SIP message received.  The IOS command above, voice rtp send-recv, is used to connect the media path in both directions instead of just a single direction.

That’s it!  Press the Save button and you’re done.  Now when the system is signalled from the ISDN network it will properly cut through the media path and your users will hear any possible announcement messages.

For Either Method :
First, create a new Class of Service in Unity Connection. Duplicate your default settings. Under ‘Licensed Features’ check ‘Allow Users to Access Voice Mail Using an IMAP Client’ and select ‘Allow Users to Access Message Bodies’.
Save the Class of Service. If you have sufficient licensing, you can just change the default Class of Service and skip the next step.
Next you will need to select which users will have this feature by selecting their Alias under Users and
changing ‘Class of Service’ to whatever you named the class you just created.
At this point you may need to change the Web Application password for the user account. Or at least set the password not to require changing at login. This is the password that will be used to access the server.

Method 1 : Configuring another account on the mail client
This is probably the easier of the two options to implement. But with multiple users it can also be the most time consuming.
Simple change the settings on the users email client.
Create a new account with the following settings :
Type : IMAP
Server : UnityConnectionIP
User Name : (Unity Alias)
Password : (Unity Alias Password)
Then you will probably want to configure rules that copy the incoming messges to the users inbox.
Copying is important since if you move it, the voicemail will be removed from the users phone as well.

Method 2: Forwarding voicemails to the primary mail server
This method is a little more difficult and requires an extra server. As it is more in-depth I’ll address it in my next post.

Symptom : Calls show up on the SIP gateway as g.711, not g.729

This is because the system is using transcoders to complete the call.  The big question is ‘Why?’.  Both devices are natively capable of supporting g.729, but they insist on using a transcoder.  The transcoder sits in a g.711 only reason, so both sides of the gateway run g.711.

Here’s the reason why : When calls connect to a SIP trunk in Cisco’s Communications Manager, the system will dynamically allocate a Media Termination Point (MTP) if the two endpoints are configured with incompatible DTMF signalling types.  Since transcoders can be used as MTPs, a transcoding session is invoked.

In many cases VG224s are used to handle Fax calls.  For those who don’t know… Fax machines and transcoders don’t mix.  But even if there are no fax machines in the mix, at remote locations this issue can cause overutilization of bandwidth.

The solution is simple, just make sure that all of your endpoints use compatible DTMF relay methods.

For example in MGCP

mgcp dtmf-relay voip codec all mode nte-ca

is compatible with this command in SIP (RFC-2833)

dtmf-relay rtp-nte

MOS Scores are used to quantify the quality of a phone conversation.  In the past this was based on the “Mean Opinion” of several call testers.  On modern IP telephony systems, there are mathematical alogrithms that do this for us.  They take into account the various inconsistencies that plague VoIP calls: loss, jitter and latency.

Those algorithms then give us a number to rate the results.  The number is from 1 to 5.  5 being a theoretical maximum.  I’m not aware of any system that claims 5.0 MOS.

MOS Score	Quality	Example
5.0	Perfect Audio	Face to face conversation
4.4	Maximum digital*	Crystal clear phone call
4.0	Very good	Normal phone call
3.8	Good	Average cell phone call
3.5	Minimum for Faxing	A few skips, but otherwise okay
3.0	Minimum phone call	A few missed words, but otherwise okay
2.0	Poor but usable	Callers need to repeat messages often
1.0	Very Poor quality	Zombies have taken over the planet and this is the only way to communicate with other outposts.  It sucks but it’s all we got.

]]> http://www.frozenreality.com/?feed=rss2&p=124 0 http://www.frozenreality.com/?p=121 http://www.frozenreality.com/?p=121#comments Mon, 08 Jun 2009 22:27:11 +0000 admin http://www.frozenreality.com/?p=121 A big drawback to the previous post is that ATAs cannot be used for fax machines. The reason for this is because the gateway, when sensing a fax tone, immediately moves into T.38 mode. The ATA is unable to handle T.38 and so tries to continue in g.711 mode. Since these two are incompatible, the call will fail.

However, even Cisco recommends that a fax machine be connected to a VG224/VG248 or FXS card connected to a router.  These devices support more than just straight passthrough for fax machines.