Re: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ??

[Harald Alvestrand <[e-mail]>]

In the case of multiple m=video lines (for instance), as required by
UnifiedPlan, signalling separate PTs for every M-line is not going to work
with many video streams. So the consensus seems to be that we should allow
PT to be identical across m-lines as long as the codec configuration is
identical.

It may make sense to have NACK on one media stream and not NACK on another
media stream, even though in the implementation, the binding is happening
via the m-line + PT combo, not just the PT. So NORMAL should be the right
disposition for a=rtcp-fb:98, in my opinion.


On Sun, Nov 3, 2013 at 7:08 AM, Suhas Nandakumar <[e-mail]>wrote:

> Hello Harald
>
>  Thanks for the inputs. I had a clarifying question on one of your points
> (inline)
>
> Cheers
> Suhas
>
>
> On Tue, Oct 22, 2013 at 12:55 AM, Harald Alvestrand <[e-mail]>wrote:
>
>> 0: No, using PT 98 for both audio and video should absolutely not be
>> allowed. Reuse of a PT for different codecs MUST NOT be done. I thought
>> that was pretty clear in BUNDLE already; if it's not 100% crystal clear, it
>> needs to be made clear.
>>
>> 1: Either the SDP should be rejected outright or the response to this SDP
>> needs to disallow bundling those two lines. This belongs in the BUNDLE
>> spec, and I thought it was pretty clear already.
>>
>> 2: If the question is about the "a=rtcp-fb" field, I think it should be
>> classified as NORMAL. If it is about "a=rtcp-fb:98", it makes more sense to
>> call it IDENTICAL.
>>
>
>  If the PT types are not allowed to be repeated across BUNDLED m=lines,
> would we have a need for the category to be IDENTICAL even in the case of
> a=rtcpfb:98 ??
>
>
>
>>
>>
>
>>
>> On Tue, Oct 22, 2013 at 8:36 AM, Suhas Nandakumar <[e-mail]>wrote:
>>
>>> Hello All
>>>
>>>    Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05
>>> defines one category of OPEN ISSUE that was raised while analyzing
>>> multiplexing behavior of RFC4855, RFC5583 attributes for example.
>>>
>>> As an example, let's consider the  SDP Example (copied from the draft)
>>>
>>>
>>>
>>> // PTs are shared and have different feedback types
>>>    a=group:BUNDLE audio video
>>>    m=audio 3456 RTP/AVP 98
>>>    a=mid:audio
>>>    a=rtpmap:98 iLBC/8000
>>>    a=rtcp-fb ack                  // Positive ACK
>>>    m=video 3456 RTP/AVP 98
>>>    a=mid:video
>>>    a=rtpmap:98 VP8/90000
>>>    a-rtcp-fb:98 nack rpsi        // Nack ACK
>>>
>>>
>>> In the above case, PT 98 is repeated between the audio and video media
>>> lines. Audio media line has rtcp-fb ack and video media line has
>>> rtcp-fb nack.
>>>
>>> Since RTCP reporting happens per RTP Session, we can see the following
>>> high level questions :
>>>
>>> 0. Should this be allowed ?
>>>
>>> 1. What should be the expected behavior in this scenario ?
>>>
>>> 2. What category assignment makes sense in here - IDENTICAL or NORMAL ??
>>>
>>>
>>> Cheers
>>> Suhas
>>>
>>>
>>>
>>
>