locked
Audio Quality on Calls Between Federated Partners RRS feed

  • Question

  • We are experience an odd issue with audio call quality between federated partners (Communicator to Communicator calls).  We have a company we are working with and our OCS Servers are connected via a private network with plenty of bandwidth (dedicated 10 meg circuit used JUST for audio calls).  On Communicator calls, there is no clipping or other digital artifacting, but the calls have a tinny/flat sound to them.  It sounds like they are either heavily compressed or the sampling rate is low.

    We did run the pre-call diagnostics tool on both ends of the call and do not see any ovious issues there.

    Any thoughts/ideas on what could cause that behavior?
    Tuesday, September 29, 2009 10:48 PM

All replies

  • What type of phone devices are you using?  If you're using non-certified OCS devices from this list here , you could be limiting your call quality to narrowband.  If you want wideband call quality, use certified OCS devices.
    MVP | MCSE:M | MCITP: Enterprise Messaging Administrator | MCTS: OCS + Voice Specialization | http://www.shudnow.net
    Wednesday, September 30, 2009 4:09 AM
  • Elan, FYI this is a deployment that I have been working on with Jon, so it's not something basic like that (using certified Polycom speakerphone and headsets).

    Additionally, audio quality is better when when the exact same federated call is placed by routing over the Internet instead of the new MPLS circuit connecting these two federated partners.  So using the same equipment, workstations, OCS servers, etc, but only changing the routes between Internet and private circuit is where the issue pops-ups.  Quality over the Internet is fine, although some latency is seen (as to be expected).
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, September 30, 2009 12:00 PM
    Moderator
  • It may sound crazy, but is there any type of QoS being provided over the MPLS link, or any "enhancements" which could be having a negative impact?

    I've never seen that happen, but if is the link thats causing the issue it could be something on that link, or a bad connection in the building even...



    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    Wednesday, September 30, 2009 12:18 PM
  • What do the Monitoring server reports look like for those calls? Any key differences in the reports for the calls across the Internet vs. the MPLS link?

    Wednesday, September 30, 2009 5:29 PM
  • Hey Randy.  No enhancements that I am aware of.  Global Crossing provides the MPLS circuits and we did not request anything beyond IP connectivity.  Is there something specific that I could check with them to see if they have enabled on the line?
    Monday, October 5, 2009 2:07 PM
  • So, I'm starting to think that this might simply be a case of the difference between the RTA and Siren codecs.  The calls over the MPLS circuit are three party conference calls using the OCS MCU.  My understanding is when the call is esclated to a conference call, the codec changes to Siren which does not provide the same level of audio fidelity.

    Has anyone else run into this?

    jon
    Monday, October 5, 2009 2:10 PM
  • It is true that when you go from a 2 person communicator call to a multi-party "conference" call you are now using the OCS Server conferencing MCU which uses the SIREN codec.  If bandwidth is not an issue you should not see a significant discrepancy in voice quality.  I would like to see what the QoE reports for a point-to-point and a conference call to see what the network and user MOS scores are. 

    I believe Global crossing supports 3 buckets for QoS, but if these are identified as RTP streams they would be marked with a DSCP of 5 typically and put into a priority queue.  This would happen for RTP streams that are RTAudio or Siren...


    Mark King | C/D/H | MCTS:OCS | MCSE: Messaging | MCITP:Enterprise Administrator | CCNA
    Monday, October 5, 2009 5:11 PM