OCS - Latency Requirement to server -- Federation to Cisco CUPS RRS feed

  • Question

  • Hi folks, I have a question on the OCS2007 / LCS2005SP1 latency requirements.

    There might not be much latency limitation between the OCS server (or load balancer) and the MOC clients if it is just IM. I.E., users can be in the US, and Japan while server is in Europe.


    However things may get different if there is a telephony integration through a mediation server in which scenario users use MOC to control the phone on the desk to do click-to-dial…etc function (Remote Call Control). In this scenario, is there a distance limitation (network latency limitation) between the OCS server and the mediation server (such as GETS)? So that the RCC realtime behavior is still acceptable? 


    Another question is on the OCS Federation. I heard that Federation can be done now between OCS and Cisco's Presence server, so that presence information can be exchanged between them. What is the official supported versions to do such cross vendor Federation? In such Federation, besides the IM presence status, will the phone status (that controlled separately in separate PBX systems by OCS and Cisco Presence server respectively) be exchanged as well?


    Many thanks! 


    (Repost from another forum)

    Friday, November 21, 2008 5:43 AM

All replies

  • The latency tolerance of RCC is pretty high since it's not an actual voice stream.  There are no documented guidelines, but it's common to centralize the RCC gateway because even round trip times of a half a second to go around the world and back are tolerable for showing presence or doing other things like sending a transfer command to your phone.


    I haven't heard specifically of federation being done between OCS and CUPS, but theoretically it could work if all the servers in the chain were properly configured.  As long as the SIP traffic can get from the front end server where the user is homed to the CUPS server then there's no reason it shouldn't work.  This works via Edge servers for external users so there's reason to believe that it would work across a federated connection, though I've never seen it and would recommend seeing it in action before you move forward with a similar deployment.

    Friday, November 21, 2008 2:22 PM
  • I just came across this document from Cisco which discusses interdomain federation with CUPS 7.  http://www.cisco.com/en/US/docs/voice_ip_comm/cups/7_0/english/integration_notes/federation/Overview_chapter.html

    Friday, November 21, 2008 4:55 PM
  • Hi Mike,


    Federation between Cisco CUPS and OCS is supported for CUPS 7.0 (not to sure about other versions). There is a slight twist to this though. You will require a Cisco ASA to do a conversion from TLS AES to TLS triple DES for the encryption side of things as CUPS does not support triple DES. In saying that I have heard you can do some stuff on the Microsoft side of the house so it will do AES but this is not a supported configuration as far as I know:-)





    Friday, November 21, 2008 4:59 PM
  • Hi Mike,


    Many thanks for your post. My concern on the latency is based on the fact that hundreds msec latency, potentially multiplied by the number of packets needed to complete an action, would make the RCC experience not practical. We have seen such limitations on other software controlled telephony function. For example in an IP contact centre environment, if the agent desktop (the software running on computer to control the agent's phone) is network-wise too far away to the server then agent would experience funny bahaviors (have to repeat greetings, or double/triple click a button as it seems not responding and in worst case the status is not updated quickly enough so calls are sent to a busy user...etc ).


    Have to say I have not done ultra distant OCS RCC before so I am not sure if it would have similar issues. If you have actually done/seen this in which case the round trip latency from MOC/media GW to server is 300ms+, I will be very happy to hear this confirmed in deployments.


    Thanks again.




    Sunday, November 23, 2008 10:29 PM
  • I have in fact done this.  I don't recall the round trip times offhand, but I'm certain that at least one of them was over 200ms.  Obviously I can't speak for your environment specifically and it's possible that you have different business needs that require ultra-fast response times.  The best advice I can give you is to test it out in your environment to see if it's good enough.  If your business requirements are such that a ~1 second delay of Available/In a Call status updates is too long then you may have to look at a more dispersed architecture.


    Chris - thanks for the info on Cisco federation.

    Monday, November 24, 2008 4:06 AM