Re: [rtcweb] No Plan

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

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: 04 June, 2013 8:30 PM
> To: Roni Even
> Cc: Emil Ivov; rtcweb@ietf.org
> Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
> 
> 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).
> 
> On Jun 3, 2013, at 3:11 PM, "Roni Even" <ron.even.tlv@gmail.com> 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
> > 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
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb