4 comments on “Anatomy of a WebRTC SDP (Antón Román)

  1. Hi,

    honestly I haven’t found prflx candidates in the tests I’ve done so far. Both Chrome and Firefox have code to deal with Peer Reflexive candidates so I understand they are using them in their ICE implementations. In google-ice it seems that prflx are not supported (at least that’s said in a comment in Chromium code). Maybe someone can give us more info about this.

    Just for the information of other readers, a peer reflexive candidate is discovered when the reply to a STUN connectivity check (a Binding Request) sent to a Server Reflexive candidate of the other peer has a MAPPED-ADDRESS (IP and/or port) different from any existing local candidate.

  2. Let me elaborate why I asked that question and get your feedback. I am trying to streamline ICE procedure by taking advantage of trickle ICE.

    The app has a media relay server (not TURN per se, but a “twice NAT”) and it inserts a port at this RS in both the O/A messages which do not contain any ICE candidates, including local addresses. Then the two end-points will do connectivity check on them, which will succeed and the media will flow. In that process, they will discover the other’s “server reflexive” addresses as peer reflexive addresses. If the both addresses are the same, then they will exchange their local addresses as well. Now they will do full connectivity test and if one of them succeed, then media will flow over this new connection, freeing up the relay server.

    The advantages are:
    1. Media can start to flow immediately, but the expensive relay server is freed up as soon as it can be.
    2. No time lost on STUN query
    3. Local address is not revealed if it is not of use and eliminating a potential threat vector.

    So, what do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *