Assignment 9 – Gloria Patri Stak Analysis by Mehrab Monjur

1           Introduction

In the Gloria Patri stak trace by Prof. Harris, we are mainly concerned about RTP, RTCP transport protocols and packet encoding (ogg format). We will look at RFC 3550 which obsoletes RFC 1889 (RTP: A Transport Protocol for Real-Time Applications) as a reference to figure out this stak of Gloria Patri.

Figure 1 shows the RTP and RTCP communication channel in Gloria Partri example.

Figure 1: RTP and RTCP communication.

2           RTCP Packets

Initially, 192.168.1.3:42051 (Kansas) sends 7 rtcp packets of 32 bytes or 72 bytes to 192.168.1.6:42051 (Missouri). The difference of packet sizes is caused by SDES, RR and SR length in this example, although there can be several rtcp packet types: Sender report packet, Receiver report packet, Source Description RTCP Packet, Goodbye RTCP Packet and Application Specific RTCP packets.

2.1           SDES

The first 7 rtcp packets are either 32 bytes or 72 bytes long with 8 byte RR packet. The difference is because of 24 and 64 byte SDES packets.

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|    SC   |  PT=SDES=202  |             length            | header

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|                          SSRC/CSRC_1                          | chunk

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   1

|                           SDES items                          |

|                              ...                              |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|                          SSRC/CSRC_2                          | chunk

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   2

|                           SDES items                          |

|                              ...                              |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Figure2: SDES packet format.

 

PROVIDER:udp USER:rtcp <8+72>
Available bytes:80
src:42051 dst:42051 length=80 cksum=332e
 
PROVIDER:rtcp USER:none <0+-1>
  RTCPReportList:
  RR:length 8  SSRC: 91ad90fb
  SDES: length 64 SSRC: 91ad90fb
    CNAME: doug@kansas
    EMAIL: jmf-user@sun.com
    TOOL: JMF RTP Player v2.0

STAK 1: RTCP size 72 bytes where SDES length 64 and RR length 8.

Stak did not parse V (version), P (padding), and SC (source counting). As it is a SDES packet, PT (packet) is 202.  For the STAK 1 in SDES we have three items to indentify the source: CNAME (canonical end-point identifier), EMAIL, and TOOL. SSRC is to identify synchronizing source so that no two source can have same SSRC in a RTP session. It is a random number.

PROVIDER:udp USER:rtcp <8+32>
Available bytes:40
src:42051 dst:42051 length=40 cksum=685d
 
PROVIDER:rtcp USER:none <0+-1>
  RTCPReportList:
  RR:length 8  SSRC: 91ad90fb
  SDES: length 24 SSRC: 91ad90fb
    CNAME: doug@kansas

STAK 2: RTCP size 32 bytes where SDES length 24 and RR length 8.

2.2           Sender and Receiver Report

In the middle of the transmission came elaborate Sender Report (CAPTURE-00060) of 28 bytes (see STAK 3) and Receiver Report (CAPTURE-00021) of 32 bytes (see STAK 4).

PROVIDER:rtcp USER:none <0+-1>
  RTCPReportList:
  SR: length 28  SSRC: 91b95a39
    NTPstamp: 47d362a97fffffff
    RTPstamp: 00006180
    sentPackets: 00000033
    sentBytes: 00003190
  SDES: length 64 SSRC: 91b95a39
    CNAME: doug@missouri
    EMAIL: jmf-user@sun.com
    TOOL: JMF RTP Player v2.0

STAK 3: Source Report

 

 

PROVIDER:rtcp USER:none <0+-1>
  RTCPReportList:
  RR:length 32  SSRC: 91ade888
    SRC 1: 91b95a39
    loss: 00000000
    hiseq: 00006bca
        jitter: 0000001d
    last SR: 00000000
    delay: 7fffffff
  SDES: length 24 SSRC: 91ade888
    CNAME: doug@kansas

STAK 4: Elaborate Receiver Report.

3           RTP Packets

RTP transmission time (TR) was steady initially. It started with 37ms and continued with an average of 39ms from CAPTURE-00007 to CAPTURE-00061.  We do not see any capture after CAPTURE-00061 up to CAPTURE-01285. Finally, we see huge increase in TR and from CAPTURE-01285 to CAPTURE-01313 average TR is 137ms.

All the RTP packets are 256 bytes (including header). Each RTP payload is 244 bytes and each header is 12 bytes. As nCsrc (count for CSRC identifier) is 0 for all the packets, there is no 4 byte CSRC (contributing source identifier) field in the header. pType is a 7 bit to identify the payload type. Here it is 5 i.e. type = Audio and Name= DV14 [rfc3551].

PROVIDER:rtp USER:none <0+-1>
  version:2
  pMarked:0
  pType:5 nCsrc:0
  seqNbr:65116
  tStamp:301920
  SSRC:2444906276
STAK 5: An instance of an RTP header.