When displaying Playbacktime video for an extended period using WebRTC JavaScript on XProtect Professional+ 2024 R2, the video stopped after about 4 hours.
The WebRTC session appears to remain in the “connected” state, but no UDP packets seem to be received. Please explain the cause and how to resolve this issue.
Specifically, after the WebRTC video stops, if you check the area in the red box in the chrome://webrtc-internals tab in Chrome,
you can see that the “Bytes sent” for UDP is still updating, but “received” is not, so it appears that XProtect is no longer sending video.
The WebRTC Javascript sample automatically refreshes the token, which expires after 4 hours. I wonder if you are using an old version of the sample?
See refreshToken (which is called by a timer) https://github.com/milestonesys/mipsdk-samples-protocol/blob/main/WebRTC_JavaScript/js/tokenCommunication.js
Thank you for your response. The information is very helpful.
If I use the 2025 R1 sample in an environment with 2024 R2 or earlier, will the current issue (stopping after 4 hours) occur?
We are currently checking, but it is possible that we are using the 2025 R1 sample with XProtect 2024 R2.
Also, if we use the 2024 R2 sample with XProtect 2024 R2, will there still be a problem where it stops after 4
Do you see the refreshToken method in the sample you are using?
The newest sample (currently 2025R2) should work without issues in XProtect 2024 R2.
Again, please tell me about the 4-hour timer.
Currently, referring to WebRTC JavaScript 2024 R2, WebRTC session maintenance does not use refresh tokens, but instead re-acquires tokens every 30 minutes (half of the 1-hour access token duration).
The acquired tokens are added as bearer tokens in headers when making REST API calls and retrieving ICE information.
Given this, if tokens are not updated through refresh, will the WebRTC session be disconnected due to the 4-hour timer mentioned below? https://supportcommunity.milestonesys.com/s/article/modify-XProtect-Advanced-and-XProtect-Plus-token-timeout-value-to-avoid-Invalid-Token?language=en_US
Thank you for your response.
After implementing access token refresh using refresh tokens, I confirmed that WebRTC sessions no longer disconnect even after 4 hours have passed.
If you know and could share for reference, please let me know the minimum and maximum values for ClientTokenTimeoutMinutes."
Please do not configure a long time out value, it is essential that clients can refresh the token and that is the reason the sample can do it. The best description of token timeout is in the knowledge base article you already referenced. - https://supportcommunity.milestonesys.com/s/article/modify-XProtect-Advanced-and-XProtect-Plus-token-timeout-value-to-avoid-Invalid-Token?language=en_US
There is a note to that article: "Whilst the above theoretical maximum value of the ClientTokenTimoutMinutes is 2147483647, we have done some testing “around the board” and have found a maximum value of 71587. This equals just over 49 days and should be sufficient for any “normal” reasons you would like to increase the timeout. "
Please let me know additionally. I am looking for the following documents. Please tell me where they are located:
- Interface specification document for obtaining tokens from XProtect (/api/IDP/connect/token)
- Documentation that explains the relationship between tokens and timeout values
To my knowledge there are no such documents.
Please note that confusingly there are two types of tokens, the tokens you can get from the Identity Provider (/api/IDP/connect/token) and the legacy tokens you get from the Management Server. I believe the relation between the two forms of token is best described here.
Thank you for your response regarding the documentation. I will review and refer to it.
We successfully bypassed the 4-hour timer by updating the access token using the refresh token. However, now the WebRTC session is being disconnected due to ApiGateway AppPool recycling. Therefore, please provide information on the following three points. If necessary, I will split them into separate POST questions.
1.Reasons why WebRTC sessions are disconnected at the timing of VideoOS ApiGateway AppPool recycling
I am using WebRTC javascript 2024 R2 for long-term Live video display, and as mentioned in the information below, I have confirmed that the WebRTC session disconnects and reconnects at the timing of VideoOS ApiGateway AppPool recycling.
https://developer.milestonesys.com/s/question/0D53X0000DMLqV0SQL/webrtc-session
“the IIS app pool used by the API Gateway (VideoOS.ApiGateway AppPool) is set to reset every 29 hours. Once the app pool is reset, all active sessions will be closed.” Please tell me the reason why the WebRTC session is disconnected even though it is connected.
2. Workaround methods for issue 1.
Please also tell me how to avoid the issue in point 1. Please tell me the impact of extending the recycling interval of VideoOS ApiGateway AppPool or setting it not to recycle. I would like to know whether session information remains, etc.
3. Regarding the control of recycling timing
Please also tell me what methods are available to control the timing of session recycling on the IIS side.
When the IIS app pool resets the sample include the code to reconnect. Please use the the sample to see how to do this. Please do not consider to change the reset of the IIS app pool.
Thank you for your response. I have a few more questions.
I will consider referring to the sample for handling WebRTC session reconnection.
In addition, please let me know how to check the status of the WebRTC session (such as expiration time) and the token status in XProtect to verify that disconnection and reconnection are working correctly.
On the other hand, if the WebRTC session is disconnected due to AppPool recycling, it would not be feasible for operation, so I would also like to consider ways to avoid this.
If, for example, it were possible to externally store and persist the WebRTC session so that it is not affected by AppPool recycling, would RTP transmission still stop?
If there are any examples or best practices where measures have been taken to prevent WebRTC sessions from being disconnected by AppPool recycling, please let me know.
Best Regards.
There is no way to ensure that the AppPool recycling doesn’t cause a disconnection of the WebRTC sessions.
Does this mean that there is no way to check the status of a WebRTC session?
If there is any method available, it would greatly accelerate our investigation, so I would appreciate any advice you can provide.
Best Regards.
I need a general idea what you want to achieve and what the issue is?
Using the WebRTC javascript sample it should refresh the token and it should reconnect automatically and thus recover from a AppPool recycle.
In your testing
Does the video stream get interrupted and never resume?
Does the video stream get interrupted and the resume is not acceptable for you? (Takes too long?)
If you want absolutely no interruption in the video stream, for how long would you want that?
-
The sample uses peerConnection.onconnectionstatechange to check the state of the WebRTC session.
https://doc.developer.milestonesys.com/html/index.html?base=samples/protocolsamples/webrtc_javascript/readme.html&tree=tree_3.html
(Please make sure you do not use an old version of the sample.)
