Incoming International Call showing as unknown - No Callid on GV

[Diana]

I have a problem with calls from a relative outside of the US.  The call is from a Mobile Number that shows up sometimes in GV Call Logs as Unknown, while the corresponding number shows up in the OBi110 with a 10-digit number (AAA-555-1212).  Other times the call comes in with 11-digits (1-AAA-555-1212) and this shows up properly with the 11-digit Callerid in the GV/OBi Logs and rings the phone attached to the OBi110 phone port.

The problem is, if the call comes in with 10-digit (unknown in GV Log), it gets diverted to another GV number which plays the message that we do not accept calls from unknown callers  ( {?:sp1(1AAA7778888)} ).

How can I change the X_InboundCallRoute to send this call (with 10-digit Callerid) to the phone port, instead of having it being diverted by the other "unkown" caller trap that I have program in my X_InboundCallRoute ( {?:sp1(1AAA7778888)} )?

Would {AAA5551212:ph} ahead of the unkown diverter work?  I only want to do this for one number only.  The country that this call is coming in from uses the same callerid as the US.

[ianobi]

The problem is, if the call comes in with 10-digit (unknown in GV Log), it gets diverted to another GV number which plays the message that we do not accept calls from unknown callers  ( {?:sp1(1AAA7778888)} ).

Are you sure that this is getting to your OBi and then being diverted to get the "do not accept" message? Is it possible that the message is coming from GV before the call gets to your OBi?

I ask the question because this rule {?:sp1(1AAA7778888)} should only trap calls that arrive with no CallerID. That is to say, if the rule did not exisit, then in Status > Call History > Peer Number would be blank. There may be other rules in your InboundCallRoute preventing you receiving a ten-digit CallerID. Perhaps you could post your full InboundCallRoute here.

If the calls are coming into your OBi and somehow being diverted, then this would show in Status > Call History.

[Diana]

The calls are indeed showing in the OBi110 call history.  For each incoming call from AAA-555-1212,at a specific time, the call history from the device web status page, shows a corresponding outbound call to 1AAA7778888.  So, I know the calls are being diverted just looking at the status page.  As stated before, the calls do come in with 1-AAA-555-1212 (1AAA5551212 = AAA = Area Code) sometimes and those calls show up correcting in the GV call logs and do ring the phone port.  The directed calls only ring the phone port once and if the phone is pickup after the first ring, you will get the dial tone and the GV Call Logs shows the call as unknown, even though the OBi110 shows a 10-digit callerid.  

See in my X_InboundCallRoute for SP1 (GV) below;  I actually have three cases where the calls are diverted:

{?:sp1(1AAA7778888)},{unknown:sp1(1AAA7778888)},{(@|@@|@@@|@@@@|@@@@@|@@@@@@):},{asterisk:},{sip:},{'asterisk':},{('asterisk'):},{0000000000:sp1(1AAA7778888)},{ph}

EDIT:  I look more closely at the OBi110 Call History and this is what I'm seeing:

Call 15   07/27/2013    19:28:24   

Terminal ID   SP2   GoogleVoice1
Peer Name      
Peer Number      1AAA7778888
Direction   Inbound   Outbound
19:28:24   Ringing   
19:28:26      Call Connected
19:28:43   End Call   
Call 16   07/27/2013    19:28:22   

Terminal ID   GoogleVoice1   PHONE1
Peer Name      
Peer Number   AAA5551212   
Direction   Inbound           Inbound
19:28:22   Ringing   
19:28:27   End Call   

I don't understand how SP2 came into the picture, since only "Chat" is checked for this contact, and the outbound calls should use the second channel of GV (SP1) for the outbound leg of the diverted calls.  I have two numbers setup for this contact in GV:  1AAA5551212 and AAA5551212.  BTW, AAA = 876.   

[ianobi]

I suspect that GV is involved somewhere in all this, but I don't use GV and don't know much about it.

I can see nothing in your InboundCallRoute that would stop a ten-digit CallerID from calling the Phone Port. For now, I would try using your suggested rule {AAA5551212:ph}. Make it the first rule in the InboundCallRoute.

[Shale]

For now, I would try using your suggested rule {AAA5551212:ph}. Make it the first rule in the InboundCallRoute.

Would {1?AAA5551212:ph} or {@.AAA5551212:ph} be more robust, or has the number been normalized to a 10-digit number by then?

For others reading the thread, AAA in this thread refers to a specific numeric area code such as 312. That may be obvious to everybody reading, but it may not be.

[ianobi]

Shale,

Yes, both of your suggestions would work fine. However, it does seem that 11 digit CallerID gets accepted anyhow, so it's the ten-digit CallerID that seems to need some help.

The incoming calls that get diverted seem to be recorded as "unknown" by GV. I think that is the key, but I don't have any real knowledge of how GV works.

[Shale]

Ahh. In my call history, all GV incoming calls have the string "From GT1(1" in the exported call history and in the call history. None is missing the "1" after the "(". However none of them is from outside of the USA.