LOL.. you might.. but you still won't :p ok maybe you can, assuming you know a bit about stun/ice/turn (you can read the rfcs).. basically, the current problem is that we have two types of 'invite', one which uses ICE and the other which doesn't...
if we don't use ICE (raw udp), it means we just use a normal UDP socket an we send/receive with that.. we use STUN to allow the traversal of the NAT by mapping our internally allocated port to an external port opened by the router for our UDP 'answers' to reach us.. (it thinks we sent a message and we expect a response, so it forwards the response to us, while in fact we are receiving the actual data.. that's what stun is used for, you send an outgoing message, the router remembers your internal ip/port and when it receives an answer on that port, it redirects it to you thinking it's an answer.. so you send a STUN (udp) message, and wait for the reply).
With raw udp, we can only send/receive to one ip/port.. with ICE you have multiple 'candidates' (which are just ip/port combinations)... so if you're both in separate locations, you send your external ip/port, and it works, but if you're in the same local network, it doesn't work because you only have the external ip, and the routers usually don't allow a packet going out and coming back in.
The thing is that if we use ICE, we will send multiple candidates, like candidate 1 : internal ip/port, candidate 2 : external ip/port, candidate 3 : a relay server in case internal AND external failed to work (rare). That relay server which is used only when both users are in symmetric NATs where the router is smart enough (5% of the cases?) to blablabla read STUN and NAT traversal to know why it would block those packets :p
anyways... the thing is that during the negociation you give it these 3 (or more depending on how many internal interfaces you have) ip/port combinations... and ICE will try to connect to each one (depending on priority, local network has higher priority than going through the external network) and it will fallback on the relay server (called a TURN server). There's also an interesting fact, when you send your ICE candidates during the negociation, you also send a single 'ip/port' (usually also found in the ICE candidates) for those clients who do not support ICE so they can fallback on it.. and MSN uses the TURN server as the fallback.. and the reason is... I just found out about it in the TURN draft 2 that M$ might be implementing :
TURN specs say that you must request from the TURN server an 'allocate' which simply means you tell it to allocate an ip/port for you on the relay server, it will give you that ip/port and you use that as you ICE candidate... what happens is that the first person to send a packet to that ip/port will be remembered by the server and it will send any data it receives from it back to you (it remembers your ip/port when send the request to allocate the resource)... and in the same way, whenever you send something to it, it will send it back to that person that connected to it...
This means that what we could do is that for WLM users, we could 'accept' the ICE request instead of rejecting it, then just use the relay server which will guarantee that it will work.. problem is, not sure about the bandwidth... maybe the sound will be a bit less 'smooth'... but anyways, at 2KB/s I don't think it will be much of a problem!
so that's my idea.. to summarize it.. always use the TURN (relay) server when talking to WLM so it can always get our data
oh.. and by the way, if you're wondering why we can't just use the ICE candidates we received, since we receive all 3 ip/port addresses (internal, external, relay).. it's simply because if we use the internal or external ip, then it's not TURN, it's just normal ICE, and that needs authentification.. you see an ice candidate is not only an ip and a port, it's actually a username (random), a password (random), a media type (rtp or rtcp), a transport (udp or tcp), a priority, then the ip and port.. that's for each candidate (so you get 6 (rtp+rtcp) candidates for your internal/external/relay and each one has a different username and password).
ICE is made to receive a lot of candidates (all internal, external (server reflexive and peer reflexive)) and only choose one as the 'selected pair'.. so since it's UDP, you have no way of knowing if the packet arrived or not, so it uses STUN to authenticate and make sure we are talking to the righ person (it doesn't want you to send your video/sound to someone other than the person you want to send to) so it sends a STUN request with *our* username and an sha1 hmac hash using password, so we know that it's the right person sending the request, and we answer it likewise (using their username/password), once and only once it receives an authenticated response to the STUN request, will it then 'elect' that candidate pair (our candidate + the remote's candidate) and start streaming to it... since we don't reply to the STUN message, it thinks that ip/port combination gets bumped on a firewall, so that candidate (or that ip/port) is useless..
it will only elect one candidate pair because if you have many candidates (in my case, I get 12 candidates), you don't want to send the same data to all of them (12 times the bandwidth usage)...
so we either have to answer to the STUN request, or use the TURN server which doesn't need STUN (I think)....
and why don't we just answer the STUN request instead of all that? simple.. we use farsight, we use gstreamer, we use a raw udp transmitter.. first, that raw udp transmitter can only send to one ip/port, so we can't just give it all the candidates we received, and assume it will work... also, because we have no access to the data unless we start playing with the gstreamer pipeline.. and I don't want to do that!!! and also because a 'ice transmitter' will very soon be ready which will take care of all that for us!!!
I hoe this explanation was good enough, I tried to make it as detailed and simple as possible :p
