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

From: "Roni Even" <[email-masked]>
Date: Mon, 3 Jun 2013 13:29:53 +0300

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)
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?

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?

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Emil Ivov
> Sent: 29 May, 2013 10:00 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Emil Ivov <[email-masked]>
Date: Mon, 03 Jun 2013 13:46:06 +0300

Hey Roni,

> exchange  and add remove streams using other means (not specified)

Yes, this is exactly it.

> 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.

> 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

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Tue, 4 Jun 2013 01:05:12 +0300

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
Roni

> From: Emil Ivov [mailto:[email-masked]]
> Sent: 03 June, 2013 1:46 PM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
> 
> Hey Roni,
> 
> > I read the draft and the email thread and I think I have similar
> > questions to the ones Cullen made.
offerer
> could add to SDP (could be useful for mobile devices for example). It is
by no
> means essential to the approach.
> 
> > 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
so
> that you could understand distinguish between two sources? If so, then it
> wouldn't be necessary.
> 
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"
> }
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 04 Jun 2013 15:09:01 +0300

Hey Roni,

> 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.

Emil

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Tue, 4 Jun 2013 19:46:00 +0300

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. Yet  for the decoding you do not need to know the
SSRC in advance 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.

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.  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.

Roni

> Sent: 04 June, 2013 3:09 PM
> To: Roni Even
> Cc: [email-masked]
> > 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.
> 
> >>> 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.
> >>
> >>> 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
> >> that you could understand distinguish between two sources? If so,
> >> An WebRTC-to-SIP gateway could transform this into SDP or whatever
> >> that target devices need.
> >>
> >>>> 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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Jun 2013 10:29:45 -0700

No. It just means that you cannot have two different codecs with the same PT on the same m line (without Bundle) or in any m-line (with Bundle).

---

From: Emil Ivov <[email-masked]>
Date: Tue, 04 Jun 2013 22:56:50 +0200

Hey Roni,

On 04.06.13, 18:46, Roni Even wrote:
> 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

See above.

> 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

OK, then I believe we are in complete agreement.

Emil

-- 
https://jitsi.org

---

From: "Roni Even" <[email-masked]>
Date: Wed, 5 Jun 2013 00:52:43 +0300

Hi,
It is a question about what de-multiplexing means. When I think about
multiplexing it means directing an RTP stream to a decoder (can be a DSP for
each RTP video stream that does both RTP and video decoding) so the
de-multiplexing is based not only on pt but also on SSRC but you do not need
to know the SSRC in the SDP.
Roni

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: 04 June, 2013 8:30 PM
> To: Roni Even
> Cc: Emil Ivov; [email-masked]
> No. It just means that you cannot have two different codecs with the same
> PT on the same m line (without Bundle) or in any m-line (with Bundle).
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 5 Jun 2013 07:45:48 -0500

On Tue, Jun 4, 2013 at 3:56 PM, Emil Ivov <[email-masked]> wrote:
> 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?
>
> 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
> 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.
[MB] Indeed. This is exactly why I really like No Plan.  I think it
provides CLUE much more flexibility in doing things in an optimal way
for the CLUE application.  CLUE has not yet finalized their signaling
solution - giving CLUE the flexibility to signal some stuff in the
CLUE channel as needed (versus SDP) is a much better option long term
for CLUE.   I don't have a detailed plan - otherwise, I'd submit it to
CLUE as an individual although personally, I don't think chairs should
have strong positions in a WG as it makes it much more difficult for a
chair to negotiate consensus since it's clear there is a bias for a
specific solution.  And, for the record, my comments here are as an
individual and I am not representing CLUE as a WG (as Paul is not
either in his comments).  Certainly, as a chair I will go with the
consensus of the CLUE WG.  [/MB]
>>> SSRCs
>>>>>>> negotiation alternative that relies on SDP and Offer/Answer just a
>>>>
>>>> little
>>>>>>
>>>>>> bit
>>>>>>>
>>>>>>> less.
>>>>>>>
>>>>>>> The draft relies on conventional use of SDP O/A but leaves the
>>>>
>>>> intricacies
>>>>>>
>>>>>> of
>>>>>>>
>>>>>>> they would have to be addressed by application-specific signalling
>>>>
>>>> and/or
>>>>>>>
>>>>>>> signalling gateways.
>>>>>>>
>>>>>>> Comments are welcome!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Emil
>>>>>>>
>>>>>>> --
>>>>>>> https://jitsi.org