02-08-2012 11:32 AM - edited 03-17-2019 10:48 PM
Hello,
In the following setup
MSE 8710 (TelePresence Server 2.2(1.43)) <--------- SIP -----> VCS (x5.2) <------ SIP-----> CUCM 7.0.2 <------SIP-----> CUCM 8.5.1 <-----------> CTS 1.7.2
While hosting calls on the TelePresence Server to CTS endpoints, the call is immediately disconnected upon connection, with the following log messages on the MSE
Far end sent media when expecting TIP negotiation
Endpoint XXXX has abandoned TIP/MUX negotiation
Endpoint XXXX has been disconnected because TIP negotiation failed
Kindly, help what could cause TIP negotiation to fail and the possible resolution?
02-09-2012 01:51 AM
Have you preconfigured that particular CTS in the endpoints section of the TS web interface? Those log messages would suggest that you have, but it is good to check this.
I think the best way to approach this would be to get a SIP log from the TS of the CTS dialling in and the call failing; and also a similar log from the CTS. Check that there are no bandwidth limitations applied in the network between the two - i.e. that the bandwidth advertised in the SIP invite sent by the CTS is the same as what is received by the TS, and also the 200 OK in the other direction. Also check that no video codecs are being removed.
02-09-2012 02:30 PM
Hi Luc,
Yes the CTS is preconfigured as a Cisco LEgacy CTS endpoint.
I think the TPS anticipates TIP negotiation, but the CTS doesn't negotiate TIP and starts sending RTP instead indicated by the log that the far end sent media when expecting TIP negotiation.
One more observation is that, once you add a CTS endpoint, it is added as Cisco TelePresence System. After the first time TIP neogtiation, the TPS is able to detect whether it is a single screen (e.g CTS 500, CTS1000) on three screen system (CTS 3xxx) and the added endpoint reflects that from thereon. BUt, here it only shows Cisco TelePresence System.
There is no bandwidth restriction in the network.
02-10-2012 02:12 PM
Yes, the fact that it does not detect the system type is a result of TIP negotiation to happening. The best thing that you can do is to take SIP traces from both ends, and make sure that video capabilities are being advertised at both ends - it could be that the SDP is being altered somewhere, or alternatively it could be the IP phone that is initiating/answering the call rather than the CTS codec, which can cause something like this to happen.
Without seeing the SIP traces it is difficult to comment further.
02-09-2012 01:38 PM
I would take the CUCM 7 out of the path. Can you set up a trunk from the CUCM 8.5 to the VCS and try again?
Sent from Cisco Technical Support iPad App
02-09-2012 02:35 PM
Hi jmunoz,
It is not possible to remove CUCM 7 out of the path as the two CUCMs are for different organisations. Besides, the CUCM 7 has several other SIP trunks to oter CUCM 7.x.x and CTS 1.6.x that work fine.
I'as checking some of the documentations available and found this
We recommend that you install and assign the Cisco Unified CM "vcs-interop" SIP Normalization script to make calls between CTS endpoints and endpoints and devices registered to VCS. Cisco Unified CM 8.5 and CTS 1.7.x do not support the Binary Flow Control Protocol (BFCP). Alternatively, you can turn off BFCP. Caveat that tracks this issue: CSCtn79239.Refer to the CTS 1.7.x release notes for more information:
http://www.cisco.com/en/US/docs/telepresence/interop/endpoint_interop.html#wp115848
Not sure if it is failing because of the bug
CSCtn79239
02-09-2012 09:05 PM
Are you certain the trunk between the two CUCMs is a SIP trunk and not an "Intercluster Trunk" that traditionally were used?
02-09-2012 11:16 PM
Yes it is a SIP trunk and not inter cluster trunk.
02-12-2012 11:15 AM
I would have to agree with jmunoz19, as I think the problem is that 7.0.2 CUCM in the path.
As you make mention of a document in your earler post, you will notice that all of the references are to 8.x releases.
Furthermore, if you look at the TP 1.7 compatibility matrix found here, you'll see that the oldest version of CUCM that is on the 1.7 list is CUCM 7.1.3bSU2, also known as 7.1.3.32900-4.
Having done quite a bit of testing well year ago with the 8710, VCS and CUCM, I know that there are many changes to the CUCM SIP stack in the 8.x (specifically 8.5 and later) that allow the CTS and CUCM platforms to better communicate with ex-Tandberg devices, specifically CTS calls into/out of 8710.
Additionally, is it possible to upgrade the VCS in the path to a more recent version?
To accurately troubleshoot this issue, you should collect wireshark SIP traces from each of the B2BUA (VCS/CUCM) in the path in addition to SIP traces from the 8710 and CTS units.
But I will strongly suggest that after expending significant time and effort collecting all the call traces and submitting TAC cases and going through troubleshooting, you are very likely to determine that due to some missing/poorly implemented/broken part of the CUCM 7.0.2 SIP stack, this call will never work the way you want it to.
02-24-2012 02:03 AM
Thanks Michael.
The issue was resolved by setting the "DTMF Signaling Method" on the SIP trunk configuations on both the 7.02 and 8.5.x CUCM to "RFC 2833"
For some reasons, the SIP logs showed and immediate BYE, after DTMF negotiations. The SDP from VCS, didn't have any video capabilities to the CTS.
We have seen this earlier with similar setup, for CTMS calls, where dial-in and dial-out from CTMS worked only when the DTMF signaling method was set to "OOB and RFC 2833". Since, the SIP logs had similar indications here, we tried a combination of the three DTMF signaling methods available here, and it worked when both the CUCMs had it set to "RFC 2833".
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide