TanSanC

[CPP] NTP Sync LocalClockOffset

NTP 는

Network Time Protocol 으로 네트워크를 통해 시간을 동기화 하는 프로토콜입니다.

NTP 서버 시간에 클라이언트 시간을 맞추기 위한 프로토콜입니다.

[현재 시점] 서버의 현재 시간과 클라이언트의 현재 시간이 다를 수 있고,

[지속 되는 상태] 서버의 1초와 클라이언트의 1초가 다를 수 있습니다.

서버 혹은 클라이언트간 시간이 아주 중요한 프로그램에서는

NTP 는 한번만 수행하는 것이 아닌 지속적으로 수행하여 동기화 하게 됩니다.

서버와 클라이언트의 시간 차이를 LocalClockOffset 으로 표기합니다.

여러 클라이언트의 시간을

NTP서버와 동기화하여

각 클라이언트간 시간이 동기화 하도록 하기 위해 사용 되는 값이 offset 입니다.

계산 식은

Timestamp Name ID When Generated

------------------------------------------------------------

Originate Timestamp T1 time request sent by client      C1

Receive Timestamp T2 time request received by server  S1

Transmit Timestamp T3 time reply sent by server         S2

Destination Timestamp T4 time reply received by client C2

The roundtrip delay d and system clock offset t are defined as:

d = (T4 - T1) - (T3 - T2)

t = ((T2 - T1) + (T3 - T4)) / 2.

t = ((S1 - C1) + (S2 - C2)) / 2.

여기서

여기서 서버와 클라리언트가 패킷을 주고 받는데 걸리는 딜레이(delay1, delay2)는 같다고 가정한다.

RTP Payload Type 참고자료

https://tools.ietf.org/html/rfc1890

      PT         encoding      audio/video    clock rate    channels
                 name          (A/V)          (Hz)          (audio)
      _______________________________________________________________
      0          PCMU          A              8000          1
      1          1016          A              8000          1
      2          G721          A              8000          1
      3          GSM           A              8000          1
      4          unassigned    A              8000          1
      5          DVI4          A              8000          1
      6          DVI4          A              16000         1
      7          LPC           A              8000          1
      8          PCMA          A              8000          1
      9          G722          A              8000          1
      10         L16           A              44100         2
      11         L16           A              44100         1
      12         unassigned    A
      13         unassigned    A
      14         MPA           A              90000        (see text)
      15         G728          A              8000          1
      16--23     unassigned    A
      24         unassigned    V
      25         CelB          V              90000
      26         JPEG          V              90000
      27         unassigned    V
      28         nv            V              90000
      29         unassigned    V
      30         unassigned    V
      31         H261          V              90000
      32         MPV           V              90000
      33         MP2T          AV             90000
      34--71     unassigned    ?
      72--76     reserved      N/A            N/A           N/A
      77--95     unassigned    ?
      96--127    dynamic       ?

   Table 2: Payload types (PT) for standard audio and video encodings

https://tools.ietf.org/html/rfc3551#page-32

               PT   encoding    media type  clock rate   channels
                    name                    (Hz)
               ___________________________________________________
               0    PCMU        A            8,000       1
               1    reserved    A
               2    reserved    A
               3    GSM         A            8,000       1
               4    G723        A            8,000       1
               5    DVI4        A            8,000       1
               6    DVI4        A           16,000       1
               7    LPC         A            8,000       1
               8    PCMA        A            8,000       1
               9    G722        A            8,000       1
               10   L16         A           44,100       2
               11   L16         A           44,100       1
               12   QCELP       A            8,000       1
               13   CN          A            8,000       1
               14   MPA         A           90,000       (see text)
               15   G728        A            8,000       1
               16   DVI4        A           11,025       1
               17   DVI4        A           22,050       1
               18   G729        A            8,000       1
               19   reserved    A
               20   unassigned  A
               21   unassigned  A
               22   unassigned  A
               23   unassigned  A
               dyn  G726-40     A            8,000       1
               dyn  G726-32     A            8,000       1
               dyn  G726-24     A            8,000       1
               dyn  G726-16     A            8,000       1
               dyn  G729D       A            8,000       1
               dyn  G729E       A            8,000       1
               dyn  GSM-EFR     A            8,000       1
               dyn  L8          A            var.        var.
               dyn  RED         A                        (see text)
               dyn  VDVI        A            var.        1

               Table 4: Payload types (PT) for audio encodings

http://www.ktword.co.kr/abbr_view.php?m_temp1=3394

     - 오디오 타입 번호 例)
        . 0 -> G.711 PCM(mu-law), 샘플링주파수 8000 Hz
        . 3 -> GSM,               샘플링주파수 8000 Hz
        . 4 -> G.723,             샘플링주파수 8000 Hz
        . 6 -> DVI4 (ADPCM),      샘플링주파수 16000 Hz
        . 7 -> LPC,               샘플링주파수 8000 Hz
        . 8 -> G.711 PCM(A-Law)   샘플링주파수 8000 Hz
        . 9 -> G.722,             샘플링주파수 8000 Hz
        . 14 -> MPEG 오디오,      샘플링주파수 90000 Hz
        . 15 -> G.728,            샘플링주파수 8000 Hz

https://tools.ietf.org/html/rfc1890

.  Audio

4.1 Encoding-Independent Recommendations

   For applications which send no packets during silence, the first
   packet of a talkspurt (first packet after a silence period) is
   distinguished by setting the marker bit in the RTP  data header.
   Applications without silence suppression set the bit to zero.

   The RTP clock rate used for generating the RTP timestamp is
   independent of the number of channels and the encoding; it equals the
   number of sampling periods per second.  For N-channel encodings, each
   sampling period (say, 1/8000 of a second) generates N samples. (This
   terminology is standard, but somewhat confusing, as the total number
   of samples generated per second is then the sampling rate times the
   channel count.)

   If multiple audio channels are used, channels are numbered left-to-
   right, starting at one. In RTP audio packets, information from
   lower-numbered channels precedes that from higher-numbered channels.
   For more than two channels, the convention followed by the AIFF-C
   audio interchange format should be followed [1], using the following
   notation:

   l    left
   r    right
   c    center
   S    surround
   F    front
   R    rear



   channels    description                 channel
                               1     2     3     4     5     6
   ___________________________________________________________
   2           stereo          l     r
   3                           l     r     c
   4           quadrophonic    Fl    Fr    Rl    Rr
   4                           l     c     r     S
   5                           Fl    Fr    Fc    Sl    Sr
   6                           l     lc    c     r     rc    S

https://tools.ietf.org/html/rfc3551#page-32

4.4 Audio Encodings

           encoding    sample/frame    bits/sample    ms/frame
           ____________________________________________________
           1016        frame           N/A            30
           DVI4        sample          4
           G721        sample          4
           G722        sample          8
           G728        frame           N/A            2.5
           GSM         frame           N/A            20
           L8          sample          8
           L16         sample          16
           LPC         frame           N/A            20
           MPA         frame           N/A
           PCMA        sample          8
           PCMU        sample          8
           VDVI        sample          var.

                 Table 1: Properties of Audio Encodings

4.5 Audio Encodings

   name of                              sampling              default
   encoding  sample/frame  bits/sample      rate  ms/frame  ms/packet
   __________________________________________________________________
   DVI4      sample        4                var.                   20
   G722      sample        8              16,000                   20
   G723      frame         N/A             8,000        30         30
   G726-40   sample        5               8,000                   20
   G726-32   sample        4               8,000                   20
   G726-24   sample        3               8,000                   20
   G726-16   sample        2               8,000                   20
   G728      frame         N/A             8,000       2.5         20
   G729      frame         N/A             8,000        10         20
   G729D     frame         N/A             8,000        10         20
   G729E     frame         N/A             8,000        10         20
   GSM       frame         N/A             8,000        20         20
   GSM-EFR   frame         N/A             8,000        20         20
   L8        sample        8                var.                   20
   L16       sample        16               var.                   20
   LPC       frame         N/A             8,000        20         20
   MPA       frame         N/A              var.      var.
   PCMA      sample        8                var.                   20
   PCMU      sample        8                var.                   20
   QCELP     frame         N/A             8,000        20         20
   VDVI      sample        var.             var.                   20

   Table 1: Properties of Audio Encodings (N/A: not applicable; var.:
            variable)

출처 : https://tools.ietf.org/html/rfc3550#page-13

RTP Protocol

. RTP Data Transfer Protocol

5.1 RTP Fixed Header Fields

   The RTP header has the following format:

    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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first twelve octets are present in every RTP packet, while the
   list of CSRC identifiers is present only when inserted by a mixer.
   The fields have the following meaning:

   version (V): 2 bits
      This field identifies the version of RTP.  The version defined by
      this specification is two (2).  (The value 1 is used by the first
      draft version of RTP and the value 0 is used by the protocol
      initially implemented in the "vat" audio tool.)

   padding (P): 1 bit
      If the padding bit is set, the packet contains one or more
      additional padding octets at the end which are not part of the
      payload.  The last octet of the padding contains a count of how
      many padding octets should be ignored, including itself.  Padding
      may be needed by some encryption algorithms with fixed block sizes
      or for carrying several RTP packets in a lower-layer protocol data
      unit.

   extension (X): 1 bit
      If the extension bit is set, the fixed header MUST be followed by
      exactly one header extension, with a format defined in Section
      5.3.1.

   CSRC count (CC): 4 bits
      The CSRC count contains the number of CSRC identifiers that follow
      the fixed header.

   marker (M): 1 bit
      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
      marker bits or specify that there is no marker bit by changing the
      number of bits in the payload type field (see Section 5.3).

   payload type (PT): 7 bits
      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 (see Section 3).  A set of default mappings for
      audio and video is specified in the companion RFC 3551 [1].  An
      RTP source MAY change the payload type during a session, but this
      field SHOULD NOT be used for multiplexing separate media streams
      (see Section 5.2).

      A receiver MUST ignore packets with payload types that it does not
      understand.

   sequence number: 16 bits
      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 according to the method in Section 9.1, because the
      packets may flow through a translator that does.  Techniques for
      choosing unpredictable numbers are discussed in [17].

   timestamp: 32 bits
      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations (see Section 6.4.1).  The
      resolution of the clock MUST be sufficient for the desired
      synchronization accuracy and for measuring packet arrival jitter
      (one tick per video frame is typically not sufficient).  The clock
      frequency is dependent on the format of data carried as payload
      and is specified statically in the profile or payload format
      specification that defines the format, or MAY be specified
      dynamically for payload formats defined through non-RTP means.  If
      RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio
      the timestamp clock would likely increment by one for each
      sampling period.  If an audio application reads blocks covering

      160 sampling periods from the input device, the timestamp would be
      increased by 160 for each such block, regardless of whether the
      block is transmitted in a packet or dropped as silent.

      The initial value of the timestamp SHOULD be random, as for the
      sequence number.  Several consecutive RTP packets will have equal
      timestamps if they are (logically) generated at once, e.g., belong
      to the same video frame.  Consecutive RTP packets MAY contain
      timestamps that are not monotonic if the data is not transmitted
      in the order it was sampled, as in the case of MPEG interpolated
      video frames.  (The sequence numbers of the packets as transmitted
      will still be monotonic.)

      RTP timestamps from different media streams may advance at
      different rates and usually have independent, random offsets.
      Therefore, although these timestamps are sufficient to reconstruct
      the timing of a single stream, directly comparing RTP timestamps
      from different media is not effective for synchronization.
      Instead, for each medium the RTP timestamp is related to the
      sampling instant by pairing it with a timestamp from a reference
      clock (wallclock) that represents the time when the data
      corresponding to the RTP timestamp was sampled.  The reference
      clock is shared by all media to be synchronized.  The timestamp
      pairs are not transmitted in every data packet, but at a lower
      rate in RTCP SR packets as described in Section 6.4.

      The sampling instant is chosen as the point of reference for the
      RTP timestamp because it is known to the transmitting endpoint and
      has a common definition for all media, independent of encoding
      delays or other processing.  The purpose is to allow synchronized
      presentation of all media sampled at the same time.

      Applications transmitting stored data rather than data sampled in
      real time typically use a virtual presentation timeline derived
      from wallclock time to determine when the next frame or other unit
      of each medium in the stored data should be presented.  In this
      case, the RTP timestamp would reflect the presentation time for
      each unit.  That is, the RTP timestamp for each unit would be
      related to the wallclock time at which the unit becomes current on
      the virtual presentation timeline.  Actual presentation occurs
      some time later as determined by the receiver.

      An example describing live audio narration of prerecorded video
      illustrates the significance of choosing the sampling instant as
      the reference point.  In this scenario, the video would be
      presented locally for the narrator to view and would be
      simultaneously transmitted using RTP.  The "sampling instant" of a
      video frame transmitted in RTP would be established by referencing

      its timestamp to the wallclock time when that video frame was
      presented to the narrator.  The sampling instant for the audio RTP
      packets containing the narrator's speech would be established by
      referencing the same wallclock time when the audio was sampled.
      The audio and video may even be transmitted by different hosts if
      the reference clocks on the two hosts are synchronized by some
      means such as NTP.  A receiver can then synchronize presentation
      of the audio and video packets by relating their RTP timestamps
      using the timestamp pairs in RTCP SR packets.

   SSRC: 32 bits
      The SSRC field identifies the synchronization source.  This
      identifier SHOULD be chosen randomly, with the intent that no two
      synchronization sources within the same RTP session will have the
      same SSRC identifier.  An example algorithm for generating a
      random identifier is presented in Appendix A.6.  Although the
      probability of multiple sources choosing the same identifier is
      low, all RTP implementations must be prepared to detect and
      resolve collisions.  Section 8 describes the probability of
      collision along with a mechanism for resolving collisions and
      detecting RTP-level forwarding loops based on the uniqueness of
      the SSRC identifier.  If a source changes its source transport
      address, it must also choose a new SSRC identifier to avoid being
      interpreted as a looped source (see Section 8.2).

   CSRC list: 0 to 15 items, 32 bits each
      The CSRC list identifies the contributing sources for the payload
      contained in this packet.  The number of identifiers is given by
      the CC field.  If there are more than 15 contributing sources,
      only 15 can be identified.  CSRC identifiers are inserted by
      mixers (see Section 7.1), using the SSRC identifiers of
      contributing sources.  For example, for audio packets the SSRC
      identifiers of all sources that were mixed together to create a
      packet are listed, allowing correct talker indication at the
      receiver.

  ㅇ 제어비트  : 16 비트
     - Ver (버젼)      : 2 비트
        . 현재 RTP 버젼은, 2 (RFC 3550)
     - P (padding)     : 1 비트
        . 1 이면 실제 유료부하 끝에 덧붙여진 패딩 데이터 있음
        . 응용프로그램이 32 비트 같은 정수배 단위로 RTP 패킷 페이로드 구성을 위함
     - X (extension)   : 1 비트
        . 1 이면 가변길이 헤더 확장(Extension Header)이 있음을 나타냄
     - CC (CSRC Count) : 4 비트
        . 기본 헤더 바로 뒤에 나타나는 CSRC(Countributing SouRCe) ID의 갯수
        . 여러 미디어가 합성되는 경우에, 그 개수를 CC로써 나타내고,
          모두의 기준 동기를 맞추려면 SRRC ID로써 이를 나타냄
     - M (Marker)      : 1 비트
        . 이벤트 발생이 시작되었음을 알림

  ㅇ 유료부하 타입(Payload type) : (7 비트)  오디오/비디오 인코딩(코덱) 종류
     - 오디오 타입 번호 例)
        . 0 -> G.711 PCM(mu-law), 샘플링주파수 8000 Hz
        . 3 -> GSM,               샘플링주파수 8000 Hz
        . 4 -> G.723,             샘플링주파수 8000 Hz
        . 6 -> DVI4 (ADPCM),      샘플링주파수 16000 Hz
        . 7 -> LPC,               샘플링주파수 8000 Hz
        . 8 -> G.711 PCM(A-Law)   샘플링주파수 8000 Hz
        . 9 -> G.722,             샘플링주파수 8000 Hz
        . 14 -> MPEG 오디오,      샘플링주파수 90000 Hz
        . 15 -> G.728,            샘플링주파수 8000 Hz
     - 비디오 타입 번호 例)
        . 26 -> 화상 JPEG, 31 -> H.261, 32 -> MPEG-1 또는 MPEG-2 비디오, 
          33 -> MPEG-2 TS 등
     - 기타 임의 지정 가능(dynamic payload type) : 96~127

     * RTP 내 유료부하 유형(Payload type) 표준 목록 ☞ IANA RTP Parameters
        . RFC 3551에서 오디오 신호/비디오 신호의 인코딩 방법,샘플링 주파수 등이 기술됨

  ㅇ 순서번호(Sequence number) : (16 비트)
     - 패킷 손실 검출 및 순서 재구성 
        . 초기값은 랜덤이고, 매 패킷 마다 1씩 증가
           .. 수신측은 패킷 재전송 요청 보다는 패킷 손실 검출 및 뒤바뀐 순서 복구를 위함

  ㅇ 타임스탬프(Timestamp) : (32 비트)
     - RTP 스트림 내 각 RTP 패킷이 샘플링된 시간관계를 나타냄
        . 랜덤한 초기값부터 시작하며, 통상적으로 카운터에 의해 1씩 증가시킴

     - 타임스탬프 간격은 유료부하 유형에 따라 정해진 샘플링 간격을 기준 
        . 대부분의 오디오 RTP 패킷의 경우 => 1 패킷 당 디폴트 시간 간격을 20 ms으로 함
           .. 例) G.711 (PCM A-Law) 오디오 페이로드 패킷 크기 
                    = (유료부하 코덱 데이터율) x (1 패킷 당 시간 간격)
                    = (64 kbps G.711 코덱) x (20 ms)
                    = (8000 samples x 8 bits)/sec x (0.02 sec)
                    = 160 바이트

     - 타임스탬프 값의 연속성 의미 구분
        . 例1) 일련의 패킷들의 타임스탬프 값이 `같은` 경우  
           .. 특정 비디오 장면이 같은 시간에 샘플링되었음을 의미
        . 例2) 일련의 패킷들의 타임스탬프 값이 `단순 증가하지 않는` 경우
           .. MPEG 화면 픽처 처럼 시간 순서가 어긋나며 전후 화면으로부터 예측되었음을 의미
        . 例3) 일련의 패킷들의 타임스탬프 값이 `연속 증가`되는 번호 순서를 갖음
           .. 오디오 패킷 흐름일 경우 등

  ㅇ 동기 발신 식별자 (SSRC ID, Synchronization SouRCe ID) : (32 비트)
     - 원래의 정보 스트림에 대한 식별 
        . 하나의 RTP 세션 내에서는, 
           .. 각각의 발송지는 무작위 SSRC ID로 나타내고, 
           .. 타 발송지와의 구별을 위해 중복되지 않아야 함
        . 여러 미디어가 혼합되어 있으면, 
           .. SSRC는 일종의 기준 역할이 가능함

     * RTP 세션 이란? 
        . RTP를 통해 상호 통신하는 참가자들 간에 형성된 논리적 연결 상태
        . RTP 세션에서 목적지 확인은, 
           .. 1개의 IP 주소 및 1쌍의 RTP/RTCP 번호로 식별됨
           .. 이때 IP 주소는 멀티캐스트 주소일 수도 있음
        . 만일, 여러 미디어가 믹서에서 혼합되면, 그 믹서에 대한 SSRC ID를 갖게됨

  ㅇ 기여 발신 식별자 (CSRC ID, Contributor SouRCe ID) 목록 : (32 비트) 1 이상 가변 갯수
     - 믹서(Mixer)를 통해 혼합되어 단일의 정보열로 되면, 원래의 각각에 대한 식별 역할
        . 여러 미디어가 혼합되면, CC(CSRC Count:4 비트)에 총 개수를 지정하고, 
        . SSRC 이외 추가된 스트림들에 대한 식별자를 CSRC ID 값으로 함

     * 만일, 하나의 미디어 소스 만 있다면, 
        . CC=1 이되고, RTP 헤더 길이는 12 바이트(기본헤더 길이)가 됨
        . 결국, SSRC ID가 하나의 값을 갖고, CSRC ID 목록은 비어있게 됨

  ※ [참고_웹] ☞ RTP의 이해