TMSPE - Adding E.164 dial to provisioned Jabber Users
We maintain several VCS devices that subscribe the the National E.164 dialing scheme via our National Gatekeeper (NOT ENUM lookups). We have may traditional endpoints that use E.164 alias dialing and this all works well.
We are also provisioning certain Jabber user via TMS, but unfortunately external inbound SIP URI dialing is not possible for certain users at this time. So, we can assigned E.164 numbers, then manipulate the number to dial the internal SIP URI.
As stated we DO NOT use ENUM, but rather have achieved this in two ways.
We have used Dial Plan -- > Transform on the local VCS to manipulate the E.164 to be replaced with the user's SIP URI
After reading the "Cisco TelePresenceManagement Suite Provisioning Extension Deployment Guide for Cisco TMSPE 1.0 with Cisco TMS 14.1 and Cisco VCS X7.1, X7.2", in the section "Sending and returning calls via ISDN gateways" (yeah, we are NOT using ISDN, but the principle is the same), and "Using FindMe to convert E.164 numbers to FindMe IDs", I have set up secondary FindMe account to forward calls to a E.164 number, to a user real provisioned user's account ID.
Ok, so if I have achived what I want, why the question.
We neither is particularly elegant and requires a lot of manual manipulation, such as manually adding a transform or manually adding separate FindMe accounts, then setting up dialing preferences. Ideally, I would like to use just TMS PE to achieve this, but is there any way this this can be automated?
Ideally, I would like to see an E.164 field avaliable to provisioned users that can be used as lookup instead of having to add a seperat fake FindME account - Feature Request.
jabber is only a SIP client soft-endpoint hence you don't see E.164 or H.323 fields in provisioning template. Have you considered using CPL to manipulate all your requirement in one single script. It may not be very intuitive to work with initially but the format/structure is realized, you can manage all your aliases from that script. Also external policy server such as Conductor is a great tool to do all required call policy settings and manipulation.
As mentioned previously in my previous article and following the same idea of certificate pinning in Cisco Meeting Server, to demonstrate this concept added since version 3.0. I used two different CA to sign :1-The WebBridge certificate with CA's certific...
Certificate pinning is introduced on cisco meeting server starting in CMS 3.0 to help prevent man in the middle attack.But what is the Certificate Pinning?Traditionally, SSL Handshake consists on the validation of the server's certificate, let's say colla...
In a Clustering over the WAN deployment, securing the ICCS (Intra-Cluster Communication Signaling) traversing the WAN can be a requirement. The IPSEC VPN Policy between nodes can be configured to secure the ICCS Traffic.To quickly verify that the IPSEC is...
Attracted by the concept of dial plan and the passion of writing, I launched a challenge to write a workbook with practical scenarios covering in details this concept, the result is a workbook with 30 practice labs treating many components such route patt...