Okay....this is killing me. I cannot figure out why this is failing coming into BR2. I've got a soft phone HQP3 calling a soft phone BR2P4. They can talk just fine. But if BR2P4 RNA's, then the call drops 100% of the time instead of going to CUE. But HQP3 can call the queue hunt pilot, and it gets there about 75% of the time. When the calls drop, the transcoder shows all sessions available.
This happens with both IPC and IPB. I'm starting to wonder if maybe I used a
hardware MTP instead of just having software MTPs if it would make a
difference....but I'm wasting a lot of time chasing this. I've done debugs on
RAS, dial-peers, gatekeeper main 10, gatekeeper call 10, and I cannot see
anything that's different between a successful call and an unsuccessful one. I
wish I had the hardware so I could try it with real phones to take the soft
phone element out of it....but I don't.
For anyone who wants to see them, I'm attaching the configs for both BR2 and
the HQ GK.
Cliff
----- Original Message -----
From: Cliff McGlamry
To: Kumar, Narinder ; ccie_voice@onlinestudylist.com
Sent: Sunday, March 01, 2009 11:05 PM
Subject: Re: [OSL | CCIE_Voice] CUE won't answer calls
Nope....set to two. It appears that it was something involving the WAN. It
cleared up later and hasn't been an issue for a while now. Strange....
----- Original Message -----
From: Kumar, Narinder
To: Cliff McGlamry ; ccie_voice@onlinestudylist.com
Sent: Sunday, March 01, 2009 9:04 PM
Subject: RE: [OSL | CCIE_Voice] CUE won't answer calls
What are you max session for the transcoding ? If max session is one try
max session 2 and see if same problem. May be the resources are no released
completely.
From: ccie_voice-boun...@onlinestudylist.com
[mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Cliff McGlamry
Sent: Monday, 2 March 2009 11:56 AM
To: ccie_voice@onlinestudylist.com
Subject: Re: [OSL | CCIE_Voice] CUE won't answer calls
Ok....finally found that one. The IP Address on the dial-peer was messed
up....but the bizarre part is that nothing was there. I would have expected it
to error out rather than just ringing non stop.
Now I have a different problem. If I call across the way via the GK trunk
to 3600, and the call forwards that will work. If I immediately redial, the
call goes fast busy most of the time...but sometimes it doesn't.
Debugging on the dial peer shows the same results for a successful and
unsuccessful call. Debugging on the DSP farm shows that the transcoder is
successfully engaged when successful, and not engaged at all when it fails.
But the resources are releasing....and should be available.
The results are the same for IP Blue and IP Communicator (which really
threw me off). It's acting like the media stream is failing to connect in some
cases, and sometimes when it does connect, the audio is terrible....making me
wonder if there is an issue within the network in the rack.
Has anyone out there got any ideas? I'm scratching my head at this. In a
real environment there are some things that could be done to troubleshoot this,
but it really seems like it's not a voice issue going on.
Any takers?
Cliff
----- Original Message -----
From: Cliff McGlamry
To: ccie_voice@onlinestudylist.com
Sent: Sunday, March 01, 2009 7:35 PM
Subject: [OSL | CCIE_Voice] CUE won't answer calls
On the rack now (Pod 24). Cue is not answering calls, though the call
history report is showing the call hitting the module.
Config looks correct. I've reset the module, and am in the process of
hard rebooting the router.
Anyone got any ideas? Call control is setting up, and the module is
there...it just won't answer the freaking phone!
Cliff
----------------------------------------------------------------------------
CONFIDENTIALITY - The information contained in this electronic mail message
is confidential and is intended solely for the addressee(s). If you are not an
authorised recipient of this message please contact Getronics Australia
immediately by reply email and destroy/delete this message from your computer.
Any unauthorised form of reproduction of this message, or part thereof, is
strictly prohibited.
DISCLAIMER - Unless specifically indicated otherwise, the views and
opinions expressed in this email are those of the sender and not Getronics
Australia. While we endeavour to protect our network from computer viruses,
Getronics Australia does not warrant that this email or any attachments are
free of viruses or any other defects or errors. It is the duty of the recipient
to virus scan and otherwise test any information contained in this email before
loading onto any computer system.
Pod22-HQ-RTR.CiscoConfig
Description: Binary data
P22-BR2-RTR.CiscoConfig
Description: Binary data
