Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B78127871 for ; Mon, 23 Apr 2018 04:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 dMn_7BRnjRXU for ; Mon, 23 Apr 2018 04:09:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 0287C12783A for ; Mon, 23 Apr 2018 04:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1524481781; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z1mZM7Nqk+2MOgSkxwW3aFSFvEx0EX+BATWg2VGdZDc=; b=Mwxl0kBhvExC9J3XQX1NhhdQULHzEfYOSSLUQzUIb43Sm/ExDPuVDxRqnaoq5Sf6 jwjB05OlD3cmvcV94H1ElDsfwV87gc47Byx8oKvg2ag5vFYDTMrOHHKstzUD9wm0 DRXZqNHz8gZrSErJfWjHGr8jdlE8MjUH+M+1veCFuy4=; X-AuditID: c1b4fb3a-eae319c00000795a-f8-5addbef46325 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 36.69.31066.4FEBDDA5; Mon, 23 Apr 2018 13:09:41 +0200 (CEST) Received: from [100.94.45.194] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 23 Apr 2018 13:09:27 +0200 To: Christer Holmberg , Suhas Nandakumar CC: "mmusic@ietf.org" References: From: Magnus Westerlund Message-ID: <3a91f217-3b5e-ffc5-0ab8-03911baebb07@ericsson.com> Date: Mon, 23 Apr 2018 13:09:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CDC27604D16E91806908DB33" Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7q+7XfXejDPr3cllMXf6YxWLn3A5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj9ry/TAX7EiqufJ7O2MDY7N7FyMkhIWAi cWLCXdYuRi4OIYEjjBI3z95nhHA2MUrc3bCeEaRKWMBNYt65BWxdjBwcIgIJEmcavUBMZgF1 iauLgyDKtzBKPLm8lw2knE3AQuLmj0Ywm1fAXuL3shWsIDaLgKrE+ddtTCC2qECMxI+jXSwQ NYISJ2c+AbM5BWwkvl9fAVbDLBAmsa9hPZQtLtH0ZSXYHCEBbYmGpg5WiAeUJK7Pu84ygVFw FpJRs5C0z0LSPgvsbHuJB1vLIMLyEs1bZzND2PoS1+/cZ0UWX8DIvopRtDi1uDg33chIL7Uo M7m4OD9PLy+1ZBMjMBoObvlttYPx4HPHQ4wCHIxKPLz9y+5GCbEmlhVX5h5ilOBgVhLh9dgG FOJNSaysSi3Kjy8qzUktPsQozcGiJM7rlGYRJSSQnliSmp2aWpBaBJNl4uCUamCc03zgyLzD m6ef4Sln4AvX9xM51F+unHd19TKJzkdLTv5be51b/LukeLKN+Mt3ugwn3j46lbH1/Y4U8b0X r1oU9eV9OXlp1+f7qkefXNFPmHDxjUzXMuu5MUGlfcE6lstKynK2z5x82eV5jmzp/hkKwscZ o71vLzjybY+DxRruJ8Kmk/9y1vQUKLEUZyQaajEXFScCAEGcZCCCAgAA Archived-At: Subject: Re: [MMUSIC] ice-options attribute: session- and media-level? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 11:09:45 -0000 --------------CDC27604D16E91806908DB33 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi, I have to say, that I don't quite understand the reasons for changing the ice-options attribute. ECN for RTP's ICE ECN capable path check procedure is not a good argument for the need for media level. The rtp+ecn option is a session level capability attribute, where the a=ecn-capable-rtp attribute indicates which media levels where the path shall be checked. However, if the consensus is to prepare for any potential future option that would use media level ICE options, then okay, but it is difficult to evaluate the changes without any clear requirements. However, the draft do need to be updated. I have to agree with Christer, the normative 2119 language affecting the rtp+ecn option thus results in an updates: RFC 6679. And in addition section 10.2 also seem to update or replace the registration rules in RFC 6336. Which of it is needs to be made explicit. And if one is to allow to use rtp+ecn option on media level then I think you need to define that better. As ecn+rtp option indicates an endpoint capability it is not clear what media level version of that means. You will clearly also need to tackle the meaning of the different option in an bundle group. Cheers Magnus Den 2018-04-23 kl. 09:12, skrev Christer Holmberg: > Hi Suhas, > > >> Section 4.6 of draft-ietf-mmusic-ice-sip-sdp-20 defines the ‘ice-options’ attribute > as both session- and media-level. > >> > >>However, there is no description of what it means to use the attribute on media-level. Does it mean that the > indicated ICE extension is only used for that particular media stream? > > > > [Suhas] Section 10.2 defines explanation of each ice-options attributes for media-level and session level considerations. > > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-10.2 > > That text is VERY confusing  - especially the stuff about “media-level > attributes being MUST be aggregated on session-level”. > > Also, the text seems to define such “aggregation rules" for the > “rtp+ecn” option. If so, shouldn’t the draft update RFC 6679? > > Related to that, the text says that the the “rtp+ecn” option can only > be used on session-level if it applies to all media, otherwise it has > to be on the media-level. How does that fulfil the “MUST aggregate to > session-level” requirement? > > Regards, > > Christer > > > > > Also, section 5.12 of draft-ietf-mmusic-sdp-mux-attributes-16 > indicates the attribute as session only (“S”). > > Is there a need to define it as media-level attribute? > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------CDC27604D16E91806908DB33 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Hi,

I have to say, that I don't quite understand the reasons for changing the ice-options attribute. ECN for RTP's ICE ECN capable path check procedure is not a good argument for the need for media level. The rtp+ecn option is a session level capability attribute, where the a=ecn-capable-rtp attribute indicates which media levels where the path shall be checked. 

However, if the consensus is to prepare for any potential future option that would use media level ICE options, then okay, but it is difficult to evaluate the changes without any clear requirements.

However, the draft do need to be updated. I have to agree with Christer, the normative 2119 language affecting the rtp+ecn option thus results in an updates: RFC 6679. And in addition section 10.2 also seem to update or replace the registration rules in RFC 6336. Which of it is needs to be made explicit.

And if one is to allow to use rtp+ecn option on media level then I think you need to define that better. As ecn+rtp option indicates an endpoint capability it is not clear what media level version of that means. You will clearly also need to tackle the meaning of the different option in an bundle group.

Cheers

Magnus


Den 2018-04-23 kl. 09:12, skrev Christer Holmberg:
Hi Suhas,

>> Section 4.6 of draft-ietf-mmusic-ice-sip-sdp-20 defines the ‘ice-options’ attribute as both session- and media-level.
>>
>>However, there is no description of what it means to use the attribute on media-level. Does it mean that the indicated ICE extension is only used for that particular media stream?
>
> [Suhas] Section 10.2 defines explanation of each ice-options attributes for media-level and session level considerations.

That text is VERY confusing  - especially the stuff about “media-level attributes being MUST be aggregated on session-level”.

Also, the text seems to define such “aggregation rules" for the “rtp+ecn” option. If so, shouldn’t the draft update RFC 6679?

Related to that, the text says that the the “rtp+ecn” option can only be used on session-level if it applies to all media, otherwise it has to be on the media-level. How does that fulfil the “MUST aggregate to session-level” requirement?

Regards,

Christer




 
Also, section 5.12 of draft-ietf-mmusic-sdp-mux-attributes-16 indicates the attribute as session only (“S”).

Is there a need to define it as media-level attribute?

Regards,

Christer


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
--------------CDC27604D16E91806908DB33--