Skip to main content

5.1.2. Profile Names and Interoperability

5.1.2. Profile Names and Interoperability​

For media "m=" sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the "TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850] and MUST indicate one of these profiles for each media "m=" line they produce in an offer. For data "m=" sections, implementations MUST support the "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile and MUST indicate one of these profiles for each data "m=" line they produce in an offer. The exact profile to use is determined by the protocol associated with the current default or selected ICE candidate, as described in [RFC8839], Section 4.2.1.2.

Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles. For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media "m=" sections in a received offer:

  • Any profile in the offer matching one of the following MUST be accepted:

    • "RTP/AVP" (defined in [RFC4566], Section 8.2.2)
    • "RTP/AVPF" (defined in [RFC4585], Section 9)
    • "RTP/SAVP" (defined in [RFC3711], Section 12)
    • "RTP/SAVPF" (defined in [RFC5124], Section 6)
    • "TCP/DTLS/RTP/SAVP" (defined in [RFC7850], Section 3.4)
    • "TCP/DTLS/RTP/SAVPF" (defined in [RFC7850], Section 3.5)
    • "UDP/TLS/RTP/SAVP" (defined in [RFC5764], Section 9)
    • "UDP/TLS/RTP/SAVPF" (defined in [RFC5764], Section 9)

  • The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.

  • Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attributes. Note that lack of an "a=fingerprint" attribute will lead to negotiation failure.

  • The use of AVPF or AVP simply controls the timing rules used for RTCP feedback. If AVPF is provided or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr-int=0". Otherwise, assume that AVPF is being used in an AVP-compatible mode and use a value of "trr-int=4000".

  • For data "m=" sections, implementations MUST support receiving the "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles.

Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. This simplifies JSEP behavior, with minimal downside, as any remote endpoint that fails to handle such a re-offer will also fail to handle a JSEP endpoint's initial offer.

Last updated on