Re: Issue 48 - latching rules

If sources 1001 and 2002 are sending simultaneously receiver r1 can have an issue producing a single track. If we are talking about source switching it can work but the distinction may not be obvious at an instant in time due to reordering since different sequence number spaces are involved and in the case of audio, no equivalent of the RFC 6190 Decoding Order Number (DON).



On Jan 26, 2015, at 3:09 PM, Robin Raymond <robin@hookflash.com<mailto:robin@hookflash.com>> wrote:


https://github.com/openpeer/ortc/issues/48


[RobinR]

Q: Does this match the expectations for WebRTC SDP requirements? I want to make sure what we produce can be made into a shim. Basically, if the WebRTC would cause an additional track to be output upon receiving the new 101 SSRC 2002 then our behaviour of routing to the same receiver object might be an issue since 1 receiver implies one output track.


[PeterT]

?I think you'd end up with another ssrc_table[packet.ssrc] entry. In other words, if you have RtpReceiver r1 and pt_table = {101: r1} and you receive? packet p1 = {pt: 101, ssrc: 1001} and p2? = {p1: 101, ssrc: 2002}, then you'd end up with a ssrc_table = {1001: r1, 2002: r1}, and both packets would get routed to r1.


-Robin