RTP의 이해

IP Telephony 2008.05.23 16:51

한 동안 업무에 집중하다 보니 글을 올리는 것이 뜸했습니다.   블로그 관리에 소홀해지지만,가끔 올라오는 댓글에 힘을 냅니다. H.323이나 SIP에 대해서는 패킷 분석을 했었는 데 정작 RTP에 대해서는 언급하지 않아서 이번 글에서 좀 자세히 다루어 보도록 하겠습니다.

프로토콜에 대해 이해하기 가장 빠르고 정확한 방법은 표준안을 보는 것이겠지만, 개발자가 아닌 이상에 엔진이어들이 가만히 앉아서 문서를 보는 것은 쉽지 않은 일입니다. 저 또한 장애처리를 할 경우에 참조용으로 주로 사용합니다만, RFC 문서의 경우는 그나마 쉽게 이해할 수 있도록 정리가 잘 되어 있습니다. 특히, RFC의 앞 개요 및 용어 정의 부분만 읽어도 상당히 업무에 도움이 됩니다.  시간나시면, 관심있는 프로토콜에 대해 읽어보실 것을 권해 보드립니다.

RFC 3550의 개요

실시간 음성, 영상 데이타를 IP 네트워크 상에서 전송하기 위해서는 항상 RTP를 사용합니다. RTP는 RFC 1889 A Transport Protocol for Real-Time Applications에 정의되어 있었지만, 2003년 RFC 1889를 대신하는 RFC 3550이 Standards Track으로 채택 되면서, RFC 1889가 폐기되었습니다. 따라서, 요즘 나오는 음성 및 영상 장비들은 RFC 3550을 지원합니다.

간략하게 RFC 3550의 앞부분에 명시된 개요 부분을 요약하면, RTP는 음성, 영상 또는 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트워크를 이용하여 전송하는 응용 서비스를 위한 end-to-end 네트워크 전송 프로토콜입니다. RTP는 IP/UDP를 통해 전송되며, RTCP (Real-time Control Protocol)에 의해 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 미디어 식별 기능을 제공합니다. 

RTP는 음성, 영상, 실시간 데이터 등을 전송하기 위한 프로토콜이라는 것을 알 수 있습니다.

more..


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

댓글을 달아 주세요

  1. 이전 댓글 더보기
  2. Favicon of http://www.nexpert.net BlogIcon 허클베리 핀 2008.09.23 12:08 신고  댓글주소  수정/삭제  댓글쓰기

    ^^ 자주 자주 찾아오시고 좋은 의견 많이 나눴으면 좋겠네요
    갓 입문 하셨다고 하시지만, 열정이 있으신것 보니 대성하실 것 같습니다.
    화이팅

  3. 마야 2009.03.12 16:48 신고  댓글주소  수정/삭제  댓글쓰기

    너무나 명쾌하고 자세한 자료 감사합니다!!

    오타로 의심되는 3 부분을 발견했습니다~

    1. RFC 3550의 개요에서 " RTP 3550을 지원합니다" 가 RTP가 RFC가 아닐까요..

    2. 페이로드를 "분석하거" 음성파일로 (밑에서 몇줄위에.)

    3. RTP가 계속 인입되더라고 호를 종료하는 수가 있습니다. <-- 제가 이해를 못하는건지.. 문장이 좀 어렵습니다. 인입되다??

  4. Favicon of http://www.nexpert.net BlogIcon 라인하트 2009.03.12 21:29 신고  댓글주소  수정/삭제  댓글쓰기

    예, 글 수정하도록 하겠습니다. ^^ 좋은 지적 감사합니다.

  5. loscive 2009.04.01 02:37 신고  댓글주소  수정/삭제  댓글쓰기

    signaling정상으로 되어 연결은 되었으나 음성이 전혀 안들릴경우, jitter가 0ms이고 dsp정상일때 rtp 패킷을 분석해보면 보통 어떤식으로 나타나나요.

  6. 라인하트 2009.04.01 08:55 신고  댓글주소  수정/삭제  댓글쓰기

    흠 우선 RTP 패킷이 수신되고 있는 지 여부를 확인하실 필요가 있겠습니다. 그리고 코덱 네고가 정상적으로 되었는 지도 확인되어야 합니다.

  7. 채운아브지 2009.05.04 10:38 신고  댓글주소  수정/삭제  댓글쓰기

    ^^ 자세한 설명 감솨합니다 , 원문 링크 좀 걸겠습니다. ^^;

  8. Favicon of http://www.gilgil.co.kr BlogIcon 이경문 2009.05.07 03:07 신고  댓글주소  수정/삭제  댓글쓰기

    오래된 글인데 인터넷 검색하다가 발견해서 덧글을 답니다. ^^

    SEQ는 16 bit이기 때문에 통화중에 overflow의 발생은 빈번하게 일어 납니다. 당연히 프로그램상에서 처리를 해 줘야 하죠.

    그리고 packet loss, packet jitter, packet reverse는 자주 일어 납니다. 국내 인터넷 환경에서는 잘 나지 않지만 외국 통화시에는 자주 발생을 하게 되며, 이 경우 다음과 같은 방식에 의해 네트워크의 부하를 주지 않는 식으로 RTP 통신의 변경이 이루어 지도록 해야 합니다.
    1. 코덱을 바꾼다(저대역폭 코덱으로)
    2. 코덱의 bandwidth를 낮춘다
    3. 여러개의 RTP payload를 하나의 패킷으로 처리해서 보낸다.

    • Favicon of http://www.nexpert.net BlogIcon 허클베리 핀 2009.05.08 12:20 신고  댓글주소  수정/삭제

      제 생각에는 RTP Payload를 늘리면, Packet loss에 더 큰영향을 받을 것 같은 생각이 듭니다. 이경문님께서 자세히 설명해 주시면 더 좋을 것 같은데요 ^^ 다시 방문해 주셔서 부연 설명해 주시면 이곳에 계신 분들에게 좋은 기회가 될 듯 싶습니다.

  9. 라인하트 2009.05.07 10:11 신고  댓글주소  수정/삭제  댓글쓰기

    흠.. 깔끔한 덧글 감사합니다. 해외간에 인터넷으로 VoIP를 사용할 경우 잠재적인 Packet Jitter 및 Loss는 피할 수 없을 듯합니다. ^^ 그런데.. SEQ는 무엇을 말하는 건가요? 간단하게 설명해주시면 감사하겠습니다.

  10. Favicon of http://www.nexpert.net BlogIcon 솔민아빠 2009.05.07 20:44 신고  댓글주소  수정/삭제  댓글쓰기

    라인하트님 농담이시라면 좀 썰렁했습니다.

    갑자기 그렇게 질문하시니 저 또한 움찔해지네요.(Sequence 아닌가요? ---왕소심))

    궁금한게 있는데요, 오버헤드를 줄이기 위해 여러 RTP Payload를 하나의 패킷으로 처리해서 보내면 latency가 증가하여 결과적으로 음질을 저하시키지 않을까요?

    그리고, 코덱의 bandwidth를 낮춘다는 것은 어떤 의미인지 설명 부탁드리겠습니다. 압축률이 높은 코덱으로 바꿔서 대역폭을 줄이는 것은 1번에 해당하는것이라서, 다른 의미가 뭐가 있을지 고민중입니다.

    • Lupi 2009.05.08 14:25 신고  댓글주소  수정/삭제

      1. 아마도 Sequence Number를 말씀하신듯 싶습니다..시작 seq는 random이기때문에 만약 60000정도로 시작시쿼스가 정해지고 전송데이터가 많다면 overflow발생의 소지가 충분할 것입니다..관련서적을 보니 위쪽에 라인하트님이 말씀하신데로 초기화되어 사용되거나 16bit를 늘려서 32bit로 사용할 수도 있다고 하네요..
      2. 여러 패킷을 뭉쳐서 보내면 아무래도 문제의 소지가 좀 있을 듯 합니다.. 회선의 상태가 좋다면 괜찮겠지만 회선의 상태가 좋지 않아서 유실되는것이 있고 먼저 보낸 패킷이 늦게 가는일이 빈번하게 발생하여 seq가 꼬여버리기 시작하면 다시 잡기가 힘들지 않을까 걱정이 되네요..
      3. Bandwidth를 낮춘다는 것은 아무래도 압축률이 높은 코덱을 사용하거나 bps를 낮춰서 데이터의 크기를 줄이는 방법이 아닐까 생각됩니다...
      혹시나 틀렸으면 지적 부탁드립니다..('')(..)

  11. 라인하트 2009.05.08 13:53 신고  댓글주소  수정/삭제  댓글쓰기

    헐 Sequence 가 맞다면, 16bit와 통화중 overflow 발생에 대한 상관 관계 유추가 어렵습니다. 혹 아시는 분 있으시나요? 아님 이경문님의 깔끔한 재답변을 기다려야 하나? 자꾸 짧은 지식이 드러나는 듯합니다
    예~~휴

  12. Favicon of http://www.nexpert.net BlogIcon 솔민아빠 2009.05.08 18:22 신고  댓글주소  수정/삭제  댓글쓰기

    Lupi님글에 댓글을 달수가 없군요.

    제가 이해력이 좀 부족해서 그러니 이해해 주시기 바랍니다.

    3번 답글에서 애매한 부분이, 압축률 높은 코덱을 사용하는 것은 위에서 이경문님께서 1번 항목에서 말씀하신 내용이라 충분히 이해가 갑니다. 하지만, 이경문님의 글의 2번 즉, bandwidth를 낮춘다는 부분이 이해가 안가는 것이었는데요, Lupi님의 "bps를 낮춰서 데이터의 크기를 줄이는 방법"이 이에 해당하는 답변인지요?? 전 왜 두분의 설명이 모두 이해가 가지 않을까요? ㅠ.ㅠ

    라인하트님과 계나 묻어야겠군요. ㅋㅋ 아무래도 라인하트님도 진심으로 물어보신듯...
    요즘 바쁘신것 같은데 너무 무리하셔서 그런것 같아요. 충분한 휴식을 권고합니다.

  13. 김광수 2009.05.24 15:21 신고  댓글주소  수정/삭제  댓글쓰기

    라인하트님// 16bit sequence의 limit은 0-65535입니다. 장시간 통화할경우 65535 를 넘는 (overflow) seq가 발생할수 있다는 말로 보입니다^^

  14. 김광수 2009.05.24 15:24 신고  댓글주소  수정/삭제  댓글쓰기

    RTP구현하고 있는데요,

    전송되어오는 스트림을 Dshow 필터에 어떻게 넣어야 재생이 될지요..
    아시는분의 조언을 구합니다.ㅠㅠ

    제가 너무 어렵게 생각하고 있는지.. 잘안되더라구요..ㅠ

  15. Moonshine 2009.05.29 17:47 신고  댓글주소  수정/삭제  댓글쓰기

    16비트 시퀀스는 0~65535 기 때문에 영상 전송의 경우 그리 어렵지않게 65535를 넘기고 한바퀴를 또 다시 돌수도 있습니다. 위의 예에서도 영상전송(H.264)의 경우 연속된 최소 8패킷이 같은 타이밍에 전송되고 있습니다. 개발의 입장에서 보면 변수타입을 Unsigned 16bit로 해놓으면 자연히 65535에서 ++하면 0이 되고요. 이 경우에 수신자는 헷갈릴 소지가 있지요.
    그렇다고 윗분의 말쓰처럼 RTP의 fixed 헤더(12byte)에 속한 SN의 길이를 임의로 32bit로 늘릴수는 없을겁니다. Extended header 를 이용할수는 있겠지만, 그럴 필요 없이 이미 표준(RFC 3550)에 윗분이 궁금한 것에 대해서 설명이 되어있습니다.

    Sequence Number는 중요한 응용에서 처리되어질 가능성(도) 있으므로, 이것은 RTCP에 SR패킷에 의해서 처리됩니다. 몇바퀴 돌았는지에 대한 정보를 가지고 있으면 번호의 연속성을 알아차릴 수 있겠지요? 자세한 사항은 RFC 3550의 6.4.1 을 참조하시면 좋겠습니다.

    • 라인하트 2009.06.02 10:42 신고  댓글주소  수정/삭제

      아주 명쾌한 설명입니다. 문신님.. 아님 달빛님..^^
      글을 보니 IT에서도 행간의 의미를 알야야 겠네요. 한 수 배웁니다.

  16. 경선 2009.06.24 17:53 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요~
    좋은 자료, 좋은 설명 너무 잘 봤습니다. ^^
    궁금한게 있는데.. ㅎㅎ rtp로 전송장비의 현재시각을 알수도 있을까요?
    rtp 타임스탬프로는 데이터의 재생시점만 알수 있어서요.
    넘 뜬금없는 질문이죠 ^^;;

  17. 라인하트 2009.06.25 13:19 신고  댓글주소  수정/삭제  댓글쓰기

    timestamp는 32 bit로 생성되는 값입니다. 정원하신다면, 동기화된 현재의 시각을 가지고 timestamp의 값을 생성하시면, 동기화된 두 장비간의 정확한 시간을 알수 있지 않을까요? ^^

  18. 경선 2009.06.25 16:09 신고  댓글주소  수정/삭제  댓글쓰기

    약속된 장비간 통신에서는 가능하겠네요~~
    답변 감사합니다. ^^
    복 겁나많이 받으세요! ㅎㅎㅎ

  19. 김현민 2011.11.10 01:06 신고  댓글주소  수정/삭제  댓글쓰기

    책에서 부족했던 부분을 쉽게 이해할수 있었습니다 ㅎ 잘 읽고 갑니다

  20. Favicon of http://blog.naver.com/misail0118 BlogIcon 착각은노망의지름길 2015.04.09 19:32 신고  댓글주소  수정/삭제  댓글쓰기

    이쪽 업계에 갓 입문한 초보입니다.
    저녁먹고 휴식하면서 글을 보고 있습니다..ㅋㅋ
    RTP를 이용해서 어플과 카메라를 연동하는 부분을 하는 중인데요
    기본이 되는 자료를 잘 정리해주셔서 제 업무파악에 도움이 되어 너무 좋습니다!
    혹시 기본이 되는 서적 또는 e-book들도 같이 추천해주셨으면 해서...
    번거로우시겠지만 괜찮다면 홈페이지에 오셔서 쪽지 또는 메일, 방명록 등으로 남겨주셔요^^

    • Favicon of http://www.nexpert.net BlogIcon 라인하트 2015.04.10 06:26 신고  댓글주소  수정/삭제

      반갑습니다. 지름길님

      제가 추천할 만한 책이 없네요. 쩝.. 국내에 책이 없다는 뜻이 아니라 제가 아직 많이 읽어보지 못했기 때문입니다.

  21. 일공공사 2016.11.16 18:12 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요! 네트워크 보이스통신분야에 관심이 많아 구글링하다 우연히 들르게 되었습니다~
    초보인 저에게 좋은 글들이 많더라구요~! 종종 공부하러 들어오겠습니다 :) 좋은 하루 되세요!