Re: [OSL | CCIE_Voice] CME to CUCM

[Devakanth Gangavarapu]

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"  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  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 R&S, Collaboration, Data Center, Wireless & Security Videos ::
>>
>> iPexpert on YouTube: www.youtube.com/ipexpertinc
>>
>
>
>
> --
> André de Castro
>
> ___
> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
>
> iPexpert on YouTube: www.youtube.com/ipexpertinc
>
___
Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::

iPexpert on YouTube: www.youtube.com/ipexpertinc

Re: [OSL | CCIE_Voice] CME to CUCM

[André de Castro]

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  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 R&S, Collaboration, Data Center, Wireless & Security Videos ::
>
> iPexpert on YouTube: www.youtube.com/ipexpertinc
>



-- 
André de Castro
___
Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::

iPexpert on YouTube: www.youtube.com/ipexpertinc

Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant

[Cristobal Priego]

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 

> 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 * wrote:
>>>
>>>
>>> From: Emin Guliyev 
>>> Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration
>>> assistant
>>> To: "Art Joe Babakhani Gharibian" , "
>>> 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 *
>>>

Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant

[Art Joe Babakhani Gharibian]

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 * wrote:
>>
>>
>> From: Emin Guliyev 
>> Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration
>> assistant
>> To: "Art Joe Babakhani Gharibian" , "
>> 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:4

Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant

[Art Joe Babakhani Gharibian]

thanks, it was the codec I changed it and now is working.

On Fri, Jul 1, 2011 at 7:57 AM, manishankar pandey  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 * wrote:
>
>
> From: Emin Guliyev 
> Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration
> assistant
> To: "Art Joe Babakhani Gharibian" , "
> 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_h22

Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant

[manishankar pandey]

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  wrote:
From: Emin Guliyev Subject: Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistantTo: "Art Joe Babakhani Gharibian" , "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:
•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 GharibianSent: Friday, July 01, 2011 12:47 AMTo: ccie_voice@onlinestudylist.comSubject: [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: 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_inc

Re: [OSL | CCIE_Voice] CME to CUCM Via CUBE configuration assistant

[Emin Guliyev]

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.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: 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

Proto