OBI110, UK PSTN Call Barring

[ianobi]

2. What is timing out such that I must answer the Obi Phone so quickly?

I think this is the key. The problem occurs when the call is coming in from the Line Port to the Phone Port, but does not occur when the call is from the aa to the Phone Port. I wonder if ring patterns are causing DECT phone confusion. At default this setting will give you North American ringing:
Physical Interfaces >LINE Port >RingProfile: A

This gives a four seconds off time between rings, which may confuse a DECT base unit set for UK ringing. I think the aa uses a different ring pattern, but I cannot work out how it chooses it just now - something for me to look in to!

If you change to:
Physical Interfaces >LINE Port >RingProfile: B
This will give you UK ring pattern, which has a maximum two seconds off time.

Both the above assume:
Physical Interfaces >LINE Port >DefaultRing: 1

Ring Patterns are a complicated subject - like most OBi related subjects! DECT phones often use their own ring patterns so they hide what the base unit is actually receiving. Yes, these settings on the Line Port page do set what ring pattern is sent out from the Phone Port when an incoming call is received on the Line Port.

Anyhow - that's idea number 358 for this thread   

[ukuser]

And the nominations for the 2013 Outstanding Support Man of the year go to:
...
ianobi !!! for his amazing tenacity and idea 358.

That's a winner Ian, thanks so much. I need to test it out a bit more ( there is horrific echo on the Obi phone)  but I can delay answering the phone much longer.

Please accept this magnificent trophy in recognition of your efforts on my behalf.

Applause...

Bob

[ianobi]

Too many different technologies involved! A bog standard £10 corded phone would not have cared!

My advice is to put as many settings as possible back to default now we have the problem sorted. There are many different ring patterns, so you might find ones that suit your DECT phone base even better.

I'm assuming that CallerID will now do call barring as required in your first post.

Time for feet up and maybe something a little stronger than a cup of tea   

[ukuser]

A bog standard £10 corded phone would not have cared!
Hmmm! I found a power supply for the old BT corded phone + answering machine and plugged it up. No joy at all there - no dial tone when it was off hook to start with. I rapidly put it away again! I agree with the bit about too many technologies though!

I'm assuming that CallerID will now do call barring as required in your first post.
I think so too; I'm too tired to try anything else today. Will let you know tomorrow.

Sadly, another "featurette" has just surfaced.  If I ring in and don't pick up, the TalkTalk voicemail cuts in for the caller to leave a message. With no Obi box you would then normally hear a discontinuous "Message Waiting" dial tone when you next lift the DECT phone.  With the Obi in circuit this doesn't happen, it's just the ordinary dial tone the Obi generates. I'm sooo looking forward to sorting that one out.   (Cannot find any documentation on Obi Tone Patterns!)

In the absence of strong drink I'm off for a hot bath!

[ianobi]

If I ring in and don't pick up, the TalkTalk voicemail cuts in for the caller to leave a message. With no Obi box you would then normally hear a discontinuous "Message Waiting" dial tone when you next lift the DECT phone.  With the Obi in circuit this doesn't happen

I think that you may be out of luck on that one. There is a simple way to directly listen to Talk Talk dial tone, see here:
http://www.obitalk.com/forum/index.php?topic=4431.msg28946#msg28946

The OBi Phone Port is already set up to send out "stutter dial tone" as it calls it as a "Message Waiting Indication", but the Line Port cannot detect that there is a message waiting, so it's only useful for voip services.

If you are really keen, then you can design your own tones and ring patterns. Lots of info regarding tones etc here:
http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf

Search on this forum for posts by CoalMinerRetired for more in depth posts regarding ring patterns.

[ukuser]

There is a simple way to directly listen to Talk Talk dial tone,
Thanks indeed for that tip - that'll do me!

you can design your own tones and ring patterns
One day perhaps; for now I'm keeping it simple!

Today I've tried setting up call blocking again:
Physical Interfaces->Line Port->RingDelay 0
Physical Interfaces->Line Port->InboundCallRoute: {(12345678912):},{ph}
This didn't work, the DECT rang as normal. CallerId logged correctly.

So changed: Physical Interfaces->Line Port->RingDelay 2500
No difference.

Try routing the "blocked" number to aa
Changed: Physical Interfaces->Line Port->InboundCallRoute: {(12345678912):aa},{ph}
Again, it didn't work. Caller was not routed to AA, DECT rang as normal

Read the admin manual. Oh! Page 177 at the bottom says:
{(14081223330|15103313456):aa},{(1800xx.|1888xx.):},{ph}
means:
Ring both PHONE port and AA for calls coming from 1 408 122 3330 or 1 510 331 3456 ... is that really right?

It's not what I want but does it work? No, TalkTalk voicemail cuts in eventually. Call History shows no attempt to route to aa; End Call occurs 20s after line started ringing (due to TT voicemail).

So: Although CallerId is being logged correctly the  InboundCallRoute processing isn't happening either with aa or nothing as a destination. Why not? CallerId is known before the line starts ringing and I've set 2.5 secs processing time to recognise 11 digits which should be more than enough.

Try :
Physical Interfaces->Line Port->InboundCallRoute: {12345678912:},{ph} (desperation: just removed braces around number)
Physical Interfaces->Line Port->RingDelay 5500
No difference. Why isn't that number being recognised?

Time for tea and review of previous comments about Ring Detection but I know CallerId was being recognised and routed correctly at one stage before faffing with ring tones.

[ianobi]

From the AdminGude:

2) {(14081223330|15103313456):aa},{(1800xx.|1888xx.):},{ph}
It says: Ring both PHONE port and AA for calls coming from 1 408 122 3330 or 1 510 331 3456, block all 800, 888, and anonymous calls, and ring the PHONE port for all other calls

Nearly all wrong! It really says:
Ring AA for calls coming from 1 408 122 3330 or 1 510 331 3456, block all 1800 and 1888 calls, and ring the PHONE port for all other calls including anonymous.

The rest of that section looks right, so it's odd that whoever wrote that got it so wrong. Obihai need to get a good proof reader!

Today I've tried setting up call blocking again:
Physical Interfaces->Line Port->RingDelay 0
Physical Interfaces->Line Port->InboundCallRoute: {(12345678912):},{ph}
This didn't work, the DECT rang as normal. CallerId logged correctly.

Did it log in Call History > Peer Number? If so, then it's odd it made it into the OBi.

For call routing to aa to work, then the CallerID should show in Call History > Peer Number. I have never known an OBi to fail to route CallerID correctly once it has logged it in Peer Number. By the way, you can also observe what is happening by looking in Status > Call Status while the call is actually in progress.

Apologies in advance for this simple question: Is the number in the blocking or routing rule exactly the same as the number observed in Line Port Status > LastCallerInfo? It has been known for a space or a hyphen etc to give odd results. I would stick with this test until you are sure CallerID works correctly:

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.

[QBZappy]

Nearly all wrong! It really says:
Ring AA for calls coming from 1 408 122 3330 or 1 510 331 3456, block all 1800 and 1888 calls, and ring the PHONE port for all other calls including anonymous.

The rest of that section looks right, so it's odd that whoever wrote that got it so wrong. Obihai need to get a good proof reader!

Funny you should bring this up. Help wanted ads are usually a good precursor of things to come. Here is a recent partial transcript of a local news paper advertisement: (tongue in cheek)

S i l l y c o n  Va l l e y  E v e n i n g  P o s t
-H e l p  W a n t e d  S e c t i o n-
Our up coming revised admin guides for the Obi100/200/300/500 series ATAs requires an experienced proof reader. The qualified candidate should have the following skills:
Ability to use a spell checker and always accept first suggested result.
Ability to translate from Chinese to American English. In a bind, British English would do.
Ability to explain with clear examples how to setup the new Open VPN client. New feature in upcoming firmware.
yada, yada, yada, ...

Obihai provides an excellent career opportunity.

Ian, I think you're a shoe in for this. Can anyone else think of anything that can be added to this partial list of requirements?

[ianobi]

QBZ,

Thanks for the vote of confidence! Can I work from home? The 5000 mile commute each way every day might be a bit tiring   

I'm not the first person on this forum to point out a few problems with Obihai documentation!

[ukuser]

Ability to use a spell checker and always accept first suggested result.

So cruel yet so true!

Anyway Ian, back to the plot.

Nearly all wrong!
Thanks for clarifying the situation.

Is the number in the blocking or routing rule exactly the same as the number observed in Line Port Status > LastCallerInfo?
NO. I can't find the embarrassed emoticon either. I'm really feeling stupid now; apologies for wasting your time.

I put in the correct number and all started working as expected, except for a really horrible sequence of events with AA:
Physical Interfaces->Line Port->InboundCallRoute: {(12345678912):aa},{ph} (The correct number this time!)
1 Dial in from mobile.
2 AA answers. (DECT doesn't ring as expected)
3 Hang up mobile (don't respond to AA at all)
4 About 30 to 40 secs later DECT starts ringing all on it's own (and flashes up CallerId of the test mobile).
5 Take DECT off-hook, hear dial tone.
6 Place DECT on-hook again.

Scratch head.
Try again, exactly as before but don't take DECT off hook (at 5).
DECT rings for >20s (so it's the Obi generating the ringing all by itself, not TalkTalk) and eventually stops.
Take DECT off-hook, hear dial tone.

Try again:
This time on dialling in, TalkTalk went straight to voice mail as if the line hadn't cleared down properly.
Unplugged Obi, plugged DECT directly into wall socket. Heard normal dial tone.
Rang in again from mobile; line still engaged - straight to voicemail.
Very worrying! In the end I cleared the line by phoning out directly (no Obi) and hanging up as usual. This cleared the line down correctly.

If any of this sounds vaguely familiar do let me know and apologies again for my stupidity!

[ianobi]

The aa expects an incoming caller to choose option 1,2 or 3. If no option is selected it does just sit there thinking and eventually calls the phone port as a default option. Even if you have cleared down it seems to think it should carry on, so no problem there.

Don't worry about the  factor. We all do it. I won't press you for the details     Some of my mistakes on this forum are very public, but that's ok - it's how we learn.

So I'm guessing you now have a fully functional OBi! Don't forget to change digit maps as suggested in Reply#1, particularly regarding emergency numbers.

Your OBi can do a 101 different things, but you may want a rest from it for now   

[ukuser]

If no option is selected it does just sit there thinking and eventually calls the phone port as a default option. Even if you have cleared down it seems to think it should carry on,
Really? What you say explains my observations so I believe you implicitly; it doesn't seem sensible behaviour to me.

so no problem there.
I was thinking of using AA to filter out automated telepests (those that aren't in the blocked list yet). The big problem is that they will never enter an aa option and if there is no one home to answer the DECT when the AA times out it will leave the TalkTalk line engaged and I won't know about it. (I'm going to check that scenario again as I'm amazed that BT/TalkTalk equipment can allow it to happen.)

Your OBi can do a 101 different things, but you may want a rest from it for now
No chance! I'm currently looking at bending the xml/xsl that the embedded Obi server uses to my own purposes. I'm sure it will all be very easy! 

Many thanks again Ian.

[rizdina]

Does anyone know what parameters I need to change in order to get my OBI 110 to work with the Belgian (Belgacom) phone system?

My OBI 110 works fine receiving calls from the Belgian phone system, but cannot make any outbound calls.  I get a fast busy tone.  I am guessing it has something to do with the outbound dialing digits parameter.  But I am newbie and would appreciate any assistance.

Riz

[ianobi]

Riz – welcome to the forum.

This may take a few posts to sort out. First test is to press "#", which should give you dial tone directly from your Belgacom PSTN line, then dial a number to see if it works.

Have you set up any voip providers and maybe changed your Primary Line? Primary Line is the one you can use without any ** codes.

To look at or change settings:
Select your Obi in Obi Dashboard, then Obi Expert Configuration, then Enter Obi Expert. In each case where you want to change a value, first uncheck both the boxes to the right of that value and leave them unchecked. When you have finished making changes on each page, press submit and wait a few minutes for the Obi to reboot.

The settings we are concerned with at first are:

Physical Interfaces > PHONE Port > PrimaryLine: PSTN Line

Physical Interfaces > LINE Port > DigitMap:
(xxxxxxxS4|1xxxxxxxxxx|xx.)

I have shown the default settings. The digitmap is set up (badly!) for North American number formats. Even so, the "xx." rule should match any number format after a ten second wait and send the number out to PSTN. We can tune this digitmap to suit your needs if you explain exactly what number formats you will be using for your PSTN line.

I'll take a wild guess at something like this:

Physical Interfaces > LINE Port > DigitMap:
(04xxxxxxxx|0[1-3,5-9]xxxxxxx|00xx.|xx.)

We can fine tune it as required. You may wish to direct certain calls via a voip provider etc, which will change the digitmaps.

[rizdina]

Thanks for the reply back.

I went through the configurations and everything was setup correctly with the PSTN being the default line.

I tried the # but that does not get be the Belgacom dial tone right away (it's different sounding than the US dial tone).  Here is what happens...when I press the # key, after a second or so I get the US (OBI) dial tone again.  I have to press the # (and wait) once or twice again to get the Belgacom dial tone.  Once I get the Belgacom dial tone, I can dial out without any problems.

I updated the DigiMap with the one you recommended.  The first time I tried it, it worked, however, every attempt I made after that, got me the fast busy signal from the OBI.  I've gone through and deleted and reinstalled the OBI 110 several times via the ObiTalk web interface but still no luck.

Perhaps the fact that I have to press the # key several times before the PSTN line is selected is somehow tied to automatic dialing.

Riz

[ianobi]

It looks to me that your OBi110 is having trouble seizing the PSTN line. I wonder if you are a long way from the local telephone exchange?

Have a look at Status > PHONE Status  the lower "port status" is the PSTN line. TipRingVoltage should be around -47v. If it is much lower than that try a lower setting here:

Physical Interfaces > Line > Port Settings > TipRingVoltageAdjust

Once all is working normally you should not need to dial "#" for Belgacom dial tone, but it is a useful test for now.

[Shale]

I wonder if that system might be doing a polarity reversal detection and interpreting that as a hang-up. I don't know why there would be a reversal. This setting is the one I am wondering if setting this to no/off would help:

Physical Interfaces->Line Port->DetectPolarityReversal

This is just a guess. If you are hardware oriented, you could also try monitoring the line with an oscilloscope or even an analog voltmeter during the call to see if there is such a reversal.

[rizdina]

I don't know how far I am from the central phone office.  I get VDSL service so I can't be too far. 

But when I checked the parameter you mentioned, it's very low...-52V.  I adjusted the TipRingVoltageAdjust down to 3.1V (and every setting in-between).  The 3.1V setting is the lowest that my screen shows.  Unfortunately, no change.  I can occasionally make an out-bound call, but most of the time it's not going through.

I also tried adjusting the DetectPolarityReversal parameter, but this didn't affect anything. 

Here are the parameters from my PHONE/Line Port Status screen:

PHONE and LINE Port Status
State                On Hook      
LoopCurrent       0 mA      
VBAT                  58 V (11.9 V)      
TipRingVoltage   46 V      
LastCallerInfo   --      


State                  On Hook      
LoopCurrent       0 mA      
TipRingVoltage    -52 V      
LastCallerInfo   --      

Riz

[ianobi]

-52v is a good reading. This is a case where being more negative is good. One wire from the exchange is 0v so if the other is -52v, then that's a 52v difference.

Try increasing this setting to 1000:

Physical Interfaces > Line Port > Line Port > Dial Delay: 1000

This gives one second for the PSTN line to stabilise before any digits are sent out.

If this does not work, then you might try plugging the OBi110 in where the PSTN line first comes into your house, removing all DSL equipment etc, to see if the problem is in your house wiring or the incoming PSTN line.

[rizdina]

Thanks for walking me through this.  It is working now.  In the end the problem turned out to be rather simple to fix.  Looks like there was a problem with the new phone cable that came with my phone.  I replaced it with an older (known good) phone cable and the OBI 110 started working perfectly.  I guess the OBI is sensitive to voltage irregularities caused by the phone line.

Thanks again for the help, without your troubleshooting help, it would have never occurred to me to simply change a phone cable. 

I did put in the new DigiMask sequence you recommended.  The Belgian phone numbers are a bit confusing.  Depending on the "area code" you dial, the subsequent number of digits varies.  I think the fixed lines all have 6 digits following the area code, the mobile numbers have 7 digits and the toll free (0800) numbers have 5 digits.

Is there someplace I can find instructions on how to set up the DigiMask for outbound calls?  I want to make sure the emergency numbers (police, fire, poison control, etc.) go through right away without any delay.

Riz