UC540 - Voice Hunt group - two sites, auto attendant issues

[Nathan Farrar]

Two sites connected via VPN tunnel. Calls come in to site A and hit a voice hunt group with a pilot of 600. There are two members in this group, extension 306 which is at site A and extension 81216 which is at site B. At site B the extension is actually 216, we have it setup for when the prefix '81' is used at site A the call will forward across to site B from A. This portion seems to be working fine, calls ring at the first extension then at the second. The final for the hunt group is extension 81398. This is with the goal that the call will first ring x306 at site A, then ring x216 at site B, and finally end up at the auto attendant at site B which is extension 398.

When the hunt group reaches the final of 81398 we do not hear the auto attendant, we hear a message that states that "this mailbox has not been setup by the subscriber". The weird thing is that this WAS working before. But the configuration was a bit different.

Here is the original voice hunt group config that was working at one point, which seemed to be missing the second site x216 but was going to the auto attendant:

voice hunt-group 2 sequential

  final 81398

  list 306, 81398

  timeout 10

  pilot 600

I changed it to the following which resulted in the second site working to x216 but not getting to the auto attendant:

voice hunt-group 2 sequential

  final 81398

  list 306, 81216

  timeout 10

  pilot 600

Figuring that it had something to do with an incompatibility with the final and auto attendant I changed it to:

voice hunt-group 2 sequential

  final 81398

  list 306, 81216, 81398

  timeout 10

  pilot 600

Still getting to x216 but no auto attendant, just that message. 

Any ideas?!

[Nathan Compton]

First thing is first.  If you call 81398 from Site A, do you receive the proper audio?

I would perform a "debug ccsip messages" on Site B with the CUE module.  Maybe the full number 81398 is being passed to CUE instead of just 398.  If that is the case you would need to either strip the 81 before it hits the CUE, or make 81398 the extension of the autoattendant.

[Nathan Farrar]

I'm getting some inconsistent results.

I called in this morning off of their normal hours and I was able to get to the auto attendant without trouble... yay! Not sure what happened, I didn't change anything. The voice hunt-group that was configured was:

voice hunt-group 2 sequential 

  final 81398

  list 306, 81216, 81398

  timeout 10

  pilot 600

This was when it was working.. I figured that having 81398 in there twice was odd so I removed it from the list and kept it as the final. I called back in and didn't get to the auto attendant, got the "this mailbox has not yet been setup by the subscriber" message again. So I went in and set the hunt group list back to the way it was before and now I am still unable to get to the auto attendant.

The debug ccsip messages shows (Selected only what seemed to be relevant) :

025110: May 21 12:00:34.407: //3317/4D2BD999AAAD/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:398@10.1.10.1:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.1.10.2:5060;x-route-tag="cid:ALL_FXO@10.1.10.2";branch=z9hG4bK32AABA
From: <sip:MYPHONENUMBER@10.1.10.2>;tag=41D20A24-218C
To: <sip:398@10.1.10.1>;tag=dsf2d1a784
Date: Wed, 21 May 2014 12:00:34 GMT
Call-ID: 592F7865-E01611E3-9D04E581-39793603@10.1.10.2
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 226

v=0
o=CiscoSystemsSIP-GW-UserAgent 2087 6133 IN IP4 10.1.10.2
s=SIP Call
c=IN IP4 10.1.10.2
t=0 0
m=audio 16772 RTP/AVP 0 101
c=IN IP4 10.1.10.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Sent:
BYE sip:398@10.1.10.1:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.1.10.2:5060;x-route-tag="cid:ALL_FXO@10.1.10.2";branch=z9hG4bK32B769
From: <sip:MYPHONENUMBER@10.1.10.2>;tag=41D20A24-218C
To: <sip:398@10.1.10.1>;tag=dsf2d1a784
Date: Wed, 21 May 2014 12:00:34 GMT
Call-ID: 592F7865-E01611E3-9D04E581-39793603@10.1.10.2
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1400673635
CSeq: 102 BYE
Reason: Q.850;cause=16
P-RTP-Stat: PS=29,OS=4640,PR=31,OR=4801,PL=0,JI=0,LA=0,DU=0
Content-Length: 0

025129: May 21 12:00:35.055: //3317/4D2BD999AAAD/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 10.1.10.2:5060;branch=z9hG4bK32B769;x-route-tag="cid:ALL_FXO@10.1.10.2"
To: <sip:398@10.1.10.1>;tag=dsf2d1a784
From: <sip:MYPHONENUMBER@10.1.10.2>;tag=41D20A24-218C
Call-ID: 592F7865-E01611E3-9D04E581-39793603@10.1.10.2
CSeq: 102 BYE
Content-Length: 0

Looks like the extension is coming in correctly and should be hitting the AA. 

I am not onsite and I can't make a call to the extension unless I find a way to get into the menu somehow. Generally I get to the AA, dial an extension, when their VM picks up I can press * and dial around.

I don't understand why it worked, then it didn't. Very odd to me.

[Nathan Compton]

I can't see the INVITE message, but it is possible the diversion header is causing some problems.  I would try stripping it on the CUE AA dial-peer to see if that helps.  Don't apply it globally or to the voicemail dial-peer:

voice class sip-profiles 300

response ANY sip-header Diversion remove

request ANY sip-header Diversion remove

dial-peer voice 100 (Auto Attendant Dial-peer)

voice-class sip profiles 1

[Nathan Farrar]

I did a test where instead of sending the call to site B's AA, I sent it to a local extension on site A. Keeping it all on the same site. Ended up with the same message. I'm trying to back track the issue as I believe it has something to do with the site A UC. May be a silly question but should I be using an ephone-hunt or is a voice-hunt correct for this application? All phones are Cisco phones.

[Nathan Compton]

You should have the same behavior with both types of hunt groups.

[Nathan Farrar]

I think you may have got it with your voice class statement.

I have worked with a few different engineers on elance to try to get this sorted out. I have gone as far as re-created the AA on site A just so I can rule out the cross site transfer to the AA. That didn't help. 

In the debug ccsip messages I kept seeing that diversion with the statement of 

"<sip:600@......"

Which I didn't think was the issue as it is in the debugs on the site that is working correctly.

I set it up on this site and it seems to have solved the issue. Yeah, I didn't give it a go the first time around because I didn't understand what it was that was happening. The strange thing is that it was intermittent, some times (with the diversion item in the logs) it would work. Very strange. 

After adding that class and applying it to the dial peer, the diversion item disappeared and it is working.

My only question for you is; how could this effect other functions if at all? They were also having issues with transfer to voicemail across the tunnel between the sites. Not sure if that is still the case yet.

Thanks!! Hopefully this solve the issue. I'll let you know this week.

[Nathan Farrar]

Well, I take that back. After I made the adjustment it worked for about three calls and then just stopped again. I'm about to take a hammer to these things.

I don't want to be presumptuous and really appreciate your help, but I've included site A's configuration here. Maybe you can see something I'm missing. 

Basically, the call gets to the AA if I do not have the call go to the remote site and back. For example... If iI have the voice hunt group got to local x306, then AA... works. If I have the hunt group go to remote 81216 then AA.. good to go...BUT if I have it go to 306, 81216, then AA... no go. Works on opposite side but everything looks exactly the same to me. 

Thanks again.

[Nathan Compton]

If the Invite to CUE has a diversion-header of "600", the CUE module will try to find a match for extension "600", not the extension "398".  You could also try copying the auto-attendant to extension 600.

[Nathan Farrar]

What do you mean by "copy auto-attendant to extension 600"?

[Nathan Compton]

Create the same auto-attendant with extension 600

[Nathan Farrar]

Wouldn't that cause an issue as the pilot for the voice hunt-group is also 600?

[Nathan Farrar]

Realized that I can call into site B directly.. When calling into site B I can get to the AA without issue.

Also found an interesting item. If I set the voice hunt-group to:

voice hunt-group 2 sequential 

  final 81398

  list 81398, 81398 <--- must use twice because have to have at least two number in HG

  timeout 10

  pilot 600

This properly transfers to the AA on site B. So I now know that the connection is good and translation is working. It is only when I have another extension before it that I have the issue. 

The previous situation was that all calls were forwarded to site B and from site B it would hunt around from Site B to Site A then back to Site B's AA. That worked fine.. but there is something I'm missing here.