ewellnitzvoip at gmail
Aug 13, 2012, 9:21 AM
Post #5 of 5
(383 views)
Permalink
|
Very helpful! Thank you!
On Mon, Aug 13, 2012 at 10:49 AM, Ryan LaFountain (rlafount) <
rlafount [at] cisco> wrote:
> Hi Erick,
>
> I looked at a call to 1234 from 5417294006 and it fails due to media
> negotiation failure with the CTI Port:
>
> Cisco001MIVR126.log:8250: 8983156: Aug 10 15:36:21.215 CDT
> %MIVR-SS_TEL-7-UNK:Call.received()
> JTAPICallContact[id=3130,implId=186642/1,state=STATE_RECEIVED_IDX,inbound=true,App
> name=Huron_IT,task=null,session=null,seq
> num=-1,cn=1234,dn=1234,cgn=5417294006,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=1234,route=RP[num=1234],TP=null
>
> Cisco001MIVR126.log:8339: 8983245: Aug 10 15:36:21.778 CDT
> %MIVR-SS_TEL-7-UNK:CallID:3130 MediaId:186642/1 Task:73000008035,
> CallCtlConnFailed, Inbound call, callctl cause:107,
> [919008003:Chi_Phones/(P1-JtapiUser_1) GCID=(1,186642)->ACTIVE]->FAILED
>
> Cause 107 is media negotiation and this is throw when the CTI Port
> attempts to answer the call.
>
> I looked at the following call (an earlier call to the same number from
> the same PSTN number) and it has the same issue:
>
> 8983068: Aug 10 15:36:20.356 CDT %MIVR-SS_TEL-7-UNK:Call.received()
> JTAPICallContact[id=3129,implId=1055625/6,state=STATE_RECEIVED_IDX,inbound=true,App
> name=Huron_IT,task=null,session=null,seq
> num=-1,cn=1234,dn=1234,cgn=5417294006,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=1234,route=RP[num=1234],TP=null
>
> I would fix this and see if the issue persists. Depending on the exact
> version of 7.x you're running, we didn't really handle exceptions like this
> very well. UCCX just assumed it would never hit a condition where the call
> failed for reasons outside of its control. As a result, the call looks to
> continue processing through the script, even though the actual call has
> failed due to the media negotiation.
>
> Hope this helps.
>
> Thank you,
>
> Ryan LaFountain
> Unified Contact Center
> Cisco Services
> Direct: +1 919 392 9898
> Email: rlafount [at] cisco
> Hours: M – F 9:00am – 5:00pm
>
> From: Erick Wellnitz <ewellnitzvoip [at] gmail>
> Date: Monday, August 13, 2012 11:39 AM
> To: Ryan LaFountain <rlafount [at] cisco>
> Cc: cisco-voip <cisco-voip [at] puck>
> Subject: Re: [cisco-voip] strange uccx 7.0 issue
>
> Oops. Here are the files direct from the MIVR directory.
>
> On Sat, Aug 11, 2012 at 7:15 AM, Ryan LaFountain (rlafount) <
> rlafount [at] cisco> wrote:
>
>> Hi Eric,
>>
>> Did you copy the log file content to a text file through RDP or VNC?
>> They are all on a single line and impossible to read.
>>
>> Please copy the actual .log file from the server and send them along.
>> I'll be able to parse them pretty easily and will let you know what I see.
>>
>> Thank you,
>>
>> Ryan LaFountain
>> Unified Contact Center
>> Cisco Services
>> Direct: +1 919 392 9898
>> Email: rlafount [at] cisco
>> Hours: M – F 9:00am – 5:00pm
>>
>> From: Erick Wellnitz <ewellnitzvoip [at] gmail>
>> Date: Friday, August 10, 2012 5:04 PM
>> To: Ryan LaFountain <rlafount [at] cisco>
>> Cc: cisco-voip <cisco-voip [at] puck>
>> Subject: Re: [cisco-voip] strange uccx 7.0 issue
>>
>> Ryan,
>>
>> Attached are three MIVR logs from the timeframe surrounding one of the
>> calls yesterday.
>>
>> Any external call to 1234 exhibits the same behavior. Time of call was
>> 15:44
>>
>> I see a lot of exceptions but I'm really rusty on reading these logs.
>>
>> On Fri, Aug 10, 2012 at 3:32 PM, Ryan LaFountain (rlafount) <
>> rlafount [at] cisco> wrote:
>>
>>> Hi Erick,
>>>
>>> With the symptoms you've described I would look for some type of call
>>> loop. If that isn't it, send along the MIVR traces and the call
>>> information, time, etc. and I'll check 'em out.
>>>
>>> Thank you,
>>>
>>> Ryan LaFountain
>>> Unified Contact Center
>>> Cisco Services
>>> Direct: +1 919 392 9898
>>> Email: rlafount [at] cisco
>>> Hours: M – F 9:00am – 5:00pm
>>>
>>> From: Erick Wellnitz <ewellnitzvoip [at] gmail>
>>> Date: Friday, August 10, 2012 3:59 PM
>>> To: cisco-voip <cisco-voip [at] puck>
>>> Subject: [cisco-voip] strange uccx 7.0 issue
>>>
>>> I have a really strange issue. I have 1 trigger misbehaving across
>>> the WAN.
>>>
>>> The number comes in at the remote site as 1234, should play prompts if
>>> the agents are busy or do it's normal agent selection routine. This works
>>> fine dialing 1234 from a cisco phone. When an outside caller calls
>>> 555-555-1234 the call maxes out our configured maximum sessions in short
>>> order and reserves all of the available agents.
>>>
>>> Anyone seen this kind of behavior before? Any ideas as to what to
>>> look for in the logs/traces?
>>>
>>> It shouldn't be a codec mismatch or I would expect a fast busy.
>>>
>>> Thanks!
>>>
>>>
>>
>
|
