Re: [MMUSIC] Offer/Answer PT Questions - text proposal

[Colin Perkins <[e-mail]>]

Hi,

> On 25 Feb 2016, at 14:17, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
> I put together some text:
> 
> "The scope of a mapping from a particular dynamic payload type number to a codec 
> (or codec configuration) is for a given RTP media flow direction within a session. 

I think this conflicts with various RTP-related RFCs and drafts, although whether this conflict causes practical problems is unclear. RFC 3551 indicates that the binding between RTP payload type and RTP payload format is per RTP session, not per sender within an RTP session:

   mechanisms for defining dynamic payload type bindings have been
   specified in the Session Description Protocol (SDP) and in other
   protocols such as ITU-T Recommendation H.323/H.245.  These mechanisms
   associate the registered name of the encoding/payload format, along
   with any additional required parameters, such as the RTP timestamp
   clock rate and number of channels, with a payload type number.  This
   association is effective only for the duration of the RTP session in
   which the dynamic payload type binding is made.  This association
   applies only to the RTP session for which it is made, thus the
   numbers can be re-used for different encodings in different sessions
   so the number space limitation is avoided.

(note: reuse in different sessions, not different participants within a session) and:

   Session participants agree through mechanisms beyond the scope of
   this specification on the set of payload types allowed in a given
   session. 

which is again, agree the set of PTs for a session, not per participant.

RFC 3550 is unclear, and defers to RFC 3551, but suggests the payload type mapping is per RTP session:

   RTP media type: An RTP media type is the collection of payload
      types which can be carried within a single RTP session.  The RTP
      Profile assigns RTP media types to RTP payload types.

draft-ietf-avtcore-multi-media-rtp-session-13 (currently in the RFC Editor queue) says, in Section 7:

   Establishing a single RTP session using multiple media types requires
   signalling.  This signalling has to:

   1.  ensure that any participant in the RTP session is aware that this
       is an RTP session with multiple media types;

   2.  ensure that the payload types in use in the RTP session are using
       unique values, with no overlap between the media types;

draft-ietf-rtcweb-rtp-usage-25 says, in section 4.3:

   A single RTP payload type number MUST NOT be assigned to different
   RTP payload formats, or different configurations of the same RTP
   payload format, within a single RTP session (note that the "m=" lines
   in an SDP bundle group [I-D.ietf-mmusic-sdp-bundle-negotiation] form
   a single RTP session).

Finally, the allowable RTP payload type numbers depend on the RTCP packet types used in the session, since use of certain RTCP packet types prevents use of some RTP payload types when RTP and RTCP multiplexing is used. The allowable RTCP packet types are signalled per RTP session, also suggesting that the mapping is per session. 


> The same dynamic payload type number can be mapped to another codec in another RTP 
> media flow direction within the same session. The mapping MUST NOT change to a different
> coded (or coded configuration) for the duration of a session. Eventhough not recommended, 
> for a given direction, multiple dynamic payload type numbers can be mapped to the 
> same codec (or codec configuration). 
> 
> Note that a mapping has been created once an endpoint
> has sent and offer or answer, describing the mapping for a given direction. Even if the
> offer or answer is rejected or discarded, or if RTP media associated with the mapping is never
> sent, the mapping MUST NOT change for the given direction within the session.
> 
> Within an offer or answer, the mapping is for the RTP media flow direction towards the offerer/answerer,
> unless the media flow is indicated as 'sendonly' in which case the mapping is for the media flow direction
> from the offerer/answerer."
> 
> Note that the text probably needs some fine tuning, but please take a look and see whether you are ok with the approach, and whether you think the text covers the issues we've discovered.
> 
> Regards,
> 
> Christer
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic



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