Skip to content

Incorrect application/trickle-ice-sdpfrag #34

Description

@jech

Hi,

The WHIP client generates an SDP offer with the ice-ufrag and ice-pwd attributes in the first media section:

...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 103 104 107 108 109 114 115 116 117 118 39 40 45 46 98 99 100 101 119 120 121
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qiKa
a=ice-pwd:bcfs93hb/+ZLuUE2K50HVbkr
...

However, it generates an sdpfrag with the same attributes at the toplevel:

a=ice-ufrag:qiKa
a=ice-pwd:bcfs93hb/+ZLuUE2K50HVbkr
m=audio 9 UDP/TLS/RTP/SAVPF 0
a=mid:0
a=candidate:1937612317 1 udp 2113937151 40a192af-d71f-4cf2-b5b4-494a95dcf739.local 44501 typ host generation 0 ufrag qiKa network-cost 999
a=candidate:670660484 1 udp 2113939711 47da31ec-00cb-4c68-bc90-c403b203d8d8.local 45749 typ host generation 0 ufrag qiKa network-cost 999

This violates RFC 8840 Section 9, which says:

The "ice-pwd" and "ice-ufrag" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also appear at the beginning of all INFO request payloads, i.e., preceding all pseudo "m=" lines. If they were originally exchanged as media-level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions