Configuring SIP PRI to allow CallerID on Call Forward

[Anonymous]

I'm trying to configure an Adtran 908E to allow my customer to pass along the originating Caller ID when they enable forwarding on one of their PBX DIDs.  When I get the call back to my switch, it is showing the DID as the calling number and not the person who is calling.  I'm able to get this feature working on standard PRIs, but on SIP PRIs, it seems to fail.  I've added the   match ani "$" add p-asserted-identity "PBX Number" so that it will authenticate, and from my understanding that should allow it, but in my test lab it isn't working.  I'm wondering if its because I don't have a full fledged PBX to test with and I'm using a 2nd Adtran to simulate a PRI handoff.

[jayh]

This may depend on your terminating carrier and/or you may have to fix it in your SBC, or come up with a different authentication method such as a registered trunk. 

Many carriers, when presented with a call with differing SIP From and P-Asserted-Identity will use P-Asserted-Identity as the CLID when presenting it to the terminating carrier.  For those cases we had to manipulate the outgoing SIP headers to that carrier in the Sansay SBC.  Be sure to use a separate route for 9-1-1 that doesn't do this, and/or set the outbound emergency caller ID in the 908e as appropriate.

RFC3325 is somewhat ambiguous on this.  If the terminating carrier doesn't consider the originating carrier as part of its trust domain, according to the RFC it MUST NOT use PAI in any way.  Normally the trust domain is limited to the network of a specific carrier but we haven't had any luck convincing terminating vendors who pass the PAI on as CLID to stop doing so. 

Bottom line, in those cases we needed to strip the PAI header before handing the call to the terminating carrier, leaving the From as received from the PBX to allow hairpinned calls at a customer's PRI-based PBX to display the inbound CLID to the destination.

[Anonymous · Accepted solution]

Jamesnye,

Thanks for posting!  Generally, an actual PBX that forwards a call will often insert a "Redirecting Number" Information Element in the Setup message for the outbound call leg.  The redirecting number serves to specify the original destination of the call, or the device from which the call was redirected.  This redirecting number is added within a Diversion header on the SIP side of the Adtran unit.  In this scenario the original caller ID is preserved by mapping the Calling Party received on the PRI into the From header on the SIP side.

If the PBX is unable to add the Redirecting Number, we often use the following template to make sure it is added as a Diversion header on the SIP side of the call.

voice ani-list DIDs

  ani <inbound DID pattern 1>

  ani <inbound DID pattern 2>

!

voice trunk-list SIP_Trunks

  trunk T01

  trunk T02

!

voice trunk-list PBX_Trunks

  trunk T03

!

voice trunk T01 type sip

  sip-server primary <SIP server IP/Hostname>

!

voice trunk T02 type sip

  sip-server primary <SIP server IP/Hostname>

  match ani $ add diversion <Customer's main number>

!

voice trunk T03 type isdn

  <normal PRI config>

  caller-id-override number-inbound <Customer's main number> if-no-cpn

!

voice grouped-trunk SIP

  trunk T01

  accept $

  deny list SIP_Trunks

  permit list DIDs

!

voice grouped-trunk SIP_Diversion

  trunk T02

  accept $

  deny list DIDs

  permit list PBX_Trunks

!

voice grouped-trunk PRI

  trunk T03

  accept $

  permit list SIP_Trunks

The concept of this configuration is that two SIP trunks are created which point to the same SIP server.  One SIP trunk handles normal calls, and the other handles the forwarded calls which will need the Diversion header added.  We control which SIP trunk is used with our Source and ANI Based Routing (SABR) feature.  SABR looks at the Calling Party (ANI) to determine if it matches our known list of ANI for the site.  Our known list of ANI is defined within the "DIDs" ani-list.  SABR only allows calls from known ANI to use the main SIP trunk, unknown ANI uses the new SIP trunk which adds the Diversion header.

Hope this helps!

David

[Anonymous]

James,

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

David

[Anonymous]

David,

I am having this issue in my office.  Caller ID is received on each desk phone but it is sending only our main phone number as the caller ID when a call is forwarded.  Would it be possible to speak with you on the phone to help fix this for us?  Caller ID passthrough is very critical for our business.  I didn't know how to get in touch with you.  I registered for this community today so I could ask you for help.

Thanks,

Anthony Campanella

Anthony Campanella  | LinkedIn