SIP user agents provide a User-Agent header in requersts, and Server header in responses, just like in HTTP.
Many applications make use of this header to collect statistics on the devices in use, how popular they are, and the versions begin run. A common way of doign this is using a file called 'browscap.ini' which is kept up to date with all the user agent strings known in existance, along with the features they support.
While SIP provides far richer protocol semantic support for support features, being able to match user agent strings is very useful for service providers providing service to generic SIP clients, as it can be used to inform users when they are running an out of date version of firmware, a device with a known bug in, or provide links to information on configuring their device or a user manual.
We keep the file up to date and make it publically available. Please let me know about any additions or modifications, new devices, vendors, or firmware, known serious bugs in versions of firmware, or releases they are fixed in. You can contact me by email.
Note that a user agent is free to send whatever useragent string they wish, and this file should really not be used for SIP level handlign based on a user agent header. However, saying that, it could potentially be useful for short term fixes, just like apache uses the HTTP cousin for SSL fixup for broken IE browsers.
The latest version of the XML file itself is here.
I'd like to urge vendors to provide useful strings in user-agent and server headers, as it allows providers to offer far more targetted support to users of your devices, inform them quickly of known bugs in the device or paticular version or firmware they're running, and provide them with exact configuration settings for the version of firmware or model they're running.
Please ensure that you include at the very minimum:
Good examples you can find in the file already are:
Not such useful strings are:
A number of vendors include MAC addresses in the User-Agent string, presumably for some custom provisioning system. There are some major privacy issues involved in doing this, and should be avoided.
Showing the version number may aid an attacker in finding paticular known vunrabilities in a software version, so it's recommended that the version number not be sent in a Server header response, and only sent in a User-Agent request which there is only trusted SIP elements between the UAC and UAS - That limits it pretty much to REGISTER on known trusted networks. Note that including the software version number in REGISTER requests can really help providers a lot with providing support to end users.