Re: [OSL | CCIE_Voice] CME to CUCM
Hi Ben, Registering the remote phones to the CUCM would not be an option? Regards, On Thu, Jul 3, 2014 at 4:13 PM, Ben John benjoh...@hotmail.com wrote: Hello, I have a CME already running at one of our remote site i am trying to connect the CME to my Callmanager so we can have 4 digits dialing between both site the HQ and the remote. I don't want to change the call routing at both just want to make a 4 digit dialing in between. Here are my configuration please let me know if i am missing something ON the CallManager we will create the following: · New Region · New Location · New Region · New Device Pool · New Gateway · New Route Group · New Route List · New Route Pattern for 4 digits dialing On the CME we will create the following: · H.323 gateway · New voip dial-peer with 4 digits something like …. and destination to my callmanager Thanks, Ben ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc -- André de Castro ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] CME to CUCM
Hi Ben You will have to add media resources to the device pool which shud have transcoders and mtp. Dev On 4/07/2014 7:30 AM, André de Castro aocbra...@gmail.com wrote: Hi Ben, Registering the remote phones to the CUCM would not be an option? Regards, On Thu, Jul 3, 2014 at 4:13 PM, Ben John benjoh...@hotmail.com wrote: Hello, I have a CME already running at one of our remote site i am trying to connect the CME to my Callmanager so we can have 4 digits dialing between both site the HQ and the remote. I don't want to change the call routing at both just want to make a 4 digit dialing in between. Here are my configuration please let me know if i am missing something ON the CallManager we will create the following: · New Region · New Location · New Region · New Device Pool · New Gateway · New Route Group · New Route List · New Route Pattern for 4 digits dialing On the CME we will create the following: · H.323 gateway · New voip dial-peer with 4 digits something like …. and destination to my callmanager Thanks, Ben ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc -- André de Castro ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant
Looks like it is failing due to codec negotiation. Media negotiation failure Typical scenarios include: *No codec match occurred. *H.323 or H.245 problem leading to failure in media negotiation 65 CC_CAUSE_BEARER_CAPABILITY_ NOT_IMPLEMENTED Indicates that the equipment sending this cause does not support the bearer capability requested. Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_send_release: Cause = 65; Location = 0 From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Art Joe Babakhani Gharibian Sent: Friday, July 01, 2011 12:47 AM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant Has anyone tested a call from CME to CUCM via Gatekeeper and CUBE? Could you please provide a working configuration sample? I have configured the gatekeeper to send the calls from CME to CUCM via CUBE. CME calls drop after matching an incoming voip dialpeer in the CUBE. I can't figure out why my calls get disconnected once they match an incoming dial-peer. It is worth mentioning that I use that exact same dial-peers to send calls from CUCM to CME and they work just fine. I am pasting some show and debug outputs. Thanks, Joe ON the CUBE show run | s dial-peer dial-peer voice 20 voip incoming called-number . dtmf-relay h245-alphanumeric no vad dial-peer voice 21 voip destination-pattern [1,3,5]... voice-class codec 1 session target ras dtmf-relay h245-alphanumeric no vad show run | s gatek gatekeeper zone local Spain ipexpert.comhttp://ipexpert.com outvia VGK zone local US ipexpert.comhttp://ipexpert.com outvia VGK zone local VGK ipexpert.comhttp://ipexpert.com zone remote PSTN-WAN ipexpert.comhttp://ipexpert.com 10.10.100.2 1719 zone prefix US 1... gw-priority 10 gk-trunk_1 zone prefix US 1... gw-priority 9 gk-trunk_2 zone prefix Spain 3... zone prefix US 5... gw-priority 10 gk-trunk_1 zone prefix US 5... gw-priority 9 gk-trunk_2 gw-type-prefix 1#* default-technology no shutdown on the CUBE debug voice dialpeer Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 On the CUBE debug cch323 h225 Jun 29 21:49:46.398: //-1//H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN Jun 29 21:49:46.398: //-1//H323/setup_ind: Entry Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: callingNumber[3006] calledNumber[5002] Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: calling IE present Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: == PI = 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/setup_ind: Receive: infoXCap 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/setup_ind: Receive: infoXCap ccb 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/setup_ind: setup_ind: is_overlap = 0, info_complete = 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_receiver: SETUPIND_CHOSEN: src address = 10.10.200.3; dest address = 10.10.112.2 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/run_h225_sm: Received event H225_EV_FS_SETUP_IND while at state H225_IDLE Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/idle_fsSetupInd_hdlr: Setup ccb 0x4A40CB50 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/act_fastStartSetupInd: full match is found Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/act_fastStartSetupInd: codec match = 2 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_create_incoming_callinfo_block: peer 4725E964, voice_peer_tag 20, ccb: 4A40CB50 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_send_release: Cause = 65; Location = 0 Jun 29 21:49:46.406: //33/8A1D25B080B9/H323/cch323_h225_send_release: h225TerminateRequest: src address = 168478723; dest address = 10.10.112.2 Jun 29 21:49:46.406: //33/8A1D25B080B9/H323/cch323_h225_set_new_state: Changing from H225_IDLE state to H225_WAIT_FOR_REL_COMP state Jun 29 21:49:46.410: //33/8A1D25B080B9/H323/run_h225_sm: Received event H225_EV_RELEASE_TIMER while at state H225_WAIT_FOR_REL_COMP Jun 29 21:49:46.410: //33/8A1D25B080B9/H323/cch323_h225_set_new_state: Changing from H225_WAIT_FOR_REL_COMP state to H225_IDLE state Jun 29 21:49:46.414: //-1//H323/validate_crv: No CCB for crv: 0x801D On The CUBE debug h225 q931 Protocol Discriminator
Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant
thanks, it was the codec I changed it and now is working. On Fri, Jul 1, 2011 at 7:57 AM, manishankar pandey manishankar...@yahoo.com wrote: Yes this has to do with Codec mismatch. Or the Interpretation of Fast start and Slow start. Try using the below option 1) Create Voice class and then bind it to dial-peer Example : voice class h323 1 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start fast ! voice class h323 5 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start interwork ! voice class h323 6 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start slow And under Dial-peer VoIP, try testing with each Voice class h323 command voice-class h323 1/5/6 Thanks --- On *Fri, 7/1/11, Emin Guliyev eguli...@fidelus.com* wrote: From: Emin Guliyev eguli...@fidelus.com Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant To: Art Joe Babakhani Gharibian ciscoie2...@gmail.com, ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Date: Friday, July 1, 2011, 6:01 PM Looks like it is failing due to codec negotiation. Media negotiation failure Typical scenarios include: •[image: Description: http://www.cisco.com/en/US/i/templates/blank.gif]No codec match occurred. •[image: Description: http://www.cisco.com/en/US/i/templates/blank.gif]H.323 or H.245 problem leading to failure in media negotiation 65 CC_CAUSE_BEARER_CAPABILITY_ NOT_IMPLEMENTED Indicates that the equipment sending this cause does not support the bearer capability requested. Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_send_release: Cause = 65; Location = 0 *From:* ccie_voice-boun...@onlinestudylist.com [mailto: ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *Art Joe Babakhani Gharibian *Sent:* Friday, July 01, 2011 12:47 AM *To:* ccie_voice@onlinestudylist.com *Subject:* [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant Has anyone tested a call from CME to CUCM via Gatekeeper and CUBE? Could you please provide a working configuration sample? I have configured the gatekeeper to send the calls from CME to CUCM via CUBE. CME calls drop after matching an incoming voip dialpeer in the CUBE. I can’t figure out why my calls get disconnected once they match an incoming dial-peer. It is worth mentioning that I use that exact same dial-peers to send calls from CUCM to CME and they work just fine. I am pasting some show and debug outputs. Thanks, Joe *ON the CUBE show run | s dial-peer * dial-peer voice 20 voip incoming called-number . dtmf-relay h245-alphanumeric no vad dial-peer voice 21 voip destination-pattern [1,3,5]... voice-class codec 1 session target ras dtmf-relay h245-alphanumeric no vad *show run | s gatek * gatekeeper zone local Spain ipexpert.com outvia VGK zone local US ipexpert.com outvia VGK zone local VGK ipexpert.com zone remote PSTN-WAN ipexpert.com 10.10.100.2 1719 zone prefix US 1... gw-priority 10 gk-trunk_1 zone prefix US 1... gw-priority 9 gk-trunk_2 zone prefix Spain 3... zone prefix US 5... gw-priority 10 gk-trunk_1 zone prefix US 5... gw-priority 9 gk-trunk_2 gw-type-prefix 1#* default-technology no shutdown *on the CUBE debug voice dialpeer * Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 *On the CUBE debug cch323 h225 * Jun 29 21:49:46.398: //-1//H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN Jun 29 21:49:46.398: //-1//H323/setup_ind: Entry Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: callingNumber[3006] calledNumber[5002] Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: calling IE present Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: == PI = 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/setup_ind: Receive: infoXCap 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/setup_ind: Receive: infoXCap ccb 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/setup_ind: setup_ind: is_overlap = 0, info_complete = 0 Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_receiver: SETUPIND_CHOSEN
Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant
One more thing. I couldn't answer the call without call start interwork so I added the following class to both incoming and outgoing dial-peers. voice class h323 5 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start interwork Thanks, Joe On Fri, Jul 1, 2011 at 11:34 AM, Art Joe Babakhani Gharibian ciscoie2...@gmail.com wrote: thanks, it was the codec I changed it and now is working. On Fri, Jul 1, 2011 at 7:57 AM, manishankar pandey manishankar...@yahoo.com wrote: Yes this has to do with Codec mismatch. Or the Interpretation of Fast start and Slow start. Try using the below option 1) Create Voice class and then bind it to dial-peer Example : voice class h323 1 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start fast ! voice class h323 5 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start interwork ! voice class h323 6 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start slow And under Dial-peer VoIP, try testing with each Voice class h323 command voice-class h323 1/5/6 Thanks --- On *Fri, 7/1/11, Emin Guliyev eguli...@fidelus.com* wrote: From: Emin Guliyev eguli...@fidelus.com Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant To: Art Joe Babakhani Gharibian ciscoie2...@gmail.com, ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Date: Friday, July 1, 2011, 6:01 PM Looks like it is failing due to codec negotiation. Media negotiation failure Typical scenarios include: •[image: Description: http://www.cisco.com/en/US/i/templates/blank.gif]No codec match occurred. •[image: Description: http://www.cisco.com/en/US/i/templates/blank.gif]H.323 or H.245 problem leading to failure in media negotiation 65 CC_CAUSE_BEARER_CAPABILITY_ NOT_IMPLEMENTED Indicates that the equipment sending this cause does not support the bearer capability requested. Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_send_release: Cause = 65; Location = 0 *From:* ccie_voice-boun...@onlinestudylist.com [mailto: ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *Art Joe Babakhani Gharibian *Sent:* Friday, July 01, 2011 12:47 AM *To:* ccie_voice@onlinestudylist.com *Subject:* [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant Has anyone tested a call from CME to CUCM via Gatekeeper and CUBE? Could you please provide a working configuration sample? I have configured the gatekeeper to send the calls from CME to CUCM via CUBE. CME calls drop after matching an incoming voip dialpeer in the CUBE. I can’t figure out why my calls get disconnected once they match an incoming dial-peer. It is worth mentioning that I use that exact same dial-peers to send calls from CUCM to CME and they work just fine. I am pasting some show and debug outputs. Thanks, Joe *ON the CUBE show run | s dial-peer * dial-peer voice 20 voip incoming called-number . dtmf-relay h245-alphanumeric no vad dial-peer voice 21 voip destination-pattern [1,3,5]... voice-class codec 1 session target ras dtmf-relay h245-alphanumeric no vad *show run | s gatek * gatekeeper zone local Spain ipexpert.com outvia VGK zone local US ipexpert.com outvia VGK zone local VGK ipexpert.com zone remote PSTN-WAN ipexpert.com 10.10.100.2 1719 zone prefix US 1... gw-priority 10 gk-trunk_1 zone prefix US 1... gw-priority 9 gk-trunk_2 zone prefix Spain 3... zone prefix US 5... gw-priority 10 gk-trunk_1 zone prefix US 5... gw-priority 9 gk-trunk_2 gw-type-prefix 1#* default-technology no shutdown *on the CUBE debug voice dialpeer * Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 *On the CUBE debug cch323 h225 * Jun 29 21:49:46.398: //-1//H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN Jun 29 21:49:46.398: //-1//H323/setup_ind: Entry Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: callingNumber[3006] calledNumber[5002] Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: calling IE present Jun 29 21:49:46.398: //33/8A1D25B080B9/H323/setup_ind: == PI
Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant
if you remove the call start interwork and on your ucm h225 trunk un check wait for far end TCS set it should work as well 2011/7/1 Art Joe Babakhani Gharibian ciscoie2...@gmail.com One more thing. I couldn't answer the call without call start interwork so I added the following class to both incoming and outgoing dial-peers. voice class h323 5 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start interwork Thanks, Joe On Fri, Jul 1, 2011 at 11:34 AM, Art Joe Babakhani Gharibian ciscoie2...@gmail.com wrote: thanks, it was the codec I changed it and now is working. On Fri, Jul 1, 2011 at 7:57 AM, manishankar pandey manishankar...@yahoo.com wrote: Yes this has to do with Codec mismatch. Or the Interpretation of Fast start and Slow start. Try using the below option 1) Create Voice class and then bind it to dial-peer Example : voice class h323 1 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start fast ! voice class h323 5 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start interwork ! voice class h323 6 h225 timeout tcp establish 5 h225 display-ie ccm-compatible call start slow And under Dial-peer VoIP, try testing with each Voice class h323 command voice-class h323 1/5/6 Thanks --- On *Fri, 7/1/11, Emin Guliyev eguli...@fidelus.com* wrote: From: Emin Guliyev eguli...@fidelus.com Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant To: Art Joe Babakhani Gharibian ciscoie2...@gmail.com, ccie_voice@onlinestudylist.com ccie_voice@onlinestudylist.com Date: Friday, July 1, 2011, 6:01 PM Looks like it is failing due to codec negotiation. Media negotiation failure Typical scenarios include: •[image: Description: http://www.cisco.com/en/US/i/templates/blank.gif]No codec match occurred. •[image: Description: http://www.cisco.com/en/US/i/templates/blank.gif]H.323 or H.245 problem leading to failure in media negotiation 65 CC_CAUSE_BEARER_CAPABILITY_ NOT_IMPLEMENTED Indicates that the equipment sending this cause does not support the bearer capability requested. Jun 29 21:49:46.402: //33/8A1D25B080B9/H323/cch323_h225_send_release: Cause = 65; Location = 0 *From:* ccie_voice-boun...@onlinestudylist.com [mailto: ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *Art Joe Babakhani Gharibian *Sent:* Friday, July 01, 2011 12:47 AM *To:* ccie_voice@onlinestudylist.com *Subject:* [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant Has anyone tested a call from CME to CUCM via Gatekeeper and CUBE? Could you please provide a working configuration sample? I have configured the gatekeeper to send the calls from CME to CUCM via CUBE. CME calls drop after matching an incoming voip dialpeer in the CUBE. I can’t figure out why my calls get disconnected once they match an incoming dial-peer. It is worth mentioning that I use that exact same dial-peers to send calls from CUCM to CME and they work just fine. I am pasting some show and debug outputs. Thanks, Joe *ON the CUBE show run | s dial-peer * dial-peer voice 20 voip incoming called-number . dtmf-relay h245-alphanumeric no vad dial-peer voice 21 voip destination-pattern [1,3,5]... voice-class codec 1 session target ras dtmf-relay h245-alphanumeric no vad *show run | s gatek * gatekeeper zone local Spain ipexpert.com outvia VGK zone local US ipexpert.com outvia VGK zone local VGK ipexpert.com zone remote PSTN-WAN ipexpert.com 10.10.100.2 1719 zone prefix US 1... gw-priority 10 gk-trunk_1 zone prefix US 1... gw-priority 9 gk-trunk_2 zone prefix Spain 3... zone prefix US 5... gw-priority 10 gk-trunk_1 zone prefix US 5... gw-priority 9 gk-trunk_2 gw-type-prefix 1#* default-technology no shutdown *on the CUBE debug voice dialpeer * Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Calling Number=3006, Called Number=5002, Voice-Interface=0x0, Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE, Peer Info Type=DIALPEER_INFO_SPEECH Jun 29 21:49:12.911: //-1/762755B380B3/DPM/dpAssociateIncomingPeerCore: Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=20 *On the CUBE debug cch323 h225 * Jun 29 21:49:46.398: //-1//H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN Jun 29 21:49:46.398: //-1//H323/setup_ind: Entry Jun 29 21:49:46.398: //33/8A1D25B080B9/H323
