Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description

[Cullen Jennings <[e-mail]>]

> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox <[e-mail]> wrote:
> 
> In general, this looks good.
> 
> I have one question, however.  What should happen if an RTP packet (without a MID) is received for a stream that has an existing mapping to an m= line, but whose PT is not valid for that m= line?
> 
> Should it
> 1. Cause the stream’s mapping to be moved to another m= line, if the received PT is in the payload type table for some other m= line?
> or 
> 2. Be an error?


Imagine a case where we have two sends call A and B and they each use one PT that is unique and go to different m lines on receiver C via a SFU.  Initially C get a packet from B with a given SSRC and the PT and creates a mapping for it. But imagine that A and B had an SSRC collision which they sort that out and A ends up having the SSRC that B initially used. If you don't have the PT override the SSRC, the packets are going to go to the wrong m-line because the PT points at the m-line A is using but the old SSRC incorrectly points at the m-line B is using. 

To put this a different way, if the packet has a mid, I think it is very clear the mid has to override the PT. Same for the PT. The mid is effectively just an extended PT. 

I'm not thinking to much about the case where SSRC is signalled in SDP but ignoring that case for a second, I think the really easy thing to specify, implement, and understand works is simply a priority order where roughly 

1) if you have mid, use that and latch the SSRC
2) if you have a unique pt, use that and latch the SSRC 
3) if you have a latched SSRC use that 

If you had signaled SSRC, guess I would insert that as step 1.5 of use that