SIP RTP - Revision history

Pchero: /* RTP Header */

2023-02-28T13:57:11Z

RTP Header

← Older revision		Revision as of 13:57, 28 February 2023
Line 75:		Line 75:
	: 보안을 이유로 랜덤 번호에서 시작하고 패킷이 늘어날 때마다 1씩 증가.		: 보안을 이유로 랜덤 번호에서 시작하고 패킷이 늘어날 때마다 1씩 증가.
	: 수신 측이 패킷 손실 여부 확인 가능.		: 수신 측이 패킷 손실 여부 확인 가능.
			: The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random(unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because the packets may flow through a translator that does.

	* Timestamp		* Timestamp
Line 80:		Line 81:
	: RTP 패킷의 첫 번째 바이트의 샘플링 순간을 표시.		: RTP 패킷의 첫 번째 바이트의 샘플링 순간을 표시.
	: 초기값은 랜덤 넘버로 결정되지만 샘플링 레이트에 따라 증가량은 상이함.		: 초기값은 랜덤 넘버로 결정되지만 샘플링 레이트에 따라 증가량은 상이함.
			: The timestamp reflects the sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock MUST be sufficient for the desired

	* SSRC (Synchronization Source) Identifier		* SSRC (Synchronization Source) Identifier

Pchero: /* RTP Header */

2023-02-28T13:53:12Z

RTP Header

← Older revision		Revision as of 13:53, 28 February 2023
Line 63:		Line 63:
	: 패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시.		: 패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시.
	: Payload Type 필드의 확장을 위해 무시되기도 함.		: Payload Type 필드의 확장을 위해 무시되기도 함.
			: The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional bits or specify that there is no marker bit by changing the number of bits in the payload type field.

	* PT (Payload Type)		* PT (Payload Type)
Line 68:		Line 69:
	: 페이로드 타입은 RTP가 전송하고 있는 실시간 데이터의 압축 코덱을 명시.		: 페이로드 타입은 RTP가 전송하고 있는 실시간 데이터의 압축 코덱을 명시.
	: 페이로드 타입은 Capability Exchange 협상에서 상호 인지 필수.		: 페이로드 타입은 Capability Exchange 협상에서 상호 인지 필수.
			: This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means. A set of default mappings for audio and video is specified in the companion RFC 3551. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams. A receiver MUST ignore packets with payload types that it does not understand.

	* Sequence number		* Sequence number

Pchero at 13:44, 14 February 2023

2023-02-14T13:44:31Z

@@ Line 126: / Line 126: @@
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </pre>
 == Troubleshooting ==

Pchero: /* RTP Header */

2020-10-06T05:56:53Z

RTP Header

← Older revision		Revision as of 05:56, 6 October 2020
Line 59:		Line 59:
	: RTP 12 바이트 고정 헤더 위에 CSRC identifier 의 수 표시.		: RTP 12 바이트 고정 헤더 위에 CSRC identifier 의 수 표시.

	* M (~~Maker~~)		* M (Marker)
	: 1 bit.		: 1 bit.
	: 패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시.		: 패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시.

Pchero: /* Troubleshooting */

2020-04-06T15:26:57Z

Troubleshooting

← Older revision		Revision as of 15:26, 6 April 2020
Line 137:		Line 137:
	: 시퀀스 넘버가 순차적으로 증가하지않고 갑자기 증가하거나 감소하는 경우가 있다. 예를 들어 100 다음 400번이 오는 경우 수신 단말은 300 개의 패킷이 손실된 것으로 보고 재생하지 않는다. 반대로 100 다음에 60 이 오는 경우 수신단말은 이미 수신한 패킷으로 인식하고 재생하지 않는다.		: 시퀀스 넘버가 순차적으로 증가하지않고 갑자기 증가하거나 감소하는 경우가 있다. 예를 들어 100 다음 400번이 오는 경우 수신 단말은 300 개의 패킷이 손실된 것으로 보고 재생하지 않는다. 반대로 100 다음에 60 이 오는 경우 수신단말은 이미 수신한 패킷으로 인식하고 재생하지 않는다.
	: RFC 3550 Appendix A.3 Determining Number of Packets Expected and Lost 에 의하면, 갑자기 비연속적인 시퀀스 넘버가 3개 이상 연속될 경우 수신 단말은 시퀀스 넘버가 재설정된 것으로 인삭하고 재생해야 한다.		: RFC 3550 Appendix A.3 Determining Number of Packets Expected and Lost 에 의하면, 갑자기 비연속적인 시퀀스 넘버가 3개 이상 연속될 경우 수신 단말은 시퀀스 넘버가 재설정된 것으로 인삭하고 재생해야 한다.

			* 타임스탬프는 일정하게 증가하는가?
			: 타임스탬프는 패킷의 재생 시점을 확인하므로 갑자기 감소하거나 크게 증가하면 안된다.

			* 음질에 문제가 있는가?
			: 와이어 샤크로 RTP 패킷을 캡쳐하여 음성 파일로 만들어서 재생할 수 있다. 음성 파일에 문제가 있다면 송신 단말에서 문제가 있는 것이고, 음성 파일에 문제가 없다면 수신 단말의 문제이다.

	== See also ==		== See also ==

Pchero: /* RTCP Header */

2020-04-06T15:25:11Z

RTCP Header

@@ Line 126: / Line 126: @@
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </pre>
 == See also ==

Pchero: /* RTP Header */

2020-04-06T15:20:26Z

RTP Header

@@ Line 42: / Line 42: @@
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </pre>
 == RTCP Header ==

Pchero: /* RTP Header */

2020-04-03T15:47:26Z

RTP Header

← Older revision		Revision as of 15:47, 3 April 2020
Line 27:		Line 27:

	== RTP Header ==		== RTP Header ==
			RFC 3550에 RTP 헤더가 정의되어 있다.
			<pre>
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\|V=2\|P\|X\| CC \|M\| PT \| sequence number \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| timestamp \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| synchronization source (SSRC) identifier \|
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			\| contributing source (CSRC) identifiers \|
			\| .... \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			</pre>

			== RTCP Header ==
			RFC 3550에 RTCP 헤더가 정의되어 있다.
			<pre>
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			header \|V=2\|P\| RC \| PT=SR=200 \| length \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| SSRC of sender \|
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			sender \| NTP timestamp, most significant word \|
			info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| NTP timestamp, least significant word \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| RTP timestamp \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| sender's packet count \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| sender's octet count \|
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			report \| SSRC_1 (SSRC of first source) \|
			block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			1 \| fraction lost \| cumulative number of packets lost \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| extended highest sequence number received \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| interarrival jitter \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| last SR (LSR) \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			\| delay since last SR (DLSR) \|
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			report \| SSRC_2 (SSRC of second source) \|
			block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			2 : ... :
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			\| profile-specific extensions \|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			</pre>

	== See also ==		== See also ==

Pchero at 15:44, 3 April 2020

2020-04-03T15:44:20Z

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

Pchero: /* RTP 의 헤더 구조 */

2020-04-03T15:30:51Z

RTP 의 헤더 구조

← Older revision		Revision as of 15:30, 3 April 2020
Line 8:		Line 8:

	== RTP 의 헤더 구조 ==		== RTP 의 헤더 구조 ==

			== See also ==
			* https://brunch.co.kr/@linecard/154 - RTP의 이해

	[[category:SIP protocol]]		[[category:SIP protocol]]