From miguel.a.garcia@ericsson.com Fri Jun 1 04:46:05 2012 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 5F3C721F8505 for ; Fri, 1 Jun 2012 04:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwInMMO-0Wx4 for ; Fri, 1 Jun 2012 04:46:04 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 084D321F8501 for ; Fri, 1 Jun 2012 04:46:03 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-39-4fc8ab7a3144 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3B.CA.00702.A7BA8CF4; Fri, 1 Jun 2012 13:46:03 +0200 (CEST) Received: from [159.107.51.115] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Fri, 1 Jun 2012 13:46:02 +0200 Message-ID: <4FC8AB79.5050808@ericsson.com> Date: Fri, 1 Jun 2012 13:46:01 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3Vrd69Ql/g/7d7BbvL+haTF3+mMXi 2f3vLA7MHlN+b2T1WLLkJ5PHpg/drAHMUVw2Kak5mWWpRfp2CVwZH1/9YC2YzV9xablEA+M0 ni5GTg4JAROJDTd+MELYYhIX7q1n62Lk4hASOMUo0bT6IytIQkhgNaPEtx/lIDavgLbEui9z 2UBsFgEViQ+XPoE1swmYS7Ru3MgOYosKBEvM677JAlEvKHFy5hMwW0RARmLvps3MIDazgIPE 4eZpYLawgJvE5c0b2SDithIX5lxngbDlJba/ncMMcYOmxOSbS5knMPLPQjJ2FpKWWUhaFjAy r2IUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECAzFg1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2M0fMr4w9m1L1ePnnN2mlbMie8F161aUZlalO3Qn3zg4pe 5/CvKTohjHxfQ2vDLvR12V5Z+0vmH4ukC9uZ1gN3HpUsvG0/78mVpKuHJtxrsG+yX9X63Gq3 BC+n+P/OCF3FO99Ut51eF1I3e7lLhMe25ZXJNXd2e27fcevOofOHoh9Of+U+bcEDDyWW4oxE Qy3mouJEAJx68S4TAgAA Cc: Flemming Andreasen , nleung@qualcomm.com Subject: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:46:05 -0000 3GPP SA4 has sent us an LS on RTCP Bandwidth Negotiation. I copy below the text. We should be able to provide them an answer in a reasonable time frame, so please, review it and provide with comments to the list. The chairs will compile a reply text. The original document can be found at the 3GPP web site: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_69/Docs/S4-120810.zip /Miguel and Flemming ------- 3GPP SA4 uses the RTCP bandwidth modifiers (b=RS and b=RR) to control the amount of RTCP bandwidth used in point-to-point VoIP and video telephony sessions. As these parameters were primarily designed for multicast sessions, the calculations in section 2 of RFC 3556 apply to the total RTCP bandwidth for the session, i.e., total bandwidth for all clients sending/receiving RTCP traffic. However, there are no SDP Offer/Answer models defined that use these parameters for the negotiation of the total RTCP bandwidth for point-to-point sessions. To clarify this, SA4 is planning to make the following recommendations in our specifications: 1. The RS and RR values included in the SDP offer should be treated as proposed values for the session and may be modified by the answerer during session negotiation. 2. When generating the SDP answer, the answerer should include the RR and RS values proposed in the SDP offer. The answerer may instead choose to include RR and RS values lower than those proposed in the SDP Offer. 3. The RS and RR values included in the SDP answer should be treated as the negotiated values for the session and should be used to calculate the total RTCP bandwidth for all terminals in the session. Actions: To IETF MMUSIC WG ACTION: SA4 asks MMUSIC WG to review the above recommendations and identify if there are any discrepancies with the practices or understanding in the IETF. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ron.even.tlv@gmail.com Fri Jun 1 09:05:45 2012 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 5049611E80F7 for ; Fri, 1 Jun 2012 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-2.371, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afr6RbEf4p6N for ; Fri, 1 Jun 2012 09:05:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4D511E80EF for ; Fri, 1 Jun 2012 09:05:44 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1459697wgb.13 for ; Fri, 01 Jun 2012 09:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=MsbE9bpZRgQFM53VF4Ai9Rhts5N45WyB46B6P9+nBJU=; b=M426w2r1vkwjaHU0t2ms5zVsAvPIsrVNmcw33jgjU8xyzDYl++rAzI51RZ2C2dP0Fn Q1dR10EtNWZUqlH7uIGcP6P1jVa6vzELcUgcbEfgMbK4FoVoYYVOLHlIx+qmGomdlz3U yG/rvcATvEuv5Trx/nxC97UVqZyJtY6t2shLmKKRh/BiEycsGORn8+HXrAMCxIJnPTM1 4V6xRWS3x6GyhNHlktCq1SsHPMb6d7oC7J8ijtXUUS9PmUIV51t4iFgwnwNYwpRSLTWZ 3O1WDlF/UC5HiQm1/AxUdk0BMWm4zodX3f0hTs08uYjdON2gBBSVTuFfO9qVL3Jp7le5 +uAw== Received: by 10.216.131.223 with SMTP id m73mr2635045wei.76.1338566741075; Fri, 01 Jun 2012 09:05:41 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id gc6sm11540816wib.0.2012.06.01.09.05.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 09:05:39 -0700 (PDT) From: "Roni Even" To: "'Miguel A. Garcia'" , "'mmusic'" References: <4FC8AB79.5050808@ericsson.com> In-Reply-To: <4FC8AB79.5050808@ericsson.com> Date: Fri, 1 Jun 2012 19:03:12 +0300 Message-ID: <4fc8e853.4668b40a.1705.7838@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0/7CPbHBbcj9GuSryynOwke8vg8wAIfduA Content-Language: en-us Cc: 'Flemming Andreasen' , nleung@qualcomm.com Subject: Re: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:05:45 -0000 Hi, In general it is good to add some text about this case since it is not addressed in RFC3556 or RFC3264. I do not see any text that claims that RFC3556 should be used for multicast or broadcast only and not to negotiate for point to point calls. I am not sure about the proposed recommendations. My understanding is that since RTCP unlike RTP is bidirectional channel than the RS and RR values specify the bw required for all endpoints. If the offer had a value for RS and RR, I believe that in a point to point call when we have two sender and two receivers each will get half of the RS and RR bandwidth. The offerer in this case will offer what he believes is needed for him to send RTCP RRs and SRs reports multiply by two so if the answerer thinks he need less bandwidth he should allow for the offerer to have enough RTCP bandwidth at least for his sender reports. So I think that answerer should respond with the same value or possibly higher. otherwise we may need to define that the RR and RS values in the offer represent the bw that offerer wants to use and the values in the answer would be the value the answerer like to use, the total RTCP bw will be the sum of the two values. Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Miguel A. Garcia > Sent: Friday, June 01, 2012 2:46 PM > To: mmusic > Cc: Flemming Andreasen; nleung@qualcomm.com > Subject: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth > Negotiation > > 3GPP SA4 has sent us an LS on RTCP Bandwidth Negotiation. I copy below > the text. > > We should be able to provide them an answer in a reasonable time frame, > so please, review it and provide with comments to the list. The chairs > will compile a reply text. > > The original document can be found at the 3GPP web site: > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_69/Docs/S4-120810.zip > > /Miguel and Flemming > ------- > > 3GPP SA4 uses the RTCP bandwidth modifiers (b=RS and b=RR) to control > the amount of RTCP bandwidth used in point-to-point VoIP and video > telephony sessions. As these parameters were primarily designed for > multicast sessions, the calculations in section 2 of RFC 3556 apply to > the total RTCP bandwidth for the session, i.e., total bandwidth for all > clients sending/receiving RTCP traffic. However, there are no SDP > Offer/Answer models defined that use these parameters for the > negotiation of the total RTCP bandwidth for point-to-point sessions. > > To clarify this, SA4 is planning to make the following recommendations > in our specifications: > > 1. The RS and RR values included in the SDP offer should be treated > as > proposed values for the session and may be modified by the answerer > during session negotiation. > > 2. When generating the SDP answer, the answerer should include the > RR and > RS values proposed in the SDP offer. The answerer may instead choose to > include RR and RS values lower than those proposed in the SDP Offer. > > 3. The RS and RR values included in the SDP answer should be treated > as > the negotiated values for the session and should be used to calculate > the total RTCP bandwidth for all terminals in the session. > > > > Actions: > To IETF MMUSIC WG > > ACTION: SA4 asks MMUSIC WG to review the above recommendations and > identify if there are any discrepancies with the practices or > understanding in the IETF. > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From stewe@stewe.org Fri Jun 1 09:29:36 2012 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 C607A11E80EF; Fri, 1 Jun 2012 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrFc2+YqtqIG; Fri, 1 Jun 2012 09:29:36 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDEC11E80E0; Fri, 1 Jun 2012 09:29:35 -0700 (PDT) Received: from mail30-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 16:29:04 +0000 Received: from mail30-va3 (localhost [127.0.0.1]) by mail30-va3-R.bigfish.com (Postfix) with ESMTP id E8D163C0335; Fri, 1 Jun 2012 16:29:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 5 X-BigFish: PS5(zzc85fh14ffIzz1202h1082kzz8275bhz2fh2a8h668h839he5bhf0ahbe3k) Received-SPF: pass (mail30-va3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail30-va3 (localhost.localdomain [127.0.0.1]) by mail30-va3 (MessageSwitch) id 1338568138869362_31304; Fri, 1 Jun 2012 16:28:58 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.247]) by mail30-va3.bigfish.com (Postfix) with ESMTP id C6D2220048; Fri, 1 Jun 2012 16:28:58 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 16:28:58 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.39]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0164.004; Fri, 1 Jun 2012 16:29:29 +0000 From: Stephan Wenger To: "mmusic@ietf.org" , "clue@ietf.org" Thread-Topic: Incoming liaison statement from MPEG Thread-Index: AQHNQBO2HABb7jVb90Wz1DwtPvoFRQ== Date: Fri, 1 Jun 2012 16:29:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: multipart/alternative; boundary="_000_CBEE3BF48790Cstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [MMUSIC] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:29:36 -0000 --_000_CBEE3BF48790Cstewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, MPEG is working towards codec independent code points, and has sent to MMUS= IC a liaison statement asking for our input. Especially the audio stuff ma= y also be relevant to CLUE, so I copy CLUE here as well. No deadline is pr= ovided, but I note that MPEG meets two weeks before the Vancouver IETF meet= ing and the text they sent us is already a CD, so our time to influence the= ir decisions (if we choose to do so) is limited. MPEG has observed that many code points relevant for audio and video are ge= neric in the sense that they can be applicable to many video or audio codec= s. Recent MPEG (and joint MPEG/ITU) video coding standards have occasional= ly copy-pasted whole sections of code points concerning things like color p= rimaries. They want to avoid this in the future. So they farm out stuff t= hat is historically located in video/audio codec specs, but are likely to b= e common between different codecs. My hunch is that the code point in their draft standard could be translated= to SDP-ish syntax. At this point, it is XML-ish. Stephan --_000_CBEE3BF48790Cstewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <06B6FA0BAA46F44483940DF898AB1155@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,
MPEG is working towards codec independent code points, and has sent to= MMUSIC a liaison statement asking for our input.  Especially the audi= o stuff may also be relevant to CLUE, so I copy CLUE here as well.  No= deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent u= s is already a CD, so our time to influence their decisions (if we choose t= o do so) is limited.
MPEG has observed that many code points relevant for audio and video a= re generic in the sense that they can be applicable to many video or audio = codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have = occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to = avoid this in the future.  So they farm out stuff that is historically= located in video/audio codec specs, but are likely to be common between di= fferent codecs.
My hunch is that the code point in their draft standard could be trans= lated to SDP-ish syntax.  At this point, it is XML-ish.
Stephan
--_000_CBEE3BF48790Cstewesteweorg_-- From ron.even.tlv@gmail.com Fri Jun 1 10:02:44 2012 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 5BC5721F88F5; Fri, 1 Jun 2012 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y90rzDNVmyfv; Fri, 1 Jun 2012 10:02:43 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 290AE21F88F3; Fri, 1 Jun 2012 10:02:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1494597wgb.13 for ; Fri, 01 Jun 2012 10:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=ULAP50B4UExgZZe5RknVi42cwr7WtEYeJC9iMcbQnIc=; b=MWAtmiWPeKWGk3p6nCTiPJXTwtAbP7H23p6wDWZ5BdHjLqfKVNGVulHlPeeLBwmyXJ ptLCua0XJ6/H0zEKkXMkhLbn3t8esnABvjbemNENHlPsQ8p3KLojY/HtmXEazyt7H5D2 xqYzbFUnzg5HM/uokI0DK/BN24UqPHVcZDjP1B1n6RToNNzL6Wl4DQ9rLLwGaOQMJkVY 7jfufQVnLecn2/Jzr2FSHbhSzBKZ1jZMWxWVBBCSwGH7ckczqZ+e523UVkYTINwJFLpK 7WqI5bENns9IHLUifsWyq+dIIXfh3ELnsd9/UFYe30QogfAKV1nTW3zgos2sF/HtRYRv JtOQ== Received: by 10.216.30.213 with SMTP id k63mr2754976wea.59.1338570162217; Fri, 01 Jun 2012 10:02:42 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id fm1sm11822460wib.10.2012.06.01.10.02.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 10:02:41 -0700 (PDT) From: "Roni Even" To: "'Stephan Wenger'" , , References: In-Reply-To: Date: Fri, 1 Jun 2012 20:00:14 +0300 Message-ID: <4fc8f5b1.4166b40a.71d3.ffff876f@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01CD4031.29E28A60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNQBO2HABb7jVb90Wz1DwtPvoFRZblrqog Content-Language: en-us Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:02:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_011B_01CD4031.29E28A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephan, I did not see the liaison statement yet in MMUSIC, so I hope it will be available in time for us to review. >From the example of color primaries I am not sure why we need to have this in SDP. if this is something that is sent as part of the payload do we need to send it also in SDP? Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Friday, June 01, 2012 7:29 PM To: mmusic@ietf.org; clue@ietf.org Subject: [clue] Incoming liaison statement from MPEG Hi all, MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input. Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well. No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited. MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs. Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries. They want to avoid this in the future. So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs. My hunch is that the code point in their draft standard could be translated to SDP-ish syntax. At this point, it is XML-ish. Stephan ------=_NextPart_000_011B_01CD4031.29E28A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephan,

I did not see the liaison statement yet in MMUSIC, so I hope it will = be available in time for us to review.

From the example of color primaries I am not sure why we need to have = this in SDP. if this is something that is sent as part of the payload do = we need to send it also in SDP?

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Friday, June 01, 2012 7:29 = PM
To: mmusic@ietf.org; clue@ietf.org
Subject: = [clue] Incoming liaison statement from = MPEG

 

Hi all,

MPEG is working towards codec independent code points, and has sent to = MMUSIC a liaison statement asking for our input.  Especially the = audio stuff may also be relevant to CLUE, so I copy CLUE here as well. =  No deadline is provided, but I note that MPEG meets two weeks = before the Vancouver IETF meeting and the text they sent us is already a = CD, so our time to influence their decisions (if we choose to do so) is = limited.

MPEG has observed that many code points relevant for audio and video = are generic in the sense that they can be applicable to many video or = audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding = standards have occasionally copy-pasted whole sections of code points = concerning things like color primaries.  They want to avoid this in = the future.  So they farm out stuff that is historically located in = video/audio codec specs, but are likely to be common between different = codecs.

My hunch is that the code point in their draft standard could be = translated to SDP-ish syntax.  At this point, it is = XML-ish.

Stephan

------=_NextPart_000_011B_01CD4031.29E28A60-- From stewe@stewe.org Fri Jun 1 10:17:58 2012 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 A467C21F89AF; Fri, 1 Jun 2012 10:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.473 X-Spam-Level: X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcB6m-PJusIA; Fri, 1 Jun 2012 10:17:57 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9F21F89AD; Fri, 1 Jun 2012 10:17:57 -0700 (PDT) Received: from mail18-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 17:17:26 +0000 Received: from mail18-tx2 (localhost [127.0.0.1]) by mail18-tx2-R.bigfish.com (Postfix) with ESMTP id 0374A420091; Fri, 1 Jun 2012 17:17:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: PS-18(zz9371Ic85eh14ffI168aJzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839he5bhf0ahbe3k) Received-SPF: pass (mail18-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail18-tx2 (localhost.localdomain [127.0.0.1]) by mail18-tx2 (MessageSwitch) id 1338571042113842_32420; Fri, 1 Jun 2012 17:17:22 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.245]) by mail18-tx2.bigfish.com (Postfix) with ESMTP id 0EC9E160054; Fri, 1 Jun 2012 17:17:22 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 17:17:20 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.39]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0164.004; Fri, 1 Jun 2012 17:17:51 +0000 From: Stephan Wenger To: Roni Even , "mmusic@ietf.org" , "clue@ietf.org" Thread-Topic: [clue] Incoming liaison statement from MPEG Thread-Index: AQHNQBO2HABb7jVb90Wz1DwtPvoFRZblrqog//+Qw4A= Date: Fri, 1 Jun 2012 17:17:50 +0000 Message-ID: In-Reply-To: <4fc8f5b1.4166b40a.71d3.ffff876f@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/alternative; boundary="_000_CBEE45B187915stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:17:58 -0000 --_000_CBEE45B187915stewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roni, The statement was sitting in my inbox for a few days, and I have forwarded = it to the secretariat for posting only this morning. Therefore, it is not = yet on the tracker, but should be on the tracker sometime soon. Color primaries, as one example, can actually being sent in SDP today, as p= art of the VUI in the sequence parameter set of H.264. And, color primarie= s are an interoperability point, at least for high quality applications (su= ch as video contribution). If your receiving box does not understand, or c= annot meaningfully process color primaries as sent, then you may get a pict= ure but it will look odd=85 There is also other stuff in the MPEG doc that= is even more needed for interoperability; for example, association of audi= o channels inside the codec bitstream with a speaker location. The key point of the MPEG doc is that they are out farming generic codec th= ings from the audio/video specs into this MPEG-A format, and we (as we are = not using MPEG-A) will probably have to find a way to either encapsulate MP= EG-A XML for cap exchange, or translate the code points to SDP-ish things. Stephan From: Roni Even > Date: Friday, 1 June, 2012 10:00 To: Stephan Wenger >, "mmusic@ietf.= org" >, "cl= ue@ietf.org" > Subject: RE: [clue] Incoming liaison statement from MPEG Stephan, I did not see the liaison statement yet in MMUSIC, so I hope it will be ava= ilable in time for us to review. >From the example of color primaries I am not sure why we need to have this = in SDP. if this is something that is sent as part of the payload do we need= to send it also in SDP? Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: Friday, June 01, 2012 7:29 PM To: mmusic@ietf.org; clue@ietf.org Subject: [clue] Incoming liaison statement from MPEG Hi all, MPEG is working towards codec independent code points, and has sent to MMUS= IC a liaison statement asking for our input. Especially the audio stuff ma= y also be relevant to CLUE, so I copy CLUE here as well. No deadline is pr= ovided, but I note that MPEG meets two weeks before the Vancouver IETF meet= ing and the text they sent us is already a CD, so our time to influence the= ir decisions (if we choose to do so) is limited. MPEG has observed that many code points relevant for audio and video are ge= neric in the sense that they can be applicable to many video or audio codec= s. Recent MPEG (and joint MPEG/ITU) video coding standards have occasional= ly copy-pasted whole sections of code points concerning things like color p= rimaries. They want to avoid this in the future. So they farm out stuff t= hat is historically located in video/audio codec specs, but are likely to b= e common between different codecs. My hunch is that the code point in their draft standard could be translated= to SDP-ish syntax. At this point, it is XML-ish. Stephan --_000_CBEE45B187915stewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3386993DB0B5F34F928E06242EFBE371@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Roni,
The statement was sitting in my inbox for a few days, and I have forwa= rded it to the secretariat for posting only this morning.  Therefore, = it is not yet on the tracker, but should be on the tracker sometime soon.
Color primaries, as one example, can actually being sent in SDP today,= as part of the VUI in the sequence parameter set of H.264.  And, colo= r primaries are an interoperability point, at least for high quality applic= ations (such as video contribution).  If your receiving box does not understand, or cannot meaningfully pr= ocess color primaries as sent, then you may get a picture but it will look = odd=85  There is also other stuff in the MPEG doc that is even more ne= eded for interoperability; for example, association of audio channels inside the codec bitstream with a speaker location.
The key point of the MPEG doc is that they are out farming generic cod= ec things from the audio/video specs into this MPEG-A format, and we (as we= are not using MPEG-A) will probably have to find a way to either encapsula= te MPEG-A XML for cap exchange, or translate the code points to SDP-ish things.
Stephan




From: Roni Even <ron.even.tlv@gmail.com>
Date: Friday, 1 June, 2012 10:00 To: Stephan Wenger <stewe@stewe.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "clue@ie= tf.org" <clue@ietf.org>
Subject: RE: [clue] Incoming liaiso= n statement from MPEG

Stephan,

I did not see the liaison statemen= t yet in MMUSIC, so I hope it will be available in time for us to review.

From the example of color primarie= s I am not sure why we need to have this in SDP. if this is something that = is sent as part of the payload do we need to send it also in SDP?

 

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 7:29 PM
To: mmusic@ietf.org; clue@ietf.org
Subject: [clue] Incoming liaison statement from MPEG

 

Hi all,

MPEG is working towards codec independent c= ode points, and has sent to MMUSIC a liaison statement asking for our input= .  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is pro= vided, but I note that MPEG meets two weeks before the Vancouver IETF meeti= ng and the text they sent us is already a CD, so our time to influence thei= r decisions (if we choose to do so) is limited.

MPEG has observed that many code points rel= evant for audio and video are generic in the sense that they can be applica= ble to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pa= sted whole sections of code points concerning things like color primaries. =  They want to avoid this in the future.  So they farm out stuff t= hat is historically located in video/audio codec specs, but are likely to be common between different codecs.

My hunch is that the code point in their dr= aft standard could be translated to SDP-ish syntax.  At this point, it= is XML-ish.

Stephan

 --_000_CBEE45B187915stewesteweorg_-- From stockhammer@nomor.de Fri Jun 1 12:12:12 2012 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 1659311E80A0; Fri, 1 Jun 2012 12:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZMjwAydT3v6; Fri, 1 Jun 2012 12:12:10 -0700 (PDT) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8E11E80A3; Fri, 1 Jun 2012 12:12:09 -0700 (PDT) X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/8loZf+4JHTB1Fvz/6Kg9 X-RZG-CLASS-ID: mo00 Received: from [192.168.1.14] (188-192-153-251-dynip.superkabel.de [188.192.153.251]) by smtp.strato.de (jorabe mo54) (RZmta 29.10 DYNA|AUTH) with ESMTPA id N05b47o51H6usr ; Fri, 1 Jun 2012 21:12:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_E2C8A1A9-2ABC-4340-A679-78E5A7240025" From: Thomas Stockhammer In-Reply-To: Date: Fri, 1 Jun 2012 21:12:04 +0200 Message-Id: <533FED60-A1DC-4E26-B487-5A90EDDEA163@nomor.de> References: To: Stephan Wenger X-Mailer: Apple Mail (2.1278) Cc: "clue@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:12:12 -0000 --Apple-Mail=_E2C8A1A9-2ABC-4340-A679-78E5A7240025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Stephan, all, a bit more background. MPEG is NOT defining the mapping of the code points to any specific = syntax, such as XML or SDP or a bitstream format. However, it provides = common code points (generally unsigned integers) and common definitions = of the code points. One of the relevant code points for IETF SDP are the frame-compatible = video formats such as SbS or TaB. Others may relate to audio properties = such as the number and configuration of audio channels. One of the main motivations is to avoid copying such code points from = one specification to the next as it happens today for example in video = coding standards.=20 The IETF is encouraged to support the unification of such code points = and by providing input to MPEG and by using references to the MPEG = specification in IETF documents. Thomas On Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote: > Hi Roni, > The statement was sitting in my inbox for a few days, and I have = forwarded it to the secretariat for posting only this morning. = Therefore, it is not yet on the tracker, but should be on the tracker = sometime soon. > Color primaries, as one example, can actually being sent in SDP today, = as part of the VUI in the sequence parameter set of H.264. And, color = primaries are an interoperability point, at least for high quality = applications (such as video contribution). If your receiving box does = not understand, or cannot meaningfully process color primaries as sent, = then you may get a picture but it will look odd=85 There is also other = stuff in the MPEG doc that is even more needed for interoperability; for = example, association of audio channels inside the codec bitstream with a = speaker location. > The key point of the MPEG doc is that they are out farming generic = codec things from the audio/video specs into this MPEG-A format, and we = (as we are not using MPEG-A) will probably have to find a way to either = encapsulate MPEG-A XML for cap exchange, or translate the code points to = SDP-ish things. > Stephan >=20 >=20 >=20 >=20 > From: Roni Even > Date: Friday, 1 June, 2012 10:00=20 > To: Stephan Wenger , "mmusic@ietf.org" = , "clue@ietf.org" > Subject: RE: [clue] Incoming liaison statement from MPEG >=20 > Stephan, > I did not see the liaison statement yet in MMUSIC, so I hope it will = be available in time for us to review. > =46rom the example of color primaries I am not sure why we need to = have this in SDP. if this is something that is sent as part of the = payload do we need to send it also in SDP? > =20 > Roni > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Stephan Wenger > Sent: Friday, June 01, 2012 7:29 PM > To: mmusic@ietf.org; clue@ietf.org > Subject: [clue] Incoming liaison statement from MPEG > =20 > Hi all, > MPEG is working towards codec independent code points, and has sent to = MMUSIC a liaison statement asking for our input. Especially the audio = stuff may also be relevant to CLUE, so I copy CLUE here as well. No = deadline is provided, but I note that MPEG meets two weeks before the = Vancouver IETF meeting and the text they sent us is already a CD, so our = time to influence their decisions (if we choose to do so) is limited. > MPEG has observed that many code points relevant for audio and video = are generic in the sense that they can be applicable to many video or = audio codecs. Recent MPEG (and joint MPEG/ITU) video coding standards = have occasionally copy-pasted whole sections of code points concerning = things like color primaries. They want to avoid this in the future. So = they farm out stuff that is historically located in video/audio codec = specs, but are likely to be common between different codecs. > My hunch is that the code point in their draft standard could be = translated to SDP-ish syntax. At this point, it is XML-ish. > Stephan > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail=_E2C8A1A9-2ABC-4340-A679-78E5A7240025 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Roni,
The statement was sitting in my inbox for a few days, and I have = forwarded it to the secretariat for posting only this morning. =  Therefore, it is not yet on the tracker, but should be on the = tracker sometime soon.
Color primaries, as one example, can actually being sent in SDP = today, as part of the VUI in the sequence parameter set of H.264. =  And, color primaries are an interoperability point, at least for = high quality applications (such as video contribution).  If your receiving box does not understand, or cannot meaningfully = process color primaries as sent, then you may get a picture but it will = look odd=85  There is also other stuff in the MPEG doc that is even = more needed for interoperability; for example, association of audio channels inside the codec bitstream with a speaker = location.
The key point of the MPEG doc is that they are out farming generic = codec things from the audio/video specs into this MPEG-A format, and we = (as we are not using MPEG-A) will probably have to find a way to either = encapsulate MPEG-A XML for cap exchange, or translate the code points to SDP-ish things.
Stephan




From: Roni Even <ron.even.tlv@gmail.com>
Date: Friday, 1 June, 2012 10:00 =
To: Stephan Wenger <stewe@stewe.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "clue@ietf.org" <clue@ietf.org>
Subject: RE: [clue] Incoming = liaison statement from MPEG

Stephan,

I did not see the liaison statement yet in MMUSIC, so I = hope it will be available in time for us to review.

=46rom = the example of color primaries I am not sure why we need to have this in = SDP. if this is something that is sent as part of the payload do we need to send it also in SDP?

 

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 7:29 PM
To: mmusic@ietf.org; clue@ietf.org
Subject: [clue] Incoming liaison statement from = MPEG

 

Hi all,

MPEG is working towards codec = independent code points, and has sent to MMUSIC a liaison statement = asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is = provided, but I note that MPEG meets two weeks before the Vancouver IETF = meeting and the text they sent us is already a CD, so our time to = influence their decisions (if we choose to do so) is limited.

MPEG has observed that many = code points relevant for audio and video are generic in the sense that = they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally = copy-pasted whole sections of code points concerning things like color = primaries.  They want to avoid this in the future.  So they = farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different = codecs.

My hunch is that the code = point in their draft standard could be translated to SDP-ish syntax. =  At this point, it is XML-ish.

Stephan
_______________________________________________
mmusic mailing = list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.






= --Apple-Mail=_E2C8A1A9-2ABC-4340-A679-78E5A7240025-- From mzanaty@cisco.com Fri Jun 1 13:32:55 2012 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 89DEC11E80B0; Fri, 1 Jun 2012 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+XYMJtmDECD; Fri, 1 Jun 2012 13:32:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A5E7511E8097; Fri, 1 Jun 2012 13:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=21680; q=dns/txt; s=iport; t=1338582771; x=1339792371; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=3TywReHcjskJis9iAVryBpvbDYtZB7xamBdrix5oRio=; b=mlmvG4b5rVA+J+bZsOKP7FRKqqpEis/P1fu7CmdV7lYHe36y1kroQrTh igEney3zI1MqSq6Tva4dmvtQbEzfez7JN1QC2LQG3YJjF5fKC91iL8+E4 q3NXfIPUcHIyFzFL2yc8EO0foKJZQCf1qe8wUApFu2c/3eINeMHPsK2ID k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANMmyU+tJXHB/2dsb2JhbABFgkWxeoEHghgBAQEEAQEBDwEJEQM+Cw4CAgEIEQMBAQELBhcBBgEaBgYfCQgBAQQBEggah1sDCwuYIZYFDYlOBIosXxMBhQFgA4gNM5dTgxWBZoJ+gTgJ X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208,217";a="88804382" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 01 Jun 2012 20:32:41 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q51KWfql012700; Fri, 1 Jun 2012 20:32:41 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jun 2012 15:32:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4035.B10307F6" Date: Fri, 1 Jun 2012 15:32:40 -0500 Message-ID: In-Reply-To: <533FED60-A1DC-4E26-B487-5A90EDDEA163@nomor.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [MMUSIC] [clue] Incoming liaison statement from MPEG thread-index: Ac1AKnY11Hmzz/b7SyutA/Bnlq3K1wABEyfg References: <533FED60-A1DC-4E26-B487-5A90EDDEA163@nomor.de> From: "Mo Zanaty (mzanaty)" To: "Thomas Stockhammer" , "Stephan Wenger" X-OriginalArrivalTime: 01 Jun 2012 20:32:41.0234 (UTC) FILETIME=[B11A2F20:01CD4035] Cc: clue@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:32:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4035.B10307F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF documents typically refer to IANA registries for code points that = are used in protocols. Code points that are part of codec payloads that = are opaque to protocols are typically not referenced. =20 The MPEG spec for common code points across codecs would be similar to = an IANA registry across all media formats. Should there be such a = registry kept in sync with MPEG, or should IETF codec payload specs = directly refer to the MPEG spec? =20 Mo =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Thomas Stockhammer Sent: Friday, June 01, 2012 3:12 PM To: Stephan Wenger Cc: clue@ietf.org; mmusic@ietf.org Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG =20 Stephan, all, =20 a bit more background. =20 MPEG is NOT defining the mapping of the code points to any specific = syntax, such as XML or SDP or a bitstream format. However, it provides = common code points (generally unsigned integers) and common definitions = of the code points. =20 One of the relevant code points for IETF SDP are the frame-compatible = video formats such as SbS or TaB. Others may relate to audio properties = such as the number and configuration of audio channels. =20 One of the main motivations is to avoid copying such code points from = one specification to the next as it happens today for example in video = coding standards.=20 =20 The IETF is encouraged to support the unification of such code points = and by providing input to MPEG and by using references to the MPEG = specification in IETF documents. =20 Thomas =20 On Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote: Hi Roni, The statement was sitting in my inbox for a few days, and I have = forwarded it to the secretariat for posting only this morning. = Therefore, it is not yet on the tracker, but should be on the tracker = sometime soon. Color primaries, as one example, can actually being sent in SDP today, = as part of the VUI in the sequence parameter set of H.264. And, color = primaries are an interoperability point, at least for high quality = applications (such as video contribution). If your receiving box does = not understand, or cannot meaningfully process color primaries as sent, = then you may get a picture but it will look odd... There is also other = stuff in the MPEG doc that is even more needed for interoperability; for = example, association of audio channels inside the codec bitstream with a = speaker location. The key point of the MPEG doc is that they are out farming generic codec = things from the audio/video specs into this MPEG-A format, and we (as we = are not using MPEG-A) will probably have to find a way to either = encapsulate MPEG-A XML for cap exchange, or translate the code points to = SDP-ish things. Stephan =20 =20 =20 =20 From: Roni Even Date: Friday, 1 June, 2012 10:00=20 To: Stephan Wenger , "mmusic@ietf.org" = , "clue@ietf.org" Subject: RE: [clue] Incoming liaison statement from MPEG =20 Stephan, I did not see the liaison statement yet in MMUSIC, so I hope it will be = available in time for us to review.=20 >From the example of color primaries I am not sure why we need to have = this in SDP. if this is something that is sent as part of the payload do = we need to send it also in SDP? =20 Roni =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger Sent: Friday, June 01, 2012 7:29 PM To: mmusic@ietf.org; clue@ietf.org Subject: [clue] Incoming liaison statement from MPEG =20 Hi all, MPEG is working towards codec independent code points, and has sent to = MMUSIC a liaison statement asking for our input. Especially the audio = stuff may also be relevant to CLUE, so I copy CLUE here as well. No = deadline is provided, but I note that MPEG meets two weeks before the = Vancouver IETF meeting and the text they sent us is already a CD, so our = time to influence their decisions (if we choose to do so) is limited. MPEG has observed that many code points relevant for audio and video are = generic in the sense that they can be applicable to many video or audio = codecs. Recent MPEG (and joint MPEG/ITU) video coding standards have = occasionally copy-pasted whole sections of code points concerning things = like color primaries. They want to avoid this in the future. So they = farm out stuff that is historically located in video/audio codec specs, = but are likely to be common between different codecs. My hunch is that the code point in their draft standard could be = translated to SDP-ish syntax. At this point, it is XML-ish. Stephan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. =20 =20 =20 =20 =20 ------_=_NextPart_001_01CD4035.B10307F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IETF = documents typically refer to IANA registries for code points that are = used in protocols. Code points that are part of codec payloads that are = opaque to protocols are typically not = referenced.

 =

The MPEG = spec for common code points across codecs would be similar to an IANA = registry across all media formats. Should there be such a registry kept = in sync with MPEG, or should IETF codec payload specs directly refer to = the MPEG spec?

 =

Mo

 =

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Thomas Stockhammer
Sent: Friday, June 01, 2012 3:12 = PM
To: Stephan Wenger
Cc: clue@ietf.org; = mmusic@ietf.org
Subject: Re: [MMUSIC] [clue] Incoming liaison = statement from MPEG

 

Stephan, = all,

 

a = bit more background.

 

MPEG is NOT defining the mapping of the code points to = any specific syntax, such as XML or SDP or a bitstream format. However, = it provides common code points (generally unsigned integers) and common = definitions of the code points.

 

One of the relevant code points for IETF SDP are the = frame-compatible video formats such as SbS or TaB. Others may relate to = audio properties such as the number and configuration of audio = channels.

 

One of the main motivations is to avoid copying such = code points from one specification to the next as it happens today for = example in video coding standards. 

 

The IETF is encouraged to support the unification of = such code points and by providing input to MPEG and by using references = to the MPEG specification in IETF documents.

 

Thomas

 

On = Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote:



Hi Roni,

The statement was sitting in my inbox for a few days, and I have = forwarded it to the secretariat for posting only this morning. =  Therefore, it is not yet on the tracker, but should be on the = tracker sometime soon.

Color primaries, as one example, can actually being sent in SDP today, = as part of the VUI in the sequence parameter set of H.264.  And, = color primaries are an interoperability point, at least for high quality = applications (such as video contribution).  If your receiving box = does not understand, or cannot meaningfully process color primaries as = sent, then you may get a picture but it will look odd…  There = is also other stuff in the MPEG doc that is even more needed for = interoperability; for example, association of audio channels inside the = codec bitstream with a speaker = location.

The key point of the MPEG doc is that they are out farming generic = codec things from the audio/video specs into this MPEG-A format, and we = (as we are not using MPEG-A) will probably have to find a way to either = encapsulate MPEG-A XML for cap exchange, or translate the code points to = SDP-ish things.

Stephan

 

 

 

 

From: Roni Even <ron.even.tlv@gmail.com>
= Date: Friday, 1 June, 2012 10:00
To: Stephan Wenger = <stewe@stewe.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "clue@ietf.org" <clue@ietf.org>
Subject: = RE: [clue] Incoming liaison statement from = MPEG

 

Stephan,

I did not see the liaison statement yet in MMUSIC, so I hope it will = be available in time for us to review.

From the example of color primaries I am not sure why we need to have = this in SDP. if this is something that is sent as part of the payload do = we need to send it also in SDP?

 

Roni

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 = 7:29 PM
To: mmusic@ietf.org; clue@ietf.org
Subject: = [clue] Incoming liaison statement from MPEG

 

Hi all,

MPEG is working towards codec independent code points, and has sent to = MMUSIC a liaison statement asking for our input.  Especially the = audio stuff may also be relevant to CLUE, so I copy CLUE here as well. =  No deadline is provided, but I note that MPEG meets two weeks = before the Vancouver IETF meeting and the text they sent us is already a = CD, so our time to influence their decisions (if we choose to do so) is = limited.

MPEG has observed that many code points relevant for audio and video = are generic in the sense that they can be applicable to many video or = audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding = standards have occasionally copy-pasted whole sections of code points = concerning things like color primaries.  They want to avoid this in = the future.  So they farm out stuff that is historically located in = video/audio codec specs, but are likely to be common between different = codecs.

My hunch is that the code point in their draft standard could be = translated to SDP-ish syntax.  At this point, it is = XML-ish.

Stephan

_______________________________________________
mmus= ic mailing list
mmusic@ietf.org
https://www.ietf.or= g/mailman/listinfo/mmusic

 

---

Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com<= o:p>

No= mor Research GmbH  -  Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 – Umsatzsteuer-ID: = DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo = Viering.

 

 

 

 



 

------_=_NextPart_001_01CD4035.B10307F6-- From mary.ietf.barnes@gmail.com Fri Jun 1 13:55:22 2012 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 8DF1921F89FE for ; Fri, 1 Jun 2012 13:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnhs1Pj6eHV5 for ; Fri, 1 Jun 2012 13:55:20 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBCB21F89F3 for ; Fri, 1 Jun 2012 13:55:20 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2383275ggn.31 for ; Fri, 01 Jun 2012 13:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=L7cSz1MoMbCf76xvgWiCtc4pxHwZ0ednGOvCAMDHBlU=; b=UE6ZiyKW3dmjRIeemoYbbeX12iIpJ9GxtQMlDzMah+98tHEv5/KZoChh8Qi62IZCye 6N40dHi8EW8Riux1ElDV8om7i/NsQLcLszi0cvycaCJTXwVRztj749uJc/i9HXSvFDbQ TS8QrJgHYKIaMCI3k1/ujsK6EaIoxousOkMojDXrhBbN8FUm2NVsXB9S7ZHyWvhFfm12 e088QAEicfOgOgezqaUMqoG6XiY+mgD2Qv6MiWRf4NESr1HAPVYVEw3j41dAMd+Y2cmK w3xt3ray9Zvs4octvhyyXjMOLPrWUFEC1pNGC1ps+u4YneU6oATn48ARTm+lpxFxRvue 4/Fg== MIME-Version: 1.0 Received: by 10.236.136.37 with SMTP id v25mr41281yhi.76.1338584119828; Fri, 01 Jun 2012 13:55:19 -0700 (PDT) Received: by 10.236.73.133 with HTTP; Fri, 1 Jun 2012 13:55:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Jun 2012 15:55:19 -0500 Message-ID: From: Mary Barnes To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=bcaec5314323f6e02504c16f667f Subject: [MMUSIC] Fwd: [clue] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:55:22 -0000 --bcaec5314323f6e02504c16f667f Content-Type: text/plain; charset=ISO-8859-1 I would appreciate it if folks could reply only to the MMUSIC WG mailing list. We are getting messages in the CLUE moderator queue from folks that are not subscribed to CLUE (and likely don't want to be). CLUE folks can follow the discussion on the MMUSIC mailing list. Thanks, Mary. ---------- Forwarded message ---------- From: Stephan Wenger Date: Fri, Jun 1, 2012 at 11:29 AM Subject: [clue] Incoming liaison statement from MPEG To: "mmusic@ietf.org" , "clue@ietf.org" Hi all, MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input. Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well. No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited. MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs. Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries. They want to avoid this in the future. So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs. My hunch is that the code point in their draft standard could be translated to SDP-ish syntax. At this point, it is XML-ish. Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --bcaec5314323f6e02504c16f667f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I would appreciate it if folks could reply o= nly to the MMUSIC WG mailing list. =A0We are getting messages in the CLUE m= oderator queue from folks that are not subscribed to CLUE (and likely don&#= 39;t want to be). =A0CLUE folks can follow the discussion on the MMUSIC mai= ling list.=A0

Thanks,
Mary.=A0

---------- Forwarded message ----------
From: Stephan Wenger <stewe@stewe.org> Date: Fri, Jun 1, 2012 at 11:29 AM
Subject: [clue] Incoming liaison stat= ement from MPEG
To: "mmusic@ietf.org" <mmusic@ietf.org>, &quo= t;clue@ietf.org"= ; <clue@ietf.org&= gt;


Hi all,
MPEG is working towards codec independent code points, and has sent to= MMUSIC a liaison statement asking for our input. =A0Especially the audio s= tuff may also be relevant to CLUE, so I copy CLUE here as well. =A0No deadl= ine is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent u= s is already a CD, so our time to influence their decisions (if we choose t= o do so) is limited.
MPEG has observed that many code points relevant for audio and video a= re generic in the sense that they can be applicable to many video or audio = codecs. =A0Recent MPEG (and joint MPEG/ITU) video coding standards have occ= asionally copy-pasted whole sections of code points concerning things like color primaries. =A0They want to avo= id this in the future. =A0So they farm out stuff that is historically locat= ed in video/audio codec specs, but are likely to be common between differen= t codecs.
My hunch is that the code point in their draft standard could be trans= lated to SDP-ish syntax. =A0At this point, it is XML-ish.
Stephan

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue



--bcaec5314323f6e02504c16f667f-- From stewe@stewe.org Sat Jun 2 09:27:28 2012 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 9506A21F85A8; Sat, 2 Jun 2012 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1vSjHJQFdN4; Sat, 2 Jun 2012 09:27:28 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id A5B5D21F851B; Sat, 2 Jun 2012 09:27:27 -0700 (PDT) Received: from mail112-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 2 Jun 2012 16:26:52 +0000 Received: from mail112-db3 (localhost [127.0.0.1]) by mail112-db3-R.bigfish.com (Postfix) with ESMTP id A5984C06A2; Sat, 2 Jun 2012 16:26:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zzc85fhzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839he5bhf0ahbe3k) Received-SPF: pass (mail112-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail112-db3 (localhost.localdomain [127.0.0.1]) by mail112-db3 (MessageSwitch) id 1338654393464861_25341; Sat, 2 Jun 2012 16:26:33 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.232]) by mail112-db3.bigfish.com (Postfix) with ESMTP id 540811A004C; Sat, 2 Jun 2012 16:26:24 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 2 Jun 2012 16:26:21 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.169]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0164.004; Sat, 2 Jun 2012 16:26:54 +0000 From: Stephan Wenger To: "mmusic@ietf.org" , "clue@ietf.org" Thread-Topic: Incoming liaison statement from MPEG Thread-Index: AQHNQNyFlaDJt4wDLkmBl4jvUXj7hw== Date: Sat, 2 Jun 2012 16:26:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: multipart/alternative; boundary="_000_CBEF8BF28797Fstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [MMUSIC] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 16:27:28 -0000 --_000_CBEF8BF28797Fstewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The liaison statement has been posted as https://datatracker.ietf.org/liais= on/1158/ Replies to mmusic list only, please. Stephan P.s.: if someone could off-list tell me how to set an reply-to header field= in outlook for Mac 2011, I would appreciate that. --_000_CBEF8BF28797Fstewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <5663C03EA9266C4DBBE6F1FA707FDB62@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
The liaison statement has been posted as https://datatracker.ietf.org/liaison/1158/
Replies to mmusic list only, please.
Stephan

P.s.: if someone could off-list tell me how to set an reply-to header = field in outlook for Mac 2011, I would appreciate that.



--_000_CBEF8BF28797Fstewesteweorg_-- From gonzalo.camarillo@ericsson.com Mon Jun 4 01:03:41 2012 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 87C8521F8750 for ; Mon, 4 Jun 2012 01:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.236 X-Spam-Level: X-Spam-Status: No, score=-106.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUBxmcE3OZBq for ; Mon, 4 Jun 2012 01:03:40 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF7221F857D for ; Mon, 4 Jun 2012 01:03:39 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-fb-4fcc6bdacc3a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 11.22.11869.ADB6CCF4; Mon, 4 Jun 2012 10:03:39 +0200 (CEST) Received: from [131.160.36.86] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Mon, 4 Jun 2012 10:03:38 +0200 Message-ID: <4FCC6BD9.90109@ericsson.com> Date: Mon, 4 Jun 2012 11:03:37 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic References: <20120601211245.2757.50764.idtracker@ietfa.amsl.com> In-Reply-To: <20120601211245.2757.50764.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <20120601211245.2757.50764.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvre7t7DP+Bm/O8VlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGc+mXmYvmMVX8eJEN1MD4yGeLkZODgkBE4kbi+exQdhiEhfu rQeyuTiEBE4xSlw4PZURwlnFKNG19CMzSBWvgKbEqy1rwWwWARWJj0s6GUFsNgELiS237rOA 2KICwRLzum+yQNQLSpyc+QTMFhGQkdi7aTNYr7BAscSCfy1gm4UEHCTuXJjOBGJzCjhKXNr8 ih3iIkmJg/+uQdk+Et/vPQKrZwa6oXX7b3YIW15i+9s5zBBztCWWP2thmcAoNAvJ6llIWmYh aVnAyLyKUTg3MTMnvdxIL7UoM7m4OD9Przh1EyMwYA9u+a26g/HOOZFDjNIcLErivNZb9/gL CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGRUr9V4o3HeoOfRRv7b7+rufAk+d6Nm5vKzTnZP p73ckncj2Ugpf8enmOv+yy6Lbq6OaPi9brnCvYmzOKVaMq2L37z81fOIM/LsdmkVo9J/NW0W ipNWVTxnNf6ztTOg7CV7dmNH8bNfXFGNc+b8lrjUEBLz5udV9y06S8XDZtmpvJslkybheECJ pTgj0VCLuag4EQBccEzdJgIAAA== Subject: [MMUSIC] Fwd: New Liaison Statement, "Liaison Statement from SC 29/WG 11 on Coding Independent Media Code Points" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jun 2012 08:03:41 -0000 FYI. Gonzalo -------- Original Message -------- Subject: New Liaison Statement, "Liaison Statement from SC 29/WG 11 on Coding Independent Media Code Points" Date: Fri, 1 Jun 2012 23:12:45 +0200 From: Liaison Statement Management Tool To: Flemming Andreasen , Miguel Garcia A CC: Gonzalo Camarillo , Robert Sparks , Multiparty Multimedia Session Control Discussion List , Stephan Wenger , Stephan Wenger Title: Liaison Statement from SC 29/WG 11 on Coding Independent Media Code Points Submission Date: 2012-06-01 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1158/ From: ISO/IEC JTC 1/SC 29/WG 11 (Stephan Wenger ) To: Multiparty Multimedia Session Control (Flemming Andreasen , Miguel Garcia ) Cc: Gonzalo Camarillo ,Robert Sparks ,Multiparty Multimedia Session Control Discussion List ,Stephan Wenger Reponse Contact: Stephan Wenger Technical Contact: Purpose: For information Body: Attachments: Liaison Statement from SC 29/WG 11 on Coding Independent Media Code Points https://datatracker.ietf.org/documents/LIAISON/liaison-2012-06-01-isoiec-jtc-1sc-29wg-11-mmusic-liaison-statement-from-sc-29wg-11-on-coding-independent-media-code-points-attachment-1.zip SC 29 N 12729 (WG 11 N 12659) https://datatracker.ietf.org/documents/LIAISON/liaison-2012-06-01-isoiec-jtc-1sc-29wg-11-mmusic-liaison-statement-from-sc-29wg-11-on-coding-independent-media-code-points-attachment-2.zip From gonzalo.camarillo@ericsson.com Tue Jun 5 03:58:45 2012 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 57B4821F86D8 for ; Tue, 5 Jun 2012 03:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51PDmufqcivF for ; Tue, 5 Jun 2012 03:58:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D7B8621F86AA for ; Tue, 5 Jun 2012 03:58:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-8a-4fcde662c40f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E6.90.28636.266EDCF4; Tue, 5 Jun 2012 12:58:42 +0200 (CEST) Received: from [131.160.36.86] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Tue, 5 Jun 2012 12:58:42 +0200 Message-ID: <4FCDE661.7020506@ericsson.com> Date: Tue, 5 Jun 2012 13:58:41 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic References: <4FC8AB79.5050808@ericsson.com> In-Reply-To: <4FC8AB79.5050808@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3Vjfp2Vl/g0395hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpQdT5kL9ghWbD1+irGB8S1vFyMnh4SAicTZl5+ZIWwxiQv3 1rN1MXJxCAmcYpT4fqyJHcJZxShx5+w1sCpeAW2JBes2s4HYLAIqEq33pzOB2GwCFhJbbt1n AbFFBYIl5nXfZIGoF5Q4OfMJmC0iICOxd9NmsDnCQDXvNj8Gs4WAZt5/3Qg0k4ODU0BH4vqi eIiDJCUO/rvGDmIzC+hJTLnawghhy0tsfzsHrnX5sxaWCYyCs5Bsm4WkZRaSlgWMzKsYhXMT M3PSyw31Uosyk4uL8/P0ilM3MQLD8uCW37o7GE+dEznEKM3BoiTOy5W0319IID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDo5PdeqmXr/qL3AX85056IXfm3f6Astre6g4PBumWxYXrhedHNL7S 9dv1dvnCP9rPtETydFz/p9cuuLHgsJCNkbKRdelMBsudpR1nS4PbnA8cf7K1u3HHGsMb2Utn xa6ecbU5Zfl2+3ePX3szxSZZRL6atHbiI1Xvo1M7y38Fi6+KUIiN+6FvocRSnJFoqMVcVJwI AKsfBXwZAgAA Subject: Re: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 10:58:45 -0000 Hi, this is the link to the LS in the tracker: https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-3gpp-mmusic-on-rtcp-bandwidth-negotiation-attachment-1.doc Cheers, Gonzalo On 01/06/2012 2:46 PM, Miguel A. Garcia wrote: > 3GPP SA4 has sent us an LS on RTCP Bandwidth Negotiation. I copy below > the text. > > We should be able to provide them an answer in a reasonable time frame, > so please, review it and provide with comments to the list. The chairs > will compile a reply text. > > The original document can be found at the 3GPP web site: > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_69/Docs/S4-120810.zip > > /Miguel and Flemming > ------- > > 3GPP SA4 uses the RTCP bandwidth modifiers (b=RS and b=RR) to control the > amount of RTCP bandwidth used in point-to-point VoIP and video telephony > sessions. As these parameters were primarily designed for multicast > sessions, the calculations in section 2 of RFC 3556 apply to the total > RTCP bandwidth for the session, i.e., total bandwidth for all clients > sending/receiving RTCP traffic. However, there are no SDP Offer/Answer > models defined that use these parameters for the negotiation of the total > RTCP bandwidth for point-to-point sessions. > > To clarify this, SA4 is planning to make the following recommendations in > our specifications: > > 1. The RS and RR values included in the SDP offer should be treated as > proposed values for the session and may be modified by the answerer > during session negotiation. > > 2. When generating the SDP answer, the answerer should include the RR and > RS values proposed in the SDP offer. The answerer may instead choose to > include RR and RS values lower than those proposed in the SDP Offer. > > 3. The RS and RR values included in the SDP answer should be treated as > the negotiated values for the session and should be used to calculate the > total RTCP bandwidth for all terminals in the session. > > > > Actions: > To IETF MMUSIC WG > > ACTION: SA4 asks MMUSIC WG to review the above recommendations and > identify if there are any discrepancies with the practices or > understanding in the IETF. > From emil@sip-communicator.org Tue Jun 5 12:21:42 2012 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 BA68C21F85D7 for ; Tue, 5 Jun 2012 12:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1v8WLOxODpM for ; Tue, 5 Jun 2012 12:21:41 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2BC21F85BE for ; Tue, 5 Jun 2012 12:21:39 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so3488697wib.13 for ; Tue, 05 Jun 2012 12:21:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=D408R+9EejGvP7Lm5k1uAkn2yzLSOI+hat6jPpc+ziY=; b=Eut2IPP0Wqd2HH4sVsr+9nW/FCC9ZLoTXiYlTisHxI4TzNt4ciDWCQA7/DkCrTChxJ FzBJvbDyo/A7FsMmJ1pblVQjrDoYdKKqG6j+3cZS15qoaTfw8dWHvx1qiWsK3zRdDtt9 BsMUdSy46PBmul7qU1krHF6FxLfh4yGEYBQRzScMIXBtdmTRzoPgitM0TbOqgvDbGvH9 A1lR/0c9h3VxIBq7X2j49hMlOGH2J+w92VCPoB7a2eoFeuhZdiMPviwRlIgEz8nvovkT /GXUWmQsy1ezFgLIkCCIJKtZ9kSuLik6teAdnIgv5/tqwN5iYGQuySj9zPMSDySSY7YB ycbQ== Received: by 10.216.226.32 with SMTP id a32mr14090024weq.190.1338924098327; Tue, 05 Jun 2012 12:21:38 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id q6sm29264102wiy.0.2012.06.05.12.21.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jun 2012 12:21:37 -0700 (PDT) Message-ID: <4FCE5C3F.2010209@jitsi.org> Date: Tue, 05 Jun 2012 21:21:35 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmoeRQF2jBb4BVS5IYjOnFNGPVlEzHZGJDhxy4gqpmDX83zQ/PnNPeVS6dRYqePEUkwLEwb Subject: [MMUSIC] Latching: draft re-submission X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 19:21:42 -0000 Hey all, Hadriel, Dan and I have just resubmitted the latching draft we discussed in Paris. New version available here: http://tools.ietf.org/html/draft-ivov-mmusic-latching-00 There have been very few changes, mostly cosmetic, and I guess that the main thing we still need to decide would be whether and how to move it forward (i.e. wihin mmusic, AD sponsored, etc. ). Cheers, Emil -- http://jitsi.org From fandreas@cisco.com Wed Jun 6 14:43:40 2012 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 0724421F8526 for ; Wed, 6 Jun 2012 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnlhzFWlx4qb for ; Wed, 6 Jun 2012 14:43:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EE2FA21F8525 for ; Wed, 6 Jun 2012 14:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=9185; q=dns/txt; s=iport; t=1339019019; x=1340228619; h=message-id:date:from:mime-version:to:cc:subject; bh=IfUypH8Hu9UW95a1pv/iMHinJt0Z6qMxP/6LEjYTNf8=; b=ghYuK9HKTyOKCe5poKn8KjuQuJ9XjMLRTZDc9M4h+Nl4H+RCf1dHqqnv mbW9hp/kcx5MNqdw5ajHYYU7h0gN0YKBQHO6ChP80YADOKgZQhboQkWXo C2bsxkRemsA9bGXuIcMa96/ytew7iueI+TleRdAvuF2M04GKkFLgKaL6g M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALjOz0+tJXG//2dsb2JhbABFgkWxdIEHgjEBGksBPBYYAwIBAgFYAQcBAQUZh2kLmGGfcZEhA5UdjhSBZoJ8 X-IronPort-AV: E=Sophos;i="4.75,726,1330905600"; d="scan'208,217";a="90191717" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jun 2012 21:43:38 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q56LhbOS021426; Wed, 6 Jun 2012 21:43:37 GMT Message-ID: <4FCFCF0A.6010607@cisco.com> Date: Wed, 06 Jun 2012 17:43:38 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-ietf-dccp-udpencap@tools.ietf.org Content-Type: multipart/alternative; boundary="------------020101060202030701040005" Cc: mmusic , Gonzalo Camarillo Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-dccp-udpencap-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:43:40 -0000 This is a multi-part message in MIME format. --------------020101060202030701040005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I am the assigned SDP directorate reviewer for draft-ietf-dccp-udpencap-10 For background on the SDP directorate, please see the FAQ at . Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: -------- There are two minor technical issues with the current draft which should be discussed further. There are also a few minor editorial issues, which can be corrected as part of the publication process. New SDP Information Elements: --------------------------- The draft defines a new "a=dccp-port" attribute Technical: --------- 1) Section 5.2 states: If the "a=rtcp:" attribute [RFC3605] is used, then the signalled port is the DCCP port used for RTCP. Hi

I am the assigned SDP directorate reviewer for draft-ietf-dccp-udpencap-10

For background on the SDP directorate, please see the FAQ at <http://www.ietf.org/iesg/directorate/sdp.html>.

Please wait for direction from your document shepherd or AD before posting a new version of the draft.


Summary:
--------
There are two minor technical issues with the current draft which should be discussed further.

There are also a few minor editorial issues, which can be corrected as part of the publication process.



New SDP Information Elements:
---------------------------
The draft defines a new "a=dccp-port" attribute



Technical:
---------
1) Section 5.2 states:
<quote>
   If the "a=rtcp:" attribute [RFC3605] is used, then the signalled port is the DCCP port used for RTCP.
</quote
I think this warrants further discussion. How will this work if non-consecutive ports are to be used for DCCP-UDP itself and how will this work if a middlebox looks at the "a=rtcp" attribute and assumes the currently defined behavior in RFC 3605, which would effectively provide it with the port information for the (UDP native) RTCP stream today ?


2) Section 5.4 discusses how to negotiate DCCP-UDP versus native DCCP (DCCP-STD) and in particular considers only the use of ICE for this (with the details of the encoding "left for future study"). While this may be appropriate for the basic use of DCCP-UDP versus DCCP-STD, it is arguably not appropriate when it comes to negotiating different RTP profiles within each of these (which are defined in this draft). SDP Capability Negotiation would be more suitable for this, as described in RFC 5939 Section 3.7. At a minimum, a reference to that effect and those considerations should be provided.


3) Section 3.8, 4th paragraph:
s/a DCCP-UDP server must therefore/a DCCP-UDP MUST therefore/ ??
                                              ^^^^                         


Editorial:
--------
Various instances of repeat words and a few spelling errors that should be caught by a spell-checker.

Also:
- Section 5.1, first paragraph:
s/(from [RFC4566]:/(from [RFC4566]):/
                                   ^
- Section 5.4, second paragraph
s/DCCPx/DCCP/

- Section 6, last paragraph:
s/A firewall than/A firewall that/
                                ^   

- ICE-TCP is now RFC 6544


Thanks

-- Flemming


--------------020101060202030701040005-- From nigel.pattinson@kaseya.com Thu Jun 7 14:37:53 2012 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 6AF5C21F8681 for ; Thu, 7 Jun 2012 14:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDV7iaPa+bCJ for ; Thu, 7 Jun 2012 14:37:52 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with SMTP id 4A3CB21F8690 for ; Thu, 7 Jun 2012 14:37:50 -0700 (PDT) Received: from mail-ob0-f172.google.com ([209.85.214.172]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT9EfLoMgpZZsROpLWVsL+uSnMtB8oZKB@postini.com; Thu, 07 Jun 2012 14:37:51 PDT Received: by obbeh20 with SMTP id eh20so2081295obb.17 for ; Thu, 07 Jun 2012 14:37:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=EUw8ymnAOkGznf0/r/Vk9/xm7dsg88lGZqXOeu9XV3c=; b=W8hTdyAEOfcUGFI455r8nwy3g6QIE9zDWmzLDA8mED1Hpz4TXu8AOjM92cfU75FMZC cgeHIxwOzNXavaK/+B6bpDNcZlI0pBfMMi73jBcSPQ3gc0lcHOdISRkH8CRYCt20T3id KCyNSeSwXu2E+jG5DBlf+XR6/ET4gPdCp4mNpaHZyvqmKvVrqZIteugWeGAY7nzeEkrF M15WifAycVAW7kZGmGbdjHz9MEn1jy+fl1d5EOSWsXMveX85TzLXa2k9812lcFOkGFyd h/f4hLk2QRN6QvilfssqAIAzPbobKr02fIFVRQxo2qPq7hq99WwK6AskjTG88cq4sAHL 0Skw== MIME-Version: 1.0 Received: by 10.60.29.169 with SMTP id l9mr3836081oeh.14.1339105069830; Thu, 07 Jun 2012 14:37:49 -0700 (PDT) Received: by 10.182.17.69 with HTTP; Thu, 7 Jun 2012 14:37:49 -0700 (PDT) Date: Fri, 8 Jun 2012 09:37:49 +1200 Message-ID: From: Nigel Pattinson To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff2566601134d04c1e8b211 X-Gm-Message-State: ALoCoQl7i9jdv2S0/VtOnuHAObyrxGwqXfly2B+Rtg4isF/Mld6OWqzr0orKAoppgiyyo8Y/d8xd Subject: [MMUSIC] Comments on ICE-TCP specification RFC 6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:40:29 -0000 --e89a8ff2566601134d04c1e8b211 Content-Type: text/plain; charset=ISO-8859-1 Hello all In our company we have just implemented support for ICE-TCP, and in our opinion there are some areas of the specification which could use some clarification. Note that our implementation is designed to be used in an XMPP/Jingle context rather than with SIP, which potentially makes a difference in some of the areas mentioned below. The specification makes no mention of foundations for TCP candidates. 4.1.1.3 in [RFC5245] specifies that TCP foundations must be different from UDP foundations, but it is unclear whether or not passive, active, and simultaneous open candidates should have distinct foundations. The same is true for NAT-assisted and tunneled candidate types - should these have distinct foundations from server-reflexive/relayed candidates ? We have guessed that in all cases they should be distinct. 4.1.1.4 in [RFC5245] states that server reflexive candidates should be kept alive until ICE processing completes. 11.2 in RFC 6544 does not contradict this, but does not clarify it either. This implies that TCP connections to a STUN server should be kept open for this duration, with STUN binding requests being sent at intervals. It is not clear to us that doing so would have any benefit, but we are not NAT experts. Either way it would be good if the ICE-TCP specification made it clear whether or not this was necessary or desirable. When the offerer has relayed candidates obtained from a TURN server, it may not be possible to ensure that permissions are created for those passive candidates prior to the peer attempting to connect. This may result in failure of the peer's active check, and hence possibly in failure of ICE as a whole. The same basic problem can happen in ICE-UDP, but the UDP check would almost certainly be retried at a time when the permissions are in place, and so should succeed eventually. The situation could be exacerbated by the Jingle recommendation that candidates are sent to the peer as soon as they are discovered - in this case even the answerer's relayed candidates may not have the permissions in place when they are needed. We're not sure if there is a foolproof solution to these problems, but we do feel that the potential for failures should at least be mentioned. 6.2 states that candidate pairs with a tcp passive local candidate should be pruned from the checklist. This clearly makes sense, but has some undesirable consequences in the following situation. Imagine that both agents are on the same network, so all connectivity checks will succeed. The top priority candidate pair in each agent's check list will most likely have a local host active candidate and a remote host passive candidate, since all pairs with a local passive candidate have been pruned. It is quite likely that the controlled agents first check request will be received by the controlling agent before the latter has had a chance to initiate its first check. If this is the case, the controlling agent will reply to the check, add a candidate pair with a local passive candidate and a remote active candidate to its check list, and trigger a check for that candidate pair. Meanwhile the controlled agent will initiate further lower-priority checks, all of which will succed and cause the controlling agent to trigger matching checks. Unless the controlling agent has a shorter _Ta than the offerer, the result can be that the controlling agent spends all its time sending triggered checks, and only gets a chance to initiate checks once the controlled agent has exhausted its check list. The downside to this is that candidate pairs with a controlling active candidate and a controlled passive candidate exist only in the controlling agent's check list, so these will not be checked at all until all pairs in the controlled agent's check list have been checked. What is worse, with the suggested priority calculcations, the highest priority pair will be just such a pair, and since aggressive nomination is not being used, it is likely that the highest priority check needs to be completed before the ICE session can be regarded as successful. We do not have an ideal solution for this, but switching the recommended active and passive direction pref values would make it unlikely that the highest priority check would have a controlling active candidate and a controlled passive candidate. 7.1 states that for tcp-active candidates, unallocated ports should be used. This may result in many port allocations, so we wonder whether it would be preferable to reuse the same port for all connections made from a specific tcp-active candidate (where supported by the host OS, of course). Sections 7.1 and 7.2 both note that a peer-reflexive candidate will 'typically' be produced. In 7.1 this is in reference to a STUN response received on an active TCP candidate, whereas in 7.2 it is in reference to a STUN request received on a passive TCP candidate. It is unclear to us whether the wording is intended to mean that this is different to the equivalent case in UDP, where a peer-reflexive candidate might, but would not 'typically', be produced. The only difference between TCP and UDP that we can see in this area is that the port actually used for active TCP candidates differs from that advertised, since all active TCP candidates are offered with 9 as the port number. We assume that this is the core reason behind the wording used, but think that it would be better if the specification explicitly stated this. We also believe that it is possible to correctly identify the correct active TCP candidate despite the lack of explicit port number information, simply by treating 9 as a wildcard that matches any port. Doing so has the benefit that all the information held against the candidate (especially priority and foundation) can be used as intended, whereas if a new peer-reflexive candidate is created this information will always be ignored for active TCP candidates. Currently our implementation does this wildcard matching, so will only produce peer-reflexive candidates in the same situations it would do if using UDP. 11.1 states that connections should be reopened if they have dropped or been closed for some reason, and have media that needs to be sent. This might make sense in an RTP context, but seems very dubious to us in the more general TCP case as it violates the normal reliability guarantees that TCP supplies. We think this requires further thought and at the very least should be configurable. Thanks for your time Nigel Pattinson --e89a8ff2566601134d04c1e8b211 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all

In our company we have just im= plemented support for ICE-TCP, and in our opinion there are some areas of t= he specification which could use some clarification. Note that our implemen= tation is designed to be used in an XMPP/Jingle context rather than with SI= P, which potentially makes a difference in some of the areas mentioned belo= w.

The specification makes no mention of foundations for T= CP candidates. 4.1.1.3 in [RFC5245] specifies that TCP foundations must be = different from UDP foundations, but it is unclear whether or not passive, a= ctive, and simultaneous open candidates should have distinct foundations. T= he same is true for NAT-assisted and tunneled candidate types - should thes= e have distinct foundations from server-reflexive/relayed candidates ? We h= ave guessed that in all cases they should be distinct.

4.1.1.4 in [RFC5245] states that server reflexive candi= dates should be kept alive until ICE processing completes. 11.2 in RFC 6544= does not contradict this, but does not clarify it either. This implies tha= t TCP connections to a STUN server should be kept open for this duration, w= ith STUN binding requests being sent at intervals. It is not clear to us th= at doing so would have any benefit, but we are not NAT experts. Either way = it would be good if the ICE-TCP specification made it clear whether or not = this was necessary or desirable.

When the offerer has relayed candidates obtained from a= TURN server, it may not be possible to ensure that permissions are created= for those passive candidates prior to the peer attempting to connect. This= may result in failure of the peer's active check, and hence possibly i= n failure of ICE as a whole. The same basic problem can happen in ICE-UDP, = but the UDP check would almost certainly be retried at a time when the perm= issions are in place, and so should succeed eventually. The situation could= be exacerbated by the Jingle recommendation that candidates are sent to th= e peer as soon as they are discovered - in this case even the answerer'= s relayed candidates may not have the permissions in place when they are ne= eded. We're not sure if there is a foolproof solution to these problems= , but we do feel that the potential for failures should at least be mention= ed.

6.2 states that candidate pairs with a tcp passive loca= l candidate should be pruned from the checklist. This clearly makes sense, = but has some undesirable consequences in the following situation. Imagine t= hat both agents are on the same network, so all connectivity checks will su= cceed. The top priority candidate pair in each agent's check list will = most likely have a local host active candidate and a remote host passive ca= ndidate, since all pairs with a local passive candidate have been pruned. I= t is quite likely that the controlled agents first check request will be re= ceived by the controlling agent before the latter has had a chance to initi= ate its first check. If this is the case, the controlling agent will reply = to the check, add a candidate pair with a local passive candidate and a rem= ote active candidate to its check list, and trigger a check for that candid= ate pair. Meanwhile the controlled agent will initiate further lower-priori= ty checks, all of which will succed and cause the controlling agent to trig= ger matching checks. Unless the controlling agent has a shorter _Ta than th= e offerer, the result can be that the controlling agent spends all its time= sending triggered checks, and only gets a chance to initiate checks once t= he controlled agent has exhausted its check list. The downside to this is t= hat candidate pairs with a controlling active candidate and a controlled pa= ssive candidate exist only in the controlling agent's check list, so th= ese will not be checked at all until all pairs in the controlled agent'= s check list have been checked. What is worse, with the suggested priority = calculcations, the highest priority pair will be just such a pair, and sinc= e aggressive nomination is not being used, it is likely that the highest pr= iority check needs to be completed before the ICE session can be regarded a= s successful. We do not have an ideal solution for this, but switching the = recommended active and passive direction pref values would make it unlikely= that the highest priority check would have a controlling active candidate = and a controlled passive candidate.

7.1 states that for tcp-active candidates, unallocated = ports should be used. This may result in many port allocations, so we wonde= r whether it would be preferable to reuse the same port for all connections= made from a specific tcp-active candidate (where supported by the host OS,= of course).

Sections 7.1 and 7.2 both note that a peer-reflexive ca= ndidate will 'typically' be produced. In 7.1 this is in reference t= o a STUN response received on an active TCP candidate, whereas in 7.2 it is= in reference to a STUN request received on a passive TCP candidate. It is = unclear to us whether the wording is intended to mean that this is differen= t to the equivalent case in UDP, where a peer-reflexive candidate might, bu= t would not 'typically', be produced. The only difference between T= CP and UDP that we can see in this area is that the port actually used for = active TCP candidates differs from that advertised, since all active TCP ca= ndidates are offered with 9 as the port number. We assume that this is the = core reason behind the wording used, but think that it would be better if t= he specification explicitly stated this. We also believe that it is possibl= e to correctly identify the correct active TCP candidate despite the lack o= f explicit port number information, simply by treating 9 as a wildcard that= matches any port. Doing so has the benefit that all the information held a= gainst the candidate (especially priority and foundation) can be used as in= tended, whereas if a new peer-reflexive candidate is created this informati= on will always be ignored for active TCP candidates. Currently our implemen= tation does this wildcard matching, so will only produce peer-reflexive can= didates in the same situations it would do if using UDP.

11.1 states that connections should be reopened if they= have dropped or been closed for some reason, and have media that needs to = be sent. =A0This might make sense in an RTP context, but seems very dubious= to us in the more general TCP case as it violates the normal reliability g= uarantees that TCP supplies. We think this requires further thought and at = the very least should be configurable.

Thanks for your time
Nigel Pattinson

--e89a8ff2566601134d04c1e8b211-- From fandreas@cisco.com Fri Jun 8 14:24:10 2012 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 31F1021F86DB for ; Fri, 8 Jun 2012 14:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLiCTBS5JSRm for ; Fri, 8 Jun 2012 14:24:09 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D47F921F86D9 for ; Fri, 8 Jun 2012 14:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=4452; q=dns/txt; s=iport; t=1339190648; x=1340400248; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q+MBjefLArZ3ErjbCDBEVIm2fqSDGCOcpfT9hU2IG1M=; b=USG/kvfgMsrrmA/huKANMBzlXCIr9U7d0ck6s+dMhLB1rXLTz4RM4A5p epnSYTYMgg8g5eGwDakrU7bJsZMVCrA+qHQBrrKCem7C2vg7HQwvHThWM Ylv988+j56CF8Bmw7iU4TrRF6/efSt6ad6ndC2/uKHRGNCiW8clSFNGq5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACNt0k+tJXHA/2dsb2JhbABFtFeBB4IYAQEBBBIBChs2CgEQCxgJCwsPCQMCAQIBRAEGDQEHAQEeh2mZG59biyYaC4VbA5UejhWBZoIWZoFD X-IronPort-AV: E=Sophos;i="4.75,739,1330905600"; d="scan'208";a="90866775" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jun 2012 21:24:07 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q58LO6JT032097; Fri, 8 Jun 2012 21:24:06 GMT Message-ID: <4FD26D77.9070500@cisco.com> Date: Fri, 08 Jun 2012 17:24:07 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4FBB701D.8030702@ericsson.com> In-Reply-To: <4FBB701D.8030702@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-sdp-cs.authors@tools.ietf.org, mmusic Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-cs-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:24:10 -0000 Hi I have reviewed the above draft and have some comments (as chair) that will need to be addressed before we can move this one forward: Technical Comments ============= 1) The document defines the "E164" 'addrtype' type as well as the "-" 'addrtype' to be used in the "c=" line and wants to register these with IANA. As it turns out, RFC 3108 also defined these, however they never got registered with IANA. While the '-' seems to be defined similarly, the syntax for the "164" differs between the two, which is obviously a problem, not least considering RFC 3108 is Standards Track. Also, for some reason the cs-draft lists RFC 3108 as a normative reference, but it does not provide any normative text for its use. 2) The "cs-correlation" attribute includes an extension mechanism, however there is no description of how to use it, or any offer/answer procedures associated with it. For example, what do cs-draft implementations do if they encounter one or more unknown extensions. - Section 5.2.1 OLD: Note that and/or should not be NEW: Note that and/or MUST NOT be - Section 5.2.3.1 Can there be at most one cs-correlation attribute per media description ? If not, are multiple occurrences concatenated ? - Section 5.2.3.3 OLD: bit appearing first in the binary data shall be most significant NEW: bit appearing first in the binary data SHALL be most significant - Section 5.3.1 OLD: circuit-switched bearer is set up should be negotiated NEW: circuit-switched bearer is set up MUST be negotiated - Section 5.6.1 If an Offerer does not know its international E.164 number, it MUST set the 'a=setup' attribute to the value 'active'. If the Offerer knows its international E.164 number, it MUST set the value to either 'actpass' or 'passive'. There may be reasons for an endpoint to not wanting to be passive, and hence should we change the last "MUST" to "SHOULD" ? - Section 5.6.2 After generating and sending the Answer, if the Answerer became the active party, it There is a race conditition between this answer making it back to the offerer and the correlated incoming call being received by the offerer. While this race condition may seem unlikely in practice, it does exist and needs to be called out (and ideally with workarounds). - Section 5.6.2 OLD: o if the SDP Answer contained a value for the "callerid" subfield, must set NEW: o if the SDP Answer contained a value for the "callerid" subfield, MUST set - Section 7 (Security Considerations) The mechanism defined in this document effectively allows an entity A to cause another entity B to generate PSTN calls as A desires. There are third-party attack considerations and potential toll charge concerns that need to be addressed as part of that. Editorial Comments ============ - Section 5.6.2, third paragraph If the Answerer is aware of its international E.164 number, it MUST include the "a=setup" attribute in the Answer and set it to value "passive" or "holdconn". Add: The Answerer MUST also include its E.164 number in the "c=" line. Section 5.6.2 The Answerer MUST select those correlation mechanisms from the Offer it supports, and include an "a=cs-correlation" attribute line in the Answer containing those mechanisms it supports. Must the answerer select all the ones it supports or just a non-empty subset (clarify) ? - Section 8.4 Per RFC 4566, Section 8.2.2, when a new "proto" value is registered Registrations MUST also define the rules by which their "fmt" namespace is managed (see below). Section 5.2.2 does describe this, however it would be desirable to either describe it here as well or include a pointer to Section 5.2.2. - I have some additional minor editorial comments that I will send in a marked-up copy of the doc off-line. Thanks -- Flemming On 5/22/12 6:53 AM, Miguel A. Garcia wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-sdp-cs-11.txt > > The WGLC ends on June 5th, 2012. > > Please reply to this e-mail to send comments, so that the authors and > the mailing list are all copied. > > /Miguel From fandreas@cisco.com Fri Jun 8 15:37:33 2012 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 353F711E8154 for ; Fri, 8 Jun 2012 15:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO17B8zRw2Kd for ; Fri, 8 Jun 2012 15:37:32 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9211E8091 for ; Fri, 8 Jun 2012 15:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=4466; q=dns/txt; s=iport; t=1339195052; x=1340404652; h=message-id:date:from:mime-version:to:cc:subject; bh=Gmizwd6+fcQ6lFD2dlyL56TDRl17+wEFw8t3HS7vqKU=; b=G4RhaH5Dmbh+ED4J091u9xYYrQ4lLfsQDJjwujbzFRi9dEh59lFspbRt bbpKgcyetiHgyet+pyGwqzzwOg8nPrMvuGh0jvLtkPmUa9koDn+3qydq5 qKFef4EkCF7l5xZKrRxAO9epja2OjuhczQ620wcdn1sskK7Ga+wZ0phTO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIl90k+tJXG//2dsb2JhbABFgkWIbqkkgQeCMQFlAR8dFhgDAgECAUsNAQcBAQUZh2kLmRGfWYsmGoVmA5UejhWBZoJ8gUM X-IronPort-AV: E=Sophos;i="4.75,739,1330905600"; d="scan'208,217";a="90687631" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jun 2012 22:37:31 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q58MbVmG027384; Fri, 8 Jun 2012 22:37:31 GMT Message-ID: <4FD27EAB.1090102@cisco.com> Date: Fri, 08 Jun 2012 18:37:31 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------000208010409090301040305" Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:37:33 -0000 This is a multi-part message in MIME format. --------------000208010409090301040305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi As part of the MMUSIC charter we have the following milestone Sep 2012 Submit Considerations for using SDP offer/answer with middleboxes for BCP and we have the middleboxes draft http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt to address that milestone. As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the document and the potential target as further explained in the following e-mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html A set of (initial) technical comments were also provided by Hadriel in the following e-mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html For now, the chairs would like to focus on the first set of questions above, i.e. what is the goal and potential target audience for the document and is there still value in pursuing it ? The chairs would like to poll the group for opinions and interest in this. Specific areas to consider: 1) What is the target audience for the document ? 2) Do people believe that the target audience will read and/or care about this document at this point ? 3) Should the document be a BCP or Informational ? Thanks -- Miguel & Flemming (as chairs) --------------000208010409090301040305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

As part of the MMUSIC charter we have the following milestone

Sep 2012 Submit Considerations for using SDP offer/answer with middleboxes for BCP

and we have the middleboxes draft

    http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt

to address that milestone.

As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the document and the potential target as further explained in the following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html

A set of (initial) technical comments were also provided by Hadriel in the following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html

For now, the chairs would like to focus on the first set of questions above, i.e. what is the goal and potential target audience for the document and is there still value in pursuing it ?


The chairs would like to poll the group for opinions and interest in this. Specific areas to consider:

1) What is the target audience for the document ?

2) Do people believe that the target audience will read and/or care about this document at this point ?

3) Should the document be a BCP or Informational ?


Thanks

-- Miguel & Flemming (as chairs)






--------------000208010409090301040305-- From fandreas@cisco.com Fri Jun 8 16:09:59 2012 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 91FE321F865A for ; Fri, 8 Jun 2012 16:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0xO5ex8MZBA for ; Fri, 8 Jun 2012 16:09:58 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 50BBE21F865C for ; Fri, 8 Jun 2012 16:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=10461; q=dns/txt; s=iport; t=1339196998; x=1340406598; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=lqG9y7EL3m1DyqZRzQBvFI0DFpVZW5d6Eav9goQ9QHM=; b=bONtlJIJG2uPw/YS0/aIJtjkiKY/Q+W0GraOhBjZfFhmxItA6h5ynoi/ 7l/4NQow09a2kSdLSebP/bsNMLLVyTRscK4HX0DFjx8qLEYGj3mtc0h3U Q301Mt11z6hysYSJPq4k0aMeVp1jCyehUIWD+8G7S/YC8x0bu6724353B 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKaF0k+tJV2Y/2dsb2JhbABFgkWIbqkkgQeCGAEBAQQBAQEPAVsKARALEgYJFg8JAwIBAgEVIg4GDQEFAgEBBRmHaQuZDZ9UiyYahWYDlR6OFYFmgnyBQw X-IronPort-AV: E=Sophos;i="4.75,739,1330905600"; d="scan'208,217";a="90931222" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jun 2012 23:09:57 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q58N9uq5018973; Fri, 8 Jun 2012 23:09:57 GMT Message-ID: <4FD28645.5000702@cisco.com> Date: Fri, 08 Jun 2012 19:09:57 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic References: <4FD27EAB.1090102@cisco.com> In-Reply-To: <4FD27EAB.1090102@cisco.com> Content-Type: multipart/alternative; boundary="------------090907050707070408050108" Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 23:09:59 -0000 This is a multi-part message in MIME format. --------------090907050707070408050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some comments (as an individual) A lot of the SIP and SDP work started out with a somewhat "purist" Internet view of the world, where things such as middleboxes were not considered. As other standards and industry organizations became interested in using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, there was, at least initially, not a great deal of knowledge about these architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that such middleboxes may break end-to-end transparency and hence there was a desire to try and alleviate that. To that effect, it was seen as useful to have a document that could a) Explain what/how middleboxes might be operating in these architectures b) Provide guidelines as to how such middleboxes could minimize (ideally avoid) impacting end-to-end transparency and/or how protocols could be used to try and alleviate any impact such middleboxes might have. The middleboxes draft is trying to address the above as it relates to the media path. The target audience is thus IETF participants that would like an overview of how these middleboxes may affect SIP/SDP-signaled media streams as well as what can be done to try and overcome that. Similarly, the document is targeted at people involved in these "other" architecture efforts, with a goal of making it clear how middleboxes may affect the operation of SIP/SDP-signaled media streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE. It could be argued that these architectures have now been around for so long that producing the above document will not make any difference at this point. While I have some sympathy for this, I also think we have to recognize the importance of documenting what we know and to make that readily available for new people that will be working in this space. In other words, I still believe there is value in pursuing this document. As to whether it should be a BCP or Informational, I don't have any strong opinions. Thanks -- Flemming (as an individual) On 6/8/12 6:37 PM, Flemming Andreasen wrote: > Hi > > As part of the MMUSIC charter we have the following milestone > > Sep 2012 Submit Considerations for using SDP offer/answer with > middleboxes for BCP > > > and we have the middleboxes draft > > http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt > > to address that milestone. > > As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns > with the goal of the document and the potential target as further > explained in the following e-mail: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html > > A set of (initial) technical comments were also provided by Hadriel in > the following e-mail: > > http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html > > For now, the chairs would like to focus on the first set of questions > above, i.e. what is the goal and potential target audience for the > document and is there still value in pursuing it ? > > > The chairs would like to poll the group for opinions and interest in > this. Specific areas to consider: > > 1) What is the target audience for the document ? > > 2) Do people believe that the target audience will read and/or care > about this document at this point ? > > 3) Should the document be a BCP or Informational ? > > > Thanks > > -- Miguel & Flemming (as chairs) > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------090907050707070408050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Some comments (as an individual)

A lot of the SIP and SDP work started out with a somewhat "purist" Internet view of the world, where things such as middleboxes were not considered. As other standards and industry organizations became interested in using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, there was, at least initially, not a great deal of knowledge about these architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that such middleboxes may break end-to-end transparency and hence there was a desire to try and alleviate that.

To that effect, it was seen as useful to have a document that could
a) Explain what/how middleboxes might be operating in these architectures
b) Provide guidelines as to how such middleboxes could minimize (ideally avoid) impacting end-to-end transparency and/or how protocols could be used to try and alleviate any impact such middleboxes might have.

The middleboxes draft is trying to address the above as it relates to the media path. The target audience is thus IETF participants that would like an overview of how these middleboxes may affect SIP/SDP-signaled media streams as well as what can be done to try and overcome that. Similarly, the document is targeted at people involved in these "other" architecture efforts, with a goal of making it clear how middleboxes may affect the operation of SIP/SDP-signaled media streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE.

It could be argued that these architectures have now been around for so long that producing the above document will not make any difference at this point. While I have some sympathy for this, I also think we have to recognize the importance of documenting what we know and to make that readily available for new people that will be working in this space.

In other words, I still believe there is value in pursuing this document. As to whether it should be a BCP or Informational, I don't have any strong opinions.

Thanks

-- Flemming (as an individual)




On 6/8/12 6:37 PM, Flemming Andreasen wrote:
Hi

As part of the MMUSIC charter we have the following milestone

Sep 2012 Submit Considerations for using SDP offer/answer with middleboxes for BCP

and we have the middleboxes draft

    http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt

to address that milestone.

As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the document and the potential target as further explained in the following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html

A set of (initial) technical comments were also provided by Hadriel in the following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html

For now, the chairs would like to focus on the first set of questions above, i.e. what is the goal and potential target audience for the document and is there still value in pursuing it ?


The chairs would like to poll the group for opinions and interest in this. Specific areas to consider:

1) What is the target audience for the document ?

2) Do people believe that the target audience will read and/or care about this document at this point ?

3) Should the document be a BCP or Informational ?


Thanks

-- Miguel & Flemming (as chairs)








_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
--------------090907050707070408050108-- From Bert.Greevenbosch@huawei.com Tue Jun 19 17:49:53 2012 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 AA4B921F85E4 for ; Tue, 19 Jun 2012 17:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwdRHT28OmnN for ; Tue, 19 Jun 2012 17:49:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91E21F85E1 for ; Tue, 19 Jun 2012 17:49:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHB17826; Tue, 19 Jun 2012 20:49:52 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 17:49:52 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 17:49:51 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Wed, 20 Jun 2012 08:49:44 +0800 From: Bert Greevenbosch To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] [clue] Incoming liaison statement from MPEG Thread-Index: AQHNQBO2HABb7jVb90Wz1DwtPvoFRZblrqog//+Qw4CAAA8rAIAQrUBg Date: Wed, 20 Jun 2012 00:49:43 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB629003ECA@szxeml509-mbs> References: <533FED60-A1DC-4E26-B487-5A90EDDEA163@nomor.de> In-Reply-To: <533FED60-A1DC-4E26-B487-5A90EDDEA163@nomor.de> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 00:49:53 -0000 Hi all, I have reviewed the MPEG LS (link below) and associated new MPEG document. I noticed that the 3D frame packing related text comes from 14496-10. In 14= 496-10, the 3D signalling is in the context of SEI messages. Including this= text in the new MPEG document indicates MPEG has plans of expanding its us= e, although the SEI messages are left out of scope and only field values an= d associated descriptions are provided. The relationship of the MPEG document with the SDP signalling draft (link b= elow) is the high-level definition of the frame-compatible video formats. F= or this reason, there is already a reference to 14496-10 in the draft. Depe= nding on the status of the new MPEG document, that reference may need to be= updated. Best regards, Bert http://datatracker.ietf.org/liaison/1158/ http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-3d-format/ --- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Thomas Stockhammer Sent: 02 June 2012 03:12 To: Stephan Wenger Cc: clue@ietf.org; mmusic@ietf.org Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG Stephan, all, a bit more background. MPEG is NOT defining the mapping of the code points to any specific syntax,= such as XML or SDP or a bitstream format. However, it provides common code= points (generally unsigned integers) and common definitions of the code po= ints. One of the relevant code points for IETF SDP are the frame-compatible video= formats such as SbS or TaB. Others may relate to audio properties such as = the number and configuration of audio channels. One of the main motivations is to avoid copying such code points from one s= pecification to the next as it happens today for example in video coding st= andards.=A0 The IETF is encouraged to support the unification of such code points and b= y providing input to MPEG and by using references to the MPEG specification= in IETF documents. Thomas On Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote: Hi Roni, The statement was sitting in my inbox for a few days, and I have forwarded = it to the secretariat for posting only this morning. =A0Therefore, it is no= t yet on the tracker, but should be on the tracker sometime soon. Color primaries, as one example, can actually being sent in SDP today, as p= art of the VUI in the sequence parameter set of H.264. =A0And, color primar= ies are an interoperability point, at least for high quality applications (= such as video contribution). =A0If your receiving box does not understand, = or cannot meaningfully process color primaries as sent, then you may get a = picture but it will look odd. =A0There is also other stuff in the MPEG doc = that is even more needed for interoperability; for example, association of = audio channels inside the codec bitstream with a speaker location. The key point of the MPEG doc is that they are out farming generic codec th= ings from the audio/video specs into this MPEG-A format, and we (as we are = not using MPEG-A) will probably have to find a way to either encapsulate MP= EG-A XML for cap exchange, or translate the code points to SDP-ish things. Stephan From: Roni Even Date: Friday, 1 June, 2012 10:00=20 To: Stephan Wenger , "mmusic@ietf.org" , = "clue@ietf.org" Subject: RE: [clue] Incoming liaison statement from MPEG Stephan, I did not see the liaison statement yet in MMUSIC, so I hope it will be ava= ilable in time for us to review.=20 >From the example of color primaries I am not sure why we need to have this = in SDP. if this is something that is sent as part of the payload do we need= to send it also in SDP? =A0 Roni =A0 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Friday, June 01, 2012 7:29 PM To: mmusic@ietf.org; clue@ietf.org Subject: [clue] Incoming liaison statement from MPEG =A0 Hi all, MPEG is working towards codec independent code points, and has sent to MMUS= IC a liaison statement asking for our input. =A0Especially the audio stuff = may also be relevant to CLUE, so I copy CLUE here as well. =A0No deadline i= s provided, but I note that MPEG meets two weeks before the Vancouver IETF = meeting and the text they sent us is already a CD, so our time to influence= their decisions (if we choose to do so) is limited. MPEG has observed that many code points relevant for audio and video are ge= neric in the sense that they can be applicable to many video or audio codec= s. =A0Recent MPEG (and joint MPEG/ITU) video coding standards have occasion= ally copy-pasted whole sections of code points concerning things like color= primaries. =A0They want to avoid this in the future. =A0So they farm out s= tuff that is historically located in video/audio codec specs, but are likel= y to be common between different codecs. My hunch is that the code point in their draft standard could be translated= to SDP-ish syntax. =A0At this point, it is XML-ish. Stephan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --- Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone +49 89 97= 8980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registergeri= cht: M=FCnchen, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FC= hrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From mary.ietf.barnes@gmail.com Fri Jun 22 12:44:05 2012 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 CD62021F8533; Fri, 22 Jun 2012 12:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.727 X-Spam-Level: X-Spam-Status: No, score=-103.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyc+lsKrDYZV; Fri, 22 Jun 2012 12:44:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0997B21F8525; Fri, 22 Jun 2012 12:44:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2764129obb.31 for ; Fri, 22 Jun 2012 12:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0E8iVrnnESllVPd3IbiwjHHJ8briCEzpSFqCxc5GEp0=; b=cfkVEXJ40JsfOSmOANweh8Cr14xz0b4f2nA2c8D2+xU1uc8PuYj2d/Y/QZj64AKm54 41z/GNxJw7u9njMO1VcTKyW5U3DKo7KoEynYg6guh4LSRh9y4Q3aa5y406aMXM6x9o3x WOWKkCIesT5ushLqPNeIdcrxdu6J6I804za4HGOCNKM79ZJm1Uz46/qnGnticBXS/HEg 5wihx9BK1a8JZxq5FGk2oZUUT8u/TDubR1Heq2qUp8TFi/fNkmSZQZfZfgbt8dVxzCAv aoJ5nNQRop79fvNSk/0+ofoSbETqOeLxeKEDFZ7uLR8TepanvgBrNeMbiB1wLEZMojJ4 UncA== MIME-Version: 1.0 Received: by 10.60.3.202 with SMTP id e10mr3236064oee.52.1340394244591; Fri, 22 Jun 2012 12:44:04 -0700 (PDT) Received: by 10.182.38.67 with HTTP; Fri, 22 Jun 2012 12:44:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Jun 2012 14:44:04 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avtcore@ietf.org, DISPATCH , mmusic@ietf.org Subject: [MMUSIC] Fwd: "Telepresence Tutorial" @ IETF-84 (Please RSVP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 19:44:06 -0000 Hi all, Apologies to the many of you that are receiving this multiple times. Unfortunately, the RAI list is not a superset of participants in WGs that might be interested in this. Folks that aren't on the RAI list might want to subscribe here: https://www.ietf.org/mailman/listinfo/rai We are planning a lunchtime tutorial on Monday, July 30th. =A0The primary objective is to provide more background on telepresence as well as an update of the work in CLUE to the broader RAI and IETF community. =A0This will hopefully facilitate the process of completing the CLUE protocol work as it gets broader community review. Here's the proposed outline: 1) Introduction to telepresence 2) Example telepresence scenarios 3) Introduction to the CLUE work 4) High level introduction of framework 5) One or two use cases as examples of how the CLUE framework is realized - showing how existing protocols (e.g., SDP, RTP) are integral to the solution along with additional signaling for CLUE. We have reserved a room for around 50 and attendance will be FCFS, so please RSVP ASAP: http://www.doodle.com/mzu3nmdeehkxkiy The deadline to reply is Friday, July 13th, 2012 (5pm Pacific), as we are trying to find a sponsor for lunch (i.e., box lunches). Note, if anyone is willing to sponsor all or even part of the lunch, please let me know ASAP. =A0Also, if you have any dietary restrictions (e.g., vegetarian, etc.), please let me know offline or include a comment in the doodle. http://www.doodle.com/mzu3nmdeehkxkiys Please send any questions/comments to me (or to the CLUE WG mailing list) rather than reply all. Regards, Mary CLUE WG co-chair From thomas.belling@nsn.com Mon Jun 25 01:48:35 2012 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 D9EF321F8499 for ; Mon, 25 Jun 2012 01:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFFMjx0yoVKN for ; Mon, 25 Jun 2012 01:48:31 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F230021F848F for ; Mon, 25 Jun 2012 01:48:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5P8mQ1e000370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jun 2012 10:48:26 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5P8mOtJ021533; Mon, 25 Jun 2012 10:48:25 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jun 2012 10:48:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD52AF.45C88721" Date: Mon, 25 Jun 2012 10:48:20 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F01847BDB@DEMUEXC014.nsn-intra.net> In-Reply-To: <4FD28645.5000702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WG Poll on the middleboxes draft(draft-ietf-mmusic-media-path-middleboxes) Thread-Index: Ac1Fy9rilvjQ2Q2UTnC8Y+IHqis9qAM41FGg References: <4FD27EAB.1090102@cisco.com> <4FD28645.5000702@cisco.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Flemming Andreasen" , X-OriginalArrivalTime: 25 Jun 2012 08:48:25.0496 (UTC) FILETIME=[48A24180:01CD52AF] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 14696 X-purgate-ID: 151667::1340614106-00003CDD-519CC6AD/0-0/0-0 Subject: Re: [MMUSIC] WG Poll on the middleboxes draft(draft-ietf-mmusic-media-path-middleboxes) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2012 08:48:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD52AF.45C88721 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. =20 Thomas =20 =20 ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 =20 =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Flemming Andreasen Sent: Saturday, June 09, 2012 1:10 AM To: mmusic Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft(draft-ietf-mmusic-media-path-middleboxes) =20 Some comments (as an individual) A lot of the SIP and SDP work started out with a somewhat "purist" Internet view of the world, where things such as middleboxes were not considered. As other standards and industry organizations became interested in using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, there was, at least initially, not a great deal of knowledge about these architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that such middleboxes may break end-to-end transparency and hence there was a desire to try and alleviate that.=20 To that effect, it was seen as useful to have a document that could a) Explain what/how middleboxes might be operating in these architectures b) Provide guidelines as to how such middleboxes could minimize (ideally avoid) impacting end-to-end transparency and/or how protocols could be used to try and alleviate any impact such middleboxes might have.=20 The middleboxes draft is trying to address the above as it relates to the media path. The target audience is thus IETF participants that would like an overview of how these middleboxes may affect SIP/SDP-signaled media streams as well as what can be done to try and overcome that. Similarly, the document is targeted at people involved in these "other" architecture efforts, with a goal of making it clear how middleboxes may affect the operation of SIP/SDP-signaled media streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE.=20 It could be argued that these architectures have now been around for so long that producing the above document will not make any difference at this point. While I have some sympathy for this, I also think we have to recognize the importance of documenting what we know and to make that readily available for new people that will be working in this space.=20 In other words, I still believe there is value in pursuing this document. As to whether it should be a BCP or Informational, I don't have any strong opinions.=20 Thanks=20 -- Flemming (as an individual) On 6/8/12 6:37 PM, Flemming Andreasen wrote:=20 Hi=20 As part of the MMUSIC charter we have the following milestone Sep 2012 Submit Considerations for using SDP offer/answer with middleboxes for BCP and we have the middleboxes draft =20 http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt to address that milestone.=20 As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the document and the potential target as further explained in the following e-mail:=20 http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html A set of (initial) technical comments were also provided by Hadriel in the following e-mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html For now, the chairs would like to focus on the first set of questions above, i.e. what is the goal and potential target audience for the document and is there still value in pursuing it ? The chairs would like to poll the group for opinions and interest in this. Specific areas to consider: 1) What is the target audience for the document ? 2) Do people believe that the target audience will read and/or care about this document at this point ? 3) Should the document be a BCP or Informational ? Thanks=20 -- Miguel & Flemming (as chairs) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01CD52AF.45C88721 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree.

 

Thomas

 

 

----------------------------------
Dr. Thomas Belling
3GPP Standardisation
Nokia Siemens Networks 

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of ext Flemming Andreasen
Sent: Saturday, June 09, = 2012 1:10 AM
To: mmusic
Cc: = draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org
Subject: Re: [MMUSIC] WG Poll on the middleboxes = draft(draft-ietf-mmusic-media-path-middleboxes)

 

Some comments (as an individual)

A lot of the = SIP and SDP work started out with a somewhat "purist" Internet = view of the world, where things such as middleboxes were not considered. = As other standards and industry organizations became interested in using = SIP and SDP, different architectures were defined and some of those = arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and = CableLabs PacketCable). From an IETF point of view, there was, at least = initially, not a great deal of knowledge about these architectures and = what the middleboxes defined by them were doing. Conversely, there was = (is) also a concern that such middleboxes may break end-to-end = transparency and hence there was a desire to try and alleviate that. =

To that effect, it was seen as useful to have a document that = could
a) Explain what/how middleboxes might be operating in these = architectures
b) Provide guidelines as to how such middleboxes could = minimize (ideally avoid) impacting end-to-end transparency and/or how = protocols could be used to try and alleviate any impact such middleboxes = might have.

The middleboxes draft is trying to address the above = as it relates to the media path. The target audience is thus IETF = participants that would like an overview of how these middleboxes may = affect SIP/SDP-signaled media streams as well as what can be done to try = and overcome that. Similarly, the document is targeted at people = involved in these "other" architecture efforts, with a goal of = making it clear how middleboxes may affect the operation of = SIP/SDP-signaled media streams and hence provide some "design = principles". This is not unlike some of the NAT work that was done = in BEHAVE.

It could be argued that these architectures have now = been around for so long that producing the above document will not make = any difference at this point. While I have some sympathy for this, I = also think we have to recognize the importance of documenting what we = know and to make that readily available for new people that will be = working in this space.

In other words, I still believe there is = value in pursuing this document. As to whether it should be a BCP or = Informational, I don't have any strong opinions.

Thanks =

-- Flemming (as an individual)




On 6/8/12 6:37 = PM, Flemming Andreasen wrote:

Hi

As part of the MMUSIC charter = we have the following milestone

Sep = 2012

Submit = Considerations for using SDP offer/answer with middleboxes for = BCP


and = we have the middleboxes draft

    http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04= .txt

to address that milestone.

As discussed at IETF = 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the = document and the potential target as further explained in the following = e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html
A set of (initial) technical comments were also provided by = Hadriel in the following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html
For now, the chairs would like to focus on the first set of = questions above, i.e. what is the goal and potential target audience for = the document and is there still value in pursuing it ?


The = chairs would like to poll the group for opinions and interest in this. = Specific areas to consider:

1) What is the target audience for = the document ?

2) Do people believe that the target audience will = read and/or care about this document at this point ?

3) Should = the document be a BCP or Informational ?


Thanks

-- = Miguel & Flemming (as = chairs)









______=
_________________________________________
mmusic =
mailing list
mmusic@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/mmusic
------_=_NextPart_001_01CD52AF.45C88721-- From mperumal@cisco.com Mon Jun 25 03:39:41 2012 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 C779F21F84B4 for ; Mon, 25 Jun 2012 03:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxaSh+ixz6fH for ; Mon, 25 Jun 2012 03:39:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDC721F8513 for ; Mon, 25 Jun 2012 03:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=17084; q=dns/txt; s=iport; t=1340620773; x=1341830373; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vwDiJ67Ert75uzN4MYwd8Qv2Vl1QpjQ36PI/Tahcet0=; b=KtiL+GEZgAfhDvgyu5beYdUaWbMPqSf2ZIjErY1jGqSfrQEqaeVKW4bl nENjwspcD0XvE0qhTdJ81ylnfiELRnfE5wugMN19sHRD6SzCnUVdqNCKZ F9ch28nKmV3d4sKc+CVX9Onw3iIT2w17tekZqBVZ3RQ53w7qJb033wWoS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAME+6E+tJV2Z/2dsb2JhbABEgkWzW4EHghgBAQEEAQEBDwEaQQsQAgEIEQEDAQELHQcnCxQDBggCBAENBQgBGYdpC5kKnzGLMxqFCGADo0mBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208,217";a="95630104" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2012 10:39:30 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5PAdUox010517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jun 2012 10:39:30 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 05:39:29 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Flemming Andreasen (fandreas)" , mmusic Thread-Topic: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) Thread-Index: AQHNRcdObbybQRoB3E6fNM1JrZOD85bxX+eAgBmRJIA= Date: Mon, 25 Jun 2012 10:39:28 +0000 Message-ID: References: <4FD27EAB.1090102@cisco.com> <4FD28645.5000702@cisco.com> In-Reply-To: <4FD28645.5000702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.80.249] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18994.004 x-tm-as-result: No--54.236700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE20128EDC8xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org" Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2012 10:39:41 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE20128EDC8xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Considering that the draft has preliminary recommendations, I think it shou= ld be a BCP if we agree on those recommendations. Muthu From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen (fandreas) Sent: Saturday, June 09, 2012 4:40 AM To: mmusic Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-m= edia-path-middleboxes) Some comments (as an individual) A lot of the SIP and SDP work started out with a somewhat "purist" Internet= view of the world, where things such as middleboxes were not considered. A= s other standards and industry organizations became interested in using SIP= and SDP, different architectures were defined and some of those arcitectur= es did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs Packe= tCable). From an IETF point of view, there was, at least initially, not a g= reat deal of knowledge about these architectures and what the middleboxes d= efined by them were doing. Conversely, there was (is) also a concern that s= uch middleboxes may break end-to-end transparency and hence there was a des= ire to try and alleviate that. To that effect, it was seen as useful to have a document that could a) Explain what/how middleboxes might be operating in these architectures b) Provide guidelines as to how such middleboxes could minimize (ideally av= oid) impacting end-to-end transparency and/or how protocols could be used t= o try and alleviate any impact such middleboxes might have. The middleboxes draft is trying to address the above as it relates to the m= edia path. The target audience is thus IETF participants that would like an= overview of how these middleboxes may affect SIP/SDP-signaled media stream= s as well as what can be done to try and overcome that. Similarly, the docu= ment is targeted at people involved in these "other" architecture efforts, = with a goal of making it clear how middleboxes may affect the operation of = SIP/SDP-signaled media streams and hence provide some "design principles". = This is not unlike some of the NAT work that was done in BEHAVE. It could be argued that these architectures have now been around for so lon= g that producing the above document will not make any difference at this po= int. While I have some sympathy for this, I also think we have to recognize= the importance of documenting what we know and to make that readily availa= ble for new people that will be working in this space. In other words, I still believe there is value in pursuing this document. A= s to whether it should be a BCP or Informational, I don't have any strong o= pinions. Thanks -- Flemming (as an individual) On 6/8/12 6:37 PM, Flemming Andreasen wrote: Hi As part of the MMUSIC charter we have the following milestone Sep 2012 Submit Considerations for using SDP offer/answer with middleboxes for BCP and we have the middleboxes draft http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt to address that milestone. As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with t= he goal of the document and the potential target as further explained in th= e following e-mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html A set of (initial) technical comments were also provided by Hadriel in the = following e-mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html For now, the chairs would like to focus on the first set of questions above= , i.e. what is the goal and potential target audience for the document and = is there still value in pursuing it ? The chairs would like to poll the group for opinions and interest in this. = Specific areas to consider: 1) What is the target audience for the document ? 2) Do people believe that the target audience will read and/or care about t= his document at this point ? 3) Should the document be a BCP or Informational ? Thanks -- Miguel & Flemming (as chairs) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_E721D8C6A2E1544DB2DEBC313AF54DE20128EDC8xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Considering that the draft has preliminar= y recommendations, I think it should be a BCP if we agree on those recommen= dations.

 

Muthu

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Flemming Andreasen (fandreas)
Sent: Saturday, June 09, 2012 4:40 AM
To: mmusic
Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org
Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-m= music-media-path-middleboxes)

 

Some comments (as an individual)

A lot of the SIP and SDP work started out with a somewhat "purist"= ; Internet view of the world, where things such as middleboxes were not con= sidered. As other standards and industry organizations became interested in= using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of midd= leboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of vi= ew, there was, at least initially, not a great deal of knowledge about thes= e architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that= such middleboxes may break end-to-end transparency and hence there was a d= esire to try and alleviate that.

To that effect, it was seen as useful to have a document that could
a) Explain what/how middleboxes might be operating in these architectures b) Provide guidelines as to how such middleboxes could minimize (ideally av= oid) impacting end-to-end transparency and/or how protocols could be used t= o try and alleviate any impact such middleboxes might have.

The middleboxes draft is trying to address the above as it relates to the m= edia path. The target audience is thus IETF participants that would like an= overview of how these middleboxes may affect SIP/SDP-signaled media stream= s as well as what can be done to try and overcome that. Similarly, the document is targeted at people invol= ved in these "other" architecture efforts, with a goal of making = it clear how middleboxes may affect the operation of SIP/SDP-signaled media= streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE.

It could be argued that these architectures have now been around for so lon= g that producing the above document will not make any difference at this po= int. While I have some sympathy for this, I also think we have to recognize= the importance of documenting what we know and to make that readily available for new people that will be wor= king in this space.

In other words, I still believe there is value in pursuing this document. A= s to whether it should be a BCP or Informational, I don't have any strong o= pinions.

Thanks

-- Flemming (as an individual)




On 6/8/12 6:37 PM, Flemming Andreasen wrote:

Hi

As part of the MMUSIC charter we have the following milestone

Sep 2012

Submit Consi= derations for using SDP offer/answer with middleboxes for BCP


and we have the middleboxes draft

    http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt<= br>
to address that milestone.

As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with t= he goal of the document and the potential target as further explained in th= e following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/m= sg09278.html

A set of (initial) technical comments were also provided by Hadriel in the = following e-mail:

    http://www.ietf.org/mail-archive/web/mmusic/current/m= sg08640.html

For now, the chairs would like to focus on the first set of questions above= , i.e. what is the goal and potential target audience for the document and = is there still value in pursuing it ?


The chairs would like to poll the group for opinions and interest in this. = Specific areas to consider:

1) What is the target audience for the document ?

2) Do people believe that the target audience will read and/or care about t= his document at this point ?

3) Should the document be a BCP or Informational ?


Thanks

-- Miguel & Flemming (as chairs)









_______________________________________________
mmusic mailing list
mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic
--_000_E721D8C6A2E1544DB2DEBC313AF54DE20128EDC8xmbrcdx02ciscoc_-- From gonzalo.camarillo@ericsson.com Tue Jun 26 00:16:20 2012 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 26EAE11E80A1 for ; Tue, 26 Jun 2012 00:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzJUOvFbxelS for ; Tue, 26 Jun 2012 00:16:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 114A721F858E for ; Tue, 26 Jun 2012 00:16:18 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-f7-4fe961c1c004 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 37.FD.00702.1C169EF4; Tue, 26 Jun 2012 09:16:17 +0200 (CEST) Received: from [131.160.126.150] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Tue, 26 Jun 2012 09:16:17 +0200 Message-ID: <4FE961C0.2010801@ericsson.com> Date: Tue, 26 Jun 2012 10:16:16 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Flemming Andreasen References: <4FCFCF0A.6010607@cisco.com> In-Reply-To: <4FCFCF0A.6010607@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvre7BxJf+Btdvq1hcfX+LzeL9BV2L qcsfs1hcm9PI5sDiMeX3RlaPJUt+MnnM2vmExePL5c9sASxRXDYpqTmZZalF+nYJXBkr3i9l LOgUr7hw8hNbA+M6wS5GDg4JAROJB4f0uhg5gUwxiQv31rN1MXJxCAmcYpS4fuEIlLOWUWJ+ 0wdWkCpeAW2Jea83sIA0swioSuw84A4SZhOwkNhy6z4LiC0qECwxr/smC0S5oMTJmU/AykWA WqcusAAZySxwmlGi98Y5NpAaYQFnia8Pf4CNFxLQkNjzcQtYL6eApsS0D/1MEMdJStxrXw1W zyygJzHlagsjhC0vsf3tHGaIXm2J5c9aWCYwCs1CsnoWkpZZSFoWMDKvYhTOTczMSS8310st ykwuLs7P0ytO3cQIDPODW34b7GDcdF/sEKM0B4uSOK+e6n5/IYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYxCPZV5e11e379c1Sez6zP323VTdtf8MFm/upCh+OQiK8XCo50K7PY+2YbysfGX nnwU47FbwayllbOrzbI7ptSvR87xQtE1zx1pibNv5+l1dy5a09Rutvr8nDi9A/e+Pn3y7f7r oMUzFzbItVzPiHA91jfT42FNTEj98ZXvWxtqri9d9mnFST0lluKMREMt5qLiRAB+JnxbQQIA AA== Cc: "draft-ietf-dccp-udpencap@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-dccp-udpencap-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 07:16:20 -0000 Hi Flemming, thanks for your review. The authors of the draft have just submitted a new revision: http://tools.ietf.org/html/draft-ietf-dccp-udpencap-11 And the diff from revision 10: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dccp-udpencap-11.txt Cheers, Gonzalo On 07/06/2012 12:43 AM, Flemming Andreasen wrote: > Hi > > I am the assigned SDP directorate reviewer for draft-ietf-dccp-udpencap-10 > > For background on the SDP directorate, please see the FAQ at > . > > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. > > > Summary: > -------- > There are two minor technical issues with the current draft which should > be discussed further. > > There are also a few minor editorial issues, which can be corrected as > part of the publication process. > > > > New SDP Information Elements: > --------------------------- > The draft defines a new "a=dccp-port" attribute > > > > Technical: > --------- > 1) Section 5.2 states: > > If the "a=rtcp:" attribute [RFC3605] is used, then the signalled port > is the DCCP port used for RTCP. > I think this warrants further discussion. How will this work if > non-consecutive ports are to be used for DCCP-UDP itself and how will > this work if a middlebox looks at the "a=rtcp" attribute and assumes the > currently defined behavior in RFC 3605, which would effectively provide > it with the port information for the (UDP native) RTCP stream today ? > > > 2) Section 5.4 discusses how to negotiate DCCP-UDP versus native DCCP > (DCCP-STD) and in particular considers only the use of ICE for this > (with the details of the encoding "left for future study"). While this > may be appropriate for the basic use of DCCP-UDP versus DCCP-STD, it is > arguably not appropriate when it comes to negotiating different RTP > profiles within each of these (which are defined in this draft). SDP > Capability Negotiation would be more suitable for this, as described in > RFC 5939 Section 3.7. At a minimum, a reference to that effect and those > considerations should be provided. > > > 3) Section 3.8, 4th paragraph: > s/a DCCP-UDP server must therefore/a DCCP-UDP MUST therefore/ ?? > ^^^^ > > > Editorial: > -------- > Various instances of repeat words and a few spelling errors that should > be caught by a spell-checker. > > Also: > - Section 5.1, first paragraph: > s/(from [RFC4566]:/(from [RFC4566]):/ > ^ > - Section 5.4, second paragraph > s/DCCPx/DCCP/ > > - Section 6, last paragraph: > s/A firewall than/A firewall that/ > ^ > > - ICE-TCP is now RFC 6544 > > > Thanks > > -- Flemming > > From fandreas@cisco.com Wed Jun 27 15:26:14 2012 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 79DAE11E8097 for ; Wed, 27 Jun 2012 15:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G4cLS16jgGG for ; Wed, 27 Jun 2012 15:26:13 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9936E11E808A for ; Wed, 27 Jun 2012 15:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=701; q=dns/txt; s=iport; t=1340835973; x=1342045573; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=YMt8K9nHtBhZCSfQD+va45VKTqcY8wO5/lglKbZuufc=; b=mlTm7fmvCroGiNWrHsAU0ePT5kvWimwQy1/Moc409Q7orZ49fOxan3J4 AaprT+HA8A2ojv+XFg2drqpqDkw5wgSTpFnmte5UgOybFu0Twl/y0Mwaf Mq9qzyc2mHNcaN7kHLckzgGnGnjbp+OyBr5O+AuehRcJBk4EfwRmnxbVD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGOI60+Q/khN/2dsb2JhbABFtjKBB4IxASVAPRYYAwIBAgFLDQgBAR6HaQuWTYEooFaRQQOVMoESjQuBZoJ7 X-IronPort-AV: E=Sophos;i="4.77,487,1336348800"; d="scan'208";a="6235732" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 27 Jun 2012 22:26:03 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5RMQ3mf010212 for ; Wed, 27 Jun 2012 22:26:03 GMT Message-ID: <4FEB8881.2020507@cisco.com> Date: Wed, 27 Jun 2012 18:26:09 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Continued WG interest in latching draft ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 22:26:14 -0000 Greetings As requested by the chairs prior to the last IETF meeting, a draft explaining how latching (aka. HNT - Hosted Nat Traversal) works was submitted and discussed in Paris. The draft authors have since then submitted an update to the document: http://tools.ietf.org/html/draft-ivov-mmusic-latching-00 with minor changes. At the meeting in Paris, the WG expressed support for continuing this work, albeit a few questions were asked as to whether the MMUSIC WG was the right place to do so. The chairs would hereby like to solicit input as to whether there is continued interest in pursuing this work within the MMUSIC WG. Thanks -- Miguel & Flemming (MMUSIC chairs) From gsalguei@cisco.com Wed Jun 27 21:30:43 2012 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 7498011E81D2 for ; Wed, 27 Jun 2012 21:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOm9LjDpeZFZ for ; Wed, 27 Jun 2012 21:30:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 78F6011E81CA for ; Wed, 27 Jun 2012 21:30:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5S4UfhP005796 for ; Thu, 28 Jun 2012 00:30:41 -0400 (EDT) Received: from rtp-gsalguei-8719.cisco.com (rtp-gsalguei-8719.cisco.com [10.116.61.58]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q5S4UZjf014230; Thu, 28 Jun 2012 00:30:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: Date: Thu, 28 Jun 2012 00:30:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49F21D33-F41E-4FBA-91ED-22C0711959A8@cisco.com> References: <4FD27EAB.1090102@cisco.com> <4FD28645.5000702@cisco.com> To: Muthu Arul Mozhi Perumal (mperumal) X-Mailer: Apple Mail (2.1278) Cc: "Flemming Andreasen \(fandreas\)" , mmusic , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 04:30:43 -0000 +1 Gonzalo On Jun 25, 2012, at 6:39 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > +1 > =20 > Considering that the draft has preliminary recommendations, I think it = should be a BCP if we agree on those recommendations. > =20 > Muthu > =20 > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Flemming Andreasen (fandreas) > Sent: Saturday, June 09, 2012 4:40 AM > To: mmusic > Cc: draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org > Subject: Re: [MMUSIC] WG Poll on the middleboxes draft = (draft-ietf-mmusic-media-path-middleboxes) > =20 > Some comments (as an individual) >=20 > A lot of the SIP and SDP work started out with a somewhat "purist" = Internet view of the world, where things such as middleboxes were not = considered. As other standards and industry organizations became = interested in using SIP and SDP, different architectures were defined = and some of those arcitectures did include the notion of middleboxes = (e.g. 3GPP IMS and CableLabs PacketCable). =46rom an IETF point of view, = there was, at least initially, not a great deal of knowledge about these = architectures and what the middleboxes defined by them were doing. = Conversely, there was (is) also a concern that such middleboxes may = break end-to-end transparency and hence there was a desire to try and = alleviate that.=20 >=20 > To that effect, it was seen as useful to have a document that could > a) Explain what/how middleboxes might be operating in these = architectures > b) Provide guidelines as to how such middleboxes could minimize = (ideally avoid) impacting end-to-end transparency and/or how protocols = could be used to try and alleviate any impact such middleboxes might = have.=20 >=20 > The middleboxes draft is trying to address the above as it relates to = the media path. The target audience is thus IETF participants that would = like an overview of how these middleboxes may affect SIP/SDP-signaled = media streams as well as what can be done to try and overcome that. = Similarly, the document is targeted at people involved in these "other" = architecture efforts, with a goal of making it clear how middleboxes may = affect the operation of SIP/SDP-signaled media streams and hence provide = some "design principles". This is not unlike some of the NAT work that = was done in BEHAVE.=20 >=20 > It could be argued that these architectures have now been around for = so long that producing the above document will not make any difference = at this point. While I have some sympathy for this, I also think we have = to recognize the importance of documenting what we know and to make that = readily available for new people that will be working in this space.=20 >=20 > In other words, I still believe there is value in pursuing this = document. As to whether it should be a BCP or Informational, I don't = have any strong opinions.=20 >=20 > Thanks=20 >=20 > -- Flemming (as an individual) >=20 >=20 >=20 >=20 > On 6/8/12 6:37 PM, Flemming Andreasen wrote: > Hi=20 >=20 > As part of the MMUSIC charter we have the following milestone >=20 > Sep 2012 > Submit Considerations for using SDP offer/answer with middleboxes for = BCP >=20 > and we have the middleboxes draft >=20 > = http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt >=20 > to address that milestone.=20 >=20 > As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns = with the goal of the document and the potential target as further = explained in the following e-mail:=20 >=20 > http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html >=20 > A set of (initial) technical comments were also provided by Hadriel in = the following e-mail: >=20 > http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html >=20 > For now, the chairs would like to focus on the first set of questions = above, i.e. what is the goal and potential target audience for the = document and is there still value in pursuing it ? >=20 >=20 > The chairs would like to poll the group for opinions and interest in = this. Specific areas to consider: >=20 > 1) What is the target audience for the document ? >=20 > 2) Do people believe that the target audience will read and/or care = about this document at this point ? >=20 > 3) Should the document be a BCP or Informational ? >=20 >=20 > Thanks=20 >=20 > -- Miguel & Flemming (as chairs) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 From hannes.tschofenig@gmx.net Thu Jun 28 03:09:43 2012 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 7D02621F8595 for ; Thu, 28 Jun 2012 03:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsaXE-HRdsaj for ; Thu, 28 Jun 2012 03:09:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7C12411E81C5 for ; Thu, 28 Jun 2012 00:19:51 -0700 (PDT) Received: (qmail invoked by alias); 28 Jun 2012 07:19:49 -0000 Received: from unknown (EHLO [10.255.135.50]) [194.251.119.201] by mail.gmx.net (mp034) with SMTP; 28 Jun 2012 09:19:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1++QvV2OIa+tpZVAGZL58kiiv9f3YdQbfJqT1nHw/ 9ClvFkG+BGo5lL Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FD28645.5000702@cisco.com> Date: Thu, 28 Jun 2012 10:19:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD27EAB.1090102@cisco.com> <4FD28645.5000702@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: mmusic , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:09:43 -0000 Hi Flemming,=20 I take a pragmatic view. The document has been worked on in the group = for a while, a WGLC had been held, the received last call comments had = been incorporated in the meanwhile.=20 =46rom there on there are only two routes (IMHO): a) publish the document through the working group,=20 b) the authors submit it to the RFC editor as an independent submission At this point in time the outcome is not so much different anymore = (since the working group had already provided their input).=20 The text about the impact of middleboxes on signaling protocols is = something worth capturing and the offered guidance seems to be OK. I = still think that this writeup will be a useful reference for the work on = middleboxes with relationship to security protocols.=20 Ciao Hannes On Jun 9, 2012, at 2:09 AM, Flemming Andreasen wrote: > Some comments (as an individual) >=20 > A lot of the SIP and SDP work started out with a somewhat "purist" = Internet view of the world, where things such as middleboxes were not = considered. As other standards and industry organizations became = interested in using SIP and SDP, different architectures were defined = and some of those arcitectures did include the notion of middleboxes = (e.g. 3GPP IMS and CableLabs PacketCable). =46rom an IETF point of view, = there was, at least initially, not a great deal of knowledge about these = architectures and what the middleboxes defined by them were doing. = Conversely, there was (is) also a concern that such middleboxes may = break end-to-end transparency and hence there was a desire to try and = alleviate that.=20 >=20 > To that effect, it was seen as useful to have a document that could > a) Explain what/how middleboxes might be operating in these = architectures > b) Provide guidelines as to how such middleboxes could minimize = (ideally avoid) impacting end-to-end transparency and/or how protocols = could be used to try and alleviate any impact such middleboxes might = have.=20 >=20 > The middleboxes draft is trying to address the above as it relates to = the media path. The target audience is thus IETF participants that would = like an overview of how these middleboxes may affect SIP/SDP-signaled = media streams as well as what can be done to try and overcome that. = Similarly, the document is targeted at people involved in these "other" = architecture efforts, with a goal of making it clear how middleboxes may = affect the operation of SIP/SDP-signaled media streams and hence provide = some "design principles". This is not unlike some of the NAT work that = was done in BEHAVE.=20 >=20 > It could be argued that these architectures have now been around for = so long that producing the above document will not make any difference = at this point. While I have some sympathy for this, I also think we have = to recognize the importance of documenting what we know and to make that = readily available for new people that will be working in this space.=20 >=20 > In other words, I still believe there is value in pursuing this = document. As to whether it should be a BCP or Informational, I don't = have any strong opinions.=20 >=20 > Thanks=20 >=20 > -- Flemming (as an individual) >=20 >=20 >=20 >=20 > On 6/8/12 6:37 PM, Flemming Andreasen wrote: >> Hi=20 >>=20 >> As part of the MMUSIC charter we have the following milestone >>=20 >> Sep 2012 Submit Considerations for using SDP offer/answer with = middleboxes for BCP >> and we have the middleboxes draft >>=20 >> = http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt >>=20 >> to address that milestone.=20 >>=20 >> As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns = with the goal of the document and the potential target as further = explained in the following e-mail:=20 >>=20 >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html >>=20 >> A set of (initial) technical comments were also provided by Hadriel = in the following e-mail: >>=20 >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html >>=20 >> For now, the chairs would like to focus on the first set of questions = above, i.e. what is the goal and potential target audience for the = document and is there still value in pursuing it ? >>=20 >>=20 >> The chairs would like to poll the group for opinions and interest in = this. Specific areas to consider: >>=20 >> 1) What is the target audience for the document ? >>=20 >> 2) Do people believe that the target audience will read and/or care = about this document at this point ? >>=20 >> 3) Should the document be a BCP or Informational ? >>=20 >>=20 >> Thanks=20 >>=20 >> -- Miguel & Flemming (as chairs) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >>=20 >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From riccardo.bernardini@uniud.it Wed Jun 27 05:32:50 2012 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 C5AE221F86CF for ; Wed, 27 Jun 2012 05:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFIoQXuqsfB0 for ; Wed, 27 Jun 2012 05:32:50 -0700 (PDT) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id B172021F8691 for ; Wed, 27 Jun 2012 05:32:48 -0700 (PDT) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id B8A17B72C2B for ; Wed, 27 Jun 2012 14:32:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at talitha1 Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id JDjjvwFinWdU for ; Wed, 27 Jun 2012 14:32:46 +0200 (CEST) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 3DF5AB0035 for ; Wed, 27 Jun 2012 14:32:45 +0200 (CEST) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Wed, 27 Jun 2012 14:32:45 +0200 Message-ID: <20120627143245.48556b2kj211431p@webmail.uniud.it> Date: Wed, 27 Jun 2012 14:32:45 +0200 From: Riccardo Bernardini To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Mailman-Approved-At: Thu, 28 Jun 2012 13:28:16 -0700 Subject: [MMUSIC] OS RTSP-2.0 implementation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:32:50 -0000 Dear all, I have a question that, although not strictly protocol-related, could nevertheless interest you. Here at my University a group of students asked my advice for some project in networking/multimedia that could be both interesting and useful. After some discussion, we decided to start an OS project having as an objective the implementation of a RTSP-2.0 server. We would start from a nicely written OS HTTP server (the AWS, Ada Web Server, http://libre.adacore.com/tools/aws/ if you are curious) and modify it to make it understand RTSP-2.0 (and maybe 1.0 too). Maybe it will not be trivial, but we are geek enough and we do not care ;-) I think that this project could be of some interest for this community too, so I wanted to check with you if you have suggestions/remarks/praises/whatever (just do not shoot us too hard! :-). If I feel that there is an interest and the project starts nicely, I can keep you informed. Best regards, Riccardo Bernardini -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine