Partial offer and answer support

[Alexander Abagian]

Does Firefox support partial offers and answers ?

I encovered a problem with more than two participants in Firefox client.

The client works in the following manner :

1)
setLocalDescription [offer]

a=group:BUNDLE sdparta_0 sdparta_1
...
m=audio
a=mid:sdparta_0
...
m=video
a=mid:sdparta_1
...

setRemoteDescription [answer]

a=group:BUNDLE sdparta_0 sdparta_1
...
m=audio
a=mid:sdparta_0
...
m=video
a=mid:sdparta_1
...

2)
setRemoteDescription [offer]

a=group:BUNDLE sdparta_0 sdparta_audio_1 sdparta_1 sdparta_video_1
...
m=audio
a=mid:sdparta_0
...
m=audio
a=mid:sdparta_audio_1
...
m=video
a=mid:sdparta_1
...
m=video
a=mid:sdparta_video_1
...

setLocalDescription [answer]

a=group:BUNDLE sdparta_0 sdparta_audio_1 sdparta_1 sdparta_video_1
...
m=audio
a=mid:sdparta_0
...
m=audio <<<<<<<<<<< fail
a=mid:sdparta_audio_1
...
m=video
a=mid:sdparta_1
...
m=video
a=mid:sdparta_video_1
...


In the pointed point, Firefox asserts "In GetAudioConduit, we found a video conduit!". Probably by some (unknown for me) reason it compares the first local SDP with the second one, where the level (number of m-line) really differs.

I found Partial Offers and Answers (draft-roach-mmusic-pof-pan-02) document that resolves the problem. The question is if it is supported by Firefox or not.

[Byron Campen]

I am surprised that reoffer wasn't rejected outright; you cannot
reorder m-sections like this. I will need to look into why you did not
hit an error sooner.

Best regards,
Byron Campen

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

[Adam Roach]

On 2/11/16 10:54, Alexander Abagian wrote:
> I found Partial Offers and Answers (draft-roach-mmusic-pof-pan-02) document that resolves the problem. The question is if it is supported by Firefox or not.

I put this draft together as a proof-of-concept around how we could
reduce the chances of certain glare conditions arising. So far, the
MMUSIC and RTCWEB working groups have not decided that this kind of
glare reduction is sufficiently important to adopt the work for
finalization and publication.

Basically: this work is dead, and unlikely to be resumed.

--
Adam Roach
Principal Platform Engineer
Office of the CTO

[Alexander Abagian]

Thank you for the answer.

I've changed the order of m-sections from all-audio-first (I've done it so because have seen this requirement it in some RFC) to audio-video pairing with adding a new m-secions to the end of the SDP, and it helps.

But anyway when I'm removing a participant, I'm receiving a error "Wrong SDP: New remote description has fewer m-sections than the previous remote description.". How should I form remote SDP in this case ? Leaving these dead m-sections, just assigning zero tp their ports ?

[Byron Campen]

> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media

Yeah, you can either disable the extra m-sections (set a port of 0),
or you can make them a=inactive. Removing m-sections is forbidden by the
rules of SDP offer/answer.

Best regards,
Byron Campen

[Randell Jesup]

On 2/12/2016 11:58 AM, Byron Campen wrote:
> On 2/12/16 9:26 AM, Alexander Abagian wrote:
>> Thank you for the answer.
>>
>> I've changed the order of m-sections from all-audio-first (I've done
>> it so because have seen this requirement it in some RFC) to
>> audio-video pairing with adding a new m-secions to the end of the
>> SDP, and it helps.
>>
>> But anyway when I'm removing a participant, I'm receiving a error
>> "Wrong SDP: New remote description has fewer m-sections than the
>> previous remote description.". How should I form remote SDP in this
>> case ? Leaving these dead m-sections, just assigning zero tp their
>> ports ?
>>

> Yeah, you can either disable the extra m-sections (set a port of
> 0), or you can make them a=inactive. Removing m-sections is forbidden
> by the rules of SDP offer/answer.

Right: You can never remove m-sections. You should not reorder them
either. You should not (though in theory I think you can) change an
m-section type (audio/video/applications); too much danger of code
getting it wrong since no one tests it - and there's very little win to
doing so.

And there's nothing that says audio should come first, though that's
generally common.

--
Randell Jesup, Mozilla

[Byron Campen]

Changing the type of an m-section is forbidden by the base spec I
believe, although the JSEP draft says you should recycle disabled
m-sections even if they need to change types (I think this is likely to
break stuff).

As far as ordering of m-sections goes, the JSEP draft says to add
m-sections based on the order that MediaStreams are added, and then the
tracks are ordered alphabetically based on media type (which happens to
put audio before video).

We have not implemented either of these behaviors yet.

Best regards,
Byron Campen