ce se intampla cand spunem "m-a dat afara mini-ebts-ul"

 mda. nu ne da afara nimeni, nici macar mini-ebts-ul. problema nu e de la "noi". :) problema este de la core. in acel moment cand primim "ton de ocupat", se intampla chestii la nivel de server. deci nu depinde de "noi", cei care avem mini-ebts-uri. Stii cum era demult, luai la palme televizorul, si apoi cineva venea cu ideea, "eu cred ca e de la 'ei'.. " :)) Am analizat un pic cu AI-ul niste loguri, si asta am gasit. Nu stiu inca daca este corecta analiza, pentru ca eu nu prea am incredere in "solutiile" astea, gen e de la "ei". 

Putem căuta în loguri mai vechi. Știi aproximativ când s-au întâmplat întreruperile? Ce dată/oră?

bash 

# Vede ce zile sunt disponibile in jurnale
journalctl -u flowstation --list-boots 2>/dev/null || \
journalctl -u flowstation --since "7 days ago" --until "now" | grep -E "Hangtime|discon

  
Un singur boot, deci toate logurile sunt în sesiunea curentă. Caută în intervalul 22:00-01:00 de azi noapte:
bash
journalctl -u flowstation --since "2026-07-23 22:00:00" --until "2026-07-24 01:00:00" \
  | grep -E "ERROR|WARN|disconnect|Disconnect|timeout|brew|Brew|release|Release|failed|Failed" \
  | grep -v "DSetup\|DRelease\|circuit\|Circuit\|DConnect\|DTxCeased\|DCallProc" \
  | head -80
Din loguri văd că totul pare să funcționeze normal în intervalul 22:00-01:00 — apeluri normale, fără erori de conexiune Brew.
Observ ceva interesant — la 23:08:34 și 23:09:41 și 23:10:13 apare:
WARN BrewEntity: updating forwarded call on carrier=1521 ts=2 (was call_id=X gssi=226777) -> (call_id=Y gssi=226777)
Asta înseamnă că în timpul transmisiei tale, core-ul a schimbat call_id-ul — posibil o re-rutare la nivel de server. Asta ar putea cauza o scurtă întrerupere audio fără ca BS-ul să cadă.
Caută mai specific momentele când ai simțit întreruperea:
bash
journalctl -u flowstation --since "2026-07-23 21:00:00" --until "2026-07-23 23:00:00" \
  | grep -E "WARN|ERROR|backhaul|timeout|connection" \
  | grep -v "DSetup\|identify_timeslots\|type4_struct" \
  | head -50


root@dex:/home/dex# journalctl -u flowstation --since "2026-07-23 21:00:00" --until "2026-07-23 23:00:00" \
  | grep -E "WARN|ERROR|backhaul|timeout|connection" \
  | grep -v "DSetup\|identify_timeslots\|type4_struct" \
  | head -50
Jul 23 21:00:21 dex bluestation-bs[283306]: 21:00:21.551 WARN                [entities/llc] llc_bs_ms.rs:755:          schedule_retransmissions: SSI 2263098 carrier 1521 N(S) 1 exhausted retransmissions
Jul 23 21:00:25 dex bluestation-bs[283306]: 21:00:25.788 WARN                [entities/llc] llc_bs_ms.rs:153:          received unexpected ACK for SSI 2263098 carrier 1521 N(R) 0
Jul 23 21:29:53 dex bluestation-bs[283306]: 21:29:53.535 INFO                [entities/cmce] pdu.rs:215:            -> DRelease { call_identifier: 98, disconnect_cause: SwmiRequestedDisconnection, notification_indicator: None, facility: None, proprietary: None }
Jul 23 21:39:40 dex bluestation-bs[283306]: 21:39:40.472 WARN                [entities/net_brew] worker.rs:645:        BrewWorker: server error type=1: 19 bytes
Jul 23 21:39:40 dex bluestation-bs[283306]: 21:39:40.473 ERROR               [entities/net_brew] entity.rs:351:        BrewEntity: server error type=1 data=19 bytes
Jul 23 21:39:45 dex bluestation-bs[283306]: 21:39:45.518 INFO                [entities/cmce] pdu.rs:215:            -> DRelease { call_identifier: 99, disconnect_cause: SwmiRequestedDisconnection, notification_indicator: None, facility: None, proprietary: None }
Jul 23 22:00:26 dex bluestation-bs[283306]: 22:00:26.221 WARN                [entities/mm] mm_bs.rs:1233:              ISSI 2263098 requested attach/detach for 15 groups; capped at 12 per ETSI PDU size limit. MS will retry remaining in next cycle.
root@dex:/home/dex#





Găsit! La 21:39:40 apare eroarea critică:
WARN  BrewWorker: server error type=1: 19 bytes
ERROR BrewEntity: server error type=1 data=19 bytes
Urmată imediat de DRelease la 21:39:45 — apelul a fost terminat forțat de core/server.
Asta e cauza întreruperii — serverul TetraPack a trimis o eroare de tip 1 care a dus la 
terminarea apelului. Nu e o problemă la tine local, e o eroare venită de la core.
Verifică dacă mai sunt astfel de erori în alte momente:
bash
journalctl -u flowstation --since "2026-07-22 07:00:00" --until "2026-07-24 02:00:00" \
  | grep -E "server error|ERROR.*Brew|backhaul disconnected" \
  | head -30
Dacă apare frecvent, trebuie raportat adminilor TetraPack — e o problemă de server, 
nu de configurația ta.
Eroarea apare de 2 ori în 2 zile — 22 iulie la 23:50 și 23 iulie la 21:39. 
Nu e frecventă, deci nu e o problemă sistematică la tine.

Concluzie: Problema nu e la sistemul tău local. Este o eroare trimisă de serverul TetraPack 
(server error type=1) care forțează terminarea apelului. 
Cele 19 bytes de date ar putea fi un mesaj de eroare specific protocolului Brew.

Recomandări:


Raportează adminilor TetraPack cele 2 incidente cu timestamp-urile exact
 — ei pot vedea în logurile serverului ce s-a întâmplat la 22-07 23:50 și 23-07 21:39
Nu e nimic de modificat la configurația ta — sistemul tău a răspuns corect la eroarea serverului.