Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

[Magnus Westerlund <[e-mail]>]

Hi Inaki,

The RTP Payload type field is defined and used under the assumption that 
is common across all SSRC within an RTP session as observed a particular 
point. This is really coming from RFC 3550 and RFC 3551. For example in 
Section 3 of RFC 3551 the following is written:

    These mechanisms
    associate the registered name of the encoding/payload format, along
    with any additional required parameters, such as the RTP timestamp
    clock rate and number of channels, with a payload type number.  This
    association is effective only for the duration of the RTP session in
    which the dynamic payload type binding is made.  This association
    applies only to the RTP session for which it is made, thus the
    numbers can be re-used for different encodings in different sessions
    so the number space limitation is avoided.

Note, I did write in a particular point, otherwise RTP middleboxes would 
not be able to translate the values for specific receivers.

And this is not only a specification issue. If you look at the RTCP 
processing one there are certain calculations that requires one to know 
the RTP payload type and things like the RTP clock rate to correctly 
process. The RTP specifications have been written under the assumption 
that these values are set on RTP session scope, rather than specific SSRCs.

I would also note that there are in existence RTP based applications 
that really utilize the fact that PT values are configured on RTP 
session level, enabling new SSRCs to be used without prior signalling.

 From my perspective, the SIP/SDP usages of RTP prior to WebRTC and CLUE 
has been so constrained that this fact that PTs are set on RTP Session 
level has not mattered at all, as one has had basically one RTP stream 
per direction and RTP session. Now we have multiple RTP streams per 
direction and RTP session and it does matter.

I don't see that we can change this without large amount of work. There 
are both specification assumptions as well as implementation assumptions 
on that PT are set on RTP session level. In addition such a change would 
make some existing RTP usages impossible. Resulting in that a change 
have significant implications, which requires both consideration and 
need for liaison with affected user groups.

I would also note that this topic if you want to continue discuss it 
should involve AVTCORE WG.

Cheers

Magnus Westerlund
AVTCORE WG chair

Den 2016-03-08 kl. 14:23, skrev Iñaki Baz Castillo:
> Hi,
>
> draft-ietf-mmusic-sdp-bundle-negotiation-27 in section 10.1.2 states:
>
>
>     Multiple bundled "m=" lines might represent RTP based media.  As all
>     RTP based media associated with a BUNDLE group belong to the same RTP
>     session, in order for a given payload type value to be used inside
>     more than one bundled "m=" line, all codecs associated with the
>     payload type number MUST share an identical codec configuration.
>     This means that the codecs MUST share the same media type, encoding
>     name, clock rate and any parameter that can affect the codec
>     configuration and packetization.
>     [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
>     attribute values must be identical for all codecs that use the same
>     payload type value.
>
>
> This basically states that there cannot be two different codecs with
> same payloadType (or same codec with different codec parameters)
> within two m= sections sharing the same "transport".
>
> Let me please describe a "real" use-case:
>
> * SFU server.
> * Alice wants to send audio "opus" with payload 100 and SSRC 1111.
> * Bob wants to send audio "g722" with payload 100 and SSRC 2222.
> * Carol just wants to receive audios from Alice and Bob over a single
> transport (BUNDLE).
>
> When Carol connects with the SFU she negotiates a single ICE/DTLS
> transport, and the SFU notifies Carol about two receiving audio tracks
> (from Alice and Bob):
>
> 1) mid: alice-audio,  codec: opus,  payload: 100, ssrc: 1111
> 2) mid: bob-audio,   codec: g722,  payload: 100, ssrc: 2222
>
> This would mean that Carol receives an SDP with two "m=audio"
> sections using BUNDLE:
>
>
>    m=audio [...] 100
>    a=sendonly
>    a=mid:alice-audio
>    a=rtpmap:100 opus/48000/2
>    a=ssrc:1111 cname:foo
>    [...]
>    m=audio [...] 100
>    a=sendonly
>    a=mid:bob-audio
>    a=rtpmap:100 g722/48000
>    a=ssrc:2222 cname:bar
>    [...]
>
>
> What is the problem here? Why is having the same payload type (100) a problem?
>
> To be clear, Carol can demux the incoming RTP:
>
> * By matching the RTP MID header (if present).
> * By matching the RTP SSRC (1111 => 'alice-audio', 2222 => 'bob-audio').
>
> There is no need to check the RTP payload in order to retrieve the
> appropriate m= section. And worse: this constraint forces the SFU
> developer to rewrite the payload type sent by the participants in a
> SFU room so all of them are different.
>
> IMHO there is no real justification for this constraint, it provides
> nothing useful, and it limits and makes worse some common scenarios.
> So I ask for such a constraint to be removed from the draft.
>
>
> Thanks a lot.
>
>


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------