News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obi110 for analog telephone line call recording

Started by DM-VL, January 04, 2012, 02:13:38 AM

Previous topic - Next topic

DM-VL

We wish to use the Obi110 for high impedance passive call recording.  We wish to connect the 110 in parallel to our analog telephone line and send SIP call control and RTP packets to our central data center.

Is this possible ?

Thanks

Dave

DM-VL

If passive packetization of the call is not possible, can we command the 110 to automatically set up a 3 way call using sp1 or sp2 (which would be configured to be our proxy servers) whenever it detects a call connected on the line port.

Thanks

Dave

Stewart

Though the OBi hardware can capture audio in a high-impedance bridge mode (that's needed for caller ID), there is AFAIK no way to get the firmware to send on-hook audio by RTP.

If you have a device, this might be worth a try: Put resistors in the tip and ring lines (I'd start with ~2 kohms).  Have a script that monitors the loop voltage.  When it drops, send a call, routed directly to the LINE port.  Look for an increase in loop current to know when the external equipment has hung up, then drop the call.

You'll need to tweak the "in-use" settings, disable the disconnect detection, crank the input gain up and the output gain down, and probably some stuff I forgot.

You should be able to test by calling in from a softphone, IP phone, or another ATA.

Good luck.

DM-VL

Thank you very much for your reply.

Can't we just set the inboundcallroute and outboundcallroute to automatically bridge calls.  For example, the inboundcallroute on the line port could be to route the call to the phone and bridge the call with an outbound call using one of the trunks to our data center ?

Similarly the outbound call route can be programmed to bridge the outbound calls.

Thanks again.

Dave

Stewart

#4
The OBi uses "bridging" to mean connecting an inbound call to an outbound one; that's not the same as conferencing.  For example, one might set the InboundCallRoute for the LINE port to ring the PHONE port and also (via a SIP provider) ring your mobile phone.  But, when you answer from either the phone port or the mobile, the other outbound leg gets cancelled; no conference is created.

AFAIK, there is no way to create a conference on the OBi, other than by sending hook flashes on the PHONE port.

You could, of course, configure the LINE port to bridge to the PBX at your data center, which could be programmed to send an outbound call back to the OBi, which would ring the PHONE port.  The PBX could then record the call.  However, this would add latency and may reduce reliability.  If there is an ocean between the locations, I wouldn't recommend this approach.

DM-VL

Hi Stewart

Thanks again.

When you suggest "Have a script that monitors the loop voltage.  When it drops, send a call, routed directly to the LINE port."

do you mean an external script outside of Obi110 that would monitor the voltage and route the call to the line port ?  I could not find in the manual any way of telling the Obi to monitor the voltage and route a call.

Besides the impedance aspect, if I connect the line port in parallel to the analog line which goes externally to a telephone instrument and set the inbound call route to bridge an incoming call with a call to our data center (via a sip provider), I should be able to record the call. 

While the above may work for inbound calls, is there any way for the line port to detect an offhook condition and bridge this with a similar call to our data center ?

The other option you suggested is also interesting.  To route all incoming calls on the line port to our data center which then calls back and the call is routed to the phone port.  Could there be an issue with outbound calls made on the phone port ?  While we could route it through our data center, we would need to know the digits dialed by the user on the phone port to call out.

Thanks

Dave

JimV

The line parameters provide us to specify the line voltage and loop current to detect line in use.  However besides displaying this in the line status, is there any way we can use this in call routing.

We would like the Obi110 to bridge a call whenever it detects the line port in use.

Thanks



RonR

Quote from: JimV on January 05, 2012, 10:45:30 PM
We would like the Obi110 to bridge a call whenever it detects the line port in use.

Please explain what you're trying to do in more detail.

JimV

We would like to bridge a call for recording whenever the line is in use.

An analog land line would be split and connected to the line port of the Obi110 device.  We would like the Obi110 to bridge a call using either SP1 or SP2 or PP1 whenever it detects the line port in use, which could be based on monitoring the line voltage.  Whenever the phone connected in parallel is taken off hook, the Obi110 should dial out a call.

Jim

RonR

JimV,

From what you've described, I gather you want the OBi to sense when a phone connected to the LINE Port goes off-hook and initiate a call through another trunk, bridging it to the LINE Port when the called party answers, allowing eavesdropping on the LINE Port call.

I can't think of any way to accomplish this without custom firmware in the OBi.

JimV

We've done some experiments, and have this to report and questions to ask:

1) By installing resistors on the tip and ring we've been able to make a phone connected in parallel (Obi110 line port and phone are each connected to separate sides of a line splitter) continue to ring, even though the Obi picks up (call goes to softphone from Obi).
2) BUT, when the phone connected in parallel with the Obi goes offhook, the Obi appears to go onhook and the connection to the softphone ends. This only happens when the resistors are in place.  Without the resistors, I can have the parallel phone and Obi both connected with no problem.
3) Looking at the Phone & Line status page, it appears that the loop current drops to zero when the parallel line goes off hook up, but that might just be because the Obi Line port goes on-hook.
4) Is there any way to force the Obi to stay off-hook even though there's a big increase in resistance on the line port (from the resistors) and a current draw from the parallel phone going off-hook?

For background: We're trying to create a configuration that enables remote monitoring/recording of a phone line using the Obi, and we're following two paths to do that.  The one discussed above uses a parallel connection (Obi is installed in parallel with user phones - see attachment).  We're also working on another option in serial, but I'll do that in a separate post.

Thanks.

RonR

Quote from: JimV on January 11, 2012, 11:32:48 AM
4) Is there any way to force the Obi to stay off-hook even though there's a big increase in resistance on the line port (from the resistors) and a current draw from the parallel phone going off-hook?

Try:

Physical Interfaces -> PHONE Port -> EnableLINEPortBargeIn : (checked)

lk96

may be I misunderstand the usage model but it seems to me that it would be cleaner if
you connect the analog handset to the obi110 phone port, and use the obi as a voice
packetizing engine: so instead of trying to intercept a call on the analog copper wires,
you tap the ethernet side. You can do that with an ethernet switch
that support port mirroring, or do some crude ARP spoofing (not recommended though) or
use an old fashion L2 switch that does true broadcasting to all ports or use an external
Linux machine to intercept Ethernet traffic and do the mirroring for you.
That will allow not only the RTP pkts to be captured but
also a lot of SIP state info that will include some caller id info.

I'm not sure if an external media loopback method is supported within obi. If not a crude emulation
of that would be:

1. use the SP1 and SP2 accounts to forward PSTN calls out and then right back in
2. use an ip pbx capable freeware (Freeswitch, Yate, Asterisk or similar) to do the loopback trick for you.
3. buy a 2nd Obi and have incoming calls on PSTN on the 1st Obi "bridge" calls to the 2nd obi and 2nd obi loop traffic back to first one. Inbound traffic from Obi2 should be routed to the phone port, etc etc.
You'll need to tweak some of the incoming call rules to accomplish desired connectivity
and avoid a loop but looks a pretty clean option to me. Based on the little I've learned recently,
setting such rules is pretty straightforward.

Of the 3 options I like #3 quite a bit *but* I don't know if voice will encounter additional latency
in case it bounces back to the public IP network and then back into your local enterprise network.
If that is a problem you have to look deeper into option #2 above because you'll have more
control over the data path taken by voice packets.

Once you capture the RTP pkts you'll need to feed them through some parsing SW to extract
the actual audio but that's feasible.

Obviously the above are not detailed and final instructions but some direction to think about.

PS: the pdf file attached states that the picture is "confidential and proprietary" information
from your company. I think it's not a good idea to post it as-is at public forums even it is
well meant and to help people in this forum provide you with requested support.

Stewart

Quote from: JimV on January 11, 2012, 11:32:48 AMIs there any way to force the Obi to stay off-hook even though there's a big increase in resistance on the line port (from the resistors) and a current draw from the parallel phone going off-hook?
Try turning off Detect CPC.  If no luck, setting LineInUseCurrentThreshold to e.g. 1 may help.