Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

[Magnus Westerlund <[e-mail]>]

Hi,

 

I have just submitted a new version with these changes.

 

/Magnus

 

 

From: Colin Perkins <[e-mail]> 
Sent: den 17 februari 2020 23:41
To: Magnus Westerlund <[e-mail]>
Cc: Roni Even <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

 

Thanks, Magnus – those changes look good to me.

Colin

 

 





On 17 Feb 2020, at 11:04, Magnus Westerlund <[e-mail] <mailto:[e-mail]> > wrote:

 

Hi,

Colin, I do see your point. This slipped past me. I have added to repository the
changes to address your points. 

Roni, I think we could add this about SSRC collision, I don't know how relevant
this is in this particular context. However, I have included this also in the
source in the repo based on that section 3.2 do discuss SSRC collision.  

If we would add both of your changes to the figure it results in this: 


                          |
                          | packets
          +--             v
          |        +------------+
          |        |   Socket   |   Transport Protocol Demultiplexing
          |        +------------+
          |            ||  ||
     RTP  |       RTP/ ||  |+-----> DTLS (SRTP Keying, SCTP, etc)
  Session |       RTCP ||  +------> STUN (multiplexed using same port)
          +--          ||
          +--          ||
          |        (split by SSRC)  +---> Identify SSRC collision
          |      ||    ||    ||    ||
          |(associate with signalling by MID/RID)
          |      ||    ||    ||    ||
    RTP   |     +--+  +--+  +--+  +--+ Jitter buffer,
  Streams |     |PB|  |PB|  |PB|  |PB| process RTCP, etc.
          |     +--+  +--+  +--+  +--+
          +--      |   |      |    |
            (select decoder based on PT)
          +--      |  /       |  /
          |        +----+     | /
          |         /   |     |
  Payload |     +---+ +---+ +---+
  Formats |     |Dec| |Dec| |Dec| Decoders
          |     +---+ +---+ +---+
          +--


Regarding 3.2.2. change. I was a bit uncertain on the extent of the change and
the rest of the sentence. The changes I have made to our source would result in
this paragraph. Is this what you had in mind Colin?

  An RTP receiver receiving a previously unseen SSRC value will
  interpret it
as a new source.  It might in fact be a previously
  existing source that had to
change SSRC number due to an SSRC
  conflict.  Use of the MID extension
  [I-
D.ietf-mmusic-sdp-bundle-negotiation] helps to identify which
  media source the
new SSRC represents and use of the RID extension
  [I-D.ietf-mmusic-rid] helps
to identify what encoding or redundancy
  stream it represents, even though the
SSRC changed.  However, the
  originator of the previous SSRC ought to have
ended the conflicting
  source by sending an RTCP BYE for it prior to starting
to send with
  the new SSRC, making the new SSRC a new source.

Cheers

Magnus



On Sun, 2020-02-16 at 14:27 +0000, Roni Even (A) wrote:



Hi,
I agree with Colin. I also think that split SSRC is when the demultiplexing
should identify SSRC collision , one of the motivation for the rid in SDP
instead of using of a=ssrc attribute




      (split by SSRC)  +------> Identify SSRC collision



Roni





-----Original Message-----
From: Colin Perkins [mailto:[e-mail]]
Sent: Sunday, February 16, 2020 3:46 PM
To: Barry Leiba
Cc: Bernard Aboba; Magnus Westerlund; [e-mail] <mailto:[e-mail]> ; draft-ietf-avtcore-
[e-mail] <mailto:[e-mail]> 
Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along

Hi,

I’m not sure I agree with this change. The -10 version of the draft changes
Figure 1 to be:

                          |
                          | packets
          +--             v
          |        +------------+
          |        |   Socket   |   Transport Protocol Demultiplexing
          |        +------------+
          |            ||  ||
     RTP  |       RTP/ ||  |+-----> DTLS (SRTP Keying, SCTP, etc)
  Session |       RTCP ||  +------> STUN (multiplexed using same port)
          +--          ||
          +--          ||
          | (split by MID/RID and/or SSRC)
          |      ||    ||    ||    ||
          |      ||    ||    ||    ||
    RTP   |     +--+  +--+  +--+  +--+ Jitter buffer,
  Streams |     |PB|  |PB|  |PB|  |PB| process RTCP, etc.
          |     +--+  +--+  +--+  +--+
          +--      |   |      |    |
            (select decoder based on PT)
          +--      |  /       |  /
          |        +----+     | /
          |         /   |     |
  Payload |     +---+ +---+ +---+
  Formats |     |Dec| |Dec| |Dec| Decoders
          |     +---+ +---+ +---+
          +--


Changing “split by SSRC” to "split by MID/RID and/or SSRC”. This is not
correct, and conflicts with Section 9.2 of BUNDLE. What should happen is
that incoming RTP packets are first split into RTP streams identified by
SSRC.
The MID and/or RID, if present, is then used to associate each RTP stream
with an SDP m= line. More like:

                          |
                          | packets
          +--             v
          |        +------------+
          |        |   Socket   |   Transport Protocol Demultiplexing
          |        +------------+
          |            ||  ||
     RTP  |       RTP/ ||  |+-----> DTLS (SRTP Keying, SCTP, etc)
  Session |       RTCP ||  +------> STUN (multiplexed using same port)
          +--          ||
          +--          ||
          |        (split by SSRC)
          |      ||    ||    ||    ||
          |(associate with signalling by MID/RID)
          |      ||    ||    ||    ||
    RTP   |     +--+  +--+  +--+  +--+ Jitter buffer,
  Streams |     |PB|  |PB|  |PB|  |PB| process RTCP, etc.
          |     +--+  +--+  +--+  +--+
          +--      |   |      |    |
            (select decoder based on PT)
          +--      |  /       |  /
          |        +----+     | /
          |         /   |     |
  Payload |     +---+ +---+ +---+
  Formats |     |Dec| |Dec| |Dec| Decoders
          |     +---+ +---+ +---+
          +--

That is, the SSRC remains the RTP stream identifier, and the MID is used to
associate RTP streams with the signalling. The MID doesn’t replace the SSRC
as the stream identifier.


Similarly, in Section 3.2.2:




  Use of the MID extension
  [I-D.ietf-mmusic-sdp-bundle-negotiation] helps to identify which
  media source the apparently new source belongs to and use of the RID
  extension [I-D.ietf-mmusic-rid] helps to identify what encoding or
  redundancy stream it represents, even though the SSRC changed.



should say “Use of the MID extension […] helps to identify which media
source the new SSRC represents”.

Colin







On 14 Feb 2020, at 23:11, Barry Leiba <[e-mail] <mailto:[e-mail]> > wrote:

Thanks, Bernard.

b

On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba


<[e-mail] <mailto:[e-mail]> > wrote:



The comments have been addressed. Thanks!

On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <[e-mail] <mailto:[e-mail]> >


wrote:



Hey, all.  Where are we on this?

Barry

On Thu, Sep 12, 2019 at 7:30 PM Magnus Westerlund
<[e-mail] <mailto:[e-mail]> > wrote:




Hi Barry,



Yes, we have apparently missed Bernard’s review. We will go through it


and respond to it so that we can progress.






Cheers



Magnus Westerlund



From: Barry Leiba <[e-mail] <mailto:[e-mail]> >
Sent: den 12 september 2019 06:35
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
Subject: Moving draft-ietf-avtcore-multiplex-guidelines along



I’m so sorry to have let this document get lost, but I am on it now and
will


move it along without further undue delay.






I’ve had a look at version -09 and like the changes there.  I think they


address most of the comments from Ben and during last call.  But...






I have not seen any response to Bernard’s TSVART review:




https://mailarchive.ietf.org/arch/msg/avt/80u2zgVtdCBDvoRhPmSXRAjufT



A



...and version -09 does not appear to address it.  Did it slip by?  Can
the


editors reply to that review now?






Barry




_______________________________________________
Audio/Video Transport Core Maintenance [e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/avt




--
Colin Perkins

 <https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F> https://protect2.fireeye.com/v1/url?k=dfc6b111-8312bc63-dfc6f18a-86859b2931b3-0cb2385e2a77d464&q=1&e=5f902834-666c-4eca-ac04-c86569fe4505&u=https%3A%2F%2Fcsperkins.org%2F







 

-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto:  <mailto:[e-mail]> [e-mail]
----------------------------------------------------------------------

 



-- 
Colin Perkins
https://csperkins.org/ <https://protect2.fireeye.com/v1/url?k=9e569236-c2df3d5d-9e56d2ad-0cc47ad93ea2-01f39bb5f5ebb0bb&q=1&e=0478ad65-1d88-46e8-a223-66eda54de36f&u=https%3A%2F%2Fcsperkins.org%2F>