사용자 음성이 입력되어 봇 응답 오디오로 돌아오기까지의 전체 경로와 바지인(barge-in) 처리
1. 오디오 수신과 EPD 전달. 클라이언트 마이크 오디오는 WebRTC Gateway가
받아 Opus를 디코드·리샘플해 16kHz/16bit/mono raw PCM으로 변환하고, 세션별 WSS bridge로
Socket Backend의 /sohri에 전달한다. Socket Backend는 AudioInputGate로
"DM/TTS 응답 준비 중" 여부만 확인하고, 오디오를 디코딩하거나 STT를 직접 수행하지 않은 채
그대로 외부 EPD 서버로 넘긴다.
2. EPD의 바지인 단계 처리. EPD는 발화 구간 감지와 STT를 내부에서 수행하고,
activity_id 단위로 CANDIDATE(발화 후보) → CONFIRMED(발화
확정) → END(STT 결과 포함 종료) 또는 CANCELLED(오탐 취소) 단계를
스트리밍한다. 이 신호는 WebRTC Gateway에서 speech_candidate/
speech_candidate_cancelled/speech_started 데이터채널 이벤트로 변환되어,
재생 중이던 TTS 오디오의 볼륨을 낮추거나(duck) 일시정지하는 상태기계를 구동한다. 확정된
interrupt/cancel, generation 변경, 큐 포화 또는 half-duplex input gate에서는 오래되거나
초과한 오디오를 의도적으로 폐기한다.
3. 사용자 턴 확정과 DM 호출. CONFIRMED 상태에서
END가 STT 텍스트를 동반하면 Socket Backend가 처리 리스(lease)를 확보해 동시에
하나의 사용자 턴만 처리하고, 사용자 메시지와 STT confidence를 저장한 뒤
POST /dm/v1/message로 Graph Builder를 호출한다(최대 3회 재시도, 지수 백오프).
4. DM 응답과 TTS 합성·전송. DM 응답이 오면 Socket Backend는 지연을 줄이기
위해 응답 텍스트를 먼저 TTS로 합성(세션의 voicePreset 또는 provider/model/voiceType
설정에 따라 CLOVA·Fish Audio·Inworld·Gemini 중 선택)한다. 일반 경로는 오디오 프레임을
dialog_response보다 먼저 보내고, 스트리밍 경로는 자막용 dialog_text
이후 PCM 청크와 최종 dialog_response를 보낸다. 오디오는
WebRTC Gateway에서 Opus로 인코딩되어 RTP로 클라이언트 스피커까지 재생된다.
5. 대화 종료 후처리. DM이 세션 종료를 알리면 대화 요약(LLM), Vocal Biomarkers 기반 감정·치매·우울·음성 바이오마커 분석, DM 세션 회수가 순서대로 실행된다.
| 서비스 | 역할 | Sohri 쪽 책임 |
|---|---|---|
| EPD | 발화 구간 감지 + STT | 오디오 중계, 응답 파싱·영속화만 |
| sohri-graph-builder (DM) | 대화 진행/시나리오 실행 | /message·/session 호출, 응답 매핑 |
| TTS 프로바이더 | 음성 합성 | 프로바이더 선택·요청 조립 |
| Vocal Biomarkers | 감정/치매/우울/음성 바이오마커 추론 | 결과 정규화·저장 |
dialog_response보다 먼저 전송되고, 스트리밍 TTS는 dialog_text 이후 PCM 청크를 전송한다.