Do not, ever, send this caps element in another client to mimick its behaviour.
Read JEP-0115 why, but I'll explain below how it should work:

The idea is a caps element has the 'node' attribute that stands for a certain client 'brand', the 'ver' attribute for a specific version. A client that receives such an element, should send a disco (JEP-0030) query to the originating client to determine the supported features. The result should always be the same for each 'brand'/'ver' combination.

Then, if the client also has some dynamic behaviour with regard to supported features (for example, by way of plugins or features that can be turned on and off), those features can be announced in the 'ext' attribute. Note that all the identifiers are opaque and specific to a certain 'node'. For each 'ext' attribute, separate disco requests can be made to determine the associated features.

Now, I suspect that Google doesn't actually do the discoing. And this is because a client that receives the exact same 'node'/'ver' combination it would send itself (same client), it would already know the feature set. A client must never do the disco-ing in this case. This of course excluding the 'ext' features.

I don't know if Google Talk does indeed implement disco, but try that. If it responds with a certain feature set, see what that is. The 'ext' element suggests the voice stuff is optional, so you might have to disco separately for that.

If discoing works, implement responding their features to a disco request, along with your own caps element. Read JEP-0115 on how it should work in detail.

Let me know about your findings (via jdev, for example).

testing comments