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

Ryan Huff ryanhuff at outlook.com
Thu Jun 30 18:11:23 EDT 2016


*viking

Thanks,

Ryan

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

In this scenario Mike, do you think adjusting the impedance would be a benefit? Possibly trying to get a closer match to what the biking maybe using?

Thanks,

Ryan

On Jun 30, 2016, at 5:28 PM, Norton, Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>> wrote:

Okay so now I’m confused about Kevin’s problem.

Considering the FXO disconnect explanation I gave previously, I think Cisco TAC could be misdiagnosing. The Viking side can’t possibly be hanging up the call because the Viking is the phone company side, and the phone company cannot magically reach into your house and hang up your phone.

I am kind of suspicious that maybe the DTMF causes the Viking to do something that results in the talk battery dropping too low to maintain enough loop current for the call to stay active. Furthering this suspicion, upon Googling the Viking, I see that it supports a bunch of hokey “line sharing” features which doubtlessly have the potential for non-standard behaviour. I also see it has a “talk battery” switch – is that turned on? Correct power supply is being used?

An alternative guess – when you use “connection plar” with H.323/SIP or an Attendant DN with MGCP, the FXO port will answer the call almost immediately and then it will play fake ringback tone to the caller until the IP phone is picked up. Perhaps the Viking is getting confused by being answered so suddenly, or by the fake ringback tone. If you use “connection plar opx” instead (with H.323/SIP; there is no equivalent for MGCP) then the FXO port won’t answer the line until the IP phone is picked up, which is closer behaviour to what the Viking might be expecting.

-mn


From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Norton, Mike
Sent: June-30-16 2:26 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>; Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>>
Subject: Re: [cisco-voip] FXO port to Viking C-1000B door entry controller

I’m not Wes but I’ll take a go at it...

An FXO port is the essentially the same thing as a regular old analog POTS phone. The side of the connection that’s across from an FXO port is essentially the same thing as a phone company.

A phone company cannot magically reach into your house and put your POTS phone on-hook. Only you - the person physically holding the POTS phone - can put it on-hook. *This is true regardless of which side initially started the phonecall.*

A phone company can attempt to influence you into putting your POTS phone on-hook by playing annoying tones into your POTS phone. If you happen to hear these tones and are inclined to comply, you will then voluntarily put your POTS phone on-hook. But the phone company cannot force you to put the phone on-hook.

A Cisco FXO port can be configured to listen for those tones and to voluntarily go on-hook when it happens to hear them. Or to not.

There are other ways that phone companies can attempt to influence you into voluntarily going on-hook. A common method is voltage-reversal. A Cisco FXO port can be, and commonly is, configured to go on-hook when it senses voltage-reversal.

In all cases, the FXO side is the sole decision-maker of going on-hook or not. The phone company side can make suggestions, but there is no guarantee that the FXO side will hear the suggestion, that it will understand the suggestion, or that it will comply.

TLDR: disconnect signalling with analog POTS doesn’t really exist and thus sucks.

-mn


From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Huff
Sent: June-29-16 5:32 PM
To: Wes Sisk (wsisk) <wsisk at cisco.com<mailto:wsisk at cisco.com>>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] FXO port to Viking C-1000B door entry controller


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<mailto:wsisk at cisco.com>>
Sent: Wednesday, June 29, 2016 6:56 PM
To: Ryan Huff
Cc: Damisch, Kevin; cisco-voip at puck.nether.net<mailto: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

_______________________________________________
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
_______________________________________________
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/20160630/af50cea7/attachment.html>


More information about the cisco-voip mailing list