Found 1 record.

Status: Reported (1)

RFC 8016, "Mobility with Traversal Using Relays around NAT (TURN)", November 2016

Errata ID: 7418
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Md Nazmus Shakeeb
Date Reported: 2023-04-11

Section 3.2.1 says:

If the client's IP address or source port has changed and the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET
attribute received in the Allocate success response in the Refresh
request.  If there has been no IP address or source port number
change, the client MUST NOT include a MOBILITY-TICKET attribute, as
this would be rejected by the server and the client would need to
retransmit the Refresh request without the MOBILITY-TICKET attribute

It should say:

When the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET attribute received in the Allocate success response in the Refresh
request.  If there has been no IP address or source port number
change, the client MUST NOT include a MOBILITY-TICKET attribute, as
this would be rejected by the server and the client would need to
retransmit the Refresh request without the MOBILITY-TICKET attribute

Notes:

Here client's IP address and port are the STUN-mapped IP address and port.

How client will know that its IP address or source port has been changed?

It can be changed transparently where the client is not aware of it.

One way is to query it by STUN binding request before sending every STUN message
but this is not a feasible solution because of the huge overhead.

The best will be if the turnserver can inform the client about the changes.

The RFC should consider this otherwise it will not be very useful.

Report New Errata