Last Caller Number / *69 Call Return
RonR:
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.
ProfTech:
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.
RonR:
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.
RonR:
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.
RonR:
obi-support2,
Do you anticipate being able to investigate these issues in time for the forthcoming update?
Navigation
[0] Message Index
[#] Next page