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. (I'm in the UK, but I don't 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.

[ianobi]

2. Status > PHONE & LINE Status > Line Port Status > LastCallerInfo
Shows:
'' 12345678901
(Phone Port Status shows the same).

I can save you some time here! The format for LastCallerInfo is:
'CallerName' CallerID

'' (that is two ') simply indicates that no CallerName was received. The space between '' and CallerID is just a separator. So that looks normal - I don't think it's even possible to get CallerName from British Telecom.

Often if a CallerID is received via voip with no CallerName, OBi will use CallerID as CallerName for the Phone Port LastCallerInfo and will show as:
'012345678912' 012345678912
For some reason it shows '' 012345678912 when received via PSTN.

Just a shot in the dark, but it might be worth trying a RingDelay of around 2500. I know CallerID is delivered much faster than that, but it may take the OBi a finite time to process it. After that it's time to start poking around with all them other pesky settings!

Edit - I see you have already worked most of this out!

[ukuser]

Thanks for that LastCallerInfo info. Ian, I was so disappointed that it wan't a bug!

This is getting frustrating! The worst thing is the results of my meddling are not consistent.

I have set the following:
Physical Interfaces->Line Port->InboundCallRoute {(01234567890):},{ph}
Physical Interfaces->Line Port->RingDelay 2500
Physical Interfaces->Line Port->CallForwardOnNoAnswerRingCount 5
Physical Interfaces->Line Port->AnonymousCallBlockEnable Yes
Physical Interfaces->Line Port->DetectPolarityReversal No (makes no difference if set to Yes)
Physical Interfaces->Line Port->ACImpedance 370+620//310nF (was something else, makes no difference anyway!)
Physical Interfaces->Line Port->FSK(V.23) was Bell 202

Everything else is set to default.

(1) When I ring in from my mobile the very first time after making changes and rebooting the OBI, the call is handled correctly. The line appears to go dead as far as the mobile is concerned, the DECT attached to the OBI never rings and I can see from the OBI leds that it hasn't routed the Line to the Phone. The call is logged correctly (Peer Number correct). LastCallerInfo correct for both Phone and Line ports. Lovely!

(2) Then I ring in again. This time the OBI routes the call to the DECT. There is no number in the Call history. LastCallerInfo is correct for the Line Port but not the Phone port. Horrible!

(3) I try again with the same result (but this time LastCallerInfo is correct for both ports and is logged in Call History).

(4) Reboot the OBI. Having made no changes to above configuration.
Ring in again. Result is as (3) above; ie. no good.

I have had this behaviour many times now; that is, if I set parameters, reboot and ring in it seems to work the first time but never subsequently.  If I just reboot without having updated any parameters first it doesn't work.

At any rate it seems the CallerId is getting recognised all the time (so the h/w Line parameters must be pretty close) but it's just not being handled correctly under certain conditions.

Confused and tired! All suggestions and moral support appreciated!

PS: I cannot find anyone in the UK who has successfully managed PSTN call barring which I find strange as the OBI has been out for a couple of years now.

[ianobi]

Are you sure that provisioning has been disabled? Are the changes you are making to settings "sticking"?

(3) I try again with the same result (but this time LastCallerInfo is correct for both ports and is logged in Call History).

I have never seen this before. If the number is in Call History, then any rules pertaining to that number have always worked.

I cannot find anyone in the UK who has successfully managed PSTN call barring which I find strange as the OBI has been out for a couple of years now.

I have used many devices to connect to the Line Port and CallerID and associated rules have always worked. I admit I have never connected to British Telecom, but they do nothing unusual as far as I know. I'm sure we have used call barring for someone in the UK.

This really has worked for some people:

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.

Two last resorts are put in a support ticket to Obihai or see if Amazon will swap it. Although I'm not convinced it's faulty.

It's Friday evening, so I'm heading towards the pub soon. This voip stuff can drive you to drink! Hoping to hear better news from you soon   

[ukuser]

Are you sure that provisioning has been disabled? Are the changes you are making to settings "sticking"?
Yes, ITSP and OBITalk provisioning are both disabled. After I reboot I always refresh and check my settings are as expected.

I'm sure we have used call barring for someone in the UK.
Well, that's encouraging!

Although I'm not convinced it's faulty.
Neither am I, strangely! Most other things I've played with work fine!

Just for fun I set:
Physical Interfaces->Line Port->InboundCallRoute to nothing, blank, not a sausage. No routing from Line to Phone at all.

Guess what?  Yes, the OBI still routes the Line port to the Phone!
There's something going on there I just don't understand as I thought the only way for the Line to route to the Phone port was if "ph" appeared as a target somewhere in the InboundCallRoute string. (I cannot see any other default Line routing  settings.)

so I'm heading towards the pub soon
Enjoy!

Thanks for all your help. Am going to play with setting AA as the target rather than ph now.

[ianobi]

I think I may have added to the confusion in this thread. If call barring is working correctly, then CallerID will not show in Call History. This is because the call has not been allowed into the OBi so cannot be recorded.

I have now done a factory reset on my brain, so let's look at some cases with incoming calls from 01234567890. This is how it should work:

Physical Interfaces->Line Port->InboundCallRoute: ph
Shows in Call History > Peer Number? Yes.
Shows in Line Port > LastCallerInfo? Yes
Caller gets? Ringing tone.
OBi phone rings? Yes.

Physical Interfaces->Line Port->InboundCallRoute: {01234567890:},{ph}
Shows in Call History > Peer Number? No.
Shows in Line Port > LastCallerInfo? Yes
Caller gets? Ringing tone.
OBi phone rings? No.

Physical Interfaces->Line Port->InboundCallRoute: {01234567890:aa},{ph}
Shows in Call History > Peer Number? Yes.
Shows in Line Port > LastCallerInfo? Yes
Caller gets? Ringing tone followed by auto attendant.
OBi phone rings? Only if caller chooses Option 1 from auto attendant menu.


Notes:

The third case above may be the most useful for testing CallerID and showing that it is being used correctly.

In this case, {01234567890:},{ph}, you cannot stop the British Telecom exchange from sending ringing to your OBi110. The rule merely tells the OBi to direct the call to nowhere, so the OBi phone does not ring.

Be careful of LastCallerInfo. The last number it has recorded stays there until it records another number or the OBi is rebooted, in which case it goes back to blank.

{01234567890:} is ok for one number, extra parenthesis only needed if you want more than one number in the list – they do no harm if only one number.

If you delete ph and leave the Line Port InboundCallRoute blank your OBi110 has no instruction so it rings the phone as a default strategy. To prevent all calls received from ringing the phone this rule is needed:
Physical Interfaces->Line Port->InboundCallRoute: {}


I suggest the way forward may be to do a factory reset on your OBi. Then only change:
Physical Interfaces->Line Port->CallerIDDetectMethod = FSK(V.23)
Then start testing again.

Apologies if I was not clear before. Human Brains and OBi110s both need rebooting from time to time   

[ukuser]

Wow, thanks for the clarification Ian and on a Bank Holiday too!

Factory reset - Done. Call history etc. cleared.
Set auto provisioning to disabled for ObiTALK and ITSP
Set Physical Interfaces->Line Port->CallerIDDetectMethod = FSK(V.23)
Nothing else changed at all. All routing and DigitMaps left at default everywhere.
Rebooted.


Physical Interfaces->Line Port->InboundCallRoute: ph Tick 
Ring in:
Shows in Call History > Peer Number? Yes. Tick
Shows in Line Port > LastCallerInfo? Yes Tick
Caller gets? Ringing tone.  Only once then cuts off. (Just as if call was blocked!)
OBi phone rings? Yes. but only once then cuts off.

Ring in again to check repeatability:
Shows in Call History > Peer Number? Yes. Tick
Shows in Line Port > LastCallerInfo? Yes Tick
Caller gets? Ringing tone.  Only once then cuts off.
OBi phone rings? Yes. Once then cuts off.
Noticed: Telephone line LED on Obi extinguished for a few minutes after this test.

Ring in again to check LED.
Same results again. LED extinguishes for 2mins approx.  (but I can dial out from DECT nonetheless - LED flashes as soon as I take the DECT off hook).

This is no good as I'm using my mobile to ring in and it is effectively blocked when it shouldn't be!
Will now try from partner's mobile:
Same result: All calls are now terminating from any number it seems. This did not happen before!
Clutch at straws.
Set Physical Interfaces->Line Port->ACImpedance 370+620//310nF
No effect
Change RingDelay from 4000 to 2500
No effect.
Stumped! but press on rewardless.

Set:
Physical Interfaces->Line Port->InboundCallRoute: {01234567890:},{ph}
Ring in on either blocked or unblocked phone:
No difference in behaviour. Caller is cut off after one ring; DECT phone rings once then stops.

This is crazy!  I can't cope with inconsistent behaviour like this. I'm going to take a break and try and get back to where I was yesterday when I could at least receive calls correctly.

Will post again later! Meantime, thanks again Ian.

[ianobi]

FYI - the ultimate hardware reset is the paper clip method:


1. With a paper clip (or similar) depress the reset pin located on the back of the OBi.
2. While keeping the reset pin depressed, plug-in the power cord.
First, the Power LED will turn red, then become solid green.
Keep depressing the reset pin while this is occurring.
3. After 10 seconds, the Power LED will start to flash green (slowly).
You may now release the reset pin.
4. Within 5 seconds, the Power led will start to flash green rapidly for about 3 seconds.
5. Next the Power LED will change to red briefly indicating the OBi is now rebooting.
The factory reset is now complete.

[ukuser]

Day 3!

FYI - the ultimate hardware reset is the paper clip method:

Thanks Ian, that's just what I tried. I even tried setting things up through the website rather than locally. (Now that IS clutching at straws!)

Sadly, nothing made any difference.

With a default setup (no blocking at all but FSK V.23 line protocol selected), incoming calls are cut off immediately, the Obi phone rings once and the Phone LED goes out for a minute or two.

I've sent an email to support & am getting ready to hunker down for the long haul!

Keep those tips/suggestions coming Ian, they're very welcome.

En passant:
1) Page 38 of the admin guide (LINE (FXO) Port Configuration Options): Codes ***090 and ***092 work as advertised.
   Codes ***091 (FXO State) says Invalid option - mighty strange?!

2) I noticed that there are no default AA messages set up and page 38 of the admin guide (Customized AA Prompt Recording Options) isn't helpful as there is a code missing which you think should be 1000 but isn't.

Bob

[ianobi]

With a default setup (no blocking at all but FSK V.23 line protocol selected), incoming calls are cut off immediately, the Obi phone rings once and the Phone LED goes out for a minute or two.

I wonder if your OBi is wrongly seeing some sort of "disconnect signal". Try unchecking both of these in your Line Port settings:
DetectPolarityReversal
DetectDisconnectTone

1) Page 38 of the admin guide (LINE (FXO) Port Configuration Options): Codes ***090 and ***092 work as advertised.
   Codes ***091 (FXO State) says Invalid option - mighty strange?!

I have never tried that before! I get exactly the same as you, so it's weird but maybe not significant.

2) I noticed that there are no default AA messages set up and page 38 of the admin guide (Customized AA Prompt Recording Options) isn't helpful as there is a code missing which you think should be 1000 but isn't.

The default messages do not show in the section Voice Services > Auto Attendant > Auto Attendant 1 Prompts. I think they only show if you set up non-default messages. What happens when you dial "**0" ? You should get "Welcome to OBi Attendant" followed by options 1, 2 and 3.

[ukuser]

Try unchecking both of these in your Line Port settings:
DetectPolarityReversal
DetectDisconnectTone

1st try: Success! Obi phone range twice, I answered it and got connected to my mobile.
Call History shows PHONE1 "Call Connected" then "End Call"

2nd try: Failure. Caller hears line disconnecting immediately. Obi Phone rang once.
Call History shows LINE1 "End Call" occurring 4 secs after "Ringing".

So you're right; unless I answer very quickly a line disconnect is being erroneously detected.
Maybe I need to meddle with the other PSTN Disconnect Detection parameters.

***091 - I get exactly the same as you,
Good to know, thanks.

Auto Attendant 1 Prompts. I think they only show if you set up non-default messages.
OK, thanks.

What happens when you dial "**0" ? You should get "Welcome to OBi Attendant" followed by options 1, 2 and 3.
OH Right, I see now. Yes, that happens. Forgive my lack of cognitive functioning!

Well, many thanks again Ian. I'm going to revisit the BT SINs to try and figure out where that line disconnect is coming from (as I write my oscilloscopes are begging to be used but I'm ignoring them for the moment).

Bob

[ianobi]

One more thing to eliminate is that the Phone Port may be giving a false answer and then dropping out. The four seconds before "End Call" is the same as your RingDelay, if still at default. Therefore, it is four seconds before the OBi tries to ring the Phone Port.

You could try this:
Physical Interfaces->Line Port->InboundCallRoute: aa

This should divert all incoming calls to the auto attendant after the RingDelay. This would eliminate any Phone Port problems if calls still fail.

[ukuser]

Physical Interfaces->Line Port->InboundCallRoute: aa

That works a treat! Absolutely reliable. Call history shows AA transferring to PHONE1 (which keeps ringing until I answer it as you'd expect) and then "Call Connected".

(Note: I terminated the call from the test mobile. The Obi phone did not revert to dial tone however, just silence until I hung up. Call History shows the call terminating when I hung up the Obi phone. Line disconnect (ie. LINE "End Call") was not registered when I hung up the mobile.)

So I'm now thinking that a Line Disconnection is probably NOT happening?!

It seems there is a very short period of time to answer the call which the AA achieves easily but not the Obi Phone. Ring delay is currently set at 0.  (CallerId seems to work OK at this setting.)

Obviously, with (ph rather than aa) I want the Obi phone to keep ringing for ages (not just once or twice if I'm lucky) until the BT/TalkTalk exchange answering machine kicks in (if it ever does, I've no idea when the exchange would consider the call "answered" now).

Where to look next?  All Phone settings are at default currently.

We're making progress Ian! Many thanks.

[ianobi]

I wonder if there is something odd about your DECT base station. Is it possible to swap it for a corded phone for testing?

If there is a small "glitch" as the ringing is sent to the phone then it might be seen as a "HookFlash" - a way of putting calls on hold etc. Try increasing:
Physical Interfaces > PHONE Port > Timers > HookFlashTimeMin to say 150.

I don't think it will make much difference, but the following would be more standard for UK phones:
Physical Interfaces > PHONE Port > Port Settings > Impedance: 320+(1050||230nF)
Physical Interfaces > PHONE Port > Port Settings > CallerIDMethod: FSK(V.23)

Using:
Physical Interfaces->Line Port->InboundCallRoute: aa
does CallerID work reliably?

Hope we solve this soon - there's not much more left to try   

[ukuser]

I wonder if there is something odd about your DECT base station. Is it possible to swap it for a corded phone for testing?
You read my mind! It's a newish Panasonic DECT which I get the feeling that people have fewest problems with. First thing this a.m. I got an old corded phone out but I have yet to find its power brick (big shock!). Will look again if necessary.

Try increasing:
Physical Interfaces > PHONE Port > Timers > HookFlashTimeMin to say 150.
Will give it a go, but see later.

Physical Interfaces > PHONE Port > Port Settings > Impedance: 320+(1050||230nF)
Physical Interfaces > PHONE Port > Port Settings > CallerIDMethod: FSK(V.23)
That's what they're set to currently, along with:
Physical Interfaces > PHONE Port > Port Settings > CallerIDTrigger After Polarity Reversal
* With these PHONE settings (and LINE InboundCallRoute ph) I now get:
Perfect operation but only if I answer the Obi phone absolutely immediately it rings (same thing as having AA do the answering I guess).  If I leave it a second longer then call history shows LINE1 End Call about 7 or 8 secs after "Ringing". This at least is repeatable! That 7 or 8 secs is a mystery as RingDelay is set to 0! It is about right as the Phone LED starts flashing about 7 secs after the Line LED. (Where does the delay come from? It eats into the (unconfigurable) 21 secs that TalkTalk give you before their voicemail cuts in).

Physical Interfaces->Line Port->InboundCallRoute: aa
does CallerID work reliably?
Yes. CallerID seems very reliable.

Note: Physical Interfaces >PHONE Port > Port Settings are important it seems. With them set as above, when the mobile hangs up the Obi phone returns to a dial tone. Nice!

Now trying Physical Interfaces > PHONE Port > Timers > HookFlashTimeMin to say 150

[ukuser]

Well, no luck with Physical Interfaces > PHONE Port > Timers > HookFlashTimeMin 150

Where I am now:

When I call in to the OBI:

LINE LED flashes.
There is then a 5 or 6 second (guess)delay before the PHONE LED starts flashing. (Don't know where this delay comes from)
There is then a small (1s) delay before the Obi phone starts ringing (normal DECT delay).
If I answer immediately, the call is connected perfectly.
If I delay answering, the phone might ring again but can only hear dial tone. Call history then shows LINE "End Call" approx 7 to 9s after "Ringing"

Physical Interfaces >LINE Port > RingDelay is 0
Physical Interfaces >LINE Port > InboundCallRoute is ph
Physical Interfaces >LINE Port > DigitMap is default (xxxxxxxS4|1xxxxxxxxxx|xx.)

Physical Interfaces > PHONE Port > Port Settings > Impedance: 320+(1050||230nF)
Physical Interfaces > PHONE Port > Port Settings > CallerIDMethod: FSK(V.23)
Physical Interfaces > PHONE Port > Port Settings > CallerIDTrigger After Polarity Reversal
Physical Interfaces > PHONE Port > Timers > HookFlashTimeMin 150

So the questions are:
1. What is delaying the routing of Line port to the Phone port for so long? Maybe it's just a bit slow and this is the normal operation - unlikely as it manages to route to the AA instantly. (Thinks: Digitmaps involved somewhere? They're all at default US settings now.)
2. What is timing out such that I must answer the Obi Phone so quickly? Is there a state where, if the phone is not answered quickly something on the exchange line (eg: Polarity Reversal or some such) makes the Obi think the caller has hung up.

Time before TalkTalk voicemail cuts in = 21s approx.
Time for Obi to start ringing DECT about (9 + 1) =10 secs (max)
So should get at least 10 secs of dect ringing worst case.

Mustn't forget: When call fails, Call History does log the call "Inbound" to the phone and logs correct CallerId. It has tried to route Line to Phone but it just doesn't give a long enough time for DECT phone to pick up.

Time for a cup of tea and a think!

Many thanks Ian.