Closed suggestedfixes closed 2 years ago
Implementation Details: https://tools.ietf.org/html/rfc5389#section-7.3.4
If the error response contains unknown comprehension-required
attributes, or if the error response does not contain an ERROR-CODE
attribute, then the transaction is simply considered to have failed.
The client then does any processing specified by the authentication
mechanism (see Section 10). This may result in a new transaction
attempt.
The processing at this point depends on the error code, the method,
and the usage; the following are the default rules:
o If the error code is 300 through 399, the client SHOULD consider
the transaction as failed unless the ALTERNATE-SERVER extension is
being used. See Section 11.
o If the error code is 400 through 499, the client declares the
transaction failed; in the case of 420 (Unknown Attribute), the
response should contain a UNKNOWN-ATTRIBUTES attribute that gives
additional information.
o If the error code is 500 through 599, the client MAY resend the
request; clients that do so MUST limit the number of times they do
this.
Any other error code causes the client to consider the transaction
failed.
Would you mind giving me more information about this feature? For example, how to hit this case in your scenario? low network speed or improper stun response from stun/turn servers?
This feature item is being tracked by the team internally.
This is a follow up of this issue: https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/issues/874
https://tools.ietf.org/html/rfc5389#section-6 It was found that stun error response was not properly recognized/handled, so possibly do a simple check and handle the error response according to the scenario?