Jump to content

Trunk Caller ID when forking


jlumby
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

  • 3 months later...

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.

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...