I've got an issue with endpoints registered to VCS-E trying to merge CUCM endpoints into a multiway conference via a traversal zone.
Set up (noting that there were more VCS's in the path, but I've elimitated
Endpoints + Conductor + TP server are registered to VCS-E VCS-E connects to other organization's VCS-C via SIP traversal zone VCS-C connects to CUCM via neighbour zone
VCS-C neighbour zone and CUCM SIP trunk security profile + SIP profile on the trunk configured as per VCS to CUCM deployment guide (including Multiway section)
So the call path is EX90 > VCS-E > traversal zone > VCS-C > CUCM > EX90. SIP the whole way, no interworking.
All endpoints can call each other and can manually dial the multiway alias. In addition, if we register and endpoint to the VCS-C, we get multiway working via the traversal zone.
However, when we try and "Merge" a CUCM endpoint into the multiway conference, the call fails. The VCS-C never recieves a search, so I assume the CUCM either doesn't recognize the request or isn't allowing it.
VCS-C + E are 7.2, CUCM is 8.6.2.
I haven't bothered with Conductor/TP server versions as the CUCM endpoints don't appear to be even attempting to call - so we haven't even reached that point by the time the call has failed.
Thanks for the advice, but I've got issues with that...
We can't use a SIP route pattern, because the VCS's are part of a route group, so CUCM won't allow us to use the VCS as a target for the SIP route pattern.
Currently, I've got my VCS trunked to another CUCM 8.6.2 and it's working, despite only having an E164 is the multiway alias and a numeric route pattern, then I've got a transofrm on VCS. This shows me that it can indeed work between CUCM and VCS with just a numeric aliad - It just doesn't work on this other CUCM for some reason. The only difference that I can see is that the working CUCM cluster is connected directly via a neighbour zone instead of a traversal zone (although as previously stated, this configuration works via the same traversal zone if the endpoint is registered to VCS-C).
So here's what we have that's working: CUCM > Neighbour zone > VCS-E > endpoints with multiway alias. We aren't using conference factory, we are using Conductor. Multiway alias is just a numeric dial string (no @) then we use a transform on VCS to change it to a valid SIP URI. This works fine and we just use standard route patterns on CUCM (not a SIP route pattern, for the reasons stated above).
We then have a traversal zone from the same VCS-E to a different organisation's VCS-C, who then have a neighbour zone to their own CUCM 8.6.2. Multiway initiated from my end works to their VCS-C endpoints but not to their CUCM endpoints. SIP trunk, profile, security profile on their CUCM are configured the same as my trunks that are working. We can't use a neighbour zone because they are on a different network and need firewall traversal.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...