there is no event for the case you're talking about.
until the RTMFP session is open, the target doesn't know the peer ID of the peer attempting the connection (the Initiator Hello packets only have the destination peer ID).
until the subscribing peer sends the 'play("streamname")' command down a NetStream control flow on an open RTMFP session, the target doesn't know if the connection was for groups or DIRECT_CONNECTIONS (or both, since both can be multiplexed on the same RTMFP session).
for more detail on how RTMFP works and why it is the way it is, take a look at Matthew Kaufman's slides from his presentation on RTMFP at IETF 77:
But I don't understand, during "UDP hole punching process", rendez-vous service sends to target peer the initiator peer id (and address), it's forced, no? So the peer target could know that a P2P connection is trying.
In the AS3 code we don't know it, yes, however it could be a improvement, because these information is available no? I am wrong?
Indeed, if both peers know that they are trying to etablish one P2P connection between them, they could create a "server bridge" while the P2P connection is attempting (not successfull).
no. the rendezvous service doesn't send the peer ID of the initiator to the target.
your application logic can inform the target that a connection is incoming through an out-of-band communication channel if you write it that way. for example, the "VideoPhoneLabs" example on the Cirrus Labs web page uses Cirrus's "short message relay service" to send a call notification to the target.
Jozsef recently posted to another thread in this forum a short code snippet that can be used with FMS to duplicate that relay function.
Ok, and really thanks for this details :-)