On 06/04/2008 9:23 PM, Tim Julien wrote: Could you perhaps refrain from top-posting? It makes the conversation hard to follow. :)
> The message flow in section 2 (i.e., "happy path") seems good. Only > question I would have is maybe wrap the bytestream / ibb negotiation > messages in jingle transport-info messages. But I can see an argument > against that if the goal is to allow existing implementations to reuse > as much code as possible. Yes, that was the goal. > section 3.1 (Transport Selection) seems good, too. OK, great. > I share your anxiety with Fallback in 3.2 - doing the fallback after > session-accept. Can we modify the PENDING state to allow > content-replace? It seems like we have a real use case for it here. Part of why I wrote the Jingle file transfer spec was to see how the general Jingle state machine would work for more use cases. In the case of fallback, I think the answer is: not very well. We'd have the same issue if we tried to do fallback from XEP-0177 to XEP-0176 (say) for an RTP session. So to me that argues for allowing content-replace during the PENDING state. > I can also envision wanting to do fallback like this for anything that > wants to be non-lossy: > ICE-TCP fallback to -> ICE-RUDP fallback to -> IBB I *think* you're right. I do wonder about fallback in general, that is: when do you know that you need to fall back? In the case you show above, you might try ICE-TCP and it might start to work (you get most of the bits through) but the file is corrupted because you're missing some bits. I think you would have accepted the session by that point, but the transport wasn't as reliable as you would have liked so you basically need to start over. That's a different case than fallback from SOCKS5 to IBB, where you try SOCKS5 but your firewall configuration makes it impossible to use any of the offered streamhosts, so you never get any bits through and need to try IBB. So I think that fallback applies to situations where the transport setup simply fails and you need to try a different transport to get any media flowing at all, rather than the situation where the transport setup worked (send session-accept) but then you have subsequent media problems -- in that situation you'd send a content-replace in the ACTIVE state, whereas in the previous situation you'd send content-replace in the PENDING state. Does that make sense? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
