Why Chrome is not considering the SSRC that sipsorcery sends?

[timothyghanim]

So, running the WebRTCGetStarted example using the latest version of the library.

1. The SDP the library sends to Chrome contains the following lines: a=ssrc:978236180 cname:bbbc2e1c-fdc7-4368-a781-0d92b61c0a88 and a=ssrc:1549578042 cname:970aa059-be8e-4e2c-b1aa-b48c7343e24d.
2. However, when Chrome sends the ReceptionReport it sends the following sender SSRC 1 and the following SSRC for the RTP source being reported on 2622290420 which causes the library to ignore the RTCCompoundPacket because there was no 'appropriate remote track for SSRC for RTCP packet - Ssrc: 1'.

So, my question(s):

1. There seems to be something wrong here, no?
2. If Yes, then why is Chrome ignoring the SSRC values the library is sending in the SDP?

This is what the library sent:

v=0
o=- 79192 0 IN IP4 127.0.0.1
s=sipsorcery
t=0 0
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVP 0 8 9 18 101
c=IN IP4 0.0.0.0
a=ice-ufrag:EKMT
a=ice-pwd:AGEBJRWADRVLULSTAAUIYRYO
a=fingerprint:sha-256 AB:AA:84:A8:AB:BC:FB:F4:BF:42:56:AC:CE:81:B1:AC:88:C3:87:EB:BE:C1:2B:2A:57:DA:11:33:74:BB:E4:5B
a=setup:actpass
a=candidate:3687219128 1 udp 2113937663 192.168.1.10 54023 typ host generation 0
a=ice-options:ice2,trickle
a=mid:0
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtcp-mux
a=rtcp:9 IN IP4 0.0.0.0
a=sendrecv
a=ssrc:978236180 cname:bbbc2e1c-fdc7-4368-a781-0d92b61c0a88
m=video 9 UDP/TLS/RTP/SAVP 96
c=IN IP4 0.0.0.0
a=ice-ufrag:EKMT
a=ice-pwd:AGEBJRWADRVLULSTAAUIYRYO
a=fingerprint:sha-256 AB:AA:84:A8:AB:BC:FB:F4:BF:42:56:AC:CE:81:B1:AC:88:C3:87:EB:BE:C1:2B:2A:57:DA:11:33:74:BB:E4:5B
a=setup:actpass
a=ice-options:ice2,trickle
a=mid:1
a=rtpmap:96 VP8/90000
a=rtcp-mux
a=rtcp:9 IN IP4 0.0.0.0
a=sendrecv
a=ssrc:1549578042 cname:970aa059-be8e-4e2c-b1aa-b48c7343e24d

And this is what Chrome response:

v=0
o=- 1224950226988980318 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVP 0 8 9 101
c=IN IP4 0.0.0.0
a=ice-ufrag:amY6
a=ice-pwd:voAzM4D32k/KU1jF5b//WEwD
a=fingerprint:sha-256 25:F6:3D:8E:2D:64:79:A4:7C:49:50:7C:13:0A:5E:AF:88:1E:FD:1B:2D:F5:15:C1:E6:B6:50:91:0B:0B:7B:8E
a=setup:active
a=mid:0
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=rtcp:9 IN IP4 0.0.0.0
a=ice-options:trickle
a=rtcp-mux
a=recvonly
m=video 9 UDP/TLS/RTP/SAVP 96
c=IN IP4 0.0.0.0
a=ice-ufrag:amY6
a=ice-pwd:voAzM4D32k/KU1jF5b//WEwD
a=fingerprint:sha-256 25:F6:3D:8E:2D:64:79:A4:7C:49:50:7C:13:0A:5E:AF:88:1E:FD:1B:2D:F5:15:C1:E6:B6:50:91:0B:0B:7B:8E
a=setup:active
a=mid:1
a=rtpmap:96 VP8/90000
a=rtcp:9 IN IP4 0.0.0.0
a=ice-options:trickle
a=rtcp-mux
a=recvonly

And this is the RTCPCompoundPacket that Chrome sends

81C90007000000019C4CF9F450171B7619C4EE1932B74E0A7D299315F398CB38800000016C42D8196AA8CCEE7ED1

Which when parsed will have the following SSRC values: 1 and 2622290420.

[lostmsu]

I believe this is the issue causing https://github.com/sipsorcery-org/sipsorcery/issues/1109

The packet is parsed incorrectly, because it has ssrc 1, which causes SIPSorcery not to find the corresponding media stream, which causes the packet not to be decrypted.