Jump to content

Redirection of Original Caller-ID to cell phones


andrewgroup
 Share

Recommended Posts

Some time ago on version 2.0 and with a previous ITSP we had the following feature working fine. An outside caller would dial a DID and the call if redirected to the person's Cell Phone would see the Caller ID of the caller and not their office or extension.

 

Somewhere in the middle of last year we upgraded that client to V3.x and that feature quit working, we didn't spend a great deal of time to address the trouble, but simply put them back on 2.x

 

That client has since moved to another ITSP using BroadSoft V14 broadworks, and we upgraded them the the latest 3.x and that old problem reappeared.

 

If we set trunk the remote party-ID (the calls are not forwarded) RFC3325 P asserted forwards the calls, but we see the trunk caller ID and not the original caller.

 

The ITSP is quick to wash their hands and lay blame on PBXnSIP, but maybe it's just us and how we have set this up.

 

We are exciting about partnering with the ITSP in our market, but need to overcome a few hurdles starting with this one....

 

Any help or feedback from someone on a Broadwords (CBEYOND) with this working as expected would be wonderful....

 

Cheers,

Link to comment
Share on other sites

Some time ago on version 2.0 and with a previous ITSP we had the following feature working fine. An outside caller would dial a DID and the call if redirected to the person's Cell Phone would see the Caller ID of the caller and not their office or extension.

 

Somewhere in the middle of last year we upgraded that client to V3.x and that feature quit working, we didn't spend a great deal of time to address the trouble, but simply put them back on 2.x

 

That client has since moved to another ITSP using BroadSoft V14 broadworks, and we upgraded them the the latest 3.x and that old problem reappeared.

 

If we set trunk the remote party-ID (the calls are not forwarded) RFC3325 P asserted forwards the calls, but we see the trunk caller ID and not the original caller.

 

The ITSP is quick to wash their hands and lay blame on PBXnSIP, but maybe it's just us and how we have set this up.

 

We are exciting about partnering with the ITSP in our market, but need to overcome a few hurdles starting with this one....

 

Any help or feedback from someone on a Broadwords (CBEYOND) with this working as expected would be wonderful....

 

The standards for presenting the caller-ID are clear, just check out RFC3325. And BroadSoft can for sure support RFC3325.

 

The root of the problem is that the carriers are simply scared that customers are using this feature for fraud. How can a carrier make sure that you don't put some funny Caller-ID in and let people call you back on numbers that cost a lot of money?

 

Either the carrier has to trust that pbxnsip software does not do such a bad thing or there needs to be an association between an inbound call and a resulting outbound call. For example if someone calls into the PBX, and the PBX forks the call off to a cell phone, then the carrier could say "okay, those calls belong together" and present the original caller-ID (which is still in the From header).

 

If we need to present some kind of token that makes this call-association easier and obvious, we'll happily put that in! I am serious!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...