News:

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

Main Menu

Shoot the attendant.

Started by Ostracus, April 23, 2012, 12:43:00 PM

Previous topic - Next topic

Ostracus

Quick question, how to get both an Obi110 and an Obi202 to both ring when a PSTN call comes in and either one can pick up WITHOUT the attendant being involved?

RonR

OBi110

Physical Interfaces -> LINE Port -> InboundCallRoute : {ph,pp(ob200123456)}

where 200123456 is the OBiTALK number of the OBi202.

Ostracus

Thanks RonR for the quick reply and I show in the Obi110 history that it's forking both to the Obitalk network AND the attached phone. But on the Obi202 history shows the forked call coming in from Obitalk and then going to AA1, which is the attendant, which I don't want. Apparently Obitalk calls head straight for the attendant which might be a security feature to prevent abuse.

RonR

Ostracus,

I'm guessing that you added your OBi202 to the same OBiTALK Web Portal account that contains your OBi110.  By doing so, both Endpoints are automatically added to that account's Circle of Trust, even though they're not displayed as such in the Dashboard.  The OBiTALK Web Portal assumes that all Endpoints in the same account want calls between them routed to the Auto Attendant and there's no way to specify otherwise.

If you wish to continue using the OBiTALK Web Portal, you have two options to stop the calls from being sent to the Auto Attendant:

1. Remove the OBi202 from the OBiTALK Web Portal account containing your OBi110 and place it in a separate OBiTALK Web Portal account.

2. Using OBi Expert, manually remove the applicable OBiTALK numbers from the following OBiTALK Service InboundCallRoute rules:

Voice Services -> OBiTALK Service -> InboundCallRoute:

...,{(290123456|200123456|...)>(xx.):pli},{(290123456|200123456|...):aa},...

For additional insight, see Using Trusted Callers and Circle of Trust.

PhASE

Quote from: RonR on April 23, 2012, 12:47:43 PM
OBi110
Physical Interfaces -> LINE Port -> InboundCallRoute : {ph,pp(ob200123456)}
where 200123456 is the OBiTALK number of the OBi202.


RonR :
what is the difference between your suggestion & this :

Physical Interfaces -> Calling Features -> CallForwardUnconditionalNumber ((ob200123456 ))

RonR

Quote from: PhASE on April 25, 2012, 10:24:52 AM
Quote from: RonR on April 23, 2012, 12:47:43 PM
OBi110
Physical Interfaces -> LINE Port -> InboundCallRoute : {ph,pp(ob200123456)}
where 200123456 is the OBiTALK number of the OBi202.


RonR :
what is the difference between your suggestion & this :

Physical Interfaces -> Calling Features -> CallForwardUnconditionalNumber ((ob200123456 ))


Call Forward Unconditional will not simultaneously ring the OBi PHONE Port in additon to another destination, allowing either to answer.  It will simply forward the call to another destination.

Just for info, the proper syntax for Call Forward Unconditional would be:

Physical Interfaces -> LINE Port -> CallForwardUnconditionalNumber : PP(ob200123456)

PhASE

RnoR
Is that mean , if i want to make 100%  of line port calls to be diverted to other OBI endpoint without AA answer in either OBI ??
i have to make this modification :
Physical Interfaces -> LINE Port -> CallForwardUnconditionalNumber : PP(ob200123456)
========

RonR

To forward all incoming calls from the LINE Port of OBi-A to the PHONE Port of OBi-B with no Auto Attendant involved:

OBi-A

Physical Interfaces -> LINE Port -> InboundCallRoute : {pp(ob20123456)}


OBi-B

Voice Services -> OBiTALK Service -> InboundCallRoute : ph


You could use:

Physical Interfaces -> LINE Port -> CallForwardUnconditionalNumber : PP(ob200123456)

in OBi-A instead, but due to a design flaw in the OBi firmware, using Call Forward Unconditional prevents the use of any InboundCallRoute rules.  Consequently, I prefer to do the forwarding from the InboundCallRoute, leaving the door open for additional InboundCallRoute rules in the future.

PhASE

RnoR 1st of all many thanks to your help
2nd :
For obi (B) :
Voice Services -> OBiTALK Service -> InboundCallRoute : ph
what is that configuration  meaning ?? is that will block all other incoming calls except from OBI(A) ??




RonR

Call forwarding from OBi-A to OBi-B uses the OBiTALK Service.

Voice Services -> OBiTALK Service -> InboundCallRoute : ph

sends all OBiTALK Service incoming calls to the OBi PHONE Port.  This is the Default setting.

PhASE

Quote from: RonR on April 25, 2012, 11:14:33 AM
Call forwarding from OBi-A to OBi-B uses the OBiTALK Service.

Voice Services -> OBiTALK Service -> InboundCallRoute : ph

sends all OBiTALK Service incoming calls to the OBi PHONE Port.  This is the Default setting.

HUmmmm,
my Voice Services -> OBiTALK Service -> InboundCallRoute :{(290444586|290928697|200979372)>(xx.):SP1},{(290444586|290928697|200979372):aa},{ph}

what is that meaning ??

RonR

Quote from: PhASE on April 25, 2012, 11:32:20 AM
Voice Services -> OBiTALK Service -> InboundCallRoute :{(290444586|290928697|200979372)>(xx.):SP1},{(290444586|290928697|200979372):aa},{ph}

You have single-stage dialing capability through SP1 as well as Auto Attendant access from OBiON Apps with OBiTALK numbers of 290444586 and 290928697 and an OBi110 whose OBiTALK number is 200979372.  Incoming OBiTALK Service calls from all other sources will ring the PHONE Port.

You probably used the OBiTALK Web Portal to configure this OBi and used Circle of Trust to link the devices.

PhASE

Quote from: RonR on April 25, 2012, 10:56:20 AM
To forward all incoming calls from the LINE Port of OBi-A to the PHONE Port of OBi-B with no Auto Attendant involved:

OBi-A

Physical Interfaces -> LINE Port -> InboundCallRoute : {pp(ob20123456)}


OBi-B

Voice Services -> OBiTALK Service -> InboundCallRoute : ph


You could use:

Physical Interfaces -> LINE Port -> CallForwardUnconditionalNumber : PP(ob200123456)

in OBi-A instead, but due to a design flaw in the OBi firmware, using Call Forward Unconditional prevents the use of any InboundCallRoute rules.  Consequently, I prefer to do the forwarding from the InboundCallRoute, leaving the door open for additional InboundCallRoute rules in the future.


I did use this setting
Physical Interfaces -> LINE Port -> InboundCallRoute : {pp(ob20123456)}
Call did forward but AA answered in obi B !!!

Also i did this setting 
Physical Interfaces -> LINE Port -> CallForwardUnconditionalNumber : PP(ob200123456

Also AA in obi B answered the diverted call
 
Do i have to remove obiA from trust circle of obi B??
Also i need to make the call forward from obi a to b, as soon as line port in obi A rings, not to wait 2 or 3 rings
Can u help with two issues ??

RonR

Quote from: PhASE on April 25, 2012, 01:51:37 PM
Do i have to remove obiA from trust circle of obi B??

Yes.  Adding a device to the Circle of Trust is explicitly asking for the Auto Attendant to intervene.

You may wish to read : Using Trusted Callers and Circle of Trust

Quote from: PhASE on April 25, 2012, 01:51:37 PM
Also i need to make the call forward from obi a to b, as soon as line port in obi A rings, not to wait 2 or 3 rings

The OBi delays the processing of calls on the LINE Port in order to receive the CallerID (if present) that's sent between the first and the second rings.

If you don't have CallerID or don't care about CallerID, set:

Physical Interfaces -> LINE Port -> RingDelay : 0

Ostracus

Well I went with option one which actually wasn't that hard to set up. I may also be able to get my softphone working again.

rsriram22

Quote from: RonR on April 25, 2012, 10:56:20 AM
To forward all incoming calls from the LINE Port of OBi-A to the PHONE Port of OBi-B with no Auto Attendant involved:

OBi-A

Physical Interfaces -> LINE Port -> InboundCallRoute : {pp(ob20123456)}


OBi-B

Voice Services -> OBiTALK Service -> InboundCallRoute : ph


You could use:

Physical Interfaces -> LINE Port -> CallForwardUnconditionalNumber : PP(ob200123456)

in OBi-A instead, but due to a design flaw in the OBi firmware, using Call Forward Unconditional prevents the use of any InboundCallRoute rules.  Consequently, I prefer to do the forwarding from the InboundCallRoute, leaving the door open for additional InboundCallRoute rules in the future.


with this configuration, i am being greeted with AA on obi-B (since both Obi's are under the same account).. Now, how do I disable AA on obi-B (only) if the call is coming from obi-A(via obiservice or if the call got originated from the LINE port on obi-A)
have two 100s and one 110