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

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Oct 2005 21:31:34 +0100

Flemming,

I am certainly interested in a mechanism that allows alternatives, without
some of the restrictions imposed by the existing text.

John

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: 19 October 2005 20:07
> To: Colin Perkins
> Cc: Dan Wing; Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Sharing ports between "m=" lines [Was Re: [MMUSIC] 
> Re: Question on sdp-new}
> 
> 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 .
> 
> 2. Potential for multiplexing misuse when using different 
> types of media 
> streams on the same transport (e.g. audio and video)
> 
> 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).
> 
> 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.) ?
> 
> 
> I guess I missed the text that was added to sdp-new (in the 
> -21 version) 
> on this which currently (-25) reads:
> <quote>
>       1.  If two media sessions have the same transport address (i.e.
>           identical IP address and port numbers), the 
> associated payload
>           types (e.g. given in the "a=rtpmap:" attribute) 
> MUST NOT be in
>           conflict, i.e. the same payload type MUST NOT be mapped to
>           different media types.
> 
>       2.  If two media sessions have the same transport address, they
>           MUST use compatible media (e.g. both audio or both video).
> 
>       3.  If two media sessions have the same transport address, they
>           SHOULD operate under the same RTP profile.  The sessions MAY
>           use two different RTP profiles only if those profiles are
>           specifically designed to be compatible.
> 
>       4.  If two media sessions have the same RTP transport address,
>           they MUST also use the same RTCP address and vice versa.
> 
>       Two media sessions with the same transport address indicate
>       alternatives for the same media stream, i.e. all profiles, media
>       types, and payload types provided in any of the "m=" lines are
>       valid.
> </quote>
> 
> 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.
> 
> 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