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
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.
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.
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
Great, maybe Ohihai will make the needed changes.
Glenn Geller,
If you have not done so already, please contact support@obihai.com with details on the way you are doing the blind transfer.
Thank you,
Obihai Support
Try this:
In the ITSP settings, SIP section, enable X_UseRefer.
By default, it is disabled.
Quote from: OBiSupport on October 08, 2012, 05:20:20 PM
Try this:
In the ITSP settings, SIP section, enable X_UseRefer.
By default, it is disabled.
Actually, I received a call from Obihai directly today, suggesting this as a possible fix.
It works and solves my problem exactly, and no longer "bridges" the transfer.
Exactly what I needed. Thanks again.
Glenn Geller
VDO-Ph International
GGellerVDOTel,
Glad it worked out.
Why don't you introduce your company to us.
Quote from: OBiSupport on October 08, 2012, 05:20:20 PM
Try this:
In the ITSP settings, SIP section, enable X_UseRefer.
By default, it is disabled.
Could you expand on what the (Enable X_UseRefer.) function is?
I ask because I am using one of my SP's as an extension to my asterisk server and when a call comes into my Asterisk and is routed to an extension it gives me the extension number and not the CID of the calling party.
I should ad that I have set up an set up my GV account on sp1 to ring both PH1 and SP2 which is the sp connected to the Asterisk box.
Clear as mud I hope ?