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 <[email protected]<mailto:[email protected]>> 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:[email protected]] On Behalf Of Norton, Mike Sent: June-30-16 2:26 PM To: [email protected]<mailto:[email protected]>; Ryan Huff <[email protected]<mailto:[email protected]>> 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:[email protected]] On Behalf Of Ryan Huff Sent: June-29-16 5:32 PM To: Wes Sisk (wsisk) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> 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) <[email protected]<mailto:[email protected]>> Sent: Wednesday, June 29, 2016 6:56 PM To: Ryan Huff Cc: Damisch, Kevin; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip <image004.jpg><image003.jpg>_______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
