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
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: [MMUSIC] Is bundle just a port override?
Precedence: list

Mo,=20

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 sayi=
ng the grouping adds much but keep in mind it is not really just the port y=
ou are selecting.  It's all the ICE transport stuff in the candidates so we=
 would have to more than just a=3Dport, you would also need the a=3Dbundle-=
ice-candiaate and perhaps some DTLS info but I'm not sure. It seems somethi=
ng like this could work. not sure it would change too much.=20

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 po=
rt? If not, then why not just directly signal the port override in an attri=
bute without any grouping semantics?
> =20
> Offer to mux audio and video on the same port:
> m=3Daudio 10000 RTP/AVP 0
> m=3Dvideo 10002 RTP/AVP 31
> a=3Dport 10000
> i=3DI really want 10000, but lied on the m-line for fear of confusing you=
. Confused yet?
> =20
> Answer supports the port override attribute and agrees to mux audio and v=
ideo:
> m=3Daudio 40000 RTP/AVP 0
> m=3Dvideo 40000 RTP/AVP 31
> a=3Dport 40000
> =85so audio and video ports are 10000<->40000.
> =20
> Answer supports the port override attribute but doesn=92t want to demux o=
n his end:
> m=3Daudio 40000 RTP/AVP 0
> m=3Dvideo 40002 RTP/AVP 31
> a=3Dport 40002
> =85so audio ports are 10000<->40000 and video ports are 10000<->40002.
> =20
> Answer doesn=92t support the port override attribute, or doesn=92t want e=
ither end to mux:
> m=3Daudio 40000 RTP/AVP 0
> m=3Dvideo 40002 RTP/AVP 31
> =85so audio ports are 10000<->40000 and video ports are 10002<->40002.
> =20
> Either end can re-offer without lies about ports on the m-line after conf=
irming the peer is not confused by muxing, if they want to avoid confusing =
intermediaries.
> =20
> Has this approach been tried yet? Dismissed?
> =20
> Mo
> =20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic