News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Help on Asterisk -> Obi110 #1 -> Obi110 #2 -> pstn setup

Started by freewilly, June 21, 2011, 12:06:37 PM

Previous topic - Next topic

RonR

Make the following change in OBi #1:


Voice Services -> SP2 Service -> X_InboundCallRoute:

{exten>([1-9]x?*@@.):pp},{exten>(<**1:>(Msp1)):sp1},{exten>(<**2:>(Msp2)):sp2},
{exten>(<**8:>(Mli)):li},{exten>(<**9:>(Mpp)):pp},{exten>(Mpli):pli},{exten:},{ph}

Note: Replace pli above (2 places) with your PrimaryLine trunk name (sp1,sp2,li,pp,tg1) as the OBi won't.
        Replace exten above (7 places) with the Peer Number shown on incoming calls to SP2 from Asterisk.


Make the following changes in both OBi #1 and OBi #2:


Voice Services -> OBiTALK Service -> InboundCallRoute:

{(Mcot)>(Mpli):pli},{(Mcot)>(<*1:>(Msp1)):sp1},{(Mcot)>(<*2:>(Msp2)):sp2},{(Mcot)>(<*8:>(Mli)):li},
{(Mcot)>(<*9:>(Mpp)):pp},{(Mcot)>(<**1:>(Msp1)):sp1},{(Mcot)>(<**2:>(Msp2)):sp2},
{(Mcot)>(<**8:>(Mli)):li},{(Mcot)>(<**9:>(Mpp)):pp},{(Mcot):aa},{ph}

Note: Replace pli above (2 places) with your PrimaryLine trunk name (sp1,sp2,li,pp,tg1) as the OBi won't.


User Settings -> User Defined Digit Maps -> User Defined Digit Mapx:

Label : cot
DigitMap : (200123456)

Note: These are trusted caller OBiTALK numbers.
        In OBi #1, use OBi #2's OBiTALK number.  In OBi #2, use OBi #1's OBiTALK number.


In the PHONE Port and Auto Attendant DigitMap's, replace [1-9]x?*(Mpli) with [1-9]x?*@@.

In the PHONE Port and Auto Attendant OutboundCallRoute's, replace {([1-9]x?*(Mpli)):pp} with {([1-9]x?*@@.):pp}

Set OBi #1 Speed Dial #2 to PP(ob200123456) where 200123456 is OBi #2's OBiTALK number.


From CSipSimple, you should be able to dial any number out any trunk of either OBi #1 or OBi #2:

     18005551212  ->  OBi #1 PrimaryLine
**1 18005551212  ->  OBi #1 SP1 Service
**2 18005551212  ->  OBi #1 SP2 Service
**8 18005551212  ->  OBi #1 LINE Port
**9 200123456      ->  OBi #1 OBiTALK Service

    2*18005551212  ->  OBi #2 PrimaryLine
2 **1 18005551212  ->  OBi #2 SP1 Service
2 **2 18005551212  ->  OBi #2 SP2 Service
2 **8 18005551212  ->  OBi #2 LINE Port
2 **9 200123456      ->  OBi #2 OBiTALK Service

freewilly

#21
Finally, it works.

I realize that my major mistake was speed dial #2,
it should be PP(ob200123456) instead of ob200123456

Of course your X_InboundCallRoute setting make it much more secure than I had before.

Quote from: RonR on June 24, 2011, 06:19:15 PM

Set OBi #1 Speed Dial #2 to PP(ob200123456) where 200123456 is OBi #2's OBiTALK number.


Thank you so much.
You are the best.


RonR

freewilly,

This call routing approach also works for ATA's, SIP Phones, and OBiON apps without the need for Asterisk being involved.  Simply load the OBiON app's gateway and Speed Dial slots with the appropriate OBiTALK numbers.    This architecture is expandable to virtually any number of OBi's.

NOTE: Due to a bug in the OBi firmware, you cannot use *78 (Do Not Disturb) to silence incoming calls destined for the OBi's phone, nor can you use *72 (Call Forward All) to forward incoming calls destined for the OBi's phone.  If either of these features is used, all InboundCallRoute processing stops on the SP1, SP2, and LINE Port trunks, breaking this call routing approach as well as any others utilizing these trunks.  Even though correcting the problem is extremely simple, I've been informed by Obihai they will not be fixing this bug.

MichiganTelephone

Quote from: RonR on June 25, 2011, 11:41:58 PMNOTE: Due to a bug in the OBi firmware, you cannot use *78 (Do Not Disturb) to silence incoming calls destined for the OBi's phone, nor can you use *72 (Call Forward All) to forward incoming calls destined for the OBi's phone.  If either of these features is used, all InboundCallRoute processing stops on the SP1, SP2, and LINE Port trunks, breaking this call routing approach as well as any others utilizing these trunks.  Even though correcting the problem is extremely simple, I've been informed by Obihai they will not be fixing this bug.

Did they happen to say why they won't be fixing it?  That seems like a rather serious bug.  I hope they will reconsider.  There are too many companies out there that don't give a damn about fixing bugs in a timely manner, but up to this point Obihai hasn't been one of them, so I find this post rather disturbing.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

RonR

This is a serious bug.  Here's a couple of simple yet very practical examples:

If you set a rule to have calls from another phone (your cell phone, for example) sent to the Auto Attendant so you can make outgoing calls using one of the OBi's resources, using *78 (Do Not Disturb) to silence other incoming calls will cause the call from your cell phone to ring endlessly instead of going to the Auto Attendant.  Using *72 (Call Forward All) to forward other incoming calls (to your cell phone, for example) will cause calls from your cell phone intended for the Auto Attendant to be forwarded right back to your cell phone instead.  Certainly not what is expected or intended.

If you set a rule to block telemarketers or other unwanted callers, using *72 (Call Forward All) to forward other incoming calls (to your cell phone, for example) will cause all those telemarketers and other unwanted callers to be forwarded right to your cell phone.  Certainly not what is expected or intended.

And, of course, more elaborate uses of the InboundCallRoutes such as the call routing capabilities described in this thread and others, using ATA's and SIP Phones with the OBi, etc., all fail completely if *72 or *78 are used.

The only work-around is to manually edit up to FOUR InboundCallRoutes every time you want to silence (and unsilence) the OBi phone or forward (and unforward) OBi phone calls without breaking everything else.  Not very practical.

The problem in the OBi firmware is a simple one and very easy to fix.  The order of checking to see if Do Not Disturb or Call Forward All is enabled and processing the InboundCallRoute is simply reversed.  These operations are being performed in the correct order on the OBiTALK Service trunk (in order to allow OBiON- and OBi-to-OBi calls to work properly with *72 and *78), but are performed in the wrong (reversed) order on the SP1, SP2, and LINE Port trunks.  The solution is terribly obvious.

MichiganTelephone

#25
I agree this is a VERY serious bug, and needs to be fixed.  But you said that you've "been informed by Obihai they will not be fixing this bug."  I can't imagine why they would take that position, which seems totally unreasonable on the face of it.  How did they respond to you, via e-mail?  Did they offer ANY explanation as to why they would not fix it?

This especially appears to have bad implications for those using an OBi110 as a gateway between a PSTN line and an Asterisk server, because if you're describing the situation accurately then setting the phone port to Do Not Disturb or Call Forward All would block incoming calls on the Line port from reaching the Asterisk server.  That is most definitely unacceptable behavior.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

RonR

This problem is easily reproduced.  Simply set one or more rules on the SP1, SP2, or LINE Port InboundCallRoute(s) and then enable Do Not Disturb (*78) or Call Forward All (*72).  You'll find those rules are ignored.

Clearly, features like DND and CFA should only be acted upon for calls actually arriving at the PHONE Port.  That's the way the OBiTALK Service trunk behaves and all the other trunks should behave identically.  There's no reason to treat SP1/SP2/LI differently.

MichiganTelephone

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

ShermanObi

Hi everyone,

Over the past several weeks, we have discussed and thought about the issue described in this post.  We do see that the current implementation could be enhanced -- and of course it will be enhanced for various other applications.  Understanding the DND & Call Fwd All limitation, the functionality in the current implementation should allow the OBi to perform well for this application.  But as I said, we are considering this concern about the current implementation and are open to enhancing the current functionality.

Thank you for your support!

RonR

Sherman,

You continue to describe this problem as a need for some new functionality, capability, or enhancement.  That's simply not the case.  Absolutely nothing new is needed.  Absolutely nothing needs to be enhanced.


The logic on the SP1, SP2, and LINE Port trunks is currently:


Do Not Disturb enabled?     Yes -> Ignore Call / End of Processing

|
V

Call Forward All Enabled?     Yes -> Forward Call / End of Processing

|
V

Process InboundCallRoute

|
V

Ring OBi Phone



If Do Not Disturb or Call Forward All is enabled, the InboundCallRoute doesn't get processed.

All that's needed to fix this problem is a trivial change to the order in which these operations are performed:


Process InboundCallRoute

|
V

Do Not Disturb enabled?     Yes -> Ignore Call / End of Processing

|
V

Call Forward All Enabled?     Yes -> Forward Call / End of Processing

|
V

Ring OBi Phone


The OBiTALK trunk performs these operations in the correct (second) order and consequently has no problem.  Simply follow the same order on the SP1, SP2, and LINE Port trunks and the problem is solved.  The change can't possibly take more than a few minutes to accomplish.

Why is there so much reluctance to correct this problem?  Currently, numerous tasks that people are accomplishing with the OBi cease to function if Do Not Disturb or Call Forward All is enabled.  Moving the placement of a single operation so that it matches the OBiTALK order allows all these tasks to continue working instead of being terminated.  It's such an obviously devastating problem that's so simple to fix, it's hard to understand why we're even having this discussion.

ChrisWesley