Subject: [MMUSIC] Associating packets with m-lines in a bundle

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2013 14:26:28 -0400

After all the discussion in the meeting today, I thought it would be 
good to unwind all the indenting and start a new thread on one issue 
that is part of the "demux" problem:

IMO the following should obviously be a truism. I want to know if all agree.

If an O/A exchange negotiates a bundle with multiple m-lines,
then attributes in those m-lines and the associated media sections must 
provide sufficient information to associate each incoming packet on the 
5-tuple to exactly *one* of those m-lines.

(If it doesn't, then there was no point in including those m-lines in 
the bundle.)

For instance a=ssrc, if unique to one m-line, can bind packets with that 
SSRC to the m-line.

If a property such as SSRC is used this way, then there is the 
possibility of receiving packets that don't match any of the m-lines. I 
think we ought to address that, by defining some syntax to specify what 
to do with packets that don't match any m-line. This might be to specify 
one m-line as the default, or that packets that don't match be discarded.

This is not the complete demux problem. Added data and logic may be 
needed to decide what application processing each of those packets may 
require. Once a packet has been associated with an m-line, then some of 
the attributes associated with that m-line may provide may provide 
further information about how to decide how to process the packet. There 
can also be information that comes via other means to qualify packet 
processing.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 May 2013 18:07:29 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

I agree.  I think there are non-legacy situations where this need may
be relaxed, but all interoperation in legacy situations seems to
require discerning the appropriate m= line so information in the SDP
section can be used to identify the particular application processing
stream.

> [...] receiving packets that don't match any of the m-lines. I 

I think that discarding them is the only workable approach.  There's
no reason to assume that sending them to a default m= line would allow
the upper level of demultiplexing to succeed.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 May 2013 11:11:17 -0400

> section can be used to identify the particular application processing

??? There aren't any legacy interoperation situations for bundle.

> the upper level of demultiplexing to succeed.

My thought was that the receiver could signal a "default m-line". This 
would need to be done for each classification criterion. E.g.,

a=ssrc:* ...

would identify the m-line that should be used for otherwise unspecified 
ssrc values.

a=new-header-extension:*

would identify the m-line to use for packets carrying no header 
extension or an undeclared value.

Any packet that still can't be classified after including such wildcards 
would be discarded.

I don't think such wildcarding makes any sense for PT.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 24 May 2013 12:34:50 -0700

On May 23, 2013, at 11:50, "Paul Kyzivat" <[email-masked]> wrote:

> After all the discussion in the meeting today, I thought it would be good to unwind all the indenting and start a new thread on one issue that is part of the "demux" problem:
> 
> then attributes in those m-lines and the associated media sections must provide sufficient information to associate each incoming packet on the 5-tuple to exactly *one* of those m-lines.

[BA] I would argue that this statement needs to be true for *both* RTP and RTCP packets.

> (If it doesn't, then there was no point in including those m-lines in the bundle.)
> 
> For instance a=ssrc, if unique to one m-line, can bind packets with that SSRC to the m-line.

[BA] That is only necessary for RTP (and RTCP) if the PT is not unique to an m line; otherwise PT demux is sufficient for RTP.  For RTCP the situation is more complicated. If we only need to bind RTCP packets from RTP senders, we can build an SSRC to PT to m line table dynamically, based on SSRCs and PTs seen in RTP packets.  However if we get a RR from a source that has not yet sent, we can't map it to an m line without a=ssrc if BUNDLE is in use.  

> If a property such as SSRC is used this way, then there is the possibility of receiving packets that don't match any of the m-lines. I think we ought to address that, by defining some syntax to specify what to do with packets that don't match any m-line. This might be to specify one m-line as the default, or that packets that don't match be discarded.

[BA] I do not believe that a default m line makes sense for RTCP packets that can't be bound to an m line.  Discard, while undesirable, seems like the only option. However this could create problems in diagnostics in some cases.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 10:01:02 +0000

Hi,

I am skeptical towards specifying a default m- line as well, as the media type may not even match :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 24. toukokuuta 2013 22:35
To: Paul Kyzivat
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle

On May 23, 2013, at 11:50, "Paul Kyzivat" <[email-masked]> wrote:

> If an O/A exchange negotiates a bundle with multiple m-lines, then 
> attributes in those m-lines and the associated media sections must provide sufficient information to associate each incoming packet on the 5-tuple to exactly *one* of those m-lines.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 May 2013 11:55:14 -0400

> [BA] I would argue that this statement needs to be true for *both* RTP and RTCP packets.

I don't know enough to comment on that, but it sounds right.

> [BA] That is only necessary for RTP (and RTCP) if the PT is not unique to an m line; otherwise PT demux is sufficient for RTP.  For RTCP the situation is more complicated. If we only need to bind R…

I discussed that elsewhere. There are several features that, when 
present in the SDP and in the packet, can be used to bind the packet to 
the m-line. The PT has the advantage that it is always present in RTP 
m-lines, and is always present in RTP packets. But as you mention, I 
guess it is not present in RTCP packets.

I'll also note that PT doesn't help when bundling non-rtp m-lines, such 
as DTLS/SCTP.

> [BA] I do not believe that a default m line makes sense for RTCP packets that can't be bound to an m line.  Discard, while undesirable, seems like the only option. However this could create problem…

Again, I'll defer to others that know more about this.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 May 2013 12:07:28 -0400

> I am skeptical towards specifying a default m- line as well, as the media type may not even match :)

That problem can occur even without defaults: E.g., I could put an 
a=ssrc with a video m-line, while it turns out that the packets with 
that ssrc are audio packets.

This needs to be part of the matching process. All of the specified 
things must match. That does mean that it should be possible to specify 
a=ssrc:* for both an audio and a video m-line. (And for any other top 
level media types.)

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 May 2013 17:15:03 +0100

On 27 May 2013, at 16:55, Paul Kyzivat wrote:
> I discussed that elsewhere. There are several features that, when present in the SDP and in the packet, can be used to bind the packet to the m-line. The PT has the advantage that it is always present in RTP m-lines, and is always present in RTP packets. But as you mention, I guess it is not present in RTCP packets.

RTCP operates at a different level, so it's not clear why it needs to be bound to an m= line. Use the SSRC to group related RTP and RTCP packets according to source, and match them to a de-jitter buffer and the state for RTCP processing. Use the PT to match those sources with the payload format, m= line and the corresponding decoding and rendering context.

> I'll also note that PT doesn't help when bundling non-rtp m-lines, such as DTLS/SCTP.
> 

Match the RTCP to the RTP based on the SSRC, and process it. There is no need to discard the RTCP in this case.

Yes, you need to define what to do about an RTP source that doesn't match to an m= line, but that's at a higher-layer than the RTP demultiplexing. The issue of if/how/where an RTP source is decoded should be separate to the issue of how the RTP and RTCP packets comprising that source are demultiplexed, fed to a de-jitter buffer, reported in RTCP, etc. 

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 May 2013 17:10:33 -0700

Colin Perkins said: 

RTCP operates at a different level, so it's not clear why it needs to be bound to an m= line. Use the SSRC to group related RTP and RTCP packets according to source, and match them to a de-jitter buffer and the state for RTCP processing. Use the PT to match those sources with the payload format, m= line and the corresponding decoding and rendering context.
[BA] I believe that the stats API requires the mapping of received RTCP packets to a peerConnection object.   Without BUNDLE, there is no issue.  With BUNDLE and without a=ssrc lines, it is possible to receive RTCP RRs from SSRCs that have not yet sent packets, so that it wouldn't be possible yet to group the RTCP and RTP packets according to source and match those sources with the PT and payload format.  So if you had more than one peerConnection object, it might not be clear which object the RTCP packet related to. 
Colin also said: 
Match the RTCP to the RTP based on the SSRC, and process it. There is no need to discard the RTCP in this case.
[BA] What if no RTP has been received from that SSRC, but an RTCP RR arrives?  This is the case I was referring to.   I agree that there is no need to discard the RTCP assuming that an RTP packet from that SSRC arrives first, permitting a mapping of SSRC to PT, corresponding m line and peerConnection object.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 28 May 2013 11:11:19 +0100

> [BA] I believe that the stats API requires the mapping of received RTCP packets to a peerConnection object.   Without BUNDLE, there is no issue.  With BUNDLE and without a=ssrc lines, it is possibl…

Agreed. 

> [BA] What if no RTP has been received from that SSRC, but an RTCP RR arrives?  This is the case I was referring to.   I agree that there is no need to discard the RTCP assuming that an RTP packet f…

Unless you've signalled SSRC values, you won't be able to map an RTCP packet that arrives before the corresponding RTP packet onto an m= line and peerConnection object. However, you'd know that the SSRC of the RTCP packet existed, and is to be avoided for collisions, and you could begin to setup some RTP layer state in the receiver. You'd also mention the SSRC of the RTCP packet in the RTCP RR packets you send (this can be a useful diagnostic if the other side is actually sending RTP, but you're not receiving it for some reason; it's one of the conditions the circuit breaker algorithm checks to detect some types of path failure). 

In summary, you might not be able to make an RTCP packet that arrives before the corresponding RTP packet available to the higher layers of your application (depending on what was signalled), but there is useful processing that can be done with that packet when it's received, and it shouldn't be discarded. 

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