cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5942
Views
177
Helpful
60
Replies

TC7.1 is now released and available on Cisco.com

Magnus Ohm
Cisco Employee
Cisco Employee

I am pleased to announce that TC7.1.0 is released and can be downloaded on http://www.cisco.com.

Please read the release notes:
http://www.cisco.com/en/US/docs/telepresence/endpoint/software/tc7/release_notes/tc-software-release-notes-tc7.pdf

Regards,
Magnus Ohm

60 Replies 60

Hi Magnus

Is there the ability to establish a continuous ping from the API?

This proved a very useful tool when attempting to establish where a problem was with relation to an endpoint on a network.

such as setting up a continuous ping to its default gateway and a second continuous ping to a remote site, helped to establish where intermittent disconnections was occurring.

I wonder, is it still possible to perform the TFTP software recovery on a codec? (A very useful tool) or at this stage will we be restricted to RMA only as the option?

Think with Portals

Hi David

If you meet such scenarios then you would have to enable the remotesupport user in order to do the continuous ping. The ping feature in the xAPI is just for verification of connectivity and is not continuous.

Yes it is still possible for the c-series, but for the new ones I have not tested. I will check it out. 

/Magnus

Kjetil Ree
Cisco Employee
Cisco Employee

Hi Magnus,

The Interoperability section of the Release Notes does not mention VCS 8.1 as a tested H.323 gatekeeper, or UCM 10.x as a tested SIP registrar. Are these call control devices supported with TC 7.1?

 

cheeky Kjetil

Yes Kjetil they are.

I will take a look at it and update the release notes.

/Magnus

Luis Campos
Cisco Employee
Cisco Employee

Hi, 

Also is good to mention that version TC7.0.1 has a deferral notice. Try to avoid this version due to different issues on it. 

Here is the deferred information:

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/endpoint/software/tc7/release_notes/cisco-tc701-deferral-notice.pdf. 

 

Regards, 

Luis C.

Danny Meyer
Level 4
Level 4

Magnus.

Very surprised about the artificial limitation in the SX80 reg. SIP/H323 dual reg. This codec is a very versatile unit and will be used by many of us for advanced setups, like the C90 before. And sometimes that dual reg was very helpful in challenging situations.

Regards

Danny

Hi Danny

There are some reasons for disabling dual registration. Going forward SIP will be the preferred call protocol for Cisco and H323 will slowly be phased out. This will be even more visible going forward. We do recommend all customers to start transitioning from H323 to SIP. Coming products will possibly not support H323 at all. Already we have SX10 released which does not support H323.  

Allowing only one call protocol at the time simplifies both the endpoint logic, reduces the test matrix and the amount of possible bugs. While dual reg may be useful in some situations Cisco recommends to standardise on SIP only, and any interworking calls (H323-SIP) should go via the VCS. H323-only endpoints should eventually be phased out. By supporting both H323 and SIP, we believe SX80 will be a versatile codec both today and in the future.

Regards,

Johan

Hi Jrandby

Would you be able to provide me with a better understanding as to why H.323 will be phased out on codec’s (I suspect Cisco are just making the endpoints more CUCM centric), I have already been in discussions with a sales person about proposing the sx10 as a solution to a client and the fact the sx10 only supports SIP is a bit of a sticking point. Not so sure this is a wise idea given certain markets out there

Think with Portals

Hi

H323 will continue to live for many years, but there is as far as I know little or no development at all on H323. New features are only made for SIP, and I think most vendors agree that SIP is the future rather than H323. 

As you point out, the fact that CUCM is not supporting H323 and CUCM is the preferred call control for TelePresence endpoints going forward is also playing a role here. It should not be a problem to use H323 for years (by using a VCS for interworking), but new endpoints and features will probably not be supported on H323. I think the stakeholders know that launching a non-H323 endpoint is a risk, but if we want our customers to transition to SIP this is a logic step to take.

-Johan

You've made the H.323 people at the IT-U very very sad :)

I can see h.323 becoming like H.320, maybe I will eat my words, I remember saying 8 years ago, ISDN will no longer be around in 2 years time, well 8 years later and we are still using it. From my perspective not supporting dual registrations misses out on a large portion of the market, this is afterall how ISDN is still lingering as there are clients out there that choose to use it for various reasons, will H.323 be the same I wonder. I'm going to miss H.323 its been good to us :)

 

I remember Tandberg made this decision a few years back with their E20 which only supported SIP in the first instance, I know for certain that there was sales missed due to that, maybe that was a tad too early for that decision, I wonder are we seeing the same again?

Another concern for me with the restriction to SIP (although in the long term probably the best idea, and for larger deployments in corporate systems this makes absolute sense) is that in the lowest price point where the clients which have the least money will consider, I would suggest supporting dual registrations would be the better idea as these clients would not have the finance to invest in the additional infrastructure to support the unit, just peaking from personal experience there, hopefully Cisco will find this feedback useful (and in all fairness this is my only concern about missing H.323).

Think with Portals

"I can see h.323 becoming like H.320, maybe I will eat my words, I remember saying 8 years ago, ISDN will no longer be around in 2 years time, well 8 years later and we are still using it"

H.320 still provides a specific purpose tho - it does not have a direct replacement in the same application like H.323 to SIP does.  Some of the H.320 baggage is also what kept H.323 complex and 'fat' and what drove many adopters to SIP.

 

"I remember Tandberg made this decision a few years back with their E20 which only supported SIP in the first instance, I know for certain that there was sales missed due to that, maybe that was a tad too early for that decision, I wonder are we seeing the same again?"

The choice behind SIP only for the E20 was for different reasons.  The E20 was designed to be a PBX handset.. that also did video.  Not a video-conferencing endpoint.  It's target market was SIP PBXs and to be a very streamlined, low cost system.  The reasoning for not doing H.323 now is more about legacy and complexity.

"The choice behind SIP only for the E20 was for different reasons.  The E20 was designed to be a PBX handset.. that also did video.  Not a video-conferencing endpoint.  It's target market was SIP PBXs and to be a very streamlined, low cost system.  The reasoning for not doing H.323 now is more about legacy and complexity."

This is mad considering that H.323 was a standard created and administered by a telephonic body for a telephonic community, yet SIP is simply a protocol defined by a bunch of RFCs of which adopters can decide to implement or not depending on which way the wind is blowing on that particular day.

"This is mad considering that H.323 was a standard created and administered by a telephonic body for a telephonic community, yet SIP is simply a protocol defined by a bunch of RFCs of which adopters can decide to implement or not depending on which way the wind is blowing on that particular day"

 

H.323 is not as strict as the common slam against SIP would make you believe.  Early on there was a lot of ambiguity in SIP that is basically behind us now as implementations have matured.  H.323 suffers alot from it's H.320 heritage in complexity and is in part what drove people to SIP who did not come from the traditional H.320 world.

As dishearting as some may see it considering H.323 came from ITU... it never had the success in voice that SIP had even from the early days.

Fascinating, maybe my view on SIP is biased due to the early days of the adaption in the VC world, I wonder, if SIP is becoming more common between manufacturers would there be a benefit from an ITU standard wrap around?.

I wonder if there are any plans within the VC world outside of call manager to simplify a SIP dialling pattern without the need for complicated transforms and Enum DNS setups, outside of CUCM that is.

Commonly SIP in the VC world has always (as I have known it) been URI based, which is a bit of a pain in the proverbial when dialling off an alphanumeric keypad, should I expect to see a revolution in SIP to an extent in the coming years?

I can see the benefits of a URI, but there are also benefits around simple DN dialling. I wonder what the feeling is with the developers which one would best suite the VC world.

Think with Portals
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: