obi-support2,
There appears to be a problem with:
Physical Interfaces -> PHONE Port -> LastCallerNumber
An incoming call to SP2 (SIP) is displayed in LastCallerNumber as: **218005551212. *69 works properly, returning the call on SP2.
An incoming call to SP1 (GV) is displayed in LastCallerNumber as: 18005551212. *69 works properly, returning the call on the PrimaryLine.
An incoming call to PP (OBiTALK) is displayed in LastCallerNumber as: ob200123456. *69 works properly, but only if PrimaryLine is set to OBiTALK Service.
I could not test the LINE Port as I don't have CallerID service.
Shouldn't LastCallerNumber be displayed consistently? I would have thought LastCallerNumber would have a **n prefix unless the call came in on the PrimaryLine (PrimaryLine appears to have no effect). Then *69 would return the call on the same service it came in on.
Please explain in detail how *69 Call Return is implemented, including how CallReturnDigitMaps is processed, whether the PHONE Port DigitMap and/or OutboundCallRoute come into play, etc. The OBi Device Administration Guide is lacking and confusing in this area.
I did a little more testing and came up with a similar preponderance. My primary line is SP1 [SIP] and SP2 is Google Voice so I have never seen where the phone number was displayed as anything except 1xxxxxxxxxx. I tried several variations of the following for the Call Return Map {sp2:(1217x.)},{sp1:(MLdist)} and
{sp2:(<**2>1217x.)},{sp1:(MLdist)} in an attempt to route the call based on the area code and no matter what I tried, the call went out SP1. I have a user defined map called ldist that is 1[2-9]xxxxxxxxx
Update: I cleared the CallReturnDigitMaps field completely and the calls still go out SP1 just fine so it must be using the OutboundCallRoute field.
I'm becoming more and more convinced the OBi is not handling the last caller number token ($LCN) correctly and/or not processing CallReturnDigitMaps properly. I suspect it's supposed to work something like this:
The OBi remembers the number of the last incoming call to the PHONE Port and the trunk name (sp1, sp2, li, pp) it came in on. It processes this through the CallReturnDigitMaps, matching the trunk name to one of the rules. The matching rule's embedded DigitMap causes **n to be added, except in the case where the call came in the PrimaryLine (pli), and the result is stored in $LCN. *69 Call Return calls the number stored in $LCN using the PHONE Port OutboundCallRoute (the PHONE Port DigitMap is not used). $LCN is also used to display PHONE Port -> LastCallerNumber.
ProfTech,
It appears that an empty CallReturnDigitMaps or a failure to match any of its rules (either by trunk name or embedded DigitMap) results in the last caller number ($LCN) simply being passed unchanged to the PHONE Port OutboundCallRoute where it is likely to match and go out the PrimaryLine.
It sure looks like this area is broken.
obi-support2,
Do you anticipate being able to investigate these issues in time for the forthcoming update?
obi-support2,
Is there some reason you're ignoring my posts to you?
Obihai,
I would really appreciate the courtesy of a reply. I will summarize my questions and concerns again.
Assuming the default PHONE Port CallReturnDigitMaps, is this an accurate description of the workings of $LCN, *69, and PHONE Port -> LastCallerNumber?:
The OBi processes the number and trunk name (sp1, sp2, li, pp) of the last incoming call to the PHONE Port through the CallReturnDigitMaps, matching the trunk name to one of the rules. The matching rule's embedded DigitMap then causes **n to be added, except in the case where the call came in the PrimaryLine (pli), and the result is stored in $LCN. *69 Call Return calls the number stored in $LCN using the PHONE Port OutboundCallRoute. $LCN is also used to display PHONE Port -> LastCallerNumber.
If this is not accurate, please provide the correct description.
Currently, *69 and LastCallerNumber do not appear to be working correctly.
Regardless of what PrimaryLine is set to:
Only calls coming in from a SIP trunk get **n added and get returned on the same trunk.
Calls coming in from a Google Voice or OBiTALK trunk do not get **n added and get returned on the PrimaryLine trunk.
*69 fails if the last caller number was from an OBiTALK trunk and PrimaryLine is not set to OBiTALK Service.
*69 fails if the last caller number was from a Google Voice trunk and PrimaryLine is set to OBiTALK Service.
There are probably failure scenarios involving the LINE Port, but I don't have CallerID and cannot test them.
If $LCN, *69, and PHONE Port -> LastCallerNumber were handled properly as I described above, I believe all scenarios would work correctly, returning the call on the same trunk it came in on, regardless of what PrimaryLine is set to.
PLEASE respond to this post.
I only use default, and it's all working as expected, including PSTN calls.
We will have someone check on your cases and report back on Monday.
Thank you.
We can duplicate the problem with Google Voice on SP1/2; and this is a bug we need to fix.
-----
To explain how it works, let's consider the default CallReturnDigitMaps:
{pli:(xx.)},{sp1:(<**1>xx.)},{sp2:(<**2>xx.)},{li:(<**8>xx.)},{pp:(<**9>xx.)}
The pli in first rule is replaced with the configured primary line upon system start.
If there is a conflict with another rule later in the list, the rule that comes first (left-to-right order) will be used by OBi. So if primary line is OBiTALK service, the **9 prefix will not be added, and so on.
For incoming calls on any trunk, the OBi first applies the CallReturnDigitMap for that trunk to come up with a mapped number. If no rule is found for that trunk, the original caller number is used as the mapped number. OBi then applies the PHONE Port DigitMap on the mapped number and
stores the mapped result as the LastCallerNumber status parameter on the PHONE Port web page.
When you dial *69, OBi uses the stored number directly for call routing. In other words, PHONE Port DigitMap is applied when the call return number is stored; not when *69 is dialed.
-----
The bug is, when SP1/2 is configured as Google Voice, the OBi fails to find the corresponding CallReturnDigitMap, and therefore no prefix is added; hence *69 in that case always try to use the primary line. If your GV trunk is also your primary line, then you won't notice the difference.
(For SIP, everything works as expected).
----
If you would like to try out patch to fix this issue, please send an email to
supprt@obihai.com and include your OBi number. We can push the patch to your unit.
Thank you for reporting this issue.
OBIHAI Support Team
Quote from: obi-support2 on May 16, 2011, 12:56:45 PMIf you would like to try out patch to fix this issue, please send an email to supprt@obihai.com and include your OBi number. We can push the patch to your unit.
Yes, I would like the update. I sent an email a couple of hours ago, but the update is still not available.
Thanks,
Ron
RonR, your unit (obi number ending 28) has just been updated.
Quote from: obi-support2 on May 16, 2011, 12:56:45 PMWe can duplicate the problem with Google Voice on SP1/2; and this is a bug we need to fix.
The problem with Google Voice appears to be corrected in the test firmware I received. FWIW, the OBiTALK Service aspect of this problem got fixed in the public release of build 2286.
Quote from: obi-support2 on May 16, 2011, 12:56:45 PMTo explain how it works, let's consider the default CallReturnDigitMaps:
I had it figured out correctly except for overlooking the need to pass the number through the PHONE Port DigitMap before storing it in LastCallerNumber.
Thanks for the explanation and fix.
There are two typos in the OBi Device Administration Guide:
Page 106 : $LCR = last caller's number (for call return) (global; read only)
Page 107 : *69, Call Return, call($LCR)
Both of these should be $LCN.