{"action":"created","issue":{"url":"https://api.github.com/repos/openpeer/ortc/issues/438","repository_url":"https://api.github.com/repos/openpeer/ortc","labels_url":"https://api.github.com/repos/openpeer/ortc/issues/438/labels{/name}","comments_url":"https://api.github.com/repos/openpeer/ortc/issues/438/comments","events_url":"https://api.github.com/repos/openpeer/ortc/issues/438/events","html_url":"https://github.com/openpeer/ortc/issues/438","id":142309909,"number":438,"title":"SSRC values should not be entered by the user","user":{"login":"ibc","id":16191,"avatar_url":"https://avatars.githubusercontent.com/u/16191?v=3","gravatar_id":"","url":"https://api.github.com/users/ibc","html_url":"https://github.com/ibc","followers_url":"https://api.github.com/users/ibc/followers","following_url":"https://api.github.com/users/ibc/following{/other_user}","gists_url":"https://api.github.com/users/ibc/gists{/gist_id}","starred_url":"https://api.github.com/users/ibc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ibc/subscriptions","organizations_url":"https://api.github.com/users/ibc/orgs","repos_url":"https://api.github.com/users/ibc/repos","events_url":"https://api.github.com/users/ibc/events{/privacy}","received_events_url":"https://api.github.com/users/ibc/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/openpeer/ortc/labels/1.1","name":"1.1","color":"0052cc"},{"url":"https://api.github.com/repos/openpeer/ortc/labels/propose-at-next-CG-meeting","name":"propose-at-next-CG-meeting","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":32,"created_at":"2016-03-21T10:34:15Z","updated_at":"2016-04-13T20:35:30Z","closed_at":null,"body":"Currently, if the user calls `RtpSender.send()` without setting specific SSRC values, the browser will choose them. This is fine. The problem is that, at that point, RTP negotiation is already supposed to be done so we cannot signal our SSRC. Even worse: `RtpSender` does not have a `getRtpParameters()` method that retrieves the effective parameters (including SSRC values chosen by the browser).\r\n\r\nThis basically means that the user (the JS) is required to manually set a random SSRC which IMHO is not very cool.\r\n\r\nNOTE: I do know that, given \"RTP Matching Rules\" the receiver may be able to somehow correlate received RTP packets, but that is not valid for all the cases (if I send two video tracks over two `RtpSenders` over the same `DtlsTransport` and choose the same PT value for both, the receiver won't be able to properly demux RTP packets belonging to both video streams, so SSRC values are required)."},"comment":{"url":"https://api.github.com/repos/openpeer/ortc/issues/comments/209637278","html_url":"https://github.com/openpeer/ortc/issues/438#issuecomment-209637278","issue_url":"https://api.github.com/repos/openpeer/ortc/issues/438","id":209637278,"user":{"login":"robin-raymond","id":2962646,"avatar_url":"https://avatars.githubusercontent.com/u/2962646?v=3","gravatar_id":"","url":"https://api.github.com/users/robin-raymond","html_url":"https://github.com/robin-raymond","followers_url":"https://api.github.com/users/robin-raymond/followers","following_url":"https://api.github.com/users/robin-raymond/following{/other_user}","gists_url":"https://api.github.com/users/robin-raymond/gists{/gist_id}","starred_url":"https://api.github.com/users/robin-raymond/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/robin-raymond/subscriptions","organizations_url":"https://api.github.com/users/robin-raymond/orgs","repos_url":"https://api.github.com/users/robin-raymond/repos","events_url":"https://api.github.com/users/robin-raymond/events{/privacy}","received_events_url":"https://api.github.com/users/robin-raymond/received_events","type":"User","site_admin":false},"created_at":"2016-04-13T20:35:30Z","updated_at":"2016-04-13T20:35:30Z","body":"@ibc I can sympathize.\r\n\r\nLet me try to address some of your concerns:\r\n1. A lot of the objects the WebRTC 1.0 WG has already adopted, so we want to be compatible with what 1.0 is doing; diverging would \"be bad\";\r\n2. Parameters do need to be transactional, but I do agree, some use cases might want to tweak some things on a smaller scale; but that needs to be use case driven (like all API features);\r\n3. The ORTC API was meant to be a \"minimal\" low-level subset of supported stuff; there's nothing restricting anyone from expanding the API for their own implementations but this is the required set to be cross compatible; thus it was designed minimal so that higher level \"simplifying\" libraries can be written;\r\n4. I agree on the ambiguity issue (as illustrated by your SSRC comment); FYI - that looks legal to me but I get your concern about ambiguous cases; we should define these or put them \"out of scope\";\r\n\r\n>A related issue is the fact that we don't have a getParameters() method in the RtpSender so the app is responsible of holding both RtpSender instances and their associated RtpParameters objects. This has been already discussed here and dismissed. I cannot understand the rationale of such a decision.\r\n\r\nLet me explain the logic. `getParameters()` as just returning what you put in originally set was deemed to add little value to justify expanding the \"minimal\" API set. Expanding `getParameters()` to return filled in SSRC was deemed not needed since programmer can specify those filled values if they care, or use auto routing via mux-id / rid. So that's how that decision came to be.\r\n"}}