When using ONLY libupnp, and when connected to the internet ONLY over a wired connection, the IGD's don't respond directly to the application's search query. However, the application does end up finding the IGD through it's advertisement, but that may take the application a bit more time to find it (a few seconds). To fix this, the libupnp README seems to indicate that a route must be added to the user's machine routing table using sudo. Not the best solution. As of right now I have not found a way to make the application achieve this without administrative privileges.
For all intents and purposes, this isn't really a bug. It's more of a result of the library's design. You have to explicitly allow your machine to route packets directly from an external source. I also think this is a very specific corner case. In order for it to happen, there must be only one IGD available, that IGD must not have NAT-PMP support, and you must ONLY be connected to it via ethernet cable and not have any wireless capabilities on your machine. The only reason I managed to find this occurrence was because I was trying to isolate my system for specifically testing ONLY libupnp over one specific interface while refactoring the code to make sure I wasn't causing any regressions. But the odds of this setup existing in real life are very low.
Jami will work regardless of the setup, no need to worry. As I mentioned this is a very specific corner case. Even if this phenomenon occurs on your setup, the application will still be able to find the internet gateway device. It just might take an extra few seconds or so to discover it. Moreover, if for some reason you need to establish communication within those few seconds, Jami will fall back on other means to accomplish what it needs to do. The Portable Universal Plug and Play (PUPnP) library is only one of the many options we have to establish communications.