Query on Behaviour of "Allow Passthrough of Configured Line Device Caller Information" SIP Profile Parameter

[Jonathan Els]

Hi

Please can someone give me a real world example of the behaviour that should be expected when configuring "Allow Passthrough of Configured Line Device Caller Information" on a SIP Profile and applying to a trunk?

I see the following basic information, but also see the following description elsewhere:

Outgoing SIP Call with two set of Identities - SIP Line

When Maintain Original Caller ID DN and Caller Name in Identity Headers are configured on the SIP Trunk, all outgoing SIP calls are impacted. This feature can also be configured for groups of SIP line devices via SIP Profiles. On the phone section of the SIP profile page, two new text boxes were added named Caller ID DN and Caller Name to mirror the switch-board data on a SIP Trunk. On the trunk section of SIP profile a new checkbox was added called Allow Passthrough of Configured Line Device Caller Information.

Please can someone explain the interaction with "Maintain Original Caller ID DN and Caller Name in Identity Headers" as well.  This is only configuration once a mask is applied under "Caller Information" on the trunk for outbound calls (under "Caller Information").?

I'm sure that the answer is staring me right in the face, but if someone would be so kind as to facilitate the needed facepalm, that would be greatly appreciated!

Thanks.

[Jonathan Schulenberg · Accepted solution]

Well this is a fun trivia question. Here is my interpretation of the documentation; disclaimer being that I have not tested all of this out first-person.

This all dictates what you want sent in the ANI and CNAM values for an outgoing call from CUCM across a SIP Trunk.

Frist, as the document explains there are two types of identities:

• network provided identity (trusted)
  In terms of SIP calls, identity headers including P-Asserted-Identity (PAI), P-Preferred-Identity (PPI) and Remote-Party-ID (RPID) carry the network provided identity
• user provided identity (non-trusted)
  the FROM header carries the user provided identity

Prior to CUCM 9 there was no distinction as far as CUCM was concerned: the Alerting/Display Name and DN (or External Phone Number Mask if set to be used on the Translation Pattern, Route Pattern, Route Group appearance on the Route List, or SIP Trunk Transformation Pattern) was set in all four SIP headers. If desired, these four fields could be overwritten all-in-one using the Caller ID DN and Caller Name fields on the SIP Trunk.

Starting in 9.0 CUCM starts distinguishing between the network and user identity. The Caller ID DN and Caller Name fields on the SIP Trunk or SIP Profile of the user device, if set, become the user identity. Meanwhile, the DN/EPNM and Alerting/Display Name become the network identity.

The Allow Passthrough of Configured Line Device Caller Information setting on the SIP Trunk tells it to use the Caller ID DN and Caller Name fields from the calling device's SIP Profile if set for the user identity instead of the Caller ID DN and Caller Name fields fields on the SIP Trunk.

In the end what do you want the far end of the SIP Trunk to see in the From header:

1. The calling phone DN/EPNM and Alerting/Display Name (default)
2. The Caller ID DN and Caller Name fields on the SIP Trunk
   To achieve this, set a value in the fields on the SIP Trunk and do NOT check Allow Passthrough of Configured Line Device Caller Information. This will ignore the value on the SIP Profile if it is set.
3. The Caller ID DN and Caller Name fields on the SIP Profile of the calling phone.
   To achieve this, set a value in the fields on the SIP Profile AND check Allow Passthrough of Configured Line Device Caller Information.

To determine what is in the P-Asserted-Identity (PAI), P-Preferred-Identity (PPI) and Remote-Party-ID (RPID) headers:

1. If the Caller ID DN and Caller Name fields ARE set on the SIP Trunk and/or SIP Profile:
   1. For the PAI, PPI, and RPID headers to match the From header, do nothing.
   2. For the PAI, PPI, and RPID headers to be the calling phone DN/EPNM and Alerting/Display Name, check the Maintain Original Caller ID DN and Caller Name in Identity Headers options on the SIP Trunk.
2. If the Caller ID DN and Caller Name fields are NOT set on the SIP Trunk and/or SIP Profile:
   1. For the PAI, PPI, and RPID headers to match the From header, do nothing.
   2. For the PAI, PPI, and RPID headers to be some other value, you have worked yourself into a corner. You probably want option 1.2.

So, a real-life example: I have seen ITSP want to "authenticate" a call based on the PAI header value being a DID the customer owns as opposed to the From header deciding the caller ID value. This wasn't how I solved that use case but it's an example.

[Lee Marson]

Hello,

I know this is an old thread but I wondered if anyone had come across this before:

Testing with ITSP they are expecting the from header on my INVITE to contain the original calling party DN as the user part of the uri e.g

From: <sip:<actual-directory-number>@10.30.10.11>

and the PAI header to show what I would like to be displayed e.g EPNM or Trunk CLI 

P-Asserted-Identity: <sip:<external-phone-number-mask>@10.30.10.11>

Problem is no matter where I manipulate the Caller ID on either CUCM or CUBE the PAI overwrites the uri in the from header so you lose the original caller address.

Seems like this is expected behaviour but wondered if anyone had come across a setting on CUCM or CUBE which would overide this? Or is there a scenario where this could happen. Suspecting its just the way Cisco implement SIP.

Thanks

Lee.

[Jonathan Els]

Without looking into it too deeply, you can achieve that with a SIP Normalization Script if you have a trivial masking requirement.  For multiple sites out the same trunk, this approach becomes less efficient.

Otherwise revisit Jonathan's (other Jonathan!) explanation above.

[lcalkins]

I realize this is a long time between, but I'm trying to find a solution to a problem I have and this explanation seems to be on the right track.

My problem is that our Telco wants a "Real' did to be in the P-asserted-identity.  What is happening by default is the when a call comes in to a DN and is forwarded, the original caller-id ends up in the P-asserted-identity and the call is rejected.  To fix this we change the value of P-asserted-identity to be a valid DID.  The problem we have now is that all calls have the same P-asserted-identity and we now need them to be based on the DN making the call.  So we want to change the value to be that of the DID in our call manager that was originally called.  If there is a setting we can put on the Trunk or on a SIP profile that will allow us to maintain the original caller-id but put the valid DID in the P-asserted-identity that would probably solve our problem.  

[jonathan.salter]

I would reach out to the carrier to see what if they can support a diversion header. I have it set up so I send the what they need in the diversion header and they will allow me to send an ANI in need out the SIP trunk.

[KY_]

what is  the difference between pi and pai ? I want to show calling name with calling name on the sip trunk via cube What should we do ?