17장. Early Media의 이해
1. Early Media의 개요
RFC 3960 Early Media and Ringing Tone Generation in the SIP (SIP에서 Early Media와 링백톤)에서 원격 링백톤 문제를 해결하기 위한 방법으로 Early Media를 제시합니다. Early Media는 Early Media Session으로 전달되는 미디어(음성)입니다. Ealry Media Session은 최종 응답 이전에 개방되는 세션이고 최종 응답 이후는 Regular Media Session 이 개방됩니다. Early Offer의 최종 응답은 200 OK이고 Delayed Offer의 최종 응답은 ACK입니다.
2. 링백톤 재생 방식
PSTN 망에서 수신자가 Alert 메시지를 보내면, 발신 측의 PBX가 로컬 링백톤(Ringback tone)을 재생하거나 컬러링을 이용할 경우에는 컬러링 서버와의 미디어 채널을 개방합니다. SIP 망에서 링백을 재생하는 방법은 링백톤, 전화기 디스플레이의 단순 메시지 또는 그림, 동영상 등 다양하므로 표준화된 방법은 없지만 PSTN의 방식을 준용합니다.
SIP 전화기는 180 Ringing 수신 후 원격으로부터 링백톤이나 컬러링이 수신되지 않을 경우에 로컬 링백톤을 재생합니다. 만일 재생 중에 Announcement 또는 컬러링이 UAS로부터 전달되면 UAC는 로컬 링백톤 재생을 중단하고 UAS로부터 전달되는 미디어를 재생합니다. 하지만 UAS는 early media를 전송하려는 의도 없이 Early Media Session을 개방하거나 Early Media Session 개방 전에 Early Media를 보낼 수도 있습니다. 발신 전화기인 UAC는 로컬 링백을 재생해야 할지 원격 링백을 기다려야 할지 결정할 수 없습니다. UAC는 링백 재생에 관한 정책이 필요합니다.
180 Ringing을 수신하지 않는다면, 로컬 링백을 재생하지 않는다.
180 Ringing을 수신하였으나 미디어 패킷이 없다면, 로컬 링백을 재생한다.
180 Ringing을 수신하고 Media 패킷이 있다면, 미디어를 재생하고 로컬 링백을 재생하지 않는다.
180 Ringing은 수신 측의 전화기가 울리고 있음을 의미하며, UAS는 Early Media Session의 상태와 상관없이 응답을 보내야 합니다. 이 정책은 미디어 게이트웨이나 미디어 게이트웨이 컨트롤러에서 구현하기는 어렵지만, Media Clipping을 제거하기 위해 들어오는 미디어 패킷을 재생해야 합니다.
3. 게이트웨이 모델과 애플리케이션 서버 모델
SIP는 다른 시그널링 프로토콜과 달리 UAC가 로컬 링백을 재생하지 않도록 할 수 있는 Early Media indicator가 없습니다. UAS가 원격 링백톤이나 announcement를 제공하려는 의도를 UAC에게 전달할 수 없습니다. 또한, SIP와 Media의 경로가 서로 달라서 SIP 시그널링보다 Media가 먼저 도착할 가능성이 있습니다. 이를 해결하기 위해 RFC 3960 Early Media and Ringing Tone Generation in the SIP에서는 링백톤 재생을 위한 게이트웨이 모델과 애플리케이션 모델을 제시합니다.
1) 게이트웨이 모델
게이트웨이 모델은 단말(UA)이 Early Media와 Regular Media를 구분할 수 없을 때만 사용됩니다. PSTN Gateway 또는 Voice Gateway에서 주로 사용합니다. 게이트웨이는 PSTN과 IP 네트워크를 서로 연결해 주지만 미디어의 내용을 알 수 없으므로 Early Media와 Regular Media 간의 전환을 정확히 인지하지 못합니다.
게이트웨이 모델은 call forking 시 media clipping 이 발생하는 점과 미디어 검출을 통해 로컬 링백을 적당하게 재생해야 하는 문제가 있습니다. RFC 3959 The Early Session Disposition Type for the SIP에서 게이트웨이 모델의 Early Media 문제를 언급합니다. Call Forking의 경우 UAC는 Early Media를 보내는 UAS의 미디어를 모두 재생하지 않고 랜덤 하게 한 개의 Early Media 만을 재생하고 나머지는 묵음(Mute) 처리합니다. 만일 200 OK를 보내는 UAS가 묵음 처리되었다면 묵음 해제 (Unmute)를 위해 새로운 Offer/Answer 교환이 필요하므로 Media Clipping이 발생합니다.
따라서, Call Forking 상황에서 미디어 클리핑 문제를 해결하기 위해서는 애플리케이션 서버 모델이 필요합니다.
2) 애플리케이션 서버 모델
Call Forking 상황에서 UAS들은 Regular Media를 위한 SDP Offer/Answer 교환과는 독립적인 Early Media를 위한 Offer/Answer교환이 필요합니다. 애플리케이션 서버 모델은 Early Media Session을 설립하기 위해 UAS가 애플리케이션 서버의 역할을 합니다. UAC와 UAC는 Regular Media Session과 Early Media Session을 위한 SDP Offer/Answer 협상을 각각 진행합니다. UAC는 정확한 시점에 Early Media와 Regular Media로 전환합니다.
4. 애플리케이션 서버 모델 구현하기
애플리케이션 서버 모델을 구현하기 위한 가장 효과적인 방법은 기존 다이얼로그와 다른 다이얼로그를 생성하는 것입니다. 두 개의 다이얼로그가 생성되므로 라우팅 가능한 별도의 URI 가 필요하지만, UAC는 Early Media 다이얼로그를 정확한 시점에 Regular Media 다이얼로그와 연결합니다.
하지만, 하나의 다이얼로그에서 두 개의 미디어 채널에 대한 SDP Offer/Answer 교환을 하는 것은 여러 가지 장점이 있습니다. 첫 째는 호처리 절차가 단순합니다. 두 번째는 동기화 문제가 없습니다. 세션 생성이 완료될 때 Early Media 다이얼로그가 종료됩니다. 세 번째는 Early Media를 위한 라우팅 가능한 URI가 필요 없습니다. 네 번째는 부가 서비스 적용 시 문제를 일으키지 않습니다. 다섯 번 째는 방화벽 투과 및 관리가 쉽습니다.
결국 애플리케이션 서버 모델을 이용하여 하나의 다이얼로그로 Early Media Session과 Regualr Media Session을 함께 처리하는 것이 가장 현실적인 방안입니다. 애플리케이션 서버 모델을 구현하기 위해 새로운 SIP 헤더를 사용하더라도 SDP Answer가 빨라도 200 OK입니다. Early Media를 전송하기 위해서 180 Ringing과 동시에 개방되어야 하지만, 현재의 Call Flow로는 불가능합니다. 새로운 SIP 메쏘드가 필요합니다.
'엔지니어를 위한 인터넷 전화와 SIP의 이해'를 책으로 만들다
https://brunch.co.kr/@linecard/188
