wrong raddr and rport in relay ice candidates

NEW
Assigned to

Status

()

Core
WebRTC: Networking
P5
normal
Rank:
45
5 years ago
8 months ago

People

(Reporter: Philipp Hancke, Assigned: bwc)

Tracking

27 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

Using https://apprtc.appspot.com, I see the following relay candidate in Nightly (27.0a1 2013-10-27) :
"C->S: {"type":"candidate","label":0,"id":"","candidate":"candidate:3 1 UDP 14745599 192.158.29.39 64878 typ relay raddr 192.158.29.39 rport 64878"}"


Actual results:

raddr and rport are wrong, being set to the ip address and port allocated by the TURN server.
This isn't bad, since those attributes are not used anywhere, it's merely a minor spec compliance issue.


Expected results:

http://tools.ietf.org/html/rfc5245#section-15.1 says the values for these should come from the mapped address attribute in the allocate response:
      is equal to the mapped address in the Allocate response that provided the client 
      with that relayed candidate

It's possible that currently this is taken from xor-relayed-addr instead of xor-mapped-addr given in the allocate response.
Byron, this is just a spec issue, but perhaps this is something we could fix next time we're in this code?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

4 years ago
I'll take the bug, but it will be some time before I can get to it.
Assignee: nobody → docfaraday
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Duplicate of this bug: 1012625
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.