- kończenie komunikatów głosowych zerem jest złym pomysłem (głos to dane
  binarne i trzeba je będzie specjalnie zakodować przed wysłaniem i odkodować
  po odebraniu; lepiej jest mieć dodatkowe pole "długość komunikatu") +
  znacznik czasowy w komunikacie głosowym
- projekt protokołu nie powinien narzucać implementacji za pomocą wątków
~ jeśli NIC_NIE_ROBIE_STATE jest charakterystyczny dla użytkownika, dlaczego
  błąd w jednym połączeniu (przy utrzymaniu innych) powoduje przejście do tego
  stanu? (to jest chyba tylko trochę niejasno napisane, nie mam formalnych
  zastrzeżeń)
+ ładny i czytelny diagram stanów
~ czyim obowiązkiem jest utworzenie połączeń TCP i UDP na wskazanych portach w
  CHCE_ZADZWONIC_STATE / KTOS_CHCE_ZADZWONIC_STATE ?
- co to znaczy "zarezerwować porty"? Jedyna sensowna z praktycznego punktu
  widzenia interpretacja polega na utworzeniu słuchających gniazd TCP i UDP po
  jednej stronie (chyba lepiej u dzwoniącego, na dowolnych wolnych portach), do
  których podłączy się druga strona używając już dowolnych portów. Wtedy
  komunikat PRZYJECIE_POLACZENIA_MSG faktycznie może zawierać numery portów,
  które trafiły się odbierającemu, ale raczej nie ma to sensu.
+ poprawna obsługa dwustronnej próby zawieszenia
+ skuteczna synchronizacja
+ implementowalność

Ocena: 4.5