And it`s no difference who create Offer or Answer in this scheme.
No difference what is the device, mobile or computer.
Result is always the same. 
I can provide any other information if needed.

P.S. Firefox (45 or 46) works properly. PC2 got audio&video from PC1.

Deleted: pc2.FF.png 108 KB

	pc2.FF.png 108 KB View Download

jansson@, can you take a look?

Hi,
If any info or testing needed, I'm always ready.
Thanks.

Could you please try https://webrtc.github.io/samples/src/content/peerconnection/pc1/ and see if it works for you?

What android device and camera are you using? Have you allowed use of the camera on the android device?

>see if it works for you?
Yes, it works.

>What android device
Device: Nexus 5X
Camera: front or rear not metter

>Have you allowed use of the camera
Yes of course I do. I told that all works fine if Firefox is used. It don`t works in Chrome when PC2 don`t have camera and so video=false is used for PC2.

Chrome versions on devices changed since my first post. Now they are:
PC1 (android): Chrome version 51.0.2704.81
PC2 (windows7 SP1 32-bit): Chrome version 51.0.2704.84 m
But above problem still remains.

Deleted: webrtc.test.jpg 521 KB

	webrtc.test.jpg 521 KB View Download

Same test but Firefox 46 is used.
As you can see at the photo PC2(windows) get video (and audio too) from PC1(android).

Deleted: webrtc.test.FF.jpg 602 KB

	webrtc.test.FF.jpg 602 KB View Download

I do not know how important this is for you for analysis but today I got the idea
to do reversed test, when PC1(windows) use video&audio=true and PC2(android) video=false audio=true. And it works fine (as expected).
So, I could be wrong that it`s android Chrome version bug. Now it looks like Chrome desktop version bug.
But, of course, make conclusions is to you.

Thanks.

Deleted: webrtc.test.reverse.jpg 584 KB

	webrtc.test.reverse.jpg 584 KB View Download

Have you set offerToReceiveVideo = 1 ?

https://github.com/webrtc/samples/blob/gh-pages/src/content/peerconnection/pc1/js/main.js#L49

It does this automatically if you have video locally.

offerToReceiveVideo was set to "true". I try to set to 1
But above problem still remains.

I attach photo with my debug info on PC2 side.

Deleted: pc2.debug.png 747 KB

	pc2.debug.png 747 KB View Download

Could you confirm that you have set it to 1 on both sides, not true?

I confirm that on PC1 it is now certainly set to 1 (see screen above). 
On PC2 it can`t be set to 1 because PC2 has no video input device, so it was set to false (see screen above). Now I also change it from "false" to "0" and IT`S WORKING !
OMG... how can this be... why I had no idea about this earlier...

Can you confirm that only "0/1" must be used and not true/false ?

The standard changed at one point so that OfferToReceive* became the _number of  streams to accept_ rather than yes or no (https://www.w3.org/TR/webrtc/). True or false should still work I reckon, a quick google search shows this style used to be supported.

dn, can you write up a small demo page that shows that OfferToReceive* = false is broken? If so that's probably a bug.

With all this said, I think OfferToReceive* is going away. hta@, comments?

phoglund@ the type has changed in the spec to long hence I do not see how a bool should continue to work. However regardless of the spec it seems like we have added back the bool style anyway but it just landed a couple of days ago in: https://codereview.chromium.org/2077323003/

The problem is in the SDP answer:

m=video 0 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98

The 0 here means "I refuse your offer".

This code path is triggered when you explicitly set "OfferToReceiveVideo: false" in the Create*Answer* call - you can see the "false" in the red circle marked PC2 above. This behavior is not well defined in the specs (and has never been), but I checked the code yesterday.

When PC2 sends OfferToReceiveVideo=false it means that PC2 refuses to receive video. This is not what you want, so you shouldn't do it. Just don't set it.

Note: Javascript's type magic will auto-convert between booleans and integers. So "true" should still work if "1" was intended.

> Note: Javascript's type magic will auto-convert between booleans and integers. So "true" should still work if "1" was intended.
Right, forgot about that ;)

Thanks for your work and comments.

So, Hmm... I`am again misunderstanding and very confused...
In my mind, when PC2 answer to PC1 "Offer" + "To" + "Receive" + "Video" sounds like "Hey PC1, I`m (PC2) heard your offer and my offer to you is to receive(true)/not to recieve(false) my video from me" (value true/false means will I (PC2) send my video or not).
According to hta`s comment it`s not so and means exactly the opposite and sounds like "OfferToTransmitVideo" param :) But in fact, everything is happening exactly as described by hta in his comment above ("OfferToTransmitVideo" = false)

But next. If "0" is "false" and "false" is "0" plus my situation above decribed in "Comment 15" when OfferToReceiveVideo = 0 (I refuse your offer) and why PC2 successfully got video from PC1 in that case ?
Now I have thinking only about "Where is the truth is ?". I don`t understand when + where(on which side) + what value I need to use.
Example - webinar. When video from broadcaster (lecturer) must recieve all participants but broadcaster (lecturer) himself not interested to recieve video from participants. In that case my opinion was:
- broadcaster send offer OfferToReceive* = true
- participants send answer OfferToReceive* = false

phoglund, according to hta`s comment, demo page still needed ? If so I need some time to do it.

OfferToReceiveVideo is a parameter that controls how the SDP is generated.
It is not, itself, part of the SDP offer or answer.

The specs don't help here, since the parameters have been removed from the specs.

Just don't set OfferToReceiveVideo on the answer, let the defaults kick in. Things will Just Work.

I understand that it`s only for SDP generation, a=video + a=audio sections and it`s is not sended anywhere.

If parameters was removed than how to control sending or not sending video or audio now ? Need to modify SDP by myself after it`s generation by createOffer() ?

Any comments ?

Thanks.

Read up on .muted, .enabled etc. Also, on the sending side, if you don't want to send audio for instance, just don't add audio tracks to the peer connection.

Closing this bug since it isn't about a bug. If you have any further questions, webrtc-discuss is the place to go.