andrewgroup Posted December 31, 2008 Report Share Posted December 31, 2008 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, Quote Link to comment Share on other sites More sharing options...
hosted Posted December 31, 2008 Report Share Posted December 31, 2008 yea before you used to be able to press $a or something to pass the ANI.. i miss that. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 1, 2009 Report Share Posted January 1, 2009 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! Quote Link to comment Share on other sites More sharing options...
shopcomputer Posted January 1, 2009 Report Share Posted January 1, 2009 This does work Vitelity, junction networks and Broadvox. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.