cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
879
Views
2
Helpful
2
Replies

P-Assertion-Identity CUCM Cube Call Forwarding

FAST-DETECT
Level 1
Level 1

Hey folks, 

my new ITSP identifies their customers with the P-Asserted-Identity header field. If it is not set, they use the number given in in the FROM field. 

During normal operations some phone registered with CUCM dialing out with their own prefix+did this works just fine. Our ITSP also supports CLIP no Screening, however a vaild number from our contract has to be submitted within the P-Asserted-Identity header field. This is pretty standard these days from what I read and know. 

We want to make use of CLIP no Screening when forwarding calls, so the original caller ID is displayed. 

Calls go in via Trunk on our CUBE, get passed to CUCM, CUCM again uses the CUBE trunk to reach our ITSP. When I make a sip-profile:

 

 

voice class sip-profiles 200
 request ANY sip-header P-Asserted-Identity modify "P-Asserted-Identity: <sip:(.*)>" "P-Asserted-Identity: <sip:+1234567@1.2.3.4>"

 

 

and use the sip-profile in my dial-peer it works just fine. 

However I dislike, that for every phone, registered to our CUCM the same P-Asserted-Identity gets transmitted to the ITSP. They might use this for billing purposes etc. 

Is there any way to have CUCM provide the correct PAID along? When I configure the Trunk on CUCM side I can send a PAID, however CUCM just sends a PAID which is apparently derived from the FROM field and corresponds to the external caller-ID. When modifying the PAID with a TCL script on the CUCM outgoing side, CUBE seems to not use that PAID but also takes the from field and converts it into a PAID. I'm on IOS 15.5(3)M4a on the CUBE which should fix a couple of bugs related to PAID pass through.

This doesn't seem to be an ultra rare requirement - I can imagine many companies want a configuration like that? Any suggestions are welcome!

regards,

Fabian

 

1 Accepted Solution

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame

You should be using the Diversion header for this instead. PAID is the original calling party information while Diversion is the forwarding CUCM DN External Phone Number Mask. The ITSP should not screen PAID if Diversion is a DID assigned to that trunk group.

If you haven’t already, enable Diversion outbound (not inbound) on the CUCM SIP trunk toward CUBE.

View solution in original post

2 Replies 2

Jonathan Schulenberg
Hall of Fame
Hall of Fame

You should be using the Diversion header for this instead. PAID is the original calling party information while Diversion is the forwarding CUCM DN External Phone Number Mask. The ITSP should not screen PAID if Diversion is a DID assigned to that trunk group.

If you haven’t already, enable Diversion outbound (not inbound) on the CUCM SIP trunk toward CUBE.

Hi,

yes you are right. They also accept Diversion outbound and will replace PAI with whatever is in the diversion field. It works just fine. CUCM sends:  Diversion: "fn ln" <sip:DID@ip>...   as Diversion header. It was easy to creat a rule on CUBE to playe our prefix-number in front of the DID. Just curious, is there a more common way to format what CUCM sets in the Diversion header?

regards,

Fabian