[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* Protocol Discriminator : 0x08 CRV Length : 2 CRV Value : 0x0009 Message Type : 0x05: SETUP Bearer Capability: Length Of IE=3 Data 8090A3 Display: Length Of IE=9 Data 6272322070686E2034 Calling Party Number: Length Of IE=6 Data 008133303036 Called Party Number: Length Of IE=5 Data 8035303032 User-User: Length Of IE=176 Data 0520A0060008914A0004014006004200520032002D00520054005228C0B5120B436973636F47617465776179003240023C0504010020402C0501FE55CEEAA2C411E0803A80B055C3ADAB00CD1D820007000A0A7002C7471100FE566B12A2C411E0803C80B055C3ADAB340213000C6013800B050001000A0A700241F3801E40060401004C60138012150001000A0A700241F2000A0A700241F3800100010001800180010
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 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
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
[OSL | CCIE_Voice] SIP SRST
I need help with SIP SRST My SIP phones wait 360 seconds before unregister from SRST GW and reregister back to CUCM. SCCP phones meanwhile only wait 30 seconds. it seems that "Connection Monitor Duration" only changes the SCCP endpoints behavior. I changed the "registrar server expires min max" values but it didn't help. what settings are used to control the SIP reregisteration time in SRST? thanks, Joe ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
