Subject: Re: Sharing ports between "m=" lines [Was Re: [MMUSIC] Re: Question on sdp-new}

From: Flemming Andreasen <[email-masked]>
Date: Thu, 19 Jan 2006 09:54:33 -0500

Joerg Ott wrote:

>>> Let me briefly recap where this comes from:
>>>
>>> 1.  This practice was originally documented in the SDP offer/anser
>>>     examples draft.  The chairs felt that it was inappropriate to
>>>     document such behavior by example only and that some normative
>>>     language should be backing this since it was commonly felt a
>>>     useful thing to have.  The result is in the SDP spec.  There
>>>     was not much input though.
>>>
>> OK. Part of the input provided though raised some concerns with this.
>>
>>> 2.  When RFC2327 was done, there was only a single RTP profile defined.
>>>     Some profiles allow mixing in a session but SDP does not allow that
>>>     to be specified.  But we must also care of those applications that
>>>     do not use offer/answer.
>>>
>>> In principle, I am all in favor of solving this problem in a reasonable
>>> way and I do not care that much which way it is.  The present text in
>>> SDP was meant to reflect observed behavior.  This is why it is there.
>>> The text itself was meant to be rather minimalistic, so it may well
>>> have holes.  If so (and what you sat clearly points into that
>>> direction), we need to fix these (and of course your help is very
>>> welcome here :-)
>>>
>> I'll be happy to help out. Can we start out by clarifying exactly 
>> what the scope of the problem we want to solve here is ? Once we 
>> agree on that we can then look at appropriate solutions.
>
>
> I am afraid we have two scope issues here: one is the problem at hand
> and the other one is the fact that SDP-new has essentially cleared
> all hurdles towards being published.
>
> The ID tracker notes: "Ancient returning item: no longer has enough 
> ballot positions to advance. Mercy for these poor souls, new reviewers!"
>
> And indeed SDP-new seems to have entered this in mid 2003 (not sure
> where the record is).
>
> This means that we should craft our second scope carefully to allow
> for quick completion.  The task at hand seems twofold:
>
> 1.  Documenting the behavior of SIP endpoints that was previously
>     stated in the offer-answer examples draft.
>
> 2.  Defining semantics for the case that two m/c lines specify
>     the same transport address (which simply was omitted entirely
>     in SDP before).
>
> For 1., an interesting question is whether this behevior still exists.

Right. I took a look at the T.38, V.150, and V.152 specs (who were the 
suspected culprits here), and I didn't see it in either of those. I also 
asked one of the authors of those specs, and he indicated they did not 
add such  behavior (based on feedback received from AVT, however they 
would have liked to).

Another equally important thing to consider here is, that even if such 
behavior does exist in certain endpoints, but were never part of the 
spec, should you now make it part of the updated sdp-new spec ? If you 
do so, you all of a sudden run the risk of making a bunch of endpoints 
that worked and were compliant with RFC 2327 non-compliant with sdp-new. 
I think we would need pretty strong arguments for doing so.

> If it does not then one could argue that there is no point in
> documenting this in the first place and we are completely free how
> to make up 2.  Otherwise, the semantics for 2. must consider this.

Given this is not part of any existing spec I know, I think we have 
substantial degrees of freedom here, but backwards compatibility must be 
an important consideration.

> For 2., I would hope to stick with a minimal scope here:
> -- identification of "equal" media sessions
> -- defining their semantics and handling

That is one option. Another is to simply say, that using the same 
address for two different media lines is not part of the basic SDP 
semantics. We could then define a more explicit framework that would 
actually allow for "equal" media sessions to be specified as 
alternatives along with more elaborate rules (particular O/A rules).

>
> At first, we need to identify when two media sessions are
> considered "equal" (bearing in mind that if they are, they are
> supposed to indicate alternatives that may of course differ
> significantly in many attributes).
>
> This equality must obviously be based upon mandatory attributes
> defined in the SDP spec and must also allow for differentiation
> of session.  It looks like the triple (IP address, port number,
> media type) should do the job.  Obviously, one would need to
> mandate that the transport addresses need to be kept identical
> across o/a exchange (i.e., if they change they all need to change
> and if they were the same before, they all need to change to the
> same new value).
>
That's not clear to me. Let's say I start out by offering RTP/AVP and 
RTP/AVPF, and the answer indicates that AVP was accepted, whereas AVPF 
was not. Is there really a need to keep offering AVPF in subsequent O/A 
exchanges ? Having said though, I agree that you would need to keep the 
transport address in sync across the multiple alternatives if they were 
being included in subsequent offers. Again, I think there's an argument 
for a more explicit grouping of alternatives here than simply looking at 
the m= lines that have identical transport addresses, but it could work.

> Thinking of your considerations on a=sendonly and a=recvonly:
> You are allowed to put calls on hold and so this attribute
> may change during a sequence of o/a exchanges.  I would count
> this into a different category than the triple avove.
>
> Further thoughts on identification?

I like the capabilities I get by using the triple <IP address, port 
number, media type>, but it leaves open some issues, which I think the 
current sdp-new text was trying to avoid (and which you address below). 
For example, if I indicate RTP/AVP and RTP/SAVP as alternatives and I 
now receive a media packet, which profile is it actually encoded under ? 
Do payload type mappings have to be the same between these alternatives 
? In general, once I allow for quite a bit of variability in the 
parameters included in these alternatives, it becomes potentially 
problematic to use them not only outside offer/answer, but also within 
offer/answer if I want to support receiving media prior to receiving the 
answer.

>
> Defining their semantics is partly influenced by legacy.
>
> If there was no legacy, we could simply declare equal descriptions
> to be illegal and a reason for rejection.  Or we could treat them
> as a single media session that just happens to be signaling twice.
> This is probably independent of o/a.
>
Agreed.

> If no negotiation mechanism is available (e.g., when retrieving
> SDP via HTTP or announcing it via SAP), the media sessions must
> be compatible as there is no way to agree on one over the other

Agree again. Here, it becomes important that we accurately define what 
"compatible" means.

> .
> (This is obvious but may be worthwhile stating anyway).

> If a negotiation mechanism is available, we have presently either

> o/a or RTSP.  RFC2326 is in such a poor condition that any fix
> need not really be backward compatible because of the many holes
> and because rfc2326-bis get a new version number anway.  (a bit
> of pragmatism here)
>
> This leaves o/a as the major thing to deal with:
>
> If you are an offerer and want to indicate (without the grouping
> framework) two alternatives, you just do so, expecting that the
> peer will accept only one of these.  

Meaning it sets the port to zero for the other one, or it doesn't 
include it in the answer (presumably the former, although I think we'll 
need some text here to state what you do in either case plus the case 
where it is actually accepted) ?

> If it does, fine, you know
> what to do.  If the peer accepts none, ok as well.  If the peer
> accepts both, you can would need to re-INVITE and pick one anyway.
> The very same holds if the peer does not understanding grouping
> except that you notice this by the absence of the grouping
> attributes.

True.

>
> The quote from o/a below does not define what multiple streams are.
> An RTP session is defined by its target transport address(es).
> If you make reference to the same RTP session in two m/c lines this
> does not create another session either.  RFC 3264 does not say
> much about allowed or disallowed addresses except that multicast
> must be responded to with and multicast and unicast with unicast.
>
> But RFC3264 does say that, if multiple streams of the same type
> are offered, it is up to the local policy how these are mapped
> to cameras, mikes, etc.  Local interpretation is what is needed
> here.
>
> Please let me know what you think so we can craft some text here.

See above. To summarize:
- It is not clear to me that we really need to define the operation of 
multiple m= lines with the same transport address in sdp-new.
- I agree we very much need the capability to negotiate alternatives 
(incl. profiles) in SDP. Whether that should be done using m= lines with 
identical transport address or something else, as well as whether it 
needs to be part of sdp-new or not (and if so, whether it is a mandatory 
or optional part of it), is something that is less clear to me. I think 
it's worth taking a step back and consider the alternatives here.

I'd be interested in what other people think about all of this as well.

-- Flemming

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