Subject: [P2PSIP] ICE Candidate Encoding

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jul 2008 12:05:02 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 24 Jul 2008 16:21:08 -0400

> well, it's gross, and not easy to parse if you don't do ICE.

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