What steps will reproduce the problem?
1. offer with audio codec occupying payload type X(104 for ISAC 32000 in my case), and video codecs (h264, vp8, vp9 + rtx codecs in my case) dynamically allocated payload type above X, i.e. it would have allocated X if not used by audio.
2. negotiate the call to audio codec Y, and video codec Z
2. remove video stream from both ends, so now we only have negotiated audio codec Y active
3. enable video offering for remote first, and then locally, now we get duplicate id warnings as the allocation of the payload type now begins with Y, all the supported video codecs and then the other supported audio codecs. In this case, the ordering of the payload type allocation has changed, and video codec would occupy payload type X instead, and voice engine would fail as it detects a payload type change on the audio codec that originally had payload type X.

What is the expected result?
The setlocaldescription shouldn't fail in this case.

What do you see instead?
now it is in a bad state where we can no longer re-enable video.

What version of the product are you using? On what operating system?
this is since m57 I think.

Please provide any additional information below.

In MediaSessionDescriptionFactory::GetCodecsToOffer, the ordering of finding the codecs to offer changes in re-negotiation (with current_description or not), which then could change the payload type of the same codec offered previously.


In WebRtcVoiceMediaChannel::SetRecvCodecs, there is code to look for the payload type change of a previously configured codec, and fail the operation.

I see there is comment in WebRtcVoiceMediaChannel::SetRecvCodecs saying changing the payload type is wrong, but it obviously happens for video and seems fine. so couple of questions:

1. why video allows changing in payload type?
2. why cannot the codecs be trimmed after both side agreed upon a subset of the codecs?
3. why cannot the audio receive streams be reconfigured with the updated payload type? It is conveyed in the sdp negotiation, so both sides will have it updated.




 

Deleted: webrtc.log 3.7 KB

webrtc.log 3.7 KB View Download