Category: Video and Telepresence

A look at the use of database dips, custom Java codes, Cisco Contact Centre Express and Cisco Finesse for the improvement of day to day processes and quality of Life. This video was born out of contemplations surrounding what life would entail without the mundane things we spend our time on. Watching A-Level students collecting their certificates /exam results was the final stimuli that prompted this publication.

. .. I hope this Video triggers contemplation.
Thanks for Viewing
Kind Regards


[]  The rise of Video conferencing as a preferred means of collaboration advocates for continuous  conversations on the issue of security. This entry seeks to contribute to that discussion.

Hope you find this useful.



Hint: Somewhere around 19 min into the recording I mentioned ‘server signing authority’ instead of ‘Certificate signing authority’.  Please process the information accordingly.

The promise of Mobile and remote access technology is that , using the Expressway-C and E servers, external devices are able to register to the corporate network  and  gain access to services  which are located within the corporate LAN without need for a VPN.  Internal services like voice-mail, directory, audio- video calls, on-premises instant message and presence information become transparently and seamlessly available to a mobile and remote devices as they move in and out of the network with no extra user education or involvement.

In the first half this video demonstration, I will:

i) Walk through what we already have configured on the corporate LAN.

In the second half, :

i) I will first of all install the Expressway-C and establish communication between Expressway-C with the internal servers like CUCM and IM&P.

ii) Then the expressway-C  is  connected to the Expressway-E via a traversal zone. The Expressway-E sits in the DMZ. The traversal zone is the link between the internal and external network.

iii) Finally, a jabber client is registered to the network via the Expressway-E. The jabber client is able to access internal services through the aid of the traversal zone that exist between the Expressway-E server that is  on the outside or DMZ of the network  and the Expressway-C server which is inside the network. .



Hint: As long as you are running a TC software that is from version 6.1 and above, you definitely have to make this change.

Hint: This work-around will not solve all call merge issues as a lot of call merge issues are ‘timer’ related. This solution is for Bug :  CSCug95623

Hint: I have also seen this error in the logs taken from endpoints that have their Ethernet settings set to auto instead of full.

Today I will be sharing a case I recently worked on  that involved several SX20 codecs, Cisco Video Communication servers and one Multipoint Control Unite (MCU). The problem was that  calls were failing to merge . As Network Professionals we know that a number of things can cause video conference calls to fail so what I’m going to do today is to first of all talk about the symptoms of this case  before talking about the solution. After talking about the solution, I will discuss how to identify this problem when looking at the logs.



1)     A caller calls another video endpoint and then calls a third endpoint/person while the other caller is placed on hold.

2)     The conference initiator presses the merge button in an attempt to merge all three participants into one call. Normally, what happens in the background when a conference initiator presses the merge button is that all participants get redirected to the Conference Bridge (simplified explanation) or Multipoint Control Unit (MCU).

3)     However, on this occasion, the initiator simply saw a message saying ‘merge failed’ and the person that  was placed on hold before; remained on hold.  Please take note of the symptom that I have just explained because it is really crucial to knowing where the fault is.  Let me explain further: A few weeks ago I worked on another case where endpoints could not initiate a video conference (MCU conference). On that occasion, when the conference initiator pressed the merge button and everyone got redirected to the MCU; a ‘merge failed’ message was displayed and everyone got disconnected and no one remained on hold. This  failure was due to an incompatible sip timer issue between the endpoints and the MCU. But in this case that I am talking about in this blog, I noticed that the call remained on hold. Does this not make you think that the call was never redirected to the MCU because the first caller never left its ‘hold’ state that it was placed in before the call merge attempt? If you did not get that question, after reading the rest of this blog, please come back to this question and it will make sense. It is very important and in everyone’s benefit that anyone interested in this post is able to answer this question.



Let me now provide the solution. The solution is to change the Sip profile of the Video endpoint from ‘ Cisco’ to ‘ Standard’.

1)     Log into the Video endpoint (eg SX20),  click the ‘ configuration’  menu

2)     Select ‘ system configuration’

3)     Select ‘ SIP’

4)     Select ‘standard’ as the ‘ Type’ instead of ‘ Cisco’ Standard Log analysis and detailed explanation:


As I mentioned before, when a conference initiator presses the merge button, a request is sent to the Video communication server with the multiway address as the destination. The video communication server understands that this is  conference request so   the video communication server checks the ‘conference factory’ configuration and responds back by sending back an address for which all conference participants  should  re-converge at. This address will be an address on the Multipoint Control Unit (MCU). The summary of the logs below shows  that  the  conference-initiating-endpoint  sends as  an incorrect multiway address to the VCS  even though the multiway address is configured correctly on the endpoint. So in response, the VCS basically comes back and tells the endpoint that it does not know that address so the call (merge) fails. These logs were taken from an SX20

Here is what the problem looks like in the logs

Jan  8 13:56:39.483 a8 appl[1592]: 1749764.49 MainEvents I: GenericTransferEvent() ‘MultiwayStarted

Jan  8 13:56:39.509 a8 appl[1592]: 1749764.52 SipPacket I: PacketDump: Proto: SIP, Direction: Outgoing, Name: REFER, CSeq: 101 REFER, RemoteAddress:, CallId: 55c9039b4884ec8f0c834997b05cfa10,Time: 1749764517 Jan  8 13:56:39.520 a8 appl[1592]: 1749764.53 SipPacket   Call-ID: 55c9039b4884ec8f0c834997b05cfa10

Jan  8 13:56:39.520 a8 appl[1592]: 1749764.53 SipPacket   CSeq: 101 REFER Jan  8 13:56:39.525 a8 appl[1592]: 1749764.53 SipPacket   Content-Id: <3ac0bec2e9862d4b@>

Jan  8 13:56:39.527 a8 appl[1592]: 1749764.54 SipPacket   Contact: <;gr=urn:uuid:00000000-0000-0000-0000-d867d97810fa>

Jan  8 13:56:39.528 a8 appl[1592]: 1749764.54 SipPacket   Refer-To: <cid:3ac0bec2e9862d4b@>

Jan  8 13:56:39.528 a8 appl[1592]: 1749764.54 SipPacket   Referred-By: <>

Jan  8 13:56:39.534 a8 appl[1592]: 1749764.54 SipPacket   From: <>;tag=c280f01b2b95aae4 Jan  8 13:56:39.535 a8 appl[1592]: 1749764.54 SipPacket   To: <sip:124758@>

Jan  8 13:56:39.535 a8 appl[1592]: 1749764.54 SipPacket   Max-Forwards: 70 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

so here is the explanation for the logs shown above:

1)Because the user pressed the merge button, the SX20 endpoint tries to transfer the call to the MCU so it ‘Refers’ the call to the MCU

2)       by sending a refer message to the VCS at Ip address:

3)       The SX20 tell the VCS to refer the call to ‘ Refer-To: cid:3ac0bec2e9862d4b@’; which is basically an incorrect  address. Notice that the ip address of the refer url is actually a loopback address which is not the ip address of the MCU ? So basically the endpoint it trying to refer the call to itself when it does not have multisite capabilities. Even though it needs the MCU to host the conference, the SX20 actually tries to host the call. . A refer to  :3ac0bec2e9862d4b@ is not the same thing as Refer-To: so it fails.

4)       See the logs  below for the response that the Video communication server sent back to the SX20 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

The VCS responds back basically saying ‘ I don’t know that address’ : We know this because we see can see  a 400 message in the logs.  A 400 message means that the requester sent a bad request with a malformed syntax.


a8 appl[1592]: 1749764.68 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 400 (Refer-To) Unknown SIP URL prefix, CSeq: 101 REFER, RemoteAddress:, CallId: 55c9039b4884ec8f0c834997b05cfa10, Time: 1749764678

Jan  8 13:56:39.682 a8 appl[1592]: 1749764.69 SipPacket   SIP/2.0 400 (Refer-To) Unknown SIP URL prefix


As  can be seen in the logs, this is very abnormal behaviour.when I complained about what I was seeing in the logs to  Cisco, I was informed that this was actually bug CSCug95623. As of today, I believe this bug is not officially published yet.   Hope this has been helpful. All the best

If you are visiting for the first time then I would like to say welcome to Voice Initiate. It is a place where experiences are shared and discussed.  As we all know, working in technology is all about being introduced to new things on an almost daily basis. For me, it’s like being in a perpetual state of initiation.

If you are reading this blog then I’m sure you can relate when I say that I came into the IP telephony world not knowing that I would have to learn programming too, but working on Contact Centers dictates  that  you must- so retreat was never an option. . . it’s an endless battle but we love it anyway.

This blog is an account of the joys and challenges faced by a Unified Communications NOC Engineer. This is a  place where both failure and success is discussed openly.

Advice and contributions are always welcomed.  My hope is that this blogs brings a sense of thrill to fellow bloggers and initiates alike and a sense of nostalgia to those that have seen the joys and challenges that we now speak of .


%d bloggers like this: