1) when the other end closes the browser, there's barely enough time to send the abrupt session close messages on all RTMFP sessions, so there's definitely no time for the multiple round-trips that would be necessary to reliably transmit some kind of "i'm shutting down now" message, wait for acknowledgements, and then shut down the sessions. at the end that's still running, the abrupt session close is indistinguishable at the RTMFP level from many other error conditions, including the "i never got a session up in the first place" case. at the application level, you could certainly make a note of whether data had ever been received and change your interpretation of the NetStream close event.
2) the 90 second timeout is not configurable, and is a worst-case try-really-hard period for trying to get communications working. if your application doesn't need to try that hard, you can set a timer in ActionScript for a shorter time, and if it fires before you get connected you can abort.
Thanks Mike, that makes sense. Regarding 2), do you have a sense for how long it would typically take to punch through most firewalls?
given how RTMFP's UDP hole punching scheme works and under good conditions, it shouldn't take more than a few seconds to get through most firewalls/NATs if it's possible to do so. if you are using a TURN proxy with Flash Player 10.0 or AIR 1.5, it could be up to 10-15 seconds.