New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users
Status: Assigned
Owner:
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
Resume the sequence number between StopSend() and StartSend()
Reported by xians@chromium.org, Jul 18 2013 Back to list

Right now WebRtc will reset the RTP sequence number in StopSend(), this sometimes causes the libSRTP to complain about packets being replayed. Libjingle work around it by caching the sequence number in WebRtcVoiceEngine.cc, and call SetInitSequenceNumber() to resume the sequence number before StartSend(). And we need to remove the libjingle workaround in order to support multiple send channels.




 
Comment 1 by xians@webrtc.org, Jul 18 2013
Cc: tommi@webrtc.org pwestin@webrtc.org
Labels: Mstone-30
Owner: xians@webrtc.org
Comment 2 by xians@webrtc.org, Jul 18 2013
There is some libjingle comment stating:
// We need to store the sequence number to be able to pick up
// the same sequence when the device is restarted.
// TODO(oja): Remove when WebRtc has fixed the problem.

So we need to fix the problem in webrtc
Project Member Comment 3 by bugdroid1@chromium.org, Jul 19 2013
The following revision refers to this bug:
    http://code.google.com/p/webrtc/source/detail?r=4374

------------------------------------------------------------------------
r4374 | xians@webrtc.org | 2013-07-19T13:57:58.212660Z

Changed paths:
   M http://code.google.com/p/webrtc/source/diff?path=/stable/webrtc/voice_engine/channel.cc&spec=svn4374&r_previous=4373&r=4374&format=side
   M http://code.google.com/p/webrtc/source/diff?path=/stable/webrtc/voice_engine/channel.h&spec=svn4374&r_previous=4373&r=4374&format=side

Store the sequence number in StopSend() and resume it in StartSend().

When restarting the microphone device, we call StopSend() first, then StartSend() later. Since we reset sequence number in StopSend(), it sometimes causes libSRTP to complain about packets being replayed. Libjingle work around it by caching the sequence number in WebRtcVoiceEngine.cc, and call SetInitSequenceNumber() to resume the sequence number before StartSend().

This patch fixes this problem by storing the sequence number in StopSend(), and resume it in StartSend(). So that we can remove the workaround in libjingle.

BUG=2102
R=tommi@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/1823004
------------------------------------------------------------------------
Project Member Comment 4 by bugdroid1@chromium.org, Jul 31 2013
The following revision refers to this bug:
    http://code.google.com/p/webrtc/source/detail?r=4451

------------------------------------------------------------------------
r4451 | xians@webrtc.org | 2013-07-31T16:30:19.619126Z

Changed paths:
   M http://code.google.com/p/webrtc/source/diff?path=/trunk/webrtc/voice_engine/channel.cc&spec=svn4451&r_previous=4450&r=4451&format=side
   M http://code.google.com/p/webrtc/source/diff?path=/trunk/webrtc/voice_engine/channel.h&spec=svn4451&r_previous=4450&r=4451&format=side

Merge r4374 from stable to trunk.

r4374 was mistakenly committed to stable, so this is to re-merge back to trunk.

Store the sequence number in StopSend() and resume it in StartSend().

When restarting the microphone device, we call StopSend() first, then
StartSend() later. Since we reset sequence number in StopSend(), it sometimes
causes libSRTP to complain about packets being replayed. Libjingle work around
it by caching the sequence number in WebRtcVoiceEngine.cc, and call
SetInitSequenceNumber() to resume the sequence number before StartSend().Store the sequence number in StopSend() and resume it in StartSend().

When restarting the microphone device, we call StopSend() first, then
StartSend() later. Since we reset sequence number in StopSend(), it sometimes
causes libSRTP to complain about packets being replayed. Libjingle work around
it by caching the sequence number in WebRtcVoiceEngine.cc, and call
SetInitSequenceNumber() to resume the sequence number before StartSend().

This patch fixes this problem by storing the sequence number in StopSend(), and
resume it in StartSend(). So that we can remove the workaround in libjingle.

BUG=2102
R=tommi@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/1922004
------------------------------------------------------------------------
Comment 5 by juberti@google.com, Aug 8 2013
Cc: juberti@webrtc.org
The real issue here is that historically we needed to call StopSend before changing input/output devices. If that problem has been resolved, we can remove the need to call StopSend.
Project Member Comment 6 by vikasmarwaha@webrtc.org, May 7 2014
Shijing, it sounds like we can close this issue. If not, can you move the target milestone. 
Comment 7 by vrk@webrtc.org, Dec 17 2014
Labels: Area-Network
Project Member Comment 8 by juberti@webrtc.org, Jan 6 2015
Cc: pthatcher@webrtc.org jlmiller@webrtc.org
Labels: -Mstone-30 Mstone-43 EngTriaged
Owner: juberti@webrtc.org
Status: Available
We need to reevaluate our use of StopSend. StopSend sends a BYE, so we shouldn't be using StopSend if we're planning to keep using the stream. Not a high priority ATM though.
Project Member Comment 9 by vikasmarwaha@webrtc.org, Mar 31 2015
should we move the milestone?
Project Member Comment 10 by juberti@webrtc.org, Apr 1 2015
Labels: -Mstone-43 Mstone-46
Project Member Comment 11 by tnakamura@webrtc.org, Sep 2 2015
Cc: -jlmiller@webrtc.org
Labels: -Mstone-46
Status: Assigned
This didn't make M46, and it's been moved around for quite some time, so I'm clearing the M46 label. Justin, when you get a chance, can you assign a new milestone label?
Project Member Comment 12 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Project Member Comment 13 by solenberg@webrtc.org, Mar 17 2017
Cc: tina.legrand@webrtc.org solenberg@webrtc.org kwiberg@webrtc.org
 Issue 2111  has been merged into this issue.
Project Member Comment 14 by solenberg@webrtc.org, Mar 17 2017
Owner: stefan@webrtc.org
Reassigning to stefan@; the merged  bug 2111  mentions that the RtpRtcpModule should keep track of sequence number when a stream is stopped then started again, and that such code in VoE (i.e. https://cs.chromium.org/chromium/src/third_party/webrtc/voice_engine/channel.cc?rcl=4491b9eb0296250967ead758ddfa19b085b75632&l=1200) should be removed.

Is any such functionality planned for the work on RtpTransports?

Project Member Comment 15 by stefan@webrtc.org, Mar 28 2017
Cc: stefan@webrtc.org
Owner: solenberg@webrtc.org
I couldn't find any code in rtp_rtcp that would reset the sequence number on calling SetSendingMediaStatus or SetSendingStatus, so my guess is that you're already good to go.
Sign in to add a comment