<SOAP-ENV:Fault> with a chinese camera (TP-LINK)

[elsampsa]

First of all, thanks for this awesome python library and the great work.

Now my question.

Don't we all just love cheap chinese camera brands?

Mine is a brand new tp-link IP cam. It is not discovered with python-ws-discovery, but digging a bit deeper, I can see that it's response is None'd in message.py around line 35:

if dom.getElementsByTagNameNS(NS_SOAPENV, "Fault"):
    return None

The essence of the SOAP message the camera returns is this:

<SOAP-ENV:Header><wsa:MessageID>urn:uuid:8837bd04-b6df-4e95-971e-1edc3062fc0a</wsa:MessageID>
<wsa:To SOAP-ENV:mustUnderstand="true">urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>
<wsa:Action SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action>
</SOAP-ENV:Header><SOAP-ENV:Body><SOAP-ENV:Fault><SOAP-ENV:Code><SOAP-ENV:Value>SOAP-ENV:Sender
</SOAP-ENV:Value><SOAP-ENV:Subcode><SOAP-ENV:Value>ter:InvalidArgVal</SOAP-ENV:Value></SOAP-ENV:Subcode>
</SOAP-ENV:Code><SOAP-ENV:Reason><SOAP-ENV:Text xml:lang="en">error</SOAP-ENV:Text></SOAP-ENV:Reason>
</SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>

So there is not much information why this camera dislikes python-ws-discovery, or maybe that ter:InvalidArgVal is providing a clue?

Does anyone have any experience / clue of why this would happen or how I could "massage" the message sent to the camera in such a way that it starts not to diss python-ws-discovery? I am happy to do the debugging, if you just give me a clue how to proceed. :)

[sriks6711]

TP-Link might be cheap but it is also very popular in the neck of the woods I live in. Maybe this helps?

https://www.reddit.com/r/ispyconnect/comments/uxdphn/tplink_onvif/

[elsampsa]

I pimped up the -c (capture) option in wsdiscover to pretty-print the xml messages & add some more info & tried TP-LINK agains UNV.

Here are my findings.

First, wsdiscover sends the PROBE msg correctly:

1 SEND 239.255.255.250:3702 iface=10.0.0.1 TS=0.1118924617767334

<?xml version="1.0" ?>
<s:Envelope 
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery" 
xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Header>
      <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</a:Action>
      <a:MessageID>urn:uuid:d5328158-9034-4872-99c5-621464e5c68f</a:MessageID>
      <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
    </s:Header>
  <s:Body>
        <d:Probe/>
   </s:Body>
</s:Envelope>

A legit answer from an UNV camera (yet another chinabrand) looks like this:

10 RECV 10.0.0.3:59513 TS=0.2311234474182129

<?xml version="1.0" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" 
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xop="http://www.w3.org/2004/08/xop/include" 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
xmlns:tns="http://schemas.xmlsoap.org/ws/2005/04/discovery" 
xmlns:dn="http://www.onvif.org/ver10/network/wsdl" 
xmlns:wsa5="http://www.w3.org/2005/08/addressing">
  <SOAP-ENV:Header>
    <tns:AppSequence MessageNumber="10109" InstanceId="1"/>
    <wsa:MessageID>urn:uuid:00010010-0001-1020-8000-48ea63363282</wsa:MessageID>
    <wsa:RelatesTo>urn:uuid:d5328158-9034-4872-99c5-621464e5c68f</wsa:RelatesTo>
    <wsa:To SOAP-ENV:mustUnderstand="true">urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>
    <wsa:Action SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</wsa:Action>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <tns:ProbeMatches>
      <tns:ProbeMatch>
        <wsa:EndpointReference>
          <wsa:Address>urn:uuid:00010010-0001-1020-8000-48ea63363282</wsa:Address>
        </wsa:EndpointReference>
        <tns:Types>dn:NetworkVideoTransmitter</tns:Types>
        <tns:Scopes>onvif://www.onvif.org/Profile/G onvif://www.onvif.org/Profile/Streaming onvif://www.onvif.org/type/video_encoder  onvif://www.onvif.org/type/ptz  onvif://www.onvif.org/type/audio_encoder  onvif://www.onvif.org/location/  onvif://www.onvif.org/register_status/offline  onvif://www.onvif.org/register_server/0.0.0.0:5060  onvif://www.onvif.org/regist_id/36-32-82  onvif://www.onvif.org/type/IPC  onvif://www.onvif.org/name/IPC3232ER3-DVZ28  onvif://www.onvif.org/manufacturer/UNV  onvif://www.onvif.org/VideoSourceNumber/1  onvif://www.onvif.org/version/IPC_Q1201-B5017P11D1607  onvif://www.onvif.org/serial/210235C20HA16A000026  onvif://www.onvif.org/macaddr/48ea63363282  onvif://www.onvif.org/hardware/IPC3232ER3-DVZ28  </tns:Scopes>
        <tns:XAddrs>http://10.0.0.3:80/onvif/device_service</tns:XAddrs>
        <tns:MetadataVersion>1</tns:MetadataVersion>
      </tns:ProbeMatch>
    </tns:ProbeMatches>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

But TP-LINK says this:

9 WARNING: BAD RECV 10.0.0.7:3702 TS=0.12566018104553223

<?xml version="1.0" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" 
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
xmlns:wsdd="http://schemas.xmlsoap.org/ws/2005/04/discovery" 
xmlns:chan="http://schemas.microsoft.com/ws/2005/02/duplex" 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:wsa5="http://www.w3.org/2005/08/addressing" xmlns:xmime="http://tempuri.org/xmime.xsd" 
xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:wsrfbf="http://docs.oasis-open.org/wsrf/bf-2" 
xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:wsrfr="http://docs.oasis-open.org/wsrf/r-2" 
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:tt="http://www.onvif.org/ver10/schema" 
xmlns:ter="http://www.onvif.org/ver10/error" xmlns:tns1="http://www.onvif.org/ver10/topics" 
xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:tmd="http://www.onvif.org/ver10/deviceIO/wsdl" 
xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" 
xmlns:tdn="http://www.onvif.org/ver10/network/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" 
xmlns:trp="http://www.onvif.org/ver10/replay/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" 
xmlns:tr2="http://www.onvif.org/ver20/media/wsdl">
  <SOAP-ENV:Header>
    <wsa:MessageID>urn:uuid:d5328158-9034-4872-99c5-621464e5c68f</wsa:MessageID>
    <wsa:To SOAP-ENV:mustUnderstand="true">urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>
    <wsa:Action SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <SOAP-ENV:Fault>
      <SOAP-ENV:Code>
        <SOAP-ENV:Value>SOAP-ENV:Sender</SOAP-ENV:Value>
        <SOAP-ENV:Subcode>
          <SOAP-ENV:Value>ter:InvalidArgVal</SOAP-ENV:Value>
        </SOAP-ENV:Subcode>
      </SOAP-ENV:Code>
      <SOAP-ENV:Reason>
        <SOAP-ENV:Text xml:lang="en">error</SOAP-ENV:Text>
      </SOAP-ENV:Reason>
    </SOAP-ENV:Fault>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Does the SOAP ping-pong:ing fail maybe because the TP-LINK camera wants more xlmns ? That "ter" might refer to that line xmlns:ter="http://www.onvif.org/ver10/error" .. that is not found in wsdiscover's original PROBE message..?

Taking a look in onvif core specs, there is this (in section 5.8.2.2):

ter:InvalidArgs --> Invalid Args --> An error due to any of the following: 
  missing argument, too many arguments, arguments are of the wrong data type.

Not sure why the camera would reply like this, since the PROBE message seems completely legit - or wait, if I look at the up-to-date WSDiscovery specs in here, it says:

<s:Envelope ... >
  <s:Header ... >
    <a:Action ... >
      http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe
    </a:Action>
    <a:MessageID ... >xs:anyURI</a:MessageID>
   [<a:ReplyTo ... >endpoint-reference</a:ReplyTo>]?
    <a:To ... >xs:anyURI</a:To>
    ...
  </s:Header>
  <s:Body ... >
    <d:Probe ... >
     [<d:Types>list of xs:QName</d:Types>]?
     [<d:Scopes [MatchBy="xs:anyURI"]? ... >
        list of xs:anyURI
      </d:Scopes>]?
     ...
    </d:Probe>
  </s:Body>
</s:Envelope>

So in the <a:Action> section there should be

http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe

instead of the oldie..?

http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe

Do these things need to be up-to-date?

EDIT: know I noticed that in the message sent by TP-LINK camera it also refers to the 2005 specs, so it should be OK

[elsampsa]

The <a:MessageID> seems different as well: it should be
<a:MessageID ... >xs:anyURI, but python-ws-discovery uses
<a:MessageID>urn:uuid.

I'd imagine that cams should look at the <a:Action> section, read the specs version from there and then expect one format or another, according to the version, right? But, as they are chinese cameras .. and the specs used by python-ws-discovery are from 2005 (!) so I guess anything can happen.

Wikipedia has nice links to the two different spec version: https://en.wikipedia.org/wiki/WS-Discovery

But as I mentioned in the previous comment, both python-ws-discovery and the TP-LINK camera seem to be using the 2005 specs.

So I think the conclusions is that TP-LINK cameras send shit by default?

For the sake of completeness, here is the PROBE as of 2005 specs:

<s:Envelope
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
xmlns:i="http://printer.example.org/2003/imaging"
xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
<s:Header>
  <a:Action>
   http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe
 </a:Action>
<a:MessageID>
  uuid:0a6dc791-2be6-4991-9af1-454778a1917a
</a:MessageID>
<a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
</s:Header>
<s:Body>
   <d:Probe>
    <d:Types>i:PrintBasic</d:Types>
    <d:Scopes
      MatchBy="http://schemas.xmlsoap.org/ws/2005/04/discovery/ldap" >
      ldap:///ou=engineering,o=examplecom,c=us
    </d:Scopes>
  </d:Probe>
</s:Body>
</s:Envelope>

[wpyoga]

UNV seems to be XiongMai -- all my cameras from XM reply with this identifier.

TP-Link has a sub-brand Mercury, and an overseas series called VIGI. I found out that they all have different mobile apps after I imported them from China. Talk about excess.

The important thing is, all of those TP-Link based cameras exhibit the same behavior. They want to be probed like this, which is what Home Assistant is doing:

<?xml version="1.0" ?>
<s:Envelope xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:d="http://schemas.xmlsoap.org/ws/2005/0
4/discovery" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
        <s:Header>
                <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</a:Action>
                <a:MessageID>urn:uuid:af0e30fa-7e14-4b6f-938f-8d76c9f1d957</a:MessageID>
                <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
        </s:Header>
        <s:Body>
                <d:Probe>
                        <d:Scopes>onvif://www.onvif.org/Profile/Streaming</d:Scopes>
                </d:Probe>
        </s:Body>
</s:Envelope>

The scope is <d:Scopes>onvif://www.onvif.org/Profile/Streaming</d:Scopes>

Or like this, which is what onvif-util is doing:

<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
	xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
	<SOAP-ENV:Header>
		<a:Action SOAP-ENV:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</a:Action>
		<a:MessageID>urn:uuid:356e5873-3409-1996-f89a-6dbede83c966</a:MessageID>
		<a:ReplyTo>
			<a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
		</a:ReplyTo>
		<a:To SOAP-ENV:mustUnderstand="1">urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
	</SOAP-ENV:Header>
	<SOAP-ENV:Body>
		<p:Probe
			xmlns:p="http://schemas.xmlsoap.org/ws/2005/04/discovery">
			<d:Types
				xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
				xmlns:dp0="http://www.onvif.org/ver10/network/wsdl">dp0:NetworkVideoTransmitter
			</d:Types>
		</p:Probe>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

It probes for NetworkVideoTransmitter.

However, even with those probes, all TP-Link cameras I've tested still respond with an incorrect MessageID, as discussed in #66

[wpyoga]

With PR #76 and #75 , I can now probe for TP-Link cameras. For comparison, this is before applying both PR's:

$ wsdiscover | grep address:
 address: 192.168.202.78:8899
 address: 192.168.202.77:8899
 address: 192.168.202.71:80

Full output

$ wsdiscover 

Discovered:

 address: 192.168.202.77:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:43:1b:d7:d5
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.78:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:43:20:fe:f4
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.71:80
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/type/ptz
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/hardware/TC-C34XN SPEC%3AI3%2FE%2FY%2F2.8mm%2FV5.0
  - onvif://www.onvif.org/mfr/ipcamera
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/location/city/tianjin
  - onvif://www.onvif.org/mac
  - onvif://www.onvif.org/firmware/APP_V3.3.0.20221223
  - onvif://www.onvif.org/name/ipcamera
  - onvif://www.onvif.org/type/ipcamera

This is with both PR's and with both new options applied -- I can discover all 16 cameras in my network:

$ wsdiscover -y http://www.onvif.org/ver10/network/wsdl dp0 NetworkVideoTransmitter -rt | grep address:
 address: 192.168.202.78:8899
 address: 192.168.202.50:2020
 address: 192.168.202.92:2020
 address: 192.168.202.84:8899
 address: 192.168.202.82:8899
 address: 192.168.202.77:8899
 address: 192.168.202.81:8899
 address: 192.168.202.80:8899
 address: 192.168.202.60:2020
 address: 192.168.202.83:8899
 address: 192.168.202.51:2020
 address: 192.168.202.86:8899
 address: 192.168.202.85:8899
 address: 192.168.202.61:2020
 address: 192.168.202.90:2020
 address: 192.168.202.71:80

Full output

$ wsdiscover -y http://www.onvif.org/ver10/network/wsdl dp0 NetworkVideoTransmitter -rt

Discovered:

 address: 192.168.202.92:2020
  - onvif://www.onvif.org/name/VIGI-C350
  - onvif://www.onvif.org/hardware/VIGI-C350
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/Profile/G
  - onvif://www.onvif.org/Profile/T
  - onvif://www.onvif.org/location/Hong Kong
  - onvif://www.onvif.org/type/NetworkVideoTransmitter

 address: 192.168.202.90:2020
  - onvif://www.onvif.org/name/VIGI-C250
  - onvif://www.onvif.org/hardware/VIGI-C250
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/Profile/G
  - onvif://www.onvif.org/Profile/T
  - onvif://www.onvif.org/location/Hong Kong
  - onvif://www.onvif.org/type/NetworkVideoTransmitter

 address: 192.168.202.60:2020
  - onvif://www.onvif.org/name/VIGI-C230I-Mini
  - onvif://www.onvif.org/hardware/VIGI-C230I-Mini
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/Profile/G
  - onvif://www.onvif.org/location/Hong Kong
  - onvif://www.onvif.org/type/NetworkVideoTransmitter

 address: 192.168.202.77:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:43:1b:d7:d5
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.51:2020
  - onvif://www.onvif.org/name/MERCURY-IPC
  - onvif://www.onvif.org/hardware/MODEL
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/location/ShenZhen
  - onvif://www.onvif.org/type/NetworkVideoTransmitter

 address: 192.168.202.78:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:43:20:fe:f4
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.82:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:d7:b4
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.83:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:d6:ae
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.81:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:bc:3c
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.84:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:cc:a3
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.61:2020
  - onvif://www.onvif.org/name/VIGI-C430
  - onvif://www.onvif.org/hardware/VIGI-C430
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/location/Hong Kong
  - onvif://www.onvif.org/type/NetworkVideoTransmitter

 address: 192.168.202.86:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:d6:69
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.80:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:d1:38
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.85:8899
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/hardware/IPC-model
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/name/NVT
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/A1C2B3/mac/00:12:31:c3:cd:a2
  - onvif://www.onvif.org/Profile/T

 address: 192.168.202.50:2020
  - onvif://www.onvif.org/name/TP-IPC
  - onvif://www.onvif.org/hardware/MODEL
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/location/ShenZhen
  - onvif://www.onvif.org/type/NetworkVideoTransmitter

 address: 192.168.202.71:80
  - onvif://www.onvif.org/type/video_encoder
  - onvif://www.onvif.org/type/audio_encoder
  - onvif://www.onvif.org/type/ptz
  - onvif://www.onvif.org/Profile/Streaming
  - onvif://www.onvif.org/hardware/TC-C34XN SPEC%3AI3%2FE%2FY%2F2.8mm%2FV5.0
  - onvif://www.onvif.org/mfr/ipcamera
  - onvif://www.onvif.org/location/country/china
  - onvif://www.onvif.org/location/city/tianjin
  - onvif://www.onvif.org/mac
  - onvif://www.onvif.org/firmware/APP_V3.3.0.20221223
  - onvif://www.onvif.org/name/ipcamera
  - onvif://www.onvif.org/type/ipcamera

In my case, specifying both the scope and type to probe, along with enabling the --relates-to option, yields the same result, all 16 cameras are discovered:

$ wsdiscover -s onvif://www.onvif.org/Profile/Streaming -y http://www.onvif.org/ver10/network/wsdl dp0 NetworkVideoTransmitter -rt | grep address:
 address: 192.168.202.77:8899
 address: 192.168.202.78:8899
 address: 192.168.202.90:2020
 address: 192.168.202.61:2020
 address: 192.168.202.92:2020
 address: 192.168.202.82:8899
 address: 192.168.202.83:8899
 address: 192.168.202.84:8899
 address: 192.168.202.80:8899
 address: 192.168.202.81:8899
 address: 192.168.202.50:2020
 address: 192.168.202.51:2020
 address: 192.168.202.86:8899
 address: 192.168.202.60:2020
 address: 192.168.202.85:8899
 address: 192.168.202.71:80

However, if I only specify the scope and not the type, some (UNV) cameras are not discovered:

$ wsdiscover -s onvif://www.onvif.org/Profile/Streaming -rt | grep address:
 address: 192.168.202.78:8899
 address: 192.168.202.50:2020
 address: 192.168.202.77:8899
 address: 192.168.202.61:2020
 address: 192.168.202.60:2020
 address: 192.168.202.51:2020
 address: 192.168.202.90:2020
 address: 192.168.202.92:2020
 address: 192.168.202.71:80

Note:

• VIGI xxx is TP-Link's international product line of security cameras
• TP-IPC is TP-Link's domestic Chinese product line
• MERCURY-IPC is TP-Link's sub-brand domestic Chinese product line

Edit: add more examples for comparison

[sriks6711]

This is promising. Thank you @wpyoga and @elsampsa - respect!