07-08-2016 11:11 AM - edited 03-17-2019 07:28 AM
Reception Hunt Pilot transfer to MeetMe Number disconnects.
Call Flow:
FXO Line => CTI 6000 => CUC Call Handle 6000 => Digit 0 => Call Handler 4505 => Transfer Rule (STD) => Hunt Pilot 4505 => Reception Answers DN 4000-4005 (Longest Idle Time) => Transfer to MeetMe DN 5550
Solved! Go to Solution.
07-08-2016 11:21 AM
Can the receptionist start the meete? This would confirm proper partition/CSS issue.
What codec is the conference bridge using? Might be codec negotiation issue, reviewing CM trace files would reveal this or any other cause.
07-08-2016 11:15 AM
Is MeetMe already started? Remember to join meetMe bridges you first need to open it by pressing the Meetme softkey on a phone.
07-08-2016 11:16 AM
Yes testing was done with the MeetMe conference started before reception transfer to 5550.
07-08-2016 11:21 AM
Can the receptionist start the meete? This would confirm proper partition/CSS issue.
What codec is the conference bridge using? Might be codec negotiation issue, reviewing CM trace files would reveal this or any other cause.
07-08-2016 11:30 AM
The receptionist can create the MeetMe but as soon as she transfers one of the 4000-4005 DN to the MeetMe DN they get disconnected.
I did more testing and all reception DN's can create the MeetMe conference.
07-08-2016 01:11 PM
I'd try a simpler test, call the reception directly, can she transfer the call to the meet-me DN?
What protocol are you using on the GW?
And just to be clear, someone else, not the receptionist, is the one who starts the meet-me and waits for the other participants to join??
07-08-2016 02:17 PM
I'm using the Software CFB. Yes everyone can create and join a MeetMe conference the way I have it configure at the moment.
Just incoming FXO calls through the Call Handlers are being disconnected once transferred to the MeetMe.
07-08-2016 02:19 PM
OK, what protocol are you using on the GW with that FXO?
07-08-2016 02:28 PM
voice service voip
ip address trusted list
ipv4 172.27.199.11
ipv4 172.27.199.14
ipv4 172.27.199.15
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
no supplementary-service sip handle-replaces
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no fax-relay sg3-to-g3
modem passthrough nse codec g711ulaw
sip
bind control source-interface BVI1
bind media source-interface BVI1
asymmetric payload full
no update-callerid
!
!
voice class uri ucm sip
host 172.27.199.11
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
codec preference 3 g711alaw
codec preference 4 ilbc
!
I'm not sure this is below section is much help since I'm using the software CFB:
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
sccp ccm 172.27.199.11 identifier 1 priority 1 version 7.0
!
sccp ccm group 1
bind interface BVI1
associate ccm 1 priority 1
associate profile 1 register CFB1ARBORG
!
!
ccm-manager sccp local BVI1
!
dspfarm profile 1 conference
description Arborg Conference Bridges
codec g729br8
codec g729r8
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
codec g722-64
codec ilbc
maximum sessions 3
associate application SCCP
!
07-11-2016 03:46 PM
It was codec mismatch between the Conference Bridge Device Pool and Gateway codex.
Thanks everyone for the support.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide