Re: [OSL | CCIE_Voice] Conference codec explanation
Setting the service parameter to true allows g729 to be negotiated for the conference instead of g729b or g729ab. When G729b is enabled, I guess the system is just designed to give it a higher priority. Thanks for the tip Samson From: dpa...@fidelus.com To: samson_kar...@hotmail.com; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Conference codec explanation Date: Wed, 20 Nov 2013 16:16:47 + Check out the CCM service parameter “Strip G.729 Annex B (Silence Suppression) from Capabilities” – the default is FALSE which means that G729b will be advertised as a selectable codec during media negotiation; you can witness this in detailed CCM traces for MediaManager’s capabilities pre-check. I’ve configured this for TRUE on numerous occasions to disable G729b negotiation cluster wide. Hope this helps. - Dan From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Samson Kareem Sent: Monday, November 18, 2013 11:47 AM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Conference codec explanation HI, Can anyone explain to me the following logic: I am making a conference call between 2 phones at site C and a phone at site B. The conference resource is on the site B gateway. When the call is up the sh sccp connections cmd shows that the codec negotiated is G729b for the site C phones and G711 for the site B phone. (CUCM region settings are G711 for intra-region calls G729 for inter-region calls) BR1#sh sccp conn sess_idconn_id stype mode codec sport rport ripaddr 33556439 33554497 conf sendrecv g729b 18468 17118 192.168.45.130 33556439 33554495 conf sendrecv g729b 17116 29316 192.168.45.121 33556439 33554493 conf sendrecv g711u 18868 18282 192.168.35.121 My question is why is G729b negotiated? I was expecting G729... If I remove G729b from the dspfarm profile, then G729ab is negotiated and if I remove that G729 gets negotiated. It's not codec complexity, as 729b is high complexity. I thought it might be configuration order of the codecs but removing and re-adding a codec does not make any difference. Sorry if I'm missing something obvious, it's been a long day but would appreciate it if someone could explain this to me. thanks in advance Samson ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
[OSL | CCIE_Voice] Conference codec explanation
HI, Can anyone explain to me the following logic: I am making a conference call between 2 phones at site C and a phone at site B. The conference resource is on the site B gateway. When the call is up the sh sccp connections cmd shows that the codec negotiated is G729b for the site C phones and G711 for the site B phone. (CUCM region settings are G711 for intra-region calls G729 for inter-region calls) BR1#sh sccp conn sess_idconn_id stype mode codec sport rport ripaddr 33556439 33554497 conf sendrecv g729b 18468 17118 192.168.45.130 33556439 33554495 conf sendrecv g729b 17116 29316 192.168.45.121 33556439 33554493 conf sendrecv g711u 18868 18282 192.168.35.121 My question is why is G729b negotiated? I was expecting G729... If I remove G729b from the dspfarm profile, then G729ab is negotiated and if I remove that G729 gets negotiated. It's not codec complexity, as 729b is high complexity. I thought it might be configuration order of the codecs but removing and re-adding a codec does not make any difference. Sorry if I'm missing something obvious, it's been a long day but would appreciate it if someone could explain this to me. thanks in advance Samson ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Thanks for sharing the link.. In the end I reconfigured the gateway from scratch as MGCP after a reload and this time calls complete ok.. Date: Wed, 23 Oct 2013 11:14:27 -0400 From: ising...@gmail.com To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Outbound PSTN call drops You may want to look into Bug ID: CSCsx67255...link below. http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetailsbugId=CSCsx67255from=summary Inder Singh CCIE™ Voice #38235 Sr. Network Engineer, Unified Communications ___ 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 ___ 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
[OSL | CCIE_Voice] Outbound PSTN call drops
Hi All, I am hitting an issue where outbound PSTN calls are failing after the call initially seems to setup ok. Then the H323 gateway sends a disconnect to the PSTN and the call drops as per below. Oct 21 16:42:59.876: ISDN Se0/3/0:15 Q931: TX - SETUP pd = 8 callref = 0x008C Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98383 Exclusive, Channel 3 Display i = 'Tobias Funke' Calling Party Number i = 0x1181, '17707022001' Plan:ISDN, Type:International Called Party Number i = 0x91, '97148037333' Plan:ISDN, Type:International Oct 21 16:42:59.908: ISDN Se0/3/0:15 Q931: RX - CALL_PROC pd = 8 callref = 0x808C Channel ID i = 0xA98383 Exclusive, Channel 3 Oct 21 16:42:59.916: ISDN Se0/3/0:15 Q931: RX - ALERTING pd = 8 callref = 0x808C Progress Ind i = 0x8188 - In-band info or appropriate now available Oct 21 16:42:59.944: ISDN Se0/3/0:15 Q931: TX - DISCONNECT pd = 8 callref = 0x008C == Cause i = 0x80AF - Resource unavailable, unspecified Oct 21 16:42:59.952: ISDN Se0/3/0:15 Q931: RX - RELEASE pd = 8 callref = 0x808C Oct 21 16:42:59.956: ISDN Se0/3/0:15 Q931: TX - RELEASE_COMP pd = 8 callref = 0x008C I first thought it was a DSP resource issue as the disconnect cause is Cause i = 0x80AF - Resource unavailable, unspecified but I checked the status of DSPs using #show voice dsp group all and no problems there. I found an old post from OSL Nov 2011 where someone suggested a codec mismatch with the H245 negotiation which causes the call to drop immediately after the alerting message. The thing is I have a voice class codec configured and in any case, the gateway was originally an MGCP gateway and calls were failing with the same ISDN disconnect cause (I only changed it to a H323 g/w for troubleshooting purposes). I tried using debug cch323 h245 and have pasted the output received after the ISDN alerting message below. I believe this is when codec negotiation takes place on the voip leg of the call between CUCM and the g/w. Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_channel_established_ind: Using fd=4 to send msgs Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_send_event_to_h245_connection_sm: Changing to new event H245_ESTABLISHED_EVENT Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_connection_sm: H245_LISTEN: Received event H245_ESTABLISHED_EVENT while at H245_WAITING state Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_set_new_state: Changing from H245_WAITING state to H245_CONNECTED state Oct 21 16:25:16.653: //51/8043215D0100/H323/run_h245_iwf_sm: received IWF_EV_H245_CONNECTED while at state IWF_IDLE Oct 21 16:25:16.653: //51/8043215D0100/H323/h245_iwf_set_new_state: changing from IWF_IDLE state to IWF_AWAIT_CAP_MSD_RESP state Oct 21 16:25:16.657: //51/8043215D0100/H323/cch323_run_h245_cap_out_sm: Received H245_EVENT_CAP_REQ while at state IDLE Oct 21 16:25:16.657: //51/8043215D0100/H323/h245_cap_out_set_new_state: changing from IDLE state to AWAITING_RESPONSE state Oct 21 16:25:16.657: //51/8043215D0100/H323/cch323_run_h245_ms_sm: Received event H245_EVENT_MSD while at state H245_MS_NONE Oct 21 16:25:16.657: //51/8043215D0100/H323/cch323_run_h245_ms_sm: Sent MSD Request Oct 21 16:25:16.657: //51/8043215D0100/H323/h245_ms_set_new_state: Changing from H245_MS_NONE state to H245_MS_OUTGOING_WAIT state does anyone have any pointers? thanks Samson ___ 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
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Hi Daniel, Viki Thanks for the tips..I'll look a bit deeper into the H245 capabilities exchange next time I lab. If I figure it out, I'll let you know. @ Viki - yes I tried the channel negotiation command, no joy and no slip errors or anything on the controller.. Thanks Samson From: dpa...@fidelus.com To: samson_kar...@hotmail.com; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Outbound PSTN call drops Date: Mon, 21 Oct 2013 21:52:49 + There’s not enough information to provide a definitive answer, but it does sound like a media negotiation issue to me as well, especially since you received the same error when using MGCP control. ALERTING is one of a few ISDN messages that trigger an audio connection attempt via various internal processes to CCM; it’s at this point that media capabilities are shared, compared, and negotiated. My suggestion would be to debug h245 asn1 at the gateway and review detailed CCM traces off the CUCM node – focus on the TCS and MSD sessions. The last entry in the output you provided below shows the router began waiting for the master/slave determination to occur, but I have a feeling the rest of the output was simply cut off so I won’t focus on that. Off the top of my head… make sure the capabilities being advertised and matched are equal to or below the configured bitrate on the associated region relationship – in traces, you’ll see an attempt at region capabilities matching after the exchange of TCS – I’d also check for any capabilities mismatch, transcoder or MTP allocation attempts, etc. after the TCS exchange (assuming you keep it a H.323 gateway). Hope you find this helpful. - Daniel From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Samson Kareem Sent: Monday, October 21, 2013 1:33 PM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Outbound PSTN call drops Hi All, I am hitting an issue where outbound PSTN calls are failing after the call initially seems to setup ok. Then the H323 gateway sends a disconnect to the PSTN and the call drops as per below. Oct 21 16:42:59.876: ISDN Se0/3/0:15 Q931: TX - SETUP pd = 8 callref = 0x008C Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98383 Exclusive, Channel 3 Display i = 'Tobias Funke' Calling Party Number i = 0x1181, '17707022001' Plan:ISDN, Type:International Called Party Number i = 0x91, '97148037333' Plan:ISDN, Type:International Oct 21 16:42:59.908: ISDN Se0/3/0:15 Q931: RX - CALL_PROC pd = 8 callref = 0x808C Channel ID i = 0xA98383 Exclusive, Channel 3 Oct 21 16:42:59.916: ISDN Se0/3/0:15 Q931: RX - ALERTING pd = 8 callref = 0x808C Progress Ind i = 0x8188 - In-band info or appropriate now available Oct 21 16:42:59.944: ISDN Se0/3/0:15 Q931: TX - DISCONNECT pd = 8 callref = 0x008C == Cause i = 0x80AF - Resource unavailable, unspecified Oct 21 16:42:59.952: ISDN Se0/3/0:15 Q931: RX - RELEASE pd = 8 callref = 0x808C Oct 21 16:42:59.956: ISDN Se0/3/0:15 Q931: TX - RELEASE_COMP pd = 8 callref = 0x008C I first thought it was a DSP resource issue as the disconnect cause is Cause i = 0x80AF - Resource unavailable, unspecified but I checked the status of DSPs using #show voice dsp group all and no problems there. I found an old post from OSL Nov 2011 where someone suggested a codec mismatch with the H245 negotiation which causes the call to drop immediately after the alerting message. The thing is I have a voice class codec configured and in any case, the gateway was originally an MGCP gateway and calls were failing with the same ISDN disconnect cause (I only changed it to a H323 g/w for troubleshooting purposes). I tried using debug cch323 h245 and have pasted the output received after the ISDN alerting message below. I believe this is when codec negotiation takes place on the voip leg of the call between CUCM and the g/w. Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_channel_established_ind: Using fd=4 to send msgs Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_send_event_to_h245_connection_sm: Changing to new event H245_ESTABLISHED_EVENT Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_connection_sm: H245_LISTEN: Received event H245_ESTABLISHED_EVENT while at H245_WAITING state Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_set_new_state: Changing from H245_WAITING state to H245_CONNECTED state Oct 21 16:25:16.653: //51/8043215D0100/H323/run_h245_iwf_sm: received IWF_EV_H245_CONNECTED while at state IWF_IDLE Oct 21 16:25:16.653: //51/8043215D0100/H323/h245_iwf_set_new_state: changing
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Hi Sandeep, ios is 12.4 22 T Thanks Samson From: samson_kar...@hotmail.com To: ccie_voice@onlinestudylist.com Date: Mon, 21 Oct 2013 22:14:24 + Subject: Re: [OSL | CCIE_Voice] Outbound PSTN call drops Hi Daniel, Viki Thanks for the tips..I'll look a bit deeper into the H245 capabilities exchange next time I lab. If I figure it out, I'll let you know. @ Viki - yes I tried the channel negotiation command, no joy and no slip errors or anything on the controller.. Thanks Samson From: dpa...@fidelus.com To: samson_kar...@hotmail.com; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Outbound PSTN call drops Date: Mon, 21 Oct 2013 21:52:49 + There’s not enough information to provide a definitive answer, but it does sound like a media negotiation issue to me as well, especially since you received the same error when using MGCP control. ALERTING is one of a few ISDN messages that trigger an audio connection attempt via various internal processes to CCM; it’s at this point that media capabilities are shared, compared, and negotiated. My suggestion would be to debug h245 asn1 at the gateway and review detailed CCM traces off the CUCM node – focus on the TCS and MSD sessions. The last entry in the output you provided below shows the router began waiting for the master/slave determination to occur, but I have a feeling the rest of the output was simply cut off so I won’t focus on that. Off the top of my head… make sure the capabilities being advertised and matched are equal to or below the configured bitrate on the associated region relationship – in traces, you’ll see an attempt at region capabilities matching after the exchange of TCS – I’d also check for any capabilities mismatch, transcoder or MTP allocation attempts, etc. after the TCS exchange (assuming you keep it a H.323 gateway). Hope you find this helpful. - Daniel From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Samson Kareem Sent: Monday, October 21, 2013 1:33 PM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Outbound PSTN call drops Hi All, I am hitting an issue where outbound PSTN calls are failing after the call initially seems to setup ok. Then the H323 gateway sends a disconnect to the PSTN and the call drops as per below. Oct 21 16:42:59.876: ISDN Se0/3/0:15 Q931: TX - SETUP pd = 8 callref = 0x008C Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98383 Exclusive, Channel 3 Display i = 'Tobias Funke' Calling Party Number i = 0x1181, '17707022001' Plan:ISDN, Type:International Called Party Number i = 0x91, '97148037333' Plan:ISDN, Type:International Oct 21 16:42:59.908: ISDN Se0/3/0:15 Q931: RX - CALL_PROC pd = 8 callref = 0x808C Channel ID i = 0xA98383 Exclusive, Channel 3 Oct 21 16:42:59.916: ISDN Se0/3/0:15 Q931: RX - ALERTING pd = 8 callref = 0x808C Progress Ind i = 0x8188 - In-band info or appropriate now available Oct 21 16:42:59.944: ISDN Se0/3/0:15 Q931: TX - DISCONNECT pd = 8 callref = 0x008C == Cause i = 0x80AF - Resource unavailable, unspecified Oct 21 16:42:59.952: ISDN Se0/3/0:15 Q931: RX - RELEASE pd = 8 callref = 0x808C Oct 21 16:42:59.956: ISDN Se0/3/0:15 Q931: TX - RELEASE_COMP pd = 8 callref = 0x008C I first thought it was a DSP resource issue as the disconnect cause is Cause i = 0x80AF - Resource unavailable, unspecified but I checked the status of DSPs using #show voice dsp group all and no problems there. I found an old post from OSL Nov 2011 where someone suggested a codec mismatch with the H245 negotiation which causes the call to drop immediately after the alerting message. The thing is I have a voice class codec configured and in any case, the gateway was originally an MGCP gateway and calls were failing with the same ISDN disconnect cause (I only changed it to a H323 g/w for troubleshooting purposes). I tried using debug cch323 h245 and have pasted the output received after the ISDN alerting message below. I believe this is when codec negotiation takes place on the voip leg of the call between CUCM and the g/w. Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_channel_established_ind: Using fd=4 to send msgs Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_send_event_to_h245_connection_sm: Changing to new event H245_ESTABLISHED_EVENT Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_connection_sm: H245_LISTEN: Received event H245_ESTABLISHED_EVENT while at H245_WAITING state Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_set_new_state: Changing from H245_WAITING state
Re: [OSL | CCIE_Voice] SNR with Local Route Groups
Thanks for the confirmation Ashok. Date: Tue, 16 Jul 2013 10:25:38 +0800 Subject: Re: [OSL | CCIE_Voice] SNR with Local Route Groups From: ping.as...@gmail.com To: samson_kar...@hotmail.com CC: ccie_voice@onlinestudylist.com It's a bug which you mentioned.https://supportforums.cisco.com/thread/2034658 On Tuesday, 16 July 2013, Samson Kareem wrote: Guys, I'm testing SNR and am seeing some strange behaviour. When I call the users deskphone, the mobile phone only rings if I am not using a standard local route group. When I use a normal route group and reference that via a route list directly on the route pattern, the mobile rings as expected.. The route group and the slrg both have the same MGCP gateway.. Has anyone seen this behaviour before? I have seen CSCtc68651 which looks like it might be the isse but I'm not sure. Thanks Samson -- Ashok Kumar Boinpally. ___ 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
[OSL | CCIE_Voice] SNR with Local Route Groups
Guys, I'm testing SNR and am seeing some strange behaviour. When I call the users deskphone, the mobile phone only rings if I am not using a standard local route group. When I use a normal route group and reference that via a route list directly on the route pattern, the mobile rings as expected.. The route group and the slrg both have the same MGCP gateway.. Has anyone seen this behaviour before? I have seen CSCtc68651 which looks like it might be the isse but I'm not sure. Thanks Samson ___ 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
[OSL | CCIE_Voice] UCCX 7.0.2 Install Issues
Hi All, I know this is an old topic but I can't find the resolution for the version of software I have. I'm trying to install UCCX 7.0.2 on Windows 2003 R2 on an ESXi VM with these settings 2GB RAM 80GB Hard Disk Thick provisioned Before kicking off the install, I edited the registry with the following HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems\Model Hardware 7835H05 Memory 2048 Speed 3400 I enabled IIS and rebooted before and after the registry edit When I run the install I get an error along the lines of Cisco Unified Contact Center Express is not supported on the current MCS OS, Upgrade to 2003.1.5 ra (or similar) I also tried editing registry with HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\Systems Info\OS Image Version 2003.1.5 Any ideas ?? Thanks Samson ___ 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
[OSL | CCIE_Voice] UCCX 7.0.2 Install Issues
Hi All, I know this is an old topic but I can't find the resolution for the version of software I have. I'm trying to install UCCX 7.0.2 on Windows 2003 R2 on an ESXi VM with these settings 2GB RAM 80GB Hard Disk Thick provisioned Before kicking off the install, I edited the registry with the following HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems\Model Hardware 7835H05 Memory 2048 Speed 3400 I enabled IIS and rebooted before and after the registry edit When I run the install I get an error along the lines of Cisco Unified Contact Center Express is not supported on the current MCS OS, Upgrade to 2003.1.5 ra (or similar) I also tried editing registry with HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\Systems Info\OS Image Version 2003.1.5 Any ideas ?? Thanks Samson ___ 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
