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

"Roni Even" <ron.even.tlv@gmail.com> Tue, 04 June 2013 21:54 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD1621F8B21 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 14:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHk8I54otDK8 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jun 2013 14:54:23 -0700 (PDT)
Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 53AE021F8168 for <rtcweb@ietf.org>; Tue, 4 Jun 2013 14:54:05 -0700 (PDT)
Received: by mail-ee0-f52.google.com with SMTP id c50so231620eek.25 for <rtcweb@ietf.org>; Tue, 04 Jun 2013 14:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=J9i9JqJ4cA59pYQgUOD4fmcJ7krRgI+DBhyailTeF74=; b=toDo4zzn8ZomN/Hw2fDnSrV0P/K0ljsAyPKgVddYbV5j+2d9Y6DTDbFebeRHl4berV 5vwjCs7JNa8Gl9mJDurlWmOjrzpi1qtQtf6Y5erwACOV3FgxudfAGPhzXueME0CQtA7U 2OrI1k5lO2emdnjurLKq6CqXqDI6R1sdP+jhvi3IUw1DrKQ50qYuaLax2nA0+KXd9Y35 ikJIvLUKuFVa87Sz79HThn+QZz1r02erCzPney0EFqzNkEYxKoMi7ZryP8zgkP3/PVjB OxX/qclKCzX4DCms7P0fuhaCvOnVkUL+snBfSqP1cl6UiJMJA+5mVsYXaTm9VzFBZxtv RC6w==
X-Received: by 10.15.43.71 with SMTP id w47mr27790686eev.32.1370382845112; Tue, 04 Jun 2013 14:54:05 -0700 (PDT)
Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id f45sm15720548eeo.14.2013.06.04.14.54.03 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Jun 2013 14:54:04 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Bernard Aboba'" <bernard_aboba@hotmail.com>
References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> <51AC73EE.5080603@jitsi.org> <026201ce60a6$6d406f20$47c14d60$@gmail.com> <BLU404-EAS14250610902587788E9538F939E0@phx.gbl>
In-Reply-To: <BLU404-EAS14250610902587788E9538F939E0@phx.gbl>
Date: Wed, 5 Jun 2013 00:52:43 +0300
Message-ID: <02f901ce616d$dd664640$9832d2c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHEV3fVemrzw+HEHjK3xmr9l9tOLgGVpZeUAndJ7A4C03LtWJkDJ6Gw
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Plan - SDP offer/answer clarification
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 21:54:24 -0000

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