Subject: RE: [MMUSIC] Draft MMUSIC Minutes

From: "Orit Levin" <[email-masked]>
Date: Fri, 5 Dec 2003 17:35:27 -0800

I see your points. I just can say that:

1. It is really sad that none of us have time (including myself) to
specify this behavior in the upcoming standard.
2. Just "disallowing" it will not help! Implementers that are not
interested in the "mid" benefits will not read through all the possible
cases of the "mid" use and find out that it is actually "is allowed" and
can happen more often as the industry moves forward!!!

The basic SDP needs to specify how you act upon receiving this case.

Orit.

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2003 8:41 AM
To: Orit Levin
Cc: Joerg Ott; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Draft MMUSIC Minutes

Orit Levin wrote:

> Unfortunately, I couldn't participate in the last MMUSIC meeting.
> Reading the minutes, I found this one peculiar:
> ------------------
> * Semantics are undefined for multiple "m=" lines with the same port
>    and "c=" The interpretation should go into the SDP-new draft as a
>    clarification. There are minor implications on the offer-answer
>    examples. Gonzalo Camarillo <mailto:[email-masked]>
>    sent some text, but for a different case (hierarchical
>    encoding). Flemming Andreasen <mailto:[email-masked]> proposed
>    that we simply prohibit this construct. The meeting agreed to the
>    prohibition.
> -------------------
>
> I am wondering how can you allow for one particular application and
prohibit all the others?

We need to make it well-defined one way or the other. We had a thread on
this issue titled "Multiple 'm' lines with the same port number" at the
end of April 2003, where the general consensus seemed to be in-line with
the above.  The problem I have with the interpretation saying that you
*can* have multiple "m=" lines with the same address and port is that it
raises all kinds of issues that have not been dealt with. For example:
- Can I use different top-level MIME media types and/or transports for
these "m=" lines ?
- How does offer/answer deal with them ? Present text suggests that an
"m=" line corresponds to a media stream, however this suggests something
different.
- What about media stream parameters applied to one of these "m=" lines,
but not the other, or applied inconsistently ? For example, what if I
set one of them to "inactive" and the other to "sendrecv", specify one
SRTP key for of them, and another for the other, etc. What am I allowed
to do, what not, and what do I do if it is violated ?

The list goes on. In short, there is lot of issues that would need to be
dealt with before this would be well-defined and interoperable, and that
suggests strongly that it either was not implied by the original spec
(which the above referenced thread seemed to converge on) or was not
very well thought out. The end result is the same; I would not expect
old implementations to understand these semantics in any kind of
interoperable way and hence it should not be part of the updated spec
either (new functionality).

>
> For the existing implementations, that don't understand the fid
attribute and the associated grouping, it will appear exactly as the
same case.

That is different. Fid is an extension, not part of the core SDP spec.
Also, fid has specified ways of recognizing and recovering from
answerers that to does not support the extension.

-- Flemming

> Orit.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Sun, 7 Dec 2003 10:29:49 +0000

> The basic SDP needs to specify how you act upon receiving this case.

If changes are needed in SDP-new, please suggest text.

-- 
Colin Perkins
http://csperkins.org/

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 07 Dec 2003 16:02:10 +0200

Orit,

> specify this behavior in the upcoming standard.

The idea is not to add new functionality to SDPnew. The idea is to 
clarify existing functionality and fix known bugs. Multiples m lines 
with the same transport address (IP address plus port) were never 
allowed, and that is what SDPnew is going to clarify.

> The basic SDP needs to specify how you act upon receiving this case.

You will never receive an SDP with multiple m lines with the same 
transport address. Existing implementations don't do it, and future 
implementations will not do it either.

Regarding the grouping framework, it does not allow multiple m lines 
with the same transport address either. So, implementors do not need to 
read thru those specs either. This issue has nothing to do with the 
grouping framework.

Gonzalo