Re: False Answer supervision

rmrojas · ‎06-27-2002

I get false answer supervision (AB=11) coming from an as5300 connected to a dialogic PC switch. The PC switch goes off-hook, receives a wink from the 5300 and then spills the digits. After about the 11th digit the as5300 goes off-hook. This also happens when the as5300's looped back to itself.

*Jun 27 12:12:28: from Trunk(0): (3/13): Tx LOOP_CLOSURE (AB=11)

*Jun 27 12:12:28: from Trunk(0): (2/13): Connect before Tx Tone Complete

Are there any known issues w/ T1 CAS & 12.2(6a) - IP plus & c549 dsp's?

rmrojas · ‎06-28-2002

I heard somewhere that this is inherent on as5300's using e&m-fgb (wink start). Can someone verify?

chaz1 · ‎08-28-2002

It appears to be inherent on all cisco as I also have to problem on 58xx...

Cisco provides a wink to acknowledge that the digits can be sent.. this last for 200 ms then drops to 0000. The second wink comes from the actual termination switch which brings AB high " real answer supervision" This cause me problems with customers who get duration on non completed calls because they see the 1st wink as answer supervision.

rmrojas · ‎08-28-2002

I resolved the issue (at least in my case) after some more testing. The T1 config below exhibits the errored behaviour (delayed answer supervision/false answer supervision):

ds0-group 0 timeslots 1-24 type e&m-fgb

whereas the one below behaves as it should:

ds0-group 0 timeslots 1-24 type e&m-fgb dtmf dnis

i couldn't find any documentation explaining the difference.

chaz1 · ‎08-29-2002

Thats what I have but what I see in a call trace is 3 off hooks and 1 on hook during a normal call.

I get offhook with the origination switch is ready to send the call.

Off hook when the digits are recieved (this is the on that provides the false answer supervision)

off hook with the terminating switch completes the call ( the one that should be providing the answer supervision)

and on hook with the call is completed (normal)

I am not sure what to try next...

rmrojas · ‎08-29-2002

Are you sure that the far end (terminating side) isn't the one providing false-answer? To eliminate this possibility send it to a route that you know has good answer supervision (possibly back to the originating switch, via the 5800) and test. Other than that, i'm not sure what else to try. What does cisco's TAC say?