Rtp 프로토콜 포트. 적합한 솔루션을 찾고 있습니다.... 작업 제어 방법

단지에 대해. 프로그램들. 철. 인터넷. 창

RTP 프로토콜 구성 원리

작업 제어 방법

RTP 프로토콜 헤더 형식

리소스 예약 프로토콜 - RSVP

문학

그리고 뭐가 그렇게 어렵나요?

적합한 솔루션을 찾는 중...

RTP 패킷의 필드로 무엇을 측정할 수 있습니까?

RTP 스트림을 식별하는 방법은 무엇입니까?

다른 트래픽에서 RTP 패킷을 분리하는 방법은 무엇입니까?

계속…

서버의 최종 결과는 무엇입니까?

단점과 장점

요약

1. 전화의 기본 개념

2. SIP/SDP/RTP 프로토콜 번들에 대한 설명

3. 누른 버튼 정보 전달

4. 음성 및 팩스 전송

5. 디지털 신호 처리(DSP). IP 텔레포니의 음질 보장, 테스트 예

집 비교 문맹 퇴치 Rtp 프로토콜 포트. 적합한 솔루션을 찾고 있습니다.... 작업 제어 방법

안녕하세요!

전체: 모니터링 시스템은 트래픽에 존재하는 모든 RTP 비디오 스트림의 전송을 지속적으로 "모니터링"하고 나중에 기지에 저장하기 위해 특정 시간 간격. 데이터베이스의 데이터에 따르면 모든 카메라에 대한 보고서가 정기적으로 작성됩니다.

솔루션을 찾는 과정에서 몇 가지 문제가 즉시 수정되었습니다.

비침입 연결. 모니터링 시스템은 대부분의 연결(RTSP를 통해)이 이미 설정되어 있는 이미 작동 중인 채널에 연결하고 서버와 클라이언트는 교환이 수행되는 포트를 이미 알고 있지만 미리 알지 못합니다. RTSP 프로토콜에 대해서만 잘 알려진 포트가 있지만 UDP 스트림은 임의의 포트를 통과할 수 있습니다. 일부 IP 주소의 이 패킷 또는 해당 패킷이 비디오 스트림에 속하는지 확인하는 방법은 무엇입니까? 예를 들어 BitTorrent 프로토콜은 유사하게 작동합니다. 연결을 설정하는 단계에서 클라이언트와 서버가 포트에 동의하면 모든 UDP 트래픽이 "비트 스트림"처럼 보입니다.
연결된 링크에는 비디오 스트림 이상의 것이 포함될 수 있습니다. HTTP, BitTorrent, SSH 및 오늘날 우리가 사용하는 기타 프로토콜이 있을 수 있습니다. 따라서 시스템은 비디오 스트림을 나머지 트래픽과 분리하기 위해 비디오 스트림을 올바르게 식별해야 합니다. 8개의 10기가비트 링크로 실시간으로 이 작업을 수행하는 방법은 무엇입니까? 물론 일반적으로 100%로 채워지지 않으므로 총 트래픽은 80기가비트/초가 아니라 약 50-60이지만 이것은 그리 적지 않습니다.
확장성. 이미 많은 비디오 스트림이 있는 경우 비디오 감시가 효과적인 도구로 오랫동안 입증되었기 때문에 더 많을 수 있습니다. 이것은 성능을 위한 여유와 링크를 위한 여유가 있어야 함을 시사합니다.

당연히 우리는 우리 자신의 경험을 최대한 활용하려고 노력했습니다. 결정이 내려졌을 때 우리는 이미 FPGA 기반 장치인 Bercut-MX(더 간단하게는 MX)에서 이더넷 패킷 처리를 구현했습니다. Bercut-MX의 도움으로 이더넷 패킷의 헤더에서 분석에 필요한 필드를 얻을 수 있었습니다. 불행히도 우리는 "일반" 서버를 사용하여 그러한 양의 트래픽을 처리한 경험이 없었기 때문에 약간의 우려를 가지고 그러한 솔루션을 살펴보았습니다...

이 방법을 RTP 패킷에 적용하는 일만 남았고 주머니에 황금 열쇠가 있을 것 같지만 MX는 트래픽만 처리할 수 있고 통계를 기록하고 저장할 수 있는 기능은 없습니다. FPGA에 메모리가 부족하여 찾은 연결(IP-IP-포트-포트 조합)을 저장할 수 없습니다. 입력에 들어가는 2x10기가비트 링크에는 약 15,000개의 비디오 스트림이 있을 수 있고 각각에 대해 " "기억" 수신 패킷 수, 손실 패킷 수 등 ... 게다가 무손실 처리에 따라 이러한 속도로 이러한 양의 데이터를 검색하는 것은 사소한 작업이 됩니다.

해결책을 찾기 위해 우리는 "더 깊이 파고들어" 품질을 측정하고 비디오 스트림을 식별하는 데 사용할 알고리즘을 파악해야 했습니다.

설명에서 RTP 패킷의 품질 측정 관점에서 볼 때 다음 필드에 관심이 있음을 알 수 있습니다.

시퀀스 번호 - 전송된 각 패킷과 함께 증가하는 16비트 카운터.
타임스탬프 - 타임스탬프, h.264의 경우 샘플 크기는 1/90000초입니다(즉, 90kHz의 주파수에 해당).
마커 비트 rfc3550에서는 일반적으로 이 비트가 "중요한" 이벤트를 지정하기 위한 것으로 설명되며 실제로 카메라는 이 비트를 사용하여 SPS/PPS 정보로 비디오 프레임 및 특수 패킷의 시작을 가장 자주 표시합니다.

시퀀스 번호를 사용하여 다음 흐름 매개변수를 정의할 수 있다는 것은 분명합니다.

패킷 손실(프레임 손실);
패킷 재전송(중복);
도착 순서 변경(재주문);
시퀀스에 큰 "갭"이 있는 카메라를 다시 로드합니다.

타임스탬프를 사용하면 다음을 측정할 수 있습니다.

지연 변동(지터라고도 함). 이 경우 90kHz 카운터는 수신 측에서 작동해야 합니다.
원칙적으로 패킷 통과의 지연. 그러나 이를 위해서는 카메라 시간을 타임스탬프와 동기화해야 하며, 이는 카메라가 발신자 보고서(RTCP SR)를 전송하는 경우 가능하지만 일반적으로 사실이 아닙니다. 실생활에서 많은 카메라는 RTCP SR 메시지를 무시합니다(작업할 기회가 있었던 카메라의 약 절반).

음, M 비트를 사용하면 프레임 속도를 측정할 수 있습니다. 사실, h.264 프로토콜의 SPS/PPS 프레임에는 오류가 발생합니다. 비디오 프레임이 아닙니다. 그러나 항상 RTP 헤더 다음에 오는 NAL 단위 헤더의 정보를 사용하여 평준화할 수 있습니다.

매개변수 측정을 위한 자세한 알고리즘은 이 기사의 범위를 벗어나므로 자세히 설명하지 않겠습니다. 관심이 있는 경우 rfc3550에 손실 계산 코드의 예와 지터 계산 공식이 있습니다. 주요 결론은 RTP 패킷 및 NAL 단위의 몇 가지 필드만 전송 스트림의 기본 특성을 측정하기에 충분하다는 것입니다. 그리고 나머지 정보는 측정에 포함되지 않으며 폐기될 수 있고 폐기되어야 합니다!

통계를 유지하려면 RTP 헤더에서 얻은 정보를 특정 카메라(비디오 스트림) 식별자에 "첨부"해야 합니다. 카메라는 다음 매개변수로 고유하게 식별할 수 있습니다.

소스 및 대상 IP 주소
소스 및 대상 포트
SSRC. 여러 스트림이 하나의 IP에서 방송될 때 특히 중요합니다. 멀티포트 인코더의 경우.

흥미롭게도 처음에는 SSRC가 임의적이어야 한다는 사실에 따라 소스 IP와 SSRC로만 카메라 식별을 만들었지만 실제로 많은 카메라에서 SSRC를 고정 값(예: 256)으로 설정했습니다. 분명히 이것은 자원을 절약하기 때문입니다. 결과적으로 카메라 ID에 포트를 추가해야 했습니다. 이로써 고유성 문제가 완전히 해결되었습니다.

문제는 남아 있습니다. 패킷을 수락한 Berkut-MX가 RTP임을 어떻게 이해할까요? RTP 헤더에는 IP와 같은 명시적 식별이 없고 체크섬이 없으며 연결이 설정될 때 동적으로 선택된 포트 번호로 UDP를 통해 전송될 수 있습니다. 그리고 우리의 경우 대부분의 연결이 오랫동안 설정되었으며 재설치를 위해 매우 오랜 시간을 기다릴 수 있습니다.

이 문제를 해결하려면 rfc3550(부록 A.1)에서 RTP 버전 비트(이는 2비트, PT(페이로드 유형) 필드는 7비트로, 동적 유형의 경우 작은 범위. 우리는 실제로 우리가 작업하는 카메라 세트의 PT가 96에서 100 사이에 맞는다는 것을 알아냈습니다.

포트의 패리티가 하나 더 있지만 실습에서 알 수 있듯이 항상 관찰되는 것은 아니므로 포기해야 했습니다.

따라서 Berkut-MX의 동작은 다음과 같습니다.

우리는 패키지를 받아 필드로 분해합니다.
버전이 2이고 페이로드 유형이 지정된 제한 내에 있으면 헤더를 서버로 보냅니다.

분명히, 이 접근 방식에는 오탐지가 있습니다. RTP 패킷뿐만 아니라 이러한 간단한 기준에 속할 수 있습니다. 그러나 RTP 패킷을 절대 놓치지 않고 서버가 "잘못된" 패킷을 걸러내는 것이 중요합니다.

잘못된 경우를 필터링하기 위해 서버는 순차적으로 수신된 여러 패킷에 대한 비디오 트래픽 소스를 등록하는 메커니즘을 사용합니다(패킷에 시퀀스 번호가 있습니다!). 여러 패킷이 연속 번호와 함께 제공된 경우 이는 우연이 아니며 이 스트림으로 작업을 시작합니다. 이 알고리즘은 매우 신뢰할 수 있는 것으로 판명되었습니다.

패킷으로 들어오는 모든 정보가 품질을 측정하고 스트림을 식별하는 데 필요하지 않다는 것을 깨닫고 RTP 패킷 필드를 수신하고 격리하는 모든 고부하 및 시간 결정적인 작업을 Berkut-MX로 전환하기로 결정했습니다. FPGA. 비디오 스트림을 "찾고" 패킷을 구문 분석하고 필요한 필드만 남겨두고 UDP 터널의 일반 서버로 보냅니다. 서버는 각 카메라에 대한 측정을 수행하고 결과를 데이터베이스에 저장합니다.

결과적으로 서버는 50-60 Gigabit / s로 작동하지 않지만 최대 5 %로 작동합니다 (이것은 정확히 평균 패킷 크기로 전송되는 데이터 비율입니다). 즉, 전체 시스템의 입력에서 55 Gigabit / s 및 3 Gigabit / s 이하만 서버에 도달합니다!

그 결과 다음과 같은 아키텍처를 얻었습니다.

그리고 우리는 초기 TOR를 설정하고 2주 후에 이 구성에서 첫 번째 결과를 얻었습니다!

그렇다면 서버는 아키텍처에서 무엇을 합니까? 그의 임무:

UDP 소켓에서 수신 대기하고 패킷 헤더가 있는 필드를 읽습니다.
들어오는 패킷을 구문 분석하고 거기에서 카메라 식별자와 함께 RTP 헤더 필드를 추출합니다.
수신된 필드를 이전에 수신된 필드와 연관시키고 패킷이 손실되었는지 여부, 패킷이 반복적으로 전송되었는지 여부, 도착 순서가 변경되었는지 여부, 패킷 전송 지연(지터)의 변동이 무엇인지 등을 이해합니다.
시간을 기준으로 측정된 데이터를 데이터베이스에 기록합니다.
기지를 분석하고 보고서를 생성하고 중요한 이벤트(높은 패킷 손실, 일부 카메라의 패킷 손실 등)에 대한 트랩을 보냅니다.

서버 입력의 총 트래픽이 약 3Gigabit/s 정도인데도 DPDK를 사용하지 않아도 서버는 대응하고, 단순히 리눅스 소켓을 통해 작업한다(물론 소켓의 버퍼 크기를 늘린 후) . 또한 성능 마진이 남아 있기 때문에 새로운 링크와 MX "를 연결할 수 있습니다.

이것은 서버 상단의 모습입니다(이것은 오직 하나의 lxc 컨테이너의 상단이며 보고서는 다른 컨테이너에서 생성됩니다):

이를 통해 품질 매개변수를 계산하고 통계를 설명하기 위한 전체 부하가 4가지 프로세스에 고르게 분포되어 있음을 알 수 있습니다. 우리는 FPGA에서 해싱을 사용하여 이러한 분포를 달성했습니다. 해시 기능은 IP로 계산되고 수신된 해시의 하위 비트는 통계가 전달될 UDP 포트의 번호를 결정합니다. 따라서 해당 포트에서 수신 대기하는 각 프로세스는 거의 동일한 양의 트래픽을 수신합니다.

이제 솔루션의 단점을 자랑하고 인정할 때입니다.

전문가부터 시작하겠습니다.

10G 링크와의 교차점에서 손실이 없습니다. FPGA가 모든 "공격"을 취하기 때문에 모든 패킷이 분석될 것이라고 확신할 수 있습니다.
55,000개 이상의 카메라를 모니터링하려면 하나의 10G 카드가 있는 하나의 서버만 필요합니다. 우리는 현재 각각 2400MHz의 코어 4개가 있는 2x Xeon 기반 서버를 사용하고 있습니다. 여유가 있으면 충분합니다. 정보 수집과 동시에 보고서가 생성됩니다.
8개의 "다스"(10G 링크) 모니터링은 2-3개의 장치에만 적합합니다. 모니터링 시스템을 위한 랙에 항상 많은 공간과 전력이 있는 것은 아닙니다.
스위치를 통해 MX에서 링크를 연결할 때 모니터링을 중지하지 않고 새 링크를 추가할 수 있습니다. 서버에 보드를 삽입할 필요가 없으며 이를 위해 끌 필요도 없습니다.
서버는 데이터로 과부하되지 않고 필요한 것만 수신합니다.
MX의 헤더는 점보 이더넷 패킷으로 들어옵니다. 즉, 프로세서가 인터럽트로 인해 질식되지 않습니다(게다가 인터럽트 병합을 잊지 않습니다).

공정하게, 나는 단점을 고려할 것입니다.

특정 작업에 대한 과도한 최적화로 인해 새로운 필드 또는 프로토콜에 대한 지원을 추가하려면 FPGA 코드를 변경해야 합니다. 이는 프로세서에서 동일한 작업을 수행하는 경우보다 더 많은 시간이 소요됩니다. 개발 및 테스트 및 배포 중
영상정보는 전혀 분석하지 않습니다. 카메라는 카메라 앞에 매달려 있는 고드름을 쏘거나 잘못된 방향으로 돌릴 수 있습니다. 이 사실은 눈에 띄지 않을 것입니다. 물론 선택한 카메라에서 비디오를 녹화할 수 있는 기능을 제공했지만 운영자가 55,000개의 카메라를 모두 통과할 수는 없습니다!
서버 및 FPGA 구동 장치는 한두 대의 서버보다 더 비쌉니다.)

결국 인터페이스에서 패킷을 구문 분석하는 부분과 통계를 유지하는 부분을 모두 제어할 수 있는 소프트웨어 및 하드웨어 콤플렉스가 생겼습니다. 카메라가 RTSP/TCP 인터리브 모드로 전환하기 시작했을 때 시스템의 모든 노드에 대한 완전한 제어는 말 그대로 우리를 구했습니다. 이 경우 RTP 헤더는 더 이상 고정된 오프셋으로 패킷에 위치하지 않기 때문에 두 패킷의 경계(첫 번째 절반은 다른 패킷에, 두 번째 패킷에는 두 번째 패킷)의 경계에도 위치할 수 있습니다. 이에 따라 RTP 헤더 및 해당 필드를 획득하는 알고리즘이 근본적으로 변경되었습니다. 우리는 50,000개의 모든 연결에 대해 서버에서 TCP 재조립을 수행해야 했습니다. 따라서 상단의 부하가 다소 높습니다.

우리는 이전에 고부하 애플리케이션 분야에서 일한 적이 없지만 FPGA에 대한 우리의 기술 덕분에 문제를 해결할 수 있었고 꽤 잘 되었습니다. 예를 들어, 55,000개의 카메라가 있는 시스템에 또 다른 20-30,000개의 스트림을 연결할 수 있습니다.

Linux 하위 시스템 조정(인터럽트에 의한 대기열 분배, 수신 버퍼 증가, 특정 프로세스에 코어 직접 할당 등)은 기사 범위를 벗어났기 때문입니다. 이 주제는 이미 잘 다루어졌습니다.

모든 것에서 멀리 떨어져 설명했지만 많은 갈퀴가 수집되었으므로 자유롭게 질문하십시오 :)

끝까지 읽어주신 모든 분들께 진심으로 감사드립니다!

인터넷의 급속한 성장은 데이터 전송의 속도와 양에 대한 새로운 요구를 제기합니다. 그리고 이러한 모든 요구를 만족시키기 위해서는 네트워크의 용량을 늘리는 것만으로는 충분하지 않으며 합리적이고 효과적인 트래픽 관리 방법과 전송선로의 혼잡이 필요합니다.

실시간 애플리케이션에서 발신자는 일정한 속도로 데이터 스트림을 생성하고 수신자(또는 수신자)는 이 데이터를 동일한 속도로 애플리케이션에 제공해야 합니다. 이러한 응용 프로그램에는 예를 들어 오디오 및 비디오 회의, 라이브 비디오, 의료 원격 진단, 컴퓨터 전화 통신, 분산 대화형 시뮬레이션, 게임, 실시간 모니터링 등이 포함됩니다.

가장 널리 사용되는 전송 계층 프로토콜은 TCP입니다. TCP는 다양한 분산 응용 프로그램을 지원할 수 있지만 실시간 응용 프로그램에는 적합하지 않습니다.

이 작업은 새로운 실시간 전송 프로토콜로 해결하기 위한 것입니다. RTP(Real-Time Transport Protocol): 지정된 제한 내에서 지연으로 하나 이상의 대상으로 데이터 전달을 보장합니다. 즉, 데이터를 실시간으로 재생할 수 있습니다.

RTP는 패킷 전달, 전송 유효성 또는 연결 안정성에 대한 메커니즘을 지원하지 않습니다. 이러한 모든 기능은 전송 프로토콜에 할당됩니다. RTP는 UDP 위에서 실행되며 RTP 세션에서 여러 참가자 간의 실시간 데이터 전송을 지원할 수 있습니다.

메모

각 RTP 참가자에 대해 세션은 패킷 대상 전송 주소 쌍(하나의 네트워크 주소 - IP 및 포트 쌍: RTP 및 RTCP)으로 정의됩니다.

RTP 패킷에는 데이터를 생성하는 당사자를 나타내는 발신자 ID, 수신 당사자가 정확한 간격으로 데이터를 재생할 수 있도록 패킷 생성 타임스탬프, 전송 순서 정보, 비디오 인코딩 유형(MPEG, Indeo 등)과 같은 패킷의 내용. 이러한 정보의 가용성은 초기 지연 값과 전송 버퍼의 크기를 추정하는 것을 가능하게 합니다.

메모

일반적인 실시간 환경에서 발신자는 일정한 속도로 패킷을 생성합니다. 그것들은 일정한 간격으로 전송되고 네트워크를 통해 이동하며 수신측에서 수신되며 수신측은 수신되는 데이터를 실시간으로 재생합니다. 그러나 패킷이 네트워크를 통해 전송될 때 지연 시간의 변화로 인해 불규칙한 간격으로 도착할 수 있습니다. 이 효과를 보상하기 위해 들어오는 패킷은 버퍼링되고 잠시 동안 유지된 다음 일정한 속도로 제공됩니다. 소프트웨어출력을 생성합니다. 따라서 실시간 프로토콜이 작동하려면 각 패킷에 타임스탬프가 포함되어 있어야 합니다. 그래야 받는 사람이 보낸 사람과 같은 속도로 들어오는 데이터를 재생할 수 있습니다.

RTP는 전송된 데이터의 페이로드 형식을 정의(및 규제)하기 때문에 동기화 개념은 이에 직접적으로 관련되어 있으며, 이는 부분적으로 RTP 변환 메커니즘인 믹서의 책임입니다. 하나 이상의 소스에서 RTP 패킷 스트림을 수신하면 믹서는 이들을 결합하고 RTP 패킷의 새 스트림을 하나 이상의 수신자에게 보냅니다. 믹서는 예를 들어 여러 음원을 결합할 때 데이터를 결합하고 형식을 변경할 수 있습니다. 그런 척 하자 새로운 시스템세션에 참여하기를 원하지만 네트워크에 대한 링크에 모든 RTP 스트림을 지원할 수 있는 용량이 충분하지 않은 경우 믹서는 이러한 모든 스트림을 수신하여 하나로 병합하고 마지막 스트림을 새 세션 구성원에게 전달합니다. 여러 스트림을 수신할 때 믹서는 단순히 PCM 값을 추가합니다. 믹서에 의해 생성된 RTP 헤더에는 패킷에 데이터가 있는 발신자의 ID가 포함됩니다.

더 간단한 중계 장치는 들어오는 RTP 패킷마다 하나의 나가는 RTP 패킷을 만듭니다. 이 메커니즘은 패킷의 데이터 형식을 변경하거나 다른 저수준 프로토콜 집합을 사용하여 한 도메인에서 다른 도메인으로 데이터를 전송할 수 있습니다. 예를 들어, 잠재적 수신자는 세션의 다른 참가자가 사용하는 고속 비디오 신호를 처리하지 못할 수 있습니다. 번역기는 비디오를 다른 고속데이터 전송.

RTP 프로토콜은 사용자 데이터(일반적으로 멀티캐스트)를 세션의 모든 참가자에게 전송하는 데만 사용됩니다. RTP와 함께 RTCP(실시간 전송 제어 프로토콜) 프로토콜이 작동하며, 그 주요 작업은 RTP 전송에 대한 제어를 제공하는 것입니다. RTCP는 RTP(보통 UDP)와 동일한 기본 전송 프로토콜을 사용하지만 다른 포트 번호를 사용합니다.

RTCP는 다음과 같은 여러 기능을 수행합니다.

혼잡 시 서비스 품질 및 피드백을 보장하고 모니터링합니다. RTCP 패킷은 멀티캐스트이므로 세션의 모든 참가자는 다른 참가자가 얼마나 잘 수행하고 수신하는지 평가할 수 있습니다. 보낸 사람의 메시지를 통해 받는 사람은 데이터 속도와 전송 품질을 평가할 수 있습니다. 수신자의 메시지에는 패킷 손실 및 과도한 리플을 포함하여 그들이 겪고 있는 문제에 대한 정보가 포함되어 있습니다. 수신자 피드백도 전파 오류를 진단하는 데 중요합니다. 모든 세션 참가자의 메시지를 분석하여 네트워크 관리자는 문제가 한 참가자에 관한 것인지 아니면 일반적인 성격의 문제인지 결정할 수 있습니다. 예를 들어 통신 채널 중 하나의 오류로 인해 문제가 시스템 전체에 일반적이라는 결론을 보내는 응용 프로그램은 품질 저하 또는 비디오 전송을 완전히 거부하십시오. 이렇게하면 연결 저용량을 통해 데이터를 전송할 수 있습니다.
발신자 식별. RTCP 패킷에는 발신자에 대한 표준 텍스트 설명이 포함되어 있습니다. 무작위로 선택한 동기화 소스 ID보다 데이터 패킷의 발신자에 대한 더 많은 정보를 제공합니다. 또한 사용자가 다른 세션과 관련된 스레드를 식별하는 데 도움이 됩니다.
세션 크기 조정 및 확장. 서비스 품질과 피드백혼잡 제어 목적과 발신자 식별 목적으로 모든 참가자는 주기적으로 RTCP 패킷을 보냅니다. 이러한 패킷의 전송 빈도는 참가자 수가 증가함에 따라 감소합니다. 참가자 수가 적은 경우 최대 5초마다 하나의 RTCP 패킷이 전송됩니다. RFC-1889는 참가자가 총 참가자 수를 기반으로 RTCP 패킷의 속도를 제한하는 알고리즘을 설명합니다. 목표는 RTCP 트래픽을 총 세션 트래픽의 5% 미만으로 유지하는 것입니다.

RTP는 스트림 지향 프로토콜입니다. RTP 패킷의 헤더는 실시간 전송을 염두에 두고 설계되었습니다. 데이터 스트림이 수신 측에서 올바르게 조합되도록 패킷 순서에 대한 정보와 재생 중 올바른 프레임 인터리빙을 위한 타임스탬프와 비디오 및 오디오와 같은 여러 데이터 스트림을 동기화하기 위한 타임스탬프가 포함되어 있습니다.

각 RTP 패킷에는 기본 헤더와 추가 응용 프로그램별 필드가 있을 수 있습니다.

이러한 응용 프로그램의 전송 프로토콜로 TCP를 사용하는 것은 다음과 같은 몇 가지 이유로 불가능합니다.

이 프로토콜은 두 끝점 간의 연결만 허용하므로 멀티캐스팅에는 적합하지 않습니다.
TCP는 실시간 애플리케이션이 더 이상 기다리지 않을 때 도착하는 손실된 세그먼트의 재전송을 제공합니다.
TCP에는 실시간 응용 프로그램에 대한 추가 요구 사항인 세그먼트와 타이밍 정보를 연결하는 편리한 메커니즘이 없습니다.

널리 사용되는 또 다른 전송 계층 프로토콜인 LJDP는 TCP의 일부 제한 사항이 없지만 제공하지 않습니다. 중요한 정보동기화에 대해.

각 실시간 응용 프로그램에는 실시간 전송을 지원하는 자체 메커니즘이 있을 수 있지만 단일 프로토콜을 정의하는 것이 매우 바람직한 많은 공통 기능을 공유합니다.

새로운 실시간 전송 프로토콜인 RTP(Real-time Transport Protocol)는 이 문제를 해결하기 위해 설계되었으며, 지정된 제한 내에서 지연으로 한 명 이상의 수신자에게 데이터 전달을 보장합니다. 즉, 데이터를 실시간으로 재생할 수 있습니다. .

무화과에. 1 제시 고정 RTP 헤더, 패키지 형식과 같은 항목을 식별하는 여러 필드가 포함되어 있습니다. 일련 번호, 소스, 경계 및 페이로드 유형. 고정 헤더 다음에 데이터에 대한 추가 정보를 포함하는 다른 필드가 올 수 있습니다.

쌀. 1. RTP 헤더를 수정했습니다.

V(2비트). 버전 필드. 현재 버전은 두 번째 버전입니다.
아르 자형(1비트). 필드를 채웁니다. 이 필드는 페이로드 끝에 패딩 옥텟이 있음을 나타냅니다. 패딩은 애플리케이션에서 페이로드 크기가 예를 들어 32비트의 배수여야 할 때 적용됩니다. 이 경우 마지막 옥텟은 패딩 옥텟의 수를 나타냅니다.
엑스(1비트). 헤더 확장 필드. 이 필드가 설정되면 기본 헤더 다음에 실험적 RTP 확장에 사용되는 추가 헤더가 옵니다.
봄 여름 시즌(4비트). 보낸 사람 수 필드입니다. 이 필드에는 패킷에 데이터가 있는 발신자의 ID 수가 포함되며 ID 자체는 기본 헤더 다음에 있습니다.
중(1비트). 마커 필드. 마커 비트의 의미는 페이로드 유형에 따라 다릅니다. 마커 비트는 일반적으로 데이터 스트림의 경계를 나타내는 데 사용됩니다. 동영상의 경우 프레임의 끝을 설정합니다. 음성의 경우 일정 시간 침묵 후 말의 시작을 지정합니다.
RT(7비트). 페이로드 유형 필드. 이 필드는 압축 및 암호화를 포함하여 페이로드 유형 및 데이터 형식을 식별합니다. 정지 상태에서 발신자는 세션당 하나의 페이로드 유형만 사용하지만 실시간 전송 제어 프로토콜(Real-Time Transport Control Protocol)에 의해 신호를 받으면 변화하는 조건에 응답하여 변경할 수 있습니다.
시퀀스 번호(16비트). 시퀀스 번호 필드. 각 소스는 임의의 번호에서 패킷 번호를 매기기 시작한 다음 RTP 데이터 패킷이 전송될 때마다 하나씩 증가합니다. 이를 통해 패킷 손실을 감지하고 동일한 타임스탬프를 가진 패킷의 순서를 결정할 수 있습니다. 동일한 비디오 프레임에 속하는 패킷과 같이 논리적으로 동시에 생성된 경우 여러 개의 연속 패킷이 동일한 타임스탬프를 가질 수 있습니다.
타임스탬프(32비트). 타임스탬프 필드. 이 필드는 첫 번째 페이로드 데이터 옥텟이 생성된 시점을 포함합니다. 이 필드에 시간이 지정되는 단위는 페이로드 유형에 따라 다릅니다. 값은 보낸 사람의 로컬 시계에 의해 결정됩니다.
동기화 소스 (SSRC) 식별자(32비트). 동기화 소스 ID 필드: 세션 내에서 소스를 고유하게 식별하고 네트워크 주소와 독립적인 임의로 생성된 번호입니다. 이 번호는 한 소스에서 들어오는 데이터 부분을 처리하는 데 중요한 역할을 합니다.
기여 출처(CSRC) 식별자(32비트). 예를 들어 믹서를 사용하여 메인 스트림에 "혼합된" 소스 식별자 필드 목록입니다. 믹서는 이 RTP 패킷 구성에 참여한 소스의 SSRC 식별자 전체 목록을 삽입합니다. 이 목록을 CSRC라고 합니다. 목록의 요소 수: 0 ~ 15 참가자 수가 15명을 초과하면 처음 15명이 선택됩니다. 예를 들어 RTP 패킷에서 모든 참가자의 연설이 수집되고 각각의 내용이 포함된 오디오 회의가 있습니다. 자체 SSRC - CSRC 목록을 구성합니다. 이 경우 전체 회의에 공통 SSRC가 있습니다.

RTCP 프로토콜은 모든 제어 프로토콜과 마찬가지로 구조 및 수행하는 기능(예: IP 및 TCP 프로토콜 비교) 면에서 훨씬 더 복잡합니다. RTCP 프로토콜의 핵심은 RTP이지만 기능을 구현하는 데 사용되는 추가 필드가 많이 포함되어 있습니다.

지연이 그다지 중요하지 않은 기존 데이터와 달리 지연에 민감한 데이터의 우선 순위 문제를 해결하기 위해 현재 IETF(Internet Engineering Task Force)에서 고려 중인 리소스 예약 프로토콜인 RSVP가 필요합니다. RSVP 허용 엔드 시스템필요한 서비스 품질, 특히 RTP 프로토콜을 사용하는 실시간 그래픽을 위한 리소스를 얻기 위해 네트워크 리소스를 예약합니다. RSVP는 주로 라우터와 관련이 있지만 종단 노드 응용 프로그램은 주어진 서비스 클래스 또는 우선 순위 수준에 필요한 대역폭을 예약하기 위해 RSVP를 사용하는 방법도 알아야 합니다.

설명된 다른 표준과 함께 RTP를 사용하면 기존 IP 네트워크를 통해 비디오 및 오디오를 성공적으로 전송할 수 있습니다. RTP/RTCP/RSVP는 실시간 데이터 네트워크를 위한 표준화된 솔루션입니다. 유일한 단점은 IP 네트워크에만 해당된다는 것입니다. 그러나 이 제한은 일시적입니다. 네트워크는 어떤 식으로든 이 방향으로 발전할 것입니다. 이 솔루션은 인터넷을 통해 지연에 민감한 데이터를 전송하는 문제를 해결할 것을 약속합니다.

RTP 프로토콜에 대한 설명은 RFC-1889에서 찾을 수 있습니다.

TCP/IP 프로토콜 스택을 기반으로 하는 서비스 품질에 대한 요구 사항이 서로 다른 여러 유형의 트래픽을 지원해야 하는 요구 사항은 이제 매우 적절합니다. 이 문제는 서비스 품질을 보장하지 않는 네트워크를 통한 음성 또는 비디오와 같은 데이터의 실시간 전송을 위한 IETF 표준인 RTP(실시간 전송 프로토콜)에 의해 해결됩니다.

RTP 프로토콜은 지정된 값을 초과하지 않는 지연으로 한 명 이상의 수신자에게 데이터 전달을 보장합니다. 이를 위해 프로토콜 헤더는 오디오 및 비디오 정보의 성공적인 복원에 필요한 타임스탬프와 정보 인코딩 방법에 대한 데이터를 제공합니다.

TCP 프로토콜은 전송된 데이터가 올바른 순서로 전달되도록 보장하지만 트래픽이 고르지 않습니다. 즉, 데이터그램을 전달하는 동안 예측할 수 없는 지연이 발생합니다. RTP 프로토콜은 데이터그램의 내용을 인식하고 데이터 손실 감지 메커니즘을 가지고 있기 때문에 대기 시간을 허용 가능한 수준으로 줄일 수 있습니다.

IP 프로토콜 주소 체계

IP 프로토콜에 사용되는 인터네트워크 주소 지정 체계는 RFC 990 및 RFC 997에 설명되어 있습니다. 이는 이러한 네트워크의 주소 지정 장치와 주소 지정 네트워크의 분리를 기반으로 합니다. 이 체계는 라우팅을 용이하게 합니다. 이 경우 보다 효율적인 라우팅을 위해 주소를 순서대로(연속적으로) 할당해야 합니다.

네트워크에서 TCP/IP 프로토콜 스택을 사용할 때 최종 장치는 고유한 주소를 받습니다. 이러한 장치는 개인용 컴퓨터, 미디어 서버, 라우터 등. 그러나 라우터와 같이 여러 물리적 포트가 있는 일부 장치는 각 포트에 고유한 주소가 있어야 합니다. 주소 지정 체계와 네트워크의 일부 장치에 여러 주소가 있을 수 있다는 사실을 기반으로 이 주소 지정 체계는 네트워크의 장치 자체를 설명하는 것이 아니라 네트워크에 대한 이 장치의 특정 연결을 설명한다는 결론을 내릴 수 있습니다. 이 계획은 여러 가지 불편을 초래합니다. 그 중 하나는 장치를 다른 네트워크로 이동할 때 장치의 주소를 변경해야 한다는 것입니다. 또 다른 단점은 분산 네트워크에서 여러 연결이 있는 장치로 작업하려면 이러한 연결을 식별하는 모든 주소를 알아야 한다는 것입니다.

따라서 IP 네트워크의 각 장치에 대해 세 가지 수준의 주소에 대해 이야기할 수 있습니다.

큐 실제 주소장치(보다 정확하게는 특정 인터페이스). 이더넷 네트워크에 있는 장치의 경우 MAC 주소입니다. 네트워크 카드또는 라우터 포트. 이러한 주소는 하드웨어 제조업체에서 할당합니다. 물리적 주소는 6바이트입니다. 상위 3바이트는 제조업체의 식별자이고 하위 3바이트는 제조업체에서 할당합니다.

● 4바이트로 구성된 IP 주소. 이 주소는 다음 용도로 사용됩니다. 네트워크 계층 OSI 참조 모델;

q 문자 식별자 - 이름. 이 식별자는 관리자가 임의로 지정할 수 있습니다.

1981년 9월에 IP 프로토콜이 표준화되었을 때 그 사양은 네트워크에 연결된 모든 장치가 고유한 32비트 주소를 가질 것을 요구했습니다. 이 주소는 두 부분으로 나뉩니다. 주소의 첫 번째 부분은 장치가 있는 네트워크를 식별합니다. 두 번째 부분은 네트워크 내에서 장치 자체를 고유하게 식별합니다. 이 체계는 2단계 주소 계층 구조로 이어집니다(그림 6.23).

이제 주소의 네트워크 번호 필드가 호출됩니다. 네트워크 접두사,네트워크를 식별하기 때문입니다. 네트워크의 모든 워크스테이션은 동일한 네트워크 접두사를 공유합니다. 동시에, 그들은 가지고 있어야합니다 고유 번호장치. 서로 다른 네트워크에 있는 두 워크스테이션은 서로 다른 네트워크 접두사를 가져야 하지만 동일한 장치 번호를 가질 수도 있습니다.

주소 지정의 유연성을 위해 컴퓨터 네트워크프로토콜 설계자는 IP 주소 공간을 A, B, C의 세 가지 클래스로 나누어야 한다고 결정했습니다. 클래스를 알면 32비트 주소에서 네트워크 접두사와 장치 번호 사이의 경계가 어디에 있는지 알 수 있습니다. . 무화과에. 그림 6.24는 이러한 기본 클래스의 주소 형식을 보여줍니다.

클래스 사용의 주요 이점 중 하나는 네트워크 접두사와 장치 번호 사이의 경계가 있는 주소의 클래스를 확인할 수 있다는 것입니다. 예를 들어, 주소의 최상위 두 비트가 10이면 분할 지점은 비트 15와 16 사이입니다.

이 방법의 단점은 연결할 때 네트워크 주소를 변경해야 한다는 것입니다. 추가 장치. 예를 들어 총 수클래스 C 네트워크의 장치 수가 255를 초과하면 해당 주소를 클래스 B 주소로 교체해야 합니다. 네트워크 주소를 변경하려면 네트워크를 디버그하기 위해 관리자의 추가 노력이 필요합니다. 네트워크 관리자는 부드러운 전환클래스가 명확하게 분리되어 있기 때문에 새 주소 클래스로 이동합니다. 전체 네트워크 주소 그룹의 사용을 금지하고 이 그룹에 있는 장치의 모든 주소를 동시에 변경한 다음 네트워크에서 다시 사용을 허용해야 합니다. 또한 주소 클래스의 도입은 이론적으로 가능한 개별 주소의 수를 크게 줄입니다. 에 현재 버전 IP 프로토콜(버전 4)의 총 주소 수는 2 32(4 294 967 296)일 수 있습니다. 프로토콜은 주소를 지정하기 위해 32비트를 사용하기 때문입니다. 당연히 서비스 목적으로 일부 비트를 사용하면 사용 가능한 개별 주소 수가 줄어듭니다.

클래스 A는 대규모 네트워크용입니다. 각 클래스 A 주소에는 8비트 네트워크 접두사가 있으며 최상위 비트는 1로 설정되고 다음 7비트는 네트워크 번호에 사용됩니다. 나머지 24비트는 장치 번호에 사용됩니다. 에 이 순간모든 클래스 A 주소가 이미 할당되었습니다. 클래스 A 주소에는 8비트 네트워크 접두사가 있기 때문에 클래스 A 네트워크는 "/8"이라고도 합니다.

클래스 A 네트워크의 최대 수는 126개입니다(2 7 -2 - 0과 1로만 구성된 두 개의 주소를 뺍니다). 이 클래스의 각 네트워크는 최대 16,777,214(2 24 -2)개의 장치를 지원합니다. 클래스 A 주소 블록은 최대 231(2 147483648)개의 개별 주소를 보유할 수 있고 IP 버전 4는 최대 232(4294967296) 주소만 지원할 수 있으므로 클래스 A는 전체 IP 주소 공간의 50%를 차지합니다.

클래스 B는 중간 규모 네트워크용입니다. 각 클래스 B 주소에는 16비트 네트워크 접두사가 있습니다. 여기서 2개의 최상위 비트는 10이고 다음 14비트는 네트워크 번호로 사용됩니다. 디바이스 번호에는 16비트가 할당됩니다. 클래스 B 주소에는 16비트 네트워크 접두사가 있기 때문에 클래스 B 네트워크는 "/16"이라고도 합니다.

클래스 B 네트워크의 최대 수는 16,382(2 14 -2)입니다. 이 클래스의 각 네트워크는 최대 65,534(2 16 -2) 장치를 지원합니다. 전체 클래스 B 주소 블록은 최대 230(1,073,741,824)개의 개별 주소를 포함할 수 있으므로 전체 IP 주소 공간의 25%를 차지합니다.

클래스 C 주소는 장치 수가 적은 네트워크에서 사용됩니다. 각 클래스 C 네트워크에는 24비트 네트워크 접두사가 있으며 여기서 3개의 최상위 비트는 110이고 다음 21비트는 네트워크 번호에 사용됩니다. 나머지 8비트는 장치 번호에 할당됩니다. 클래스 C 주소에는 24비트 네트워크 접두사가 있기 때문에 클래스 C 네트워크는 "/24"라고도 합니다.

클래스 C 네트워크의 최대 수는 2,097,152(221)입니다. 이 클래스의 각 네트워크는 최대 254개(2 8 -2)개의 장치를 지원합니다. 클래스 C는 전체 IP 주소 공간의 12.5%를 차지합니다.

테이블에서. 6.9는 네트워크 클래스에 대한 분석을 요약합니다.

표 6.9. 네트워크 클래스

이 세 가지 클래스의 주소 외에도 두 가지 클래스가 더 있습니다. 클래스 D에서 최상위 4비트는 1110입니다. 이 클래스는 멀티캐스팅에 사용됩니다. 클래스 E에서 상위 4비트는 1111입니다. 실험용으로 예약되어 있습니다.

기술 문헌, 응용 프로그램 등의 주소를 읽기 쉽도록 IP 주소는 4개로 표시됩니다. 십진수점으로 구분됩니다. 이 숫자 각각은 IP 주소의 한 옥텟(8비트)에 해당합니다. 이 형식을 점분리 십진법(Decimal-Point Notation) 또는 점분리 십진법(그림 6.25)이라고 합니다.

테이블에서. 6.10은 세 가지 주소 클래스에 대한 10진수 값의 범위를 나열합니다. 테이블에서. 6.10 XXX 항목은 임의의 필드를 의미합니다.

표 6.10. 주소 값 범위

일부 IP 주소는 네트워크의 장치에 할당할 수 없습니다(표 6.11).

이 표에서 볼 수 있듯이 예약된 IP 주소에서 0으로 설정된 모든 비트는 다음 중 하나에 해당합니다. 이 기기, 또는 이 네트워크와 모든 비트가 1로 설정된 IP 주소는 정보를 브로드캐스트하는 데 사용됩니다. 전체 IP 네트워크를 전체적으로 참조하기 위해 모든 비트가 "0"으로 설정된 장치 번호가 있는 주소가 사용됩니다. 클래스 A 네트워크 주소 127.0.0.0은 루프백용으로 예약되어 있으며 동일한 시스템의 프로세스 간 통신을 테스트하기 위해 도입되었습니다. 응용 프로그램이 루프백 주소를 사용할 때 TCP/IP 프로토콜 스택은 네트워크에 아무 것도 보내지 않고 이 데이터를 응용 프로그램에 반환합니다. 또한 이 주소는 동일한 시스템 내에서 개별 프로세스의 상호 작용에 사용할 수 있습니다. 따라서 IP 네트워크에서 127로 시작하는 IP 주소를 장치에 할당하는 것은 금지되어 있습니다.

특정 워크스테이션으로 직접 데이터를 전송하는 것 외에도 현재 또는 지정된 네트워크의 모든 스테이션이 정보를 수신하는 브로드캐스트 전송이 활발히 사용됩니다. IP 프로토콜에는 두 가지 유형의 브로드캐스트가 있습니다.

방향 지정 브로드캐스트를 사용하면 원격 네트워크의 장치가 동일한 네트워크의 모든 장치에 데이터그램을 보낼 수 있습니다. 현재 네트워크. 전달된 브로드캐스트 주소가 있는 데이터그램은 라우터를 통과할 수 있지만 모든 장치가 아니라 지정된 네트워크의 모든 장치에만 전달됩니다. 직접 브로드캐스트에서 대상 주소는 특정 네트워크 번호와 장치 번호로 구성되며 모든 비트는 0 또는 1입니다. 예를 들어 주소 185.100.255.255 및 185.100.0.0은 클래스 B에 대한 직접 브로드캐스트 주소로 처리됩니다. 네트워크 185.100.xxx.xxx 주소 지정 관점에서 지향성 브로드캐스트의 주요 단점은 대상 네트워크 번호를 알아야 한다는 것입니다.

제한된 브로드캐스트라고 하는 두 번째 브로드캐스트 형식은 현재 네트워크(전송 장치가 있는 네트워크) 내에서 브로드캐스트합니다. 제한된 브로드캐스트 주소를 가진 데이터그램은 라우터를 통과하지 않습니다. 제한된 브로드캐스트에서 네트워크 번호와 장치 번호 비트는 모두 0 또는 1입니다. 따라서 대상 주소가 255.255.255.255 또는 0.0.0.0인 데이터그램은 네트워크의 모든 장치에 전달됩니다. 무화과에. 그림 6.26은 라우터로 연결된 네트워크를 보여줍니다. 테이블에서. 그림 6.12는 워크스테이션 A에서 보낸 브로드캐스트 데이터그램의 수신자를 나열합니다.

IP 프로토콜은 단일(유니캐스트), 브로드캐스트(브로드캐스트) 및 그룹(멀티캐스트)의 세 가지 주소 지정 방법을 지원합니다.

표 6.12. 브로드캐스트 데이터그램 수신기

단일 주소 지정에서 데이터그램은 특정 단일 장치로 전송됩니다. 이 접근 방식의 구현은 어렵지 않지만, 작업 그룹여러 스테이션을 포함하는 경우 동일한 데이터그램이 여러 번 전송되므로 처리량이 충분하지 않을 수 있습니다.

브로드캐스트 주소 지정을 사용하면 응용 프로그램에서 단일 데이터그램을 보내 네트워크의 모든 장치에 전달합니다. 이 접근 방식은 구현하기가 훨씬 더 간단하지만 이 경우 브로드캐스트 트래픽이 지역 네트워크(예를 들어 다른 네트워크가 라우터를 사용하여 전달되는 경우) 글로벌 네트워크에는 상당한 대역폭이 있어야 합니다. 정보가 소규모 장치 그룹에만 적용되는 것이라면 이 접근 방식은 비합리적으로 보입니다.

멀티캐스트에서 데이터그램은 특정 장치 그룹에 전달됩니다. 동시에(분산 네트워크에서 작업할 때 매우 중요함) 초과 트래픽이 생성되지 않습니다. 멀티캐스트 및 단일 주소 데이터그램은 주소가 다릅니다. 멀티캐스트가 있는 IP 데이터그램의 헤더에는 클래스 A, B, C의 IP 주소 대신에 클래스 D 주소, 즉 그룹 주소가 있습니다.

그룹 주소는 일부 수신 장치, 즉 그룹에 할당됩니다. 발신자는 이 멀티캐스트 주소를 IP 데이터그램의 헤더에 기록합니다. 데이터그램은 그룹의 모든 구성원에게 전달됩니다. 클래스 D 주소의 처음 4비트는 1110입니다. 나머지 주소(28비트)는 그룹 식별자가 차지합니다(그림 6.27).

점으로 구분된 10진수 형식에서 그룹 주소의 범위는 224.0.0.0에서 239.255.255.255입니다. 테이블에서. 그림 6.13은 클래스 D 주소 할당 방식을 보여줍니다.

표 6.13. 클래스 D 주소 할당

표에서 알 수 있듯이. 6.13에서 처음 256개 주소는 예약되어 있습니다. 특히 이 범위는 라우팅 프로토콜 및 기타 저수준 프로토콜용으로 예약되어 있습니다. 테이블에서. 6.14에는 일부 예약된 클래스 D IP 주소가 포함되어 있습니다.

이 범위 이상은 큰 그룹인터넷에서 실행되는 응용 프로그램에 할당된 주소. 최상위 주소 범위(약 1600만 주소)는 LAN에서 관리 목적으로 사용됩니다. 클래스 D 그룹 주소는 IANA라는 특수 조직에서 중앙에서 관리하고 등록합니다.

멀티캐스트는 OSI 모델의 두 가지 수준, 즉 채널(데이터 링크 계층)과 네트워크(네트워크 계층)에서 구현할 수 있습니다. 이더넷 및 FDDI와 같은 링크 계층 전송 프로토콜은 단일, 브로드캐스트 및 멀티캐스트 주소 지정을 지원할 수 있습니다. 링크 계층 멀티캐스트는 NIC의 하드웨어에서 지원되는 경우 특히 효과적입니다.

IANA 멀티캐스팅을 지원하기 위해 01-00-5E(16진수 표기법)부터 시작하는 멀티캐스트 이더넷 주소 블록이 할당되었습니다. 멀티캐스트 IP 주소는 이 블록의 주소로 변환될 수 있습니다. 변환 원리는 매우 간단합니다. IP 그룹 식별자의 하위 23비트는 이더넷 주소의 하위 23비트로 복사됩니다. 이 체계는 IP 그룹 ID의 다음 5비트가 무시되기 때문에 최대 32개의 서로 다른 IP 그룹을 동일한 이더넷 주소와 연관시킵니다.

표 6.14. 예약된 클래스 D 주소

주소	목적
224.0.0.1	서브넷의 모든 장치
224.0.0.2	서브넷의 모든 라우터
224.0.0.4	모든 DVMRP 라우터
224.0.0.5	모든 MOSPF 라우터
224.0.0.9	RIP IP 버전 II
224.0.1.7	오디오 뉴스
224.0.1.11	IEFT 오디오
224.0.1.12	IEFT 비디오

발신자와 수신자가 동일한 물리적 네트워크에 속한 경우 링크 계층에서 멀티캐스트 프레임을 보내고 받는 프로세스는 매우 간단합니다. 발신자는 수신자 그룹의 IP 주소를 지정하고 NIC는 이 주소를 해당 그룹 이더넷 주소로 변환하여 프레임을 보냅니다.

발신자와 수신자가 라우터로 연결된 서로 다른 서브넷에 있는 경우 데이터그램 전달이 어렵습니다. 이 경우 라우터는 멀티캐스트 라우팅 프로토콜(DVMRP, MOSPF, PIM - 아래 참조) 중 하나를 지원해야 합니다. 이러한 프로토콜에 따라 라우터는 전달 트리를 구축하고 멀티캐스트 트래픽을 올바르게 전달합니다. 또한 각 라우터는 직접 연결된 서브넷에 그룹 구성원이 있는지 확인하기 위해 IGMP(그룹 관리 프로토콜)를 지원해야 합니다(그림 6.28).

언젠가 VoIP(Voice over IP)가 무엇이며 이러한 모든 약어가 의미하는 바를 빨리 파악해야 하는 경우 이 설명서가 도움이 되기를 바랍니다. 추가 유형의 전화 통신 서비스 구성 문제(예: 통화 전송, 음성 메일, 전화 회의 등)은 여기에서 고려되지 않습니다.

그래서 우리가 컷에서 다룰 내용 :

전화 통신의 기본 개념: 장치 유형, 연결 방식
SIP/SDP/RTP 프로토콜 번들: 작동 방식
누른 버튼에 대한 정보가 전송되는 방식
음성 및 팩스 전송은 어떻게 작동합니까?
IP 텔레포니의 디지털 신호 처리 및 오디오 품질 보증

일반적으로 일반 전화선을 통해 지역 가입자를 전화 사업자에 연결하는 방식은 다음과 같습니다.

공급자(PBX) 쪽에 FXS(Foreign eXchange Subscriber) 포트가 있는 전화 모듈이 설치됩니다. FXO(Foreign eXchange Office) 포트와 다이얼러 모듈이 있는 전화 또는 팩스기는 가정이나 사무실에 설치됩니다.

에 의해 모습 FXS 및 FXO 포트는 다르지 않으며 일반 6핀 RJ11 커넥터입니다. 그러나 전압계를 사용하면 매우 쉽게 구별할 수 있습니다. FXS 포트에는 항상 약간의 전압이 있습니다. 핸드셋이 온훅 상태일 때는 48/60V, 통화 중에는 6-15V입니다. FXO에서 라인에 연결되어 있지 않으면 전압은 항상 0입니다.

전화선을 통해 데이터를 전송하려면 SLIC(가입자 회선 인터페이스 회로) 모듈에서 구현할 수 있는 공급자 측과 가입자 측에서 DAA(직접 액세스 배열) 모듈을 사용하는 추가 논리가 필요합니다.

무선 DECT 전화(디지털 유럽 무선 통신)는 현재 상당히 인기가 있습니다. 장치 측면에서 일반 전화기와 유사합니다. FXO 포트와 다이얼러 모듈도 있지만 모듈도 있습니다. 무선 통신 1.9GHz의 주파수에서 스테이션 및 핸드셋.

가입자가 PSTN망(공중교환전화망)에 접속 - 전화망일반용은 PSTN, PSTN입니다. PSTN 네트워크는 다음을 사용하여 구성할 수 있습니다. 다른 기술: ISDN, 광학, POTS, 이더넷. 일반 아날로그/구리선을 사용하는 PSTN의 특별한 경우 - POTS(Plain Old Telephone Service) - 단순한 구형 전화 시스템.

인터넷의 발달로 전화 통신새로운 수준으로 이동했습니다. 고정 전화기는 주로 공식적인 필요를 위해 점점 더 적게 사용됩니다. DECT 전화는 조금 더 편리하지만 집 주변으로 제한됩니다. GSM 전화는 훨씬 더 편리하지만 국경에 의해 제한됩니다(로밍 비용이 비쌈). 그러나 IP 전화기의 경우에도 소프트폰(SoftPhone)이므로 인터넷 액세스를 제외하고는 제한이 없습니다.

Skype는 소프트폰의 가장 유명한 예입니다. 많은 일을 할 수 있지만 두 가지 중요한 단점이 있습니다. 닫힌 구조와 도청이 어느 당국에 의해 알려져 있는지입니다. 첫 번째 때문에 자신의 전화 마이크로 네트워크를 만드는 것이 불가능합니다. 그리고 두 번째 때문에 - 특히 개인 및 상업적 대화에서 감시당할 때 그다지 유쾌하지 않습니다.

다행스럽게도 SIP 및 H.323과 같은 유용한 통신 네트워크를 생성하기 위한 개방형 프로토콜이 있습니다. SIP 프로토콜에는 H.323보다 몇 가지 더 많은 소프트폰이 있으며 이는 상대적 단순성과 유연성으로 설명할 수 있습니다. 그러나 때로는 이러한 유연성으로 인해 큰 어려움을 겪을 수 있습니다. SIP 및 H.323 프로토콜은 모두 RTP 프로토콜을 사용하여 미디어 데이터를 전송합니다.

고려하다 기본 원리들두 가입자의 연결이 어떻게 발생하는지 이해하기 위한 SIP 프로토콜.

SIP(Session Initiation Protocol) - 세션을 설정하기 위한 프로토콜(단순히 전화가 아님)은 UDP를 통한 텍스트 프로토콜입니다. SIP over TCP를 사용하는 것도 가능하지만 드문 경우입니다.

SDP(세션 설명 프로토콜)는 전송된 데이터 유형(사운드 및 비디오의 경우 코덱 및 형식, 팩스의 경우 전송 속도 및 오류 수정)과 대상 주소(IP 및 포트)를 협상하기 위한 프로토콜입니다. 또한 텍스트 프로토콜입니다. SDP 매개변수는 SIP 패킷의 본문으로 전송됩니다.

RTP(실시간 전송 프로토콜)는 오디오/비디오 데이터 전송 프로토콜입니다. UDP를 통한 바이너리 프로토콜입니다.

SIP 패킷의 일반 구조:

Start-Line: 요청 시 SIP 방식(command), 응답 시 SIP 방식 실행 결과를 나타내는 필드.
헤더: 추가 정보 ATTRIBUTE: VALUE 쌍을 포함하는 문자열로 형식화된 Start-Line에.
본문: 바이너리 또는 텍스트 데이터. 일반적으로 SDP 매개변수 또는 메시지를 보내는 데 사용됩니다.

다음은 하나의 공통 통화 설정 절차에 대한 두 개의 SIP 패킷의 예입니다.

왼쪽은 SIP INVITE 패킷의 내용이고 오른쪽은 SIP 200 OK에 대한 응답입니다.

주요 필드는 다음과 같이 구성됩니다.

메소드/요청-URI는 SIP 메소드 및 URI를 포함합니다. 예에서 세션이 설정되었습니다. INVITE 메서드, 구독자가 호출됩니다. [이메일 보호됨]
상태 코드 - 이전 SIP 명령에 대한 응답 코드입니다. 에 이 예명령이 성공적으로 완료되었습니다 - 코드 200, 즉. 가입자 555가 전화를 받았습니다.
경유 - 가입자 777이 응답을 기다리는 주소. 200 OK 메시지의 경우 이 필드는 INVITE 메시지에서 복사됩니다.
보낸 사람/받는 사람 - 메시지를 보낸 사람과 받는 사람의 이름과 주소를 표시합니다. 200 OK 메시지의 경우 이 필드는 INVITE 메시지에서 복사됩니다.
Cseq는 명령의 순서 번호와 주어진 메시지가 참조하는 메소드의 이름을 포함합니다. 200 OK 메시지의 경우 이 필드는 INVITE 메시지에서 복사됩니다.
Content-Type - Body 블록에서 전송되는 데이터 유형(이 경우 SDP 데이터)입니다.
연결 정보 - 두 번째 가입자가 RTP 패킷(또는 T.38을 통한 팩스 전송의 경우 UDPTL 패킷)을 보내야 하는 IP 주소입니다.
미디어 설명 - 두 번째 가입자가 지정된 데이터를 전송해야 하는 포트입니다. 이 경우 오디오(오디오 RTP/AVP) 및 지원되는 데이터 유형 목록(PCMU, PCMA, GSM 코덱 및 DTMF 신호)입니다.

SDP 메시지는 FIELD=VALUE 쌍을 포함하는 행으로 구성됩니다. 주요 필드는 다음과 같습니다.

영형- 출처, 세션 주최자 이름 및 세션 ID.
와 함께- 연결 정보, 필드는 앞에서 설명했습니다.
중- 미디어 설명, 필드는 앞에서 설명했습니다.
ㅏ- 미디어 속성, 전송된 데이터의 형식을 지정합니다. 예를 들어 사운드의 방향(수신 또는 전송(sendrecv))을 나타내며 코덱의 경우 샘플링 속도와 바인딩 번호(rtpmap)를 나타냅니다.

RTP 패킷에는 특정 형식으로 인코딩된 오디오/비디오 데이터가 포함됩니다. 이 형식 PT(페이로드 유형) 필드에 지정됩니다. 이 필드의 값이 특정 형식에 어떻게 대응하는지에 대한 표는 https://wikipedia org wiki RTP 오디오 비디오 프로필에 나와 있습니다.

또한 RTP 패킷에는 고유한 SSRC 식별자(RTP 스트림의 소스 정의)와 타임스탬프(오디오 또는 비디오를 고르게 재생하는 데 사용되는 타임스탬프)가 포함되어 있습니다.

SIP 서버(별표)를 통한 두 SIP 가입자 간의 상호 작용 예:

SIP 전화가 시작되자마자 가장 먼저 하는 일은 SIP 전화에 등록하는 것입니다. 원격 서버(SIP Registar), SIP REGISTER 메시지를 보냅니다.

가입자를 호출할 때 SIP INVITE 메시지가 전송되며, 그 본문에는 오디오/비디오 전송 매개변수(지원되는 코덱, 오디오를 보낼 IP 및 포트 등)가 포함된 SDP 메시지가 포함되어 있습니다.

원격 가입자가 전화를 받으면 SDP 매개변수가 포함된 SIP 200 OK 메시지도 수신되며 원격 가입자만 해당됩니다. 송수신된 SDP 매개변수를 사용하여 RTP 오디오/비디오 세션 또는 T.38 팩스 세션을 설정할 수 있습니다.

수신된 SDP 매개변수가 적합하지 않거나 중간 SIP 서버가 자체적으로 RTP 트래픽을 전달하지 않기로 결정한 경우, 소위 REINVITE라고 하는 SDP 재협상 절차가 수행됩니다. 그건 그렇고, 무료 SIP 프록시 서버에 한 가지 단점이 있는 것은 바로 이 절차 때문입니다. 두 가입자가 동일한 로컬 네트워크에 있고 프록시 서버가 NAT 뒤에 있는 경우 RTP 트래픽을 리디렉션한 후 가입자 중 누구도 들을 수 없습니다. 또 다른.

통화 종료 후 전화를 끊은 가입자는 SIP BYE 메시지를 보냅니다.

때때로 세션이 설정된 후 통화 중에 통화 보류, 전환, 음성 메일 등의 추가 서비스(VAS)에 대한 액세스가 필요합니다. - 누른 버튼의 특정 조합에 반응합니다.

따라서 일반 전화선에서는 두 가지 방법으로 번호를 다이얼할 수 있습니다.

Pulse - 역사적으로 처음으로 회전식 다이얼러가 있는 전화기에 주로 사용되었습니다. 다이얼링은 다이얼한 숫자에 따라 전화선이 순차적으로 닫히고 열리기 때문에 발생합니다.
톤 - DTMF 코드로 다이얼링(듀얼 톤 다중 주파수) - 전화기의 각 버튼에는 두 개의 사인파 신호(톤)의 고유한 조합이 있습니다. Goertzel 알고리즘을 실행하면 눌린 버튼을 판별하는 것이 매우 쉽습니다.

대화 중 펄스 방식은 누른 버튼을 전송하는 데 불편합니다. 따라서 "0"(각각 100ms의 10개 펄스: 60ms - 줄 바꿈, 40ms - 줄 닫기)을 전송하는 데 약 1초가 걸리고 숫자 사이의 일시 중지에는 200ms가 걸립니다. 또한 펄스 다이얼링 중에 특유의 딸깍 소리가 자주 들립니다. 따라서 기존의 전화 통신에서는 VAS에 액세스하는 톤 모드만 사용됩니다.

VoIP 전화 통신에서 눌린 버튼에 대한 정보는 세 가지 방법으로 전송될 수 있습니다.

DTMF 대역 내 - 오디오 톤을 생성하고 오디오 데이터(현재 RTP 채널) 내부에서 전송하는 것은 일반 톤 다이얼입니다.
RFC2833 - 누른 키, 볼륨 및 지속 시간에 대한 정보가 포함된 특수 전화 이벤트 RTP 패킷이 생성됩니다. RFC2833 DTMF 패킷이 전송될 RTP 형식의 번호는 SDP 메시지 본문에 지정됩니다. 예: a=rtpmap:98 telephone-event/8000.
SIP INFO - SIP INFO 패킷은 누른 키, 볼륨 및 지속 시간에 대한 정보로 구성됩니다.

오디오 데이터(Inband) 내부의 DTMF 전송은 톤 생성/임베딩 및 이를 감지할 때 오버헤드 리소스, DTMF 코드를 왜곡할 수 있는 일부 코덱의 제한 및 낮은 전송 신뢰성(패킷의 일부가 손실되면 동일한 키를 두 번 누르면 감지가 발생할 수 있음).

DTMF RFC2833과 SIP INFO의 주요 차이점: SIP 프록시 서버가 서버 자체를 우회하는 가입자 간에 RTP를 직접 전송할 수 있는 경우(예: canreinvite=yes in 별표), 서버는 RFC2833 패킷을 인식하지 못합니다. 그들이 되는 결과 사용할 수 없는 서비스 DVO. SIP 패킷은 항상 SIP 프록시 서버를 통해 전송되므로 VAS는 항상 작동합니다.

이미 언급했듯이 RTP 프로토콜은 미디어 데이터를 전송하는 데 사용됩니다. RTP 패킷은 항상 전송된 데이터(코덱)의 형식을 지정합니다.

비트 전송률/품질/복잡도의 비율이 다른 음성 전송을 위한 다양한 코덱이 있으며 개방형 및 폐쇄형 코덱이 있습니다. 모든 소프트폰은 G.711 alaw/ulaw 코덱을 지원해야 하며 구현이 매우 간단하고 음질이 좋지만 64kbps의 대역폭이 필요합니다. 예를 들어, G.729 코덱은 8kbps만 필요하지만 CPU를 매우 많이 사용하며 무료가 아닙니다.

팩스 전송에는 일반적으로 G.711 코덱 또는 T.38 프로토콜이 사용됩니다. G.711 코덱을 사용하여 팩스를 보내는 것은 일반 전화선을 통해 팩스를 보낸 것처럼 T.30 프로토콜을 사용하여 팩스를 보내는 것과 같지만 동시에 아날로그 신호라인으로부터는 Law/ulaw 법에 따라 디지털화됩니다. 이를 Inband T.30 팩스라고도 합니다.

T.30 프로토콜을 사용하는 팩스는 전송 속도, 데이터그램 크기, 오류 수정 유형과 같은 매개변수를 협상합니다. T.38 프로토콜은 T.30 프로토콜을 기반으로 하지만 Inband 전송과 달리 생성 및 수신된 T.30 명령을 분석합니다. 따라서 원시 데이터가 전송되지 않고 인식된 팩스 제어 명령이 전송됩니다.

T.38 명령은 UDP 기반 프로토콜이며 T.38에만 사용되는 UDPTL 프로토콜을 사용하여 전송됩니다. TCP 및 RTP 프로토콜도 T.38 명령을 전송하는 데 사용할 수 있지만 훨씬 덜 자주 사용됩니다.

T.38의 주요 장점은 대역 내 팩스 전송에 비해 네트워크 부하가 감소하고 안정성이 향상된다는 것입니다.

T.38 모드에서 팩스를 보내는 절차는 다음과 같습니다.

모든 코덱을 사용하여 정상적인 음성 연결이 설정됩니다.
보내는 팩스기에 용지를 넣으면 팩스를 보낼 준비가 되었음을 나타내기 위해 주기적으로 T.30 CNG(호출음) 신호를 보냅니다.
수신 측에서 T.30 신호 CED(터미널 식별이라고 함)가 생성됩니다. 이는 팩스 수신 준비 상태입니다. 이 신호는 "팩스 수신" 버튼을 누른 후 전송되거나 팩스가 자동으로 수행합니다.
CED 신호는 송신 측에서 감지되고 SIP REINVITE 절차가 발생하며 T.38 유형은 SDP 메시지에 표시됩니다. m=image 39164 udptl t38.

가급적이면 T.38로 인터넷을 통해 팩스 보내기. 사무실 내에서 또는 안정적인 연결이 있는 개체 간에 팩스를 전송해야 하는 경우 Inband T.30 팩스 전송을 사용할 수 있습니다. 이 경우 팩스를 보내기 전에 추가 왜곡이 발생하지 않도록 에코 제거 절차를 꺼야 합니다.

팩스에 대한 매우 자세한 정보는 David Hanes와 Gonzalo Salgueiro가 쓴 "Fax, Modem, and Text for IP Telephony" 책에 나와 있습니다.

우리는 대화 세션(SIP/SDP)을 설정하기 위한 프로토콜과 RTP 채널을 통해 오디오를 전송하는 방법을 다루었습니다. 한 가지 중요한 질문이 있었습니다. 바로 음질이었습니다. 한편으로 음질은 선택한 코덱에 의해 결정됩니다. 그러나 다른 한편으로는 추가적인 DSP 절차(DSP - 디지털 신호 처리)가 여전히 필요합니다. 이러한 절차는 VoIP 전화 통신의 특성을 고려합니다. 고품질 헤드셋이 항상 사용되는 것은 아니며 인터넷에 패킷 드롭이 있고 때때로 패킷이 고르지 않게 도착합니다. 처리량네트워크도 고무가 아닙니다.

음질을 개선하는 기본 절차:

VAD(음성 활동 감지기) - 음성(활성 음성 프레임) 또는 묵음(비활성 음성 프레임)을 포함하는 프레임을 결정하는 절차입니다. 이 분리는 침묵에 대한 정보 전송이 훨씬 적은 데이터를 필요로 하기 때문에 네트워크 부하를 크게 줄일 수 있습니다(노이즈 수준을 전송하기에 충분하거나 전혀 전송하지 않음).

일부 코덱에는 이미 VAD 절차(GSM, G.729)가 포함되어 있지만 다른 코덱(G.711, G.722, G.726)에는 이를 구현해야 합니다.

VAD가 노이즈 레벨에 대한 정보를 전송하도록 구성된 경우 특수 SID 패킷(Silence Insertion Descriptor)은 13번째 CN(Comfort Noise) RTP 형식으로 전송됩니다.

SID 패킷은 SIP 프록시 서버에 의해 삭제될 수 있으므로 확인을 위해 SIP 서버를 지나는 RTP 트래픽 전송을 구성하는 것이 좋습니다.

CNG(comfort noise generation) - SID 패킷의 정보를 기반으로 컴포트 노이즈를 생성하는 절차입니다. 따라서 VAD와 CNG는 함께 작동하지만 CNG 절차는 수요가 훨씬 적습니다. 특히 낮은 볼륨에서 CNG의 작업을 항상 알아차릴 수 있는 것은 아니기 때문입니다.

PLC(패킷 손실 은닉) - 패킷 손실의 경우 오디오 스트림을 복원하는 절차입니다. 패킷 손실이 50%인 경우에도 우수한 PLC 알고리즘은 허용 가능한 음성 품질을 달성할 수 있습니다. 물론 왜곡이 있을 수 있지만 단어를 알아낼 수 있습니다.

패킷 손실을 에뮬레이트하는 가장 쉬운 방법(Linux에서)은 netem 모듈과 함께 iproute 패키지의 tc 유틸리티를 사용하는 것입니다. 나가는 트래픽의 셰이핑만 수행합니다.

50% 패킷 손실로 네트워크 에뮬레이션을 실행하는 예:

Tc qdisc 변경 dev eth1 루트 netem 손실 50%

에뮬레이션 비활성화:

Tc qdisc del dev eth1 루트

지터 버퍼- 수신 패킷 사이의 간격이 많이 변하고 최악의 경우 수신 패킷의 순서가 잘못된 경우 지터 효과를 제거하는 절차. 또한 이 효과는 말을 중단시킵니다. 지터 효과를 없애기 위해서는 주어진 간격으로 원래의 패킷 전송 순서를 복원할 수 있는 충분한 크기의 패킷 버퍼를 수신측에 구현해야 합니다.

tc 유틸리티를 사용하여 지터 효과를 에뮬레이션할 수도 있습니다(패킷 도착 예상 순간과 실제 순간 사이의 간격은 최대 500ms일 수 있음).

tc qdisc add dev eth1 루트 netem 지연 500ms 재정렬 99%

LEC(Line Echo Canceller) - 원격 가입자가 자신의 목소리를 듣기 시작할 때 로컬 에코를 제거하는 절차입니다. 그 본질은 특정 계수로 전송 신호에서 수신 신호를 빼는 것입니다.

에코는 여러 가지 이유로 발생할 수 있습니다.

열악한 오디오 경로로 인한 음향 에코(스피커의 소리가 마이크에 입력됨);
임피던스 불일치로 인한 전기적 에코 전화및 SLIC 모듈. 대부분의 경우 이것은 4선식 전화선을 2선식으로 변환하는 회로에서 발생합니다.

이유(음향 또는 전기 에코)를 찾는 것은 어렵지 않습니다. 에코가 생성되는 가입자는 마이크를 꺼야 합니다. 에코가 계속 발생하면 전기적인 것입니다.

VoIP 및 DSP 절차에 대한 자세한 내용은 VoIP 음성 및 팩스 신호 처리를 참조하십시오. Google 도서에서 미리보기를 사용할 수 있습니다.

이것으로 VoIP에 대한 피상적인 이론적 개요가 완성되었습니다. 관심이 있다면 실제 하드웨어 플랫폼에서 mini-PBX를 실제로 구현하는 예를 다음 기사에서 고려할 수 있습니다.

[!?] 질문과 의견을 환영합니다. Promwad 전자 설계 센터의 소프트웨어 엔지니어인 Dmitry Valento 기사 작성자가 답변을 제공합니다.

태그:

초보자를 위한
초보자를 위한

태그 추가

동기화 소스(SSRC) 식별자

기여 소스(CSRC) 식별자