Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - RTP demux - Pull Request

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 10:37:31 +0000

Hi,

I¹ve created a pull request with additional text regarding associating
RTP/RTCP packets with the correct ³m=³ line.

https://github.com/cdh4u/draft-sdp-bundle/pull/10

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Oct 2016 09:03:49 -0600

That looks about right for RTP but I think it is still missing stuff for RTCP handling. Here is the current text we did for JSEP. I prefer the style in which you described it compared to the algorithm style below but I think this might help figure out what to write for RTCP. 

When an RTP packet is received by a transport and passes SRTP authentication, that packet needs to be routed to the correct RtpReceiver. For each transport, the following steps MUST be followed to prepare to route packets:
Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport.
Construct a table mapping incoming SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive. Some of the SSRCs may be present in the m= section corresponding to that RtpReceiver in the remote description.
Construct a table mapping outgoing SSRC to RtpSender for each RtpSender configured to transmit from this transport and for each SSRC that RtpSender is configured to use when sending.
Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each payload type that RtpReceiver is configured to receive. The payload types of a given RtpReceiver are found in the m= section corresponding to that RtpReceiver in the local description. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description.
As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated.
For each RTP packet received, the following steps MUST be followed to route the packet:
If the packet has a MID and that MID is not in the table mapping MID to RtpReceiver, drop the packet and stop.
If the packet has a MID and that MID is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that MID.
If the packet's SSRC is in the incoming SSRC mapping table, deliver the packet to the associated RtpReceiver and stop.
If the packet's payload type is in the payload type table, update the the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that payload type. In addition, deliver the packet to the associated RtpReceiver and stop.
Otherwise, drop the packet.
For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the following type-specific handling MUST be performed to route the packet:
If the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC. In addition, for each report block in the report whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC.
If the packet is of type RR, for each report block in the packet whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC.
If the packet is of type SDES, and the sender SSRC for the packet is found in the incoming SSRC table, deliver the packet to the RtpReceiver associated with that SSRC. In addition, for each chunk in the packet that contains a MID that is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the SSRC for that chunk to the RtpReceiver associated with that MID. (This case can occur when RTCP for a source is received before any RTP packets.)
If the packet is of type BYE, for each SSRC indicated in the packet that is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC.
If the packet is of type RTPFB or PSFB, as defined in [RFC4585] <http://rtcweb-wg.github.io/jsep/#RFC4585>, and the media source SSRC for the packet is found in the outgoing SSRC table, deliver the packet to the RtpSender associated with that SSRC.
After packets are routed to the RtpReceiver, further processing of the RTP packets is done at the RtpReceiver level. This includes using [I-D.ietf-mmusic-rid] <http://rtcweb-wg.github.io/jsep/#I-D.ietf-mmusic-rid> to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream. If the RTP packet's PT does not match any codec in use by the RtpReceiver, the packet will be dropped.

> On Oct 12, 2016, at 4:37 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> Iąve created a pull request with additional text regarding associating
> RTP/RTCP packets with the correct łm=ł line.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Oct 2016 16:01:25 +0000

Hi,

RTCP packets can be associated with m- lines in the same way as RTP packets.

However, Magnus told me it’s not needed, so I’d like to get some input from him.

Regards,

Christer

From: Cullen Jennings [mailto:[email-masked]]
Sent: 13 October 2016 18:04
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; Magnus Westerlund <[email-masked]>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - RTP demux - Pull Request

When an RTP packet is received by a transport and passes SRTP authentication, that packet needs to be routed to the correct RtpReceiver. For each transport, the following steps MUST be followed to prepare to route packets:
·       Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport.
·       Construct a table mapping incoming SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive. Some of the SSRCs may be present in the m= section corresponding to that RtpReceiver in the remote description.
·       Construct a table mapping outgoing SSRC to RtpSender for each RtpSender configured to transmit from this transport and for each SSRC that RtpSender is configured to use when sending.
·       Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each payload type that RtpReceiver is configured to receive. The payload types of a given RtpReceiver are found in the m= section corresponding to that RtpReceiver in the local description. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description.
As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated.
For each RTP packet received, the following steps MUST be followed to route the packet:
·       If the packet has a MID and that MID is not in the table mapping MID to RtpReceiver, drop the packet and stop.
·       If the packet has a MID and that MID is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that MID.
·       If the packet's SSRC is in the incoming SSRC mapping table, deliver the packet to the associated RtpReceiver and stop.
·       If the packet's payload type is in the payload type table, update the the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that payload type. In addition, deliver the packet to the associated RtpReceiver and stop.
·       Otherwise, drop the packet.
For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the following type-specific handling MUST be performed to route the packet:
·       If the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC. In addition, for each report block in the report whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC.
·       If the packet is of type RR, for each report block in the packet whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the RtpSender associated with that SSRC.
·       If the packet is of type SDES, and the sender SSRC for the packet is found in the incoming SSRC table, deliver the packet to the RtpReceiver associated with that SSRC. In addition, for each chunk in the packet that contains a MID that is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the SSRC for that chunk to the RtpReceiver associated with that MID. (This case can occur when RTCP for a source is received before any RTP packets.)
·       If the packet is of type BYE, for each SSRC indicated in the packet that is found in the incoming SSRC table, deliver a copy of the packet to the RtpReceiver associated with that SSRC.
·       If the packet is of type RTPFB or PSFB, as defined in [RFC4585]<http://rtcweb-wg.github.io/jsep/#RFC4585>, and the media source SSRC for the packet is found in the outgoing SSRC table, deliver the packet to the RtpSender associated with that SSRC.
After packets are routed to the RtpReceiver, further processing of the RTP packets is done at the RtpReceiver level. This includes using [I-D.ietf-mmusic-rid]<http://rtcweb-wg.github.io/jsep/#I-D.ietf-mmusic-rid> to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream. If the RTP packet's PT does not match any codec in use by the RtpReceiver, the packet will be dropped.

On Oct 12, 2016, at 4:37 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Oct 2016 09:54:15 +0200

Den 2016-10-13 kl. 18:01, skrev Christer Holmberg:
> *From:*Cullen Jennings [mailto:[email-masked]]
> That looks about right for RTP but I think it is still missing stuff for
> RTCP handling. Here is the current text we did for JSEP. I prefer the
> style in which you described it compared to the algorithm style below
> but I think this might help figure out what to write for RTCP.
>

I dislike the algorithmic description JSEP has because it inserts itself 
at position in the stack where I would not myself implement the binding 
handling. The implementations of RTP stacks I have made have never let 
the full RTCP packets be available to the application layer. It has only 
implemented event and request based interface to provide the triggers 
and data associated with the differnet RTCP packets. Thus, from my 
perspective the routing of the RTCP packets becomes a question if the 
SSRC is bound to the right m=. Then handel the received RTCP packets in 
that context.

So what might be a suitable RTCP clarification regarding RTCP would be 
the following.

Simply add RTCP in the following sentence:

"Later, when an offerer or answerer receives an RTP packet that does not 
carry the identification-tag, it can associate the packet with the
correct "m=" line using the SSRC value."

so that it reads:

"Later, when an offerer or answerer receives an RTP or RTCP packet that 
does not carry the identification-tag, it can associate the packet with 
the correct "m=" line using the SSRC value."

Regarding the second paragraph. If the association has been done 
according to this part then also the RTCP packets has an association. If 
an RTCP packet arrives with a non associated SSRC, then many RTCP 
packets type can still be processed and the information stored in the 
SSRC related information table. Some that are application interaction 
related, like some of the feedback messages can of course not be handled.

One very important aspect here is that the basic RTCP processing do need 
to occur for also non-associated SSRCs. This to ensure that the sender 
get the RTCP feedback information for congestion control purposes. We 
want the transport layer functions to continue function, even if the 
application can't consume the packets.

Thus, I would consider that the "the packet SHOULD be dropped." needs an 
addition that says after having been processed as received by the RTCP 
layer. If we don't report them as received we skew the congestion 
control information, and it will make any coupled congestion controller 
that looks at the set of RTP streams being emitted take the wrong 
decision. I also assumes that a lack of association is in most cases a 
temporary issue that will be resolved by the regular transmissions.

A long term lack of association is from my perspective indicates an 
error on the signalling plane, so that a renegotation is needed. I do 
see the downside that the sending sides RTP/RTCP stack is lacking the 
information that the packet is being dropped after reception. This could 
be solved if one implemented the RTCP XR packet type Discard Count 
Metric Reporting (https://datatracker.ietf.org/doc/rfc7002/).
I would use the 01 "Packet to early" for this case.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Oct 2016 10:50:50 +0100

> On 14 Oct 2016, at 08:54, Magnus Westerlund <[email-masked]> wrote:
> 
> I dislike the algorithmic description JSEP has because it inserts itself at position in the stack where I would not myself implement the binding handling. The implementations of RTP stacks I have made have never let the full RTCP packets be available to the application layer. It has only implemented event and request based interface to provide the triggers and data associated with the differnet RTCP packets. Thus, from my perspective the routing of the RTCP packets becomes a question if the SSRC is bound to the right m=. Then handel the received RTCP packets in that context.
> 
> So what might be a suitable RTCP clarification regarding RTCP would be the following.
> 
> "Later, when an offerer or answerer receives an RTP packet that does not carry the identification-tag, it can associate the packet with the
> "Later, when an offerer or answerer receives an RTP or RTCP packet that does not carry the identification-tag, it can associate the packet with the correct "m=" line using the SSRC value."
> 
> Regarding the second paragraph. If the association has been done according to this part then also the RTCP packets has an association. If an RTCP packet arrives with a non associated SSRC, then many RTCP packets type can still be processed and the information stored in the SSRC related information table. Some that are application interaction related, like some of the feedback messages can of course not be handled.
> 
> One very important aspect here is that the basic RTCP processing do need to occur for also non-associated SSRCs. This to ensure that the sender get the RTCP feedback information for congestion control purposes. We want the transport layer functions to continue function, even if the application can't consume the packets.
> 
> Thus, I would consider that the "the packet SHOULD be dropped." needs an addition that says after having been processed as received by the RTCP layer. If we don't report them as received we skew the congestion control information, and it will make any coupled congestion controller that looks at the set of RTP streams being emitted take the wrong decision. I also assumes that a lack of association is in most cases a temporary issue that will be resolved by the regular transmissions.

I agree with all of this. The mapping shouldn’t be from RTP or RTCP packets onto RtpRecivers. The RTP protocol requires RTP and RTCP packets be associated to an SSRC, and the mapping is to determine what’s the role of that SSRC (i.e., to map from SSRC to RtpReceiver).

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2016 12:36:28 +0000

Hi,

Would the following work:

- BUNDLE defines how to associate received RTP packets with an m- line
- JSET defines how to associate m- lines with RtpReceivers

In that case, BUNDLE would define the generic associate-with-m-line rules,
while JSEP defines the WebRTC specifics.

Regards,

Christer

On 17/10/16 12:50, "Colin Perkins" <[email-masked]> wrote:

>>> However, Magnus told me it¹s not needed, so I¹d like to get some input
>>> from him.
>>> 
>> I dislike the algorithmic description JSEP has because it inserts
>>itself at position in the stack where I would not myself implement the
>>binding handling. The implementations of RTP stacks I have made have
>>never let the full RTCP packets be available to the application layer.
>>It has only implemented event and request based interface to provide the
>>triggers and data associated with the differnet RTCP packets. Thus, from
>>my perspective the routing of the RTCP packets becomes a question if the
>> "Later, when an offerer or answerer receives an RTP packet that does
>>not carry the identification-tag, it can associate the packet with the
>> One very important aspect here is that the basic RTCP processing do
>>need to occur for also non-associated SSRCs. This to ensure that the
>>sender get the RTCP feedback information for congestion control
>>purposes. We want the transport layer functions to continue function,
>>even if the application can't consume the packets.
>> 
>> Thus, I would consider that the "the packet SHOULD be dropped." needs
>>an addition that says after having been processed as received by the
>>RTCP layer. If we don't report them as received we skew the congestion
>I agree with all of this. The mapping shouldn¹t be from RTP or RTCP
>packets onto RtpRecivers. The RTP protocol requires RTP and RTCP packets
>be associated to an SSRC, and the mapping is to determine what¹s the role
>of that SSRC (i.e., to map from SSRC to RtpReceiver).
>
>
>-- 
>Colin Perkins
>https://csperkins.org/
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2016 11:16:47 +0000

Hi,

I¹ve updated the pull request based on Magnus¹ suggestion.

Regards,

Christer

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Oct 2016 13:18:39 +0100

Hi,

That split between BUNDLE and JSEP is fine with me. My concern, though, is that it’s still phrased in terms of “associate received RTP packets with an m= line”, rather than “associate SSRC with an m= line”. For the RTP processing to work, the RTP and RTCP packets need to be grouped by SSRC, since RTCP processing, repairs, etc., are done per SSRC, then that SSRC mapped is onto the m= line.

Colin

> On 17 Oct 2016, at 13:36, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2016 12:37:21 +0000

Hi Colin,

BUNDLE is about grouping m- lines, and as all m- lines shares the same
address:port I think the text should be how to associate RTP packets with
m- lines, using MID, SSRC etc.

How RTP packets are then grouped and processed etc I think is outside the
scope of BUNDLE.

Regards,

Christer

On 19/10/16 15:18, "Colin Perkins" <[email-masked]> wrote:

>Hi,
>
>That split between BUNDLE and JSEP is fine with me. My concern, though,
>is that it’s still phrased in terms of “associate received RTP packets
>with an m= line”, rather than “associate SSRC with an m= line”. For the
>RTP processing to work, the RTP and RTCP packets need to be grouped by
>SSRC, since RTCP processing, repairs, etc., are done per SSRC, then that
>SSRC mapped is onto the m= line.
>
>Colin
>
>
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Oct 2016 14:18:36 +0100

Hi,

> On 19 Oct 2016, at 13:37, Christer Holmberg <[email-masked]> wrote:
> 

Sorry, but I think this is fundamentally wrong. BUNDLE associates RTP _streams_ with “m=“ lines; it doesn’t associate RTP _packets_ with “m=“ lines. There’s an important semantic difference between these two that’s getting missed.

When RTP and RTCP packets are received, they’re associated with an RTP stream, based on, and identified by, their SSRC [RFC7656]. This is done whether or not BUNDLE is in use.

The goal of BUNDLE is then to associate those received RTP streams with m= lines. This might be done based on a signalled mapping from SSRC to m= line (“a=ssrc:”), it might be done using MID, or some other means. But, the association is from RTP stream to m= line, not from RTP packets to m= line.

> How RTP packets are then grouped and processed etc I think is outside the

Yes, but not in the way you suggest. I think what should happen is:

- The grouping of RTP and RTCP packets into RTP streams happens below BUNDLE. An RTP stream is always identified by SSRC, and will have other metadata associated with it. That metadata can be sent in RTCP, in RTP header extensions, or it can be signalled using “a=ssrc:” lines. The SSRC might not be signalled in advance, but still identifies the RTP stream.

- BUNDLE then associates those RTP streams with m= lines. This mapping needs to be defined in terms of RTP streams, not RTP packets, since the RTP packets have already been grouped into streams before they reach BUNDLE. It should describe how to map an RTP stream with a particular SSRC onto an “m=“ line, based on the metadata associated with that RTP stream. 

- How those m= lines relate to higher-level semantics is determined by a higher-layer protocol, such as JSEP.

Getting the layering right is important, I think, to have something that’s both understandable and extensible:

 RTP Layer  : RTP and RTCP packets -> RTP streams
 SDP BUNDLE : RTP streams -> SDP “m=" lines
 JSEP       : SDP “m=" lines -> application-level semantics

I don’t think this will need a big text change, but it is a semantic change in how the BUNDLE draft describes the mapping.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2016 13:31:42 +0000

Hi Colin,

I'd really appreciate if you could provide text, by e-mail, by a pull request, or however you want :)

Regards,

Christer

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 19 October 2016 16:19
To: Christer Holmberg <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; Cullen Jennings <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - RTP demux - Pull Request

Hi,

> How RTP packets are then grouped and processed etc I think is outside 
> the scope of BUNDLE.

 RTP Layer  : RTP and RTCP packets -> RTP streams  SDP BUNDLE : RTP streams -> SDP “m=" lines
 JSEP       : SDP “m=" lines -> application-level semantics

Colin

>> That split between BUNDLE and JSEP is fine with me. My concern, 
>> though, is that it’s still phrased in terms of “associate received 
>> RTP packets with an m= line”, rather than “associate SSRC with an m= 
>> line”. For the RTP processing to work, the RTP and RTCP packets need 
>> to be grouped by SSRC, since RTCP processing, repairs, etc., are done 
>> per SSRC, then that SSRC mapped is onto the m= line.
>> 
>> Colin
>> 
>> 
>> 
>>> In that case, BUNDLE would define the generic associate-with-m-line 
>>> rules, while JSEP defines the WebRTC specifics.
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>>>>> However, Magnus told me it¹s not needed, so I¹d like to get some 
>>>>>> input from him.
>>>>>> 
>>>>>> *From:*Cullen Jennings [mailto:[email-masked]] That looks about 
>>>>>> right for RTP but I think it is still missing stuff for RTCP 
>>>>>> handling. Here is the current text we did for JSEP. I prefer the 
>>>>>> style in which you described it compared to the algorithm style 
>>>>>> below but I think this might help figure out what to write for RTCP.
>>>>>> 
>>>>> 
>>>>> itself at position in the stack where I would not myself implement 
>>>>> the binding handling. The implementations of RTP stacks I have 
>>>>> made have never let the full RTCP packets be available to the application layer.
>>>>> It has only implemented event and request based interface to 
>>>>> provide the triggers and data associated with the differnet RTCP 
>>>>> packets. Thus, from my perspective the routing of the RTCP packets 
>>>>> becomes a question if the SSRC is bound to the right m=. Then 
>>>>> handel the received RTCP packets in that context.
>>>>> 
>>>>> "Later, when an offerer or answerer receives an RTP packet that 
>>>>> does not carry the identification-tag, it can associate the packet 
>>>>> with the correct "m=" line using the SSRC value."
>>>>> 
>>>>> so that it reads:
>>>>> 
>>>>> "Later, when an offerer or answerer receives an RTP or RTCP packet 
>>>>> that does not carry the identification-tag, it can associate the 
>>>>> packet with the correct "m=" line using the SSRC value."
>>>>> 
>>>>> packets type can still be processed and the information stored in 
>>>>> the SSRC related information table. Some that are application 
>>>>> interaction related, like some of the feedback messages can of 
>>>>> course not be handled.
>>>>> 
>>>>> One very important aspect here is that the basic RTCP processing 
>>>>> do need to occur for also non-associated SSRCs. This to ensure 
>>>>> that the sender get the RTCP feedback information for congestion 
>>>>> control purposes. We want the transport layer functions to 
>>>>> continue function, even if the application can't consume the packets.
>>>>> 
>>>>> Thus, I would consider that the "the packet SHOULD be dropped." 
>>>>> needs an addition that says after having been processed as 
>>>>> received by the RTCP layer. If we don't report them as received we 
>>>>> skew the congestion control information, and it will make any 
>>>>> coupled congestion controller that looks at the set of RTP streams 
>>>>> being emitted take the wrong decision. I also assumes that a lack 
>>>>> of association is in most cases a temporary issue that will be 
>>>>> resolved by the regular transmissions.
>>>> 
>>>> packets onto RtpRecivers. The RTP protocol requires RTP and RTCP 
>>>> packets be associated to an SSRC, and the mapping is to determine 
>>>> what¹s the role of that SSRC (i.e., to map from SSRC to 
>>>> RtpReceiver).
>>>> 
>>>> 
>>>> --
>>>> Colin Perkins
>>>> https://csperkins.org/
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Colin Perkins
>> https://csperkins.org/
>> 
>> 
>> 
>> 
> 

--
Colin Perkins
https://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Oct 2016 15:36:54 +0200

Hi,

I just want to say that I support what Colin expresses below.

Cheers

Magnus

Den 2016-10-19 kl. 15:18, skrev Colin Perkins:
>>>>>>> input
>>>>>> that
>>>>>> with
>>>>> packets

-- 

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2016 13:48:01 +0000

Hi,

>I just want to say that I support what Colin expresses below.

Awesome - feel free to help Colin putting together the pull request :)

Regards,

Christer

Den 2016-10-19 kl. 15:18, skrev Colin Perkins:
>> BUNDLE is about grouping m- lines, and as all m- lines shares the 
>> same address:port I think the text should be how to associate RTP 
>> packets with
>>> to be grouped by SSRC, since RTCP processing, repairs, etc., are 
>>> done per SSRC, then that SSRC mapped is onto the m= line.
>>>
>>> Colin
>>>
>>>
>>>
>>>>>> itself at position in the stack where I would not myself 
>>>>>> implement the binding handling. The implementations of RTP stacks 
>>>>>> I have made have never let the full RTCP packets be available to the application layer.
>>>>>> packets. Thus, from my perspective the routing of the RTCP 
>>>>>> packets becomes a question if the SSRC is bound to the right m=. 
>>>>>> Then handel the received RTCP packets in that context.
>>>>>>
>>>>>> does not carry the identification-tag, it can associate the 
>>>>>> "Later, when an offerer or answerer receives an RTP or RTCP 
>>>>>> packet that does not carry the identification-tag, it can 
>>>>>> associate the packet with the correct "m=" line using the SSRC 
>>>>>> value."
>>>>>>
>>>>>> received by the RTCP layer. If we don't report them as received 
>>>>>> we skew the congestion control information, and it will make any 
>>>>>> coupled congestion controller that looks at the set of RTP 
>>>>>> streams being emitted take the wrong decision. I also assumes 
>>>>>> that a lack of association is in most cases a temporary issue 
>>>>>> that will be resolved by the regular transmissions.
>>>>>
>>>>> I agree with all of this. The mapping shouldn¹t be from RTP or 
>>>>> RTCP packets onto RtpRecivers. The RTP protocol requires RTP and 
>>>>> RTCP packets be associated to an SSRC, and the mapping is to 
>>>>> determine what¹s the role of that SSRC (i.e., to map from SSRC to 
>>>>> RtpReceiver).
>>>>>
>>>>>
>>>>> --
>>>>> Colin Perkins
>>>>> https://csperkins.org/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Colin Perkins
>>> https://csperkins.org/
>>>
>>>
>>>
>>>
>>
>
>
>

-- 

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Oct 2016 16:20:25 -0400

> I don’t think this will need a big text change, but it is a semantic change in how the BUNDLE draft describes the mapping.

ISTM this isn't fundamentally about BUNDLE. It is about the relationship 
of SDP and RTP. My impression is that this was never *right*, and the 
introduction of BUNDLE has brought it to a head.

For the most part SDP rarely mentions SSRCs. (It *can* using a=SSRC, but 
that is a rarely used construct.)

SDP is a container for multiple "Media Descriptions". Syntactically it 
does this by:

- grouping multiple SDP lines into multiple media descriptions
   delineated by m-lines
- associating a 3-tuple with each media description based on the
   c-line and info in the m-line
- associating two SDPs (offer and answer), pairing the media
   descriptions in each in order to merge properties. This merges
   two 3-tuples into a 5-tuple

The code that interprets this stuff then (in the case of RTP) associates 
each media description with (possibly multiple) RTP streams. In non-rtp 
cases the interpretation is different.

Historically (pre-bundle) that code was able to associate network 
packets with media descriptions based on the 5-tuple. This was partially 
done by the OS (sockets) and partially the application.

The introduction of BUNDLE is with the intent using a single 5-tuple for 
multiple media descriptions. That means that the 5-tuple is insufficient 
to associate packets with media descriptions, so some additional 
algorithm is required to do that.

When Christer is talking about an m-line he is generally using that as 
shorthand language for the media description delineated by the m-line. 
With that in mind, his wording "associate received RTP packets wth an m= 
line [media description]" seems right to me.

In the case of RTP, it remains the job of the RTP implementation to 
associate those incoming RTP packets with a media description. *Then* it 
can use the other properties of that media description to help in 
figuring out what RTP stream they are associated with.

That is only for RTP. In the case of non-RTP media that is is the bundle 
some different algorithm is needed to make the association. We have only 
defined a limited case for non-RTP media in a bundle, so the task is 
easier. But we just put that off. In principle more things could be 
bundled. For instance, we *could* have allowed multiple UDP/DTLS/SCTP 
media descriptions in the bundle as long as they had differing 
SCTP-ports. That would bind corresponding packets to one or the other of 
the media descriptions.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Oct 2016 15:34:19 -0500

RTCP packets can contain information relevant to more than one RtpReceiver
or RtpSender.  As a result, the ORTC specification contains the (admittedly
somewhat vague) text below.  We omitted the RTCP "app" message (Section 6.7
of RFC 3550) since support for that is not required in WebRTC.

"RTCP packets arriving on an RTCDtlsTransport
<http://draft.ortc.org/#dom-rtcdtlstransport> are decrypted and a
notification is sent to all RTCRtpSender
<http://draft.ortc.org/#dom-rtcrtpsender> andRTCRtpReceiver
<http://draft.ortc.org/#dom-rtcrtpreceiver> objects utilizing that
transport. RTCRtpSender <http://draft.ortc.org/#dom-rtcrtpsender> and
RTCRtpReceiver <http://draft.ortc.org/#dom-rtcrtpreceiver> objects then
examine the RTCP packets to determine the information relevant to their
operation and the statistics maintained by them.

RTCP packets should be queued for 30 seconds and all RTCRtpSender
<http://draft.ortc.org/#dom-rtcrtpsender> and RTCRtpReceiver
<http://draft.ortc.org/#dom-rtcrtpreceiver> objects on the related
RTCDTlsTransport <http://draft.ortc.org/#dom-rtcdtlstransport> have access
to those packets until the packet is removed from the queue, should the
RTCRtpSender <http://draft.ortc.org/#dom-rtcrtpsender> or RTCRtpReceiver
<http://draft.ortc.org/#dom-rtcrtpreceiver> objects need to examine them.

Relevant SSRC fields within selected RTCP packets are summarized within [
RFC3550 <http://draft.ortc.org/#bib-RFC3550>] Section 6.4.1 (Sender
Report), Section 6.4.2 (Receiver Report), Section 6.5 (SDES), Section 6.6
(BYE), [RFC4585 <http://draft.ortc.org/#bib-RFC4585>] Section 6.1 (Feedback
Messages), and [RFC3611 <http://draft.ortc.org/#bib-RFC3611>] Section 2
(Extended Reports)."

On Thu, Oct 13, 2016 at 10:03 AM, Cullen Jennings <[email-masked]> wrote:

> RTCP handling. Here is the current text we did for JSEP. I prefer the style
> in which you described it compared to the algorithm style below but I think
> this might help figure out what to write for RTCP.
>
>
>
> When an RTP packet is received by a transport and passes SRTP
> authentication, that packet needs to be routed to the correct RtpReceiver.
> For each transport, the following steps MUST be followed to prepare to
> route packets:
>
>
>    - Construct a table mapping MID to RtpReceiver for each RtpReceiver
>    configured to receive from this transport.
>    - Construct a table mapping incoming SSRC to RtpReceiver for each
>    RtpReceiver configured to receive from this transport and for each SSRC
>    that RtpReceiver is configured to receive. Some of the SSRCs may be present
>    in the m= section corresponding to that RtpReceiver in the remote
>    description.
>    - Construct a table mapping outgoing SSRC to RtpSender for each
>    RtpSender configured to transmit from this transport and for each SSRC that
>    RtpSender is configured to use when sending.
>    - Construct a table mapping payload type to RtpReceiver for each
>    RtpReceiver configured to receive from this transport and for each payload
>    type that RtpReceiver is configured to receive. The payload types of a
>    given RtpReceiver are found in the m= section corresponding to that
>    RtpReceiver in the local description. If any payload type could map to more
>    than one RtpReceiver, map to the RtpReceiver whose m= section appears
>    earliest in the local description.
>
> As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped,
> or reconfigured, the tables above must also be updated.
>    - If the packet has a MID and that MID is not in the table mapping MID
>    to RtpReceiver, drop the packet and stop.
>    - If the packet has a MID and that MID is in the table mapping MID to
>    RtpReceiver, update the incoming SSRC mapping table to include an entry
>    that maps the packet's SSRC to the RtpReceiver for that MID.
>    - If the packet's SSRC is in the incoming SSRC mapping table, deliver
>    the packet to the associated RtpReceiver and stop.
>    - If the packet's payload type is in the payload type table, update
>    the the incoming SSRC mapping table to include an entry that maps the
>    packet's SSRC to the RtpReceiver for that payload type. In addition,
>    deliver the packet to the associated RtpReceiver and stop.
>    - Otherwise, drop the packet.
>
> For each RTCP packet received (including each RTCP packet that is part of
> a compound RTCP packet), the following type-specific handling MUST be
> performed to route the packet:
>
>
>    - If the packet is of type SR, and the sender SSRC for the packet is
>    found in the incoming SSRC table, deliver a copy of the packet to the
>    RtpReceiver associated with that SSRC. In addition, for each report block
>    in the report whose SSRC is found in the outgoing SSRC table, deliver a
>    copy of the RTCP packet to the RtpSender associated with that SSRC.
>    - If the packet is of type RR, for each report block in the packet
>    whose SSRC is found in the outgoing SSRC table, deliver a copy of the RTCP
>    packet to the RtpSender associated with that SSRC.
>    - If the packet is of type SDES, and the sender SSRC for the packet is
>    found in the incoming SSRC table, deliver the packet to the RtpReceiver
>    associated with that SSRC. In addition, for each chunk in the packet that
>    contains a MID that is in the table mapping MID to RtpReceiver, update the
>    incoming SSRC mapping table to include an entry that maps the SSRC for that
>    chunk to the RtpReceiver associated with that MID. (This case can occur
>    when RTCP for a source is received before any RTP packets.)
>    - If the packet is of type BYE, for each SSRC indicated in the packet
>    that is found in the incoming SSRC table, deliver a copy of the packet to
>    the RtpReceiver associated with that SSRC.
>    - If the packet is of type RTPFB or PSFB, as defined in [RFC4585]
>    <http://rtcweb-wg.github.io/jsep/#RFC4585>, and the media source SSRC
>    for the packet is found in the outgoing SSRC table, deliver the packet to
>    the RtpSender associated with that SSRC.
>
> After packets are routed to the RtpReceiver, further processing of the RTP
> packets is done at the RtpReceiver level. This includes using
> [I-D.ietf-mmusic-rid]
> <http://rtcweb-wg.github.io/jsep/#I-D.ietf-mmusic-rid> to distinguish
> between multiple Encoded Streams, as well as determine which Source RTP
> stream should be repaired by a given Redundancy RTP stream. If the RTP
> packet's PT does not match any codec in use by the RtpReceiver, the packet
> will be dropped.
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Oct 2016 15:44:01 -0500

Magnus --

Applying RTP routing rules to RTCP packets does not work in general.
Consider below an RTCP SR packet (from RFC 3550 Section 6.4.1).

This RTCP SR can contain several report blocks, corresponding to multiple
sources.  Therefore it is conceivable that the first report block will
match one RtpReceiver (based on consulting the ssrc_table), and another
report block will match a different RtpReceiver (consulting that
RtpReceiver's ssrc_table).  So portions of the packet would be relevant to
different RtpReceiver objects.

As a result, you cannot use the RTP routing rules to deliver RTCP packets.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=SR=200   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SSRC of sender                        |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             NTP timestamp, least significant word             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         RTP timestamp                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     sender's packet count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      sender's octet count                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

On Fri, Oct 14, 2016 at 2:54 AM, Magnus Westerlund <
[email-masked]> wrote:

> handling. The implementations of RTP stacks I have made have never let the
> full RTCP packets be available to the application layer. It has only
> implemented event and request based interface to provide the triggers and
> data associated with the differnet RTCP packets. Thus, from my perspective
> the routing of the RTCP packets becomes a question if the SSRC is bound to
> the right m=. Then handel the received RTCP packets in that context.
>
> does not carry the identification-tag, it can associate the packet with the
> Regarding the second paragraph. If the association has been done according
> to this part then also the RTCP packets has an association. If an RTCP
> packet arrives with a non associated SSRC, then many RTCP packets type can
> still be processed and the information stored in the SSRC related
> information table. Some that are application interaction related, like some
> of the feedback messages can of course not be handled.
>
> to occur for also non-associated SSRCs. This to ensure that the sender get
> the RTCP feedback information for congestion control purposes. We want the
> transport layer functions to continue function, even if the application
> can't consume the packets.
>
> layer. If we don't report them as received we skew the congestion control
> information, and it will make any coupled congestion controller that looks
> at the set of RTP streams being emitted take the wrong decision. I also
> assumes that a lack of association is in most cases a temporary issue that
> will be resolved by the regular transmissions.
>
> A long term lack of association is from my perspective indicates an error
> on the signalling plane, so that a renegotation is needed. I do see the
> downside that the sending sides RTP/RTCP stack is lacking the information
> that the packet is being dropped after reception. This could be solved if
> one implemented the RTCP XR packet type Discard Count Metric Reporting (
> https://datatracker.ietf.org/doc/rfc7002/).

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 07:18:34 +0000

Hi,

In BUNDLE, can’t we just say that an RTCP packet can be associated with multiple SSRCs, and therefore possibly with m- lines?

Regards,

Christer

From: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 19 October 2016 at 23:44
To: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - RTP demux - Pull Request

Magnus --

Applying RTP routing rules to RTCP packets does not work in general.  Consider below an RTCP SR packet (from RFC 3550 Section 6.4.1).

This RTCP SR can contain several report blocks, corresponding to multiple sources.  Therefore it is conceivable that the first report block will match one RtpReceiver (based on consulting the ssrc_table), and another report block will match a different RtpReceiver (consulting that RtpReceiver's ssrc_table).  So portions of the packet would be relevant to different RtpReceiver objects.

        0                   1                   2                   3

On Fri, Oct 14, 2016 at 2:54 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
Den 2016-10-13 kl. 18:01, skrev Christer Holmberg:
However, Magnus told me it’s not needed, so I’d like to get some input
from him.

*From:*Cullen Jennings [mailto:[email-masked]<mailto:[email-masked]>]

so that it reads:

A long term lack of association is from my perspective indicates an error on the signalling plane, so that a renegotation is needed. I do see the downside that the sending sides RTP/RTCP stack is lacking the information that the packet is being dropped after reception. This could be solved if one implemented the RTCP XR packet type Discard Count Metric Reporting (https://datatracker.ietf.org/doc/rfc7002/).
I would use the 01 "Packet to early" for this case.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                 | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Oct 2016 09:45:54 +0200

Hi,

Not disagreeing. I was not well formulated what I wrote, it was not 
conveying what it needed to say. Colin also pointed out that talking 
about packets is misleading. Something that is especially true for RTCP, 
where all information is associated with SSRCs, and as you correctly 
point out a single RTCP packet can contain multiple information elements 
related to different RTP streams.

So, yes we need to change the text. I think we first have to ensure that 
there are not anything hiding in the discussion Paul raised.

Cheers

Magnus

Den 2016-10-19 kl. 22:44, skrev Bernard Aboba:
> This RTCP SR can contain several report blocks, corresponding to
> multiple sources.  Therefore it is conceivable that the first report
> block will match one RtpReceiver (based on consulting the ssrc_table),
> and another report block will match a different RtpReceiver (consulting
> that RtpReceiver's ssrc_table).  So portions of the packet would be
> relevant to different RtpReceiver objects.
>
> On Fri, Oct 14, 2016 at 2:54 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>         *From:*Cullen Jennings [mailto:[email-masked] <mailto:[email-masked]>]
>         below
>     the binding handling. The implementations of RTP stacks I have made
>     have never let the full RTCP packets be available to the application
>     layer. It has only implemented event and request based interface to
>     becomes a question if the SSRC is bound to the right m=. Then handel
>     the received RTCP packets in that context.
>
>     according to this part then also the RTCP packets has an
>     association. If an RTCP packet arrives with a non associated SSRC,
>     then many RTCP packets type can still be processed and the
>     information stored in the SSRC related information table. Some that
>     are application interaction related, like some of the feedback
>     messages can of course not be handled.
>
>     purposes. We want the transport layer functions to continue
>     function, even if the application can't consume the packets.
>
>     needs an addition that says after having been processed as received
>     by the RTCP layer. If we don't report them as received we skew the
>     congestion control information, and it will make any coupled
>     congestion controller that looks at the set of RTP streams being
>     emitted take the wrong decision. I also assumes that a lack of
>     association is in most cases a temporary issue that will be resolved
>     by the regular transmissions.
>
>     error on the signalling plane, so that a renegotation is needed. I
>     do see the downside that the sending sides RTP/RTCP stack is lacking
>     the information that the packet is being dropped after reception.
>     This could be solved if one implemented the RTCP XR packet type
>     Discard Count Metric Reporting
>     (https://datatracker.ietf.org/doc/rfc7002/
>     <https://datatracker.ietf.org/doc/rfc7002/>).
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Oct 2016 13:43:05 +0200

Hi,

Yes, there are history here, we also have made decision on what we 
wanted the m= line to mean. Yes, the path we chose it is not the one 
that results in the cleanest configuration for RTP.

I am also try my best to keep in mind that how you implemented your RTP 
stack can significantly impact how you consider these issues.

So comments inline.

Attempt to conclude at the bottom.

Den 2016-10-19 kl. 22:20, skrev Paul Kyzivat:
>> Getting the layering right is important, I think, to have something
>> that’s both understandable and extensible:
>>
>> I don’t think this will need a big text change, but it is a semantic
>> change in how the BUNDLE draft describes the mapping.
>

Agreed, the usage of SAP wiht SDP for configuring RAT/VIC MBONE tools 
actually worked on an RTP session level (with an assumption of sending 
one but receiving many streams per RTP session and media type). Then SIP 
O/A came along and introduced a media stream centric definition. Which I 
think is part of where it went in a direction that contributes to 
today's issues.

> done by the OS (sockets) and partially the application.

Yes, part of this tangle is that parameters that in reality are RTP 
session related parameters are tangled up with the media source you 
would like to receive and send.

And from my perspective, the OS (Sockets) selectors for incoming data 
are really associated first of all with the RTP session. Only a possible 
second usage for identifying a particular incoming RTP stream as being 
from a particular end-point and application context.

And the O/A design introduced an artificial limitation for RTP. As the 
3-tupe or 5-tuple are not at all related to how many RTP streams can 
flow between these end-points.

> SCTP-ports. That would bind corresponding packets to one or the other of

Yes, but also in the case for SCTP, one doesn't need to talk about SCTP 
packets, one should talk about the different SCTP association, which is 
what the SCTP ports identify. Yes, on the lowest level it might be easy 
to just abstract it to be packets from the other protocol. But, in most 
cases I think you can easily put another label on the flow(s) of 
packets, uni or bi-directional depending on the protocol. When defining 
an SDP configuration of a transport mechanism one have to consider what 
protocol elements that needs to be configured.

I currently fail to see that the above discussion changes what needs to 
be done. Yes, SDP's description of RTP is not optimally structured, but 
that we can't change. We also have the agreement that one m= should 
describe one Media Source, thus we simply have to describe how this is 
accomplished, despite the fact that one needs to consider both RTP 
session and the set of RTP streams associated with a media source that 
on sends as well as the RTP streams one is willing to receive.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2016 12:40:06 -0400

> on sends as well as the RTP streams one is willing to receive.

IMO the issue is to sort out different levels of abstraction and layering.

SDP media descriptions are not fundamentally about RTP streams, they are 
about something more general. A whole variety of different sorts of 
connections/associations can be described using media descriptions. Some 
describe a single stream, some describe multiple streams. When they 
describe multiple streams, they have differing nomenclature for talking 
about and denoting those streams. SSRC is meaningful only for RTP. So 
SSRC, or RTP stream, are not terms that ought to be fundamentally 
involved in defining the meaning/function of SDP or BUNDLE. (OTOH, they 
certainly can be considered as part of a discussion of specializing the 
media description for RTP-based media descriptions.)

It might be helpful to conceptualize this in terms of superclasses and 
subclasses. MediaDescription is a base class. A Bundle is a collection 
of MediaDescriptions, but not all MediaDescriptions are bundleable - 
there are some constraints that must be satisfied.

The key feature of a bundle is that all the contained MediaDescriptions 
must share a 5-tuple. The protocol part of the 5-tuple is itself a bit 
tricky, in that we don't require them to have identical m-line <proto> 
fields. Instead, we only require them to share some lower level part of 
the stack of protocols in each of the bundled m-lines. In particular 
DTLS over UDP or DTLS over TCP. (And this is further complicated by ICE, 
but that is a separate discussion.)

The next most significant constraint is that all the data received via 
the 5-tuple must be able to be disambiguated by the receiver regarding 
which MediaDescription(s) it applies to. My attempt to describe that as 
classifying *packets* turns out to be an over-simplification.

The actual classification probably needs to be layered. If the common 
protocol to all the bundled MediaDescriptions is packet-oriented, then 
that is where classification can start. Consider a bundle including RTP, 
RTCP, and SCTP: the first level of classification will be to classify 
the packet as one of those. If there is a single SCTP MediaDescription 
in the bundle then that will be enough to associate SCTP packets with 
that one. If there are multiple RTP MediaDescriptions then RTP and RTCP 
packets need further analysis. The RTCP packets are complicated, as has 
been discussed previously. I still have the sense that RTP packets can 
be classified to a single MediaDescription, but my understanding is 
limited so I am prepared to be wrong about that.

The bottom line is that much of this isn't part of the general bundle 
mechanism. It is specific to the specialization of bundle to RTP. That 
does need to be written down *somewhere*. It could be part of the bundle 
draft, as a subsection specific to RTP. Or it could be in some other 
document.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 18:41:16 +0000

>SDP media descriptions are not fundamentally about RTP streams, they are about something more general. A whole variety 
>of different sorts of connections/associations can be described using media descriptions. Some describe a single stream, some 
>describe multiple streams. When they describe multiple streams, they have differing nomenclature for talking about and 
>denoting those streams. SSRC is meaningful only for RTP. So SSRC, or RTP stream, are not terms that ought to be 
>fundamentally involved in defining the meaning/function of SDP or BUNDLE. (OTOH, they certainly can be considered 
>as part of a discussion of specializing the media description for RTP-based media descriptions.)
>
>It might be helpful to conceptualize this in terms of superclasses and subclasses. MediaDescription is a base class. A
>Bundle is a collection of MediaDescriptions, but not all MediaDescriptions are bundleable - there are some constraints 
>that must be satisfied.
>
>The key feature of a bundle is that all the contained MediaDescriptions must share a 5-tuple. The protocol part of the 
>5-tuple is itself a bit tricky, in that we don't require them to have identical m-line <proto> fields. Instead, we only 
>require them to share some lower level part of the stack of protocols in each of the bundled m-lines. In particular
>DTLS over UDP or DTLS over TCP. (And this is further complicated by ICE, but that is a separate discussion.)
>
>The next most significant constraint is that all the data received via the 5-tuple must be able to be disambiguated 
>by the receiver regarding which MediaDescription(s) it applies to. My attempt to describe that as classifying *packets* 
>turns out to be an over-simplification.
>
>The actual classification probably needs to be layered. If the common protocol to all the bundled MediaDescriptions 
>is packet-oriented, then that is where classification can start. Consider a bundle including RTP, RTCP, and SCTP: the 
>first level of classification will be to classify the packet as one of those. If there is a single SCTP MediaDescription in 
>the bundle then that will be enough to associate SCTP packets with that one. If there are multiple RTP MediaDescriptions 
>then RTP and RTCP packets need further analysis. The RTCP packets are complicated, as has been discussed previously. 
>I still have the sense that RTP packets can be classified to a single MediaDescription, but my understanding is limited 
>so I am prepared to be wrong about that.
>
>The bottom line is that much of this isn't part of the general bundle mechanism. It is specific to the specialization of 
>bundle to RTP. That does need to be written down *somewhere*. It could be part of the bundle draft, as a subsection 
>specific to RTP. Or it could be in some other document.

Some other document.

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Oct 2016 11:46:19 +0200

> limited so I am prepared to be wrong about that.

Yes, you are making it unnecessary complicated because you try to 
interpret RTP packets without considering the RTP stack implementation 
and the work it should do. From my perspective, the SDP needs to be able 
to establish the lower layer filter to be able to dispatch the packets 
to the right RTP stack instance. That is one or more 5-tuples combined 
with a protocol filter, i.e. is this RTP.

Then the RTP stack does it work. And that is particular important to 
consider in the RTCP case. At the end, the RTP stack delivers media data 
associated with RTP streams. It provides meta data, feedback messages 
etc related to that stream. It doesn't need at all to present a raw 
packet, only the information. That higher layer API deliver its data to 
the related application consumer.

> draft, as a subsection specific to RTP. Or it could be in some other

My question to you Paul, what is your view on the latest proposal from 
Christer (yesterday). Is that insufficient, just enough, to detailed, or 
simply not the right thing?

I do think it is good enough.

I promised, and will do an attempt to provide text for the simulcast 
case regarding what type of RTP packet behaviors that is expected to 
occur out from sender, handling in middlebox, and arriving at a 
receiver. Yes, this is not Bundle specific, even if BUNDLE can occur and 
thus needs to be considered. But it is a case which will have multiple 
RTP streams under one SDP media description. Our initial target for this 
text is the MMUSIC simulcast draft. But, I know there is only one more 
week to write it.

cheers

Magnus Westerlund