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

Fri Jul 1 11:52:31 EDT 2016

Hi Mike -et al,

I was hoping to continue this thread a little longer for a couple reasons;

  *   I've always held the idea this list about educating as much as it is fixing/diagnosing issues
  *   You, Wes and many others clearly have a mastery of these analog topics, so I wanted to capitalize on that for myself, and anyone on this list that would benefit

If anyone would like me to mute, please tell me so and I surely will :) ...... so on to it then.

I get that neither side can physically force the other side to hang-up their equipment -that extends to a lot of things in telephony, so I get that part. When I mentioned one side or the other being able to disconnect the call, I was referring to the ability for either side to hang-up their own equipment, and as you put it, "influence" the other side to hang-up through analog signaling techniques.

I think my misdirection was in my understanding of how supervisory disconnect works. In the original described scenario, the far-end (Viking) calls the local-end (ISR/FXO) and established a connected call. Only after the local-end generates an oscillated sine wave (in this case, a DTMF event), the call is somehow terminated. As I understand supervisory disconnect (as it applies to this context), for the local-end to be hanging up, it would take the far-end generating a tone (or battery reversal/loss of battery) to "influence" the local-end to cause itself to hang-up its own equipment. What wouldn't make sense to me here, is that action being triggered by the local-side generating a DTMF event (unless something were malformed and the tone was being heard incorrectly). I saw your reply where you seemed to suggest that it may not be the supervisory tone either. Is that a correct understanding of supervisory disconnect?

Since the call starts and maintains a connection (and only disconnects when the local-side generates DTMF); my thoughts were that it did have something to do with the "noise" aspect of the call (the alternating current part of the signal as you put it). If the local-end generated too much far-end echo, couldn't that potentially cause the Viking to hang itself up (if the Viking is providing supervisory disconnect)? So if the local-side is at 600Ohm (which Kevin said it was), would changing to 900Ohm (on the local-side) in theory, help reduce far-end echo (assuming that is even in play). I realize you may not be a Viking expert ;) ... I'm just trying to bounce things off someone who clearly has an excellent understanding of this analog topic, in hopes that I may learn something!

Thanks,

Ryan

On 06/30/2016 06:31 PM, Norton, Mike wrote:
Impedance mismatch would cause symptoms with the AC part of the signal (audio). E.g. too loud, too quiet, and particularly notably, echo.

The onhook/offhook signalling is DC and the impedances shouldn’t really matter.

It’s conceivable that impedance mismatch could be making the DTMF echo back to the gateway too strongly. But that shouldn’t actually cause anything to happen unless the gateway is misconfigured to interpret the frequencies of * tone as the telco’s disconnect tone. I suppose it might be worth ensuring the correct cptone country is configured on the FXO port.

I see in the Viking manual that upon being answered, it plays call-waiting tones to indicate which door is calling. I don’t know if Cisco FXO ports have any particular behaviour in response to call-waiting tones. But might be worth looking into.

-mn

From: Ryan Huff [mailto:ryanhuff at outlook.com]
Sent: June-30-16 4:10 PM
To: Norton, Mike <mikenorton at pwsd76.ab.ca><mailto:mikenorton at pwsd76.ab.ca>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>; Damisch, Kevin <Kevin.Damisch at oneneck.com><mailto:Kevin.Damisch at oneneck.com>
Subject: Re: [cisco-voip] FXO port to Viking C-1000B door entry controller

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 <<mailto:mikenorton at pwsd76.ab.ca>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>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 <<mailto:ryanhuff at outlook.com>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>mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Huff
Sent: June-29-16 5:32 PM
To: Wes Sisk (wsisk) <<mailto:wsisk at cisco.com>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) <<mailto:wsisk at cisco.com>wsisk at cisco.com<mailto:wsisk at cisco.com>>
Sent: Wednesday, June 29, 2016 6:56 PM
To: Ryan Huff
Cc: Damisch, Kevin; <mailto:cisco-voip at puck.nether.net> 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 <<mailto:ryanhuff at outlook.com>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 <<mailto:Kevin.Damisch at oneneck.com>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

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