Requirements for choice of transport
Currently, the known transports are:
- Raw UDP
- google-p2p (libjingle 0.3 pseudo-ICE)
- ICE-UDP
Requirements:
- For each transport that Gabble can signal, it must be able to know whether to set the XMPP capability for that transport (solved in smcv's branch)
- For each of RTP audio and video, Gabble must be able to know whether to set the XMPP capability (solved in smcv's branch)
- For each contact, Gabble must be able to tell clients whether we can make audio and/or video calls to them (solved in smcv's branch)
- For each transport that Gabble can signal, it should be able to know, when a channel is requested, whether the client that will handle it can do that transport:
<ptlo> smcv: in xmpp, cm is in the best position to pick one of the available transports (~~ nat traversal mechanism), but the list of supported mechanisms has to come from farsight <ptlo> so e.g. farsight reports google-p2p and ice-udp, and then gabble can pick google-p2p for contact that only supports that, or ice-udp if contact supports it because it's preferred <ptlo> so Tp client has to tell CM somehow what's supported; the general idea is to pass it as optional parameter in channel request (see my channel requests branch that implements it halfway) <ptlo> the hard part is incoming jingle sessions (deciding what to advertise as supported transport, for example, without waking up all media handler clients and asking them for what they support; also, responding to session-initiate with preferred transport before knowing which transports are supported) <ptlo> so yeah, at least for xmpp, cm should be able to choose, but the choices should come from fs