Callerid lost when routing via PP?

[codex22]

Hi folks,

new to Obi, I'm trying to route calls that come in on the LINE port on one OBI (A) to another OBI (B) to let the phone ring there.

It's working, but I always get the OBI (A) caller id, not the original caller id coming from the LINE port. The caller id is recognized, as I can see it both on a phone connected to OBI (A) and the call logs on OBI (A).

My POTS line InboundCallRoute looks simply like that:

{ph,pp(ob200265443)}

I also tried pp($1>ob200265443) and even pp(123456>ob200265443), but it seems there is never any caller id transported via pp!

Am I doing something wrong or is this just not supported?

Thanks

Michael

[yhfung]

You are not allowed to pass the user-defined ID to other end via ObiTalk. Only the OBi number of your OBi device will be passed to other OBi device.

YH

[codex22]

YH,

thanks for your fast response.

You are not allowed to pass the user-defined ID to other end via ObiTalk. Only the OBi number of your OBi device will be passed to other OBi device.

That's unfortunate, as this mean I will never know who's calling before I pick up the phone. Can this be done using SIP instead of ObiTalk? Had hoped I could avoid all that.

Michael

[yhfung]

Michael，

You may use SP1 or SP2 to pass your defined callerID provided that your SIP service providers allow you to do so otherwise it is the same as OBiTalk.

YH

[jimates]

I have multi Obi setup with calls forked to 2nd obi and I wish the incoming call caller id would be passed by the Obi.

[codex22]

IMHO, this is a crucial feature.

Take the scenario as supported by the "Home to Office Phone System Extension Wizard". How is this usable if you don't know who's calling?

I understand that there are security issues, but the OBI receiving the caller id from another OBI could explicitly allow this from specific devices ("allow caller id from following OBI numbers").

Unfortunately, my OBIs will be collecting dust 'til this is possible. :-(

Cheers

Michael

[jimates]

the current situation restricts the Obion apps to the point of outgoing calls only for me.

[krpan]

 

According to documentation (OBi Device Administration Guide v31.03.11, p.113-114) there are no restriction/exceptions to what terminal arguments are/work in InboundCallRoute.

In plain words, there is no mention on those pages that terminal arguments of the form cid>target (where cid is a literal string or $1) are not allowed or do not work when target is another OBi device.

I just wasted a lot of my time scratching my had as to why the documented feature does not work as advertised until I stumbled on this thread.

This means that, according to official documentation, we are dealing with a bug that needs to be fixed, or documentation is disseminating false and unreliable information.

I for one hope we are dealing with a bug that will be dealt with promptly, otherwise I wasted money on a dozen OBi's that are now useless. An here I was under impression I was making an informed decision by reading the official documentation 

[QBZappy]

krpan,

It is unfortunate that CID can not pass to target. There have been several posts regarding this. There are a few SP out there that might offer this ability. It's not clear what you are trying to do with a dozen OBi's, however another strategy you might consider is using a PBX like Asterisk to work around the current CID limitations of the OBi. This unfortunately increases the complexity of the system. On the bright side you will end up with OBi+Asterisk features.

[krpan]

Yes, I'm aware of and use SIP providers that allow setting of CID (e.g. CallWithUs) and I could also setup Asterix or preferably Freeswitch or even use a service at a place like PBXes.org. However there is a glaring problem associated with that... I waste one of the two precious SPx profiles (I need those to setup unique GV accounts, 2 per OBi unit)

Also, yeah I saw earlier that there are several post regarding this issue, but I did not think I'd have to verify veracity of all the information provided in official documentation. I know better now 

It is unfortunate, I'd like to have used (and recommended) OBi's for use in situations like what I wanted it for (i.e. physical line connected to OBi110 distributing calls to OBi110's or OBi100's at various other locations, neat and inexpensive compared to other solutions). While still doable, by adding layer(s) of complexity and wasting SIP/GV profiles, sadly it is no longer the attractive solution I thought it was.

But I still love OBi for all the other wonderful things it can do 

[obi-support2]

This is a limitation in 1.1 and 1.2 releases.
The OBi does not pass the original caller's number so that the called OBi can recognize the call is from a member in the circle-of-trust.

In release 1.3 (coming-soon), there will be an enhancement to show the original caller's number at the called OBi, but still uses the calling OBi's number for circle-of-trust matching.

[jimates]

"show the original caller's number at the called OBi"

Great. I am pretty sure that will satisfy my needs, and many others, where I only want to see the original callers number when forking calls to another endpoint, without any additional call management.


"but still uses the calling OBi's number for circle-of-trust matching"

If I understand that correctly, the caller id of the last device passing the call (not the id of the original call) is the caller id that will be used for COT at the next endpoint.

[krpan]

Thank you for info obi-support2, I'll definitely look forward to 1.3 

On another note, in my attempts to find ways to work around the soon to be dealt with limitation  I observed that when used in appropriate places in InboundCallRoute, $1 and $2 are treated as literals instead of being substituted with caller id and called id respectively (as per information on pages 113-114 in admin documentation)

I.e. According to documentation the following should work if used in InboundCallRoute of SP1 (SP1 and SP2 are setup as SIP accounts):

{(xx.):sp2($1>$2)}

instead OBi tries to make a call via SP2 using literal $2 as called id and using literal $1 as CID. The only place I've seen $1 substituted appropriately and not treated as a literal value was in AA digit map 

[QBZappy]

obi-support2,

Looking forward for this feature that many considered basic to have. Well done. (dance of joy)
+1

[yhfung]

On another note, in my attempts to find ways to work around the soon to be dealt with limitation  I observed that when used in appropriate places in InboundCallRoute, $1 and $2 are treated as literals instead of being substituted with caller id and called id respectively (as per information on pages 113-114 in admin documentation)

I.e. According to documentation the following should work if used in InboundCallRoute of SP1 (SP1 and SP2 are setup as SIP accounts):

{(xx.):sp2($1>$2)}

instead OBi tries to make a call via SP2 using literal $2 as called id and using literal $1 as CID. The only place I've seen $1 substituted appropriately and not treated as a literal value was in AA digit map 

Please note that if you want to pass caller or callee IDs to other parties via SP1 or SP2 provided the VoIP providers allow you to do so, otherwise all the information sent by OBi device to the providers are disregarded.


YH

[krpan]

Please note that if you want to pass caller or callee IDs to other parties via SP1 or SP2 provided the VoIP providers allow you to do so, otherwise all the information sent by OBi device to the providers are disregarded.


YH

Yup, I'm aware of that. My testing was done using CallWithUs as provider, and they accept passed CID data. That's why I know that OBi sent '$1' as CID when I tried to use it as documented in OBi Admin Guide