Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:reg


Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:sub


Question:
This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.

(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins>


Question:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

monitor for new push messages. Requesting the delivery of events is particularly important for the <del> Web Push API.  The subscription, management and monitoring functions </del> <ins> W3C Push API.  The subscription, management and monitoring functions </ins> are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.


Question:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. <ins> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </ins> 8.1. The protection afforded by TLS does not protect content from the push <del> service.  Without additional safeguards, a push service is able to see and modify the content of the messages. Applications are able to provide additional confidentiality, integrity or authentication mechanisms within the push message itself.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The process of providing the application server with subscription information provides a convenient medium for key agreement. The Web Push API codifies this practice by requiring that each push subscription created by the browser be bound to a browser generated encryption key.  Pushed messages are authenticated and decrypted by the browser before delivery to applications.  This scheme ensures that the push service is unable to examine the contents of push messages. The public key for a subscription ensures that applications using that subscription can identify messages from unknown sources and discard them.  This depends on the public key only being disclosed to entities that are authorized to send messages on the channel.  The push service does not require access to this public key. </del> <ins> service.  Without additional safeguards, a push service can inspect and modify the message content. For its requirements, the API has adopted I-D.ietf-webpush-encryption to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies. </ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used


Question:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

8.4. <del> Discarding unwanted messages at the user agent based on message authentication doesn't protect against a denial of service attack on the user agent.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </del> <ins> A user agent can control where valid push messages originate by limiting the distribution of push URIs to authorized application servers.  Ensuring that push URIs are hard to guess ensures that only application servers that have received a push URI can use it. Push messages that are not successfully authenticated by the user agent will not be delivered, but this can present a denial of service risk.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </ins> <del> An application can limit where valid push messages can originate by limiting the distribution of push URIs to authorized entities. Ensuring that push URIs are hard to guess ensures that only application servers that have been given a push URI can use it. </del> <ins> To address this case, the API has adopted I-D.ietf-webpush-vapid, which allows a user agent to restrict a subscription to a specific application server.  The push service can then identity and reject unwanted messages without contacting the user agent. </ins> A malicious application with a valid push URI could use the greater resources of a push service to mount a denial of service attack on a


Question:
Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.

A push service or user agent MAY also delete that receive too many push messages. <del> End-to-end confidentiality mechanisms, such as those in API, prevent an entity with a valid push message subscription URI from learning the contents of push messages.  Push messages that are not successfully authenticated will not be delivered by the API, but this can present a denial of service risk. Conversely, a push service is also able to deny service to user agents.  Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </del> <ins> A push service is also able to deny service to user agents. Intentional failure to deliver messages is difficult to distinguish from faults, which might occur due to transient network errors, interruptions in user agent availability, or genuine service outages. </ins> 8.5. <del> Server request logs can reveal subscription-related URIs.  Acquiring a push message subscription URI enables the receipt of messages or deletion of the subscription.  Acquiring a push URI permits the sending of push messages.  Logging could also reveal relationships between different subscription-related URIs for the same user agent. Encrypted message contents are not revealed to the push service. Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities. </del> <ins> Server request logs can reveal subscription-related URIs or relationships between subscription-related URIs for the same user agent.  Limitations on log retention and strong access control mechanisms can ensure that URIs are not revealed to unauthorized entities. </ins> 9.


Question:
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?

2. <del> Application servers that wish to self-identity generate and maintain </del> <ins> Application servers that wish to self-identify generate and maintain </ins> a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the


Question:
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?

2.1. If the application server wishes to provide contact details it MAY <del> include an "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </del> <ins> include a "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </ins> include a contact URI for the application server as either a "mailto:" (email) RFC6068 or an "https:" RFC2818 URI.


Question:
Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?

An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field <del> with credentials that use the "WebPush" authentication scheme auth and a Crypto-Key header field that includes its public key key. </del> <ins> with credentials that use the "WebPush" authentication scheme (auth) and a Crypto-Key header field that includes its public key (key). </ins> Note that the header fields shown in ex-push don't include line wrapping.  Extra whitespace is added to meet formatting constraints.


Question:
I have changed the by as it is the terminology that rfc 8443 uses. Also quoted the sdp attribute values. NAME wdyt?
added tentative text
The text says: "Unlike [RFC5763] a WHIP client MAY use a setup attribute value of setup:active in the SDP offer, in which case the WHIP endpoint MUST use a setup attribute value of setup:passive in the SDP answer." First, check whether it would be useful to also reference RFC 8842. Second, I think it is a BAD idea to go against the "MUST use setup:actpass" text in RFC 5763. Since you specify that the answerer MUST use setup:passive, there is no reason why the offer couldn't use setup:actpass, following the standard.
The idea is to prevent the WHIP client to have to implement active and passive setup. The MUST for the server is only in case that the client uses the setup attribute, maybe some rewording helps
You can still use the MUST for the server, even if the client uses 'actpass'.
Yes, we could, but would it be worthy? If the client sends , server MUST send . If the client sends , then the client MUST support to receive either an or response from the server, so I don't think we should put any extra requirement on the server. If the media server wants to only implement they are allowed in any case.
The document specifies the behavior of the media server, so even if the standard allows both 'active' and 'passive' you can still specify that a WHIP compliant server MUST send 'passive'. It is better than having the client do something which is not standard compliant.
ok, I get your point. The idea would be then to ask the client to send on the offer, despite only supporting the part, and force the media server to reply , right? Not sure if I like it or not, will ping the mailing list for consensus.
Yes. Specify that a WHIP-compliant media server MUST reply 'passive'.
If a MUST has to be added on servers, I think it should be 'active', not passive. It's an unwritten convention in basically all WebRTC applications that who receives the offer will send 'active', and while a convention is not a rule, forcing a change in this pattern would break a lot of implementations out there that may want to support WHIP on the server side.
Which is exactly why I wanted the original language that the client could say setup:active to indicate that it only implements DTLS client. Which isn't as unlikely as you might think, especially on devices with a secure element providing the DTLS certificate. It makes no sense to have an offer of actpass and then not actually allow both replies. Either you believe in the O/A model or you don't. By the way all my 'server' devices send answers with setup:passive because they are servers so running a DTLS server makes perfect sense. Seems to work fine...
An implementation can of course send whatever it wants, including setup:active. There is nothing anyone can do about that :) But I don't think we should standardize such behavior. As far as the WebRTC and SDP O/A standards are concerned, the offerer can act as both DTLS client and server. If that is the wrong assumption, then I think it shall be discussed in the affected WGs, and based on those discussions potentially update RFC 5763, 8839 etc. I don't think a standards document shall discard MUSTs just because we don't want to support required functionality. But then it should not matter if the offer contains setup:actpass, should it? :)
I fully agree with Tim. WHIP complicane with WebRTC means that WebRTC endpoints (or whatever name we give to them) can act like a WHIP client, but not all WHIP client needs to be fully compliant WebRTC endpoints. For the server side we are already reducing the requirements of a JSEP client as explained in the gateway draft: So, I would challenge that reducing the requirements on the WHIP client makes WHIP non-webrtc compliant. The idea behing this change is that there is no need for a whip client talking to a whip server to have to implement both active and passive setup. Negotiating actpass when only one mode is supported seems completelly wrong to me.
We've already found out that Tim always sends passive from servers, while Janus always sends active when it receives an offer: this means that whatever you force on the WHIP client will break one of the two servers. I think clients should send actpass as the RFC says.
Mandating clients to implement both active and passive is a no go for me. The goal has always been to reduce the burden on the clients because there was none available. Increasing the complexity of implementing them is not going to help.
btw, I think that Tim is referring that his servers respond as passive, while their clients sends active. So his (whip) clients would be able to talk with janus server, which is what we intended.
No, they wouldn't, because Janus expects actpass when it receives an offer, and will set the role of active for itself. Two actives won't get anywhere.
When you say 'clients', what exactly are you referring to? The WebRTC library that you are using in the application?
No, I am referring to the WHIP clients
Imagine I have a smart camera acting as a WHIP source which can only do Active DTLS (because of a hardware limitation). Let's assume when it tries to talk to Janus it will fail because Janus will only do active. If the camera signals this in it's WHIP offer with setup:active then the O/A fails early with a sensible error message http status:402 If it sends a (mendacious) setup:actpass then the connection will silently fail after ice connects and a 16 second DTLS timeout. So sending setup:active in the offer is the right thing for the camera to do. The other option is to say that such hardware shouldn't be doing WHIP, which seems like a needless limitation on hardware encoder design.
Incidentally I checked my (open source) Whipi client and it actually sends ! Which is why it works with Janus. (The target hardware (raspberry pi) does not have a secure element, so it is just a code size simplification not a hardware limitation - It still halves the complexity of the DTLS layer by only having to implement dtls server)
Back to the High level point. The WebRTC spec was designed to be Peer-to-Peer - so it makes sense that both sides need equal capabilities since you never know who will initiate an offer - so mandating actpass in the offer is a good idea. WISH/WHIP is explicitly client-server so asymmetry is to be expected. I would argue that the original wording is wrong however - "WHIP endpoint MUST use a setup attribute value of setup:passive in the SDP answer." Should read "WHIP endpoint SHOULD use a setup attribute value of setup:passive in the SDP answer. Or if it does not support passive it MUST reply with an http 402 error status and an explanation error message."
I think it shall be MUST. If the server cannot do that for whatever reason it will obviously have to return an error. We can for sure specify which error code to use. Also, I think it is better to say that the server MUST follow the procedures in RFC 4573. Regarding the WHIP client, a compromise would be to say that it SHOULD use actpass, according to 4573, unless it only implements the DTLS client role in which case it can use active. Because, we should not forbid a WHIP client from using the standard 4573 behavior if it is able to do so. In addition, there could be a note saying a few words about why a WHIP client might only implement the DTLS client role.
Here is some new text suggestion (I have not created a PR yet) for Section 4.2. Note that I also modify the BUNDLE text. The SDP BUNDLE mechanism [RFC8843] MUST be used by both WHIP clients and media servers. Each m- line MUST be part of a single BUNDLE group. Hence, when a WHIP client sends an SDP offer, it MUST include a bundle-only attribute in each bundled m- line. In addition, per [8843] the WHIP client and media server will use RTP/RTCP multiplexing for all bundled media. The WHIP client and media server SHOULD include the rtcp-mux-only attribute in each bundled m- line. When a WHIP client sends an SDP offer, it SHOULD use the setup:actpass attribute, as defined in [RFC5763]. However, if the WHIP client only implements the DTLS client role, it MAY use the setup:active attribute. NOTE: [RFC5763] defines that the offerer must use the setup:actpass attribute. However, the WHIP client will always communicate with a media server that is expected to support the DTLS server role, in which case the client might choose to only implement support for the DTLS client role.
I like that and I think it is a good compromise, creating the PR now
I have split it in two PRs so we can review/merge them independently: BUNDLE: URL SETUP: URL The include the proposed changes by NAME with a bit of rewording to match the notation of the referenced RFCs, and include that the server SHOULD response with a 422 error if the setup:active is not supported.
When reading this again, I think there still need to be some changes: both the WHIP endpoint and the media server need to support BUNDLE/multiplexing: the WHIP endpoint needs to support the BUNDLE SDP extension, while the media server needs to support the multiplexed media associated with the BUNDLE group.

clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage: <del> Bothe the WHIP client and the media server SHALL use SDP bundle RFC8843.  The SDP offer created by the WHIP client must include the bundle-only attribute in all m-lines as per RFC8843.  Also, RTCP muxing SHALL be supported by both the WHIP client and the media server. </del> <ins> Both the the WHIP client and the WHIP endpoint SHALL use SDP bundle RFC8843.  Each "m=" section MUST be part of a single BUNDLE group. Hence, when a WHIP client sends an SDP offer, it MUST include a "bundle-only" attribute in each bundled "m=" section.  The WHIP client and the Media Server MUST support multiplexed media associated with the BUNDLE group as per RFC8843 section 9.  In addition, per RFC8843 the WHIP client and Media Server will use RTP/RTCP multiplexing for all bundled media.  The WHIP client and media server SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in


Question:
Consider a client that does Since the ICE gathering process has started at the time of , it is too late at this point to call . Thus, a way is needed to find the set of ICE servers before the offer is POSTed to the server. In his mail of 12 July 2022, Sergio suggests a different procedure: This alternate procedure should work, but it is somewhat unusual; thus, the spec should describe this procedure in detail, and indicate that this is the procedure that the WHIP client must use if it wishes to use the server-provided ICE servers. What is more, with this procedure the posted offer does not contain any local candidates, which might imply that client-side Trickle ICE is a requirement, at least in some environments. Again, this should be discussed in the draft.
That is not true. If server is on a public IP address or behind a port forwarding NAT. The candidates sent by the server are enough to establish the ICE connection. Gathering all the ICE candidates on the local offer are only required if the client does not support trickle and the server is behind of a NAT that requires hole punching. I don't think we should explain how to use webrtc apis in the spec.
So WHIP is restricted to the case where the server is on a public IP, with no firewall? That would be fine with me, but if that's the case then IMHO it needs to be stated explicitly in the draft. What happens if the client is on a restrictive network that only lets outgoing TCP through, which is unfortunately still the case in many university networks? Are you assuming that the server supports passive TCP ICE? If so, should that be mentioned in the draft somewhere?
The turn server configuration via OPTIONS is not going to be removed. I can add a note like:

server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. <ins> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTION request processing and increase the processing required to