This would be a great feature. So full DNS-name based hosting would be possible without standard ports (and with just one IP address of course) in a transparent und most RFC like way.
Logged In: YES
QHostInfo only has support for address records, meaning we'd have to add platform specific DNS code. Until QDns is fully ported to Qt4, we're unlikely to support any fancy DNS things :(
Logged In: YES
You could take the implementation from open source Jabber Instant Messenging Client Psi (www.psi-im.org). I know they have SRV code and they recently updated their dev branch to Qt 4.2. I'm sure that's what open source is all about.
Psi uses JDNS, which is part of the iris package. That's fairly much code to include for one tiny feature.
There's also another problem; murmur doesn't really support a concept of server farms, so we wouldn't be using the prioritizing and load balancing present in SRV, so it would just be a very fancy method of avoiding to write down the port number.
SRV also makes much more sense in the scenario where many servers cooperate to provide the same virtual service, whereas murmur is designed to have many virtual services on the same server. SRV breaks down when you want to have 10 different murmurs running on the same physcial box. I don't know if it's easier to write "clanA.voip.server" than "voip.server port 123".
If you can change my mind, I'll peek at adding support at least for Linux and Win32.
Sure the balancing feature isn't needed at the moment. The reason for giving the ability to use name based addressing instead of IP or port based addressing is, simply said, the same why DNS was invented. Because humans like to remember words better than numbers. On the other side the most people like it when they read or write their names! Possibly you could do it the host-header way HTTP does it. But it's less centralized to control and less RFCish.
Logged In: YES
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
This would be a nice enhancement because a domain may use a third-party VOIP hosting service. Users should only need to type the domain name (ex. example.org') into mumble instead of having users type a full-out subdomain likevoip.example.org' for the case where this is only one voicechat session at a site.
example.org') into mumble instead of having users type a full-out subdomain like
I would like to nominate this request for reopening, or at least initiate a new discussion on the matter.
Support for SRV records would allow for easier end user setup, and automated failover for larger installations.
As it is, server administrators are at the mercy of ISPs who do not honor the ttl on domain names. This makes automated failover difficult to implement, and in some cases it is completely impossible.
(an isp that forces a 12 hour ttl for example completely prohibits any realtime changes)
With srv records you can designate a priority order, allowing mumble to be aware of the primary and the secondary server at the same time.
This allows the client to automatically switch to using the backup server as soon as it determines that the primary in unreachable.
For gaming groups and hosting providers, being able to lose a server and force an instant reconnect to a different server can be a major advantage.
Use case #1:
Don is a web/email/chat hosting provider with 50 separate instances of murmur, and three sites at separate physical locations.
Currently, Don uses srv records for both web and email. When site #1 goes down, all connections instantly migrate to site #2 without any user intervention.
Don's DNS servers also instantly changes the dns A record for 'mumble.donsplace.com' to the ip address for site #2. This a record has a TTL (time to live) of 60 seconds.
Ideally, this would mean that after 60 seconds, all of Don's mumble users would attempt to connect to 'mumble.donsplace.com', and receive the updated A record for site #2.
Unfortunately, 30% of Don's mumble users are using "Slowlink ISP".
Slowlink forces an 8 hour dns TTL, so everytime Don switches services to a different site it takes 8 hours before Slowlink changes their local dns server to match the correct data.
Because of this, everytime Don has to switch to site #2, he loses several customers.
Use case #2:
Chad runs the murmer server for his Raiding guild.
He has a large internet connection at work, and his boss allows him to run the server from there.
Chad's guild leader also has a paid Virtual server with a limited amount of monthly bandwidth that chad can use as a backup for the server.
On tuesday night, chad's raid group is halfway through running a 40 person raid when his bosses girlfriend dumps a drink onto the router at the office.
Chad immediately changes the dns record for the mumble server to the backup, but only half of the group can connect to it immediately.
They spend the next 30 minutes explaining how to connect directly to the backup via in game chat.
In that time several members have to leave, and the raid has to be cancelled or rescheduled.
SRV records are an excellent and simple way to allow for the end user to implement a backup for their server, and allow for hosting providers to offer higher reliability.
I support the request for reopening
Qt still doesn't resolve SRV records, meaning this would be a non-trivial amount of work to get it working across all platforms for something that benefits very few users.
Qt can now resolve SRV records: http://qt-project.org/doc/qt-5.0/qtnetwork/qdnsservicerecord.html
SRV records are particularly useful for the mumble.com example of centralized hosting for gaming clans. Each gaming clan would have their own domain whose SRV record would point to their CNAME subdomain of mumble.com. This allows for maximum flexibility: the gaming clan distributes their own domain for connecting to, and mumble.com can dynamically manage the client subdomain CNAME mapping to real servers.
I.e. bravecollective.net SRV bnicomms.mumble.com:1234 CNAME m12.mumble.com A 18.104.22.168 -- a real DNS query chain, just using a CNAME subdomain on the bravecollective.net side at the moment. And if we could possibly avoid confusing our newbie gamers with the concept of a "port number" all the better.
Can we get this reopened since QT now supports SRV records?
Can you we please get this feature!
Since it's now been 10 months since this was reopened and 2 years since qt implemented the feature for us, I would like to again request that someone look into adding this.
This QT bug report contains the api code incorporated into QT if you need to look at it more closely.
I would also really appreciate SRV records support for mumble..
Will mumble support this anytime soon ... been waiting for awhile now :(
Would be great for running multible servers or setting up fallback solutions in case one server is going down all people would nearly instantly reconnect to an other mumble at an other server...
This post sounded way more passive aggressive than I intended. This feature looks like its been requested since ages so I imagine it may not be coming.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.