Re: [rtcweb] No Plan

Hey Roni,

On 04.06.13, 01:05, Roni Even wrote:
> Hi Emil,
> My understanding is that you propose to de-multiplex by the pt number so you
> cannot have two rtp streams with the same payload type number

A PT number is only used to pick a codec/processing chain. Different 
SSRCs would then be used as an indication that packets belong to 
different RTP flows and that they have to end-up in different 
MediaStream-s and eventually <video> tags. This works with No Plan and 
it does not require that SSRCs be known in advance.

Does this answer your question?

Emil

> Roni
>
>> -----Original Message-----
>> From: Emil Ivov [mailto:emcho@jitsi.org]
>> Sent: 03 June, 2013 1:46 PM
>> To: Roni Even
>> Cc: rtcweb@ietf.org
>> Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
>>
>> Hey Roni,
>>
>> On 03.06.13, 13:29, Roni Even wrote:
>>> Hi,
>>> I read the draft and the email thread and I think I have similar
>>> questions to the ones Cullen made.
>>> My understanding was that the proposal is to  do one SDP offer/ answer
>>> exchange  and add remove streams using other means (not specified)
>>
>> Yes, this is exactly it.
>>
>>> I looked at the offer example is section 3 and it has
>>>
>>> a=max-send-ssrc:{*:1}                      // declaring maximum
>>>      a=max-recv-ssrc:{*:4}                     // number of SSRCs
>>>
>>> I have some clarifying questions?
>>>
>>> 1. Is the proposal to always offer max-send-ssrc=1?
>>>
>>> 2. What is the answer in this case can it be max-send-ssrc=4?
>>
>> The max-ssrc in the SDP was just an example for capabilities that the
> offerer
>> could add to SDP (could be useful for mobile devices for example). It is
> by no
>> means essential to the approach.
>>
>>> 3. If max-send-ssrc >1 in the answer and the m-line has, for example,
>>> support for H.264 and VP8 with max-send-ssrc=2  and de-multiplexing is
>>> based on pt number, it will require four pt in the m-line since there
>>> can be two
>>> VP8 or two H.264 RTP streams
>>>
>>>      m=video 5002 RTP/SAVPF 97 98 99 100
>>>      a=mid:video
>>>      a=rtcp-mux
>>>      a=rtpmap:97 VP8/90000
>>>      a=rtpmap:98 VP8/90000
>>>      a=rtpmap:99 H264/90000
>>>      a=rtpmap:100 H264/90000
>>> Is my understanding correct?
>>
>> Can you help me understand why you need the PT duplication? Is this just
> so
>> that you could understand distinguish between two sources? If so, then it
>> wouldn't be necessary.
>>
>> With No Plan you would just send:
>>
>>        m=video 5002 RTP/SAVPF 97 99
>>        a=mid:video
>>        a=rtcp-mux
>>        a=rtpmap:97 VP8/90000
>>        a=rtpmap:99 H264/90000
>>
>> If then you want to have one of the VP8 streams rendered on the left
> screen
>> and the other on the right, you will add this in application-specific
> signalling. A
>> web application could do this like this:
>>
>> {
>>       "leftSSRC": "1234",
>>       "rightSSRC": "5678"
>> }
>>
>> An WebRTC-to-SIP gateway could transform this into SDP or whatever that
>> target devices need.
>>
>> Does this answer your question?
>>
>> Emil
>>
>>
>>
>>>
>>>
>>> Roni
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>> Behalf Of Emil Ivov
>>>> Sent: 29 May, 2013 10:00 PM
>>>> To: rtcweb@ietf.org
>>>> Subject: [rtcweb] No Plan
>>>>
>>>> Hey all,
>>>>
>>>> Based on many of the discussions that we've had here, as well as many
>>>> others that we've had offlist, it seemed like a good idea to
> investigate a
>>>> negotiation alternative that relies on SDP and Offer/Answer just a
> little
>>> bit
>>>> less.
>>>>
>>>> The following "no plan" draft attempts to present one such approach:
>>>>
>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>>
>>>> The draft relies on conventional use of SDP O/A but leaves the
> intricacies
>>> of
>>>> multi-source scenarios to application-specific signalling, with
>>> potentially a
>>>> little help from RTP.
>>>>
>>>> Hopefully, proponents of Plans A and B would find that the
>>> interoperability
>>>> requirements that concerned them can still be met with "no plan". Of
>>> course
>>>> they would have to be addressed by application-specific signalling
> and/or
>>>> signalling gateways.
>>>>
>>>> Comments are welcome!
>>>>
>>>> Cheers,
>>>> Emil
>>>>
>>>> --
>>>> https://jitsi.org
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>
>> --
>> https://jitsi.org
>
>

-- 
https://jitsi.org