Edge WebRTC doesn't support ssrc change

Site Outreach Issue #9763337

Details

Created
Nov 11, 2016
Privacy
This issue is public.
Found in
  • Microsoft Edge
Found in build #
14.14393
Reports
Reported by 1 person

Sign in to watch or report this issue.

Steps to reproduce

Make a video call between Chrome and Edge through a rtp gateway. Disable and re-enable video from Chrome towards Edge.

Expected: Video should be re-establish after re-enabling.

Actually: Video cannot work any more from Chrome to Edge.

Issue: Chrome sends other video stream (changed ssrc), our rtp gateway changes the ssrc as well (with srtp change) but Edge doesn’t seem to handle this.

Note: Both Chrome and Firefox support ssrc change (with srtp change).

Attachments

0 attachments

    Comments and activity

    • Note I am using H264 Video Codec (experimental support)

    • Microsoft Edge Team

      Changed Assigned To to “Brad E.”

    • Issue happens for audio as well. Audio source could change for example due to a call transfer.

    • Microsoft Edge Team

      Changed Assigned To to “Venkat K.”

      Changed Assigned To from “Venkat K.” to “Shijun S.”

      Changed Status to “Confirmed”

    • Thanks for reporting the issue to us!

      Routing after an SSRC change is still under discussion within W3C ORTC CG and IETF WG.  It’d be very helpful if you could provide more details for us to understand exactly what is going wrong, for example, whether you are specifying SSRCs to match, or just payload types, or a mixture of both.

      Meanwhile, without knowing that level of details, here is a tip in case it is relevant.  For SSRC matching to handle an SSRC change, the new SSRC needs to be signaled, i.e. the RtpParameters should be updated and receiver.receive(parameters) should be called again.  Packets coming from the new SSRC will potentially be dropped until the signaling and receive() call.

      All the Best, MS Edge Team

    • Thank you for giving essential info !

      We would like to change ssrc just by changing it in the rtp header (without specifying SSRCs change).

      We use SIP for signalling and we provide inter-operability with classic SIP phones. Those phone does not need to signal SSRC change (even with srtp). Furthermore Chrome and Firefox support SSRC change without signalling.

      When someone performs an attended transfer (call then transfer) after it - each party will receive a new stream (from the new source) - therefore SSRC must change. We could signal this, but transfer is already intensive in terms of exchanged SIP messages.

      Thank you for sharing the receiver.receive trick. We will try it but we would prefer changing SSRC without signalling.

      Best Regards,

      Florin Popescu

    • From your description, it sounds like this is audio only and no audio/video mux involved. I expect the Payload Type matching should work. We allow SSRC change without signaling change, but once the app set receive SSRC, we start honor that and throw away packets that don’t match the SSRC.

      Could you confirm whether you provide unique PTs to receive(), and no SSRCs at all?  That will help us further narrow down the problem.

      Best, Shijun

    • Thank you for the answer.

      We are doing audio and audio+video as well. I have just described an example when we need SSRC change for the audio stream.

      We are using webrtc adapter (github) and we were providing unique PTs but we also set first SSRC to receive (therefore it seems that bounded to that one).

      We finally succeeded into calling rtpReceiver.receive() with only RTCRtpCodecCapability array structure filled in (without specifying SSRC).
      However it seems that it requires a non empty array of RTCRtpEncodingParameters structure in the RTCRtpParameters.encodings field, which i couldn’t find in documentation. Also it only worked if I put {ssrc: null, active: true} in the first position of the array. Any other attempt was failing with native InvalidAccessError exception !

      So, audio call works even after transfers, but I couldn’t do the same for video.

      Is video working in a different way ? Any attempt to set rtpReceiver.receive() without a valid encoding.ssrc was failing with the same InvalidAccessError exception.

      Best Regards,

      Florin

    • Good to know you had the audio scenario working.  A/V mux is a different story, SSRC must be specified and we don’t support payload-based de-mux.  It looks like you need to call rtpReceiver.receive() with new SSRC’s explicitly, if you have to use A/V bundle.

      Best, Shijun

    • Hi Shijun,

      Thank you for the answer. We will try to call receive with the new parameters.
      Unfortunately, we cannot do this for all of our use cases.

      We hope it will be possible to change SSRC without signalling in the near future.

      Best regards,

      Florin

    • Microsoft Edge Team

      Changed Status from “Confirmed” to “Site Outreach”

    • We will resolve the bug for now.  Please feel free to reactivate the bug if calling receive() doesn’t work out for your immediate scenarios, and feel free to bring the topic to IETF or W3C groups if necessary.

      All the Best, Shijun

    You need to sign in to your Microsoft account to add a comment.

    Sign in