| commit | 6d9e032232b872d2386451b129e271260b179883 | |
| author | Jakub Adam <jakub.adam@ktknet.cz> | |
| Tue, 12 Aug 2014 08:10:04 +0000 (12 10:10 +0200) | ||
| committer | Jakub Adam <jakub.adam@ktknet.cz> | |
| Wed, 27 May 2015 06:42:53 +0000 (27 08:42 +0200) | ||
| tree | bacd4b269f56309ee1e23ec032a37850d66cc333 | treesnapshot (tar.gz zip) |
| parent | e13d3ea255051f76d75ce4d2ec68c0393c4d1669 | commitdiff |
media: align TCP RTP+RTCP candidate pairs
Lync uses a single TCP connection for both RTP and RTCP, and also
expects the components within each candidate pair we offer to have
the same priority, IP, port, etc.
However, libnice initially creates distinct TCP candidate pairs and
it's only later, when a candidate pair is established, that connection
can be switched to mux (single-TCP-channel) mode (see e13d3ea2).
Consequently, because libnice gives us distinct pairs, the application
itself is responsible for offering our candidates in a format Lync
expects, and thus presenting TCP-pairs as duplicats which differ only
in component type (RTP or RTCP).
Lync uses a single TCP connection for both RTP and RTCP, and also
expects the components within each candidate pair we offer to have
the same priority, IP, port, etc.
However, libnice initially creates distinct TCP candidate pairs and
it's only later, when a candidate pair is established, that connection
can be switched to mux (single-TCP-channel) mode (see e13d3ea2).
Consequently, because libnice gives us distinct pairs, the application
itself is responsible for offering our candidates in a format Lync
expects, and thus presenting TCP-pairs as duplicats which differ only
in component type (RTP or RTCP).
| src/purple/purple-media.c | diffblobblamehistory |