"twoWayAudioEnabled" key does not exist just after camera registration

Answered

Kenji Torigoe

July 07, 2026 01:45

I cannot find the “twoWayAudioEnabled" key-value in a response of “rest/v4/devices/{id}” just after camera registration which supports 2 way audio. When I change and apply “Enable 2 way audio” in camera setting on Nx client, “twoWayAudioEnabled” key-value is created newly and it will keep existing after that.

Camera: AXIS M1075-L
Nx Witness Version: v6.1.2.42921
OS: Ubuntu 24.04 (ARM64)

Is this a known bug?
If so, please inform a plan to fix.

Thank you in advance.

0

• 

  Ichiro

  • Network Optix team

  July 09, 2026 15:42 Edited

  Hi ,

  It is expected. 
  The API response will show the current setting of the camera initial state, and for such parameter will show after firstly enabled.

  And you may use PATCH or POST to add this parameter, it should be working.

  0
• 

  Kenji Torigoe

  July 10, 2026 10:02

  When a new camera with audio I/O is added to Nx, "Enable 2-way audio" is automatically checked and active in the camera settings. However, "twoWayAudioEnabled" is missing from the "rest/v4/devices/{id}" response. It seems contradictory that we cannot verify its status through the API despite it being enabled in the UI.

  0
• 

  Ichiro

  • Network Optix team

  July 13, 2026 07:23

  Hi Kenji Torigoe,

  Yes, let me check with the dev-team if there is any change.

  0
• 

  Ichiro

  • Network Optix team

  July 17, 2026 04:01 Edited

  Hi Kenji Torigoe,

  By default, this property is hidden, since not every device explicitly supports audio functionality, and some devices have no audio features at all.

  To avoid confusion, twoWayAudioEnabled is a hidden property that can still always be used — even though its name may change between versions (from the old version to the new version).

  Regardless of whether twoWayAudioEnabled currently appears in the response, you can still edit this audio capability using:

  PATCH /rest/v4/devices/{id}
  
  {
      "parameters": {
           "twoWayAudioEnabled": false // true
      }
  }

  0
• 

  Kenji Torigoe

  July 17, 2026 04:46

  Hi Ichiro,

  I would like to check the current audio configuration of a device, rather than modifying it.

  According to the documentation, the twoWayAudioEnabled property is hidden by default. Because of this, we are unable to determine whether the setting is currently true or false.

  Is there any way (such as using specific query parameters like ?fields=all or ?verbose=true in a GET request) to force this property to be returned in the response?

  If not, what is the recommended way to retrieve the current state of this setting?

  0
• 

  Ichiro

  • Network Optix team

  July 21, 2026 03:26

  Hi Kenji Torigoe,

  In this case, we'd suggest sending the request to set your desired default value right after registration.

  You can check whether the camera supports audio via GET /rest/v4/devices/{id} — look for audioTransmit in the properties.

  If it does support audio, use PATCH to set twoWayAudioEnabled to true or false, depending on your use case.

  If it does not support audio, no further action is needed — it will be disabled and set to false by default.

   

  Is there any way (such as using specific query parameters like ?fields=all or ?verbose=true in a GET request) to force this property to be returned in the response?

  Unfortunately, no. There is no such implementation supported at the moment.
  But we will consider about this use case and give the suggestions to the product team for improvement.
   

  0
• 

  Kenji Torigoe

  July 21, 2026 03:37

  Hi Ichiro,

  Thank you for your reply and suggestion.

  However, we cannot adopt the proposed approach due to our application logic.

  In our application, the end-user has the authority to decide whether to enable or disable the audio function. Our app operates by reading the camera's current setting to reflect the appropriate UI and audio controls for the user.

  Because of this, our app cannot overwrite or send a PATCH request to set a default value upon registration, as doing so would ignore/change the user's intended setting on the camera side.

  Since we strictly need to read the current twoWayAudioEnabled status without modifying it, is there truly no way to retrieve this setting via API?

  If twoWayAudioEnabled cannot be returned in the GET response under any circumstances, could you please advise how an external client application is supposed to detect the user's actual audio configuration?

  Thank you for your understanding and support.

  0
• 

  Ichiro

  • Network Optix team

  July 21, 2026 04:09

  Hi Kenji Torigoe,

  how an external client application is supposed to detect the user's actual audio configuration?

  We don't currently have visibility into whether a user has enabled two-way audio during registration. By default, it should be disabled(from old experience from camera firmwares), and only enabled once the user explicitly changes the configuration. For other applications, we're not involved in their implementation, so audio settings simply follow whatever the camera reports to us by default. (ONVIF or manufacturer APIs)

   

  However, we cannot adopt the proposed approach due to our application logic. In our application, the end-user has the authority to decide whether to enable or disable the audio function.

  I think this may be a bit of a misunderstanding. 

  We're not suggesting that you change or overwrite any end-user's configuration. What we meant is this: your users will tell you whether they want audio on or off, and you can then apply that preference. 

  If a user wants audio enabled by default, you can send an "enable" request after registration; 
  if they want it disabled, you can send a "disable" request. 

  We don't have the intention that asking you to override anyone's configuration just to apply the value your customer has told you they want. (as a workaround)

   

  is there truly no way to retrieve this setting via API?

  Per our developers, this is intentional by design. 

  The audio feature has inconsistent/various implementation and behavior across cameras, whether proprietary or ONVIF-based. Based on past experience, a camera might report no audio capability at all, yet still claim to support two-way audio during registration. 

  Because device-reported audio information can be confused/inconsistent, the media server would run into confusion if it simply trusted whatever value it received. 

  To avoid this, we rely on explicit, manual configuration set by the user rather than defaulting to device-reported values. In other words, we use and present the value once the user has actually configured it themselves. This design might have been in place since v3.x if I remember right.

  I understand this may be a bit frustrating, and the workaround isn't the most elegant. That said, if your goal is to get the audio state and result your customer would like to see, this approach is doable for now. 

  We'll also take this use case into consideration and share it with our product team for future improvement.
   

   

  0

Please sign in to leave a comment.