p.s just wanted to update here that routing using destination uri-to matching will be available starting IOS 15.4.1T or IOS-XE 3.11. Exactly what we need!: p1-CUBE-POD1(config)#dial-peer voice 1 voip p1-CUBE-POD1(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   route-string      Match destination route-string   uri               Configure voice class to match destination URI   uri-diversion     voice class uri to match sip diversion header   uri-from          voice class uri to match sip from header   uri-referred-by   voice class uri to match sip referred-by header   uri-to            voice class uri to match sip to header   uri-via           voice class uri to match sip via header p1-CUBE-POD1(config-dial-peer)#destination uri p1-CUBE-POD1(config-dial-peer)#destination uri-to ... View more

Hi Jonathan, Thanks a lot, the world makes sense now I tested that but as far as I can see, the destination URI does not work on the incoming dial-peer selection....but ill test more extensively later. On another note on the same tangent destination uri looks a bit useless to me. Reason: most deployments I have seen are where the CUBE has address hiding between two separate sip domains. invites from both sides coming with the INVITE header as the CUBE interface. Since its two domains, easiest would have been to match the HOST part of the "TO" field and choose the outbound dial-peer. 2 dialpeers for all outbound connections - simples! not so much: Inbound uri is powerful enough for us to select the "TO" fieldhost  instead of choose the inbound dial-peer. But the destination uri dial-peer on the other hand can only look at the "INVITE" header which is useless since it will always be the CUBE. IF we have to use the user part of the INVITE header, we might as well use the destination-patter. So we are forced to use the destination pattern or some prefix from CUCM to have simpler dial-peers... Or is would you know of a better way to do this? Thanks! ... View more

Many thanks for the pointers guys! We ended up choosing one of the TAC supported options just for the matter of support etc. Thanks again. Regards, Kamran ... View more