Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

[Paul Kyzivat <[e-mail]>]

On 6/20/13 1:11 AM, Christer Holmberg wrote:
> Hi,
>
>>> *IF* you have a way to find the right m= line, couldn't PT X have
>>> different codec configurations in different m= lines?
>>
>> Yes, I think so.
>
> RTP seems to forbid it, though.

I just commented on that in a separate reply.
I can't find clear text about that.
But if that is the consensus interpretation, then I'm fine with that as 
long as then the bundle spec clearly specifies the implications of that 
on bundle usage.

>>> Let's assume that it could ... but then how would you know that your
>>> peer also supports the same demuxing technique as yourself?
>>
>> Muxing/demuxing (in the sense of associating to a particular m-line) MUST be consistent on both ends. (The sender knows which m-line he associates a packet with, and expects that the receiver will make the same association.)
>>
>> There must be enough signaling to get the two sides in sync about this.
>
> When it comes to PT values, each endpoint decides which PT values it wants to other endpoint to send.
>
> So, even if Alice uses the same PT value in multiple "m=" lines, and have some way to find the "m=" line when media is received, Bob can still assign unique PT values in each "m=" line.
>
> I don't think there is a requirement to have symmetric PT values in both directions, eventhough I know implementations often do that.

Yeah, you are right about that. But I don't think it changes the essence 
of what I am saying, at least for PT, since there is no question that 
both sides support the notion of PT.

Specifically, the answerer can look at the offer, and the answer it is 
planning to send, and it can determine if:
- the offerer will be able to associate any packet that might be sent
   to a specific m-line by use of PT alone.
- the answerer will be able to associate any packet it might receive
   to a specific m-line by use of PT alone.

And if it can't, and nothing else has been negotiated to assist in the 
association, then the answer is invalid. So then it will have to revise 
the answer before sending it.

>>> In SIP for example, when constructing a first offer, you may want to
>>> map both Opus and VP8 to 96, then add SSRCs for demuxing. This means
>>> that you expect your peer to support SSRC demuxing and you can't
>>> expect that unless we mandate it.
>>
>> In this case there will be two m-lines, one audio and one video, each using PT 96. And the offer specifies a specific ssrc for each m-line.
>>
>> If the answerer does't understand or support muxing by ssrc it will then note that if it accepted both m-lines it would not be able to associate packets with m-lines. So it then has two choices in constructing its answer:
>>
>> - reject the bundle, but accept both m-lines
>> - accept the bundle, but reject one of the m-lines.
>
> Again, my understanding is that the Offerer indicates which PT values it wants to RECEIVE. So, it it assigns the same PT value to both audio and video, it will receive the same PT value in the media packets.
>
> But, the Answerer can indicate different PT values for audio and video in the SDP Answer, and it will receive different PT values in the media packets.

I think I covered all the PT issues above.

But it may be a little harder than I suggest above to figure out if 
things are ok using ssrc, since a=ssrc only applies to what will be sent.

It works ok for the answerer deciding if he will be able to associate 
received packets to m-lines.

But for the answerer to decide if the offerer will be able to associate 
the packets it receives to m-lines, the answerer will need to know if 
the offerer supports using the ssrc to associate packets to m-lines.

The simplest thing I can suggest for that is that if the offer requires 
using ssrc for demux, then perhaps one can assume that the offerer is 
also prepared to use ssrc to demux on its end. Most of the time that 
would be a no-brainer.

	Thanks,
	Paul