Re: [rtcweb] No Plan - SDP offer/answer clarification

[Emil Ivov <[e-mail]>]

Hey Roni,

On 04.06.13, 18:46, Roni Even wrote:
> Hi Emil,
> I get it what you call de-multiplexing is just selecting the right codec but
> not the decoding of individual streams which need to be handled by the SSRC.
> The SSRC is not needed only for mapping it to a different MediaStream it is
> needed also for decoding.

Why is that? Do you have in mind something like the case that Cullen 
described, where two different screens, each with its own codec chain, 
would need to render two different SSRCs that both have PT 99, H.264 PM=1?

If so then you'll simply need to tell this to the remote side with 
application-specific signalling.

> Yet  for the decoding you do not need to know the
> SSRC in advance

Yes. I don't. Therefore, I don't want the browser to make me send it. If 
you need it however, then sure, just transmit it with your own 
application-specific signalling. In a CLUE channel for example.

> and you suggest that the mapping between SSRC and
> MediaStream will not be done in SDP under the assumption that current
> systems will only support one audio and one video stream so multiple stream
> support is not required.

See above.

> The question will be what happens further down the road, I hope you are not
> saying that from now on the only systems will be based on WebRTC and there
> will not be any new SIP systems that will work end to end with a SIP
> application and support multiple streams.

Oh believe me, I am very, very far from saying that. The reason I am 
insisting on No Plan is exactly because I work on such non-WebRTC 
systems and I don't want my life to be harder than it should be.

> So there may be different ways to
> convey such information that will be application profile dependent and will
> require gateways. I think that CLUE is taking a different approach to map
> between the SSRC and the Media Captures using SDP and RTP/RTCP to provide
> the mapping and not an application channel.  CLUE does not require to know
> all SSRCs in advance, dynamic mapping from SSRC  to Media Captures proposal
> is to use RTP header extensions and RTCP SDES and not the CLUE channel to
> carry the mapping from SSRC to the CaptureID.  So the SDP can have static
> SSRC mapping when the SSRC are known. In both cases the assumption is that
> the m-line include all the pt numbers that will be used during the call even
> for new streams that will be added later.

OK, then I believe we are in complete agreement.

Emil


>> -----Original Message-----
>> From: Emil Ivov [mailto:[e-mail]]
>> Sent: 04 June, 2013 3:09 PM
>> To: Roni Even
>> Cc: [e-mail]
>> Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
>>
>> 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:[e-mail]]
>>>> Sent: 03 June, 2013 1:46 PM
>>>> To: Roni Even
>>>> Cc: [e-mail]
>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf Of Emil Ivov
>>>>>> Sent: 29 May, 2013 10:00 PM
>>>>>> To: [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>
>>>>>
>>>>
>>>> --
>>>> https://jitsi.org
>>>
>>>
>>
>> --
>> https://jitsi.org
>
>

-- 
https://jitsi.org