[1.x] AudioBridge Talking Event is not firing

[mail2mhossain]

Janus Server Version: V1.2.1

Have you tested a more recent version of Janus too? NO

We are connecting the client to the Janus Server as follows:

Once the connection is successful, audio is being transferred and received. However, we are not receiving Talking related events from the Janus Server:

{
   "janus": "event",
   "session_id": 7139199376061861,
   "sender": 3585038430980055,
   "plugindata": {
      "plugin": "janus.plugin.audiobridge",
      "data": {
         "audiobridge": "talking",
         "room": 619850549732418,
         "id": 1346778935093210
      }
   }
}

{
   "janus": "event",
   "session_id": 7139199376061861,
   "sender": 3585038430980055,
   "plugindata": {
      "plugin": "janus.plugin.audiobridge",
      "data": {
         "audiobridge": "stopped-talking",
         "room": 619850549732418,
         "id": 2281497554882625
      }
   }
}

Is there something we might be missing in the Janus payload that we're sending to the Janus server, or does it depend on the offer SDP? AudioBridge.zip

[atoppi]

Is audio level RTP extension being negotiated?

[lminiero]

Not only that. The room must have been created with support for the extension, and the related properties must be tweaked to use good values for detecting users talking. By default this is disabled, and the default properties are probably not sensitive enough for most use cases (meaning no speech could ever be detected). In both cases, this is not an issue (so out of scope here) but a matter of properly configuring rooms and participants.

[mail2mhossain]

The room is configured correctly, and other devices, such as the Android app, are receiving Talking events. I am using the desktop version of our WebRTC client with the SIPSorcery WebRTC library.

[mail2mhossain]

Is audio level RTP extension being negotiated?

Would you please explain a bit.

[lminiero]

The room is configured correctly, and other devices, such as the Android app, are receiving Talking events. I am using the desktop version of our WebRTC client with the SIPSorcery WebRTC library.

Janus has no idea if the client is a mobile endpoint or something else: if the feature is available, it will be used. As Alessandro pointed out, though, this will only work if the audio-level extension is negotiated by the WebRTC endpoint, as we use that to detect voice activity. You should check iif SIP Sorcery does negotiate them in the SDP: if not, you have your answer.

[lminiero]

@mail2mhossain have you checked if SIP Sorcery negotiates the audio-levels RTP extension, and if the extension is indeed present in RTP packets?

[mail2mhossain]

In Android SDP, there are audio-level RTP mappings:

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

However, this mapping is missing in the desktop SDP.

I have manually added it to the desktop SDP, but I'm still not receiving the talking events.

[lminiero]

That's because, as I said in my previous messages, the extension must be negotiated but also present in RTP packets. Closing as not an issue.