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

From: Joerg Ott <[email-masked]>
Date: Mon, 28 Nov 2005 09:38:18 +0200

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.

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 :-)

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

Grouping of m= lines is not necessarily backwards compatible in that
sense either.  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).

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

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.

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