Bug 13158 - support Jingle raw UDP and ICE transports
Summary: support Jingle raw UDP and ICE transports
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: high enhancement
Assignee: Will Thompson
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/wj...
Whiteboard:
Keywords: patch
Depends on: 22458
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-09 05:23 UTC by Robert McQueen
Modified: 2009-06-29 05:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert McQueen 2007-11-09 05:23:14 UTC
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.
Comment 1 Senko Rasic 2008-12-02 10:27:36 UTC
With the refactored Jingle engine in 0.7.16, it should be
straightforward to implement raw UDP and ICE UDP support.
Comment 2 Will Thompson 2009-06-27 09:45:59 UTC
I've brought up-to-date Senko and Sjoerd's branch; it took quite some merging, but seems to work now. :)
Comment 3 Sjoerd Simons 2009-06-28 06:23:58 UTC
- 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)
Comment 4 Will Thompson 2009-06-28 08:56:12 UTC
(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.
Comment 5 Will Thompson 2009-06-29 05:29:27 UTC
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.