Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan)

"Roni Even" <ron.even.tlv@gmail.com> Mon, 03 June 2013 22:34 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 5AAE711E811B for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 15:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 kLj7tnAgQH5D for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 15:34:29 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4320811E812E for <rtcweb@ietf.org>; Mon, 3 Jun 2013 15:29:00 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id o14so1709311eaj.35 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 15:28:59 -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=ZICQi42slqLYa20TOukU6MRxWgtt06RKkuVEK4QpQlw=; b=jcKcaoRe8QfJvsqaozFEjj7y3umGOuKfaiJCdr/ml5XTVC1AfTc9eQHYlEjH6BoI0I KMttcTTyRawZKIjruJPCVo65i1B0n1Go36du4cLoQOKFcO6umaH+fe7BTAuKOglIHvii R7s91AEk514zLHcq+PdJaz4eK+4Vud9AtAsn6wpcGLacaCe1JDExPuOMPzf45PDS0wL4 fgTQq6+LNBlv3mJ75pRNWD+64WoNFZ6dot7JTBHafY/zpqYObJTy/wHgH8DRZJEgmD/p a2dLzC1NOfjAqJG1g/GMuwWyNq14uzNk3zsZ7NaWxowavvM8+/NwHJoeI0lrtOi40f++ g6TQ==
X-Received: by 10.14.2.199 with SMTP id 47mr24378831eef.131.1370298539349; Mon, 03 Jun 2013 15:28:59 -0700 (PDT)
Received: from RoniE ([109.64.225.31]) by mx.google.com with ESMTPSA id g7sm87817863eew.15.2013.06.03.15.28.57 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Jun 2013 15:28:58 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Emil Ivov'" <emcho@jitsi.org>, "'Cullen Jennings \(fluffy\)'" <fluffy@cisco.com>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113528171@xmb-aln-x02.cisco.com> <51A8EAB7.8080206@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11352940B@xmb-aln-x02.cisco.com> <51ACD224.8080100@jitsi.org>
In-Reply-To: <51ACD224.8080100@jitsi.org>
Date: Tue, 4 Jun 2013 01:27:44 +0300
Message-ID: <026601ce60a9$935dca60$ba195f20$@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: AQKY1+pHnunKeTVQ57jkMHJdmrnDtABcFAfPAX32L6oBX6G4ywHAYU4IAr9kYt0CEayFy5dBR3yg
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Translating Plan A into No Plan (Was: No Plan)
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:34:41 -0000

Emil,
I assume that in the example of no-plan the m-video section should have
a=max-send-ssrc:{*:3} and a=max-recv-ssrc:{*:3}

I had the other thread about the de-mux but this also shows my question, the
document says " This specification uses demuxing based on RTP payload
types." But in this example they are not unique, you may have three RTP
streams with the same pt number to de-mux using only pt-number.  

If you use max-send-ssrc to indicate the number of send streams, if you add
a stream you need to update the max-send-ssrc

Roni

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: 03 June, 2013 8:28 PM
> To: Cullen Jennings (fluffy)
> Cc: rtcweb@ietf.org
> Subject: [rtcweb] Translating Plan A into No Plan (Was: No Plan)
> 
> Hey Cullen, Paul, all
> 
> On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote:
> > On 31.05.2013, at 12:23 PM, Emil Ivov <emcho@jitsi.org> wrote:
> >
> >> Certainly. Could you please post the SDP that you would like to see
> >> translated in a way that's compatible with "No Plan"?
> >>
> >> Emil
> >
> > We can start with the SDP in plan A
> 
> The example in "7.3. Many Videos" looks like a good start:
> 
> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3
> 
> Here it is:
> 
>     v=0
>     o=- 20518 0 IN IP4 198.51.100.1
>     s=
>     t=0 0
>     c=IN IP4 203.0.113.1
>     a=ice-ufrag:F7gI
>     a=ice-pwd:x9cml/YzichV2+XlhiMu8g
>     a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7
>     a=group:BUNDLE m0 m1 m2 m3
> 
>     m=audio 56600 RTP/SAVPF 0 96
>     a=mid:m0
>     a=rtpmap:0 PCMU/8000
>     a=rtpmap:96 opus/48000
>     a=ptime:20
>     a=sendrecv
>     a=rtcp-mux
>     [ICE Candidates]
> 
>     m=video 0 RTP/SAVPF 97 98
>     a=mid:m1
>     a=rtpmap:97 H264/90000
>     a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>     a=rtpmap:98 VP8/90000
>     a=sendrecv
>     a=rtcp-mux
>     a=bundle-only
>     a=ssrc:11111 cname:45:5f:fe:cb:81:e9
> 
>     m=video 0 RTP/SAVPF 97 98
>     a=mid:m2
>     a=rtpmap:97 H264/90000
>     a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>     a=rtpmap:98 VP8/90000
>     a=sendrecv
>     a=rtcp-mux
>     a=bundle-only
>     a=ssrc:22222 cname:45:5f:fe:cb:81:e9
> 
>     m=video 0 RTP/SAVPF 97 98
>     a=mid:m3
>     a=rtpmap:97 H264/90000
>     a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>     a=rtpmap:98 VP8/90000
>     a=sendrecv
>     a=rtcp-mux
>     a=bundle-only
>     a=ssrc:333333 cname:45:5f:fe:cb:81:e9
> 
> 
> An offer generated by a "No Plan" browser in this case would look
something
> like this:
> 
>     v=0
>     o=- 20518 0 IN IP4 198.51.100.1
>     s=
>     t=0 0
>     c=IN IP4 203.0.113.1
>     a=ice-ufrag:F7gI
>     a=ice-pwd:x9cml/YzichV2+XlhiMu8g
>     a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7
>     a=group:BUNDLE m0 m1
> 
>     m=audio 56600 RTP/SAVPF 96 0
>     a=mid:m0
>     a=rtpmap:96 opus/48000
>     a=rtpmap:0 PCMU/8000
>     a=ptime:20
>     a=sendrecv
>     a=rtcp-mux
>     [ICE candidates]
> 
>     m=video 56602 RTP/SAVPF 97 98
>     a=mid:m1
>     a=rtpmap:97 H264/90000
>     a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>     a=rtpmap:98 VP8/90000
>     a=sendrecv
>     a=rtcp-mux
>     [ICE candidates]
> 
> I. Talking to legacy
> 
> In case you need to talk to an actual legacy (as in widely deployed SIP)
> endpoint, the above would translate into a regular two-stream call. Both
Plan
> A and No Plan would lead to essentially the same result (if we accept that
> older endpoints won't throw an exception at the sight of 4 m= lines) so
not
> much to discuss here.
> 
> II. Talking to Plan A style endpoints
> 
> If you need to talk to a Plan A endpoint you basically have the following
> options:
> 
> 1. You use JavaScript to prettify the "No Plan" SDP and turn it into
something
> that looks like "Plan A". Not my favourite option, but I am sure some
would
> like to use it. Maybe vendors of Plan A equipment would even distribute JS
> libs that do this. It would basically all come down to generating one ssrc
> attribute and two additional m=lines and appending this to the existing
SDP
> string.
> 
> 2. The application retrieves SSRCs from the browser, adds additional
> application-specific signalling to it and then sends the whole thing to a
> signalling gateway. The gateway (which you would also have with Plan
> A) would convert the SDP into what it needs it to be.
> 
> The application specific signalling can look like this:
> 
> {
>      "firstStream":
>      {
>          "SSRC": "11111",
>          "CNAME": "45:5f:fe:cb:81:e9"
>      },
>      "secondStream":
>      {
>          "SSRC": "22222",
>          "CNAME": "45:5f:fe:cb:81:e9"
>      },
>      "thirdStream":
>      {
>          "SSRC": "333333",
>          "CNAME": "45:5f:fe:cb:81:e9"
>      },
> }
> 
> 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP with
the
> help of .content properties. If browser vendors are willing to implement
> support for this then I suppose it would be a third option.
> 
> III. Talking to other WebRTC applications
> 
> This is the fun case and the one we should be most concerned with. Let's
> imagine that the answerer needs to add a fourth video stream. To make this
> work endpoints would need to do the following:
> 
> a) with Plan A and draft-roach-rtcweb-glareless-add:
>     - send application specific signalling to the offerer
>     - have a new O/A exchange
> 
> b) with Plan A:
>     - have a new O/A exchange
>     - potentially risk glare with some impact on user experience
> 
> c) with No Plan:
>     ... nothing
> 
> I am intentionally not going into how all plans would require additional
> metadata that would place SSRC 1 left and 2 right as I don't think this
conveys
> any meaningful differences.
> 
> Comments on the above are welcome. We could also move to another
> scenario from the Plan A draft, if you believe that 7.3 is not
representative
> enough.
> 
> Emil
> 
> 
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb