Although we were the first in the world to support Jingle (XEP-0166 and friends), at the time Farsight only had support for the transport used by Google Talk, as implemented in libjingle, which is an early form of ICE, so this is the only <transport> we implemented in Gabble. However, most other implementations of Jingle from scratch will use XEP-0177 (raw UDP) to start with, and XEP-0176 (ICE) is generally agreed to be the most preferable transport for client use. Subsequently Farsight and Stream-Engine have grown support for raw UDP (ie what SIP does) transports, and libnice support is on its way soon as the IETF finally standardises ICE, so we need to support these standard transport namespaces or watch our Jingle implementation pale into irrelevancy as we are unable to interoperate with anyone but Google Talk and some N800s.
With the refactored Jingle engine in 0.7.16, it should be straightforward to implement raw UDP and ICE UDP support.
I've brought up-to-date Senko and Sjoerd's branch; it took quite some merging, but seems to work now. :)
- jingle-transport-iceudp: * parse_candidates: shouldn't stop parsing the candidates when it considers one to be not valid. * parse_candidates: should the foundationtion and use that as the id * inject_candidates: priority usage string seems fine? * inject_candidates: multiple c->preference by 65536 to match tp-fs * inject_candidates: don't invent your own foundation strings, tp-fs gives them to you as the candidate id in NewNativeCandidate * inject_candidates: don't assert when you get a candidate type you don't expect * inject_candidates: don't assert when you get a protocol you don't expect * inject_candidates: What's the name attribute for the candidate? * new_local_candidates: state variable is retrieved but never used - jingle-transport-rawudp: * parse_candidates: - FIXME : you don't care about stun vs. local * inject_candidates: id == c->username ?? * new_local_candites: state variable retrieved but not used * new_local_candites: you can assert that pending_candidates == NULL if priv->local_candidates was NULL * new_local_candidates && can_accept: nitpick: this only works correctly because tp-fs gives exactly one rtp and one rtcp candidate in one call to NewNativeCandidate and only calls that once with the best candidate (i think). In a prefect world we'd batch all the candidates untill NativeCandidatesPrepared is called and then pick the highest preference rtp candidate to send out. (and error out if there is no rtp candidate)
(In reply to comment #3) > - jingle-transport-iceudp: > * parse_candidates: shouldn't stop parsing the candidates when it > considers one to be not valid. > * parse_candidates: should the foundationtion and use that as the id > * inject_candidates: priority usage string seems fine? > * inject_candidates: multiple c->preference by 65536 to match tp-fs > * inject_candidates: don't invent your own foundation strings, tp-fs gives > them to you as the candidate id in NewNativeCandidate > * inject_candidates: don't assert when you get a candidate type you don't > expect > * inject_candidates: don't assert when you get a protocol you don't expect > * inject_candidates: What's the name attribute for the candidate? > * new_local_candidates: state variable is retrieved but never used > > - jingle-transport-rawudp: > * parse_candidates: - FIXME : you don't care about stun vs. local > * inject_candidates: id == c->username ?? > * new_local_candites: state variable retrieved but not used > * new_local_candites: you can assert that pending_candidates == NULL if > priv->local_candidates was NULL Fixed. > * new_local_candidates && can_accept: nitpick: this only works correctly > because tp-fs gives exactly one rtp and one rtcp candidate in one call to > NewNativeCandidate and only calls that once with the best candidate (i > think). In a prefect world we'd batch all the candidates untill > NativeCandidatesPrepared is called and then pick the highest preference > rtp candidate to send out. (and error out if there is no rtp candidate) I haven't implemented this; if this isn't a merge blocker, I'll file a wishlist bug.
Merged; will be in 0.7.30. \o/
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.