not receiving RTX packets for RTP seqNum signaled through NACK bitmask
443 views
Skip to first unread message
Dennis
Oct 3, 2016, 4:59:03 PM10/3/16
to discuss-webrtc
I am simulating sporadic bursts of sequential packet loss from a vp8 video-only webrtc stream received on a custom middlebox relay and forcing the request of retransmits but I am only seeing the RTX packet for the sequence number specified in the PID field and sequence numbers indicated through the bitmask field are not retransmitted.
For example, if I drop RTP packets 680, 681, 682, and 684, and then when I get RTP packet seq num 685 I send a generic nack with 680 in the PID field, and 0000 1011 in the BLP field (0x000b), I get the RTX packet for 680 only. I do not get any RTX packets for 681, 682, or 684. I've tried reverse endianness for the bitmask field too (just in case either I screwed up or webrtc devs did) , and also adjusted waiting a bit longer lets say not sending the NACK until I get RTP seq num 700 , but no success. I always only get that one RTX packet for the PID but none that are specified in the bitmask. I've fiddled with adjusting bitmask endianess and timing and other variations of this all over the place and can't get this to work. It doesn't even matter if I put 0xffff in the bitmask, none of those packets are retransmitted. I verified this through wireshark too. So if I try this several times lets say seq num 680-685 then 720-725 then 750-755 I'll only get 680, 720, and 750 and the sequence numbers in the RTX stream increments by 1 for each of those (so the RTX seq number for 680 would be like 30932, and 720 would be 30933, and 750 would be 30934) so it's definitely not sending all those other packets that are indicated through the bitmasks.
My test setup is a webrtc stream sending a video only stream at 10fps to a custom middlebox where every now and then I'll drop a few sequential RTP packets intentionally and which triggers an RTCP_RTPFB_NACK / generic NACK feedback report back to the webrtc source which specifies the first lost packet in the PID field and several more sequential ones as indicated by the BLP bitmask ("BLP allows for reporting losses of any of the 16 RTP packets immediately following the RTP packet indicated by the PID", see spec snippet at bottom below). I do receive the one RTP packet thats indicated by the PID sequence number itself, but I do not get any retransmission packets for the others.
For example, if I drop RTP packets 680, 681, 682, and 684, and then when I get RTP packet seq num 685 I send a generic nack with 680 in the PID field, and 0000 1011 in the BLP field (0x000b), I get the RTX packet for 680 only. I do not get any RTX packets for 681, 682, or 684. I've tried reverse endianness for the bitmask field too (just in case either I screwed up or webrtc devs did) , and also adjusted waiting a bit longer lets say not sending the NACK until I get RTP seq num 700 , but no success. I always only get that one RTX packet for the PID but none that are specified in the bitmask. I've fiddled with adjusting bitmask endianess and timing and other variations of this all over the place and can't get this to work. It doesn't even matter if I put 0xffff in the bitmask, none of those packets are retransmitted. I verified this through wireshark too. So if I try this several times lets say seq num 680-685 then 720-725 then 750-755 I'll only get 680, 720, and 750 and the sequence numbers in the RTX stream increments by 1 for each of those (so the RTX seq number for 680 would be like 30932, and 720 would be 30933, and 750 would be 30934) so it's definitely not sending all those other packets that are indicated through the bitmasks.
Has anyone seen anything like this before? Does Webrtc completely ignore the BLP bitmask field and expect that each packet needed needs to be in its own separate generic NACK FCI ? at least that's what it seems like to me from my testing....
From RFS 4585:
From RFS 4585:
The Feedback Control Information (FCI) field has the following Syntax
(Figure 4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message
Packet ID (PID): 16 bits
The PID field is used to specify a lost packet. The PID field
refers to the RTP sequence number of the lost packet.
bitmask of following lost packets (BLP): 16 bits
The BLP allows for reporting losses of any of the 16 RTP packets
immediately following the RTP packet indicated by the PID. The
BLP's definition is identical to that given in [6]. Denoting the
BLP's least significant bit as bit 1, and its most significant bit
as bit 16, then bit i of the bit mask is set to 1 if the receiver
has not received RTP packet number (PID+i) (modulo 2^16) and
indicates this packet is lost; bit i is set to 0 otherwise. Note
that the sender MUST NOT assume that a receiver has received a
packet because its bit mask was set to 0. For example, the least
significant bit of the BLP would be set to 1 if the packet
corresponding to the PID and the following packet have been lost.
However, the sender cannot infer that packets PID+2 through PID+16
have been received simply because bits 2 through 15 of the BLP are
0; all the sender knows is that the receiver has not reported them
as lost at this time.
Jeremy Noring
Oct 4, 2016, 12:35:43 PM10/4/16
to discuss-webrtc
I noticed very similar behavior last week when working with our media server. It did not seem like NACKed packets would always be resent.
If you create a single NACK field for each missing packet, ignoring BLP entirely, does stuff get retransmitted?
Dennis Dowhy
Oct 4, 2016, 2:36:52 PM10/4/16
to discuss...@googlegroups.com
If I dedicate an entire RTCP compound packet (RR+NACK) per missing RTP packet, where the NACK contains only one generic NACK FCI and setting the pid to the sequence number and the blp to 0, and I do this for every single missing packet, yea they get retransmitted but that doesn't seem the right way whatsoever..
So if I want all 3 retransmitted, the only way I can get this to work is to do this in 3 separate packets:
SEND RTCP FEEDBACK PACKET 1:
I even tried multiple generic nack's in the FCI using only the pid and setting blp=0 for each and that didn't work either. so for the following example, I would see 680 retransmitted but not 681 or 682.
// 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=RR=201 | length |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
// 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) |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=5 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=680 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=681 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=682 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So if I want all 3 retransmitted, the only way I can get this to work is to do this in 3 separate packets:
SEND RTCP FEEDBACK PACKET 1:
// 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=RR=201 | length |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
// 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) |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=3 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=680 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SEND RTCP FEEDBACK PACKET 2:
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SEND RTCP FEEDBACK PACKET 2:
// 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=RR=201 | length |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
// 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) |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=3 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=681 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SEND RTCP FEEDBACK PACKET 3:
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SEND RTCP FEEDBACK PACKET 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=RR=201 | length |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
// 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) |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=3 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=682 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What's also interesting is that I've tried this:
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What's also interesting is that I've tried this:
// 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=RR=201 | length |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
// 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) |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=3 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=680 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=3 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=681 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// |V=2|P| FMT=1 | PT=205 | length=3 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of packet sender |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | SSRC of media source |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// | PID=682 | BLP=0 |
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and in this case, I'll get 682 but I won't get 680 or 681...
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/952a418b-9fe1-4f56-96bd-e049e8664dd6%40googlegroups.com.--
---
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-webrtc+unsubscribe@googlegroups.com.
Jeremy Noring
Oct 4, 2016, 3:24:13 PM10/4/16
to discuss-webrtc
On Tuesday, October 4, 2016 at 12:36:52 PM UTC-6, Dennis wrote:
If I dedicate an entire RTCP compound packet (RR+NACK) per missing RTP packet, where the NACK contains only one generic NACK FCI and setting the pid to the sequence number and the blp to 0, and I do this for every single missing packet, yea they get retransmitted but that doesn't seem the right way whatsoever..
I agree it's not the right way--I'm just curious if it works or not to try and narrow down on the problem.
My vote is either A) I don't understand how NACKs work or B) there's a bug. Because I agree, a PID with a BLP field that isn't 0x0 should result in multiple NACK'd packets. I'd bug it.
Stefan Birrer
Oct 10, 2016, 9:54:47 AM10/10/16
to discuss-webrtc
It appears you are not using the bitmask to request multiple NACKs even though the packets are sequential.
From the behavior you describe it appears to only parse the act on the last NACK packet. Your first example the second and third entry are not valid so they are probably ignored. In the other example the last NACK packet seems to take effect. This may or may not be behavior defined in the standard.
Though you should be able to form one NACK packet that has the base sequence number and the bit mask to request multiple packets at once.
Dennis Dowhy
Oct 10, 2016, 11:12:08 AM10/10/16
to discuss...@googlegroups.com
Stefan, you missed the whole original point. "one NACK packet that has the base sequence number and the bit mask to request multiple packets at once." this was the first test that I had done, and it does not work. So, in the meantime trying to find a workaround (since the webrtc implementation seems to have a bug in it), I experimented with other ways to see if they worked. But the original test itself, where I send one NACK packet with the base sequence number and setting bits in the bitmask does *NOT* work. In that case only the base sequence number is retransmitted, and none of the packets that are indicated by the pid+bitmask are retransmitted.
--
---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/46460cd1-c36e-4f87-82c9-c97eeeeeb318%40googlegroups.com.
Stefan Birrer
Oct 10, 2016, 2:27:54 PM10/10/16
to discuss...@googlegroups.com
Sorry for missing that but I guess that means you already know the answer. According to your observation only a plain vanilla NACK work.
For the records: The RFC allows for multiple PID/BLP pairs (see toward the end of paragraph 6.2.1). So both of your use cases should be supported.
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/46460cd1-c36e-4f87-82c9-c97eeeeeb318%40googlegroups.com.
--
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/WwoJYmxmnhk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAKsVzDjVXGON9yzbzGKwhw9Mc_gBE6JFA6ocw7iEEUF4MyN4JQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Stefan Birrer, PhD | PhenixP2P Inc
CEO & Co-Founder
312.801.5535(o) | 773.442.2588(c) | 888.505.0753(f)
stefan...@phenixp2p.comReply all
Reply to author
Forward
0 new messages