[MMUSIC] Using connectivity check to carry additional candidates [was Re: draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice]

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/04/2013 12:07 PM, Alan Johnston wrote:
> I admit that my first thought was that UPDATE was more appropriate than
> INFO.
> 
> But the more I think about it, trickling in new candidates is not
> necessarily a part of O/A, rather it can be thought of as communication
> between two ICE Agents. For tunneling another protocol using SIP as
> transport, INFO is the right choice.
> 
> Not every ICE candidate is signaled in SDP - Peer Reflexive Candidates, for
> example.

True.  But so why not push the idea further, and use an in-band mechanism to
send the newly discovered candidates?  E.g. the Offerer still sends the full
list of candidates but the Answered uses the same path than a successful
connectivity check to send its candidates as it discovers them, using a new
STUN transaction.  The Offerer will add the candidates received in this new
transactions more or less in the same way Peer Reflexive Candidates are added,
and start connectivity checks in the other direction. The answered will send
its answer only when it has collected all the candidates on its side, making
it identical to non-trickle ICE.

Obviously there is lot of details missing here, but that solution does not
require UPDATE or INFO, or a=ice-options:trickle.  It's probably not
compatible with non-SIP trickle implementations, but perhaps a gateway can
convert candidates in the signaling path to and from candidates in the media path.

> 
> And remember ICE has a second O/A exchange that brings the SDP into line
> with the chosen candidate pair.
> 

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRXhhmAAoJECnERZXWan7EiuEP/AtJycZvB/8Qi23OBu2Nla+5
SKniH7J139IQy6v2gEoAfDweuwcwYIH2lgX78bQMXNm/1P42zkqwTuvGtFEGej2b
Q1ln6VkSnYhujjg2kP1iRntQhcI7wgSWa+w32MkHD1HPtuD1eoyVhSD+XYNGZBBO
1IN69JTzlOw2ygYUWBGS5ni7GyoHnAmAXIK3gDbtHys9ENBt3eI+6+0eTL3Bco+h
BfYeG96ubnO2/H9Qbop1/Q8HjygxySWIeUf8m1ZLelnmMU019UeHGdyq2+tuLo8V
yzS+3jwptEx9lendnxJUyMv4BLcx1Gx/3TEuyCkRolCef3etjrlTaP6Qmnfvztpe
OkHR3WAKMIqRRMXHVqd+9QqQOWAosEL6utXBQzDqtZQmdmY9Qqiu8JOvP8GGNxKo
2uUAKSceguGl5T46/j4zQd1WGMArgg3rPAOPhSy1zl3ycC67S4u0zFNG2KvDWbaF
W+xzlTuQMzoHerCQdrTdxWWZCi4ngfEDtSVxAtZxDOiXs8TpwFHX1cEpjDKPMYln
/MIbWSjE/ORSB8DU7OMADhsJft3S9RqVxd+ia1cM+rVYp1kDPsD8yE94pkf/kb9s
8EdFOpBpl4gPXLG2o+ffYKSBsolFzl6K/0vHtkLj/2AJCzmd9eDs8m3Xs55JaUy1
KAfPUaz3+CDBE8uCypSs
=Ov6n
-----END PGP SIGNATURE-----