SIP의 이해 - 2.SDP (RFC 4566 & RFC 3264 )

                                                                                   글 싣는 순서

                                                                                  1. SIP의 개요 (RFC 3261)
                                                                                  2. SDP의 개요 (RFC 4566 & RFC 3264)
                                                                                  3. Early Media in SDP (RFC 3959 & RFC 3960)
                                                                                  4. RFC 3261의 주요 매쏘드 (I)             
                                                                                  5. RFC 3261의 주요 매쏘드 (II) 
                                                                                  6. RFC 3261의 Response의 이해 
                                                                                  7. PRACK (RFC 3262) 
                                                                                  8. SUBSCRIBE & NOTIFY (RFC 3265, RFC 3680) 
                                                                                  9. INFO  (RFC 2976) 
                                                                                 10. UPDATE (RFC 3311)
                                                                                 11. REFER (RFC 3515)
                                                                                 12. PUBLSIH (RFC 3903)

SDP의 개요
SDP는 Session Description Protocol로 멀티미디어 세션 파라미터를 설정합니다. 즉, H.323프로토콜의 H.245와 같은 기능을 수행합니다.SDP는 현재 RFC 2327을 개정한 RFC 4566이 표준화 되었습니다. 또한, SIP 뿐만 아니라 MGCP / Megaco에서도 멀티미디어 세션 파라미터 설정을 위해 SDP를  사용합니다.

SDP를 이해해야지만, 이기종 장비간 연동이나 장애처리의 많은 부분을 해결할 수 있습니다. 이 글에서는 SDP 4566의 기본적인 부분과 RFC 3264를 기준으로 이야기를 전개하겠습니다. 사실 실제 업무환경에서 필요한 내용 위주로 전개한다는 것이 제 생각입니다. ^^ 

Offer/Answer Model
RFC 3264 An Offer/Answer Model with the SDP를 통해 Capability Exchange를 설명합니다. SIP도 마찬가지로 Request / Response Model이므로 같은 방식으로 동작합니다.  이 Offer / Answer Model이라고 해서 머 특별한 것은 아닙니다. 아래 그림을 참조하시기 바랍니다.

 

위 그림은 SIP Proxy Server가 없는 것으로 가정한 것입니다. Invite 메세지에 SDP메세지가 포함되어 전송되고, 이때 Alice의 사용가능한 Capability가  Offer됩니다. 200 OK 메세지에 SDP에는 Bob의 사용가능한 Capability가 Answer 되고, RTP가 개방될 수 있습니다. 

SDP Lines Message 설명
SDP도 SIP 마찬가지로 텍스트 기반이며, 다음의 내용을 포함합니다.

• v = protocol version
• o = owner/creator and session identifier )
• s = session name
• c = connection information – not required if included in all media
• k = encryption keys
• t = time the session is active
• m = media description and transport address
• a = (zero or more) media attributes lines

위의 내용에서 관심가질 사항은 딱 두개입니다 "m"과 "a"입니다. 실제 사용될 코덱과 코덱의 속성에 대해 설명합니다.

위의 그림은 SDP의 일반적인 메세지 포맷을 나타낸 것입니다. "m"의 내용을 보면 Media는 음성이며 UDP port 49172를 사용하고, 코덱은 0를 쓴다고 되어 있습니다. 코덱 0은 a=rtpmap에 표시되어 있습니다. PCMU/8000 이라고 되어 있네요 1초를 1/8000로 샘플링한 G.711ulaw 코덱을 사용하자고 보냅니다. 이런 것이 SDP의 역할입니다. 좀 깊게 알고 싶으신 분은 "SIP 화상회의 패킷 분석" 자료를 참조하시기 바랍니다. 

RFC 3264의 기본 예제
RFC 3264 에는 SDP 교환에 대한 예제가 나와 있습니다. 이를 읽어보시면, Media capability에 대한 교환과 표시를 쉽게 이해할 수 있습니다. 개인적으로는 상당히 잘 정리되고, 쉽게 이해할 수 있는  RFC 문서라고 생각됩니다.  이 부분의 내용은 RFC 3264의 10.1절에 나와 있는 내용입니다.

Caller인 엘리스가 Callee인 밥에게 Offer를 시도합니다.

 

 

 

 

 

 

위의 내용을 보면, 하나의 양방향 Audio Stream과 두 개의 양방향 Video Stram을 엘리스가 요구합니다. 세부적인 내용은 설명하지 않아도 되리라 생각합니다.  이에 아래 처럼 밥이 Answer를 합니다.

엘리스의 Offer와 어떤 차이가 있는 지 보시면, 첫번째 Video에 대한 속성 "a=rtpmap:31 H261/900000" 라는 부분이 없습니다. 즉, 밥은 첫번째 영상을 받고 싶어하지 않습니다. 따라서,  음성과 두번째 영상만을 서로 주고 받을 것입니다.  

이 시점에서 밥은 엘레스에게 음성 UDP 포트를 49920에서 65422로 변경을 Offer합니다. 헐 예제를 만들려니까 아주 복잡하게 만듭니다. 또한, 수신 전용의 이벤트 처리를 위한 RTP Payload Type 110인 음성 채널 하나를 더 요청합니다. 이 음성 채널은 실제 음성을 교환하는 것이 아니라 이벤트 처리만을 담당하게 될 것입니다. 

이 Offer에 엘리스는 다음과 같이 Answer합니다. 밥의 요청을 모두 수락한 것입니다.  밥의 수신 전용이므로, 엘리스의 송신 전용 음성 채널 개방이 합의 되었습니다.

 RFC 3264의 제공된 다수의 코덱에서 선택하기
일반적으로 IP Phone이나 Gateway의 경우 DSP를 사용합니다. SIP 단말의 지원 코덱은 DSP에 전적으로 의존하게 됩니다. 아래 그림처럼 엘리스는 밥에게  하나의 음성 채널을 개방하며, 사용가능한 코덱은 G.711ulaw, G.723, G.729 3개임을 나타내며,선호하는 코덱은 G.711ulaw임을 나타냅니다.  "a=inactive"는 코덱이 선택되기 전까지는 Media를 받아들일 수없음을 의미합니다.

밥은 엘리스에게 사용가능한 코덱은 2개라고 보내며, 선호하는 것은 G.711ulaw라고 보냅니다. 여전히 inactive 상황입니다.

이 때에는 서로 새롭게 코덱을 선택하게 되고, inactive 상태를 sendrecv로 전환하도록 다시한번 Offer 와 Answer를 교환합니다. 일반적으로는 Offer 또는 Answer상의 맨 상위 코덱을 사용하는 것이 일반적입니다.   

일반적인 SIP 시그널링 예제
지금까지 SDP의 입장에서만 살펴보았습니다. 전체적인 프로세스 상에서 어떻게 움직이는 지 확인하겠습니다.

엘리스는 Invite with SDP로 Offer합니다. 내용은 단순합니다. 음성, UDP Port 49172, 지원 코덱(G.711ulaw, G.723, G.729) 그리고 이중에서 G.711ualw를 선호함을 나타냅니다.

밥은 200 OK with SDP로 음성, UDP Port 3456, 선호 코덱 G.711ulaw로 보냅니다.  코덱은 선택되었으며, 반드시 엘리스에 의해 ACK 되어져합니다.

 이 장에서는 Invite with SDP를 살펴보았습니다. 그러나, 경우에 따라서는 Invite without SDP가 많은 경우에 발생합니다. 이러한 경우에는 SDP 교환은 어떻게 발생할까요?  ^^ 다음 챕터에서 살펴봅시다.

결언
패킷 분석을 통해 몇 번씩 설명했던 부분이지만, 이렇게 RFC 문서를 기본으로 다시 한 번 정리를 하였습니다.  RFC 4566 SDP는 첫부분만 보면, 굳이 읽어 보실 필요가 없을 듯합니다. 저도 읽지 않았습니다.^^ 그러나 RFC 3264는 내용도 단순히 실제적인 SDP를 이해할 수 있는 내용이므로 시간나면 읽어보시기 바랍니다. 다음에는 RFC 3960 ealry media 협상에 대해 살펴보겠습니다.

-----------------------
라인하트
linecard@naver.com
CCIEV #18487