Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

Hi,

>>> The different port number issue arises in multiple contexts here.  
>>> Firstly, it arises within the dependency grouping.  RFC 6190 allows 
>>> layers to use different ports as well as allowing multiple layers to 
>>> be sent to the same port. While the SDP example in RFC 6190 (which I 
>>> copied) shows different ports being offered, in practice, I believe that H.264/SVC implementations typically prefer using the same port.  However, using the same port in an SDP offer can cause answerers to reject the SDP as invalid, which is >>>presumably why that approach was chosen for the RFC 6190 example. So the potential solution is to offer different ports, and have the answer respond with the same port.
>> That is what Harald's original TOGETHER proposal was all about, and where I had issues (related to intermediares who assume that the offered ports are used, and if the offer wants to set the multiplex port to zero).
>>
>> So, IF people think that offering the same port will cause problem, and IF people think that an m=bundle m- line would be removed, maybe the only option is to have 2 offer/answers: the first is a "normal" offer, with different ports, and if the answerer >>indicates that it supports bundle then the second offer will be sent with the same port.
>If "m=bundle m-line is removed" means "we'll negotiate the old style session with old equipment", then that's a success, not a failure.

Agree. There would be no multiplexing, but the session establishment would still succeed.

Regards,

Christer

> On Aug 25, 2012, at 7:28, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>
>> On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
>>> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>>>
>>>> Harald said:
>>>>> Bernard, since I'm so easily confused by how people transmit 
>>>>> layers of layered codecs, can you illustrate the particular scheme 
>>>>> you want to use, and can't think of how to represent in Jonathan's scheme?
>>>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency 
>>>> in SDP". An example of how this would be used with H.264/SVC is included in RFC 6190, Section 7.3.4:
>>>>
>>>>        a=group:DDP L1 L2
>>>>        m=video 20000 RTP/AVP 96
>>>>        a=rtpmap:96 H264/90000
>>>>        a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>>>        a=mid:L1
>>>>        m=video 20002 RTP/AVP 97
>>>>        a=rtpmap:97 H264-SVC/90000
>>>>        a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>>        a=mid:L2
>>>>        a=depend:97 lay L1:96
>>>>
>>>>
>>>> Here the a=depend line is expressing the decoding dependency (layered in this case).
>>>>
>>>> Let us assume that there is also audio, as in Jonathan's example:
>>>>
>>>>         m=audio 10000 RTP/AVP 0 8 97
>>>>         a=mid:foo
>>>>         b=AS:200
>>>>         a=rtpmap:0 PCMU/8000
>>>>         a=rtpmap:8 PCMA/8000
>>>>         a=rtpmap:97 iLBC/8000
>>>>
>>>>
>>>> Does the entire SDP offer with BUNDLE and dependency grouping  look like this (ignoring RTP/RTCP mux for the moment)?
>>>>
>>>>         v=0
>>>>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>>>>
>>>>         s=
>>>>         c=IN IP4
>>>> host.atlanta.com
>>>>
>>>>         t=0 0
>>>>         a=group:BUNDLE foo L1 L2 baz
>>>>
>>>>         a=group:DDP L1 L2
>>>>         m=audio 10000 RTP/AVP 0 8 98
>>>>         a=mid:foo
>>>>         b=AS:200
>>>>         a=rtpmap:0 PCMU/8000
>>>>         a=rtpmap:8 PCMA/8000
>>>>         a=rtpmap:98 iLBC/8000
>>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com
>>>>   10000 typ host
>>>>         m=video 20000 RTP/AVP 96
>>>>         a=rtpmap:96 H264/90000
>>>>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>>>         a=mid:L1
>>>>         m=video 20002 RTP/AVP 97
>>>>         a=rtpmap:97 H264-SVC/90000
>>>>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>>         a=mid:L2
>>>>         a=depend:97 lay L1:96
>>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com
>>>>   20002 typ host
>>>>         m=bundle 10000 RTP/AVP 0 8 96 97 98
>>>>         a=mid:baz
>>>>         b=AS:1200
>>>>         a=full-rtpmap:0 audio/PCMU/8000
>>>>         a=full-rtpmap:8 audio/PCMA/8000
>>>>         a=full-rtpmap:98 audio/iLBC/8000
>>>>         a=full-rtpmap:96 H264/90000
>>>>         a=full-rtpmap:97 H264-SVC/90000
>>>>         a=depend:97 lay L1:96
>>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com
>>>>   10000 typ host
>>>>
>>>>
>>>>
>>> I think it will work better if it just looked like
>>>
>>>         v=0
>>>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>>>         s=
>>>         c=IN IP4 host.atlanta.com
>>>
>>>         t=0 0
>>>         a=group:BUNDLE foo L1 L2 baz
>>>
>>>         a=group:DDP L1 L2
>>>         m=audio 10000 RTP/AVP 0 8 98
>>>         a=mid:foo
>>>         b=AS:200
>>>         a=rtpmap:0 PCMU/8000
>>>         a=rtpmap:8 PCMA/8000
>>>         a=rtpmap:98 iLBC/8000
>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>>>         m=video 20000 RTP/AVP 96
>>>         a=rtpmap:96 H264/90000
>>>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>>         a=mid:L1
>>>         m=video 20002 RTP/AVP 97
>>>         a=rtpmap:97 H264-SVC/90000
>>>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>>         a=mid:L2
>>>         a=depend:97 lay L1:96
>>>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ 
>>> host
>>>
>>>
>>> that seems to have all the same information as the version with m=bundle thing and AFAIC some firewalls are going to remove all the stuff under the m=bundle line as it is not a recognized media type.
>> Not taking a position, but having firewalls remove all the m=bundle 
>> stuff (and presumably also the a=group:BUNDLE line) is, in my view, 
>> actually an advantage of this approach. (If the firewall removes the 
>> m=bundle and not the a=group:BUNDLE, we're left with a somewhat 
>> strange SDP.)
>>
>> Cullen, I note you're using different port numbers on the m= sections. Are you assuming the semantics from a=group:TOGETHER - that one picks the first one?
>>
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic