question about SIP INVITE

[Brent W. Baccala]

Hi -

I'm trying to get Big Blue Button working within a private network, and to do this I have to deal with ".local" addresses being returned from the browser as candidate IP addresses.

I've reverted the changes that filter out these addresses from the candidate list, and my HTML5 client is sending INVITEs to freeswitch with valid "a=candidate" lines that have the .local addresses in them, but I still have an "c=IN IP4 0.0.0.0" line in the INVITE that I suppose is causing problems, since it still doesn't work.

Can anybody tell me where in our code the "c=IN IP4 0.0.0.0" line is constructed?

I figure it needs to be something like "c=IN IP4 d2a5b7bf-88fa-41e8-8f5e-16ef30686ac5.local", but I don't know how to make that happen.

    agape

    brent

[Paulo Lanzarin]

> I'm trying to get Big Blue Button working within a private network, and to do this I have to deal with ".local" addresses being returned from the browser as candidate IP addresses.

Isn't the browser generating candidates other than mDNS ones? Not even regular host candidates?

> Can anybody tell me where in our code the "c=IN IP4 0.0.0.0" line is constructed?

Nowhere. That's done by the browser. The local description is constructed and set before gathering takes place so c=/o= IPs are 0.0.0.0 and ports

are `9` as per JSEP specs, so that's the correct behavior.

> I figure it needs to be something like "c=IN IP4 d2a5b7bf-88fa-41e8-8f5e-16ef30686ac5.local", but I don't know how to make that happen.

No. In this scenario, c=/o= IPs are irrelevant, so you should ignore them. What's important is that candidates are signaled and that both

ends are able to make connectivity checks work between candidate pairs.

We filter(ed) mDNS candidates because FreeSWITCH just didn't support them until mid-2021 (as in rejected an INVITE with such candidates).
That changed in v1.10.7 where FreeSWITCH can now either try to resolve or ignore those candidates, but we've not tested that yet hence why

they're still being filtered by the client.

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/d2c3de82-686a-46d5-a73d-6705d19bcd9an%40googlegroups.com.

[Paulo Lanzarin]

Also: I think mDNS resolution is disabled by default in FreeSWITCH.

You can enable it via `fsctl mdns_resolve enable` or setting `ice-resolve-candidate` to true in

switch.conf.

s,

prlanzarin

[Brent W. Baccala]

On Thursday, April 28, 2022 at 8:24:52 AM UTC-4 prlanzarin wrote:

> I'm trying to get Big Blue Button working within a private network, and to do this I have to deal with ".local" addresses being returned from the browser as candidate IP addresses.

Isn't the browser generating candidates other than mDNS ones? Not even regular host candidates?

When I connect to either listen-only, or microphone without microphone permissions enable (so it has to prompt for permissions), I get an mDNS candidate and no others.  When I connect with microphone permissions already enabled I get an IPv4 address and no mDNS.

 

We filter(ed) mDNS candidates because FreeSWITCH just didn't support them until mid-2021 (as in rejected an INVITE with such candidates).

That changed in v1.10.7 where FreeSWITCH can now either try to resolve or ignore those candidates, but we've not tested that yet hence why

they're still being filtered by the client.

I'm testing it now. :-)

    agape

    brent 

[Brent W. Baccala]

On Thursday, April 28, 2022 at 8:30:09 AM UTC-4 prlanzarin wrote:

Also: I think mDNS resolution is disabled by default in FreeSWITCH.

You can enable it via `fsctl mdns_resolve enable` or setting `ice-resolve-candidate` to true in

switch.conf.

That's it!  That fixed it.

 

[Paulo Lanzarin]

>  When I connect to either listen-only, or microphone without microphone permissions enable (so it has to prompt for permissions), I get an mDNS candidate and no others.  When I connect with microphone permissions already enabled I get an IPv4 address and no mDNS.

Yes. That's an "heuristic" of sorts to prevent IP leaks. If no gUM permission was given => obfuscate host candidates with mDNS.

> That's it!  That fixed it.

Good. Maybe we should make client-side mDNS filtering officially configurable so people can use it with less friction.

--

You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/6f6225b9-6370-4278-9b88-9dfe26287939n%40googlegroups.com.

[Paulo Lanzarin]

> Good. Maybe we should make client-side mDNS filtering officially configurable so people can use it with less friction.

FYI: https://github.com/bigbluebutton/bigbluebutton/pull/14966