jlumby Posted January 28, 2010 Report Share Posted January 28, 2010 I just wanted to see how caller ID should be handled when forking to a call phone. In the past all of my ITSPs have sent the original caller ID along when forking to a cell phone. However I now have a situation with a different ITSP where it always sends whatever is in the ANI field. I have tried all of the different caller ID settings on the trunk, and it always sends the ANI. I have verified that they will allow me to send any ANI I want by filling a random 10 digit number in the field, and it will send it on through to the cell phone. I have looked at packet captures, and I see both the ANI, and the original caller ID going out in the invite packet from the trunk. What value should be getting used, as well as what is the intended way for PBXnSIP to work? Quote Link to comment Share on other sites More sharing options...
jlumby Posted January 28, 2010 Author Report Share Posted January 28, 2010 I have just completed a bunch of packet captures, and uncovered what seem to be some inconsistencies in the fields when you select different types of caller ID on the trunk With the trunk set to P Preferred when forking a call, the fields display the following: From: Original Caller ID Contact: Original Caller ID P Preferred: Extension ANI field With the trunk set to P Asserted when forking a call, the fields display the following: From: Original Caller ID Contact: Original Caller ID P asserted: Extension ANI field With the trunk set to none, when forking a call, the fields display the following: From: Extension ANI field Contact: Extension ANI field With the trunk set to remote party id when forking a call, the fields display the following: From: Extension ANI Field Contact: Extension ANI Field remote party ID: Original Caller ID With the trunk set to 3325 don't hide when forking a call, the fields display the following: From: Original Caller ID Contact: Original Caller ID P Preferred: Extension ANI field All of these packet captures were done on 3.4.0.3202 win 32. While I do not know the RFC behind them, I am going out on a limb, and assuming that the From: and contact: fields should remain the same, and the Remote Party/Privacy Indication: should be the only thing that is different in the packets. Ontop of that, I would expect that it would show something consistently like always show the original caller ID, or always show the ANI field, and not change based upon the type of Remote Party/Privacy Indication: selected on the trunk. Personally I wish I could always show the original caller ID, however I believe that to make a flexible product, there should be the option to choose on a per extension basis if you want to send the original caller ID, or if you want to send the extension ANI on forked calls. The inconsistencies I am having come from if I have 2 trunks, and someone turns on call forking, if their call goes out the trunk that supports remote party ID, they get the original caller id, however if that trunk if full, or the second trunk (P preferred identity trunk)is prefered in the dialplan, then they get their Extension ANI on forked calls. This inconsistency is causing a real customer service headache. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 29, 2010 Report Share Posted January 29, 2010 I wish the world out there would be clear when it comes to representing where the call comes from. It is a pretty big mess. What is clear that the "From" header contains what the call phone should have on the display. Period. The mess is about PAI, PPI, Remote-Party-ID and all that stuff. Everyone uses it in a different way. That is why we have so man options and you always have to guess which one is the right one. Actually, for a proper trunk identification, all you need is the ICID. This is a kind of token that identifies the trunk to the provider, very very simple and does the job 100 %. We also send an additional prorietary header called "Related-Call-ID", which contains the Call-ID for the original call. This should make it possible for the carrier to verify that the content of the From-field is okay and that we are not just spoofing Caller-IDs. Quote Link to comment Share on other sites More sharing options...
jlumby Posted January 29, 2010 Author Report Share Posted January 29, 2010 I can understand how all of the different standards can be problematic, however you said that what is clear is what is in the from header is what should be on the display. In my packet captures I noticed that the from header changes based upon the type of Remote Party/Privacy Indication selected, is this a glitch, and if so, can it be fixed? Just wondering since I can come up with a workaround with my second ITSP if the from field always indicated the original caller id (like it does for PPI and PAI) They stated that if they did not receive a PPI or PAI, then they will fall back to reading the from header. So therefore I could set it to no indication (or remote party id), and that would cause them to read the from header. The problem now is the from header changes when you select no indication or remote party ID vs PPI or PAI Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 30, 2010 Report Share Posted January 30, 2010 No, RPI actually requires that the "From" goes into the RPI and then the from header takes the content of the authenticated party. Sounds complicated and troublesome? That is why if never became RFC and should not be used any more. IMHO ICID is the best. 2nd best are PAI or PPI. Unfortunately there is a lot of legacy stuff out there and voting here would not help... Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted May 18, 2010 Report Share Posted May 18, 2010 Maybe Not related, but worth a try... set the inbound trunk setting to http://forum.pbxnsip.com/index.php?showtopic=3598 Out ITSP just upgraded their BroadSoft Platform to Enterprise V16 and installed a acme packet SBC that deliver of the originating caller when redirected to a cell or land line. Use the term "hairpinning" when talking to the ITSP, maybe that will help. 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.