On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote: >>>>> Section 6.3.4 states: >>>>> >>>>> 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. >>>>> >>>>> It is reasonable to provide guidance as to the number of re-sends? >>>> >>>> Same issue here, that's a section that is unmodified from RFC 5389. >>> >>> I understand. Now is our chance to fix it. :-) >>> >>>> As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability. >>> >>> Choosing different numbers is OK, but choosing an infinite number is >>> not. Can we provide guidance as to how many is too many? 10? 50? 100? >> >> Well, the text already states that an infinite number of of re-sends is not compliant. Anyway, I am not sure how to determine a reasonable number, but I'll try. > > I chose 4 as the maximum number of retransmissions. I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity. The new text reads like this: > > "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. Unless a specific error code specifies a different value, > the number of retransmissions MUST be limited to 4." > "SHOULD be limited to 4" seems fine, but MUST is OK too. Thanks for looking into this and making the fix. Peter
