OBI110, UK PSTN Call Barring
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:
Quote
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!
Quote
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:
Quote from: ianobi on May 07, 2013, 09:33:07 am
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 :D
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!
Navigation
[0] Message Index
[#] Next page
[*] Previous page