audioSubscriber.getNetStreamInfo error/bug BEWARE-DINGOS

[esteimle]

Not sure if this is a bug or just me abusing things. I get the following error when I do what I describe below:

TypeError: Error #1010: A term is undefined and has no properties.
    at com.adobe.rtc.collaboration::AudioSubscriber/getNetStreamInfo()[C:\work\main\connect\cocomoPlayer10\src\com\adobe\rtc\collaboration\AudioSubscriber.as:412]
    at com.desktop.view.videoChat::videoChat/stats()[/Users/eric/Documents/Flex Builder 3/betty/src/com/desktop/view/videoChat/videoChat.mxml:190]

I have two clients:

HSTEIMLE, using an instance of our air client

ESTEIMLE, using an instance of our web based client

I make a video call from ESTEIMLE to HSTEIMLE.  Once that call is set up, on the HSTEIMLE client I do a:

var test:Object = session.streamManager.getStreamsOfType(StreamManager.AUDIO_STREAM);

And I get an object containing two streamDescriptors:

EXT-ESTEIMLE-ESTEIMLE

EXT-ESTEIMLE-HSTEIMLE

Now I couldn't really see which one was going in which direction so I used my audioSubscriber and tried this:

var test2:NetStreamInfo =  audioSub.getNetStreamInfo("EXT-ESTEIMLE-ESTEIMLE");

this returns a valid NetStreamInfo result

var test2:NetStreamInfo = audioSub.getNetStreamInfo("EXT-ESTEIMLE-HSTEIMLE");

it fails with the error above for this case

Now the thing that leads me to believe this could be a bug is if I do the same thing with a nonsense word it's fine for example:

var test2:NetStreamInfo =  audioSub.getNetStreamInfo("EXT-BEWARE-DINGOS");

in this case null is returned.

I wonder if this could be because in AudioSubscriber.as, the getNetStreamInfo function first uses streamManager to get a stream descriptor based on the publisherID passed to it.  So it will get a valid streamDescriptor because it does exist in the streamManager.   However the next thing it does is look up that streamDescriptor in it's local netStreamTable.  It won't be there though so it will throw "the term is undefined and has no property error" at this line return this._netStreamTable[streamDescriptor].info, because this._netStreamTable[streamDescriptor] does not exist?

Just a thought and since I ran up against it I thought I'd report it.

-Eric

[Former Community Member]

Hi Eric ,

I bet you are right. Basically, it should check either the netStreamTable has the stream of if it's me who is the publisher( because in that case, the netStreamTable will not keep a local copy of my own audio).

I will get this minor fix and get in before next release which is coming very soon as I mentioned earlier.

And so Currently , you will get NetStreamInfo of streams of all users except yourself on your subscriber.

Thanks again for pointing issues. Moreover, from coming release , you will have all source codes :).

Regards

Hironmay Basu

[Former Community Member]

Hi Eric,

As an added Info, I think you can get info about your own stream from the AudioPublisher by calling audioPublisher.netStreamInfo . The AudioSubscriber will continue to return null if you call with your publisherID since you don't subscribe to yours.

Thanks

Hironmay Basu

[esteimle]

Thank you for both responses. How do I tell which stream is the one I am

receiving from the other client? Should I just use the publisherID in the

streamDescriptor?

Also is that publisherID in this format EXT-ROOMNAME-USERNAME?

Thank you,

-Eric

[Former Community Member]

Hi,

Yes you can use streamdescriptor's publisherID. There is not a specific format and its generated but publisherID is the same as the userID of the user who is publishing. So, if the streamDesc.streamPublishedID != _userManager.myUserID , then its other user stream.

Thanks

Hironmay Basu

[esteimle]

perfect thank you

[Raff_]

The format of userIDs generated by external authentication tokens is:

EXT-<accountname>-<userid>

Where accountname is your account name (not the room name, userIDs are global in your account)

And userid is whatever id you pass to Session.getAuthenticationToken (name is the "display name" for your user, id is the unique identifier for your user)

In the next version of the server-side scripts you'll find a new getUserID() method, but all it does is building the EXT-<account>-<userid> string.

Still you will not have to "guess"

[Marc_Speck]

If somebody else cares, the format of the userId seems to be now

EXT-<accountname>-<userid>/<usercounter>

For example, if Hugo logs in with a second instance of Flash, the userId looks like "EXT-mycompany-hugo/2".

The displayName also gets the usercounter attached, e.g. "Hugo Miller 2".

[Raff_]

If there a user connects multiple times to a room you'll see multiple userIDs with the counter as you describe.

Note that this is true both for external authentication than regular authentication (but if you are using guest users, they'll have a different GUID even if they have the same name so you'll never get the /#)

The format of external authentication ids is what you describe (EXT-). Note that the server-side scripts have a method (getUserID) that will return the correct format, just in case some day we decide to change it.

[Marc_Speck]

Thanks for the additional information. Because you mention Session.getUserID(), some feedback from my side:

- I need the parameter "id" that is passed into Session.getAuthenticationToken() also on the client side. This allows to link the AFCS users to users of my apps.

- There is no method to extract the parameter "id" from e.g. the MessageItem.publisherId(), .recipientID(), .associatedUserID()

- It was confusing that userID is not the parameter "id" passed into Session.getAuthenticationToken().

- A class UserID on the server and client would help. Besides others, it should have UserId.customId().

Just some thoughts...

Marc