[OSL | CCIE_Voice] Standard Local RG troubleshooting: RouteGroup :RouteGroup Name= Standard Local Route Group

2012-02-06 Thread Ricardo Palaver

Hi Folks,  I am facing a problem with Standard local route group ...,  it is 
not working and I have no idea where could I troubleshoot it.  I configured as 
usual ... , RL - Standard Local RGIn each DP, I pointed to the respective 
gateway (using Local  Route Group param) and of course each phone with the 
respective device.  I tried  by using DNA, but it does not go further , the 
last point I see is  RouteGroup :RouteGroup Name= Standard Local Route Group  
..., As far as I know there is nothing in the service param to enable ... or 
there are something ?  Thanks all !___
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] Standard Local RG troubleshooting: RouteGroup :RouteGroup Name= Standard Local Route Group

2012-02-06 Thread Ricardo Palaver

Hi Willian ,  Yes,  DNA does  not revolve in the 7.X.  Do you know if there are 
any parameter to  double check?   May be any db table , or something.  I have 
not found any school boy error in the config...  Thanks a zillions!Subject: Re: 
[OSL | CCIE_Voice] Standard Local RG troubleshooting: RouteGroup :RouteGroup 
Name= Standard Local Route Group
From: w...@netcraftsmen.net
Date: Mon, 6 Feb 2012 19:45:53 -0500
CC: ccie_voice@onlinestudylist.com
To: ricardo.pala...@hotmail.com



Ricardo,
If I follow your question, I believe this is normal. DNA won't resolve Standard 
Local Route Group to the actual route group assigned to the device's DP. At 
least in version 7.x. In CUCM 8.5, it does resolve the actual route group name.
Regards,Bill
On Feb 6, 2012, at 7:05 PM, Ricardo Palaver wrote:Hi Folks, 
 
I am facing a problem with Standard local route group ...,  it is not working 
and I have no idea where could I troubleshoot it.  I configured as usual ... , 
RL - Standard Local RG
In each DP, I pointed to the respective gateway (using Local  Route Group 
param) and of course each phone with the respective device. 
 
I tried  by using DNA, but it does not go further , the last point I see is  
RouteGroup :RouteGroup Name= Standard Local Route Group ..., As far as I know 
there is nothing in the service param to enable ... or there are something ?
 
 
Thanks all !
 
 
 
___
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

Re: [OSL | CCIE_Voice] Standard Local RG troubleshooting: RouteGroup :RouteGroup Name= Standard Local Route Group

2012-02-06 Thread Ricardo Palaver

Hi Emanuel !.  No , it does not work .. As far as I know, this is for use AAR, 
or Am I wrong?  Thanks  !
 Date: Mon, 6 Feb 2012 23:01:14 -0200
Subject: Re: [OSL | CCIE_Voice] Standard Local RG troubleshooting: RouteGroup 
:RouteGroup Name= Standard Local Route Group
From: aedamasc...@gmail.com
To: ricardo.pala...@hotmail.com
CC: ccie_voice@onlinestudylist.com

Hello Ricardo,

You need to go to Service Parameters  Call Manager, and set the option Stop 
Routing on Unallocated Number Flag to FALSE

I hope this helps :)Emanuel Damasceno

CCNP Voice






On Mon, Feb 6, 2012 at 10:05 PM, Ricardo Palaver ricardo.pala...@hotmail.com 
wrote:





Hi Folks, 
 
I am facing a problem with Standard local route group ...,  it is not working 
and I have no idea where could I troubleshoot it.  I configured as usual ... , 
RL - Standard Local RG
In each DP, I pointed to the respective gateway (using Local  Route Group 
param) and of course each phone with the respective device. 

 
I tried  by using DNA, but it does not go further , the last point I see is  
RouteGroup :RouteGroup Name= Standard Local Route Group  ..., As far as I 
know there is nothing in the service param to enable ... or there are something 
?

 
 
Thanks all !
 
 
 
  

___

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

Re: [OSL | CCIE_Voice] ISDN Cause i = 0x80AF - Resource unavailable

2011-11-27 Thread Ricardo Palaver

Hi Folks., 
 
I was in the lab4. 
 
Datucha touched in the right point.  There is no ISDN problem since local calls 
was working properly. 
Unfortunatelly I can check it in the next lab session.
 
Thanks all for helping!. 
 
 



Date: Sun, 27 Nov 2011 09:34:21 -0500
From: ejzi...@gmail.com
To: whl...@gmail.com
CC: ccie_voice@onlinestudylist.com
Subject: Re: [OSL | CCIE_Voice] ISDN Cause i = 0x80AF - Resource unavailable

Bill what lab are you working on?


On Sun, Nov 27, 2011 at 7:55 AM, Bill Lake whl...@gmail.com wrote:

OK, if you are sure it is not a ISDN issue but it appears to be that the call 
is set up


Nov 26 22:10:48.504: ISDN Se0/0/0:15 Q931: RX - ALERTING pd = 8  callref = 
0x808D
Progress Ind i = 0x8188 - In-band info or appropriate now availab

you then get


Nov 26 22:10:48.548: ISDN Se0/0/0:15 Q931: TX - DISCONNECT pd = 8  callref = 
0x008D
Cause i = 0x80AF - Resource unavailable, unspecified

so maybe it is an IOS bug but we don't know what IOS you are running or do we 
know running config or the status of any of your system.  

Just guessing here but can you complete any calls over the PSTN connection?  If 
so what type of calls are completed?





On Sun, Nov 27, 2011 at 6:36 AM, datucha123 datucha123 datucha...@gmail.com 
wrote:


Bill, if you will take a dipper look at the Logs of ISDN, you will see the the 
Router send the ISD SETUP message, then received the Procceding and Alerting 
message. 
So the Voice port in operating normally. 
After the Alert message, the IP Side is starting - H245 is going for 
negotiation, and there is a problem in H323 IP Side, not in ISDN side. 
 
And I have already mentioned the Problem description in my earlier post. 
 
If there would the DSP issues, then the SETUP message will not be send even. 


On Sun, Nov 27, 2011 at 1:26 AM, Bill Lake whl...@gmail.com wrote:

This looks like it could be an ISDN issue:

Is your voice-port in an active (not shut down) state?

Do you have the proper DSP resources for your configuration?

Check these and post your configuration if this is not the issue.







On Sat, Nov 26, 2011 at 1:24 PM, datucha123 datucha123 datucha...@gmail.com 
wrote:


That's because of Codec Problem between HQ router and the CUCM.
 
Now look, as we know, when the CUCM sends the H323 SETUP message to GW, the GW, 
by default, begins the H245 Address announcement on Alert Message, and at that 
point the CUCM and GW have exchanged the H245 message, and the GW provides the 
Ring Back tone. Even when the CUCM is using the Slow Start.
Whereas CUCME can detect CUCM and start the H245 only on Connect Message, while 
the default one idicates h245 address on Alert. CUCME IP Phones cannot provide 
the In Band Ring Back tones, so that CUCM needs always the Slow start to CUCME, 
so that CUCM will provide the Local Ringback to its IP Phones until the H245 
address is received from CUCME (whereas CUCME will send the H245 address On 
Connect only to CUCM).
 
Now look, as for you case, you get the error message after the Alerting 
Message. What does happen at that moment? GW sends the Alert message with H245 
Address (and the TCS OLC negotiation begins). CUCM and GW have some problems 
with Codec negotation, and that's why you get that message. 
 
Try to ensure that you use the correct region to GW, and also the correct 
Codecs (or voice class codec) is configured on the GW. 
 
That's the problem of the Codec mismatch. 
 
 
 
 

 


On Sat, Nov 26, 2011 at 9:19 PM, Ricardo Palaver ricardo.pala...@hotmail.com 
wrote:





Hi Experts!, 
 
I 've already gave up to fix the problem below. 
 
I am calling from a HQ - phone #  to PSTN (BR2) region  but call fails  and 
it's returnning me the cause code: 0x80AF. 
 
In the Cisco community I found its an IOS bug,  so if it is,   someone here  
have already faced the same issue.
 
Can someone give me any idea on how to fix it ?
 
 
Thanks a zillions !..   have a great weekend all !
 
 

debug isdn q931 is  ON.
BR2-RTR#
Nov 26 22:10:48.460: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 
is 0x0 0x0, Calling num 2123945001
Nov 26 22:10:48.464: ISDN Se0/0/0:15 Q931: Sending SETUP  callref = 0x008D 
callID = 0x800E switch = primary-net5 interface = User
Nov 26 22:10:48.464: ISDN Se0/0/0:15 Q931: TX - SETUP pd = 8  callref = 0x008D
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'HQ Phone 1'
Calling Party Number i = 0x0081, '2123945001'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '32141891'
Plan:Unknown, Type:Unknown
Nov 26 22:10:48.500: ISDN Se0/0/0:15 Q931: RX - CALL_PROC pd = 8  callref = 
0x808D
Channel ID i = 0xA98381
Exclusive, Channel 1
Nov 26 22:10:48.504

[OSL | CCIE_Voice] ISDN Cause i = 0x80AF - Resource unavailable

2011-11-26 Thread Ricardo Palaver

Hi Experts!, 
 
I 've already gave up to fix the problem below. 
 
I am calling from a HQ - phone #  to PSTN (BR2) region  but call fails  and 
it's returnning me the cause code: 0x80AF. 
 
In the Cisco community I found its an IOS bug,  so if it is,   someone here  
have already faced the same issue.
 
Can someone give me any idea on how to fix it ?
 
 
Thanks a zillions !..   have a great weekend all !
 
 

debug isdn q931 is  ON.
BR2-RTR#
Nov 26 22:10:48.460: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 
is 0x0 0x0, Calling num 2123945001
Nov 26 22:10:48.464: ISDN Se0/0/0:15 Q931: Sending SETUP  callref = 0x008D 
callID = 0x800E switch = primary-net5 interface = User
Nov 26 22:10:48.464: ISDN Se0/0/0:15 Q931: TX - SETUP pd = 8  callref = 0x008D
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = 'HQ Phone 1'
Calling Party Number i = 0x0081, '2123945001'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '32141891'
Plan:Unknown, Type:Unknown
Nov 26 22:10:48.500: ISDN Se0/0/0:15 Q931: RX - CALL_PROC pd = 8  callref = 
0x808D
Channel ID i = 0xA98381
Exclusive, Channel 1
Nov 26 22:10:48.504: ISDN Se0/0/0:15 Q931: RX - ALERTING pd = 8  callref = 
0x808D
Progress Ind i = 0x8188 - In-band info or appropriate now availab
BR2-RTR#le
Nov 26 22:10:48.548: ISDN Se0/0/0:15 Q931: TX - DISCONNECT pd = 8  callref = 
0x008D
Cause i = 0x80AF - Resource unavailable, unspecified
Nov 26 22:10:48.560: ISDN Se0/0/0:15 Q931: RX - RELEASE pd = 8  callref = 
0x808D
Nov 26 22:10:48.564: ISDN Se0/0/0:15 Q931: TX - RELEASE_COMP pd = 8  callref = 
0x008D
  ___
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] Lab loading - ProctorLabs

2011-11-22 Thread Ricardo Palaver

Hi Dear, 
 
Just a quick question. I do not know if is there someone here who uses the 
proctorlabs ... but .. 
 
Is it commum the labs loading be wrong ?  An example ,  I am in the Workbook1 / 
LAB 4 and I faced that all services in the SUB was down, but per my 
understanding these services were supposed to be up once the tasks from this 
lab are not related to this kind of feature. 
 
This means that everytime I load a lab configuration   I may be suposed to 
troubleshoot   or it is a pod loading error?
 
Thanks all !
 
 
 
 
  ___
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