The typical SDP message
v=0
o=- 3376022867449415700 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS Jyup2XWPA5tOgvau9NIBMjlZFQzSEl6g3P0b
m=audio 57008 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 202.53.167.164
a=rtcp:57008 IN IP4 202.53.167.164
a=candidate:2068563606 1 udp 2122194687 192.168.10.148 57008 typ host generation 0
a=candidate:2068563606 2 udp 2122194687 192.168.10.148 57008 typ host generation 0
a=candidate:902314598 1 tcp 1518214911 192.168.10.148 0 typ host tcptype active generation 0
a=candidate:902314598 2 tcp 1518214911 192.168.10.148 0 typ host tcptype active generation 0
a=candidate:3083270405 1 udp 1685987071 202.53.167.164 57008 typ srflx raddr 192.168.10.148 rport 57008 generation 0
a=candidate:3083270405 2 udp 1685987071 202.53.167.164 57008 typ srflx raddr 192.168.10.148 rport 57008 generation 0
a=ice-ufrag:cinBWZB6tiSnOnf1
a=ice-pwd:50yVBGm5WuKlbZeyRrmjOvMn
a=ice-options:google-ice
a=fingerprint:sha-256 7C:69:84:B5:D5:C1:86:D0:56:8F:22:BA:5F:61:AD:1E:55:21:5A:6A:50:35:0C:49:E2:43:E9:C0:03:CC:B5:31
Any candidate priority is depends on the typical preference,local preference and component id with reference to RFC 5245
For RTP component id is 1,for RTCP component id is 2
so based on the component id the priority of the candidate is changed.
But in the above code sample why priority is same for different component id and same type of candidate.
Quoting from [RFC5245][1]
Notice the word SHOULD. Let us see what that means from [RFC2119][2]
Which means its not absolutely necessary to follow the algorithm precisely for calculating a candidate's priority. The algorithm can be modified if that is necessary. I think the SDP you have provided is that kind of a case. While calculating the priority they ignored the component ID of the candidate. [1]: https://www.rfc-editor.org/rfc/rfc5245#section-4.1.2 [2]: https://www.rfc-editor.org/rfc/rfc2119