cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
920
Views
0
Helpful
3
Replies

CURRI divert - how to show the original called number

stephan.steiner
Spotlight
Spotlight

When sending a <divert> in CURRI, is there a way I can get the original called destination shown on the final destination? Sorta like you can see when X calls A and A has an immediate forward on B, B sees that the callee is X, and that the call was originally meant for A.

3 Replies 3

dstaudt
Cisco Employee
Cisco Employee

It looks like you should be able to manipulate the called/calling numbers, etc. using the parameters described here, e.g. <modify calledNumber>: https://developer.cisco.com/site/curri/documents/latest-version/cixml_parameter.html

But shouldn't this be done implicitly? afaik when you deflect in JTAPI, you have both the original called and current called info (number, name). Even if I manage to modify the calling number / name, there's one name. There's no information about for whom the call was originally meant.

As for the modify tag, it's rather limited and doesn't always work as expected. See devnet support case 2088. Basically with Jabber Clients and defined DirectoryURIs, you can modify all day long and Jabber will still show the unmodified information (it works for hardphones though). Plus, you'd have to modify the called name. In the above sample calledName should be "X - redirected for B". Which certainly would present differently in jabber and devices than if X called A and A has an immediate FWD to B.

by the way, this works in UC14 and was just backported to 12.5SU6.

The trick is to also set the 'reason' for a divert in the cixml. the diversion info is included if the reason is one of the following: user-busy, no-answer, unconditional, out-of-service. the diversion info is NOT included for reasons: unknown, deflection, follow-me, do-not-disturb, unavailable, away.

 

Still trying to figure out if there's more to these reasons.. my software is using 'deflection' to not get the diversion info, and 'unconditional' to get the diversion info and this seems to be working just fine on 12.5SU6.

 

P.S. the documentation may not have been updated yet. diversion supports the 3 attributes: destination, item and reason concurrently (the doc said 'one out of' when I last checked).