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

["Roni Even" <[e-mail]>]

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


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