Peter Saint-Andre wrote:
On 05/30/2008 12:14 PM, Tim Julien wrote:
One of the first things I'm going to want to do is add ice-udp (we have
a reliable UDP impl) as a transport
Isn't reliable UDP different from UDP? Or would you just negotiate
ice-udp and if your UDP stack provides reliable UDP that would just fall
out from the negotiation?
I'm not sure if reliable UDP would be a new transport type or an
attribute / feature of the current UDP Jingle transports. I think I
would lean towards defining a new transport - if only to register it as
"reliable" as opposed to "lossy".
(and ice-tcp when we get that spec).
Yes, we need to define that one. It should be pretty straightforward.
Do you envision those negotiations occurring after session-accept, like
Socks5 and IBB in this spec, or before session-accept like in jingle
audio / video over RTP?
Probably before, since they would function just like ICE in the voice
and video examples (start sending candidates even before you receive the
session-accept).
I've mentioned it before, but just to beat a dead horse - its strange to
me to negotiate the initial transport in different states, depending on
which transport you are negotiating. I find it confusing, and from an
implementation perspective it will probably make things alot more
complicated because being in the ACTIVE state doesn't tell you anything
about whether you have negotiated a transport. Also, this is counter to
all other Jingle specs to date.
From the Jingle spec (166) section 5 (Concepts and Approach), check out
items 3 and 6 in the sequence of events:
...
3. The parties attempt to set up data transmission over the designated
transport method as defined in the relevant specification (e.g., this
may involve sending multiple transport-info actions).
...
6. As soon as the responder determines that data can flow over the
designated transport, it sends to the initiator a session-accept action.
Seems like negotiating initial transport after session-accept breaks that.
/psa
