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

"Roni Even" <ron.even.tlv@gmail.com> Mon, 03 June 2013 22:11 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 20B3C11E812B for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 15:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 pcCStcIiFyb6 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 15:10:50 -0700 (PDT)
Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2611E8130 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 15:06:27 -0700 (PDT)
Received: by mail-ee0-f51.google.com with SMTP id e52so401335eek.38 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 15:06:27 -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=WPzdyRhDK4HwaWxVe/19R+3o/JWqOBOp2iNk77efwHw=; b=vgIoMC40cDApD4HoJTyO/vtnZkV4jX+qmUT/LwKlNElcH1np7Kjux5xcpkUr+6JQDP mAGWJUKab/hIS7GpNEmgZT3DKdXsj1fevG868HD4h+RyEZe8Iq+rvLNdmg1WEFuJtr39 GIjfzjmxlpgqqATKUAE6mmf1oOBRjHFZiLyFI7q+brzhoISrMEx957RNFq0gzxUfeFe3 YHFWZUQdusY+GpfTU1g1KRrgbsziMfyLYoCc8np0wetie2hZgSZPR02K8N5UF2cWFRzi vQUjg8zmIqTnXTCOsnDfvGCRl0x1vxXOVSNi4/qGwLbkBzm5ZNSptZ0erraWBpyS6jF4 wGNw==
X-Received: by 10.14.176.66 with SMTP id a42mr14200046eem.150.1370297186941; Mon, 03 Jun 2013 15:06:26 -0700 (PDT)
Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id s43sm87435679eem.13.2013.06.03.15.06.25 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 15:06:26 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Emil Ivov'" <emcho@jitsi.org>
References: <020e01ce6045$4b07dee0$e1179ca0$@gmail.com> <51AC73EE.5080603@jitsi.org>
In-Reply-To: <51AC73EE.5080603@jitsi.org>
Date: Tue, 4 Jun 2013 01:05:12 +0300
Message-ID: <026201ce60a6$6d406f20$47c14d60$@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+HEHjK3xmr9l9tOLgGVpZeUmSvwXdA=
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: Mon, 03 Jun 2013 22:11:11 -0000

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