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

[Telephony Analyst]

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@192.168.1.1) 
I would want the following call treatment:
When P-Asserted ID field has the DN 2222 (ex: sip:2222@192.168.1.1) prefix the number 99 and send to 192.168.5.1

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 192.168.5.1

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

Thanks

[Mohammed al Baqari]

Hi,

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. 

[Telephony Analyst]

Ok

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]

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

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.html

[Telephony Analyst]

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

Thank you

[Nadeem Ahmed]

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

[Telephony Analyst]

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:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/inbound-hdr-for-outbound.html

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

[Mohammed al Baqari]

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

[Telephony Analyst]

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

[Telephony Analyst]

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

[Mohammed al Baqari]

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.