Passing CID from Google Voice to CallCentric

[RJDB]

I have Google Voice configured on SP1 and CallCentric configured on SP2.

I am able to sucessfully bridge calls on SP1 and SP2 (both directions).

I have an inboundcallroute rule that bridges all incoming SP1 to SP2.

When I bridge from SP1 to SP2, the CID received on the SP2 distant end is the OBI SP2 CC number.    When I look at the call history, it shows the correct number (not a GV number) on the inbound SP1.

Is there a way I can pass the inbound SP1 CID to the outbound SP2 - so the distant CC end shows the CID of the initiating phone (the inbound SP1 CID)??

Thanks

[RonR]

Do you have?:

Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID : (checked)

[RJDB]

I selected it, and tried again.   The call did not go through.   

When I examine the call history it shows the call was bridged, with "End Call (403 Incorrect Authentication)".

I have IP Freedom accounts with CC, and according to the rules I am only allowed to make in network calls.

Apparently, CC will not complete the call when it encounters an Out of Network number.

Thanks for your support!!!

[RonR]

You might wish to review this Callcentric FAQ page:

http://www.callcentric.com/faq/31/219

I don't believe the OBi sets P-ASSERTED-IDENTITY or REMOTE-PARTY-ID headers on CallerID spoofing.  Instead, it alters the FROM header, which does not work with most VoIP providers.

[RJDB]

Thanks for the link Ron.

Unfortunately, I wanted to simply pass all inbound SP1 to SP2 on short term temporary situations (traveling out of the country, etc.).   Thought it might be nice to implement CID for bridged calls.

The CC number verification process is probably doable for a very short list of friends/relatives, but it really doesn't support my lofty goals.

Thanks again!

[Stewart]

Is there a way I can pass the inbound SP1 CID to the outbound SP2 - so the distant CC end shows the CID of the initiating phone (the inbound SP1 CID)??

This can be a really tough problem, not because of what you have already seen, but because the low-cost routes to foreign mobiles generally won't pass caller ID.  Some solutions don't involve the OBi.

Get a DID from Anveo and forward to your destination.  Quality and reliability are excellent, caller ID gets correctly delivered, but this is a fairly expensive solution.

Next step down, try Localphone.  Unfortunately, a US caller ID gets sent as 10 digits (without the initial 1), so e.g. a call from 415 area code may be interpreted and parsed by your phone as coming from Switzerland and will likely not match the entry in your contact list.  However, if you visually recognize the number, you'll know who is calling.

Through the OBi, if the call comes to a provider that supports call transfer via REFER, and you send it back out via the same provider, the call will be transferred rather than bridged, so the caller ID will be correct (if provider's upstream carrier passes it correctly).

What you were originally trying to do will work with Voxbeam.  They give you $1 credit at signup, so you can test without making a payment.  Unfortunately, OBi won't spoof on a VGx, so you would have to "burn" SP2 for Voxbeam.  You'd then have to move Callcentric to a VGx, perhaps using SIP URI to get incoming calls.  Of course, you'll need to use Premium route to ensure caller ID delivery.

Flowroute is likely a better solution than Voxbeam, because you won't have to hassle with IP authentication.  They also give you a small test credit when you sign up.  I'm not a Flowroute customer, though, so can't supply the details.

[CustomATA]

Is there a way I can pass the inbound SP1 CID to the outbound SP2 - so the distant CC end shows the CID of the initiating phone (the inbound SP1 CID)??

What you want is easily done. As per RonR's post, you need Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID checked.

You also need an entry in Voice Services -> SP1 Service -> X_InboundCallRoute to bridge your inbound calls to the remote extension via callcentric's public interface, i.e. "in.callcentric.com" (not "callcentric.com"). The entry should look something like "{sp2(17775551234@in.callcentric.com)}", where you'd replace "17775551234" with the actual callcentric extension you want to ring. If you want to ring both the remote extension as well as any phone attached to the OBi, you can make the entry "{ph,sp2(17775551234@in.callcentric.com)}" instead.

[Stewart]

... You also need an entry in Voice Services -> SP1 Service -> X_InboundCallRoute to bridge your inbound calls to the remote extension via callcentric's public interface, i.e. "in.callcentric.com" (not "callcentric.com").

This is very interesting news.  I had learned (the hard way) that OBi won't spoof on a VGx, but didn't know that a direct URI would bypass that limitation.  I don't want to test that now; my OBi is far away and there is a risk of losing control when the device is rebooted.

I see two great uses for this feature.  Can you please confirm whether either or both will work?

1. Send the call to a second CC account, using in.callcentric.com, then forward it on to your foreign mobile, via a Call Treatment.

2. Send the call directly to a foreign mobile via e.g. Voxbeam or Flowroute, with X_InboundCallRoute = {sp2(0011101xxxxxxxxxxx@sbc.voxbeam.com)}

[RJDB]

Is there a way I can pass the inbound SP1 CID to the outbound SP2 - so the distant CC end shows the CID of the initiating phone (the inbound SP1 CID)??

What you want is easily done. As per RonR's post, you need Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID checked.

You also need an entry in Voice Services -> SP1 Service -> X_InboundCallRoute to bridge your inbound calls to the remote extension via callcentric's public interface, i.e. "in.callcentric.com" (not "callcentric.com"). The entry should look something like "{sp2(17775551234@in.callcentric.com)}", where you'd replace "17775551234" with the actual callcentric extension you want to ring. If you want to ring both the remote extension as well as any phone attached to the OBi, you can make the entry "{ph,sp2(17775551234@in.callcentric.com)}" instead.

It worked like a Champ!!!    The originating CID was displayed on my cell softphone (CC account) - at the distant/receiving end.

Thanks!!!

[CustomATA]

I don't want to test that now; my OBi is far away and there is a risk of losing control when the device is rebooted.

I don't have an OBi myself. "My" OBi actually belongs to a family member, for whom I manage it remotely through provisioning. Haven't had any issues at all doing it. If you manage yours via the OBiTalk portal, you may want to consider provisioning it yourself instead.

I see two great uses for this feature.  Can you please confirm whether either or both will work?

1. Send the call to a second CC account, using in.callcentric.com, then forward it on to your foreign mobile, via a Call Treatment.

2. Send the call directly to a foreign mobile via e.g. Voxbeam or Flowroute, with X_InboundCallRoute = {sp2(0011101xxxxxxxxxxx@sbc.voxbeam.com)}

I only have free IP Freedom accounts with Callcentric, and no Voxbeam or Flowroute accounts, so I'm afraid you'll have to confirm it yourself, or have someone else try it for you. As Callcentric goes, I'd expect that they'd forward to the PSTN with the DID associated with the forwarding CC extension as caller id. Since in.callcentric.com accepts any arbitrary caller id, there could be potential regulatory issues in blindly passing such along to the PSTN. I have no idea what Voxbeam or Flowroute do.

[RonR]

If you manage yours via the OBiTalk portal, you may want to consider provisioning it yourself instead.

How have you managed to do your own provisioning?  I was under the impression that Obihai wouldn't release provisioning info to anyone but OEM types.

[RJDB]

If you manage yours via the OBiTalk portal, you may want to consider provisioning it yourself instead.

How have you managed to do your own provisioning?  I was under the impression that Obihai wouldn't release provisioning info to anyone but OEM types.

I interpretted "provisioning it yourself" as local provisioning via 192.168.xxx.xxx, as opposed to OBiTalk.com.

[CustomATA]

How have you managed to do your own provisioning?  I was under the impression that Obihai wouldn't release provisioning info to anyone but OEM types.

It's trivially easy to figure out how. I may write up some instructions when/if I find the time.

I interpretted "provisioning it yourself" as local provisioning via 192.168.xxx.xxx, as opposed to OBiTalk.com.

I'm referring to auto-provisioning via "System Management -> Auto Provisioning -> ITSP Provisioning -> ConfigURL".

[RonR]

How have you managed to do your own provisioning?  I was under the impression that Obihai wouldn't release provisioning info to anyone but OEM types.

It's trivially easy to figure out how. I may write up some instructions when/if I find the time.

I hadn't thought about, but it wouldn't surprise me if the config file format is the same as a backup file.  Is that the case?

[CustomATA]

I hadn't thought about, but it wouldn't surprise me if the config file format is the same as a backup file.  Is that the case?

Yes. The quick and easy way is to use a backup file (generated without any of the backup options checked) as starting point. That file doesn't include any of the secret fields, such as account passwords and protected provisioning variables, which have to be added manually. If you want the provisioning to be encrypted, as I do it, you'll need to encrypt the file with a tool such as OpenSSL and specify the right encryption parameters in ConfigURL.

[RonR]

Thanks!  I'll play around with it when I find some time.

[infin8loop]

I hadn't thought about, but it wouldn't surprise me if the config file format is the same as a backup file.  Is that the case?

Yes. The quick and easy way is to use a backup file (generated without any of the backup options checked) as starting point. That file doesn't include any of the secret fields, such as account passwords and protected provisioning variables, which have to be added manually. If you want the provisioning to be encrypted, as I do it, you'll need to encrypt the file with a tool such as OpenSSL and specify the right encryption parameters in ConfigURL.

That is clever! I can see another weekend playing with this in my future.  LOL