<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>Remote audio routing within the C90 via the API</title>
  <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_thread?p_l_id=&amp;threadId=10747796" />
  <subtitle>Remote audio routing within the C90 via the API</subtitle>
  <id>http://developer.cisco.com/c/message_boards/find_thread?p_l_id=&amp;threadId=10747796</id>
  <updated>2013-06-19T09:26:57Z</updated>
  <dc:date>2013-06-19T09:26:57Z</dc:date>
  <entry>
    <title>RE: Remote audio routing within the C90 via the API</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=10825526" />
    <author>
      <name>David Bruun-Lie</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=10825526</id>
    <updated>2013-01-18T09:56:35Z</updated>
    <published>2013-01-18T09:51:47Z</published>
    <summary type="html">Bob, got this from our audio experts:   

I recommend that they use xStatus Audio to determine the IDs of the Remote Audio Input and Remote Audio Output for a call.

Example from a C40:

[code]
xstatus Audio 
Audio Microphones Mute: Off
Audio Volume: 0
Audio Input LocalInput 1 Name: "Microphone"
...
Audio Input LocalInput 2 Name: "PC input"
...
Audio Input LocalInput 3 Name: "HDMI input"
...
Audio Input RemoteInput 606 CallId: 302
Audio Output LocalOutput 4 Name: "Loudspeaker"
...
Audio Output LocalOutput 5 Name: "Recorder"
...
Audio Output RemoteOutput 607 CallId: 302
Audio Output RemoteOutput 607 Input 1 Gain: 0
Audio Output RemoteOutput 607 Input 2 Gain: 0
Audio Output RemoteOutput 607 Input 3 Gain: 0
Audio Module 0 Type: Unknown
Audio Module 0 SoftwareID: ""
Audio Module 0 HardwareID: ""
Audio Module 0 Connector: ""
end
[/code]
From the above example:

Call Id: 302
Remote Audio Input ID: 606
Remote Audio Output ID: 607

Hope this helps, Regards, David</summary>
    <dc:creator>David Bruun-Lie</dc:creator>
    <dc:date>2013-01-18T09:51:47Z</dc:date>
  </entry>
  <entry>
    <title>Remote audio routing within the C90 via the API</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=10747795" />
    <author>
      <name>Bob Philby</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=10747795</id>
    <updated>2013-01-16T17:35:03Z</updated>
    <published>2013-01-16T17:35:03Z</published>
    <summary type="html">[color=#1f497d]I am programming a system that requires two calls to be active and I need to break the audio between them inside the C90 (ver 5.1.5). I used the Debug window in TC Console initially to determine how to do this. The command that I am using is:[/color]
[color=#1f497d]"xCommand Audio RemoteOutput DisconnectInput OutputId:[/color][color=red]XXX[/color][color=#1f497d] InputId:[/color][color=red]YYY[/color][color=#1f497d] "[/color]
[color=#1f497d] [/color]
[color=#1f497d]After placing a few calls and watching the values in the debug window I was able to determine that the OutputId ([/color][color=red]XXX[/color][color=#1f497d]) was (Call ID x 2) + 4. The InputId ([/color][color=red]YYY[/color][color=#1f497d]) was (Call ID x 2) +3. This was consistently the case using the Call ID returned by the codec when the call was established. The math was easy, it made sense, and worked all the time. Well, almost all the time. During the last day of testing, I placed a call, the system set up the codec as it had a hundred times before, but the audio between the calls was not broken. We ended up with massive echo caused by the loop. I opened TC Console and verified that the audio paths were still in place. Then I opened the Debug window in TC Console and broke the paths. What I found was unsettling. [/color]
[color=#1f497d] [/color]
[color=#1f497d]When the unit failed to configure correctly, the math had changed. The OutputId was now (Call ID x 2) + 2, and the InputId was (Call ID x 2) + 1. I disconnected the calls and made two more calls. The same thing happened. The codec seemed to be mapping the remote audio input and output IDs differently. I rebooted the codec, the math returned to normal, and the system was again working.[/color]
[color=#1f497d] [/color]
[color=#1f497d]My concern is that this is going to happen again and we’re going to end up with an unhappy customer and a service call. The only thing that had happened out of the ordinary prior to the failure was the codec received an incoming call which I rejected. It was like the call ID number may have been incremented but since the call was never established the Input and Output IDs weren’t.  I’m not saying this is what happened and unfortunately I had no other system available to me to test the theory. My question is whether there is another/better means of determining the Remote Audio Input and Output IDs to put in the commands. The obvious information I have to work with was the Call ID of the active calls. But there must be another way since TC Console can do it. Any secrets you can share?[/color]</summary>
    <dc:creator>Bob Philby</dc:creator>
    <dc:date>2013-01-16T17:35:03Z</dc:date>
  </entry>
</feed>

