big-microphone-99982
12/19/2025, 4:21 AMtall-airline-16756
12/19/2025, 4:21 AMtall-airline-16756
12/19/2025, 4:21 AMcurl -X POST "<https://YOUR_LIVEKIT_HOST/twirp/livekit.RoomService/DeleteRoom>" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"room": "삭제할_룸_이름"
}'
요점 요약
• 엔드포인트: POST /twirp/livekit.RoomService/DeleteRoom
• 바디 필드: `room`에 삭제할 룸의 이름(룸 ID 아님)을 넣습니다.
• 인증: Authorization: Bearer <JWT> 헤더에 유효한 토큰 필요(토큰에 roomCreate 권한 포함).
• 결과: 해당 룸이 삭제되고 연결된 참가자들은 끊깁니다.
원하시면:
• 사용 중인 LiveKit 호스트(예: myproject.livekit.cloud)와 예시 룸 이름을 알려주시면 curl 명령을 맞춰 드리겠습니다.
• 또는 JWT 토큰 생성 예시가 필요하시면 방법도 안내해 드릴게요. Sources: Managing rooms | LiveKit docs | SIP APIs | LiveKit docsbig-microphone-99982
12/19/2025, 5:31 AMtall-airline-16756
12/19/2025, 5:32 AMDeleteRoom 호출 시 해당 룸은 종료되고 참가자 연결은 끊기며 더 이상 활성 세션 역할을 하지 않아야 합니다.
• 하지만 같은 룸 이름으로 빠르게 CreateRoom → DeleteRoom 을 반복하면 시스템이 짧은 시간 내에 같은 ID를 재사용할 수 있습니다. 따라서 Session Events에서 반복 생성/삭제가 발생할 때 ID 재사용 또는 타이밍 차이로 인해 혼란스러운 기록이 보일 수 있습니다.
원인 요약 (간단)
• 삭제와 생성 요청 사이의 타이밍, 데이터 반영 지연 또는 내부 리소스 정리 지연으로 인해 ID가 재사용되거나 이벤트 순서가 겹칠 수 있습니다.
권장 조치
• 동일한 룸 이름으로 테스트할 때는 룸 이름에 타임스탬프나 UUID 등 고유 접미사를 붙여서 각 세션이 확실히 별개가 되도록 하세요.
• 자동화된 테스트나 프로덕션에서 ID 재사용을 피하려면 룸 생성 시 고유 식별자를 포함시키는 것이 가장 확실합니다.
더 확인해드릴까요?
• 이벤트에 표시된 실제 룸 ID(또는 이벤트 로그 일부)를 공유해 주시면, 재사용 여부를 구체적으로 확인해 보고 원인 추적에 도움 드리겠습니다. Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Managing rooms | LiveKit docs