[cisco-voip] FXO port to Viking C-1000B door entry controller

Wed Jun 29 19:31:35 EDT 2016

Wes,

With the utmost respect to you, I just want to take a moment to understand something, in hopes that I may learn something from you (if you don't mind).

As I understand this; if the FXO port originates the call from the FXO port, then the FXO port DOES have control over the local disconnect. If the FXO port receives the call, it would require the far-end to send the disconnect in order to terminate the connection.

In this scenario, wouldn't the Viking device be sending the call to the FXO port (thereby making the FXO port the receiver)? So my question would be; how would the tone supervisory disconnect on the FXO port initiate a disconnect signal that, if my understanding is correct, can only only be sent from the far-end in this flow scenario?

Again, I am genuinely hoping to learn something here :) - you rock!!

Thanks,

Ryan

________________________________
From: Wes Sisk (wsisk) <wsisk at cisco.com>
Sent: Wednesday, June 29, 2016 6:56 PM
To: Ryan Huff
Cc: Damisch, Kevin; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] FXO port to Viking C-1000B door entry controller

alternatively looks like the FXO port might be configured to to tone disconnect supervision. try disabling that all together and work forward from there. IIRC (dis)connect supervision is implemented in firmware on the card and is only sent back to IOS as an asserted event. Alternatively stated: mapping the cable conditions to the disconnect event is implemented in the module firmware, can be affected by configuration, but is only reported to IOS as a discrete event.  Alternatively stated it’s up to the card firmware to determine 40V or 60V equals “1” but the card only returns “1” to IOS. The 40..60 is still configurable in IOS and is downloaded to (programs/configures) the card on initialization.

-w

On Jun 29, 2016, at 6:30 PM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

On the Cisco FXO port side, try "impedance 600r" under the voice port config.

Essentially, what I believe you are up against, is a sine oscillation disagreement between the FXO port and the Viking.

Thanks,

Ryan

On Jun 29, 2016, at 5:55 PM, Damisch, Kevin <Kevin.Damisch at oneneck.com<mailto:Kevin.Damisch at oneneck.com>> wrote:

Customer has a 4431 router with an FXO card connected to a Viking C-1000B door entry controller.  The normal operation is to press the button on the doorbox, connection plar on the FXO port sends the call to an IP phone, the user answers, IP phone user presses ** which is the code to unlock the door.  The problem is with the mid-call DTMF.  As soon as *any* DTMF digit is pressed mid-call, we get a disconnect on the FXO port.  We don’t even have a chance to press the * key a second time.  The doorboxes connected to this C-1000B controller requires us to use an FXO port, not an FXS port.

Ran the vtsp/vpm debugs.  TAC is saying it is something with the Viking unit causing the disconnect, which is what they confirmed here:

30278353: Jun 14 14:09:32.746: htsp_process_event: [0/1/1, FXOLS_CONNECT, E_DSP_SIG_0100]fxols_normal_battery
30278354: Jun 14 14:09:32.747: htsp_timer_stop2 fxols_disc_confirm

30278358: Jun 14 14:09:32.747: //3699561/56508068916F/VTSP:(0/1/1):-1:1:1/vtsp_process_event:
   [state:S_CONNECT, event:E_TSP_DISCONNECT_IND]

We also did a PCM capture (will they EVER let us have the tool to decode it???), TAC sent me the extracted wav file from the capture and we clearly hear the correct DTMF * key.  We have ringing, two way audio, then at about 6.7 seconds in the screenshot, you can see the DTMF in the waveform below:

<image003.jpg>

We took it one step further and verified the 2 frequencies of * DTMF digit (942 Hz x 1209 Hz) in the audio from the FXO port capture, which looks and sounds good:
<image004.jpg>

It’s a 2-port card and we tried the other port, but get the same thing.  Tried MGCP and H323, same thing.  No, we have not tried another FXO card yet since the call works, we have two-way audio to the Viking doorbox.  It’s just that the mid-call DTMF is causing a disconnect, which appears to be coming from the Viking unit.  From Cisco’s perspective, the call setup is there and we are sending the * DTMF digit out during the call.

So, we call Viking support.  We did some tests with an analog phone/buttset.  Sure enough, it works just fine.  You press the doorbox button, rings the phone, answer it, two-way audio, press **, and the door unlocks and disconnects.

Connect it back up to the FXO port, press the doorbox button, answer it, two-way audio, but as soon as any DTMF digit is pressed, the call disconnects, and the door doesn’t unlock.  The customer had the Viking C-1000A on an Avaya, we did a migration to Cisco UC, and now it doesn’t work.  They got a newer Viking C-1000B unit to see if that would help, but we have the same problem.  TAC says it is Viking’s issue.  Viking says it is something on the Cisco side.

If anyone has setup one of these up on a FXO port and got it to work, please let me know what you ended up doing.  There are quite a few forum posts I found online, but no resolution was found or nobody followed up with what they did to get it to work.

Thanks!
Kevin

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
<image004.jpg><image003.jpg>_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160629/502907db/attachment.html>