setRemoteDescription fails if media type from PeerConnection and GetUserMedia are different

[Mamadou]

Hello,

All is in the title. Below, javaScript code to reproduce the issue.
If you change the code to use same media type for both PeerConnection
and GetUserMedia then, the code work.
var o_webkitGetUserMediaHasType = { audio: true, video: false };
var o_MediaContraintsHasType = { audio: true, video: false };



== JAVASCRIPT CODE ==

var o_stream = null;
var o_pc;
var o_webkitGetUserMediaHasType = { audio: true, video: false };
var o_MediaContraintsHasType = { audio: true, video: true };
var o_media_constraints =
{ 'mandatory':
{
'OfferToReceiveAudio': o_MediaContraintsHasType.audio,
'OfferToReceiveVideo': o_MediaContraintsHasType.video
}
};

window.onload = function () {
if (navigator.webkitGetUserMedia) {
navigator.webkitGetUserMedia({ audio:
o_webkitGetUserMediaHasType.audio, video:
o_webkitGetUserMediaHasType.video },
function (stream) {
o_stream = stream;
},
function (e) {
console.error(e.toString());
});
}
};

var s_answer = "v=0\r\n" +
"o=root 1899020397 1899020397 IN IP4 87.106.69.240\r\n" +
"s=Asterisk PBX SVN-trunk-r376131M\r\n" +
"c=IN IP4 87.106.69.240\r\n" +
"t=0 0\r\n" +
"m=audio 16872 RTP/SAVPF 0 8 101\r\n" +
"a=rtpmap:0 PCMU/8000\r\n" +
"a=rtpmap:8 PCMA/8000\r\n" +
"a=rtpmap:101 telephone-event/8000\r\n" +
"a=fmtp:101 0-16\r\n" +
"a=silenceSupp:off - - - -\r\n" +
"a=ptime:20\r\n" +
"a=ice-ufrag:4d41d1d24fe82de138e9871d4905fbbe\r\n" +
"a=ice-pwd:71454c1b48845b8b37b6f9875d5d844f\r\n" +
"a=candidate:H576a45f0 1 udp 2130706431 87.106.69.240 16872
typ host generation 0 svn 25\r\n" +
"a=candidate:S576a45f0 1 udp 1694498815 87.106.69.240 16872
typ srflx generation 0 svn 25\r\n" +
"a=candidate:H576a45f0 2 udp 2130706430 87.106.69.240 16873
typ host generation 0 svn 25\r\n" +
"a=candidate:S576a45f0 2 udp 1694498814 87.106.69.240 16872
typ srflx generation 0 svn 25\r\n" +
"a=sendrecv\r\n" +
"a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:DPm7A6pyoRY1ctub98B92/j/dqFO4yuSgD+Gbx9m\r\n";


o_pc = new webkitRTCPeerConnection(
{ iceServers: [{ url: 'stun:stun.l.google.com:
19302'}] },
o_media_constraints
);

o_pc.onicecandidate = function (o_event) {
console.info("onicecandidate = " + o_pc.iceState);
if (o_pc.iceState == "completed" || (o_event && !
o_event.candidate)) {
console.info("ICE COMPLETED");

o_pc.setRemoteDescription(
new RTCSessionDescription({ type: "answer", sdp:
s_answer }),
function () { // success callback
console.info("setRemoteDescription ok");
},
function (s_error) { // error callback
console.error("setRemoteDescription nok");
}
);
}
else if (o_pc.iceState == "failed") {
console.error("Ice state is 'failed'");
}
}
o_pc.onopen = function () {
console.info("onopen");
}

o_pc.addStream(o_stream);

o_pc.createOffer(
function (desc) {
o_pc.setLocalDescription(desc);
},
function (s_error) {
console.error("createAnswer nok: " + s_error);
},
o_media_constraints
);


Regards,

[Brave Yao]

Hi Mamadou

This should be not be a problem of the different of mediaType in constraints to peerConnection and getUserMedia. I think the problem is in the Answer message.

video:false in getUserMedia means no video sending out. And video:true in peerConnection means video receiving ok. So I suppose in the Answer you should still provide video capabilities. Below answer works in my test. One-way video session could be setup.

S->C: {"sdp":"v=0\r\no=- 271651317 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\nm=audio 1 RTP/SAVPF 103 104 0 8 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:SzSsfdwx/XmvQmgz\r\na=ice-pwd:6BhUWmqRRMuyJgJP8jwmBED6\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JpOHrKY7B4JG7oLTIhB42ybpv9aIUYZCM2q5Seus\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:905408483 cname:pvy8yvfED2pXzK1/\r\na=ssrc:905408483 msid:2C42I4QLCVkEvEo8b2ydLWGtRvY5Ikw7Hu7N a0\r\na=ssrc:905408483 mslabel:2C42I4QLCVkEvEo8b2ydLWGtRvY5Ikw7Hu7N\r\na=ssrc:905408483 label:2C42I4QLCVkEvEo8b2ydLWGtRvY5Ikw7Hu7Na0\r\nm=video 1 RTP/SAVPF 100 116 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:SzSsfdwx/XmvQmgz\r\na=ice-pwd:6BhUWmqRRMuyJgJP8jwmBED6\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JpOHrKY7B4JG7oLTIhB42ybpv9aIUYZCM2q5Seus\r\na=rtpmap:100 VP8/90000\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\n","type":"answer"}

[Mamadou]

I wrote my sample code quickly and there is a typo but the issue is
there.
I'm using chrome "25.0.1352.0 canary" on Windows Vista

1)
var o_webkitGetUserMediaHasType = { audio: true, video: true };

var o_MediaContraintsHasType = { audio: true, video: false };

this fails -> NOT EXPECTED otherwise explain why
online test: http://sipml5.org/tests/test_webrtc.html

2)

var o_webkitGetUserMediaHasType = { audio: true, video: false };
var o_MediaContraintsHasType = { audio: true, video: false };

this succeed -> EXPECTED

3)
var o_webkitGetUserMediaHasType = { audio: true, video: true };

var o_MediaContraintsHasType = { audio: true, video: true };

this fails -> EXPECTED as there is no video line in the answer
Adding ["m=video 0 RTP/SAVPF 100\r\n"] to the answer do not fix the
issue -> NOT EXPECTED but it's another bug in webrtc

On Dec 8, 12:32 am, Brave Yao <brave...@webrtc.org> wrote:
> Hi Mamadou
>
> This should be not be a problem of the different of mediaType in
> constraints to peerConnection and getUserMedia. I think the problem is in
> the Answer message.
> video:false in getUserMedia means no video sending out. And video:true in
> peerConnection means video receiving ok. So I suppose in the Answer you
> should still provide video capabilities. Below answer works in my test.
> One-way video session could be setup.
>
> S->C: {"sdp":"v=0\r\no=- 271651317 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0
> 0\r\na=group:BUNDLE audio video\r\nm=audio 1 RTP/SAVPF 103 104 0 8
> 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4

> 0.0.0.0\r\na=ice-ufrag:SzSsfdwx/XmvQmgz\r\na=ice-pwd:6BhUWmqRRMuyJgJP8jwmBE D6\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1

> AES_CM_128_HMAC_SHA1_80
> inline:JpOHrKY7B4JG7oLTIhB42ybpv9aIUYZCM2q5Seus\r\na=rtpmap:103
> ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8
> PCMA/8000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:905408483
> cname:pvy8yvfED2pXzK1/\r\na=ssrc:905408483
> msid:2C42I4QLCVkEvEo8b2ydLWGtRvY5Ikw7Hu7N a0\r\na=ssrc:905408483
> mslabel:2C42I4QLCVkEvEo8b2ydLWGtRvY5Ikw7Hu7N\r\na=ssrc:905408483
> label:2C42I4QLCVkEvEo8b2ydLWGtRvY5Ikw7Hu7Na0\r\nm=video 1 RTP/SAVPF 100 116
> 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4

> 0.0.0.0\r\na=ice-ufrag:SzSsfdwx/XmvQmgz\r\na=ice-pwd:6BhUWmqRRMuyJgJP8jwmBE D6\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1

[Brave Yao]

the case1 is actually same as case 3. The video:true in getUserMedia would override the video:false in peerConnection, which means if you are sending the steam, you must receive it. So in these two cases, you can't just remove the video part away from sdp.  As I remember, you can try sendonly and receiveonly in offer and answer.

[Mamadou]

I'm completely lost:
1) you said: "The video:true in getUserMedia would override the
video:false in peerConnection". Do you mean 'OfferToReceiveAudio' and
'OfferToReceiveVideo' are useless?
It looks like it's the case as the generated SDP contains "m=video"
line.
3) this is valid use case: if you propose audio+video the remote peer
can answer with audio-only by setting the video port value to zero.
RFC 3264 section 6: To reject an offered stream, the port number in
the corresponding stream in the answer MUST be set to zero.

PS: all is working as expected in chrome STABLE. Hope Google will not
break everything again.

[Brave Yao]

Hi,

As to 1), yes, I'm afraid that it's true.

As to 3), When you add the m line in the answer, maybe you should also add a corresponding rtpmap attr line, in RFC 3264, it also says "the answer MUST contain rtpmap attributes to define the payload type". I suppose you can refer the SDP from Canary under same circumstance a little bit, which might make the interop working easier.

Sorry for all the mess here. We're trying to be more RFC compatible. If you find anything  we violate the RFC we should follow, just feel free to file a bug to us. Your feedback is really appreciated!

[Mamadou]

are you sure this apply to rejected media?
The complete section is:
"In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer. Even if the
same
payload type number is used, the answer MUST contain rtpmap
attributes to define the payload type mappings for dynamic payload
types, and SHOULD contain mappings for static payload types"

In section 6 it's also said that if media is rejected then, "Any media
formats listed are ignored. At least one MUST be present, as
specified by SDP."
I don't see how it's possible to add rtpmap attributes if a format is
missing. In my example I'm preserving one format as required in the
RFC ["m=video 0 RTP/SAVPF 100\r\n"]
I don't remember any SIP client/server preserving the rtpmap
attributes (this is not science but...).

[Brave Yao]

Frankly, I'm not sure. I just want to find out why you would fail and I can succeed.

I tried your test-webrtc.html, test it with the original case, getUserMedia with video:false and peerConnection with video:true. And adds below string to reject video,

m=video 0 RTP/SAVPF 100 116 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:SzSsfdwx/XmvQmgz\r\na=ice-pwd:6BhUWmqRRMuyJgJP8jwmBED6\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JpOHrKY7B4JG7oLTIhB42ybpv9aIUYZCM2q5Seus\r\na=rtpmap:100 VP8/90000\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\n"

And it works.

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

onicecandidate = starting sdp_test.html:137

ICE COMPLETED sdp_test.html:139

setRemoteDescription ok sdp_test.html:144  //ok here

onopen sdp_test.html:156

onicecandidate = starting 

So I suppose the answer should corresponding all items in offer as rfc suggests.

[Mamadou]

In my case it fails because I'm not adding the rtpmap attributes and I
don't think it's required. IMHO is no reason to add attributes to a
disabled stream.
IMHO, "Any media formats listed are ignored" in section 6 means rtmap
attributes are useless and not required.
The section you were referring to is for general use case.
In your example, you are generating an answer with video stream
disabled but with rtpmap, ice, crypto, codecs... attributes. Strange
to make such effort for disabled media. In old specs this could make
sense as port=0 was used to hold a call.

On Dec 8, 3:50 am, Brave Yao <brave...@webrtc.org> wrote:
> Frankly, I'm not sure. I just want to find out why you would fail and I can
> succeed.
> I tried your test-webrtc.html, test it with the original case, getUserMedia
> with video:false and peerConnection with video:true. And adds below string
> to reject video,
> m=video 0 RTP/SAVPF 100 116 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4
> 0.0.0.0\r\na=ice-ufrag:SzSsfdwx/XmvQmgz\r\na=ice-pwd:

> 6BhUWmqRRMuyJgJP8jwmBED6\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=cr ypto:1

> ...
>
> read more »

[Brave Yao]

OK. I would check which is the proper way and update later.