Showing results for 
Search instead for 
Did you mean: 

Call treatment based on the P-Asserted or Remote Party Id fields in the SIP messages

In CUBE is it possible to apply a call treatment based on the P-Asserted or Remote Party Id fields in the SIP messages ?

For example I can use a Dial-Peer to match an URI or Destination-pattern and do a call treatment that would prefix digits or send to a specific Ip adress.
I want to do exactly the same type of call treatments but not based on the Called number, based the transfered to number (P-Asserted or Remote Party Id fields)

What I need to do:

Let say I have an Ip phone DN 1111 that wants to transfer a call coming from the PSTN to extension 2222
The P-Asserted and remote party ID fields gets populated with the transfered to number (ex: sip:2222@ 
I would want the following call treatment:
When P-Asserted ID field has the DN 2222 (ex: sip:2222@ prefix the number 99 and send to

I could easily do that with a dial peer matching destinatio-pattern
It would like this:

Dial peer voice 111 voip
Destination-pattern 2222
translation-profile (to prefix the digits)
Session protocol sipv2
Session target ipv4

How can I do the same but not matching the dialed number destination-pattern but matching the number in P-Asserted or Remote Party Id fields ? 

Any input would help


10 Replies 10

Mohammed al Baqari
VIP Advisor VIP Advisor
VIP Advisor



The only way I can think about is using TCL script associated with inbound dialpeer. The script should read PAI header or Remote ID header and perform signalling. 


One point to mention that the forward to number will be listed in Diversion header. Remote party id or PAI is used for caller ID display. 





I havent played much with TCL scripts, I will try to in my lab this weekend and let you know. Do you have any input on the script to put me on the right path?


Thank you

Jaime Valencia
Hall of Fame Cisco Employee Hall of Fame Cisco Employee
Hall of Fame Cisco Employee

Depending on your IOS version, there have been several new enhancements for dial-peer matching based on the SIP headers, not sure if one of them might be useful for you



if this helps, please rate

I heard of those enhancements using improve sip profiles. I will have a look at the doc.


Thank you

Nadeem Ahmed
Cisco Employee
Cisco Employee

AFAIK, I don't think we can achieve this using PAI value & RPID to route the call as Dial-peer can be used using following parameter

config-dial-peer)#destination ?
  calling           Match destination calling number
  dpg               Configure voice class dpg
  e164-pattern-map  Configure voice class to match destination e164-pattern-map
  provision-policy  Configure voice class dial-peer provision-policy
  uri               Configure voice class to match destination URI


however even if i see to do some manipulation using sip-profile that would be done only manipulating the headers not for routing.

But this is kind of interesting one.




Br, Nadeem Please rate all useful post.

Actually I beleive Jaime and Mohammed might have put me on the right track because of this:


1. Mohammed is right, call being transfered populates the Diversion header, so I need to find a may to match based on diversion field


2. Jaime's document states that in the newer IOS your dial peer can match a URI. The Diversion  of an incoming call leg can be used for outbound dial-peer matching via this command; destination uri-diversion. Link to info:


Now in theory I only have one issue left, my diversion field doesnt get populated. My * transfer to * number populates the P Asserted and Remote party id fields when I should see it in the diversion header.


Does someone has any idea on what setting to play with in CUCM so that my Diversion field gets populated when I initiate a call transfer ??


Thank you all




In your SIP trunk in cucm make sure that 'Redirecting Diversion Header Delivery - Outbound' is ENABLED

Ok thank you, i think I have all the pieces to the puzzle, I will try it in my lab and let you know the results


Thank you


For the benefit of someone facing the same type of challenge, DIVERSION hearders are not used in call transfers. 

Diversion header will be used when the call is diverted before a call request is actually answered by any end point (example: A call forward). For a call transfer scenario, further changes will be send via REFER,UPDATE,RE-INVITE's, etc. 

Diversion header will be added in case of a call diversion scenario before the actual call connect, not involved once the call is connected

We made several tests with Cisco

Hope this helps someone

Sorry I thought this was a call forward. You are right, call forward uses diversion header. Call transfer users replace headers in REFER/UPDATE messages.



Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers