Trying to understand wire format for RTX (rfc4588)

[Jeremy Noring]

I'm trying to understand the retransmission payload format (see https://tools.ietf.org/html/rfc4588#section-4); I don't understand the format on the wire.  Could someone provide a quick example of what an rtx packet would look like for an arbitrary lost packet?

Thanks!

[Sergio Garcia Murillo]

WebRTC uses SSRC-multiplexing so:

   In the case of SSRC-multiplexing, two different SSRC values MUST be
   used for the original stream and the retransmission stream as
   required by RTP.

   The retransmission packet timestamp MUST be set to the original
   timestamp, i.e., to the timestamp of the original packet. 

	
   The timestamp clockrate used by the retransmission payload
   type MUST be the same as the one used by the associated original
   payload type.

   The marker bit (M), the CSRC count (CC), and the CSRC list of the
   original RTP header MUST be copied "as is" into the RTP header of the
   retransmission packet.

   The payload of the RTP retransmission packet comprises the
   retransmission payload header followed by the payload of the original
   RTP packet.  The length of the retransmission payload header is 2
   octets.  This payload header contains only one field, OSN (original
   sequence number), which MUST be set to the sequence number of the
   associated original RTP packet.  The original RTP packet payload,
   including any possible payload headers specific to the original
   payload type, MUST be placed right after the retransmission payload
   header.

   If the original RTP packet contained RTP padding, that padding MUST
   be removed before constructing the retransmission packet.  If padding
   of the retransmission packet is needed, padding MUST be performed as
   with any RTP packets and the padding bit MUST be set.

And the payload type is the one set on the apt SDP attribute. Associated SSRC for rtx stream can be also be retrieved from the SDP.

Best regards
Sergio

On 21/09/2016 23:55, Jeremy Noring wrote:

I'm trying to understand the retransmission payload format (see https://tools.ietf.org/html/rfc4588#section-4); I don't understand the format on the wire.  Could someone provide a quick example of what an rtx packet would look like for an arbitrary lost packet?

Thanks!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/0cd8575f-89be-441b-b43f-a6878d283316%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Noring]

Thanks Sergio.

One thing that's strange is I see Chrome merely resending packets verbatim in response to a NACK; it doesn't appear to be using this rtx format?  Could that be because of something in my SDP?  Also, I know this to be true because I remember having to hack libsrtp's replay detection in my media server to ensure NACK'd packets didn't get dropped on the floor.  I'm assuming if Chrome was using rfc4588 this would not be the case?