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

Justin Uberti <juberti@google.com> Thu, 21 March 2013 05:11 UTC

Return-Path: <juberti@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD721F87D3 for <mmusic@ietfa.amsl.com>; Wed, 20 Mar 2013 22:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.277
X-Spam-Level:
X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, 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 AjTDaIpATcWj for <mmusic@ietfa.amsl.com>; Wed, 20 Mar 2013 22:11:39 -0700 (PDT)
Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id A500721F8821 for <mmusic@ietf.org>; Wed, 20 Mar 2013 22:11:32 -0700 (PDT)
Received: by mail-ia0-f182.google.com with SMTP id u8so2096845iag.27 for <mmusic@ietf.org>; Wed, 20 Mar 2013 22:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=n+8GNuWa1ReekamkcioQQX3DuG7LAxDUbGd0Jx9tVYw=; b=a6U+IEphxaIZ4Ar2nBf90Yyw5Sw91k9zSvM+roEBz/Arxib5lsEZHFzE4BGYb7VWTU 1GTOgoXSq9FKYzw9uTQ4x+4mGIf2UnwdCa/NOEeRNu8zq4S5Mc0TovUyZGAXmsF6CTOX cPx/wELZfJAHOFz8M9T8Kzed7/jqL10c69332fK8uV/GSgPE7WI/k97+ja4dbYaB8cqH Vo6J9g0tgoulW3ZaVur1cPLDyuXezJ2drkWuqqS91E8xWWbGdJgzhofDLsywPkYDbw8U a2ytpkhhSBD6lr5yb5nMNhyJE6d+OsUfmle2X7F3HYzPVV4x1IEy1R6Mqhd4G1ASO8z9 JGnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=n+8GNuWa1ReekamkcioQQX3DuG7LAxDUbGd0Jx9tVYw=; b=gLNfCIoXFXFgExD8CxzVs8V66ybGNGUybkZ2pL4ilgYBldclbI8YL9WRkpHCdYReh8 KA5PngUgsrm0Drz0VpHMS9lDMEGb1A1GvAGXB3gohi01GLftIEZXgNxZBzcicl+x+4bb Dcq+riduh0GvvxbXXsRdQzEBTt1A68r87d3tgfyyzx/s7nvr2Dz/1nSzZJOhA3oCiBOw N+PsTNW5nrnsNZoJTRjtl5N7HkntN9AHvh4SDbQgazQhV5fLyjfuROwcKtARm8tTXwY2 RDGaMr97zs9JNuuMlETltK1G3/IBe0ugQfbmAnK7TM/Z5tQ4KhZPGrB9Vz6ElCuZ/ePd A1Og==
X-Received: by 10.42.175.73 with SMTP id az9mr10595920icb.55.1363842692172; Wed, 20 Mar 2013 22:11:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.250.18 with HTTP; Wed, 20 Mar 2013 22:11:12 -0700 (PDT)
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com> <514829CE.4010004@alvestrand.no> <3879D71E758A7E4AA99A35DD8D41D3D90F694591@xmb-rcd-x14.cisco.com> <51489A43.3030109@jitsi.org> <3879D71E758A7E4AA99A35DD8D41D3D90F69476F@xmb-rcd-x14.cisco.com> <201303191936.r2JJakU4763611@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6951B8@xmb-rcd-x14.cisco.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 20 Mar 2013 22:11:12 -0700
Message-ID: <CAOJ7v-2eH9oy8=OWVyoUki5ALWSwaB8x_dwpYUDJ-rY_VJ--kw@mail.gmail.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Content-Type: multipart/alternative; boundary=90e6ba6e8f30326b3704d8685f8e
X-Gm-Message-State: ALoCoQmbVSggiG6ARiSzOe7HAq2l+tcJFlGte3dTt1eSHPH2iIR49fo/3e93+Yemc3CUrl1gx4ST3a7fWdDxi0mFJB+h+5isHUflPhTyNQnT1FUSlBRWYhYiI4VyUYj2wZCramcEmP5S2erio9mfOH4we60PWpcQxpxAFFwS/l2ULT6IhQVcYk2Am3K684+hRMljD54f1QmC
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Is bundle just a port override?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 05:11:40 -0000

The point of the different ports is not just to make intermediaries happy,
but to ensure that we're successful when talking to an endpoint who doesn't
support BUNDLE. There are a litany of problems that have been identified
when the same ports are used on the offerer side and the answerer is
BUNDLE-unaware.

On Wed, Mar 20, 2013 at 9:43 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com>wrote;wrote:

> Hi Dale,
>
> In your draft (and Richard's), I understand your motivation to answer with
> port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that sniff
> ports so they don't smell anything fishy. I won't comment on whether they
> will react better to nostril-plugging than fishy smells, because I don't
> know, but that is orthogonal to what I'm describing here.
>
> Your bundle alternatives (and Richard's) also work fine with a simple
> attribute without complex grouping semantics.
>
> 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 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
> a=port 40000
> ...so audio and video ports are 10000<->40000.
>
> Answer doesn't support the port override attribute, or doesn't want 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.
>
> Cheers,
> Mo
>
>
> -----Original Message-----
> From: Dale R. Worley [mailto:worley@ariadne.com]
> Sent: Tuesday, March 19, 2013 3:37 PM
> To: Mo Zanaty (mzanaty)
> Cc: emcho@jitsi.org; rtcweb@ietf.org; mmusic@ietf.org
> Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?
>
> > From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
> >
> > Those drafts use the SDP grouping framework
> > (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity
> > and ambiguity for something which can be solved in a much simpler
> > and clearer way with a single attribute: a=port <port>. (Or, if we
> > want to warn humans about RTP muxing, then name it a=rtp-mux:<port>,
> > but machines won't care about the name, and their RTP
> > implementations already know how to deal with muxing if they use
> > this attribute, so stronger warnings are unnecessary.)
> >
> > Regarding the concern about non-use of the discarded RTP ports
> > confusing SBCs, see this part of my original message [with
> > clarifications], which is what the current bundle draft also
> > suggests:
> >
> > > 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 [that may monitor the unused ports].
>
> It's messier than that, unfortunately.
>
> One requirement is that after negotiation is completed, the negotiated
> transport associations (as seen by a legacy intermediary) must match
> the actual media flows.
>
> Another requirement is that two media descriptions shouldn't use the
> same port (because a lot of legacy SBCs can't handle that).  This
> applies to offer/answer updates as well as original offers/answers.
>
> So what we want is a way for a media description to say, "I'm
> reporting port zero so SBCs think this MD is rejected, but I'm
> actually using port 1234 (which is officially reported in another
> MD)."
>
> There are also situations where the we want to signal perferences as
> to which media descriptions share ports with which other media
> descriptions.
>
> Dale
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>