[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] retransmission and SSRC-based multiplexing
- To: <avt@ietf.org>
- Subject: [AVT] retransmission and SSRC-based multiplexing
- From: David.Leon@nokia.com
- Date: Mon, 17 Jun 2002 15:52:36 -0500
- Importance: high
- List-Id: Audio/Video Transport Working Group <avt.ietf.org>
- Priority: Urgent
- Sender: avt-admin@ietf.org
- Thread-Index: AcIWOmYrZGz/9H1MEdat6gAGKfW1ag==
- Thread-Topic: retransmission and SSRC-based multiplexing
Hello,
As requested at the last WG meeting, the RTP retransmission framework draft now includes an applicability statement and can be found at http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-01.txt
We would like to hear any comments you may have on this applicability statement and draw your attention on the following point.
The draft requires that two separate sequence number spaces be used for the original stream and the retransmission stream. As noted in the applicability statement, this requires that the retransmission stream have a separate addresse/port. If setting additional ports for the retransmission stream is a concern for some implementers, we would like to ask feedback from the working group whether it would be acceptable to use SSRC based multiplexing for the original and the retransmission stream instead of port multiplexing.
We had proposed SSRC based multiplexing for retransmission back in August 2001 at the IETF meeting in London. It was commented that since the SSRC is a random number chosen by the RTP sender, it would not be possible to associate original stream and retransmission stream in a multicast group.
However, in unicast we believe that SSRC based multiplexing could be used. Let's imagine that an RTP receiver receives the original stream and retransmission stream on the same multicast address/port. Since the receiver knows the payload types used by the original stream and the retransmission stream, it would be able to derive which SSRC corresponds to the original data and which SSRC corresponds to retransmissions.
So would like to propose that in the multicast case, separate address and/or port be used as described in the draft but to allow in unicast the retransmission stream to be either multiplexed based on the port or the SSRC.
We are aware that multiplexing RTP streams based on SSRC and payload type should generally be avoided. Section 5.2 of the RTP states that "Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields". However, in the case of retransmission, it is the same media sent in both streams.
We would thus like to hear feedback whether there is any objection to update the draft to allow the use of SSRC-based multiplexing for unicast retransmission.
Thanks, David.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt