SKALA

Jitsi 이용법 총 정리!!

붉은범 2025. 5. 3. 01:01
반응형

Jitsi 는 오픈소스 기반 비디오 컨퍼런스 솔루션!!!

 

직접 손수 화상회의를 WebRTC로 구축하는건 정말 정말 너무 힘들다....

STUN 서버니, TURN서버니, 뭐니, 시그널링 서버니, Mesh, SFU, MCU 이런 것들 전부 다 알아야 하고 구현도 할 줄 알아야 한다. 진짜 농담아니고 GPT한테 다 맡겨도 얘도 못 만들어낼 정도다. 

진짜 신경 쓸 것도 너무 많고 안되는 것도 너무 많고.... 그래서 오픈 소스 기반 비디오 컨퍼런스 솔루션인 Jitsi를 사용해보자!!!

근데 한국어로는 레퍼런스가 너무 없고.... GPT도 계속 할루시네이션만 만들어내고.... 그래서 화가나서 직접 공식 홈페이지를 뒤져가며 정리를 한다.

 

일단 기본적으로 Jitsi에서는 매 회의마다 5분정도의 제한을 걸고 무료 호스팅 서버를 제공한다.

여기서 테스트는 가능함!! 하지만 시간 제한 5분에 워터마크까지 있다

저기 보이는 것이 Jitsi 무료 서버 주소!!

 

 

이런식으로 왼쪽 위에 Jitsi 워터마크가 새이고 5분 제한이 있다고 왼쪽 아래에 명시된다.

참고로 저 UI들은 직접 만든 것이다. 원래는 Jitsi에서 UI를 모두 제공하니 되도록이면 그걸 쓰자!!!

우리 팀은 다른 기능들도 넣어야 되다 보니 UI를 변경하였다.

 

그렇다면 워터마크도 없애고 시간 제한도 없애는 방법은...?

1. EC2에 직접 서버 호스팅

2. Jitsi as a Service(Jaas) 사용하기

 

 

1번의 경우에는 뭐 Jitsi Github에서 clone받아서 docker-compose로 컨테이너를 띄우고 뭐 설정하고 하면 된다는데, EC2 RAM을 최소 2GB를 요구한다고 Jitsi 공식 문서에서 설명하고 있다.

우리는 t2.micro, 즉 RAM 1GB를 사용하고 있기 때문에 힘들다

심지어 우리 EC2에는 컨테이너가 4개 띄어져있다.

거기에 추가로 nginx도 붙어 있어서 설정이 정말 까다롭다. 그렇기에 그냥 2번으로 하기로 결정했다.

 

 

https://jaas.8x8.vc/#/

 

Jitsi as a Service – World's easiest way to add meetings to your apps

The simplest integration available out there allows you to embed our meeting into your own website or mobile app with just few clicks.

jaas.8x8.vc

사이트에 접속해서 회원가입을 하면 25MAU(월간 활성 사용자) 까지는 공짜로 해준다고 한다.

그리고 활성 사용자 숫자는 Device기준이다!!

 

이런식으로 AppID를 받고 프론트에서 적절히 해당 AppID를 넣어주면 끝!!

 



 

정상적으로 워터마크도 없어지고 시간제한도 없어졌다!!

 

추가로 WebRTC구성은 

MESH, SFU, MCU 이렇게 있다

우리의 GOAT Jitsi는 SFU(Selective Forwarding Unit)를 사용한다.

 

1. Mesh (P2P 연결 구조)

  • 구조: 모든 참가자가 모든 다른 참가자와 직접 P2P 연결
  • 장점:
    • 서버 비용 거의 없음 (중앙 서버 없이 작동)
    • 지연(latency)이 가장 낮음 (직접 연결)
  • 단점:
    • 연결 수가 많아지면 기기 부하 급증 (N명이면 N-1개의 연결)
    • 대역폭 소모 큼 (예: 5명 = 4개의 업로드 스트림 필요)
  • 적합한 경우:
    • 1:1 통화 또는 소규모 그룹 (최대 3~4명)

2. SFU (Selective Forwarding Unit)

  • 구조: 클라이언트들이 미디어를 SFU 서버에 업로드하고, SFU는 필요한 스트림만 포워딩
  • 장점:
    • 확장성 좋음 (참가자 수 늘려도 클라이언트 부담 적음)
    • 클라이언트는 1개의 업로드 스트림만 유지
    • 다자간 화상 회의에 적합
  • 단점:
    • 서버 비용 발생
    • SFU는 미디어 처리를 하지 않음 → 혼합 불가
  • 적합한 경우:
    • 5명 이상의 다자간 회의
    • 성능과 품질의 균형이 필요한 서비스 (ex: Zoom, Google Meet 등)

3. MCU (Multipoint Control Unit)

  • 구조: MCU 서버가 모든 참가자의 미디어를 받아서 믹싱한 후, 다시 각 클라이언트에 단일 스트림 전달
  • 장점:
    • 클라이언트 입장에서는 처리 부담이 거의 없음 (단일 스트림만 수신)
    • 네트워크 환경이 나쁜 사용자에게도 안정적인 전달 가능
  • 단점:
    • 서버가 미디어를 인코딩/디코딩/믹싱하므로 서버 부하 큼
    • 지연이 발생할 수 있음 (믹싱 시간)
  • 적합한 경우:
    • 저사양 기기 대상 서비스 (예: 교육용 태블릿, 일부 원격의료)
    • 방송형 회의 (1명 말하고 나머지는 듣기만 하는 구조)
반응형