Cisco Voice Guru

Several months ago, I came across a great script that combines UCCX/IP-IVR with MeetMe functionality.  This allows you to front-end MeetMe calls with a conference number and pin.  Call it a “poor man’s” version of Meeting Place.

Read the rest of this entry »

Refer to the following document for an excellent reference on Catalyst 3750 Qos:
https://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml

Priority Queuing

• Inbound priority queue: Q2 (of two queues)
• Outbound priority queue: Q1 (of four queues)

Normal Behavior with “mls qos” Enabled

• CoS is found in the 802.1p priority bits.  When entering the switch, these incoming incoming frames are marked to CoS 0.
• CoS 0 is referenced against the cos-to-dscp mappings configured on the switch.  By default, CoS 0 is mapped to DSCP 0.
• The frame is passed on through the switch with CoS 0 / DSCP 0

Three Options for CoS/DSCP Classification and Marking

• There are three methods used for classification and marking on Catalyst 3750 switches:
• Port-based configuration using the “mls qos” interface commands.
• MQC-based configuration using class-maps and policy-maps.
• VLAN-based configuration
• These three methods are mutually exclusive.  Meaning, you can only use one of these options at a time.  Otherwise, the subsequent optioned configured will overwrite the initial option configured.

Port-Based Methods

• Access Port (i.e. no Cisco IP phone connected).  Trust DSCP because there is not dot1q/ISL tag in the frames, which is where the CoS bits are stored.

interface FastEthernet 1/0/10
mls qos trust dscp

• Trust Port (i.e. Cisco phone).  The Cisco phone uses 802.1p frames for voice vlan traffic.  PC traffic is sent untagged, which pass through as DSCP 0 regardless of the trust state.

interface FastEthernet 1/0/20
mls qos trust cos

• Uplink Port (i.e. Router-facing)

interface FastEthernet 1/0/1
mls qos trust dscp

Additional Port-Based Commands

• “mls qos cos 3 override” – Sets tagged and untagged frames to the value defined.  This overrides any “mls qos trust [cos | dscp]” values.
• “switchport priority extend cos 0” – Configures the phone to reset PC-egressing traffic to CoS 0
• “mls qos trust device cisco-phone” – Trusts the CoS markings made by the Cisco IP phone.  It also prevents someone from plugging a PC directly into this switchport (i.e. not daisy-chaining through the phone’’s built-in switch) and receiving any preferential marking.

MQC-Based Classification and Marking Example

HQ-3750(config-std-nacl)#ip access-list extended ACL-VOICE-SIGNALING
HQ-3750(config-ext-nacl)#permit tcp any any eq 1720
HQ-3750(config-ext-nacl)#permit tcp any any eq 2000
HQ-3750(config-ext-nacl)#permit tcp any any eq 2428
HQ-3750(config-ext-nacl)#permit tcp any any eq 5060
HQ-3750(config-ext-nacl)#permit tcp any any range 11000 11999
HQ-3750(config-ext-nacl)#permit udp any any eq 1718
HQ-3750(config-ext-nacl)#permit udp any any eq 1719
HQ-3750(config-ext-nacl)#permit udp any any eq 2427
HQ-3750(config-ext-nacl)#permit udp any any eq 2428
HQ-3750(config-ext-nacl)#permit udp any any eq 5060
HQ-3750(config-ext-nacl)#exit

HQ-3750(config-std-nacl)#ip access-list extended ACL-VOICE-MEDIA
HQ-3750(config-ext-nacl)#permit udp any any range 16385 32767

HQ-3750(config)#class-map CLASS-VOICE-SIGNALING
HQ-3750(config-cmap)#match access-group name ACL-VOICE-SIGNALING
HQ-3750(config-cmap)#exit
HQ-3750(config)#class-map  CLASS-VOICE-MEDIA
HQ-3750(config-cmap)#match access-group name ACL-VOICE-MEDIA
HQ-3750(config-cmap)#exit

HQ-3750(config)#policy-map POLICY-VOICE
HQ-3750(config-pmap)#class CLASS-VOICE-SIGNALING
HQ-3750(config-pmap-c)#trust cos
HQ-3750(config-pmap-c)#exit
HQ-3750(config-pmap)#class CLASS-VOICE-MEDIA
HQ-3750(config-pmap-c)#set dscp af26
HQ-3750(config-pmap-c)#exit
HQ-3750(config-pmap)#exit

HQ-3750(config)#interface gigabitEthernet 1/0/13
HQ-3750(config-if)#switchport access vlan 10
HQ-3750(config-if)#switchport mode access
HQ-3750(config-if)#switchport voice vlan 100
HQ-3750(config-if)#spanning-tree portfast
HQ-3750(config-if)#service-policy input POLICY-VOICE
HQ-3750(config-if)#exit

Default Scheduler Configuration

The priority queue is disabled. Both the shaped and shared mode are configured for the SRR. Shaped mode weights override the shared mode value. Therefore, the net result is queue 1 is serviced in shaped mode and queues 2, 3, and 4 are serviced in shared mode. This means queue 1 is serviced with an absolute value that is (1/25) percent, or four percent, of the bandwidth. Queues 2, 3 and 4 are serviced at 25 percent of the bandwidth. If the bandwidth is available, then queues 2, 3 and 4 can be serviced at more than 25 percent of the bandwidth.

Distribution1#show mls qos int gigabitEthernet 1/0/20 queueing
GigabitEthernet1/0/20
Egress Priority Queue : disabled
Shaped queue weights (absolute) :  25 0 0 0
Shared queue weights  :  25 25 25 25
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 1

Have a look at the marked up configuration below.  This is the result of running "auto qos voip trust" with just a bit of tweaking afterward.  A big thanks to Warren Heaviside for initially posting the majority of this content on the IPexpert online study list.

This maps a COS to DSCP value

mls qos map cos-dscp 0 8 16 26 32 46 48 56

This is the weighted ratio (not percentage) that the queues are serviced to send packets from each queue.

mls qos srr-queue input bandwidth 90 10

This is the percentage at which input/ingress queue 1 will begin tail dropping for thresholds 1 and 2.  Threshold 3 is not configurable and has a value of 100% assigned to it so it is not shown.

mls qos srr-queue input threshold 1 8 16

This is the percentage at which input/ingress queue 2 will begin tail dropping for thresholds 1 and 2.   Threshold 3 is not configurable and has a value of 100% assigned to it so it is not shown.

mls qos srr-queue input threshold 2 34 66

This is where you define how the two input/ingress queues will share the buffer space between them using percentage.

mls qos srr-queue input buffers 67 33

This is mapping CoS values to either input/ingress queues 1 or 2 and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue input cos-map queue 1 threshold 2  1
mls qos srr-queue input cos-map queue 1 threshold 3  0   
mls qos srr-queue input cos-map queue 2 threshold 1  2
mls qos srr-queue input cos-map queue 2 threshold 2  4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3  3 5

This is mapping DSCP’s to either input/ingress queues 1 or 2 and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue input dscp-map queue 1 threshold 2  9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3  0 1 2 3 4 5 6 7 32
mls qos srr-queue input dscp-map queue 2 threshold 1  16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2  33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2  49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2  57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3  40 41 42 43 44 45 46 47

This is mapping COS’s to one of four output/egress queues and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue output cos-map queue 1 threshold 3  5    
mls qos srr-queue output cos-map queue 2 threshold 3  3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3  2 4
mls qos srr-queue output cos-map queue 4 threshold 2  1
mls qos srr-queue output cos-map queue 4 threshold 3  0

This is mapping DSCP’s to one of four output/egress queues and to thresholds 1,2 or 3 where 3 is the highest.

mls qos srr-queue output dscp-map queue 1 threshold 3  40 41 42 43 44 45 46 47  
mls qos srr-queue output dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31   
mls qos srr-queue output dscp-map queue 2 threshold 3  48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3  56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3  16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3  32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1  8
mls qos srr-queue output dscp-map queue 4 threshold 2  9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3  0 1 2 3 4 5 6 7

This is configuring the drop threshold values for each queue-set and four related output queues.

mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400

mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242

This is the percent amount of buffer space for "queue set 1" allocated to to each of the four queues.  In this case the expedite queue 1 is getting 10%.

mls qos queue-set output 1 buffers 10 10 26 54

This is the percent amount of buffer space for "queue set 2" allocated to to each of the four queues.  In this case the expedite queue 1 is getting 16%.

mls qos queue-set output 2 buffers 16 6 17 61

This turns on QoS globally for the switch, but the auto QOS macro does this.

mls qos

Below is the configuration for the access port.  In this example, I have assigned Gig 1/0/2 the properties of queue-set 2 (defined in values above).  Priority-queue is enabled.  Therefore, anything in Q1 can burst up to the full capacity of the link.  Shape and share commands are ignored when “priority-queue out” is configured.

The shape command (1/x = y%) is configured for Q2.  This negates any share command set for that queue.  Q2 is allowed to consume up to 33% of the link capacity, minus what is currently in use by Q1.

Q3 and Q4 are configured according to the share command.  They are allowed to share bandwidth with each other up to 75% ( 60 / [60+20] ) and 25% ( 20 / [ 60 + 20] ) of the remaining link capacity, respectively.

Remember, priority-queue always overrides shaping.  Shaping always overrides sharing.

We are also telling the switch to trust any CoS markings coming inbound toward this switch port.  You must be very careful to trust either CoS or DSCP.  If a packet comes in marked as DSCP, but you are trusting CoS, you risk that packet being marked down to DSCP 0.  The same holds true for CoS trusting.

interface GigabitEthernet1/0/2
srr-queue bandwidth share 10 10 60 20  
srr-queue bandwidth shape  0  3  0  0  (COS 3 is mapped to queue 2
priority-queue out
mls qos trust cos
auto qos voip trust
queue-set 2

Beware: This is a short post. I am not going to explain the concepts behind AAR/CFUR in this post.  I simply wanted to publish a quick example of a base CFUR configuration.  By separating the CFUR call routing into a separate partition and calling search space, you gain two benefits:

1. Efficient troubleshooting
2. Unrestricted CFUR call routing privileges

Directory Number Configuration:

Route Pattern Configuration:

It’s been asked for.  Here is the latest CCIE Voice Techtorial from Cisco Live! 2010 in Las Vegas.

Right-click this link to download, select “Save As” (PDF)

Most of the content from this troubleshooting post was gathered from the H.323 Gatekeeper Troubleshooting document on Cisco’s docwiki site.  I have tried to summarize the important points below.  Thanks to Zen Beck for pointing me in the right direction.

Troubleshooting H.323 Gatekeeper Registration

To determine registration reject issues, run a “debug h225 asn1” and search for “rejectReason.”  Below is a list of the registration reject reasons and corresponding explanations:

RRJ: rejectReason duplicateAlias

This is usually the result of the gateway registering a duplicate of an E164-ID or H323-ID-another gateway has already been registered to the gatekeeper. If it is a duplicated E164-ID, change the destination pattern configured under a POTS dial-peer associated with an FXS port. If it is a duplicated H323-ID, change the gateway’s H.323 ID under the H.323 VoIP interface.

RRJ: rejectReason terminalExcluded

This is the result of the gateway subnet being disabled in the gatekeeper. Check the gatekeeper configuration. Removing the “no zone subnet gk” command resolves the issue. To remove the command completely, remove the “zone local gk” command.

RRJ: rejectReason securityDenial

This RRJ is the result of the security commands being enabled in the gatekeeper, and the inability of the gateway to match the H.323-ID, E.164-ID, passwords, or security token that the gatekeeper requires. To resolve the issue, check the securiy configuration in the gatekeeper.

RRJ: rejectReason invalidAlias

The RRJ is the result of a no-zone prefix defined in the gatekeeper. Check the configuration on the gatekeeper and add the zone prefix with the proper E.164 address.

Troubleshooting H.323 Gatekeeper Call Routing and Dial Peers

The following is a list of useful show and debug commands used to verify and troubleshoot gatekeeper and gateway call routing issues.

• show gateway - Used to verify E.164 and H.323 alias registration for the gateway
• show gatekeeper endpoints – Used to verify the E.164 and H.323 alias registered with the gatekeeper
• show gatekeeper gw-type-prefix - Used to verify E.164 prefix registrations on the gatekeeper
• show gatekeeper zone prefix | status - Used to verify zone status and configuration parameters
• debug ras - Applicable for gateways and gatekeepers
• debug debug h225 asn1 - Applicable for gateways and gatekeepers
• show dial-peer voice - Used to verify configured technology prefixes under the dial-peers

Troubleshooting H.323 Gatekeeper Bandwidth

When deciding whether there is enough bandwidth to accept a call Admission Request (ARQ), the Cisco gatekeeper calculates the available bandwidth with the following formula:

Available bandwidth = (total allocated bandwidth) – (bandwidth used locally) – (bandwidth used by all alternates).

If the available bandwidth is sufficient for the call, an Admission Confirmation (ACF) is returned, otherwise an Admission Rejection (ARJ) is returned.

Three show commands give you visibility into the bandwidth management on the gatekeeper:

• show gatekeeper zone status
• show gatekeeper zone cluster
• show gatekeeper calls

Troubleshooting Gatekeeper Endpoint Call Admission Issues

Admission Confirmed (Busy Tone Back)

If the Admission Confirmed (ACF) message has been sent by the gatekeeper and arrived at the endpoint side, but the call still received a busy signal, check to see if the terminating IP address in the ACF is an expected valid endpoint IP.  If the ACF has an IP address of the terminating endpoint, remove the gatekeeper and make a direct endpoint-to-endpoint call to see if a call can be established.

Admission Reject (ARJ) rejectReason calledPartyNotRegistered

This is a common reason for rejection. It is captured from the local or originating gatekeeper when the gatekeeper has no information on where the called number should be terminated. There are two ways this problem can occur. One reason is that the call terminates at a gateway, and the gateway is not registered with the E.164 address or with a tech-prefix. To resolve this, make sure the gateway is registered with a tech-prefix to the gatekeeper.

A second possible explanation for this error message arises if the called party is a terminal in a remote zone. It might be that the terminal does not have a proxy enabled in the same gatekeeper zone where it is registered.

Note: Intrazone calls do not require the match of a zone prefix.

ARJ "rejectReason requestDenied"

The rejection shown here comes about because the endpoint-requested bandwidth exceeds the limit configured in the gatekeeper. To resolve this, increase the bandwidth in the gatekeeper using the “bandwidth” command under the gatekeeper mode, or lower the bandwidth request from the endpoint.

Refer to the “debug h225 asn1” for the requested bandwidth in the ARQ (Search for “admissionRequest” in the otuput).  Compare requested value to the “gatekeeper zone status” to see if enough bandwidth is available.

Voice and Unified Communications > Unity Express > Configure > Configuration Examples and Technotes

CallManager for Cisco Unity Express Configuration Example
“Sample Cisco Unity Express Configuration” section provides a very nice CUE CLI output required for the necessary integration in the event that CUE GUI is not available.

CUCM-CUE Verification:

show ccn status ccm-manager
JTAPI Subsystem is currently registered with Call Manager: 14.86.11.11
JTAPI Version: 3.0(2.3) Release

Cisco CallManager Express/Cisco Unity Express Configuration Example:
”Configure the Voicemail Application” section provides some basic CLI commands to setup voicemail.  This is useful in a bind when your nerves have gotten to you.  The document itself also provides helpful troubleshooting information.

ccn application voicemail
description “Cisco Voicemail”
maxsessions 4
!
ccn trigger sip phonenumber 3600
application voicemail
enabled
maxsessions 4

Configuration Example: Cisco Unity Express Networking [Cisco Unity Express]
”Using the CLI for Configuration” section contains the necessary commands to setup VPIM on CUE.  It also contains troubleshooting help, good show commands, and trace output walkthroughs.

1. Configure the DNS server.
2. Ensure local users and extensions are setup.
3. Configure networking configuration for remote site.
4. Configure local site definition.
5. Optionally, setup remote users.

Failure to Set MWI on Phones Connected to the Remote CallManager Express
”Solution” sections shows you how to configure MWI relay for remote sites.  It contains both CUE and CME configuration necessary to make it work.  Again, it’s a simple configuration, but it’s good to know about in a bind.

Transfer a Caller Directly into a Unity Express Mailbox
”Unity Express CLI Configuration” section shows how to configure the feature that allows users to transfer a call directly into another user’s voicemail.

ephone-dn 99
number 33…
description DN to transfer directly to CUE voicemail
call-forward all 3600
!
dial-peer voice 3600 voip
destination-pattern 3600
description CUE voicemail pilot number
session protocol sipv2
session target ipv4:10.10.202.2
dtmf-relay sip-notify
codec g711ulaw
no vad
!
CUE: user HSimpson phonenumberE164 33001

Troubleshoot Voice View Express
Enough said.

I’m getting off the CCIE Voice bandwagon for a brief moment.  I ran into a real-world scenario today where I needed to pull CDR reports for an end-user’s call activity.  The problem with a generic CDR user report is that it will be truncated if there are more than 100 calls in the output.

The best way around is to do an export of the entire CDR database for the time period in question.  The file will be a .txt file.  Rename it to <filename>.csv and open it in Excel.

The next problem you will encounter is that the dateTimeOrigination column is in epoch time instead of standard time legible by normal human beings.  To convert this, you can use a handy formula that my Twitter-buddy Josh posted on his blog, BlindHog.net.

In Call Manager, the CDR exports are in EPOCH time. Here is the formula to convert epoch time in a Call Manager CDR to a standard format in excel. After using the formula, you will need to format the cell for date and time.

=(((E2-(6*3600))/86400)+25569)

• E2 = cell reference
• 6 = Timezone Offset (this is Central Standard time)
• 3600 = Number of seconds in an hour
• 86400 = Number of seconds in a year
• 25569 = Excel hack because excel counts epoch from 1/1/1900 and most others start at 1/1/1970.

References:

• http://www.mrexcel.com/archive2/44100/51255.htm
• http://www.peterabowen.com/?p=8

CRCX

Hello, voice peeps.  I’m back and at ‘em again.

I had a conversation with an engineer at CDW today and botched up my bandwidth calculations.  I know them, trust me.  However, I get confused at times between the values used for Locations-based CAC, GK-based CAC, RSVP, and QoS.  This post serves to redeem my conscience.

I’ve been unable to find a good article that clearly lays out the different values for each method.  Therefore, I took the initiative to contribute this reference sheet to the CCIE Voice and larger UC community.

DLCX

CUCM Locations-Based CAC Bandwidth Values
You can find this information in CUCM Admin > System > Locations > Add Location > Help > About This Page

• G.711 call uses 80 kbps
• G.722 call uses 80 kbps
• G.723 call uses 24 kbps
• G.728 call uses 16 kbps
• G.729 call uses 24 kbps
• GSM call uses 29 kbps
• Wideband call uses 272 kbps

Gatekeeper-Based CAC Bandwidth Values
A “debug h225 asn1” will reveal “bandWidth 1280” in the ARQ.  Note well, H225 debugs tack a 0 (zero) on the end of your values.  Therefore, 128 kbps (G.711) will show 1280 and 16 kbps (G.729) will show 160.

• G.711 call uses 128 kbps
• G.729 call uses 16 kbps

QoS Bandwidth Values
Best document is the QoS SRND, page 33.
[L2 (G.729 = 20 kbps; G.711 = 80 kbps) + L3] * 8 * 50 = Value per call

• 802.1Q Ethernet adds (up to) 32 bytes of Layer 2 overhead.
• Point-to-point protocol (PPP) adds 12 bytes of Layer 2 overhead.
• Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead.
• Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.

RSVP Bandwidth Values
A “debug ip rsvp messages” will show the worst-case scenario bandwidth value used.  Look for “start requesting XX kbps” in the output.

The ip rsvp bandwidth value should be equal to (x-1 calls at normal scenario + 1 call at worst case scenario).  For example, two G.729 calls would be calculated as 24 + 40 = 64 kbps.  In the example below, I have configured RSVP for one G.729 calls (1-1 calls at normal scenario + 1 call at worst-case scenario of 40 kbps)

• G.711 call uses 96 kbps as a 10 ms worst-case scenario.
• G.729 call uses 40 kbps as a 10 ms worst-case scenario.

External Phone Number Mask on a CME SCCP Phone (Under DN):

ephone-dn 5 octo-line
number 3001 no-reg
name Jacques Strahp
description +3432143001

External Phone Number Mask on a CME SIP Phone (Under Phone):

voice register pool 1
description +3432143001
!
voice register dn 1
number 3001
name Jacques Strahp

SIP Phone Caveats

• You must bind all SIP media and control messages to a particular interface; preferably, the voice VLAN’s default router.  If you do not do this, your SIP phones to sporadically unregister/reregister.  Useful command: “voice service voip” | “sip” | “bind all source-interface Vlan 240” and “registrar server”
• If you do not define an NTP reference for your SIP phones, they will use the time from the last SIP message sender.  Therefore, make sure to enter “voice register global” | “ntp server X.X.X.X”
• Cisco CME SIP phones cannot negotiate codec like the CME SCCP phones.  Therefore, remember to configure “codec g711ulaw” and “dtmf-relay rtp-nte” under each “voice register pool” section.

Intercluster Presence Subscription (CME-to-CME):

Scenario: Extension 5002 at CME HQ, watching Extension 1002 at CME SB.
HQ Configuration:

sip-ua
presence enable

presence
server 10.10.201.1
watcher all
allow subscribe

ephone  2 
blf-speed-dial 1 1002 label "SBPHN2-1002"

dial-peer voice 1002 voip
destination-pattern 1…
session protocol sipv2
session target ipv4:10.10.201.1
incoming called-number 5…
dtmf-relay rtp-nte
no vad

SB Configuration:

presence
server 10.10.200.3
watcher all
allow subscribe
sip-ua 
presence enable

dial-peer voice 5002 voip
destination-pattern 5…
session protocol sipv2
session target ipv4:10.10.200.3
incoming called-number 1…
dtmf-relay rtp-nte
no vad

CUE CLI Command Reference:

• security password expiry days 90
• security pin expiry days 90
• voicemail mailbox owner "SCPHN1" | login pinless subscriber-phone-numbers
• voicemail notification restriction msg-notification

Restrict Inbound International Calls To Single Extension in CME:

This setup is especially useful when the inbound restriction is tied to a particular number.  The gut reaction is to attempt to use CoR, but let’s face it…CoR sucks and doesn’t always work the way you’d expect.

voice translation-rule 2
rule 1 reject // type international plan isdn

voice translation-profile 2-IN
translate calling 2

dial-peer voice 2 pots
call-block translation-profile incoming 2-IN
call-block disconnect-cause incoming call-reject
incoming called-number 1002
direct-inward-dial
port 0/0/0:23

After-Hours Block Patterns in CME:

Remember, the start time starts at the VERY BEGINNING (i.e. 00:00:00 – no secs); the end time ends at the VERY LATEST (i.e. 23:59:59 – max secs).

In Cisco CME 3.4 and later, call-blocking configuration under telephony-service applies to all SCCP, H.323, SIP, and POTS calls that go through the CME router.  All incoming calls to the router, except calls from an exempt phone, are also checked against this after-hours configuration.

after-hours block pattern 1 9011T
after-hours day Sun 12:00 06:59
after-hours day Mon 19:00 06:59
after-hours day Tue 19:00 06:59
after-hours day Wed 19:00 06:59
after-hours day Thu 19:00 06:59
after-hours day Fri 19:00 06:59
after-hours day Sat 13:00 12:00

Basic Gatekeeper Configuration with Default-Tech and Hop-Off

It’s always good to look at gatekeeper configurations, just so you don’t forget!

gatekeeper
zone local US cisco.com 10.10.110.1
zone local SP cisco.com 10.10.110.1
zone prefix US 212* gw-priority 10 HQ-GW
zone prefix US 212* gw-priority 9 SB-GW
zone prefix SP 34*
gw-type-prefix 2# default-technology
gw-type-prefix 617* hopoff US gw ipaddr 10.10.110.2 1720
no shutdown

Basic Gatekeeper CAC for US Zone

gatekeeper
…
bandwidth interzone zone US 32
endpoint resource-threshold
endpoint max-calls h323id HQ-GW 1
no shutdown

Random Notes That Don’t Below Anywhere Else

• One way to limit conference participants is to string ephone-dns together with “no huntstop.”  This way, you can set a restriction lower than 8/16 participants, which is the minimum values possible when working with a G.729r8-enabled hardware conference bridge.
• The command “conference admin” gives users the ability to add/drop/list conference participants in CME.
• Verify CME conferencing using:

show ephone-dn conference
show telephony-service conference hardware

CME-to-CUC SCCP Integration

1. Add call-forward settings for each user’s extension under “ephone-dn”
2. Add voicemail command under “telephony-service”
3. Add voicemail pilot under “ephone-dn”.  Number should be the voicemail pilot.
4. Add DN for mwi under “ephone-dn”.  Use “number 5601 secondaey 5602 no-reg both” | “mwi on-off”
5. Add voicemail port under “ephone”.  Use “vm-device-id” command and make sure it matches what you enter in the CUC port group.