On 06/04/2008 10:08 AM, Tim Julien wrote: > 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".
Right, that seems appropriate. I hadn't realize that many people have implemented RFC 908 / 1151, but you learn something new every day. ;-) >>> (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. OK I will think about that some more, but I need to perform some surgery on the other Jingle specs first, per list discussion. I think you may be right but I want to complete those other edits first. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
