DLNA uses wrong IP address
Closed this issue · 5 comments
I have multiple Ethernet interfaces. When I try to connect with a DLNA player, it uses the wrong IP address.
The SWYH's DLNA server included for PCM and MP3 stream, one resource per network interface. So each stream is exposed on all your network interfaces of your machine.
For example, on my laptop I have 3 network interfaces (on 3 different networks), so each stream has 3 resources :
It's the responsibility of your DLNA Media Renderer to choose the correct resource that is available to it (IP of the same network).
Otherwise, in the "HTTP Live Streaming" window, I display the first IP address, but you can use anyone !
SWYH 1.4 is on Windows 7 with
eth0 192.168.0.5/255.255.255.0
eth1 172.16.0.5/255.255.255.0
VLC for iOS is on 192.168.0.20
Selecting "Music/Stream What You Hear MP3"
It tries to connect to 172.16.0.5:3727/stream/swyh.mp3
Connection fails
UPnP Device Architecture Version 1.1
"Multi-homed devices MUST send the search response using the same UPnP-enabled interface on which the search request was received. The URL specified in the LOCATION field value MUST specify an address that is reachable on that interface."
Hi dogbertai,
I have check the code and I do test with network analyzer (Wireshark & Upnp Device sniffer) ! SWYH is compliant the UPnP Device Architecture, the Location field is correctly specify the remote address !
SWYH listens on UDP port 1900 (SSDP) and when it receives a M-SEARCH request, it's reply HTTP 200 with Location set to the local address of the interface on which the search request was received ! For example, my laptop is on 3 different networks with Ipv4 & v6, so when I send a multicast M-SEARCH request on each interfaces, SWYH reply his correct location for each.
So SWYH is detectable and any UPnP/DLNA client can connect to the SOAP service on the correct IP address to discover the contents of the Media Server.
Once connected to the SWYH's SOAP service, VLC can now "see" the "Music" folder containing the two media streams (PCM & MP3). The fact that VLC can discover the contents of the SWYH's Media Server proves that network connectivity between VLC and SWYH is working well.
Then the two media streams ("audioItem.audioBroadcast") exposed by SWYH contains various properties such as title, artist, genre .... and a resources list that describes the media format (bitrate, bit, channel) and especially the URI (contentUri) for all network interfaces.
So if VLC can discover SWYH on your network and connect to the Media Server to get the media streams I don't think this is a bug in the implementation of UPnP / SSDP in SWYH. I think that VLC doesn't selects the right contenUri in the resources list of the media.
Maybe because your two network interfaces have the same network mask?
It's the responsibility of your DLNA Media Renderer to choose the correct resource that is available to it (IP of the same network).
Do you have a source for this?
I've been trying to search for more information.
One document I've seen states that most implementations only choose the first resource.
I've seen documents that refer to other attributes like protocol and bitrate, but I haven't seen anything that refer to discriminating based on IP address.
Are DLNA clients required to have a failover? If one resource fails, try the next?
I think the purpose of multiple resources is to provide content in different formats. I don't think it should be to list server-IPs other than the one the client already found and is talking to.
I understand these don't explicity say it, but here are more quotes with the same general idea from UPnP Device Architecture Version 1.1
However, as a general principle, related interactions between control points and devices (e.g. action control request and response messages, event subscription and event messages) MUST occur using the same pair of outgoing and incoming UPnP-enabled interfaces.
On a multi-homed device, all fully qualified URLs contained in response arguments that refer to resources on the device MUST be reachable on the UPnP-enabled interface on which the response message is sent.
On a multi-homed device, all fully-qualified URLs contained in event body that refer to resources on the device MUST be reachable on the UPnP-enabled interface on which the event message is sent.
Hi,
I have released a new version to fixes this issue : https://github.com/StreamWhatYouHear/SWYH/releases/tag/1.4.15258.0
I don't have any problem with other client than VLC (tested with Windows Media Player and Intel Media renderer) so I think that the DLNA client should try all resources.
But as I know the receiver IP used to query the ContentDirectory service, I have updated my code to include only this IP, so the resources, and especially the Content URI, are different depending on the caller. So the DLNA client will get only one IP, the same as he used to query service.
Best,