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

[Christer Holmberg <[e-mail]>]

Hi,

Jumping in late - trying to catch up :)

>>>>> 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.

Even without BUNDLE, this is how you would do it if you offer multiple streams within a single m- line.

> 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

Correct.

(All other m- lines associated with the MMT group, that is)

> - 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.

Correct.

(All other m- lines associated with the MMT group, that is)

> 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?

Note that there are still some details (e.g. whether "RTP/AVP" is going to be used) that have to be sorted out, but something like this:

m=anytype 10000 RTP/AVP 0 8 97 31 32
a=mmtype: 0 audio
a=mmtype: 8 audio
a=mmtype: 97 audio
a=mmtype: 31 video
a=mmtype: 32 video
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

Then, you will use the SSRC attribute to identify the streams. But, we do need to define how to associate SSRCs with media types and/or payload types.

In one of your e-mails, you suggested to extend the mmtype attribute. That's for sure one possibility.

Regards,

Christer