Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

Hi,

Some people suggested that it should be allowed to send the same ports in the first offer, IF it is known that the answerer supports BUNDLE.

However, that is currently not described in the draft, and there were also objections to such approach.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Hadriel Kaplan&apos; [hadriel.kaplan@oracle.com]; Christer Holmberg [christer.holmberg@ericsson.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?
Hi Hadriel/Christer,

My understanding is that the initial offer with same port breaks more than
one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft
indicates one of the possible interop issue with existing mobile networks.
So, I don't agree with Hadriel claim of 99% system works with same port. The
current BUNDLE draft mechanism interop in the better way.

In case it is known to offerer that answerer supports BUNDLE before sending
offer, it is fine to send the same port in the offer using bundle-only
attribute. I'm not seeing any issue there.

Thanks
Partha

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, August 08, 2013 7:46 PM
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-
> only m- lines?
>
>
> On Aug 8, 2013, at 9:04 AM, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>
> > Another advantage of using different port numbers is that it provides
> a fallback in case the remote endpoint does not support, or does not
> want to use BUNDLE.
>
> Yes, except as far as I can tell all devices (and even intermediaries)
> handle an offer with the same port number just fine.  But that's just a
> personal observation, and dangerous to assume ALL of them handle it
> fine; that's why I didn't argue for long that we should use the same
> port number in the offer - because it concerned me that someone knew of
> at least one implementation that didn't handle it well. (not that we
> can truly accommodate ALL implementations anyway, but it's got to be a
> heck of a lot higher than simple majority, and as close to 100% as we
> can get)
>
>
> > However, for bundle-only m- lines such fallback is not needed - they
> are ONLY going to be used IF the remote endpoint chooses to use BUNDLE.
> > ...and, based on the agreed scope, the Offerer KNOWS that the remote
> endpoint supports BUNDLE, so the "one implementation that doesn't
> handle it" will not be there :)
>
> For WebRTC sure - but we were talking about using BUNDLE generically.
> Or at least that's what I thought you were asking about.  If we're only
> talking about using BUNDLE for WebRTC, then not only do you not need to
> use a port=0, but you also don't need a second offer/answer, etc.
>
>
> >> Also, from a purely protocol perspective, it seems quite logical to
> me to use a port number of 0 for an m-line you literally don't want to
> use if the far-end doesn't support
> >> BUNDLE - a port number of 0 effectively means "disabled" today, and
> that's basically what you want.
> >
> > Well, one could also say that it means "Here are some m- lines  I
> want to bundle, with this port, but only if you (the remote endpoint)
> wants to use bundle." :)
>
> We can certainly change the semantics of SDP offers with port=0 for
> WebRTC, but I think it would be really dangerous to change its
> semantics for general use.
>
>
> >> What I think should happen is the UAS should send an SDP answer
> using port=0 for those same m-lines, and the UAC should then send a new
> offer with those m-lines having the real port number of the bundle
> transport, and the far-end should answer that in the same fashion.
> >
> > The problem is that the grouping framework does not allow, in SDP
> Answers, usage of port=0 in grouped m- lines. It would require an
> update of the RFC, and I think we want to avoid that.
>
> Considering the number of docs the Unified-Plan proposes to either
> create, change, update or whatever... methinks having BUNDLE update the
> grouping framework RFC is rather a minor nit. :)
>
> -hadriel
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic