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.

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