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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 09 May 2013 15:55 UTC

Return-Path: <fluffy@cisco.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 C10BF21F8651; Thu, 9 May 2013 08:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.399
X-Spam-Level:
X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 ngHOuV1qCxRQ; Thu, 9 May 2013 08:55:47 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C219421F85E8; Thu, 9 May 2013 08:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2166; q=dns/txt; s=iport; t=1368114947; x=1369324547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x8zslPkmsuXnk0Tx6gT5XTo1DLjXW/+ywzfkF7er9Gs=; b=QDWWea99FVlmhsV9P608/VF3SOVHHFW8Vy7E+4krUvKpDSOXwG6RZURA OCDnrDOZ1n7bM8e2e1ReLhapbMvtoOsjazNGvkHnHdSgDPjHsL0+Vj+UN vKrbmH/7+xenhIcXJP4VrMzFvvOmoD+37CnoNkr+fp6LYAhrWE198OH+g A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0FAH7Gi1GtJV2Z/2dsb2JhbABSgwc3wAd6FnSCHwEBAQMBAQEBJEcLBQsCAQgiJCcLJQIEDgUIh34FAQy9egSOdQIxB4J0YQOoYYMPgic
X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208407207"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 May 2013 15:55:46 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r49Ftk0k011974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:55:46 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:55:45 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
Thread-Topic: [MMUSIC] Is bundle just a port override?
Thread-Index: AQHOTM2qLSobb9TZDkGuVuUzGWRiZA==
Date: Thu, 9 May 2013 15:55:45 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB1134DC72A@xmb-aln-x02.cisco.com>
References: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6942C3@xmb-rcd-x14.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.68.20.68]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <851923EC09F7454FBB300324ADEB3ACC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 09 May 2013 15:56:00 -0000

Mo, 

I think the key part of the grouping was it gave a way to say which m-line to use that still allowed that m-line to later be set to zero. I'm not saying the grouping adds much but keep in mind it is not really just the port you are selecting.  It's all the ICE transport stuff in the candidates so we would have to more than just a=port, you would also need the a=bundle-ice-candiaate and perhaps some DTLS info but I'm not sure. It seems something like this could work. not sure it would change too much. 

my 2 cents..


On Mar 18, 2013, at 9:19 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> 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?
>  
> 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