Re: [MMUSIC] Offer/Answer PT Questions

Comment to used RTP terminology:
Should be tightly coupled to RFC 7656 in my understanding. We got know an agreed RTP terminology with that RFC.
Replacements in text:
=> "session" = "RTP session" (RFC 7656, § 2.2.2)
=> "media stream" = "(media) source stream" (RFC 7656, § 2.1.5) ???

With regards to notion "RTP media flow direction":
= "RTP media flow" is identified by the 2-tuple {SSRC, PT}, i.e. represents a subflow component of an "RTP stream" (given by SSRC; RFC 7656, § 2.1.10)
If this is the aimed semantic of an RTP media flow, then attribute "direction" might be obsolete because an "RTP stream" is inherently unidirectional (from RTP source towards RTP sink).

Regards,
Albrecht

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christer Holmberg
Sent: Donnerstag, 25. Februar 2016 15:29
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

And, just to clarify: the idea is that this text would update the existing text in Section 8.3.2 of RFC 3264 says the following:

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

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 February 2016 16:17
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

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. 
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
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

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