Closed
Bug 931700
Opened 11 years ago
Closed 5 years ago
wrong raddr and rport in relay ice candidates
Categories
(Core :: WebRTC: Networking, defect, P5)
Tracking
()
RESOLVED
DUPLICATE
of bug 1215616
backlog | webrtc/webaudio+ |
People
(Reporter: philipp+bugzilla, Assigned: bwc)
References
Details
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.
Comment 1•10 years ago
|
||
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•10 years ago
|
||
I'll take the bug, but it will be some time before I can get to it.
Assignee: nobody → docfaraday
Updated•9 years ago
|
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Comment 4•7 years ago
|
||
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
Assignee | ||
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•