How to add provider for an element without a namespace in smack 4.2.0

Question

I haven't been able to find anything on this in my Googling, but I'm far from an XMPP expert so perhaps the answer is obvious. I'm wondering about the best way to parse custom child elements that don't have an explicit namespace. In this case I'm parsing some jingle elements, and some of them don't have any explicit namespace (for example, payload-type, or parameter which don't explicitly state a namespace and just inherit it).

For example:

<description maxptime="60" media="audio" xmlns="urn:xmpp:jingle:apps:rtp:1">
  <payload-type name="opus" clockrate="48000" id="111" channels="2">
    <parameter value="10" name="minptime" />
    <parameter value="1" name="useinbandfec" />
  </payload-type>
  ...
</description>

Here, both payload-type and parameter will inherit the parent namespace from description (urn:xmpp:jingle:apps:rtp:1). But parameter can also be used elsewhere:

<source ssrc="1789460357" xmlns="urn:xmpp:jingle:apps:rtp:ssma:0">
  <parameter value="mixed" name="cname" />
  ...  
</source>

Here, parameter will have the urn:xmpp:jingle:apps:rtp:ssma:0 namspace.

When adding custom providers to the ProviderManager, it requires passing in an explicit namespace, so I can't pass in just an empty string (ProviderManager.addExtensionProvider explicitly checks for that).

One option would be to register the parameter provider, for example, under every possible namespace, but that doesn't feel too great.

Another option would be for the higher-level providers (the ones with explicit namespaces) parsing any nested children elements without namespaces instead of just recursively getting the appropriate extension provider and calling parse. It seemed like registering everything with the ProviderManager was the more idiomatic way to do it though. This would probably use some sort of internal version of provider manager that would work on name alone. So an element would first look in the official ProviderManager for anything that matched, then try its internal version.

Is there an idiomatic way to achieve this? Maybe something I've completely missed?

I do see in this question that namespaces are expected, but I don't see any listed in the Jingle RTP spec. So perhaps one of the ideas I have above is the right one, but I'm wondering which would fit best with the library.

Thanks