cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2984
Views
10
Helpful
11
Replies

One way media from Spark Room 55 to C40

Paul Richardson
Level 1
Level 1

Hi,

 

I have a one way video/audio fault at a client site. They have just installed 2 x Spark Room 55 Kits running CE9.2.1 and a SX20 on TC 7.3.9 at a new site. Calls from the Spark endpoints to a C40 on TC 7.1.4 at another site have no incoming audio/video at the C40. Calls from the SX20 are fine. Calls originated from the C40 to the Spark units are also OK. To check if it was a firewall issue at the new site, we also placed calls from a Spark Room 55 at a third site to the C40 and get the same result. Incoming calls to the C40 have no audio/video, but outgoing calls to the Spark unit are fine.

 

Incoming and outgoing calls from the C40 to any other of their 50+ endpoints at multiple sites are fine. I have checked the RTP port range is the same on the Spark endpoints as the SX20.

 

All these endpoints are registered using SIP to a VCS Control cluster.

 

Any ideas would be appreciated.

 

Cheers, Paul R.

1 Accepted Solution

Accepted Solutions

Hi Justin,

In my above post, I've mentioned the Bug-ID you can relate to :CSCvd33159 (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd33159/?rfs=iqvred)

 @Paul Richardson, for workaround till you upgrade, can try below other than setting Encryption option to Best-Effort:

-> Add a Capset Filter: "AEAD_AES_128_GCM;AEAD_AES_256_GCM" into the CapsetFilter on the CE endpoint to filter out the unsupported encryption.

 

Hope it helps !

Regards,

Rishabh Gupta

View solution in original post

11 Replies 11

Does the C40 and/or Spark Room 55 have dual registration?  I'm wondering if the call is interworked one way but not the other (ignore if it's all SIP).

Try making sure that it's SIP the whole way in both directions.  In addition, try upgrading the C40 to TC7.3.12.  TC7.1.4 is very old and way past end-of-life, it wouldn't have been tested with the newer units.

Hi Nick,

 

The call is SIP from end to end with no interworking.  Regarding upgrading the C40, I agree it needs to be upgraded, but as the room and codec are AMX controlled, our AMX provider will have to check the code at that site to ensure that it is compatible with the APIs in TC7.3.12 prior to any upgrade.

 

Cheers, Paul R.

I've gone from TC6 to TC7.3 on AMX controlled C-Series without issue before - I'd suggest upgrading and you can just roll back if you have any problems.  Codecs need updates just like PCs!

Rishabh Gupta
Cisco Employee
Cisco Employee

HI Paul,

 

I understand that, it is only the outgoing SIP calls from Spark Room 55 units to the C40 codecs which has media issues while Firewall has already been ruled out.

 

I guess, you would have configured the endpoints for Encryption ON.

So it seems , this is hitting following defect : CSCvd33159 (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd33159/?rfs=iqvred)

 

FYI, there are issues between CE8.3.3 ( or higher)  and TC7.3.4 or lower is because of the encryption method that is used.

CE8.3.3 offers AES-256 & AES-128 and even though they negotiate AES-128, the media isn't able to be decrypted on one side; same can be verified by log snippets as well.

 

You should go ahead and upgrade the C40 unit to TC 7.3.4 or above, (would recommend TC 7.3.12) to fix this. You can download it from here : 

https://software.cisco.com/download/release.html?mdfid=283613657&flowid=&softwareid=280886992&release=TC7.3.12&relind=AVAILABLE&rellifecycle=&reltype=latest

 

Until you upgrade, as a workaround, you can keep the Encryption setting on Best-Effort.

 

Please rate the response and mark as solution, if it helps.

 

Thanks & Ragards,

Rishabh Gupta

 

 

 

 

 

Rishabh,

How does upgrading the TC endpoint resolve the issue?  I looked thru the release notes for TC7.x and I don't see anything related to AES-256; do you have a bug?

Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

Hi Justin,

In my above post, I've mentioned the Bug-ID you can relate to :CSCvd33159 (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd33159/?rfs=iqvred)

 @Paul Richardson, for workaround till you upgrade, can try below other than setting Encryption option to Best-Effort:

-> Add a Capset Filter: "AEAD_AES_128_GCM;AEAD_AES_256_GCM" into the CapsetFilter on the CE endpoint to filter out the unsupported encryption.

 

Hope it helps !

Regards,

Rishabh Gupta

Rishabh,
The bug you listed only references the E20 which runs TE software, totally different from TC software....
You still haven't clarified how upgrading TC software will resolve the issue. I don't see any bugs or any information in the release notes about TC endpoints having issues with AES-256.
Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

Hi Justin,
Understand that the defect talks just about the E20, which needs bit of documentation corrections and addition to release notes; but I have came across this issue with same symptoms on TC software as well.
FYI, there are issues between CE8.3.3 ( or higher) and TC7.3.4 or lower is because of the encryption method that is used.
CE8.3.3 offers AES-256 & AES-128 and even though they negotiate AES-128, the media isn't able to be decrypted on one side; same can be verified by log snippets as well.
See below :
From a C90’s logs (TC 7.1.4):
Mar 15 13:43:23.673 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_128_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.675 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_256_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.676 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_128_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.677 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_256_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.678 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_128_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.679 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_256_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.680 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_128_GCM", defaulting to AES_CM_128_HMAC_SHA1_80
Mar 15 13:43:23.680 a8 eventlog[1582]: SIPMEDIA_MD_getCryptoParams: Unknown crypto profile "AEAD_AES_256_GCM", defaulting to AES_CM_128_HMAC_SHA1_80

=>Post upgrade, this worked fine as the interop issues are taken care.
Hope it clarifies.
-Rishabh

Rishabh,
Thank you for the information, this looks good!
Thank you,
Justin Ferello
Technical Support Specialist, ScanSource KBZ

Hi Rishabh,

 

It is the bug that you pointed out.  You may wish to note that even with encryption as Best Efforts it still attempts the negotiation and we end up with one way media.

 

Setting encryption to Off does allow media in both directions.  Now to convince the client to upgrade the C40s at this site. :)

 

Cheers, Paul R.

PJMack
Level 7
Level 7

Paul, since you're understandably reluctant to upgrade the C40 until you get verification that it won't break your AMX integration, here's an idea for you - downgrade the SX20 to 7.1.4 and try it. If that has the same problem then you know for sure it's the code that's the issue. 

 

That said - Cisco (and Tandberg before) have always made a strong effort to endure backwards compatibility with the TC code API, I'd be very surprised if upgrading your C40 caused any problems with the AMX integration.