Auto attendant not answering incoming PSTN call from phone in Circle of Trust

[Jon9999]

I have my cell number (e.g., (9175551212) in my Circle of Trust, with the Match option unchecked. I can see that OBiTalk has correctly changed my LINE InboundCallRoute to {('jon'|x.9175551212):aa},{ph}.

Yet when I call my POTS number from my cell, it just rings the phone. The aa doesn't pick up.

I can see in my call log that the calls from my cell are coming through with CID of 'WIRELESS CALLER' 9175551212.

I've tried changing the LINE InboundCallRoute to {('jon'|@.9175551212):aa},{ph} but that doesn't work either.

The aa does pick up when I call from OBiON.

Any ideas?

-jon

[ianobi]

I can see in my call log that the calls from my cell are coming through with CID of 'WIRELESS CALLER' 9175551212.

What matters here is exactly what is recorded in Status > Call History > Peer Number

Status > Call History > Peer Name is ignored by the OBi for routing purposes.

A rule such as @.9175551212 would match almost anything ending with digits 9175551212, if that is the Peer Number.

By the way, we are talking about "Trusted Callers" not "Circle of Trust". Yes, I know I'm being pedantic and it does not change anything about this question   

[Jon9999]

Darndest thing, Ian. Even though my incoming calls' CID is showing up correctly in Status>PHONE & LINE Status>Last Caller Info, and even thought the CID is displaying correctly on the phone connected to the PHONE port, the entries for Peer Name and Peer Number for the same call in Call History is completely blank. So that's why it's not matching the aa rule in the Line Port's Incoming Call Route. But why is the peer information not being captured in the log (or, presumably, in the rule engine) when it's there?

[ianobi]

You are not the first person to have this problem!

The OBi110 defaults are set for standard North America CallerID detect, so you should be OK for most settings. That's assuming that you are using a fairly normal PSTN line. Some of us plug all sorts of weird stuff into our Line Ports - GSM devices, other ATAs etc.

Several settings can affect how the OBi110 detects CallerID from the Line Port. To give the OBi more time to detect CallerID try increasing:
Physical Interfaces -> LINE Port -> RingDelay
This might get annoying if increased too much as it delays ringing from incoming calls.

You could also try changing these settings:
Physical Interfaces->LINE Port->Ring Detection -> RingThreshold to 19.35-23.65 and/or RingValidationTime to 150.

In North America the CallerID is delivered between the first and second bursts of ringing. The OBi110 needs to actually detect that first burst of ringing and have enough time to process the information before it routes the call. If any of that fails, then it routes the call to the Phone Port as a default position.

[azrobert]

If RingDelay is set too low you cannot test for CallerID in the InboundRoute(as ianobi described), but the OBi will start to display the CallerID as soon as it's available.

[Jon9999]

Several settings can affect how the OBi110 detects CallerID from the Line Port. To give the OBi more time to detect CallerID try increasing:
Physical Interfaces -> LINE Port -> RingDelay
This might get annoying if increased too much as it delays ringing from incoming calls.

That was it, Ian!  I had previously decreased the RingDelay to 2000 msec from the default of 4000 msec, because waiting 4 sec for my phone to start ringing led too many people to hang up before I got to the phone. I hadn't realized that that could affect the OBi's ability to capture the CID before routing the call over to the local phone. (But: Why can't the OBi continue to listen for CID even after it routes the call to the local phone?)

I put the RingDelay back up to 3500 msec, and now the AA is answering when he should be.

Thanks again!


P.S.  Ian, can you please explain something about the part of the AA-terminating InboundCallRoute that says 'jon'? I've figured out that OBiTalk puts it there using the GMail address that I entered into the Trusted Callers list so that Google Talk "call computer" calls made from that address to the OBi are sent to the AA, but what I don't quite get is why OBiTalk only inserted the part of the GMail address before the at-sign. The address I added is in a custom (non-gmail.com) domain, so how does that work? If someone named jon@gmail.com or jon@anything-else called from his Google Talk account to my phone number, wouldn't his call also go to my AA? Isn't that a big hole?

[ianobi]

In answer to your P.S. – some of this is new to me. I don’t use GV, so some of these issues don’t come up. However, I do have a gmail account so I did some testing.

Yes, trusted Callers does ignore the “@” and everything after it.
For incoming CallerID the OBi ignores the “@” and everything after it.

If someone named jon@gmail.com or jon@anything-else called from his Google Talk account to my phone number, wouldn't his call also go to my AA? Isn't that a big hole?

Yes, “jon” followed by “@” followed by anything with give a CallerID of “jon” and so will match your InboundCallRoute rule to give access to your AA. Yup – looks like a hole to me! To be fair, you can set a PIN number which prompts users for the PIN if using the AA Option 2. I find that too much of a nuisance, but the option is there.

I guess the moral here is to make your gmail user name very robust!

Obihai designed “Cicle of Trust” and “Trusted Callers” to allow non-techy people to use those functions and the InboundCallRoutes are changed by the OBi for them. They are blunt instruments. For instance, putting a number in Trusted Callers puts the corresponding access to AA rule in all InboundCallRoutes except for the OBiTALK InboundCallRoute.

You seem to be comfortable changing configurations, so you might get more finely tuned InboundCallRoutes by changing them manually. Using the “Expert Pages” as you have for other things. Uncheck the two boxes to the right, then simply input your own InboundCallRoute rules and submit changes.