Chapter 5. SDP
5. SDP의 협상 방식
SDP는 단말 간의 멀티미디어 세션과 관련된 미디어 타입 및 포맷을 협상하는 프로토콜입니다. SDP는 Offer/Answer 방식으로 협상하고 반드시 SIP 메세지를 통해서 전달됩니다. SDP Offer가 어떤 SIP 메세지에서 전달되느냐에 따라 협상 방식은 두 가지로 나뉩니다.
- Early Offer
INVITE 메세지를 전송할 때 SDP Offer를 포함하는 방식으로 가장 널리 사용됩니다. INVITE 메세지에 포함된 SDP Offer에 대한 SDP Answer는 200 OK 나 180 Ringing과 함께 전달됩니다. 호를 시도하는 발신자가 SDP 협상의 주도권을 갖습니다. - Delayed Offer
INVITE 메세지를 전송할 떄 SDP Offer없이 전송하는 방식으로 시스코 CUCM이 대표적으로 사용합니다. 180 Ringing 이나 200 OK에 포함된 SDP Offer에 대한 SDP Answer는 ACK와 함꼐 전달됩니다. 호를 수신하는 수신자가 SDP 협상의 주도권을 갖습니다.
RFC 권고안은 두 가지 협상 방식을 모두 정의하였습니다. Early Offer는 미디어 채널의 협상이 빠르고, Delay Offer는 코덱 협상이 확실합니다.
6. 미디어 클리핑과 링백톤의 문제
아래 그림은 일반적인 SDP Early Offer 상황에서 코덱을 결정하는 과정과 미디어가 전달되는 상황을 정리한 것입니다. 통화하는 과정과 SIP 및 SDP 메세지가 송수신되는 과정을 같이 정리해보겠습니다.
엘리스는 수화기를 들고 다이얼링을 하는 순간 전화기는 INVITE 메세지와 함께 SDP Offer를 송신합니다. 밥의 전화기는 따르릉 따르릉하면서 벨이 울리면서 앨리스의 전화기로 180 Ringing 메세지를 송신합니다. 엘리스의 전화기는 앨리스에게 링백톤(Ringback Tone)을 들려주면서 밥의 전화기가 울리고 있다는 것을 알려줍니다. 밥은 벨소리를 듣고 수화기를 드는 순간 200 OK 메세지와 SDP Answer가 엘리스의 전화기로 송신됩니다. 200 OK를 받은 엘리스의 전화기는 ACK를 밥에게 송신하면서 통화가 시작됩니다.
밥은 수화기를 드는 순간 "여보세요" 또는 "Hello"라고 말하게 되고 앨리스는 정확하게 들어야 하므로 미디어 채널이 개방되는 시점이 중요합니다. 정확한 시점은 SDP 협상이 완료되는 200 OK 및 ACK 송수신 이후입니다. 현실적으로 미디어 채널이 개방되는 시점으로 인해 두 가지 문제가 발생합니다.
- Remote Ringback
180 Ringing 메세지를 전달받은 엘리스의 전화기는 자체적으로 Local Ringback tone을 발생시킵니다. 즉,미디어 채널이 개방되지 않아도 전화기가 "드르륵 드르륵" 소리를 만들어 주면 발신자인 앨리스는 통화가 정상적으로 이루어지고 있다는 것을 인지합니다.
현실에서는 컬러링이나 착신측에서 보내주는 Remote Ringback Tone (링백톤)을 사용합니다. 앨리스는 로컬 링백톤 대신 최신 음악의 컬러링을 듣게 해야 하지만, 문제는 아직 미디어 채널 협상이 끝나지 않은 상태입니다. - Media Clipping
보통 사람들은 수화기를 들면서 "여보세요"라고 말하지만, ACK를 수신하기 전까지 미디어 채널은 개방되지 않습니다. 또한, SIP 시그널링은 다수의 SIP Proxy를 거쳐서 전달되지만, 미디어를 전달하는 RTP는 전화기와 전화기 간에 최단 경로로 전달되므로 시그널링보다 미디어가 더 빨리 전달될 가능성이 높습니다. 논리적으로 Media Clipping이 발생할 가능성은 높습니다.
Media Clipping이란 밥의 "여보세요"가 엘리스에게는 "보세요"라고 들리는 것처럼 선두음이 짤리는 현상을 가리킵니다.
컬러링과 미디어 클리핑 문제는 심각한 것으로 인터넷 전화에서는 반드시 해결해야 하는 문제입니다. 어떻게 해결할 수 있는 지를 생각해 보겠습니다. 미디어 클리핑(Media Clipping)은 이론적으로는 충분히 발생할 수 있지만, SDP Early Offer 협상만으로도 문제를 해결할 수 있습니다. UAC (발신자)가 Offer를 전송하자 마자 수신되는 미디어 패킷을 재생할 준비를 하기 때문입니다.
Remote Ringback 문제를 해결하는 방법은 SDP Offer / Answer 협상 이전에 Media 채널이 개방되어야 합니다. 기존의 SDP 협상 방식으로 개방되는 미디어 채널로는 원격 링백톤이나 컬러링을 처리할 수 없으므로 다양한 방법을 고민해 보아야 합니다.
7. Early Media 의 이해
RFC 3960 "Early Media and Ringing Tone Generation in the SIP” 에서 원격 링백톤 문제를 해결하기 위한 방법으로 게이트웨이 모델과 어플리케이션 서버 모델을 각각 설명합니다. RFC 3960의 Early Media는 Early Media Session을 통하여 송수신되는 미디어를 가리킵니다. Early Media Session은 200 OK 및 ACK 이후에 열리는 Regular Media Session 이전에 개방되는 세션으로 INVITE 부터 최종 응답까지만 개방됩니다. Early Offer의 최종 응답은 200 OK이며, Delayed Offer의 최종 응답은 ACK입니다.
PSTN상에서 수신자가 Alert 메세지를 보내면 Ringback tone은 PBX에서 표준화된 링백톤을 재생합니다. SIP망에서 링백을 재생하는 방법은 링백톤 말고도 전화기 디스플레이에 단순 메세지나 그림으로 표시 하기도 하므로 표준화된 방법을 결정할 수 없지만 주로 PSTN 전화기의 방식을 모방합니다.
일반적으로 SIP 전화기는 180 Ringing 수신 후 원격으로 부터 링백톤이나 컬러링이 수신되지 않으면 발신자에게 로컬 링백톤을 재생합니다. 만일 재생 중에 Announcement 또는 컬러링이 UAS로 부터 전달되면 UAC는 로컬 링백톤 재생을 중단하고 UAS로 부터오는 Media를 재생합니다.
하지만 UAS가 early media 전송하려는 의도없이 Early Media Session을 열거나 Early Media Session 개방 전에 Early Media를 보내기도 하기 때문에 UAC는 쉽게 로컬 링백톤을 재생해야 할지 Early Media를 기다려야 할지를 알 수 없습니다. UAC는 링백톤 재생에 관한 정책이 필요하며, 다음은 일반적인 정책입니다.
1) 180 Ringing을 받지 않는 한, local ringing을 재생하지 않는다
2) 180 Ringing을 받았으나 수신되는 미디어 패킷이 없다면, local ringing을 재생한다.
3) 180 Ringing을 받았으면서 Media 패킷이 수신된다면, Media를 재생하고 local ringing을 재생하지 않는다.
180 Ringing은 수신측의 전화기가 울리고 있음을 의미하며, UAS는 Early Media Session의 상태와 상관없이 응답을 보내야 합니다. 이 정책은 미디어 게이트웨이나 미디어 게이트웨이 컨트롤러에서 구현하기는 어렵지만, Media Clipping을 제거하기 위해 들어오는 미디어 패킷을 재생해야 합니다.
SIP는 다른 시그널링 프로토콜과 달리 Early Media indicator가 없습니다. 이 indicator가 있다면 UAS가 원격 링백톤이나 announcement를 제공하고자 할 때 UAC가 로컬 링백을 재생하지 않도록 하는 것이 가능합니다. 그러나, SIP와 Media의 경로가 서로 달라서 SIP 시그널링보다 Media가 먼저 도착할 확률이 높습니다.
게이트웨이 모델은 단말(UA)이 Early Media와 Regular Media를 구분할 수 없을 때만 사용됩니다. Gateway 모델이 효과적으로 적용될 수 있는 UA는 PSTN 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 상황에서 UAS들은 Regular Media를 위한 Offer/Answer 교환과는 독립적인 Early Media를 위한 Offer/Answer교환이 필요합니다. 그래서 Application Server Model은 Early Media Session을 설립하기 위해 UAS가 애플리케이션 서버의 역할을 합니다. Regular Media를 위한 Offer/Answer 교환과 분리하여 Early Media를 위한 Offer/Answer 교환을 합니다. UAC는 정확한 순간에 Early Media와 Regular Media를 전환합니다. Early Media를 위한 별도의 Offer/Answer 교환으로 UAC는 로컬 링백을 재생할지 아닐지를 결정할 수 있습니다.
Application Server Model을 구현하기 위한 가장 효과적인 방법은 독립적인 SDP Offer/Answer 교환을 위해 라우팅 가능한 URI를 이용하여 기존 다이얼로그와 다른 다이얼로그를 생성하는 것입니다. 새롭게 생성된 Early Media를 위한 다이얼로그는 Regular Media를 위한 다이얼로그와 연결하면 됩니다. 그러나, 기존 다이얼로그 안에서 모든 미디어 채널에 대한 Offer/Answer 교환을 하는 것은 여러가지 현실적인 이점이 있습니다.
- 단순하다.
- 동기화 문제가 없다. 세션 생성이 완료될 때 Early Meda를 위한 모든 다이얼로그가 종료됩니다.
- 별도의 라우팅 가능한 URI가 필요 없다
- 새로운 다이얼로그에 잘못 적용된 서비스와 관련된 서비스 상호 작용 문제를 일으키지 않는다.
- 방화벽 투과 및 관리가 쉽다.
결국 Application Server Model을 이용할 경우에 하나의 다이얼로그 내에서 Early Media를 처리하는 것이 현실적인 면에서 가장 효과적입니다.
마치며
Application Server Model을 구현하기 위해 새로운 SIP 헤더를 이용할 지라도 SDP Offer에 대한 응답은 빨라야 200 OK 입니다. 180 Ringing과 동시에 Early Media Session을 개방하기 위해서는 어떻게 해야 할까요? 지금까지 배운 SIP Call Flow로는 불가능합니다. 새로운 SIP 메쏘드가 필요해지는 시점입니다.
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
