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.

Symptoms:

::::::::::::::::::::::::::::::

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.

Solution:

:::::::::::::::::::::::::

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: 10.86.24.90:5061, 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@127.0.0.1>

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

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

Jan  8 13:56:39.528 a8 appl[1592]: 1749764.54 SipPacket   Referred-By: <sip:812000@voiceinitiate.com>

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

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: 10.86.24.90

3)       The SX20 tell the VCS to refer the call to ‘ Refer-To: cid:3ac0bec2e9862d4b@127.0.0.1’; 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@127.0.0.1 is not the same thing as Refer-To: multiway@voiceinitiate.com 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: 10.86.24.90:5061, 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