Investigação

Qual RFC mais recente (a partir de 2025 ABR) define o formato de dados candidatos do WebRTC ICE?

Fundo

O RFC 5245 definiu o formato de dados do candidato ICE:

candidate:842163049 1 udp 1677729535 192.168.1.2 61734 typ srflx raddr 10.0.0.2 rport 54321

O formato pode ser claramente identificado com RFC 5245 15.1. Atributo "candidato" :

15.1.  "candidate" Attribute

   The candidate attribute is a media-level attribute only.  It contains
   a transport address for a candidate that can be used for connectivity
   checks.

   The syntax of this attribute is defined using Augmented BNF as
   defined in RFC 5234 [RFC5234]:

   candidate-attribute   = "candidate" ":" foundation SP component-id SP
                           transport SP
                           priority SP
                           connection-address SP     ;from RFC 4566
                           port         ;port from RFC 4566
                           SP cand-type
                           [SP rel-addr]
                           [SP rel-port]
                           *(SP extension-att-name SP
                                extension-att-value)

   foundation            = 1*32ice-char
   component-id          = 1*5DIGIT
   transport             = "UDP" / transport-extension
   transport-extension   = token              ; from RFC 3261
   priority              = 1*10DIGIT
   cand-type             = "typ" SP candidate-types
   candidate-types       = "host" / "srflx" / "prflx" / "relay" / token
   rel-addr              = "raddr" SP connection-address
   rel-port              = "rport" SP port
   extension-att-name    = byte-string    ;from RFC 4566
   extension-att-value   = byte-string
   ice-char              = ALPHA / DIGIT / "+" / "/"

No entanto, ele foi descontinuado e estamos procurando qual RFC mais recente o define.

RFC 8445 5.3. Troca de informações de candidatos tem informações semelhantes, mas não definitivas, por exemplo, Type: The type of the candidate.não dá a pista do uso de typ nos dados do candidato ICE.

5.3.  Exchanging Candidate Information

   ICE agents (initiating and responding) need the following information
   about candidates to be exchanged.  Each ICE usage MUST define how the
   information is exchanged with the using protocol.  This section
   describes the information that needs to be exchanged.

   Candidates:   One or more candidates.  For each candidate:

      Address:  The IP address and transport protocol port of the
         candidate.

      Transport:  The transport protocol of the candidate.  This MAY be
         omitted if the using protocol only runs over a single transport
         protocol.

      Foundation:  A sequence of up to 32 characters.

      Component ID:  The component ID of the candidate.  This MAY be
         omitted if the using protocol does not use the concept of
         components.

      Priority:  The 32-bit priority of the candidate.

      Type:  The type of the candidate.

      Related Address and Port:  The related IP address and port of the
         candidate.  These MAY be omitted or set to invalid values if
         the agent does not want to reveal them, e.g., for privacy
         reasons.

      Extensibility Parameters:  The using protocol might define means
         for adding new per-candidate ICE parameters in the future.

Qual servidor lida com a troca de ICE (troca de nós por rotas potenciais entre pares), servidor de sinalização SDP ou servidor STUN (ou TURN, que também pode funcionar como STUN)?

A conectividade MDN WebRTC mostra que o SDP Signaling Server lida com o ICE Exchange.

Entretanto, o WebRTC.org Getting started with peer connections diz que o STUN ou TURN Server lida com a troca ICE.

Como as condições da rede podem variar dependendo de uma série de fatores, um serviço externo é geralmente usado para descobrir os possíveis candidatos para conexão a um peer. Esse serviço é chamado ICE e usa um servidor STUN ou TURN.

RFC8445 - Estabelecimento de Conectividade Interativa (ICE) também indica que é STUN ou TURN para fazer troca de ICE.

2.1. Reunindo Candidatos

Para executar o ICE, um agente ICE identifica e reúne um ou mais candidatos de endereço. Um candidato tem um endereço de transporte -- uma combinação de endereço IP e porta para um protocolo de transporte específico (com apenas UDP especificado aqui). Existem diferentes tipos de candidatos; alguns são derivados de interfaces de rede físicas ou lógicas, e outros são detectáveis ​​via STUN e TURN.

A primeira categoria de candidatos são aqueles com um endereço de transporte obtido diretamente de uma interface local. Tal candidato é chamado de "candidato host". A interface local pode ser Ethernet ou Wi-Fi, ou pode ser uma obtida por meio de um mecanismo de túnel, como uma Rede Privada Virtual (VPN) ou IP Móvel (MIP). Em todos os casos, tal interface de rede aparece para o agente como uma interface local da qual portas (e, portanto, candidatos) podem ser alocados.

Em seguida, o agente usa STUN ou TURN para obter candidatos adicionais.

itergera uma coleção ordenada do conjunto não ordenado conforme abaixo. Este resultado classificado é um comportamento garantido do Python 3?

>>> x = {1, 9, 2, 8, 4, 6}
>>> y = iter(x)
>>> list(y)
[1, 2, 4, 6, 8, 9]      # <--- Sorted

O COMO FAZER Expressões Regulares diz que sequências especiais podem ser incluídas em uma classe de caracteres (ênfase minha):

A lista de sequências especiais a seguir não está completa. Para obter uma lista completa de sequências e definições de classe expandidas para padrões de string Unicode, consulte a última parte de Sintaxe de Expressão Regular na referência da Biblioteca Padrão. Em geral, as versões Unicode correspondem a qualquer caractere que esteja na categoria apropriada no banco de dados Unicode.

\dCorresponde a qualquer dígito decimal; isso é equivalente à classe [0-9].

\DCorresponde a qualquer caractere que não seja um dígito; isso é equivalente à classe [^0-9].

\sCorresponde a qualquer caractere de espaço em branco; isso é equivalente à classe [ \t\n\r\f\v].

\SCorresponde a qualquer caractere que não seja espaço em branco; isso é equivalente à classe [^ \t\n\r\f\v].

\wCorresponde a qualquer caractere alfanumérico; isso é equivalente à classe [a-zA-Z0-9_].

\WCorresponde a qualquer caractere não alfanumérico; isso é equivalente à classe [^a-zA-Z0-9_].

Essas sequências podem ser incluídas dentro de uma classe de caracteres . Por exemplo, [\s,.]é uma classe de caracteres que corresponderá a qualquer caractere de espaço em branco, ou ','ou '.'.

No entanto, parece que \bnão pode ser usado em uma classe de personagem.

pattern = r'\bcool\b'
text = "cool"

matches = re.finditer(
    pattern=pattern, 
    string=text.strip(), 
    flags=re.IGNORECASE
)
if matches:
    for match in matches:
        print(f"match: {match.group(0): <20} start: {match.start():<5} end: {match.end():<5} pos: {match.endpos:<5}")
---
match: cool                 start: 0     end: 4     pos: 4    

pattern = r'[\b\s]cool\b'    # <-----
text = "cool"

matches = re.finditer(
    pattern=pattern, 
    string=text.strip(), 
    flags=re.IGNORECASE
)
if matches:
    for match in matches:
        print(f"match: {match.group(0): <20} start: {match.start():<5} end: {match.end():<5} pos: {match.endpos:<5}")
---
No match

Por favor, ajude a entender o comportamento. Pode \bser usado, por exemplo, porque é considerado backspace na classe de personagem? Então está documentado em algum lugar?

Por que o início e o fim de uma linha correspondem ao [.]*e como evitá-lo?

Parece que o padrão corresponde ao limite do Word, mas não tenho certeza se foi projetado e qual especificação ele implementa.

$ echo " a " | sed -n 's/[.]*/X/pg'
X XaX X

$ echo " a " | sed -n 's/[\b]*/X/pg'
X XaX X