• defines a new SDP attribute, 'bundle-only', which can be used to request that a specific "m=" section (and the associated media) be used only if kept within a BUNDLE group.
• updates RFC 3264 to also allow assigning a zero port value to an "m=" section in cases where the media described by the "m=" section is not disabled or rejected.
• defines a new RTCP SDES item, Media Identification ('MID'), and a new RTP SDES header extension that can be used to associate RTP streams with "m=" sections.
• updates by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension.
• updates by allowing an SDP 'group' attribute to contain an identification-tag that identifies an "m=" section with the port value set to zero.

• Assign a unique address:port to each bundled "m=" section following the procedures in , excluding any bundle-only "m=" sections (see below);
• Pick a bundled "m=" section as the suggested offerer-tagged "m=" ();
• Include SDP attributes in the bundled "m=" sections following the rules in ;
• Include an SDP 'group:BUNDLE' attribute in the offer; and
• Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the suggested offerer-tagged "m=" section.

• Include an SDP 'bundle-only' attribute () in the "m=" section, and
• Assign a zero port value to the "m=" section.

• The answerer is only allowed to include a BUNDLE group in an initial BUNDLE answer if the offerer requested the BUNDLE group to be created in the corresponding initial BUNDLE offer;
• The answerer is only allowed to include a BUNDLE group in a subsequent answer if the corresponding subsequent offer contains a previously negotiated BUNDLE group;
• The answerer is only allowed to include a bundled "m=" section in an answer if the "m=" section was indicated as bundled in the corresponding offer; and
• The answerer is only allowed to include a bundled "m=" section in the same BUNDLE group as the bundled "m=" line in the corresponding offer.

• In case of an initial BUNDLE answer, select the offerer-tagged "m=" section using the procedures in . In case of a subsequent answer, the offerer-tagged "m=" section is indicated in the corresponding subsequent offer and MUST NOT be changed by the answerer;
• Select the answerer-tagged "m=" section ();
• Assign the answerer BUNDLE address:port to the answerer-tagged "m=" section and to every other bundled "m=" section within the BUNDLE group;
• Include SDP attributes in the bundled "m=" sections following the rules in ;
• Include an SDP 'group:BUNDLE' attribute in the answer; and
• Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag indicates the answerer-tagged "m=" section ().

• Move the "m=" section out of the BUNDLE group (); or
• Reject the "m=" section ().

• Pick one bundled "m=" section as the offerer-tagged "m=" section. The offerer can pick either the "m=" section that was previously selected by the answerer as the offerer-tagged "m=" section or another bundled "m=" section within the BUNDLE group;
• Assign a BUNDLE address:port (previously negotiated or newly suggested) to the offerer-tagged "m=" section and to every other bundled "m=" section within the BUNDLE group;
• Include SDP attributes in the bundled "m=" sections following the rules in ;
• Include an SDP 'group:BUNDLE' attribute in the offer; and
• Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the offerer-tagged "m=" section.

• The offerer wants to move the "m=" section out of the BUNDLE group (), or
• The offerer wants to disable the "m=" section ().

• A specific payload type value can be used in multiple bundled "m=" sections only if each codec associated with the payload type number shares an identical codec configuration ().
• The proto value in each bundled RTP-based "m=" section MUST be identical (e.g., RTP/AVPF).
• The RTP MID header extension MUST be enabled by including an SDP 'extmap' attribute , with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value defined in this specification in each bundled RTP-based "m=" section in every offer and answer.
• A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=" sections.

• Construct a table mapping a MID to an "m=" section for each "m=" section in this BUNDLE group. Note that an "m=" section may only have one MID.
• Construct a table mapping SSRCs of incoming RTP streams to an "m=" section for each "m=" section in this BUNDLE group and for each SSRC configured for receiving in that "m=" section.
• Construct a table mapping the SSRC of each outgoing RTP stream to an "m=" section for each "m=" section in this BUNDLE group and for each SSRC configured for sending in that "m=" section.
• Construct a table mapping a payload type to an "m=" section for each "m=" section in the BUNDLE group and for each payload type configured for receiving in that "m=" section. If any payload type is configured for receiving in more than one "m=" section in the BUNDLE group, do not include it in the table, as it cannot be used to uniquely identify an "m=" section.
• Note that for each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps.

• If the MID associated with the RTP stream is not in the table mapping a MID to an "m=" section, then the RTP stream is not decoded, and the payload data is discarded.
• If the packet has a MID and the packet's extended sequence number is greater than that of the last MID update, as discussed in , update the MID associated with the RTP stream to match the MID carried in the RTP packet and then update the mapping tables to include an entry that maps the SSRC of that RTP stream to the "m=" section for that MID.
• If the SSRC of the RTP stream is in the incoming SSRC mapping table, check that the payload type used by the RTP stream matches a payload type included in the matching "m=" section. If so, associate the RTP stream with that "m=" section. Otherwise, the RTP stream is not decoded, and the payload data is discarded.
• If the payload type used by the RTP stream is in the payload type table, update the incoming SSRC mapping table to include an entry that maps the RTP stream's SSRC to the "m=" section for that payload type. Associate the RTP stream with the corresponding "m=" section.
• Otherwise, mark the RTP stream as "not for decoding" and discard the payload.

• If the RTCP packet is of type SDES, for each chunk in the packet whose SSRC is found in the incoming SSRC table, deliver a copy of the SDES packet to the "m=" section associated with that SSRC. In addition, for any SDES MID items contained in these chunks, if the MID is found in the table mapping a MID to an "m=" section, update the incoming SSRC table to include an entry that maps the RTP stream associated with the chunk's SSRC to the "m=" section associated with that MID, unless the packet is older than the packet that most recently updated the mapping for this SSRC, as discussed in .
• Note that if an SDES packet is received as part of a compound RTCP packet, the SSRC to "m=" section mapping might not exist until the SDES packet is handled (e.g., in the case where RTCP for a source is received before any RTP packets). Therefore, it can be beneficial for an implementation to delay RTCP packet routing, such that it either prioritizes processing of the SDES item to generate or update the mapping or buffers the RTCP information that needs to be routed until the SDES item(s) has been processed. If the implementation is unable to follow this recommendation, the consequence could be that some RTCP information from this particular RTCP compound packet is not provided to higher layers. The impact from this is likely minor when this information relates to a future incoming RTP stream.
• If the RTCP packet is of type BYE, it indicates that the RTP streams referenced in the packet are ending. Therefore, for each SSRC indicated in the packet that is found in the incoming SSRC table, first deliver a copy of the BYE packet to the "m=" section associated with that SSRC, and then remove the entry for that SSRC from the incoming SSRC table after an appropriate delay to account for "straggler packets", as specified in .
• If the RTCP packet is of type sender report (SR) or receiver report (RR), for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the SR or RR packet to the "m=" section associated with that SSRC. In addition, if the packet is of type SR and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the SR packet to the "m=" section associated with that SSRC.
• If the implementation supports the RTCP Extended Report (XR) and the packet is of type XR, as defined in , for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC. In addition, if the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC.
• If the RTCP packet is a feedback message of type RTPFB (transport-layer FB message) or PSFB (payload-specific FB message), as defined in , it will contain a media source SSRC, and this SSRC is used for routing certain subtypes of feedback messages. However, several subtypes of PSFB and RTPFB messages include a target SSRC(s) in a section called Feedback Control Information (FCI). For these messages, the target SSRC(s) is used for routing.
• If the RTCP packet is a feedback packet that does not include target SSRCs in its FCI section, and the media source SSRC is found in the outgoing SSRC table, deliver the feedback packet to the "m=" section associated with that SSRC. RTPFB and PSFB types that are handled in this way include:

  Generic NACK:

  (PT=RTPFB, FMT=1)

  Picture Loss Indication (PLI):

  (PT=PSFB, FMT=1)

  Slice Loss Indication (SLI):

  (PT=PSFB, FMT=2)

  Reference Picture Selection Indication (RPSI):

  (PT=PSFB, FMT=3)

• If the RTCP packet is a feedback message that does include a target SSRC(s) in its FCI section, it can either be a request or a notification. Requests reference an RTP stream that is being sent by the message recipient, whereas notifications are responses to an earlier request and therefore reference an RTP stream that is being received by the message recipient.
• If the RTCP packet is a feedback request that includes a target SSRC(s), for each target SSRC that is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with that SSRC. PSFB and RTPFB types that are handled in this way include:

  Full Intra Request (FIR):

  (PT=PSFB, FMT=4)

  Temporal-Spatial Trade-off Request (TSTR):

  (PT=PSFB, FMT=5)

  H.271 Video Back Channel Message (VBCM):

  (PT=PSFB, FMT=7)

  Temporary Maximum Media Stream Bit Rate Request (TMMBR):

  (PT=RTPFB, FMT=3)

  Layer Refresh Request (LRR):

  (PT=PSFB, FMT=10) .

• If the RTCP packet is a feedback notification that includes a target SSRC(s), for each target SSRC that is found in the incoming SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with the RTP stream with a matching SSRC. PSFB and RTPFB types that are handled in this way include:

  Temporal-Spatial Trade-off Notification (TSTN):

  (PT=PSFB, FMT=6) . This message is a notification in response to a prior TSTR.

  Temporary Maximum Media Stream Bit Rate Notification (TMMBN):

  (PT=RTPFB, FMT=4) . This message is a notification in response to a prior TMMBR, but it can also be sent unsolicited.

• If the RTCP packet is of type APP, then it is handled in an application-specific manner. If the application does not recognize the APP packet, then it MUST be discarded.

For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream (Section ). Furthermore, existing streams can be terminated by setting the port to zero (Section ). In general, a port number of zero indicates that the media stream is not wanted.

For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of the RTP and RTCP packets that will be sent by the offerer. By default, a port number of zero in the offer indicates that the stream is offered but MUST NOT be used, but an extension mechanism might specify different semantics for the usage of a zero port value. Furthermore, existing streams can be terminated by setting the port to zero (Section ). In general, a port number of zero by default indicates that the media stream is not wanted.

RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.

RFC 2543 specifies that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, if it would specify that the stream has been disabled. However, an extension mechanism might specify different semantics of the zero port number usage. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP is to be sent to the peer.

SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero.

SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero, but an extension mechanism might specify different semantics for including identification-tags that correspond to such "m=" lines.

Value:

15

Abbrev.:

MID

Name:

Media Identification

Reference:

RFC 9143

Extension URI:

urn:ietf:params:rtp-hdrext:sdes:mid

Description:

Media identification

Contact:

IESG (iesg@ietf.org)

Reference:

RFC 9143

Attribute name:

bundle-only

Type of attribute:

media

Subject to charset:

No

Purpose:

Request a media description to be accepted in the answer only if kept within a BUNDLE group by the answerer.

Appropriate values:

N/A

Contact name:

IESG

Contact e-mail:

iesg@ietf.org

Reference:

RFC 9143

Mux category:

NORMAL

• An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group and indicates the audio "m=" section as the suggested offerer-tagged "m=" section.
• An initial BUNDLE answer, in which the answerer accepts the creation of the BUNDLE group, selects the audio "m=" section in the offer as the offerer-tagged "m=" section, selects the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section.

• An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group and indicates the audio "m=" section as the suggested offerer-tagged "m=" section.
• An initial BUNDLE answer, in which the answerer rejects the creation of the BUNDLE group, generates a normal answer, and assigns a unique address:port to each "m=" section in the answer.

• A subsequent offer, in which the offerer adds a new bundled "m=" section (video), indicated by the "zen" identification-tag, to a previously negotiated BUNDLE group; indicates the new "m=" section as the offerer-tagged "m=" section; and assigns the offerer BUNDLE address:port to that "m=" section.
• A subsequent answer, in which the answerer indicates the new video "m=" section in the answer as the answerer-tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section.

• A subsequent offer, in which the offerer removes an "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group; indicates one of the bundled "m=" sections (audio) remaining in the BUNDLE group as the offerer-tagged "m=" section; and assigns the offerer BUNDLE address:port to that "m=" section.
• A subsequent answer, in which the answerer removes the "m=" section from the BUNDLE group, indicates the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section.

• A subsequent offer, in which the offerer disables (by assigning a zero port value) an "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group; indicates one of the bundled "m=" sections (audio) remaining active in the BUNDLE group as the offerer-tagged "m=" section; and assigns the offerer BUNDLE address:port to that "m=" section.
• A subsequent answer, in which the answerer disables the "m=" section, indicates the audio "m=" section in the answer as the answerer-tagged "m=" section, and assigns the answerer BUNDLE address:port to that "m=" section.