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

Colin Perkins <csp@csperkins.org> Mon, 17 February 2020 22:40 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF9C120048; Mon, 17 Feb 2020 14:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tfb_viM6pEp; Mon, 17 Feb 2020 14:40:52 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DFA120041; Mon, 17 Feb 2020 14:40:51 -0800 (PST)
Received: from [81.187.2.149] (port=38672 helo=[192.168.0.66]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1j3p4F-0003fb-Lr; Mon, 17 Feb 2020 22:40:48 +0000
From: Colin Perkins <csp@csperkins.org>
Message-Id: <269C9774-62FD-44BC-A04C-73C810FB9EBA@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D884549-83E6-4993-AF73-60B465C0951A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 17 Feb 2020 22:40:33 +0000
In-Reply-To: <9c7f68d8ae395f0a4d93d7c775cd796013564ee4.camel@ericsson.com>
Cc: Roni Even <roni.even@huawei.com>, "barryleiba@computer.org" <barryleiba@computer.org>, "bernard.aboba@gmail.com" <bernard.aboba@gmail.com>, "draft-ietf-avtcore-multiplex-guidelines.all@ietf.org" <draft-ietf-avtcore-multiplex-guidelines.all@ietf.org>, "avt@ietf.org" <avt@ietf.org>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <CALaySJ+FVGYTStOVYjarR_UtPG5Ksm8hKDD2DdXQLYgQO3zRrg@mail.gmail.com> <DB7PR07MB5736513571AA3CFD7E16574795B00@DB7PR07MB5736.eurprd07.prod.outlook.com> <CALaySJ+xsk-CVmvbwcNP31J8kLsQd4hLfQh1OT-gDBhzsqCaAA@mail.gmail.com> <CAOW+2dvNesLiS8Se64x-ynu5BB626bJNTVrJCasSQ5RGhAx11A@mail.gmail.com> <CALaySJLziO42tM1gtcdLnfA88JExci9nujUDh2sgbv9fJqY8Tg@mail.gmail.com> <14719C1F-0ED6-4FFA-9B09-9632F43B9F71@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD27D914E8@dggemm526-mbx.china.huawei.com> <9c7f68d8ae395f0a4d93d7c775cd796013564ee4.camel@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/v9dl5xmjSmVEJRFZI_wgEelVBvU>
Subject: Re: [AVTCORE] Moving draft-ietf-avtcore-multiplex-guidelines along
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2020 22:40:54 -0000

Thanks, Magnus – those changes look good to me.
Colin



> On 17 Feb 2020, at 11:04, Magnus Westerlund <magnus.westerlund@ericsson.com> 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:csp@csperkins.org]
>>> Sent: Sunday, February 16, 2020 3:46 PM
>>> To: Barry Leiba
>>> Cc: Bernard Aboba; Magnus Westerlund; avt@ietf.org; draft-ietf-avtcore-
>>> multiplex-guidelines.all@ietf.org
>>> 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 <barryleiba@computer.org> wrote:
>>>> 
>>>> Thanks, Bernard.
>>>> 
>>>> b
>>>> 
>>>> On Fri, Feb 14, 2020 at 9:13 AM Bernard Aboba
>>> 
>>> <bernard.aboba@gmail.com> wrote:
>>>> The comments have been addressed. Thanks!
>>>> 
>>>> On Tue, Nov 19, 2019 at 9:01 PM Barry Leiba <barryleiba@computer.org>
>>> 
>>> wrote:
>>>> Hey, all.  Where are we on this?
>>>> 
>>>> Barry
>>>> 
>>>> On Thu, Sep 12, 2019 at 7:30 PM Magnus Westerlund
>>>> <magnus.westerlund@ericsson.com> 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 <barryleiba@computer.org>
>>>>> Sent: den 12 september 2019 06:35
>>>>> To: draft-ietf-avtcore-multiplex-guidelines.all@ietf.org
>>>>> Cc: avt@ietf.org
>>>>> 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 avt@ietf.org
>>>> 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  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>
> ----------------------------------------------------------------------



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