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

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 Dec 2005 11:56:13 -0500

Joerg Ott wrote:

> Flemming,
>
> sorry, I must have missed this thread earlier.

> 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.

>> We've had the discussion around whether to allow port (i.e. transport 
>> address) reuse between multiple media lines a few times in the past 
>> (e.g. the thread "Multiple 'm' lines with the same port number" in 
>> 2003/04), and various concerns were expressed around that. To recap, 
>> the major concerns were:
>>
>> 1. Backwards compatibility issues with RFC 2327 implementations which 
>> did not specify this .
>
>
> This was considered to be quite common practice and therefore
> documented.
>
Common among some endpoints perhaps, however that does not make it 
generally backwards compatible.

> Grouping of m= lines is not necessarily backwards compatible in that
> sense either.  

Agreed - especially once you get outside of SIP where you don't 
necessarily have an option tag to ensure support. Regardless, use of an 
option tag here is not necessarily desirable (e.g. consider the 
well-known forking scenarios with one endpoint supporting it and another 
that does not)

> But this calls
>
> (RFC2327 is fundamentally broken and did not specify much in the first
> place -- and we notice the brittleness of SDP over and over again,
> but this is a different story)
>
>> 2. Potential for multiplexing misuse when using different types of 
>> media streams on the same transport (e.g. audio and video)
>
>
> The present SDP text is supposed to prevent this as you state below.
>
>> 3. Consistency with RFC 3264 offer/answer procedures. For example 
>> 3264 states
>> <quote>
>>    If multiple media streams of the same type are present in an offer,
>>   it means that the offerer wishes to send (and/or receive) multiple
>>   streams of that type at the same time. </quote>
>> Other 3264 concerns have to do with matching of media streams in an 
>> updated offer/answer exchage (3264, Section 8).
>
>
> This is an important point and we have to take additional steps to
> ensure that o/a works in a backward-compatible way (which applies to
> the new grouping attributes that are popping up as well).
>
Agreed. We may want to be a bit more specific here as well. There is 
seamless backwards compatibility and there is backwards compatibility 
where you recognize that the other side did not support what you wanted 
and you need to take some kind of recovery action.

>> 4. Generally getting into a gray area of what this means. For 
>> example, can we now negotiate media streams with asymmetric codecs 
>> (one "m=" marked "sendonly", another marked "recvonly") ? How do we 
>> deal with all the other potential parameters that may differ between 
>> the two "m=" lines (fmtp parameters, RTCP bandwidth, etc.) ?
>
>
> The text should indeed be a bit more explicit here.
>
>> Taking a look at the concerns above, the added text does little to 
>> address any but the second one (and even there, it's not entirely 
>> clear what "compatible media" actually means, e.g. is T38 fax relay 
>> compatible with G.711 audio ?) In summary, I have serious concerns 
>> with the current text on this in sdp-new-25 and belive it should 
>> either be removed or reworked significantly.
>
>
> If you remove it that does not solve anything for those endpoints _not_
> doing o/a.  And it it was put in on purpose.  This means that we will
> have to rework the text to (and possibly parts of the overall approach)
> to address this.
>
OK, so if I can rephrase here: The updated SDP specification needs to 
have a solution to this problem so all implementations claiming 
conformance with it will support it (i.e. cannot just be an extension) ?

> Related to this is some discussion from the last IETF concerning
> groupings that are felt useful but not yet addressed:
>
> -- alternative RTP profiles for joint use and/or for exclusive
>    use (picking one)
> -- allowing multicast and unicast addresses to be specified as
>    alternatives (which ANAT does not allow for)
>
> There may be more but these are the ones that need solving.
>
OK. Again, can we write up a paragraph or two describing exactly what 
the scope of the problems we want to solve here are (for example, when 
we say alternative RTP profiles, do the two profiles in fact have to be 
different) ?

-- Flemming

> Any suggestions are surely welcome.
>
> Joerg
>
>> I do however support the general idea of trying to solve the problems 
>> that lead to the above text, but explicit signaling mechanisms (e.g. 
>> using grouping of media lines as Magnus suggested) and more extensive 
>> treatment of the issues above is needed for this IMO. If there is 
>> group and chair interest in this, I'd be happy to help out.
>>
>> -- Flemming
>>
>>
>> Colin Perkins wrote:
>>
>>> On 13 Oct 2005, at 19:47, Dan Wing wrote:
>>>
>>>>>> What do you mean by 'interoperate'?  My read of -avt-rtcp-
>>>>>> feedback-11 is
>>>>>> that both sides of an offer/answer would need to understand
>>>>>> the RTP/AVPF profile.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> See section 5 of draft-ietf-avt-rtcp-feedback-11.txt
>>>>
>>>>
>>>>
>>>>
>>>> Yes, I read that before responding.  But I'm still failing to 
>>>> grasp  how an
>>>> AVPF-unaware endpoint would do anything but reject an m= line  
>>>> containing
>>>> AVPF.  Specifically, if my offer says:
>>>>
>>>>   ...
>>>>   m=audio 49170 RTP/AVPF 0
>>>>   ...
>>>>
>>>> and the answerer only understands RTP/AVP, the answer will contain  
>>>> only "m="
>>>> for that media line (that is, that media line is rejected).  I'll  
>>>> have to
>>>> send another offer with RTP/AVP, under the assumption the reason 
>>>> it  was
>>>> rejected was AVPF.  This gets really messy
>>>>
>>>> It's the same problem of sending RTP/SAVP -- the answer won't  
>>>> understand
>>>> "SAVP" and will reject that media line.
>>>
>>>
>>>
>>>
>>> Sure, but since RTP/AVP and RTP/AVPF are compatible, you can offer  
>>> both with the same port, and have the receiver choose which to 
>>> accept  (per sdp-new-25 section 5.14). Not ideal, but I think it 
>>> solves this  case.
>>>
>>> Colin
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
>

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