Cullen Jennings wrote:
The current draft uses a string encoding for ICE candidates ripped off from when it had to be represented in SDP. This has the advantage of easy compatibility with ICE stacks, but the disadvantage that, well, it's gross, and not easy to parse if you don't do ICE. _______________________________________________ P2PSIP mailing list P2PSIP at ietf.org https://www.ietf.org/mailman/listinfo/p2psip
Jonathan's current ice-nonsip draft has a brief section on what parameters are required (http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01.html#section-5.2.2). Assuming this draft starts to get traction, I would like to suggest reload discusses its requirements in reference to this draft (single component, no default candidates, etc, etc) and then specify a binary encoding of the parameters using the same syntax as the rest of reload. (unless ice-nonsip evolves into something that specifies an encoding itself.)
From my experience and talking with others who have implemented ICE, the on-wire encoding is a pretty simple translation thrown on top of the ICE library, so there should be no reason to preserve SDP syntax.
Bruce _______________________________________________ P2PSIP mailing list P2PSIP at ietf.org https://www.ietf.org/mailman/listinfo/p2psip