cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3265
Views
0
Helpful
11
Replies

CUCM Hunt Pilot Initial Announcement Not Heard by External Callers

SK T1
Level 1
Level 1

Hi,

I'm facing the issue about hunt pilot on CUCM9.x

My CUCM version : 9.1.2.12901-3

Problem : Initial announcement not heard (Silence during announcement playing)  by external callers, for internal is working. I'm already check with ITSP they're not block the audio.

Call flow : ISDN PRI -- IOS -- SIP -- CUCM hunt pilot

Don't sure there is related with bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuh15872 or not.

SIP trunk also have MGRL.

Any idea ?

1 Accepted Solution

Accepted Solutions

here is the script information and how to deploy it.

For script to be triggered pots dial-peer needs to be matched on the incoming call leg.

dial-peer voice 1500 pots
service script
incoming called-number 1500
no digit-strip
direct-inward-dial
!
application
service script flash:script.tcl
!

===========

Script content: script.tcl

proc act_Setup { } {
global dest

set dest [infotag get leg_dnis]
puts "Destinacija: $dest"

leg connect leg_incoming
puts "CONNECT"

handoff appl leg_incoming default "DESTINATION=$dest"
puts "prosledjivanje na $dest"

act_Cleanup
}

# raskidanje poziva
proc act_Cleanup { } {
puts "Procedura: act_Cleanup"
call close
}


#----------------------------------
# State Machine
#----------------------------------

set fsm(any_state,ev_disconnected) "act_Cleanup same_state"
set fsm(CALL_INIT,ev_setup_indication) "act_Setup PLACECALL"
set fsm(PLACECALL,ev_disconnected) "act_Cleanup CALLDISCONNECT"
set fsm(CALLDISCONNECT,ev_disconnected) "act_Cleanup same_state"
set fsm(CALLDISCONNECT,ev_disconnect_done) "act_Cleanup same_state"

fsm define fsm CALL_INIT

View solution in original post

11 Replies 11

Suresh Hudda
VIP Alumni
VIP Alumni

Check below link, I hope it will help u to resolve this issue.

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116230-problem-Hunt-00.html

Suresh

Hi Suresh,

I've checked already. The results should be working from our end.

For ITSP side. They're not block the audio.

SK,

Have you verified progress indicator value and taken pcm capture at iOS gateway end, if both verified then this must be resolved from service provider end only.

Suresh

Hi,

The ITSP confirmed they're not block the audio. I've tested with the option "play announcement if call is queued' It's working.

For "Play announcement before routing to Hunt Member" still not working.

Any idea ?

SK

That looks indeed like a defect you've mentioned in the first posted information.

The reason that  "play announcement if call is queued' is working is that for this one call is actually connected so CUCM will send 200 OK to the gateway and all is good.

For "Play announcement before routing to Hunt Member" the call is never fully connected (early media), CUCM will send SDP to GW withing 180/183 message, and this is what the defect is referring to.

So you are either left with upgrade or contact TAC for workaround (bo to be honest I don't remeber if TAC has script for SIP as well or only for H323).

The script that TAC uses for workaround is whenever gateway is going to get early media from CUCM then it will translate that to Connect message when sending on the PRI site.

You can also make sure that you telco is not blocking early media for that to be 100%  sure that all is good on CUCM/VG site you'd need to collect traces and pcap from VG/CUCM.

Pcap that that Suresh mentioned together with debug ccsip messages and debug isdn q931 would be very useful.

Leszek

Hi,

Does anyone know the TAC script ?

I found something wrong from my ccsip trace ;

Jun 14 2016 05:44:22.155: //53656/20F79648B21E/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.35.16.5:5060;x-route-tag="tgrp:PSTN";branch=z9hG4bK5D47C5A
From: <sip:90878317650@10.35.16.5>;tag=CD70C9E8-1C3F
To: <sip:5653@10.35.23.214>;tag=3308007~f4438adc-dbc2-4920-b14b-41c99540b99d-32386101
Date: Mon, 13 Jun 2016 22:43:48 GMT
Call-ID: 20F8CF30-30EF11E6-AA3E94EB-E866E969@10.35.16.5
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=27
Content-Length: 0

Hi,

404 is because the system on 10.35.23.21 doesn't know the extension 5653.

If 10.35.23.21 is CUCM and 5653 is configured on it then this will usually be CSS problem.

About the script, I'll check i should have it somewhere, but as mentioned from what i recall it's only for h323 not for SIP, but will check and let you know.

Leszek

here is the script information and how to deploy it.

For script to be triggered pots dial-peer needs to be matched on the incoming call leg.

dial-peer voice 1500 pots
service script
incoming called-number 1500
no digit-strip
direct-inward-dial
!
application
service script flash:script.tcl
!

===========

Script content: script.tcl

proc act_Setup { } {
global dest

set dest [infotag get leg_dnis]
puts "Destinacija: $dest"

leg connect leg_incoming
puts "CONNECT"

handoff appl leg_incoming default "DESTINATION=$dest"
puts "prosledjivanje na $dest"

act_Cleanup
}

# raskidanje poziva
proc act_Cleanup { } {
puts "Procedura: act_Cleanup"
call close
}


#----------------------------------
# State Machine
#----------------------------------

set fsm(any_state,ev_disconnected) "act_Cleanup same_state"
set fsm(CALL_INIT,ev_setup_indication) "act_Setup PLACECALL"
set fsm(PLACECALL,ev_disconnected) "act_Cleanup CALLDISCONNECT"
set fsm(CALLDISCONNECT,ev_disconnected) "act_Cleanup same_state"
set fsm(CALLDISCONNECT,ev_disconnect_done) "act_Cleanup same_state"

fsm define fsm CALL_INIT

Hi,

Have you tried to apply the script?

Did it solve the issue, or you still need assistance on this?

Leszek

Hi Leszek,

 

we use this script to overcome the same problem,

or at least in the offices where the provider cannot enable Previous Through Connection on their side.

 

I noticed that external mobile numbers, or international numbers, can reach us, but national and local landlines have issues...the call will be immediately disconnected after we send the CONNECT message.

The interesting things is that all offices so far, where this issue present is, have an open numbering plan.

If we deactivate the script these calls are coming through.

 

Thanks in advance,

Ivan

SK T1
Level 1
Level 1

Dear Leszek Wojnarski

Thanks for your help !

I've raised this issue to Cisco TAC and this issue is CUCM bug.

The solution from TAC looks as your script.

Now problem solved.

Thanks again !

SK