08-14-2015 11:10 AM - edited 03-17-2019 04:00 AM
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
08-14-2015 12:02 PM
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.
08-14-2015 12:18 PM
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
08-14-2015 12:08 PM
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
08-14-2015 12:19 PM
I heard of those enhancements using improve sip profiles. I will have a look at the doc.
Thank you
08-14-2015 12:24 PM
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
08-14-2015 12:39 PM
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
08-14-2015 12:52 PM
In your SIP trunk in cucm make sure that 'Redirecting Diversion Header Delivery - Outbound' is ENABLED
08-14-2015 12:59 PM
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
08-24-2015 01:18 PM
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
08-24-2015 10:27 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide