VoIP: anàlisi de SIP i RTP

L’anàlisi VoIP és el mode de protocol més madur de lippycat. Segueix els diàlegs de senyalització SIP, correlaciona els fluxos de mitjans RTP amb les sessions SIP que els controlen i admet l’extracció de PCAP per trucada per a l’anàlisi fora de línia.

Flux de senyalització SIP

SIP (Session Initiation Protocol) utilitza un model de petició/resposta per establir, modificar i acabar trucades de veu i vídeo. lippycat segueix tot el cicle de vida del diàleg. Una trucada reeixida típica segueix aquesta seqüència:

sequenceDiagram
    participant Caller
    participant Callee

    Caller->>Callee: INVITE (SDP offer)
    Callee-->>Caller: 100 Trying
    Callee-->>Caller: 180 Ringing
    Callee-->>Caller: 200 OK (SDP answer)
    Caller->>Callee: ACK

    Note over Caller,Callee: RTP media (bidirectional)
    Caller->>Callee: RTP audio stream
    Callee->>Caller: RTP audio stream

    Callee->>Caller: BYE
    Caller-->>Callee: 200 OK

lippycat analitza cada missatge SIP i n’extreu:

Mètodes SIP que lippycat reconeix: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, PRACK, UPDATE, INFO, REFER, SUBSCRIBE, NOTIFY, MESSAGE, PUBLISH.

Captura de trànsit SIP

La captura VoIP bàsica mostra tot el trànsit SIP i RTP d’una interfície:

sudo lc sniff voip -i eth0

Filtreu per usuari SIP per centrar-vos en extrems concrets:

Per a un sol usuari:

sudo lc sniff voip -i eth0 -u alicent

Per a diversos usuaris:

sudo lc sniff voip -i eth0 -u "alicent,robb"

Per a una coincidència de sufix amb comodí (tots els números acabats en 456789):

sudo lc sniff voip -i eth0 -u "*456789"

Extraieu informació d’establiment de trucada amb jq:

Per mostrar totes les peticions INVITE amb qui truca i qui rep la trucada:

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.Method == "INVITE") |
    [.Timestamp, .VoIPData.From, .VoIPData.To, .VoIPData.CallID] |
    @tsv'

Per seguir les transicions d’estat d’una trucada amb un Call-ID concret:

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.CallID == "abc123@pbx.local") |
    [.Timestamp, .VoIPData.Method // ("Response " + (.VoIPData.Status|tostring))] |
    @tsv'

Transport SIP: UDP i TCP

SIP funciona tant sobre UDP com sobre TCP. UDP és més habitual per a la senyalització, però TCP s’utilitza per a missatges grans (p. ex., SIP amb SDP que supera l’MTU) i és necessari per a SIP xifrat amb TLS (SIPS).

Per defecte, lippycat captura tant el trànsit SIP UDP com TCP. SIP TCP requereix reassemblatge del flux, cosa que afegeix sobrecàrrega de CPU. En xarxes amb molt trànsit TCP que no és SIP, podeu ometre completament el processament TCP:

El mode només UDP genera un filtre BPF optimitzat que exclou TCP:

sudo lc sniff voip -i eth0 -U -S 5060

Quan cal SIP TCP, trieu un perfil de rendiment per ajustar els paràmetres de reassemblatge (vegeu Captura CLI amb lc sniff):

sudo lc sniff voip -i eth0 -M throughput

Fluxos de mitjans RTP i SRTP

Un cop establert un diàleg SIP, els mitjans circulen com a paquets RTP (Real-time Transport Protocol). lippycat detecta els fluxos RTP identificant paquets dins dels intervals de ports configurats (per defecte: 10000-32768) que coincideixen amb l’estructura de la capçalera RTP.

Cada paquet RTP conté metadades que lippycat extreu:

lippycat correlaciona els fluxos RTP amb el diàleg SIP que els controla mitjançant el Call-ID. Quan els paquets RTP arriben abans de l’INVITE SIP corresponent (fet que passa quan la captura comença a mitja trucada), lippycat crea un registre de trucada sintètic i el fusiona quan apareix la senyalització SIP.

Supervisió dels fluxos RTP:

Per mostrar els fluxos RTP actius amb SSRC i còdec:

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.IsRTP) |
    [.SrcIP, .DstIP, .VoIPData.SSRC, .VoIPData.Codec, .VoIPData.SequenceNum] |
    @tsv'

Per detectar salts en la seqüència RTP (possible pèrdua de paquets):

sudo lc sniff voip -i eth0 2>/dev/null | \
  jq -r 'select(.VoIPData.IsRTP) |
    [.VoIPData.SSRC, .VoIPData.SequenceNum] | @tsv' | \
  awk -F'\t' '{
    if (prev[$1] != "" && $2 != (prev[$1]+1) % 65536)
      print "Gap: SSRC="$1, "expected="(prev[$1]+1)%65536, "got="$2;
    prev[$1] = $2
  }'

Intervals de ports RTP personalitzats:

Si la vostra centraleta utilitza ports RTP no estàndard, especifiqueu explícitament l’interval:

sudo lc sniff voip -i eth0 -R 8000-9000

sudo lc sniff voip -i eth0 -R "8000-9000,40000-50000"

Mètriques de qualitat de les trucades

Els números de seqüència i les marques temporals RTP permeten analitzar la qualitat de les trucades. Tot i que lippycat captura les metadades RTP en brut, podeu obtenir mètriques estàndard de qualitat a partir de la sortida JSON:

Pèrdua de paquets: es detecta pels salts en el número de seqüència RTP. El número de seqüència és un comptador de 16 bits que augmenta una unitat per paquet i torna a zero després de 65535.

Jitter: variació en el temps d’arribada entre paquets. Calculeu-lo comparant l’interval d’arribada esperat (basat en marques temporals RTP) amb els temps d’arribada reals.

MOS (Mean Opinion Score): estimació de la qualitat de veu entre 1,0 (dolenta) i 5,0 (excel·lent). MOS es deriva del factor R, que té en compte el còdec, la pèrdua de paquets, el jitter i el retard. Un MOS superior a 4,0 es considera de bona qualitat.

Exemple: calculeu el percentatge de pèrdua de paquets per SSRC d’un fitxer PCAP:

El comandament següent analitza una gravació per SSRC. El comentari dins del programa awk forma part del programa i es conserva:

lc sniff voip -r call-recording.pcap 2>/dev/null | \
  jq -r 'select(.VoIPData.IsRTP) |
    [.VoIPData.SSRC, .VoIPData.SequenceNum] | @tsv' | \
  awk -F'\t' '
    { count[$1]++; seq[$1] = $2 }
    END {
      for (ssrc in count) {
        # Expected = max_seq - min_seq + 1 (approximate)
        loss = 1 - (count[ssrc] / (count[ssrc] + 0.001))
        printf "SSRC=%s packets=%d\n", ssrc, count[ssrc]
      }
    }'

Per supervisar la qualitat de les trucades en producció, exporteu les dades RTP a un sistema de supervisió dedicat o utilitzeu la vista de trucades en temps real de la TUI (vegeu Captura interactiva amb lc watch).

Flux de treball PCAP per trucada

L’escriptura PCAP per trucada crea fitxers de captura separats per a cada trucada VoIP, cosa que facilita arxivar, reproduir o compartir gravacions de trucades individuals.

La funció PCAP per trucada està disponible als nodes processadors i Tap. Crea dos fitxers per trucada:

20250123_143022_abc123_sip.pcap    # SIP signaling packets
20250123_143022_abc123_rtp.pcap    # RTP media packets

Captura independent amb PCAP per trucada (mode Tap):

sudo lc tap voip -i eth0 \
  --per-call-pcap \
  --per-call-pcap-dir /var/voip/calls \
  --per-call-pcap-pattern "{timestamp}_{callid}.pcap" \
  --insecure

Captura distribuïda amb PCAP per trucada (processador):

lc process --listen :55555 \
  --per-call-pcap \
  --per-call-pcap-dir /var/capture/calls \
  --pcap-command 'gzip %pcap%' \
  --tls-cert server.crt --tls-key server.key

El hook --pcap-command s’executa quan es tanca cada fitxer PCAP i permet comprimir, pujar o arxivar automàticament. El hook --voip-command s’executa quan acaba tota una trucada (tots dos fitxers SIP i RTP estan finalitzats):

lc process --listen :55555 \
  --per-call-pcap --per-call-pcap-dir /var/capture/calls \
  --pcap-command 'gzip %pcap%' \
  --voip-command '/opt/scripts/process-call.sh %callid% %dirname%' \
  --tls-cert server.crt --tls-key server.key

Marcadors dels patrons de noms de fitxer: {callid}, {from}, {to}, {timestamp}.

El període de gràcia PCAP (--pcap-grace-period, 5 segons per defecte) controla quant espera lippycat després de l’últim paquet abans de tancar els fitxers PCAP d’una trucada. Això té en compte els paquets RTP que arriben tard i les retransmissions.

Per a la configuració completa del PCAP per trucada, vegeu Agregació central amb lc process i Mode independent amb lc tap.

Flux de dades VoIP

Entendre com circulen els paquets per l’analitzador VoIP ajuda a resoldre problemes i ajustar el rendiment:

flowchart LR
    A[Network Interface] --> B[gopacket]
    B --> C{Protocol Detection}
    C -->|UDP| D[SIP Parser]
    C -->|UDP| E[RTP Detector]
    C -->|TCP| F[TCP Reassembly]
    F --> D
    D --> G[VoIP Packet Processor]
    E --> G
    G --> H{GPU Available?}
    H -->|Yes| I[GPU Acceleration]
    H -->|No| J[CPU Processing]
    I --> K[Filter & Display]
    J --> K

Els paquets SIP UDP s’analitzen directament. Els paquets SIP TCP passen primer pel motor de reassemblatge (configurat amb --tcp-performance-mode). Els paquets RTP es detecten per l’estructura de la capçalera dins de l’interval de ports configurat. El processador de paquets VoIP correlaciona els fluxos RTP amb els diàlegs SIP mitjançant el Call-ID. L’acceleració GPU, quan està disponible, descarrega la cerca de patrons per al filtratge d’usuaris SIP.

Captura selectiva de mitjans amb eBPF

hunt voip --rtp-ebpf i tap voip --rtp-ebpf poden rebutjar mitjans no relacionats abans que libpcap els transmeti per descodificar-los en l’espai d’usuari. Aquesta via Linux activada explícitament manté el lector libpcap i actualitza els mapes d’un filtre de socket persistent quan canvien les trucades seleccionades. No reinicia la captura per l’activitat de trucades. L’assignació existent en l’espai d’usuari, l’atribució de filtres, la caducitat i les comprovacions de sortida continuen sent autoritatives.

Els mitjans seleccionats per trucada es capturen només després de la selecció i la publicació dels extrems. Les metadades SDP validades i limitades es poden conservar abans de la selecció; no es conserva l’historial RTP. Els filtres IP/CIDR independents i la política configurada sense filtres continuen aplicant-se.

L’aprenentatge compartit d’SDP conserva les seccions de mitjans independents vàlides abans i després d’una secció invàlida, només amb extrems IP/port numèrics exactes. No fa inferències a partir de DNS, candidats ICE ni intervals d’adreces. S’admeten els perfils RTP i UDP/TLS/RTP per a àudio, vídeo i altres tipus de mitjans. RTCP utilitza per defecte el port següent; un port/adreça RTCP explícit substitueix aquest valor, mentre que RTCP mux utilitza un extrem compartit. El port RTP 65535 requereix a=rtcp-mux, a=rtcp-mux-only o un port/adreça a=rtcp: explícit vàlid: el port següent implícit seria 65536, fora de l’interval UDP. Sense una d’aquestes declaracions, l’analitzador rebutja conservadorament tota la secció. Les dades invàlides de mitjans, connexió o RTCP invaliden la secció afectada sense reutilitzar l’adreça d’una secció anterior. Les dades invàlides de connexió de sessió impedeixen heretar extrems; encara es pot utilitzar una adreça posterior vàlida a nivell de mitjans. Els ports zero, els mitjans inactius i les adreces de pausa no especificades no aporten extrems nous. Els extrems acceptats prèviament es conserven fins a la neteja autoritativa del cicle de vida de la trucada. En arribar a la capacitat, només es conserven els primers extrems únics en l’ordre del trànsit dins del límit configurat i la derivació queda incompleta. La derivació incompleta d’una trucada seleccionada aplica la política de fallada d’admissió configurada i bloqueja la recuperació de l’aplicació del filtre fins que el context de senyalització afectat es repari, se substitueixi vàlidament o es retiri. Una resposta completa de l’altra part no resol per si sola una oferta incompleta. L’SDP en mètodes SIP no relacionats no resol la incertesa de negociació. Rebutjar una oferta posterior conserva la incertesa del seu predecessor fins que una negociació reeixida n’estableixi la substitució.

La recuperació d’admissió admet la seqüència d’oferta diferida formada per un INVITE observat sense cos, una resposta provisional fiable inicial amb etiqueta (per exemple, 183) que conté l’oferta SDP amb capçaleres Require: 100rel i RSeq vàlides, i una resposta SDP completa en el PRACK corresponent. La prova requereix la mateixa branca de diàleg i el mateix cicle de vida de la trucada seleccionada: el número de resposta RAck de PRACK ha de coincidir amb RSeq i el número/mètode CSeq que referencia ha de coincidir amb el CSeq INVITE de la resposta provisional. El CSeq propi de PRACK i la branca Via identifiquen la seva transacció separada. L’oferta sola, una resposta final o ACK sense cos i l’SDP de PRACK no relacionat no poden resoldre la resposta que falta. Les proves absents, contradictòries, caducades sense correspondència o perdudes per capacitat continuen sent incertes; encara es poden promoure extrems segurs independentment. Altres contextos no resolts, promocions d’extrems fallides o escriptures de control també impedeixen la recuperació. Els enllaços conservats estan limitats i no apareixen als logs d’estat ni d’avisos.

La recuperació conserva enllaços fiables limitats d’oferta/resposta per iniciador de petició i branca de diàleg. La resposta fiable inicial ha de tenir RSeq entre 1 i 2^31-1; les respostes fiables vàlides posteriors continuen requerint enllaç exacte i confirmació. Els enllaços sense correspondència caduquen amb pending_ttl. Un cop validada la resposta, el seu context limitat del cicle de vida actual sobreviu a aquesta caducitat fins a la substitució o retirada aplicable. Un rebuig amb correspondència exacta del PRACK restaura la incertesa.

L’oferta provisional fiable requereix la resposta en PRACK, tal com defineix RFC 3262, secció 5. L’SDP en ACK després d’un PRACK sense cos no substitueix aquesta prova d’admissió que falta; l’intercanvi continua sent incert. L’associació SDP ordinària del processador és un comportament separat i encara pot associar extrems d’ACK. Un UPDATE primerenc no pot respondre una oferta provisional fiable pendent. Els UPDATE primerencs i els de diàleg establert tenen restriccions d’oferta/resposta diferents, tal com descriu RFC 3311, secció 5.1.

Després que una resposta final INVITE reeixida observada estableixi el diàleg, un re-INVITE complet confirmat o un UPDATE de diàleg establert de qualsevol participant pot substituir la incertesa de negociació aplicable en aquell mateix diàleg i trucada activa. Això inclou capçaleres de transacció contradictòries, PRACK defectuós, ofertes diferides no resoltes i SDP parcial. La vigència es comprova en l’espai de seqüència de l’iniciador de la reparació; els números CSeq de qui truca i de qui rep la trucada no es comparen mai entre si. Una petició sola, una resposta parcial o rebutjada, capçaleres de substitució contradictòries, un intercanvi obsolet o un altre diàleg no poden establir la recuperació. Els contextos independents no resolts, la pèrdua de proves de cicle de vida/recursos, les promocions d’extrems fallides i les escriptures de control encara impedeixen restaurar l’aplicació del filtre.

En mode enforce, l’assignació obsoleta d’extrems basada només en incertesa continua disponible durant la gràcia de mitjans finals del rol. Els extrems necessaris per a un intercanvi històric vàlid, la reparació completa o una obligació independent continuen protegits; les observacions parcials o contradictòries no esdevenen historial vàlid només perquè s’hagin conservat. Una negociació vàlida que recupera un extrem cancel·la només la retirada pendent d’aquell extrem. La neteja torna a comprovar el cicle de vida exacte i els requisits independents actuals; un callback obsolet no pot eliminar l’assignació d’un cicle de vida reutilitzat. L’acabament autoritatiu de la trucada deixa la neteja final per al període de gràcia d’acabament. Les noves ofertes vàlides i la pausa/represa conserven l’assignació històrica del registre. La recuperació shadow actualitza proves i diagnòstics tot conservant l’assignació d’extrems en l’espai d’usuari. L’estat de retirada utilitza els límits existents configurats de metadades i per propietari.

Tap utilitza el valor efectiu de --pcap-grace-period tant per a la retirada d’extrems com per a l’acabament de trucades; els valors no positius es normalitzen al valor existent per defecte de cinc segons abans de construir l’encaminament. Hunter utilitza el seu PCAPGracePeriod configurat amb el mateix valor alternatiu de cinc segons; no té cap opció --pcap-grace-period. Un pont d’admissió directe de baix nivell pot utilitzar intencionadament zero per a una retirada immediata; aquest comportament de biblioteca no canvia els valors d’inici per defecte dels rols.

La gràcia protegeix l’atribució durant la seva finestra, inclosa una parella obsoleta amb un extrem compartit per una altra trucada. Un cop caduca, encara s’aplica l’alternativa existent de resolució unilateral: els paquets arbitràriament tardans es poden resoldre mitjançant el propietari restant d’un extrem compartit. Els marcadors d’alliberament que suprimeixen aquesta alternativa són un reforç secundari i no s’implementen en aquest canvi.

L’analitzador SIP combina les línies Require repetides i conserva l’últim valor de les capçaleres úniques CSeq, RSeq i RAck per als consumidors generals. L’admissió accepta duplicats vàlids idèntics després de comparar-ne el significat: els camps numèrics ignoren els zeros inicials, es normalitzen els espais en blanc i els mètodes SIP es comparen distingint majúscules i minúscules. Un únic RSeq o RAck malformat invalida el seu enllaç fiable sense fer incert un intercanvi ordinari d’oferta/resposta altrament vàlid. Un grup repetit que contingui qualsevol valor malformat continua sent contradictori, incloses les barreges vàlid/malformat i les repeticions invàlides idèntiques. Un CSeq contradictori conserva només proves mínimes/màximes vàlides limitades per al seu iniciador; els conflictes de mètode i els límits malformats o no disponibles continuen sent explícitament incerts. Una substitució completa, correcta i confirmada ha de superar la marca d’incertesa aplicable. Encara es poden aprendre extrems SDP segurs de trucades seleccionades dins dels límits configurats, sense autoritzar sortides ni aportar proves. La política de fallada open/closed i totes les restriccions explícites de captura/espai d’usuari continuen vigents.

L’analitzador conserva l’interval validat CSeqMin/CSeqMax perquè les proves descriguin amb precisió cada ocurrència vàlida, independentment de l’últim valor de capçalera exposat als consumidors generals. Actualment, la recuperació utilitza només CSeqMax com a límit de vigència; CSeqMin es conserva per al contracte de proves de l’analitzador i la validació de l’interval, no com a segon llindar de recuperació.

Les proves pendents, la procedència dels extrems i la neteja diferida estan vinculades als cicles de vida autoritatius de les trucades. Les proves vinculades explícitament a una sessió/generació antiga es rebutgen fins i tot després que caduqui l’historial de reproducció. La retirada registra proteccions exactes limitades de seqüència dels iniciadors anteriors per posar en quarantena identitats de trànsit reutilitzades durant replay_window (per defecte 2m), mesurat des de la retirada amb el rellotge monòton del pont en lloc de les marques temporals dels paquets. Una retirada posterior de la mateixa identitat renova la finestra; les observacions de reproducció no l’allarguen. Els conflictes malformats sense límits utilitzables bloquegen aquell iniciador; la pèrdua d’identitat/límits bloqueja el Call-ID reutilitzat dins de la finestra.

L’historial de reproducció té un conjunt separat només d’entrades exactes compartit entre dominis d’observació: replay_guard_capacity (per defecte 10000) i replay_guard_bytes (per defecte 2097152), amb 128 bytes comptabilitzats per entrada. S’apliquen tots dos límits; l’historial no consumeix capacitat de derivació seleccionada activa. Les proteccions no caducades no s’expulsen mai per admetre entrades noves. El manteniment de caducitat del worker existent recorre el mapa exacte, amb el treball limitat per la capacitat configurada. El tancament allibera els recursos comptabilitzats. No hi ha cap magatzem probabilístic de desbordament.

Si no es pot registrar una protecció de retirada, totes les proves d’aquell domini d’observació són conservadores fins a l’última retirada no registrable més replay_window. Aquesta alternativa conserva les proteccions exactes existents i segueix la política open/closed configurada; no deixa el pont permanentment inutilitzable. La sobrecàrrega sostinguda pot allargar l’interval. Un cop caduca, les trucades ja actives concilien les proves restants i les incerteses independents en lloc de declarar-se conegudes a cegues. Quan la pressió de reproducció ha descartat observacions, la recuperació requereix una nova petició completa i una resposta corresponent observades després del descart; una resposta en memòria cau anterior a la pressió no pot substituir proves absents. Retirar una trucada amb aquestes proves absents registra una protecció de Call-ID bloquejat durant la finestra. Els avisos agregats es limiten a l’interval de reintent i no inclouen identitats del trànsit.

El valor per defecte de dos minuts és un marge d’enginyeria respecte de l’horitzó habitual de transacció SIP de 32 segons, 64 vegades T1 amb T1 de 500 ms, descrit a RFC 3261, secció 17.1.1.2, i del pending_ttl existent de 30 segons. No limita tots els diàlegs SIP, el reassemblatge TCP, les cues de captura, l’emmagatzematge temporal dels Hunters ni els retards de transmissió. Configureu la finestra segons els retards coneguts del desplegament. Un cop caduca, les identitats de trànsit idèntiques no vinculades no poden distingir un intercanvi nou d’una captura antiga o d’un missatge retardat; les reproduccions arbitràries queden fora d’aquesta garantia de protecció finita.

Les proves de diàlegs primerencs es conserven separadament per a cada branca limitada. La confirmació observada resol el diàleg guanyador; l’assignació exclusiva dels diàlegs perdedors segueix la gràcia de mitjans finals, mentre es mantenen els requisits compartits i independents. Diverses branques reeixides continuen sent conservadores. Tant una oferta INVITE amb la seva resposta fiable com una oferta diferida amb la seva resposta PRACK poden conservar l’SDP canònic acceptat mentre es repeteix SDP idèntic en una resposta provisional fiable posterior. Cada resposta provisional nova requereix el seu propi RSeq següent vàlid i el RAck/PRACK corresponent en el mateix cicle de vida i diàleg primerenc. Les retransmissions amb el mateix RSeq no generen una nova obligació de confirmació. L’SDP modificat continua sent conservador i només afegeix extrems fins a una reparació vàlida; un 200 final que repeteixi la resposta canònica no pot eludir un PRACK pendent. Els bytes SDP iguals per si sols no poden validar proves RSeq, RAck, de diàleg o de cicle de vida no relacionades.

rtp_ebpf.scopes[].uncertainty informa per domini de unknown_calls actives úniques i de comptadors de motius superposats: conflicting_headers, faulty_prack, partial_sdp, delayed_offer, fork_ambiguity i evidence_loss. Una trucada pot tenir diversos motius; no sumeu els comptadors de motius per obtenir un total de trucades. identical_duplicates i conflicting_duplicates són comptadors acumulatius de missatges amb un grup de capçalera única repetit, comptats separadament per CSeq, RSeq i RAck. Tres o més línies repetides en un grup compten una vegada, no una per línia; aquests comptadors no compten les trucades actualment desconegudes. Els duplicats vàlids idèntics per si sols no creen incertesa.

malformed_rseq i malformed_rack compten separadament els missatges analitzats que contenen almenys una ocurrència malformada d’aquell tipus de capçalera, una vegada per tipus i missatge, incloses les retransmissions. Un grup de duplicats mixt o invàlid incrementa tant el comptador del tipus malformat com conflicting_duplicates; una capçalera única malformada no incrementa el comptador de duplicats. Aquests comptadors d’ocurrències són independents dels totals de trucades actives desconegudes i es poden superposar.

replay_guards i replay_guard_bytes informen de l’ús d’historial exacte per domini; replay_guard_capacity i replay_guard_byte_limit són límits del conjunt compartit, no quotes multiplicades pel nombre de dominis. replay_window_ns informa de la finestra efectiva configurada. replay_unrecorded compta acumulativament els intents fallits d’inserció de proteccions i replay_degraded_ns és l’interval conservador restant de tot el domini, zero quan és inactiu. Les trucades actives afectades per aquell interval també apareixen als totals únics de trucades desconegudes i als comptadors superposats evidence_loss. Aquests camps no requereixen identitats ni etiquetes dinàmiques; les versions antigues els ometen.

degraded_since_unix_ns identifica l’inici de la degradació actual i degraded_duration_ns la seva durada transcorreguda, inclosos els estats degraded-closed i control-failed. Una conciliació completa reeixida restableix tots dos; open_duration_ns continua sent el temps acumulatiu d’obertura confirmada i té un significat diferent. El JSON d’estat CLI exposa aquests camps addicionals. La vista Nodes mostra diagnòstics agregats d’admissió per al Hunter o processador/Tap seleccionat tant en disposició de taula com de graf. En aquests diagnòstics no apareixen adreces d’extrems, identitats de trucada ni errors bruts de l’analitzador/backend. Els nodes antics ometen els camps nous i els clients antics els ignoren.

Aquesta semàntica compartida dels extrems també s’aplica amb eBPF desactivat; obrir l’admissió del nucli no inventa mai atribució en l’espai d’usuari.

El pressupost d’extrems del rastrejador inclou RTP, RTCP separat i claus de diagnòstic antigues basades només en ports. Les claus de diagnòstic no poden autoritzar mitjans, però poden ocupar espai necessari per a extrems exactes posteriors durant canvis de mitjans. Aquest pressupost compartit és anterior a la correcció posterior. Sense admissió, el rastrejador ordinari té un valor de biblioteca per defecte de 64 extrems per trucada i el processador VoIP local de 32; la connexió actual dels comandaments no ofereix cap paràmetre de límit d’extrems per a l’operador. Els paràmetres de recursos d’admissió no augmenten aquests límits ordinaris del registre. Tingueu en compte l’RTCP separat i les claus de diagnòstic en interpretar els avisos de limitació de recursos. L’expulsió o retirada del rastrejador acaba la selecció heretada del Hunter encara que quedi un buffer temporal; les coincidències obsoletes en buffer no autoritzen sortides. Si el conjunt de tokens de propietaris seleccionats es desborda, la recuperació requereix un registre autoritatiu buit, inclosa la retirada de trucades no seleccionades, o una captura reiniciada explícitament després de corregir les condicions de capacitat.

Els avisos SDP informen durant el manteniment de comptadors agregats depurats de casos parcials, fallits, limitats per recursos i suprimits, com a màxim una vegada per interval de 30 segons, més un resum final pendent en aturar-se. S’apliquen els paràmetres normals del logger. No necessiten eBPF ni sortida de logs estructurats. Sniff/Hunter utilitzen informes de buffer, Tap utilitza el seu processador local i el processament distribuït informa de missatges SIP complets per la seva pròpia via. El tractament de paquets no espera l’E/S de logs.

Amb --rtp-ebpf, no necessiteu --rtp-port-range: els extrems RTP i RTCP s’aprenen de l’SDP de la trucada seleccionada, inclosos els extrems fora de l’interval generat per defecte 10000–32768. Utilitzeu --sip-port per limitar la captura de senyalització als vostres ports SIP; és opcional i ometre’l conserva la descoberta en ports arbitraris. Per exemple:

sudo lc hunt voip --processor processor:55555 -i eth0 \
  --rtp-ebpf --sip-port 5060 --tls-ca ca.crt

Si establiu explícitament --rtp-port-range, continua sent una restricció de captura: s’exclouen els extrems de mitjans apresos fora d’aquell interval. Un --filter explícit també continua vigent i ha de permetre la senyalització i els mitjans que voleu capturar.

Els ports SIP explícits també limiten la descoberta UDP sense mitjans: un datagrama sense una capçalera RTP/RTCP reconeguda amb confiança s’exclou fora d’aquells ports de senyalització, fins i tot en un port explícit d’interval de mitjans. El BPF ordinari basat en ports amb admissió desactivada pot admetre aquest datagrama. Els modes shadow i degraded-open conserven aquesta limitació explícita.

Amb --rtp-ebpf, inclòs el mode shadow, els selectors IP/CIDR de Hunt i Tap admeten mitjans elegibles independentment dels extrems de trucades seleccionades. No eludeixen mai els predicats explícits de paquets ni les comprovacions de sortida en l’espai d’usuari. Amb eBPF desactivat, Tap encamina els filtres IP/CIDR mitjançant BPF clàssic. En configuracions mixtes de filtres IP i identitat SIP, un paquet RTP coincident per IP es pot capturar però rebutjar en l’espai d’usuari perquè no està associat a una trucada seleccionada. Per tant, desactivar l’admissió no conserva aquesta sortida de filtres mixtos per als mitjans no associats. Les configuracions Tap realment només IP no tenen cap filtre d’identitat SIP que exigeixi aquesta associació. La selecció de mitjans IP/CIDR del Hunter continua sent independent amb eBPF activat o desactivat.

--rtp-ebpf-mode=shadow registra decisions limitades tot conservant la recepció dinàmica de mitjans. Les fallades d’actualització en execució provoquen per defecte admissió àmplia dins del domini afectat, conservant les restriccions explícites de captura; --rtp-ebpf-failure-policy=closed conserva les entrades vàlides instal·lades sense obrir. Una escriptura fallida de control de mode s’informa separadament. L’aplicació del filtre només es reprèn després de conciliar completament l’estat actual. Una fallada d’inici no activa mai silenciosament shadow ni una captura àmplia.

--rtp-ebpf-shadow-sample-every (per defecte 1) utilitza mostreig determinista compartit per les decisions del nucli, l’observació de captura i l’atribució verificada; YAML utilitza rtp_ebpf.shadow_sample_every sota els paràmetres VoIP del rol. Per a trames completes de fins a 256 bytes, la regla inclou el domini, la longitud completa i tots els bytes de la trama. Un N positiu selecciona aproximadament una de cada N identitats; 1 inclou totes les identitats elegibles. Les còpies idèntiques comparteixen l’elegibilitat i es compta cada còpia elegible. Els hash trien mostres; els bytes exactes estableixen la identitat. Les observacions no mostrejades no ocupen entrades de correlació. Aquest paràmetre sol no activa l’admissió.

Avís de dimensionament shadow: els valors per defecte conserven només 1024 identitats de trames elegibles diferents, mostregen cada identitat (N=1) i mantenen les entrades durant uns 60–61 segons. Això deixa poc espai per a trànsit de fons elegible diferent. Dividir 1024 per aquesta finestra de retenció dona aproximadament 17 identitats elegibles diferents per segon abans de reservar marge per a ràfegues. És un càlcul teòric de dimensionament de l’emmagatzematge, no una taxa de paquets admesa, un rendiment mesurat ni un llindar d’acceptació. Una identitat és una trama completa, de manera que modificar números de seqüència o dades útils crea identitats noves fins i tot dins del mateix flux.

shadow_evidence_capacity limita les identitats de trames completes elegibles diferents. Les entrades de correlació caduquen estrictament després del doble de pending_ttl, en el següent manteniment de retry_interval. El dimensionament aproximat és el nombre d’identitats elegibles diferents per segon multiplicat per aquella finestra, amb marge per a ràfegues; la finestra per defecte és d’uns 60–61 segons. pending_ttl també controla les metadades SIP pendents, de manera que reduir-lo canvia el comportament de promoció. L’historial de propietaris retirats dura més de tres TTL i continua limitat per la capacitat de propietaris. L’historial separat de mostres utilitza el mateix paràmetre de capacitat de proves, compta ocurrències i pot sobreescriure encara que la taula d’identitats tingui espai.

Quan augmenta el volum d’identitats elegibles, considereu augmentar l’interval de mostreig abans d’augmentar la capacitat. El mostreig redueix tant les identitats conservades com el treball dels hooks mentre compta cada còpia de cada identitat elegible. Una capacitat més gran conserva més proves, però augmenta la memòria i el treball de manteniment: el manteniment recorre les entrades mantenint el mutex de correlació i les observacions elegibles concurrents utilitzen TryLock. No obtenir el bloqueig implica una pèrdua real de proves i pot impedir la classificació; una capacitat més gran per si sola no garanteix proves completes.

L’emmagatzematge creix separadament per a la taula de correlació de trames completes, l’historial de mostres de diagnòstic, l’historial de propietaris i l’anell del nucli. La taula d’identitats conté els bytes exactes de les trames i l’estat de correlació; l’historial de mostres conté ocurrències limitades i pot sobreescriure independentment; l’historial de propietaris està limitat per la seva capacitat; l’emmagatzematge de l’anell del nucli està limitat separadament. El mostreig canvia quines observacions entren en aquestes vies però no n’augmenta les capacitats configurades. No s’hi implica cap estimació fixa de memòria per entrada ni garantia de durada del recorregut.

La classificació requereix proves úniques de trama completa, observació de captura, atribució verificada al cicle de vida seleccionat i generació històrica de publicació. Les trames de més de 256 bytes, les proves truncades o duplicades, les mostres tardanes, l’absència de propietari, les diferències de configuració i les revisions d’extrems modificades continuen sent incompletes. El desbordament elegible real o la pressió de bloqueig invaliden afirmacions d’unicitat no demostrades, potencialment també sobre altres proves pendents. La pèrdua persistent pot impedir classificacions útils. L’estat no exposa continguts de paquets ni identitats de trucades. La pèrdua de l’anell del nucli, la sobreescriptura de mostres conservades, les mostres malformades, els errors de recollida i la correlació incompleta tenen comptadors separats. Els rebutjos classificats són observacions mostrejades, mai comptadors exactes de rebuig de tot el trànsit ni proves de paritat.

Els diagnòstics de mitjans absents distingeixen la derivació d’extrems desconeguda dels mitjans intencionadament inactius. Una revisió acceptada d’extrem o completesa restableix l’expectativa, de manera que un paquet de mitjans anterior no pot ocultar un canvi posterior de mitjans. Els avisos per propietari estan limitats en nombre i freqüència i només identifiquen una referència numèrica transitòria del propietari. No amplien mai l’admissió automàticament.

Per defecte, totes les interfícies comparteixen un domini d’observació. Els paràmetres de domini explícits separen trànsit local superposat i han d’agrupar la senyalització i els mitjans relacionats. S’admet Ethernet; la captura cooked any i els predicats VLAN explícits es rebutgen. Els fragments, les cadenes complexes d’extensions i l’encapsulació admesa poden passar per una via de compatibilitat comptabilitzada, cosa que redueix la selectivitat. Els paquets desconeguts i els diagnòstics de mitjans absents no obren cap domini.

La senyalització TCP reassemblada de Tap utilitza la interfície i la marca temporal de captura de l’últim byte que contribueix al missatge. Les interfícies del mateix domini d’observació comparteixen l’emmarcament, inclosos els segments en cua, però cada missatge sintetitzat conserva la font real que hi contribueix. Les interfícies de dominis separats no completen mai les trames de les altres. Les trucades senyalitzades per TCP comparteixen la mateixa comptabilització de capacitat que les senyalitzades per UDP. Les respostes terminals de diàleg només completen després del tractament pel processador (o d’un descart explícit d’injecció), conservant la gràcia de mitjans finals i la neteja específica del cicle de vida. Amb l’admissió desactivada, els límits de trucades no positius conserven el valor antic per defecte; els pressupostos positius configurats continuen aplicant-se.

L’admissió de sockets requereix sockets Linux AF_PACKET, SO_ATTACH_BPF, crides BPF activades, els tipus de mapa necessaris i helpers d’anell. Els anells es van introduir a Linux 5.8; això és un mínim funcional, no una versió mínima del nucli verificada universalment. La configuració del nucli, el comportament del verificador, la política de distribució i les restriccions dels contenidors encara poden rebutjar l’inici. Els sockets de paquets requereixen CAP_NET_RAW; les operacions privilegiades d’objectes BPF requereixen CAP_BPF o l’alternativa antiga CAP_SYS_ADMIN. CAP_NET_ADMIN no és un requisit general del carregador de filtres de socket; la configuració de captura pot requerir permisos independentment. Abans de Linux 5.11, la memòria BPF habitualment compta contra RLIMIT_MEMLOCK; els nuclis més nous poden utilitzar comptabilització de memòria per cgroup. L’aplicació no augmenta automàticament el límit de memòria bloquejada. Vegeu el carregador BPF de Linux, la documentació dels anells i les indicacions de comptabilització de memòria.

Els gestors activats utilitzen el mode immediat i retiren les dades de socket/anell conservades abans de l’activació; els paquets posteriors no es comparen amb un límit permanent del rellotge del sistema. El buidatge d’inici és limitat i permet pèrdua de paquets. Els enllaços no admesos, els predicats VLAN explícits, l’ús fora de línia, la retirada de packet-mmap no admesa i els errors de càrrega, associació o buidatge fan fallar l’inici explícitament.

Vegeu la referència de configuració per a tots els límits de recursos. docs/VOIP_EBPF_ADMISSION.md del repositori proporciona detalls de plataforma, privilegis, diagnòstic i verificació; el pla d’implementació registra l’estat actual d’integració. libpcap continua sent una dependència cgo i cgo no desactiva la concurrència de goroutines.