CallerID incorrect when using Blind Transfer feature *98 (or attended transfer)

(1/2) > >>

GGellerVDOTel:
When testing this "undocumented" feature of blind transfer using *98, I have found that any calls transferred using this method are NOT using the original caller's callerID information.

Only the callerID of the OBi device is displayed to the receiving caller.

Comparing this against other similar ATAs I find this to be an OBi bug, as the callerID should be the original caller's.

I have verified this is the same result as attended transfer.

OBi 302
Firmware: 3.0.0 (Build: 3460)

Thanks,

Glenn Geller
VDO-Ph International

QBZappy:
Quote from: GGellerVDOTel on October 06, 2012, 10:48:21 pm

When testing this "undocumented" feature of blind transfer using *98, I have found that any calls transferred using this method are NOT using the original caller's callerID information.

Only the callerID of the OBi device is displayed to the receiving caller.

Comparing this against other similar ATAs I find this to be an OBi bug, as the callerID should be the original caller's.

I have verified this is the same result as attended transfer.

OBi 302
Firmware: 3.0.0 (Build: 3460)

Thanks,

Glenn Geller
VDO-Ph International


I believe that showing the OBi CID is by design. The actual CID is only delivered via the OBiTALK service, meaning that the proper CID will pass when transferred from an OBi to another OBi or OBi APP. I think this is more of a marketing philosophy to get you to buy another unit.

jimates:
The caller id should be that of the service used to bridge the call. If the transfer is using the Obitalk Service then it would be that of the delivering Obi. If you gave your Obi a name it will display the name.

Note: When a call originally comes in and is forked to another end point using the Obitalk Service, the caller id of the original call is used.

GGellerVDOTel:
Thanks for your input...

However, I was really comparing this feature of transferring to another device/phone number directly compared to other competing devices.

As I am specifically evaluating the OBi 302 (with Firmware: 3.0.0 (Build: 3460)) for ITSP use, I must mention that this behavior is different from all other competing devices we've certified.

As a service provider, we would not want the OBi callerID to show, except when being called directly by an OBi device. If it is a transfer, or a forward (using REFER), the ORIGINAL callerID should (read: MUST) be shown to the destination endpoint, otherwise it's broken (as compared to others).

Specifically, our reasoning is simple. Many of our customers rely on the callerID information of the actual caller, and if the OBi's callerID is in its place, then we cannot use the device for some clients, if not all clients.

Thanks,

Glenn Geller
VDO-Ph International

jimates:
Great, maybe Ohihai will make the needed changes.

Navigation

[0] Message Index

[#] Next page