Re: [rtcweb] Plan A, respun

[Paul Kyzivat <[e-mail]>]

On 5/8/13 11:47 AM, Martin Thomson wrote:
> This is a pretty complicated example, but I agree that it is quite relevant.
>
> If the camera that can produce Z is attached (to the
> RTCPeerConnection), then an offer would include X, Y and Z, but it
> would probably have to be marked sendonly.  Other m-lines could be
> used to offer to receive X and Y.
>
> I don't see this being solved very well by SDP at all.  Regardless of
> the option chosen.

There are multiple ways to skin this cat:

- there could be separate m-lines for sendonly and recvonly (and
   flipped at the peer). To be safe, you could make everything that
   way - no sendrecv m-lines. Each stream would be assigned to an
   m-line with the appropriate directionality. (But this doesn't
   work well if you want to change the directionality to reflect
   hold.)

- we could make the extension to support a=ssrc:nnn sendonly, etc.
   That way you can signal the directionality of each individual stream.
   Presumably in that case an a=sendonly/recvonly/... for the same
   m-line would apply to any ssrc's that didn't have their own.

	Thanks,
	Paul

> On 8 May 2013 06:06, Stefan Håkansson LK
> <[e-mail]> wrote:
>> One more question (and I think this one is applicable to Plan B as well). It
>> has to do with devices with HW encoders.
>>
>> If I have a system that supports video encoding and decoding of format X and
>> Y it is pretty obvious what the offer should look like.
>>
>> But if I add a camera that can also encode in format Z, what should the
>> offer look like?
>>
>> The camera would not decode, so for sendrecv m-lines format Z could not be
>> included in an offer.
>>
>> Does this mean that to utilize camera encoders (if the corresponding
>> decoders are not available in the system), we'd be limited to sendonly
>> m-lines?
>>
>> Stefan
>>
>>
>>
>> On 2013-05-08 14:38, Stefan Håkansson LK wrote:
>>>
>>> A couple of questions (and sorry for the rtcweb/webrtc centric
>>> perspective) for clarification:
>>>
>>> * How would the info about PC-track and PC-stream id's be conveyed (I
>>> assume the msid draft)?
>>>
>>> * What is your thinking regarding mapping between PC-tracks and m-lines?
>>> For example, if Alice's app initiates a session with two video
>>> PC-track's flowing to Bob's app, that would presumable create a session
>>> with two sendonly m-lines. If, at a later stage, Bob's app upgrades the
>>> session by sending three video PC-tracks to Alice's app. How would the
>>> Bob -> Alice video PC-tracks be allocated to the existing m-lines
>>> (becoming sendrecv), and how would pick which one to use a new m-line?
>>> E.g., would it be random, or should the app decide, and based on what in
>>> that case?
>>>
>>> Stefan
>>>
>>>
>>>
>>> On 2013-05-07 20:30, Adam Roach wrote:
>>>>
>>>> In order to facilitate discussion between the two SDP format
>>>> alternatives we're considering, I've put together a document that more
>>>> clearly spells out the Plan A approach as we originally envisioned it.
>>>> Note that this is a slightly different approach than Cullen outlined in
>>>> Orlando. I fear the Orlando approach may have suffered from its attempts
>>>> to incorporate some elements of Plan B in an attempt to appease
>>>> proponents of that approach; and, in doing so, lost some of its clean
>>>> architecture.
>>>>
>>>> The cleaned up, new-and-improved description of the Plan A approach is
>>>> available here:
>>>>
>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt
>>>>
>>>> Note that we've omitted discussion of glare reduction from that
>>>> document, as I believe that mid-session glare can be completely avoided
>>>> by applications implementing a set of non-normative behaviors. These
>>>> behaviors are described in the a separate companion document:
>>>>
>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt
>>>>
>>>> Thanks.
>>>>
>>>> /a
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>