If you look at our error code documentation, you will see that this error code is Errors_Invalid_Parameter. Upon inspection of your JWT payload, the culprit appears to be the tpc field. This field must be equivalent to the sessionName parameter, which in your case would be yksession.
@jon.zoom ,
thank you for your suggestion. Unfortunately, it does not work - problem persists.
Are there any limitation on user identity? Looks like it is almost “hardcoded” - test_ + Build.MODEL
JWT is definitely valid, i verified it with jwt.io - using SDK key as apiKey and apiSecret for signature verification.
@jon.zoom ,
i think i found a problem. Looks like sessionContext.userName for the session and user_identity in JWT should be the same
Please let me know.
Thank you
Yevgeniy
You definitely do not need the userName and user_identity values to match. The username is meant to identify a user by other users in a session, commonly by using their actual first/last name. The user_identity field on the JWT is meant to act as an identifier you can use to differentiate between users in your own system (e.g. for tracking which accounts were in a session).
Did you make any other changes aside from those fields? I can successfully join a session when using different values.
@jon.zoom ,
no additional changes.
i tried from two different phones and i was able to share session. while session name is the same, user names are different on each phone - but on each phone user_identity in JWT and userName in a session context are the same.
I will try tomorrow change it back and will let you know
thank you
Yevgeniy
@jon.zoom
yes, sorry for delay, i started by using two different phones to troubleshoot the issue.
Looks like is it not necessary for both elements to have the same value - you are correct.
However, after additional troubleshooting with multiple test i found that test_SAMSUNG-SM-J320A - does not work te-st_SAMSUNG - works.
Can you please try “test_SAMSUNG-SM-J320A”? looks like characters do not matter, maybe size?
In case of the demo code, the value is “hardcoded” as
public static String customIdentity=“test_”+ Build.MODEL;
Considering that my phone model is SAMSUNG-SM-J320A…
So when i change this value to userName, which is shorter, it started to work.
There is a character limit on the user_identity field of 15 characters. It looks like this limitation was mistakenly removed from our documentation, so apologies for any inconvenience as we revert that change.
Hi @jon.zoom ,
that definitely explains
i guess demo code should be fixed also.
As for parameters,
SDK secret for a signature creation, i assume that API is an account identifier,
but what is a purpose of user identity? looks like it does not correspond to the user name on UI, so for tracking purposes in session dashboard?
and password - is it password for session or user identity? looks like for session…
Thank you
Yevgeniy
We can definitely look into adding a character limit for the value generated in the sample app, that’s a good idea!
SDK secret for a signature creation, i assume that API is an account identifier,
The account identifier is actually the SDK key. The secret is used to sign the JWT. If you’re interested in learning more about the how/why or JWTs, the spec can be found here.
but what is a purpose of user identity? looks like it does not correspond to the user name on UI, so for tracking purposes in session dashboard?
This allows you to provide your own tracking identity to a participant in a session. For example, if you generate an ID for each user when they register in your system, you could provide that ID so that you can associate the user’s information on your servers with the ZoomVideoSDKUser object in a session.
We also do not require that these values are unique, so another potential use case could be setting this value to identify a specific type of user.
and password - is it password for session or user identity? looks like for session…
The password is for the session. If you are the first person joining the session (i.e. the user creating it), this is optional. If the user creating the session includes a password, it must be provided by any other users who wish to join that same session.