Re: [rtcweb] [MMUSIC] Is bundle just a port override?

Harald Alvestrand <harald@alvestrand.no> Tue, 19 March 2013 09:03 UTC

Return-Path: <harald@alvestrand.no>
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 0D2E621F88A0; Tue, 19 Mar 2013 02:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.498
X-Spam-Level:
X-Spam-Status: No, score=-109.498 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 oDjY2lRMiC85; Tue, 19 Mar 2013 02:03:14 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2064321F88C6; Tue, 19 Mar 2013 02:03:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E48E139E16F; Tue, 19 Mar 2013 10:03:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jhcvenrtCol; Tue, 19 Mar 2013 10:03:11 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1A9FC39E04C; Tue, 19 Mar 2013 10:03:11 +0100 (CET)
Message-ID: <514829CE.4010004@alvestrand.no>
Date: Tue, 19 Mar 2013 10:03:10 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
Content-Type: multipart/alternative; boundary="------------070403010200000102090802"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?
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, 19 Mar 2013 09:03:16 -0000

On 03/19/2013 05:19 AM, Mo Zanaty (mzanaty) wrote:
>
> Does bundle imply anything beyond a simple port override of the m-line 
> port? If not, then why not just directly signal the port override in 
> an attribute without any grouping semantics?
>

No, it's not just a port override.

BUNDLE shoves things into the same RTP session, which means that one has 
to obey the rules for being in the same RTP session:
- Security done consistently
- RTCP-mux done consistently
- No SSRC collision
- No payload type collision
So it's a good deal more than just a port override.

Magnus argued in favour of a solution that inserted a multiplex layer, 
so that one could use the same ports but still have stuff in different 
RTP sessions, but that did not appeal to many.

> Offer to mux audio and video on the same port:
>
> m=audio 10000 RTP/AVP 0
>
> m=video 10002 RTP/AVP 31
>
> a=port 10000
>
> i=I really want 10000, but lied on the m-line for fear of confusing 
> you. Confused yet?
>
> Answer supports the port override attribute and agrees to mux audio 
> and video:
>
> m=audio 40000 RTP/AVP 0
>
> m=video 40000 RTP/AVP 31
>
> a=port 40000
>
> ...so audio and video ports are 10000<->40000.
>
> Answer supports the port override attribute but doesn't want to demux 
> on his end:
>
> m=audio 40000 RTP/AVP 0
>
> m=video 40002 RTP/AVP 31
>
> a=port 40002
>
> ...so audio ports are 10000<->40000 and video ports are 10000<->40002.
>
> Answer doesn't support the port override attribute, or doesn't want 
> either end to mux:
>
> m=audio 40000 RTP/AVP 0
>
> m=video 40002 RTP/AVP 31
>
> ...so audio ports are 10000<->40000 and video ports are 10002<->40002.
>
> Either end can re-offer without lies about ports on the m-line after 
> confirming the peer is not confused by muxing, if they want to avoid 
> confusing intermediaries.
>
> Has this approach been tried yet? Dismissed?
>
> Mo
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic