Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
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).
Nathan Phillip Brink
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