Voicemail problem on hub and spoke UC500s

[brandon.kallas]

If one of the spoke sites calls an extension of a user at the hub and tries to leave a voicemail, they get disconnected.   I had them call the hub voicemail extension (500) and it rings busy.    Does the spoke locations need the voicemail dial-peer added for the hub location and visa versa?

[Steven DiStefano]

Hi Brandon,

Check your Voice Service Voice configuration to make sure the following two statements exist:

no supplementary-service H450.2

no supplementary-service H450.3

This should allow call control at the terminating office site so you can access that sites Voice mail.

let us know.

Steve

[brandon.kallas]

The spoke site had this configured, but the hub site did not.  I added the two statements, but it did not fix the problem.    Still when you call that user's extension and when it goes to voicemail, you start to hear "Sorry..." as if it's trying to play the voicemail greeting, but then disconnects.   Also if you dial the voicemail extension directly it rings busy.

[Steven DiStefano]

OK, so this sound like the Voice Mail is not working at that site at all?  In other words, do local calls to voice mail work in that site?

[brandon.kallas]

Yes, when you call an extension at the hub site locally, it works with no problems.   Also when you dial 500 it goes directly to that users voicemail box.

[Steven Smith]

What are the IP addresses at the sites (including the CUE subnet)?  Does voice (RTP) go across the tunnels?

What version of IOS are you running and CUE are you running?

[brandon.kallas]

Yes, both voice and data go across the tunnels.

Spoke Site: IOS: 12.4(11)XW9  CUE: 3.2

Hub Site: IOS: 12.4(20)T2  CUE: 3.2

Hub site has a SIP connection, and here is the Access List for the SIP source group

access-list 2 remark CCA_SIP_SOURCE_GROUP_ACL

access-list 2 remark SDM_ACL Category=1

access-list 2 permit xx.xx.xx.xx  <-- Cbeyond SIP

access-list 2 permit 192.168.254.0 0.0.0.255   <-- Local Data

access-list 2 permit 10.1.3.0 0.0.0.255   <-- Spoke Voice 1

access-list 2 permit 192.168.253.0 0.0.0.255    <-- Spoke Voice 2

access-list 2 permit 10.1.2.0 0.0.0.255    <-- Spoke Voice 2

access-list 2 permit 192.168.252.0 0.0.0.255   <-- Spoke Data 2

access-list 2 permit 10.1.1.0 0.0.0.255   <-- Local Voice

access-list 2 permit 10.1.10.0 0.0.0.3    <-- CUE

access-list 2 deny   any

[Steven Smith]

Can you do a debug ccsip messages at the hub site and the remote site to capture a call?

Does this happen both ways?  Hub leaving a VM on a spoke and spoke leaving a VM on the hub?

[brandon.kallas]

I was able to get this working, and seemed to work fine.   But then it stopped working again (when you call a user at the destination location and when the voicemail picks up, it disconnects you).   Here are the dial-peers for the source location (McIntosh) as well as the destination location (Broomfield).   When it was working, you could leave a message, but the DTMF-tones were not being recognized for selecting the available options for message delivery.

I have attached the debugs for "ccsip messages" and "voice ccapi inout" at the destination (Broomfield)

McIntosh Location (10.1.2.1) = Source

Calling number = 370

dial-peer voice 400 voip

destination-pattern 1[0-7].

session target ipv4:10.1.1.1

dtmf-relay h245-alphanumeric

codec g711ulaw

dial-peer voice 403 voip

destination-pattern 500

session target ipv4:10.1.1.1

dtmf-relay h245-alphanumeric

codec g711ulaw

Broomfield Location (10.1.1.1) = Destination

Voicemail extension = 500

Called Number = 120

dial-peer voice 303 voip

incoming called-number 500

dtmf-relay h245-alphanumeric

codec g711ulaw

dial-peer voice 2000 voip

description ** Xfterto VM **

translation-profile outgoing xfertovm

destination-pattern 500

session protocol sipv2

session target ipv4:10.1.10.1

dtmf-relay sip-notify

codec g711ulaw

no vad

CUE

ccn subsystem sip

gateway address "10.1.10.2"

dtmf-relay sip-notify

end subsystem

[Maulik Shah]

Need to check the config under voice service voip in Broomfield. Below is what CCA Multi Site Manager configures and should be the same on the sites:

voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service h450.2
no supplementary-service h450.3
supplementary-service h450.12
sip
  no update-callerid

This doc may help as well to compare CLI

https://supportforums.cisco.com/docs/DOC-9652

[finalconnect]

Are your CUE IP addresses different at each site? 10.1.10.x or are they both the same 10.1.10.1 and 10.1.10.2?

[brandon.kallas]

Here are the configs for both sites, also the TAC Engineer stated that it could be because McIntosh location is running XW9 and Broomfield is running 20T2.  I just upgraded Broomfield to 20T4 and it still does not work.

Broomfield:

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

no supplementary-service h450.2

no supplementary-service h450.3

supplementary-service h450.12

no supplementary-service sip moved-temporarily

no supplementary-service sip refer

sip

  registrar server expires max 3600 min 3600

   localhost dns:sipconnect.den0.cbeyond.net

  no update-callerid

McIntosh:

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

no supplementary-service h450.2

no supplementary-service h450.3

supplementary-service h450.12

no supplementary-service sip moved-temporarily

no supplementary-service sip refer

sip

[David Trad]

Hi Brandon,

I just finished going through this problem myself, a couple of things to look at here that we did to resolve it:

1. Make sure that Transcoding is working fine, CUE only likes to work as G-711 uLaw
2. Use the Voice-Class codec directive, run two of them, in Voice-Class Codec 1 have only uLaw in there, in #-2 have all your other ones, then apply this code to your WAN dial-peers, preferrably use #-1 first, and then if that does not work try #-2

Check your packet loss over the WAN link, i have also found that heavy packet loss can prevent connectivity over WAN to CUE, it is a real pain in the...You kow what :)

Good luck with resolving the problem.

Cheers,

David.

[finalconnect]

I can't believe TAC tried to blame IOS version mismatch and recommend an IOS upgrade...just kidding. I hear that everytime....

[finalconnect]

Do you have the SIP trunk tied to the interface (typically VLAN1) in the config on each destination?

Sorry don't have the command in front of me.