erizo can renegotiate streams, which means it would also make sense to implement placing calls "on hold".
As I can see in SdpInfo, erizo obviously only supports a=sendrecv, sendonly and recvonly, depite of RFC 4566 defining a=inactive as well. I admit libjingle/peerconnection has no means for setting a=inactive either, but at least we would be able to mangle sdp in order to add a=inactive if erizo would support it. Do I see this correctly?
How big is the effort of implementing this feature into erizo? Is it just adding the constant and passing a=inactive through between clients, or is there more? I believe a=inactive only needs to behave as if something was set to ...only, just always and/or in both directions.
There are discussions underway for implementing
a=inactive
into WebRTC. Chrome already supports this.https://www.w3.org/2011/04/webrtc/wiki/images/archive/f/f7/20131112025841!W3C-sdp-2.pdf https://bugzilla.mozilla.org/show_bug.cgi?id=1015052 https://bugzilla.mozilla.org/show_bug.cgi?id=1213773
erizo can renegotiate streams, which means it would also make sense to implement placing calls "on hold".
As I can see in SdpInfo, erizo obviously only supports
a=sendrecv
,sendonly
andrecvonly
, depite of RFC 4566 defininga=inactive
as well. I admit libjingle/peerconnection has no means for settinga=inactive
either, but at least we would be able to mangle sdp in order to adda=inactive
if erizo would support it. Do I see this correctly?How big is the effort of implementing this feature into erizo? Is it just adding the constant and passing
a=inactive
through between clients, or is there more? I believea=inactive
only needs to behave as if something was set to...only
, just always and/or in both directions.