Re: [MMUSIC] Query: payload type collision with offer/answer

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Harald Alvestrand
> Sent: Friday, January 11, 2013 4:47 AM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Query: payload type collision with offer/answer
> 
> On 01/10/2013 07:50 PM, Paul Kyzivat wrote:
> >
> >> Well there's also section 8.3.2 in 3264. The section is about updating
> >> offers but it seems like the text explicitly prohibits remapping payload
> >> types in any scenarios:
> >>
> >>     However, in the
> >>     case of RTP, the mapping from a particular dynamic payload type
> >>     number to a particular codec within that media stream MUST NOT
> >> change
> >>     for the duration of a session.  For example, if A generates an offer
> >>     with G.711 assigned to dynamic payload type number 46, payload type
> >>     number 46 MUST refer to G.711 from that point forward in any offers
> >>     or answers for that media stream within the session. However, it is
> >>     acceptable for multiple payload type numbers to be mapped to the
> >> same
> >>     codec, so that an updated offer could also use payload type
> >> number 72
> >>     for G.711.
> >
> > The language above is underspecified.
> >
> > It is my impression that the intent of this language was to ensure
> > there is no ambiguity in the meaning of a payload type. Since the
> > exchange of the SDP is not synchronized with the flow of RTP, if you
> > were to send a new SDP that changed the mapping for a payload type,
> > then the result would be almost certainly to interpret some media
> > packets according to the wrong mapping.
> >
> > But this argument is only about packets flowing in one direction. It
> > isn't a valid argument for requiring the payload types to be
> > consistent in the two directions. And its not clear to me that it even
> > intended that this language apply to both directions. It could be
> > clarified as follows:
> >
> >                               ...  For example, if A generates an offer
> >    with G.711 assigned to dynamic payload type number 46, payload type
> >    number 46 MUST refer to G.711 from that point forward in any offers
> >    or answers ***by A*** for that media stream within the session.  ...
> >
> > Interpreting it to apply to both directions brings it in conflict with
> > the language elsewhere that permits it to be different in the two
> > directions.
> More than one number for one codec is explicitly permitted.
> More than one codec for one number in a single direction is clearly
> impossible.
> More than one codec for one number in a single RTP session..... that's
> the question.
> 
> If one were to go with textual analysis, this would hinge on the meaning
> of "for that media stream" - which again hinges on whether a media
> stream is unidirectional or bidirectional.
> 
> RFC 3264's definition:
> 
>        Media Stream: From RTSP [8], a media stream is a single media
>           instance, e.g., an audio stream or a video stream as well as a
>           single whiteboard or shared application group.  In SDP, a media
>           stream is described by an "m=" line and its associated
>           attributes.
> 
> which points back to RFC 2326:
> 
>     (Media) stream:
>            A single media instance, e.g., an audio stream or a video
>            stream as well as a single whiteboard or shared application
>            group. When using RTP, a stream consists of all RTP and RTCP
>            packets created by a source within an RTP session. This is
>            equivalent to the definition of a DSM-CC stream([5]).
> 
> So if we believe these definitions, there's no prohibition on reusing
> the payload type.
> Definitely nice to clarify in a 3264bis.
> 
> >
> > The use of different mappings in each direction has been discussed
> > over the years, though I couldn't point you to where. IIRC one of the
> > reasons had to do with gatewaying to other protocols. But I can't
> > offer any details.
> >
> > Bottom line: IMO, in the weird case Harald described X ought to follow
> > Postel's Law and accept the answer from Y. But for the same reason I
> > would strongly discourage implementations from acting as Y did.
> >
> Seems like a conclusion.

Agreed, this would be a useful clarification to add as an update to RFC 3264.

Cheers,
Charles

> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic