Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?

[Harald Alvestrand <[e-mail]>]

On 10/12/2012 12:15 PM, Stach, Thomas wrote:
> Harald Alvestrand wrote:
>> On 10/12/2012 09:58 AM, Stach, Thomas wrote:
>>>>> I think we should continue to use RFC 5576 for this purpose:
>>>>>
>>>>> a=ssrc:1 <something follows>
>>> I haven't thought about that, but yes it would work for as well.
>>> For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it
>>> would look like this?
>>>
>>>      a=rtpmap:0 PCMU/8000
>>>      a=rtpmap:8 PCMA/8000
>>>      a=rtpmap:97 iLBC/8000
>>>      a=mmtype: 0 audio
>>>      a=mmtype: 8 audio
>>>      a=mmtype: 97 audio
>>>      a=ssrc:12345 fmtp:0
>>>      a=ssrc:12345 fmtp:8
>>>      a=ssrc:67890 fmtp:97
>> Yes, except that as far as I can tell from RFC 5576, you
>> can't use fmtp:
>> without an actual parameter value: "This parameter MUST only
>> be used for
>> media
>>      types for which source-level format parameters have
>> explicitly been
>>      specified". (section 6.3).
>>
>> If you need to use a field that's always present, use CNAME.
>>
>> Note(1): If you only use one payload type for all your audio,
>> you have
>> no need to signal which format they're using.
>>
>> Note(2): In the above, you have ssrc 12345 using both PCMU/8000 and
>> PCMA/8000. I don't know if it's intentional or not.
>>
> Yes, this was intentional,
> I used two different ssrc (12345, 67890) in order to indicate that I want to establish two audio streams.
> I used ssrc=12345 twice in order to give a hint that the first audio stream should either use PCMU or PCMA (and ssrc=12345).
> The second audio stream would use ssrc=67890 and iLBC.
>
> However from your responses I'm not sure if we are on the same page with respect to what I want to achieve.
> Let me tray to clarify.
>
> My understanding is that
> - the m=anymedia gives a complete description of what is offered,
> - if the answerer understands m=anymedia, it accepts the m=anymedia line and rejects all other m-lines
> - if the answerer understands m=anymedia, it can ignore all other m-lines in the SDP, it doesn't even have to look at them in order to build its answer.
>
> If this is correct, consider an SDP offer with e.g. 4 m-lines (2 audio+2 video)
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>         t=0 0
>         m=audio 10000 RTP/AVP 0 8
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         m=audio 10002 RTP/AVP 97
>         a=rtpmap:97 iLBC/8000
>         m=video 20000 RTP/AVP 31
>         a=rtpmap:31 H261/90000
>         m=video 20002 RTP/AVP 32
>         a=rtpmap:32 MPV/90000
>
> How would the associated m=anymedia line look like in this case, such that the answerer can see
> that 2 audio and 2 video streams are offered without having to look into the other m-lines?
This offer does not guarantee that there are only 2 audio and 2 video 
streams.
It makes it a fair assumption that there are at least 2 of each (unless 
some of the m-lines are intended to be used for receiveonly), but it is 
perfectly legal to send more than one audio stream in each RTP session 
under each M-line.

So I don't think the starting point you're starting from is correct; 
until draft-westerlund-mmusic-max-ssrc or something like it is accepted, 
you have no way to tell *now* how many streams you are going to get.