if you're talking about using the 1:1 APIs as illustrated in VideoPhoneLabs, then the subscriber must still know the peer ID of the publisher. and the publisher's peer ID is ephemeral; it is new for every new NetConnection, and it is cryptographically pseudorandom and cannot be influenced or predicted.
so the subscriber(s) still need some way to learn the ephemeral peer ID of the publisher, perhaps via a web service or something. a one-way exchange will probably be easier.
of course, in this model the publisher is sending a separate copy of the stream for each subscriber who's watching it. this is not scalable to more than a few subscribers.
there's also P2P multicast, but the latency there will be even higher than with FMLE and FMS, and the stream must fit into the average *upload* capacity of the subscribers. but as long as you stay within the average upload capacity of subscribers, you can scale up indefinitely.
Thanks Michael. I've experimented a little and can now clearly see that
saving an old number doesn't work. No way to activate it again. The word
'group' came up in one of the older programs and I tried it in cirrus.
It does not appear to use a web service (at least not a visible one) It
only exchanges text although it displays the local cam. Is a 'group'
some previous scheme to exchange usernames?
An idea I tried was to write two versions of the program, one for the
publisher and one for the subscribers. Run the publisher program first
and copy its number into the code for the subscriber version. Keep the
publisher program running. Compile the subscriber program with the
publisher's number in the code. As long as the publisher does not shut
off the program, subscribers can run their version and connect. Stupid,
yes, but if one is desperate, it does work.
Also, there seems to be a 320X240 size limit on the video images
transmitted. No matter which parameters I change the image (distant peer
image) remains the same size. I can adjust the size of the local video
image ok, but the incoming image is pretty small. Is that a limitation
there is no limit to the size of video images you can send with P2P. you set the capture resolution (and fps) with Camera.setMode().
"RTMFP Groups" refers to self-organizing P2P mesh networks. these meshes support several different communication modes which are distinct from the 1-to-1 P2P that you have seen with VideoPhoneLabs. most of these modes are accessed via the NetGroup object. however, you use NetStream, only constructed with a "group specification" instead of a peer ID (think of it like a "peers ID"), for P2P multicast streaming (since NetStream is the natural interface for video streaming).
for more information about RTMFP Groups, i strongly recommend watching Matthew Kaufman's session from MAX 2009 and my session from MAX 2011:
and also to go through my labs from MAX 2009 and 2010:
the real MAX 2009 archive site seems to be offline, so i put copies of the materials on my computer. the lab from 2009 is probably more relevant, especially for getting started with multicast.
also, see the files i attached to this thread, which are slightly modified versions of my MAX 2009 lab: