Obi110 for analog telephone line call recording
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 am
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 turning off Detect CPC. If no luck, setting LineInUseCurrentThreshold to e.g. 1 may help.
Navigation
[0] Message Index
[*] Previous page