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)

27 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED DUPLICATE of bug 1215616

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.
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
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
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
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.