OBI110, UK PSTN Call Barring
ukuser:
I have just installed an OBI 110 - UK (bought new from Amazon).
It checks out fine so far with my Panasonic DECT handsets and British Telecom PSTN line even though most settings for PSTN are for the US, not the UK.
I want to bar (block) inbound landline (Line) calls from a certain number, say 01234567890. I don't want the phone to ring at all in such cases.
So far, I have changed:
Physical Interfaces->Line Port->CallerIDDetectMethod = FSK(V.23)
Physical Interfaces->Line Port->InboundCallRoute from ph to {(01234567890):},{ph}
(I have also disabled OBITalk and ITSP provisioning)
Result: no difference at all. Phone still rings and caller id flashes up in DECT handsets. Note: When this rule is in effect, the call log shows the call but (I think) the Peer Number is sometimes blank (to be verified!). In an case, even if it isn't blank (ie. the unwanted CallerID has been recognised), the call is treated as normal.
Should I be setting something else?
Thanks for any pointers.
Bob
ianobi:
Bob welcome to the forum.
This rule:
Physical Interfaces->Line Port->InboundCallRoute {(01234567890):},{ph}
Should do exactly what you want. It does rely on the OBi110 processing the CallerID. If it has processed it correctly, then it will show in your Call History > Peer Number. The fact that the CallerID has been passed through the OBi110 to your dect phones is no indication that the OBi110 has processed the CallerID.
You could try increasing Physical Interfaces->Line Port-> RingDelay. The default is 4000 (4 seconds). This is to give the OBi110 time to capture and process the the CallerID. I would have thought that 4 seconds is more than enough time. British Telecom uses FSK(V.23), as you have noted, which I believe sends the CallerID before the first ring. (Im in the UK, but I dont use Bristish Telecom, so I cannot do useful tests on this).
You will have noted that all digit maps etc are set for North American formats. This was suggested for sipgate.co.uk and PSTN, so needs a little modification to suit your setup:
http://www.obitalk.com/forum/index.php?topic=5362.msg34764#msg34764
If nothing else, change the references to 911 to 999|112.
ukuser:
Hi Ian,
Thank you for the welcome! Thank you also for the link for setting up the Phone port - very useful, I'll get to it later.
As far as Physical Interfaces->Line Port-> RingDelay is concerned:
I've tried all kinds of delays from 0 to 5500mS - no joy. It has little effect on whether the caller id is recorded in Call History; sometimes it is, sometimes it isn't. Either way, the Obi fails to block the call. Also note: I have a test phone connected to the PSTN line directly just to check when the exchange starts ringing the line; RingDelay doesn't noticeably affect the time that the OBI phone starts ringing, it's always about 3 or 4 secs after the test phone.
I'm sure I saw some setup somewhere to control whether the Line Port should expect polarity reversal. I can't find it now; it's only settable for the Phone port it seems?
Getting confused now!
Thanks Ian,
Bob
Out-takes:
As you say, the first thing that happens with Caller Id is a line polarity reversal. (FYI: The BT PSTN incoming call sequence is (tediously!) described in SIN227 www.sinet.bt.com/227v3p5.pdf.)
There is then a load of sync. stuff and a lump of V23 data sent containing (inter alia) the Caller Id. After that, there is at least 200mS before the line starts ringing.
Ring Delay CallerId is displayed in the log
10mS No
100mS Sometimes
500ms Sometimes
5500ms No
ianobi:
SIN227 is indeed a tedious read :)
I don't think that the OBi Line Port is concerned about the polarity reversal. It can be used to indicate a disconnected condition at the end of a call.
Have a look at Status > PHONE & LINE Status > Line Port Status > LastCallerInfo
If the number shows there, then CallerID is reaching the OBi110. For some reason it is not getting processed. I wonder if other phones etc in parallel with the OBi Line Port are reducing the FSK signal level?
Clutching at straws here, but other users have reported that any of the settings under Line Port > Ring Detection may have some effect on CallerID.
To do any barring or set up trusted callers etc the OBi has to be seeing those CallerIDs in Call History.
ukuser:
Aha! Thanks for those pointers Ian. We are getting closer!
1. I wonder if other phones etc in parallel with the OBi Line Port are reducing the FSK signal level?
Probably not, or at least not enough to cause the problem. I only put the parallel test phone in after barring did not happen correctly. It makes no difference to the OBI behaviour regarding CallerId detection.
2. Status > PHONE & LINE Status > Line Port Status > LastCallerInfo
Shows:
'' 12345678901
(Phone Port Status shows the same).
[EDIT] Looking at the admin guide I guess this is just a different representation of the number; the empty single quotes signify no literals and the space is just for readability. [END EDIT]
Yes indeed, that is <single quote><single quote><space> in front of the number - smells mighty buggy to me! If / when the number appears as "Peer Number" in Status->Call History, it does show correctly though: 12345678901
(Thought: It's just the kind of error that I used to get writing async comms stuff when the Rx clock rate was slightly off or the line wasn't driven hard enough.)
I'm going to:
1. test the repeatability of this situation to see if the extraneous first three characters are always the same.
2. try, literally, '' 12345678901 and or some wildcards in the InboundCallRoute to see if I can gobble them up
3. depending on 1 above, maybe poke around with Line Port > ChannelRxGain although I hate messing with things that are not well documented.
Please jump in with any thoughts!
Bob
Outtakes:
I read things here http://www.macfringe.com/mb/2012/obi110-part-1-block-annoying-phone-callers/ about prefacing InboundCallRoutes with 1? depending on whether the Call History>Peer Number is listed as a 10 or 11 digit number. I conveniently forgot about it as all my numbers are shown as 11 digit and I'm not trying to set a generic block. I think it's a red herring for now.
Navigation
[0] Message Index
[#] Next page