-
Notifications
You must be signed in to change notification settings - Fork 849
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dedicated document for Rejection Reason Codes #2742
Comments
SDP/SRT |
This separation is intended. The rejection codes in API-functions.md define the "system" rejection codes, that is, erroneous situation caused by SRT-specific settings or a general situation. They may occur in a normal SRT operation without any participation of the application, as well as the application has no possibility to simulate these codes. Also the description of the rejection code is a description of a situation that did happen. Those in "Access Control" are codes intended for use by the application to forcefully reject the connection in the listener callback. This is only a guideline and standard proposal, and if an application decides to use them, it must still adopt these codes and publish its specific description of them. The description in the documentation is only an example or proposal, not an explanation of the code's meaning because only the application that adopts this code can define its true meaning. Even though the code can be read in one place as coming from both sources, these two sources are strictly separate. As per expansion, these parts are also separate - system rejection codes would be added as features of SRT get modified, while application rejection codes could expand as SRT applications get in better communication with one another and the need for additional codes appear by that reason. |
I don't think a separate document is necessary. We can just add a note to API-functions.md, edit the existing description in access-control.md, and then add cross-reference links between them. One specific thing that is not clearly explained is the difference between the prefixes SRT_REJ, SRT_REJC, and SRT_REJX. |
Take a look at this from the user's point of view. |
I understand that reasoning, but then collecting all the codes in one document would be misleading. If you are an application developer and you use the However, this function may return you just as well application rejection codes that have been passed from the peer application. The developer might want to look into some documentation to understand the code. But then, the explanation provided by the documentation doesn't tell you the exact meaning. The true meaning of the code is what the peer application defines for itself and the explanation should be searched in THIS APPLICATION's documentation, not in SRT documentation. The description in the SRT documents for the If there is a situation that the peer application didn't make their rejection code description available, the explanation may be wanted to be searched through the list of Because of all these things, I think the best approach would be to clearly mention in the |
As you say, there are SRT-internal codes (0-99).
Even though I see certain advantages of having those definitions in two different documents, still I am concerned it is not as user-friendly as it could be if it was a single document. For me, all the possible rejection reasons is a separate big topic that deserves a dedicated and well-structured document, also clearly stating the difference between SRT-specific, SRT-reserved, and application space codes. |
After some review, here is the summary for rejection codes.
1. SRT Internal Rejection ReasonsDefined in Provides the reason why a connection is rejected by SRT. Naming:
2. Extended Rejection CodesDefined in Standard server error codes including those adopted from HTTP. Subranges (1000 + value):
Naming: Example:
3. User Defined Rejection CodesReserved range |
Yeah, very good. Changes in the access control docs would be then probably not required. |
@maxsharabayko Lines 563 to 568 in srt.h mention |
|
@stevomatthews // Planned deprecation removal: rel1.6.0.
#define SRT_REJ__SIZE SRT_REJ_E_SIZE |
Currently rejection reason codes are described in several places.
Better to have a separate document, especially given that more might be defined further and a more extensive use may be expected (e.g. see #1292, #2638).
TODO
Create a dedicated document in
docs/API/rejection-codes.md
and compile the codes from both places mentioned above.Add references to the new document.
SRT_REJ_CRYPTO
is missing from API-functions.md#rejection-reasons-1The text was updated successfully, but these errors were encountered: