SDP send only on one side and receive only on the other side

[Francois Temasys]

Hi,

What I want to build is simple: One peer is send only (audio+video) the second is receive only.

I have been trying to change munge example to do it.

The main possibility I can see is to use the following sdp constraints:

var sdpConstraints = {
  'mandatory': {
    'OfferToReceiveAudio': false,
    'OfferToReceiveVideo': false
  }
};

But the sdp created is:

v=0

o=- 8108126897426929144 2 IN IP4 127.0.0.1

s=-

t=0 0

a=group:BUNDLE audio video

a=msid-semantic: WMS 1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq

m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:frtwD6Hq9h1XD6jy

a=ice-pwd:IuJX7vHY4ELqDIsUlPWsGjB/

a=ice-options:google-ice

a=fingerprint:sha-256 26:85:6C:16:11:62:F2:2A:90:CD:6F:DE:E4:C7:57:44:9E:BC:E5:2D:AE:F3:5C:0F:FD:3B:26:45:94:AF:25:DB

a=setup:actpass

a=mid:audio

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=sendrecv

a=rtcp-mux

a=rtpmap:111 opus/48000/2

a=fmtp:111 minptime=10

a=rtpmap:103 ISAC/16000

a=rtpmap:104 ISAC/32000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:106 CN/32000

a=rtpmap:105 CN/16000

a=rtpmap:13 CN/8000

a=rtpmap:126 telephone-event/8000

a=maxptime:60

a=ssrc:2476532855 cname:HYqHq1UHtvexr/7/

a=ssrc:2476532855 msid:1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq f5f2e2f5-bcc3-4568-b7c2-ec9f56d26fed

a=ssrc:2476532855 mslabel:1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq

a=ssrc:2476532855 label:f5f2e2f5-bcc3-4568-b7c2-ec9f56d26fed

m=video 1 RTP/SAVPF 100 116 117 96

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:frtwD6Hq9h1XD6jy

a=ice-pwd:IuJX7vHY4ELqDIsUlPWsGjB/

a=ice-options:google-ice

a=fingerprint:sha-256 26:85:6C:16:11:62:F2:2A:90:CD:6F:DE:E4:C7:57:44:9E:BC:E5:2D:AE:F3:5C:0F:FD:3B:26:45:94:AF:25:DB

a=setup:actpass

a=mid:video

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=sendrecv

a=rtcp-mux

a=rtpmap:100 VP8/90000

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 nack

a=rtcp-fb:100 nack pli

a=rtcp-fb:100 goog-remb

a=rtpmap:116 red/90000

a=rtpmap:117 ulpfec/90000

a=rtpmap:96 rtx/90000

a=fmtp:96 apt=100

a=ssrc-group:FID 3439947383 2459553587

a=ssrc:3439947383 cname:HYqHq1UHtvexr/7/

a=ssrc:3439947383 msid:1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq 85a93166-9055-46cf-98dc-65c4071de67e

a=ssrc:3439947383 mslabel:1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq

a=ssrc:3439947383 label:85a93166-9055-46cf-98dc-65c4071de67e

a=ssrc:2459553587 cname:HYqHq1UHtvexr/7/

a=ssrc:2459553587 msid:1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq 85a93166-9055-46cf-98dc-65c4071de67e

a=ssrc:2459553587 mslabel:1AWJbQ72HhOa4PJxK3zb1agb1r8IpQG9yfcq

a=ssrc:2459553587 label:85a93166-9055-46cf-98dc-65c4071de67e

Where I was expecting a sendonly. So how to get it sendonly?

But that is for the offer. According to this document: https://www.ietf.org/rfc/rfc3264.txt

6.1 Unicast Streams

   If a stream is offered as sendonly, the corresponding stream MUST be
   marked as recvonly or inactive in the answer.  If a media stream is
   listed as recvonly in the offer, the answer MUST be marked as
   sendonly or inactive in the answer.  If an offered media stream is
   listed as sendrecv (or if there is no direction attribute at the
   media or session level, in which case the stream is sendrecv by
   default), the corresponding stream in the answer MAY be marked as
   sendonly, recvonly, sendrecv, or inactive.  If an offered media
   stream is listed as inactive, it MUST be marked as inactive in the
   answer.

The answer for a sendonly is a recvonly. Right?

[Philipp Hancke]

2014-08-28 9:48 GMT+02:00 Francois Temasys <regn...@temasys.com.sg>:

Hi,

What I want to build is simple: One peer is send only (audio+video) the second is receive only.

I have been trying to change munge example to do it.

The main possibility I can see is to use the following sdp constraints:

var sdpConstraints = {
  'mandatory': {
    'OfferToReceiveAudio': false,
    'OfferToReceiveVideo': false
  }
};

But the sdp created is:

That rings a bell... https://code.google.com/p/webrtc/issues/detail?id=1553

I recently saw a bug related to sendonly/recvonly (not triggering onaddstream at the remote end). https://code.google.com/p/webrtc/issues/detail?id=2628 -- seems to be fixed in M38. For M37 you need to be careful about who sends the offer, it works in one direction but not the other.

[...]

Where I was expecting a sendonly. So how to get it sendonly?

Removing any audio tracks from the stream you attach should work. Or not attaching a stream at all.

[...]

answer.

The answer for a sendonly is a recvonly. Right?

Right.

[Francois Temasys]

I'm on M37.

If I do:

-Removing any audio tracks from the stream you attach should work. Or not attaching a stream at all.

It's likely to give me a recvonly not sendonly (and why would I want to send something empty?).

Thanks for directing me to these issues.

Francois

[Philipp Hancke]

2014-08-28 10:05 GMT+02:00 Francois Temasys <regn...@temasys.com.sg>:

I'm on M37.

If I do:

-Removing any audio tracks from the stream you attach should work. Or not attaching a stream at all.

It's likely to give me a recvonly not sendonly (and why would I want to send something empty?).

Point. That was for getting recvonly. I think there is also an issue for setting those constraints to false and not attaching a stream which generates a sessionpart only SDP which is odd...

[Vikas]

Its probably issue 3508, currently we have not implemented the "sendonly" where you have a stream and offerToReceive constraints is set to false. 

/Vikas