From miguel.a.garcia@ericsson.com Thu Mar 1 01:38:39 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 630B221F852C for ; Thu, 1 Mar 2012 01:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.343 X-Spam-Level: X-Spam-Status: No, score=-10.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 RJFtpudfs-X4 for ; Thu, 1 Mar 2012 01:38:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEAE21F852A for ; Thu, 1 Mar 2012 01:38:38 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-76-4f4f439db468 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DB.66.01970.D934F4F4; Thu, 1 Mar 2012 10:38:37 +0100 (CET) Received: from [159.107.24.231] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 10:38:37 +0100 Message-ID: <4F4F439C.2030503@ericsson.com> Date: Thu, 1 Mar 2012 10:38:36 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mmusic , Simo Veikkolainen , Bob Gilman References: <20120301092924.7142.15442.idtracker@ietfa.amsl.com> In-Reply-To: <20120301092924.7142.15442.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120301092924.7142.15442.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] draft-garcia-mmusic-sdp-miscellaneous-caps-01.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: Thu, 01 Mar 2012 09:38:39 -0000 We have just submitted a new version of the SDP Miscellaneous capabilities draft. This draft builds on the SDP Capability Negotiation and the SDP Media Capability Negotiation to add three new capabilities: o 'bcap': bandwidth capability o 'ccap': connection data capability o 'icap': title capability The 'ccap' capability is perhaps the most interesting one, because it enables offering a media stream over RTP or over Circuit-Switched (draft-ietf-mmusic-sdp-cs). As usually, the authors are willing to receive your comments. BR; Miguel -------- Original Message -------- Subject: New Version Notification for draft-garcia-mmusic-sdp-miscellaneous-caps-01.txt Date: Thu, 1 Mar 2012 10:29:24 +0100 From: internet-drafts@ietf.org To: Miguel Garcia A CC: simo.veikkolainen@nokia.com , bob_gilman@comcast.net A new version of I-D, draft-garcia-mmusic-sdp-miscellaneous-caps-01.txt has been successfully submitted by Miguel A. Garcia-Martin and posted to the IETF repository. Filename: draft-garcia-mmusic-sdp-miscellaneous-caps Revision: 01 Title: Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) Creation date: 2012-03-01 WG ID: Individual Submission Number of pages: 19 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=' line), connection data ('c=' line), and titles ('i=' line for each session or media). The IETF Secretariat From capelastegui@dit.upm.es Thu Mar 1 08:06: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 090DC21E8133 for ; Thu, 1 Mar 2012 08:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 MQpyikZBWxAb for ; Thu, 1 Mar 2012 08:06:57 -0800 (PST) Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8D21E812D for ; Thu, 1 Mar 2012 08:06:56 -0800 (PST) Received: from correo.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id q21G6OJn027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 17:06:24 +0100 Received: from correo.dit.upm.es (localhost [127.0.0.1]) by correo.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q21G6BTa020768; Thu, 1 Mar 2012 17:06:11 +0100 Received: from 80.29.105.112 (SquirrelMail authenticated user capelastegui) by correo.dit.upm.es with HTTP; Thu, 1 Mar 2012 17:06:13 +0100 Message-ID: In-Reply-To: <46A1DF3F04371240B504290A071B4DB6232C3ADA@szxeml509-mbx.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB623252FF8@szxeml509-mbs.china.huawei.com> <000001cce7f0$1e5e5e10$5b1b1a30$@dit.upm.es> <46A1DF3F04371240B504290A071B4DB6232C3ADA@szxeml509-mbx.china.huawei.com> Date: Thu, 1 Mar 2012 17:06:13 +0100 From: capelastegui@dit.upm.es To: "Bert Greevenbosch" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 'IETF - MMUSIC' Subject: Re: [MMUSIC] The 3D drafts 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, 01 Mar 2012 16:06:58 -0000 Hi Bert, Thanks for answering. The usage of the BUNDLE mechanism to handle the transmission of video and auxiliary maps in a single stream is an interesting idea. I have a few comments about it: 1) Media Structure: The base assumption for BUNDLE is that several media streams are sent over a single RTP session, and sharing the same 5-tuple. These media streams can be differentiated from one another by their payload type and SSRC. However, a stream containing 2D video and an auxiliary map doesn't follow the same structure: the auxiliary map is included as metadata within the 2D video stream. I don't know whether that could be a problem. At the very least, if BUNDLE and 3dFormat are used together as you suggest, the specification should state clearly that this is a deviation from the normal behavior of BUNDLE. 2) When to use BUNDLE: Should the BUNDLE mechanism be used only in the specific scenario of 2D video and auxiliary streams with different encodings, or would it apply to all scenarios with 2D+aux in a single stream? In the latter case, BUNDLE would effectively replace the formats "CD", "LD", "CP" and "LP", as defined in the current draft. This makes for more complex and verbose session descriptions, but is probably a more consistent approach than supporting the syntax with BUNDLE and the one without. 3) Your example SDP: You don't really need that many streams and groups when combining 3dFormat and BUNDLE. A more compact way to describe the same offer would be to use 2 streams, offering 2 different payload types for the auxiliary map. Incidentally, this is also more efficient than the mechanism I suggested in my original example: a=group:3DS 1 2 a=group:BUNDLE 1 2 m=video 49170 RTP/AVP 99 a=rtpmap:99 H264/90000 a=3dFormat:SC C a=mid:1 m=video 49170 RTP/AVP 100 101 a=rtpmap:100 H263/90000 a=rtpmap:101 H264/90000 a=3dFormat:SC D a=mid:2 Best regards, Pedro > Hi Pedro, > > As promised, here the answer to your second e-mail. > > The current simulcast solution in the draft indeed assumes a single codec, > which internally contains both a 2D and an auxiliary stream. > > But my understanding is that your main concern is the simulcast of two > streams (2D and aux), with different codecs. Your proposed solution would > indeed resolve that problem. > > Now that we have the discussions on RTP multiplexing, especially the > "BUNDLE" draft > (http://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation), > I was wondering whether we could somehow use that mechanism to resolve the > problem. In that case, your original example > > m=video 49170 RTP/AVP 99 100 > a=3dFormat:2DA CD > a=rtpmap:99 H264/90000 > a=3daux: 99 H263/90000 aux-fmtp:(...) > a=rtpmap:100 H264/90000 > a=3daux: 100 H264/90000 aux-fmtp:(...) > > would become as follows: > > a=group:3DS 1 2 > a=group:BUNDLE 1 2 > m=video 49170 RTP/AVP 99 > a=rtpmap:99 H264/90000 > a=3dFormat:SC C > a=mid:1 > m=video 49170 RTP/AVP 100 > a=rtpmap:100 H263/90000 > a=3dFormat:SC D > a=mid:2 > a=group:3DS 3 4 > a=group:BUNDLE 3 4 > m=video 49170 RTP/AVP 99 > a=rtpmap:99 H264/90000 > a=3dFormat:SC C > a=mid:3 > m=video 49170 RTP/AVP 100 > a=rtpmap:100 H264/90000 > a=3dFormat:SC D > a=mid:4 > > This means, that we use the separate streams mechanism + the "BUNDLE" > mechanism to achieve our goal. It this is maybe a bit premature, as the > "BUNDLE" draft is only a personal draft, but it seems to work and we would > not need an extra mechanism in the 3D format draft. > > Admittedly, this solution also looks complex, especially because of the > double grouping mechanism. However, it would not require to define a new > "3daux" attribute and "aux-fmtp" semantics. > > What do you think? > > Best regards, > Bert > > > From: Pedro Capelastegui [mailto:capelastegui@dit.upm.es] > Sent: 10 February 2012 20:33 > To: Bert Greevenbosch; 'IETF - MMUSIC' > Subject: RE: [MMUSIC] The 3D drafts > > Hi Bert, > > After taking another look at the "3d format" draft, I have found a few > additional issues. They are summarized below: > > > 1) Encoding of auxiliary stream: In the "video plus auxiliary stream" > schemes using a single stream (i.e. "LD", "LP", "CD", and "CP"), no > encoding information is provided for the auxiliary stream. > > 2) Ambiguous negotiation for scenarios with multiple 3D streams: > There is no clear way for an offerer to indicate when multiple 3D streams > (e.g. to show in multiple displays) are offered, as opposed to a single 3D > stream with several possible configurations. > > 3) Support for H264/MVC streams: The H264/MVC codec is very well > suited for 3d video applications. It uses some encoding formats that are > not supported by the current draft but could be added without much effort. > I'll cover each topic in a separate mail. Here is some discussion on point > 1), auxiliary stream encoding. > > Auxiliary video streams such as depth maps or parallax can be encoded, > just like any other video stream. In the "Signal 3d format" draft, the > encoding for these streams can be described and negotiated normally when > they are transmitted as separate RTP streams. However, this is no longer > true when depth or parallax maps are encapsulated with a regular view as a > single RTP stream, as defined in ISO 23002-3. This corresponds to the > formats "2DA CD", "2DA CP" , "2DA LD" and "2DA LP" in the draft. > > It could be assumed that, since no encoding information is provided for > these streams, they can use the same encoding used for the video view they > are encapsulated with. As an example, consider the following stream: > > m=video 49170 RTP/AVP 99 > a=rtpmap:99 H264/90000 > a=3dFormat:2DA CD > > The above lines describe a video stream representing a central view, with > a depth map included in the same RTP stream as auxiliary data. The central > view is encoded in H264, but the depth map encoding is undefined. We could > solve this by stating in the draft that, when no encoding is specified for > an auxiliary stream, it uses the same configuration as the same view. > Thus, the depth map in the example would also use H264. > > I think this works well as a default assumption. However, it does not > cover all possible scenarios, as the auxiliary stream CAN use a different > format than the base view. In fact, that will likely be the best > performing configuration, since depth maps have different properties than > regular video streams, and codecs like H264 don't perform particularly > well with them. > > To address this, we would need a way to express the media format for > auxiliary streams. At the very least, this would involve including the > information normally expressed in "a=rtpmap" and "a=fmtp" attributes. > > One possible way to do this would be to add the values of these attributes > (for the auxiliary map) as optional parameters in the "a=3dformat" > attribute. In the previous example, this could look as follows: > > m=video 49170 RTP/AVP 99 > a=rtpmap:99 H264/90000 > a=3dFormat:2DA CD aux-map:H264/90000 aux-fmtp:(...) > > A limitation of this approach is that it just describes a single encoding > for the auxiliary map. Ideally, a solution should allow the offerer to > suggest multiple configurations from which the answerer can choose one, as > with any media stream in the offer/answer model. For this, we could define > a new attribute, like "a=3daux", and include in it a payload type number, > the value of "a=rtpmap" for the auxiliary stream, and the value of > "a=fmtp" for that stream. It could look as follows: > > m=video 49170 RTP/AVP 99 100 > a=3dFormat:2DA CD > a=rtpmap:99 H264/90000 > a=3daux: 99 H263/90000 aux-fmtp:(...) > a=rtpmap:100 H264/90000 > a=3daux: 100 H264/90000 aux-fmtp:(...) > > In this example, the offerer is providing two possible configurations: > > > - PT 99: Central view encoded in H.264, depth map encoded in > H.263 > > - PT 100: Central view and depth map encoded in H.264 > > In addition, there may be other SDP fields or attributes that have to be > taken into account while signalling these auxiliary streams. > > Best regards, > Pedro > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Bert Greevenbosch > Sent: Monday, February 06, 2012 1:32 AM > To: IETF - MMUSIC > Subject: [MMUSIC] The 3D drafts > > Hi all, > > I was wondering, if everybody is happy with the current versions of the 3D > drafts, or are there still open issues? > I look forward to your comments. > > Best regards, > Bert > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/ > http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/ > ________________________________ > > No se encontraron virus en este mensaje. > Comprobado por AVG - www.avg.com > Versión: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de > publicación: 02/05/12 > From yuepeiyu@huawei.com Thu Mar 1 22:11:01 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 8E83B21E8020 for ; Thu, 1 Mar 2012 22:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.813 X-Spam-Level: X-Spam-Status: No, score=-106.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, 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 JPgvxxOpbzVu for ; Thu, 1 Mar 2012 22:11:00 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3D21F8C16 for ; Thu, 1 Mar 2012 22:10:59 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0800EIKUFVJ5@szxga05-in.huawei.com> for mmusic@ietf.org; Fri, 02 Mar 2012 14:09:31 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0800EBCUFVLA@szxga05-in.huawei.com> for mmusic@ietf.org; Fri, 02 Mar 2012 14:09:31 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHN83025; Fri, 02 Mar 2012 14:09:30 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Mar 2012 14:09:05 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.9]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 02 Mar 2012 14:09:29 +0800 Date: Fri, 02 Mar 2012 06:09:28 +0000 From: "yuepeiyu (Roy)" X-Originating-IP: [10.138.73.89] To: "mmusic@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-yue-mmusic-rtsp-substream-control-extension-01.txt Thread-index: AQHM+DsGzngic7uS5kONLG5YMwC7QQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [MMUSIC] New Version Notification for draft-yue-mmusic-rtsp-substream-control-extension-01.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, 02 Mar 2012 06:11:01 -0000 RGVhciBmb2xrcywNCg0KSSBoYXZlIHVwbG9hZGVkIGFuIHVwZGF0ZWQgZHJhZnQgb24gUlRTUCBl eHRlbnNpb25zIGZvciBTdWJzdHJlYW0gY29udHJvbC4gWW91IGNhbiBmaW5kIGl0IGF0Og0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC15dWUtbW11c2ljLXJ0c3Atc3Vic3RyZWFtLWNvbnRy b2wtZXh0ZW5zaW9uLTAxLnR4dA0KDQpDb21wYXJpbmcgdG8gdGhlIHByZXZpb3VzIHZlcnNpb24s IFRoZSBtYWluIGNoYW5nZXMgYXJlOg0KMS4gc3RydWN0dXJlIG9mIHRoZSBkb2N1bWVudDogbm93 IHRoZSBzZWN0aW9uIDQgYW5kIDUgZGVzY3JpYmVzIHByb3RvY29sIGZyYW1ld29yaywgaXNvbGF0 ZSB3aXRoIGFueSBzcGVjaWZpYyBtZWRpYSB0eXBlLiBUaGlzIGlzIGJlbGlldmVkIHRvIGJlIGJl dHRlciBmb3IgZnV0dXJlIGV4dGVuc2lvbi4gU2VjdGlvbiA2IGlzIGFkZGVkIGZvciBTVkMgYW5k IE1WQyByZWxhdGVkIHNwZWNpZmljYXRpb25zLg0KMi4gVXBkYXRlcyBvbiA1NTMgJiA1NTQgcmVz cG9uc2U6IGRlbGV0ZSB0aGUgc3Vic3RyZWFtIGluZm9ybWF0aW9uIGluZGljYXRpb24gaW4gNTUz IGFuZCA1NTQgcmVzcG9uc2UuDQozLiBVcGRhdGVzIG9uIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z DQo0LiBFeGFtcGxlcyBhcmUgYWRkZWQgaW4gc2VjdGlvbiA3Lg0KNS4gVmFyaW91cyBlZGl0b3Jp YWwgbW9kaWZpY2F0aW9uIGFuZCBjb3JyZWN0aW9ucy4NCg0KUGxlYXNlIGhhdmUgYSBsb29rLiBB bnkgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFkdmljZXMgYXJlIGFwcHJlY2lhdGVkIQ0KDQpSZWdh cmRzLCBSb3kNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaX tumXtDogMjAxMuW5tDPmnIgy5pelIDEzOjUxDQrmlLbku7bkuro6IHl1ZXBlaXl1IChSb3kpDQrk uLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteXVlLW1tdXNpYy1ydHNw LXN1YnN0cmVhbS1jb250cm9sLWV4dGVuc2lvbi0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXl1ZS1tbXVzaWMtcnRzcC1zdWJzdHJlYW0tY29udHJvbC1leHRlbnNpb24tMDEu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGVpeXUgWXVlIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC15dWUtbW11c2lj LXJ0c3Atc3Vic3RyZWFtLWNvbnRyb2wtZXh0ZW5zaW9uDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJ CSBSVFNQIEV4dGVuc2lvbiBmb3IgU3Vic3RyZWFtIENvbnRyb2wNCkNyZWF0aW9uIGRhdGU6CSAy MDEyLTAzLTAyDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdl czogMTUNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgZXh0ZW5zaW9ucyB0 byBSVFNQIDIuMCBwcm90b2NvbCwgaW5jbHVkaW5nDQogICBoZWFkZXIgJnF1b3Q7U3Vic3RyZWFt Q3RybCZxdW90OywgZmVhdHVyZSB0YWcgJnF1b3Q7UGxheS5zdWJzdHJlYW0mcXVvdDsgLCBhbmQg cmVsYXRlZA0KICAgbmV3IHN0YXR1cyBjb2Rlcy4gIFRoZXNlIGV4dGVuc2lvbnMgZW5hYmxlcyB0 aGUgcGxheWJhY2sgY29udHJvbCBvZiBhDQogICBtZWRpYSBzdHJlYW0gb24gc3Vic3RyZWFtIGJh c2lzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg== From miguel.a.garcia@ericsson.com Thu Mar 1 23:28:54 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 AA03821E8113 for ; Thu, 1 Mar 2012 23:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.358 X-Spam-Level: X-Spam-Status: No, score=-10.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 082206RyG6cw for ; Thu, 1 Mar 2012 23:28:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5DA21E80AB for ; Thu, 1 Mar 2012 23:28:53 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-36-4f5076b4bf6e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 62.77.27041.4B6705F4; Fri, 2 Mar 2012 08:28:52 +0100 (CET) Received: from [159.107.105.123] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Mar 2012 08:28:51 +0100 Message-ID: <4F5076B3.6040802@ericsson.com> Date: Fri, 2 Mar 2012 08:28:51 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mmusic References: <4F4C135C.2040905@cisco.com> In-Reply-To: <4F4C135C.2040905@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG poll on 3dformat and parallax drafts following recent IPR declarations 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, 02 Mar 2012 07:28:54 -0000 So, from the data below, a patent application of the 3D draft was file on March 2nd 2011, and the first version of the corresponding 3D draft was submitted the following day. What a coincidence!!! The second one: A patent application was filed 6 months before the submission of the first version of the draft, yet none in the authors' affiliated company was apparently aware of this patent application until a couple of weeks ago. It is hard to digest that the procedures of RFC 3979 have been followed here. /Miguel On 28/02/2012 0:35, Flemming Andreasen wrote: > Hello MMUSIC group > > Following the initial submission and WG presentation of the 3dformat and > parallax drafts, the WG expressed an interest in working on these topics > and milestones were added to the MMUSIC charter. At the last IETF, the > chairs polled the group for interest in adopting > > draft-greevenbosch-mmusic-signal-3d-format-02 > > and > > draft-greevenbosch-mmusic-parallax-attribute-01 > > as WG items for these milestones. A WG hum indicated support in the room > for doing so, and hence they were adopted and resubmitted as WG drafts. > > At the time, there was no known IPR on either of these drafts, however > the authors' affiliated company has subsequently submitted IPR > declarations for both of these drafts. Since the 3dformat and parallax > drafts were adopted as WG items without knowledge of the potential IPR > issue, the chairs would like to sense the group for whether it still > wishes to have these as WG items. > > The IPR declarations on the drafts are as follows: > > 1) draft-ietf-mmusic-signal-3d-format-00 had a Huawei IPR declaration 1673: > http://datatracker.ietf.org/ipr/1673/ > > which points to the following patent application: > http://ip.com/sipoen/102137298 > > Apparently this patent application was filed on March 2nd, 201 and the > first version of this draft was published as > draft-greevenbosch-mmusic-signal-3d-format-00.txt on March 3rd, 2011. > > 2) draft-ietf-mmusic-parallax-attribute-00 had a Huawei IPR declaration 1674: > http://datatracker.ietf.org/ipr/1674/ > > which points to the following patent application: > http://ip.com/sipoen/102137264 > > Apparently this patent application was filed on August 25th, 2010 and the > first version of this draft was submitted as > draft-greevenbosch-mmusic-parallax-attribute-00.txt on February 25th, 2011. > > > We would like to remind all WG participants of their obligation to > dislose any known IPR in accordance with RFC 3979 and in particular in > accordance with the procedures stated in Section 6.2.1 of RFC 3979, which > says: > > The IPR disclosure required pursuant to section 6.1.1 must be made as > soon as reasonably possible after the Contribution is published in an > Internet Draft unless the required disclosure is already on file. > > > The CCAMP WG experienced a similar incident recently, and as a result > sent out a more detailed reminder, which is appropriate for everybody > here to read as well: > > http://www.ietf.org/mail-archive/web/ccamp/current/msg13082.html > > Again, since the 3dformat and parallax drafts were adopted as WG items > without knowledge of the potential IPR issue, the chairs are hereby > soliciting the WG for feedback as to whether people still wish to have > these drafts as WG items. > > > Please comment > > Flemming and Miguel (MMUSIC chairs) > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From harald@alvestrand.no Fri Mar 2 04:43:07 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 157A621F8BD2 for ; Fri, 2 Mar 2012 04:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 j1OWoxtLJMUq for ; Fri, 2 Mar 2012 04:43:06 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8633C21F8BCA for ; Fri, 2 Mar 2012 04:43:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BEE5339E0A7; Fri, 2 Mar 2012 13:43:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1CwBfOVQK+K; Fri, 2 Mar 2012 13:43:00 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 39DF339E01E; Fri, 2 Mar 2012 13:43:00 +0100 (CET) Message-ID: <4F50C053.6070806@alvestrand.no> Date: Fri, 02 Mar 2012 13:42:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4F473A0C.7060407@ericsson.com> In-Reply-To: <4F473A0C.7060407@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic , Christer Holmberg Subject: Re: [MMUSIC] Agenda requests from IETF 83 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, 02 Mar 2012 12:43:07 -0000 On 02/24/2012 08:19 AM, Miguel A. Garcia wrote: > MMUSIC will meet for 2.5 hours at IETF 83 in Paris. > > If you want to request a time slot to discuss a draft, please send an > e-mail to Flemming and myself. > > As usually, we want to remind you that we should smartly use our > meeting time. In principle, the meeting time should be use to discuss > open issues. We give priority to drafts that gather attention and > discussion in the mailing list prior to the meeting. > > /Miguel I would like to make sure two drafts are on the agenda: - draft-ietf-mmusic-sdp-bundle-negotiation (this is already in charter, with Christer as the lead) - draft-alvestrand-rtcweb-msid-01 The last one is a quite simple functionality needed by the W3C WebRTC WG's proposed "media stream" concept, which it proposes to use with RTCWEB connections. I think 15 minutes should be perfectly adequate for this draft in MMUSIC. Harald From miguel.a.garcia@ericsson.com Fri Mar 2 05:47:37 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 CFED221F87FA for ; Fri, 2 Mar 2012 05:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 kA+N2hCSPfuf for ; Fri, 2 Mar 2012 05:47:37 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id ABEC621F87F8 for ; Fri, 2 Mar 2012 05:47:36 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-42-4f50cf77da2b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C5.C2.27041.77FC05F4; Fri, 2 Mar 2012 14:47:35 +0100 (CET) Received: from [159.107.105.123] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Fri, 2 Mar 2012 14:47:35 +0100 Message-ID: <4F50CF76.9000902@ericsson.com> Date: Fri, 2 Mar 2012 14:47:34 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4F473A0C.7060407@ericsson.com> <4F50C053.6070806@alvestrand.no> In-Reply-To: <4F50C053.6070806@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , mmusic , Christer Holmberg Subject: Re: [MMUSIC] Agenda requests from IETF 83 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, 02 Mar 2012 13:47:37 -0000 Harald, Agenda request received. Since this draft is, in principle, addressed to the RTCWEB WG, it would be good if you send a separate mail to the MMUSIC mailing list, where you inform of the draft, and motive why is interesting to MMUSIC, and give an advance of the issues you want to discuss. BR, MIguel On 02/03/2012 13:42, Harald Alvestrand wrote: > On 02/24/2012 08:19 AM, Miguel A. Garcia wrote: >> MMUSIC will meet for 2.5 hours at IETF 83 in Paris. >> >> If you want to request a time slot to discuss a draft, please send an >> e-mail to Flemming and myself. >> >> As usually, we want to remind you that we should smartly use our >> meeting time. In principle, the meeting time should be use to discuss >> open issues. We give priority to drafts that gather attention and >> discussion in the mailing list prior to the meeting. >> >> /Miguel > I would like to make sure two drafts are on the agenda: > > - draft-ietf-mmusic-sdp-bundle-negotiation (this is already in charter, > with Christer as the lead) > - draft-alvestrand-rtcweb-msid-01 > > The last one is a quite simple functionality needed by the W3C WebRTC > WG's proposed "media stream" concept, which it proposes to use with > RTCWEB connections. > > I think 15 minutes should be perfectly adequate for this draft in MMUSIC. > > Harald > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From atle.monrad@ericsson.com Sat Mar 3 02:01:52 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 0438521F86C2 for ; Sat, 3 Mar 2012 02:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.389 X-Spam-Level: X-Spam-Status: No, score=-9.389 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 93s6VV12leqg for ; Sat, 3 Mar 2012 02:01:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E742921F86BD for ; Sat, 3 Mar 2012 02:01:49 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-c1-4f51ec0cbb40 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D3.2F.01970.C0CE15F4; Sat, 3 Mar 2012 11:01:48 +0100 (CET) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.95]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Sat, 3 Mar 2012 11:01:48 +0100 From: Atle Monrad To: mmusic Date: Sat, 3 Mar 2012 11:01:43 +0100 Thread-Topic: Progress of draft-garcia-mmusic-sdp-miscellaneous-caps Thread-Index: Acz5JKK/44qq9MLTTLuJjBpT+1+5nw== Message-ID: <7A051DFAA46D0246A82293C7CEF621E90685094258@ESESSCMS0352.eemea.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: multipart/related; boundary="_005_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Progress of draft-garcia-mmusic-sdp-miscellaneous-caps 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, 03 Mar 2012 10:01:52 -0000 --_005_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_ Content-Type: multipart/alternative; boundary="_000_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_" --_000_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All Together with draft-ietf-mmusic-sdp-cs & draft-ietf-mmusic-sdp-media-capabi= lities, the draft-garcia-mmusic-sdp-miscellaneous-caps is important to 3GPP= and are pending items for 3GPP Release-8. These drafts have been in the pipeline for long time, and it is appreciated= if the topics can be completed as soon as possible. In order to pick up speed, it would be appreciated if mmusic can adopt draf= t-garcia-mmusic-sdp-miscellaneous-caps as a WG item before the IETF meeting= in Paris. Thanks /atle ATLE MONRAD 3GPP CT Chairman Standardization and Regulation Group Function Technology and Portfolio Management [http://www.ericsson.com/shared/images/Email.gif] This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All
 
Together = with=20 draft-ietf-mmusic-sdp-cs &=20 draft-ietf-mmusic-sdp-media-capabilities,=20 the=20 draft-garcia-mmusic-sdp-miscellaneous-caps is important to 3GPP and are pen= ding=20 items for 3GPP Release-8.
 
These dra= fts have=20 been in the pipeline for long time, and it is appreciated if the topics can= be=20 completed as soon as possible.
 
In order = to pick up=20 speed, it would be appreciated if mmusic can adopt=20 draft-garcia-mmusic-sdp-miscellaneous-caps as a WG item before the IET= F=20 meeting in Paris.
 
Thanks
/atle
 


3Dline

ATLE=20 MONRAD
3GPP CT=20 Chairman


Standardizatio= n and=20 Regulation
Group Function Technology and Portfolio Management
=



3Dhttp://www.ericsson.com/


This Communica= tion is=20 Confidential. We only send and receive email on the basis of the terms set = out=20 at www.ericsson.com/email_di= sclaimer=20

 
--_000_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_-- --_005_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_ Content-Type: image/gif; name="Email_line.gif" Content-Description: Email_line.gif Content-Disposition: inline; filename="Email_line.gif"; size=1417; creation-date="Sat, 03 Mar 2012 10:01:45 GMT"; modification-date="Sat, 03 Mar 2012 10:01:45 GMT" Content-Location: http://www.ericsson.com/shared/images/Email_line.gif Content-Transfer-Encoding: base64 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --_005_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_ Content-Type: image/gif; name="Email.gif" Content-Description: Email.gif Content-Disposition: inline; filename="Email.gif"; size=1809; creation-date="Sat, 03 Mar 2012 10:01:46 GMT"; modification-date="Sat, 03 Mar 2012 10:01:46 GMT" Content-Location: http://www.ericsson.com/shared/images/Email.gif Content-Transfer-Encoding: base64 R0lGODlh9AFRAPcAAId6ryxvsAtXo8zr6BBJmdIaXiuWxACZi5nW17ritehtmC6skFWWx3YdbtfD 2ffg6qpUjgCXpb3X6gCYnGvHjKbbqaypzHvCQSmsSpnXzI3RjQCcZxKkauLx1OWUtcXjpq3ftkQj ed7r9ACMuieltdekwo5Xlbvh6ur25oy118MaYQiiUwCaeM7s3tc5dNbV5u71+hg7jnfE1tjuzZnS 4qbUcZXPb6bXiLIvcojM3MfmswN8uVW7tKrY5rWWve6jv+zh7ENysSpGlJ2bw5vZvaoaZWa8Q4TQ npYvd2g/iCwqgBGatpsbZ7R3p1m5RILEQMeVuunR4YUca3m32fL68wCeW5rM47Xfp/Tw9gCTsm9v qUu6cEahywOCurMaY3JRlG6Yxse10b3l1YjQuRSmT2e41UyFvZSjyhGhhEi6gt4oZ8tIgZ+52HbH cYrD3sOlxtTu223AUk62RY6v04jO00S2ld7y6+749atonUKzRka2U1W8nLTiw9SVuM3m8X3NoJDV rfXR3/rw9WbDpyhYobqGsTGFvq3M4zOiyFEgdeCjwamYwHMtemO/Wd3w9TQnfTq0ZTq1drW713fK s+NHfarezK6Hs+TC1tSzzmbCuL/iptmFrKGz1FtTmIGbxtrw2rXdms/c7BGdqnuu07qmyFas0glg qiKpe4k7gRWFvj+yR8rqzojJW14fc1S6VHSKu8V2pCEyh/Oyya6Xv4jPy2qp0fPC1Krd1BKSwIjS shpmrFW5xrfcjBd5t+azyzg6isLL4YvGPwZusjKvSO73+u+Us94ZXHvGXFikz2GDuY7JTbHA2w6k UUSww+Dm8ZGozn2mzjayVojFQCuvaavgx1aw0ojHTsLhmZzA3ZTKTFfAjMSFr4jQwpegx37ET1M6 iEBehn+Trr/J1xA1aJ+uwu/y9t/k68/X4WB5mzBQfCBDcprYqnCGpY+huK+8zE9rkqatz9brv7/R 5ZbNWRhusshmmI+r0Kvbm3TAQiKrW5dpobvfmt1XiaGJtgAoXv///ywAAAAA9AFRAAAI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1L1qC5duHC iSvLtq3bqeTe+Zs7F93bu3jz/hSHbhzdv/7I6R1MuPBKc+zUAV4MzrDjx5AxlmuXbrFlf40ja97M uWDcy6Azdx5NWi9fv6BBCy7NurVYxIpTp2bnurZtrJMrywatjp2528CDPz0Xe7dldO6EK1+eVLfx v+nIlWNOvXrQc8/p9v5tvbt3neKe/o9Dt7bgOXbg3q3+zr49yvCywUkveLb4XNHu8+v3aP+vunbc DVQOOeCA1s5+CCZ40TmozTXeOQa5g85u+Clo4YULTYYOO+sNdF6D8WEo4ogOneXcc++QqOKKAg0o V3Z/JcfijBZKCCKM43RI447swQYjYOm0Mx2PRH7H4I/a+Vbkkt/19xxyTEbZHXzZyTeklFgyR6Vs 6oQT4EBxgQNOOFdmaeZo2KU2XnkEndMXkGWeKWdkBVqmnlnhOElXOHP2GVk5J/735T8DnnhZhX4m Opg7aUFYkDsvGoeoopQW5uaNu6VY6aaDmZMnknOxyemoZRUK6lzqyEjqqmGdEymo/u+oyuqsXblz qj/RxUnrrllhutt2vAbL1Za7jSersMheRWxo8yXrLFZp8ubls9RmVSdgD1arLW7X+nPntuBCS447 g4Zr7rnopqvuuuy26+678MYr77z01mvvvfiqe444/PKr0IBpkeMowOG0MzA5aRk8kDkIh+NovvRa tla3/uQoUKgChbPYP0fS1Rg5IGbGDpCO0lVegXxCfO5c6YgpJoQUzzUdxiOjCk5l/8TWcsv/oLZz Yxrf5/PF9wmEssor+yOq0XMRqttaoZpD14EC/eaggPClI2DPcx1YDmqC/TWxPykjDW7X/Z4cqjt+ jUO0OOSwbBBqvUFYTpK/wee2+UA181kXZv8cbfbZGweOrYyhBl02mIDZVfOe8InWTtFzSR2Y4INr W1daaTENWHmhTu7tQZfSBeFpdMWN60BB09a0xupgnjm1GBdU5z+i2/VPqNE+bNCLbAI6l62VC6Tb gU1/XTHZs2vuDzqcT3v73RW/bfjmef7zDjrttIOaOL2hhZo5E+L6WcUz+5Pxns1XK/H1Ar0YttKE xizOjY0tZpfwf42DuPqEQs3i2oes6HHuN+jJjDvExKe0BEhCLvNNOFwGDiH9I4Fi6lCYwKGkjJVN HGlZGgFHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMYUUCAgA7 --_005_7A051DFAA46D0246A82293C7CEF621E90685094258ESESSCMS0352e_-- From keith.drage@alcatel-lucent.com Sat Mar 3 03:21:21 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 830F021F871E for ; Sat, 3 Mar 2012 03:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.433 X-Spam-Level: X-Spam-Status: No, score=-109.433 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 ZbywbiHA-LjI for ; Sat, 3 Mar 2012 03:21:20 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4825A21F871D for ; Sat, 3 Mar 2012 03:21:20 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q23BLED3023863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Mar 2012 12:21:15 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 3 Mar 2012 12:21:14 +0100 From: "DRAGE, Keith (Keith)" To: "Miguel A. Garcia" , mmusic Date: Sat, 3 Mar 2012 12:21:13 +0100 Thread-Topic: [MMUSIC] WG poll on 3dformat and parallax drafts following recent IPR declarations Thread-Index: Acz4RiWnhhMaG7TJRiiTkLJzpcrKZAA6W57w Message-ID: References: <4F4C135C.2040905@cisco.com> <4F5076B3.6040802@ericsson.com> In-Reply-To: <4F5076B3.6040802@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG poll on 3dformat and parallax drafts following recent IPR declarations 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, 03 Mar 2012 11:21:21 -0000 I believe we should have a discussion on this at Paris, and then after that= totally rerun the question for the adoption of the text of these drafts. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 02 March 2012 07:29 > To: mmusic > Cc: Flemming Andreasen > Subject: Re: [MMUSIC] WG poll on 3dformat and parallax drafts following > recent IPR declarations >=20 > >=20 > So, from the data below, a patent application of the 3D draft was file on > March 2nd 2011, and the first version of the corresponding 3D draft was > submitted the following day. What a coincidence!!! >=20 > The second one: A patent application was filed 6 months before the > submission of the first version of the draft, yet none in the authors' > affiliated company was apparently aware of this patent application until > a couple of weeks ago. >=20 > It is hard to digest that the procedures of RFC 3979 have been followed > here. >=20 > /Miguel >=20 > >=20 > On 28/02/2012 0:35, Flemming Andreasen wrote: > > Hello MMUSIC group > > > > Following the initial submission and WG presentation of the 3dformat an= d > > parallax drafts, the WG expressed an interest in working on these topic= s > > and milestones were added to the MMUSIC charter. At the last IETF, the > > chairs polled the group for interest in adopting > > > > draft-greevenbosch-mmusic-signal-3d-format-02 > > > > and > > > > draft-greevenbosch-mmusic-parallax-attribute-01 > > > > as WG items for these milestones. A WG hum indicated support in the roo= m > > for doing so, and hence they were adopted and resubmitted as WG drafts. > > > > At the time, there was no known IPR on either of these drafts, however > > the authors' affiliated company has subsequently submitted IPR > > declarations for both of these drafts. Since the 3dformat and parallax > > drafts were adopted as WG items without knowledge of the potential IPR > > issue, the chairs would like to sense the group for whether it still > > wishes to have these as WG items. > > > > The IPR declarations on the drafts are as follows: > > > > 1) draft-ietf-mmusic-signal-3d-format-00 had a Huawei IPR declaration > 1673: > > http://datatracker.ietf.org/ipr/1673/ > > > > which points to the following patent application: > > http://ip.com/sipoen/102137298 > > > > Apparently this patent application was filed on March 2nd, 201 and the > > first version of this draft was published as > > draft-greevenbosch-mmusic-signal-3d-format-00.txt on March 3rd, 2011. > > > > 2) draft-ietf-mmusic-parallax-attribute-00 had a Huawei IPR declaration > 1674: > > http://datatracker.ietf.org/ipr/1674/ > > > > which points to the following patent application: > > http://ip.com/sipoen/102137264 > > > > Apparently this patent application was filed on August 25th, 2010 and > the > > first version of this draft was submitted as > > draft-greevenbosch-mmusic-parallax-attribute-00.txt on February 25th, > 2011. > > > > > > We would like to remind all WG participants of their obligation to > > dislose any known IPR in accordance with RFC 3979 and in particular in > > accordance with the procedures stated in Section 6.2.1 of RFC 3979, > which > > says: > > > > The IPR disclosure required pursuant to section 6.1.1 must be made as > > soon as reasonably possible after the Contribution is published in an > > Internet Draft unless the required disclosure is already on file. > > > > > > The CCAMP WG experienced a similar incident recently, and as a result > > sent out a more detailed reminder, which is appropriate for everybody > > here to read as well: > > > > http://www.ietf.org/mail- > archive/web/ccamp/current/msg13082.html > > > > Again, since the 3dformat and parallax drafts were adopted as WG items > > without knowledge of the potential IPR issue, the chairs are hereby > > soliciting the WG for feedback as to whether people still wish to have > > these drafts as WG items. > > > > > > Please comment > > > > Flemming and Miguel (MMUSIC chairs) > > >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@nomadiclab.com Mon Mar 5 03:15:09 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 EB32721F8739 for ; Mon, 5 Mar 2012 03:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 6pZUpRZu0Gv3 for ; Mon, 5 Mar 2012 03:15:09 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAFF21F8735 for ; Mon, 5 Mar 2012 03:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E77C34E6E8; Mon, 5 Mar 2012 13:15:07 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVoYxjblwyqm; Mon, 5 Mar 2012 13:15:02 +0200 (EET) Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 663374E66C; Mon, 5 Mar 2012 13:15:01 +0200 (EET) Message-ID: <4F54A033.5010700@nomadiclab.com> Date: Mon, 05 Mar 2012 13:14:59 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <20120305110420.16390.76868.idtracker@ietfa.amsl.com> In-Reply-To: <20120305110420.16390.76868.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120305110420.16390.76868.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Jari Arkko Subject: [MMUSIC] Fwd: New Version Notification for draft-keranen-mmusic-ice-address-selection-00.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: Mon, 05 Mar 2012 11:15:10 -0000 Folks, We have written a new draft about how different addresses should be selected and combined when ICE NAT traversal is used: http://tools.ietf.org/html/draft-keranen-mmusic-ice-address-selection-00 This draft was requested on an IESG review of the ICE TCP draft to clarify how different kind of IPv6 addresses (e.g. ULAs) should be handled. However, since the same rules apply also to UDP ICE, a separate draft was written instead of updating the rules in the ICE TCP draft. Also, we propose a couple of new rules that also affect IPv4 (namely, to not use loop back and not combine relayed candidates with private-range addresses). Comments are welcome! Cheers, Ari -------- Original Message -------- Subject: New Version Notification for draft-keranen-mmusic-ice-address-selection-00.txt Date: Mon, 5 Mar 2012 12:04:20 +0100 From: internet-drafts@ietf.org To: Ari Keränen CC: jari.arkko@piuha.net A new version of I-D, draft-keranen-mmusic-ice-address-selection-00.txt has been successfully submitted by Ari Keranen and posted to the IETF repository. Filename: draft-keranen-mmusic-ice-address-selection Revision: 00 Title: Update on Candidate Address Selection for Interactive Connectivity Establishment (ICE) Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 7 Abstract: This document revisits the rules on how candidate addresses are selected and combined when the Interactive Connectivity Establishment (ICE) NAT traversal method is used. This document updates RFCs 5245 and 6544. The IETF Secretariat From harald@alvestrand.no Mon Mar 5 06:29:29 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 B216A21F8725 for ; Mon, 5 Mar 2012 06:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Sn+Wf0o4M2rS for ; Mon, 5 Mar 2012 06:29:29 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 120E021F8718 for ; Mon, 5 Mar 2012 06:29:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11DEA39E08A for ; Mon, 5 Mar 2012 15:29:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icW5WvRsLfpC for ; Mon, 5 Mar 2012 15:29:16 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 08B5D39E062 for ; Mon, 5 Mar 2012 15:29:16 +0100 (CET) Message-ID: <4F54CDBB.9040205@alvestrand.no> Date: Mon, 05 Mar 2012 15:29:15 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Request for MMUSIC review: draft-alvestrand-rtcweb-msid-01 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, 05 Mar 2012 14:29:29 -0000 Hello, this is a request for a cross-group review and evaluation for wider application: In the WebRTC effort, the W3C group has identified a preferred programming model that involves bundling one or more video or audio tracks together in something called a "MediaStream". The RTCWEB WG has decided that it is not appropriate to use a CNAME to group these together, since one identity or synchronization context (which CNAME is the primary identifier for) may be the source of multiple MediaStreams. This means that media flows inside an RTP session have to be associated with MediaStreams some other way. One suggestion for this function is described here: draft-alvestrand-rtcweb-msid-01 which also contains some background and notes about other approaches we did not pick. A presentation of the function is available from the minutes of the RTCWEB interim meeting here: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.html the URL of the presentation is: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-5.pdf I hope this information is suitable for the MMUSIC group to give guidance on further processing, including whether this draft needs to be an MMUSIC draft or an RTCWEB draft. Harald From internet-drafts@ietf.org Tue Mar 6 01:26: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 D939E21F87EE; Tue, 6 Mar 2012 01:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 IVyYJ+cOP0WA; Tue, 6 Mar 2012 01:26:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B0121F87E4; Tue, 6 Mar 2012 01:26:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 01:26:27 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Tue, 06 Mar 2012 09:26:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-10.txt Pages : 34 Date : 2012-03-06 This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt From Simo.Veikkolainen@nokia.com Tue Mar 6 01:34:34 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 2002421F8810 for ; Tue, 6 Mar 2012 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.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 Dvg0lxPqTxPD for ; Tue, 6 Mar 2012 01:34:33 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65921F8800 for ; Tue, 6 Mar 2012 01:34:32 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q269YUG2009461; Tue, 6 Mar 2012 11:34:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 11:34:29 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.186]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Tue, 6 Mar 2012 10:34:29 +0100 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt Thread-Index: AQHM+3tLdQaPmKC0lECFviDRi6kLvJZdAYyA Date: Tue, 6 Mar 2012 09:34:28 +0000 Message-ID: References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> In-Reply-To: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYkm5/qUrMzogd3WFmWpWApLUd1Re7e4m347Lxwl+/yYexmdYyCpu/q+En6V6AWbVmZRCV4GIhxMAjx9CS2Rl1w45RQJBR9DEOYUMeAk+d3GyJ5zBlA7rLisySd6BkAVnUOThP5WxEHsaLtD/FxrWjy/s459Ge1cTePSr9+1aWxVczmhbDBeZ7Xvyw8n5RotpXg== x-originating-ip: [88.114.28.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2012 09:34:29.0633 (UTC) FILETIME=[5455D710:01CCFB7C] X-Nokia-AV: Clean Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Tue, 06 Mar 2012 09:34:34 -0000 We have submitted a new version (-10) of Session Description Protocol (SDP)= Extension For Setting Up Audio and Video Media Streams Over Circuit-Switch= ed Bearers In The Public Switched Telephone Network (PSTN), which can be fo= und at http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt Changes in this version include: - The port number in "m=3D" line SHOULD be set to "9" (the discard port) bu= t it MUST be ignored at reception - Clarified that the Discriminator byte is included in the cs-correlation:u= uie attribute, but we don't specify a value for the Discriminator byte - Added a new example with audio and video streams - Added a new section "Considerations for Usage of Third Party Call Control= (3PCC)" which recommends the Controller to use "-" as the connection addr= ess (to be in line with 0.0.0.0 which is used for IPv4). - Added a new paragraph to security considerations on privacy concerns that= arise from including the phone number in the SDP Regards, Simo & Miguel -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 6. maaliskuuta 2012 11:26 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-10.txt Pages : 34 Date : 2012-03-06 This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Mar 6 11:48:48 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 0E5E721E80B4 for ; Tue, 6 Mar 2012 11:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 bj8t8pUC6eNQ for ; Tue, 6 Mar 2012 11:48:47 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61521F8757 for ; Tue, 6 Mar 2012 11:48:46 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id iJ3q1i00627AodY58Komji; Tue, 06 Mar 2012 19:48:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id iKom1i01r07duvL3fKom2m; Tue, 06 Mar 2012 19:48:46 +0000 Message-ID: <4F566A1C.3040406@alum.mit.edu> Date: Tue, 06 Mar 2012 14:48:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Tue, 06 Mar 2012 19:48:48 -0000 On 3/6/12 4:34 AM, Simo.Veikkolainen@nokia.com wrote: > We have submitted a new version (-10) of Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN), which can be found at http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt > > Changes in this version include: > - The port number in "m=" line SHOULD be set to "9" (the discard port) but it MUST be ignored at reception > - Clarified that the Discriminator byte is included in the cs-correlation:uuie attribute, but we don't specify a value for the Discriminator byte I know this has been discussed before, but it still bothers me: Is there a reason why the representation of this UUIE is so different from the representation used in draft-ietf-cuss-sip-uui-isdn-02? These things are talking about conveying the same thing in the same manner. IMO it would be much better to be consistent about this. Is it because implementations of this draft have already been deployed? > - Added a new example with audio and video streams While its good to seen the new example, as shown it has missed the main issue that will arise, because it only shows the situation when one of the proposed streams is rejected. If both streams are to be accepted, are they to result in one pstn phone call, or two? I would think the intent would be to have only one. But in that case, how is it represented in SDP so that its known that only one call is made? Is there an assumption that if one phone number is used for multiple m-lines, then the same call should be used for both? Thanks, Paul > - Added a new section "Considerations for Usage of Third Party Call Control (3PCC)" which recommends the Controller to use "-" as the connection address (to be in line with 0.0.0.0 which is used for IPv4). > - Added a new paragraph to security considerations on privacy concerns that arise from including the phone number in the SDP From Bert.Greevenbosch@huawei.com Tue Mar 6 18:54:49 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 A9E3821F8596 for ; Tue, 6 Mar 2012 18:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 UXj8cOvcubjJ for ; Tue, 6 Mar 2012 18:54:48 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99B21F856D for ; Tue, 6 Mar 2012 18:54:48 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H000L9UR4FG@szxga04-in.huawei.com> for mmusic@ietf.org; Wed, 07 Mar 2012 10:54:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H00AK8UR4M9@szxga04-in.huawei.com> for mmusic@ietf.org; Wed, 07 Mar 2012 10:54:40 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHQ28083; Wed, 07 Mar 2012 10:54:40 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 10:54:33 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.86]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 07 Mar 2012 10:54:36 +0800 Date: Wed, 07 Mar 2012 02:54:35 +0000 From: Bert Greevenbosch In-reply-to: <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> X-Originating-IP: [10.70.109.135] To: "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Hitchhiker's guide to SDP Thread-index: AQHM8ibrK1fnIxUm3UOSjsFPFGU6nZZKMLAAgAAGtYCABO9jgIAN0jKA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 02:54:50 -0000 Hi all, On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied most initial text from there, and in addition included an initial list of RFCs / drafts that seem relevant. https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ If the group is happy with this approach, I will be happy to maintain an editor's role, and write more text. Obviously other people's input will be highly appreciated, and indeed is needed. I look forward to your comments. Best regards, Bert P.S. Unfortunately, I forgot to include "mmusic" in the name of the draft. How to deal with this? -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 27 February 2012 04:53 To: Gonzalo Camarillo; Mary Barnes Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP Hi, As a directorate member, I am willing to co-author such draft, should a decision to write one be taken. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: 23. helmikuuta 2012 19:31 To: Mary Barnes Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP I agree. Gonzalo On 23/02/2012 7:06 PM, Mary Barnes wrote: > I would think that in order for the document to have integrity that at > least one of the directorate members should at least be a co-author. > Otherwise, I see a lot more stuff falling through the cracks and > needing to be resolved during WGLC and later, which usually isn't a > good thing. The SIP Hitchhiker's guide provides a good example in > that the author was also a primary contributor to RFC3261, etc. > > Mary. > > On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > > > wrote: > > Hi Mary, > > yes, the members of the SDP directorate would need to review such a > guide. However, the fact that they agreed to be members of the > directorate does not mean they will necessarily have cycles to > significantly contribute to the creation of the guide. We need to make > sure we have enough energy around this effort in order to start it. > > Cheers, > > Gonzalo > > On 15/02/2012 7:14 PM, Mary Barnes wrote: > > I think this is a good idea. I would think the experts that can > > contribute (and should review) can be found in the new SDP > > directorate: > > http://www.ietf.org/iesg/directorate/sdp.html > > BTW, it would be nice to have a link to this page on the MMUSIC WG > wiki: > > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > > > As far as whether to publish, I think it would be a good idea to > > complete publication as IMHO that improves the integrity of the > > information - i.e., more eyes review a published RFC than a draft. > > It could later be updated to reflect more recent RFCs OR a "More of > > Hitchhikers Guide" could be published. > > > > Thanks, > > Mary. > > > > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > > > wrote: > >> Hi Miguel, Andrew, all, > >> > >> Sounds like a good idea. I would be happy to volunteer to play a > central role in it (i.e. be the editor, create the initial draft, > ...), but I would need support from other experts too. > >> > >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" > has become an RFC (5411). That means that it has been frozen, and to > add new info new individual or WG drafts are needed. > >> > >> Would this be the same approach for SDP? Currently, there are > already quite some new drafts that extend SDP. How will future > extensions be handled? Maybe it would be good to make it a permanent > WG draft, which is updated every now and then. > >> > >> Best regards, > >> Bert > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org ] On > Behalf Of Miguel A. Garcia > >> Sent: 14 February 2012 15:42 > >> To: Andrew Allen > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> > >> Sounds good to me too. If someone wants to start such draft... > >> > >> /Miguel > >> > >> On 13/02/2012 23:15, Andrew Allen wrote: > >>> > >>> What about considering a hitchhikers guide to SDP similar to > what was done for SIP? > >>> > >>> One umbrella document that points the reader to all the SDP > capabilities available that they might want to take advantage of. > >>> > >>> Just a suggestion. > >>> > >>> Andrew > >>> > >>> ----- Original Message ----- > >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com > ] > >>> Sent: Saturday, January 28, 2012 06:23 AM > >>> To: mmusic> > >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >>> > >>> > >>> > >>> Hi all, > >>> > >>> You know we are revising RFC 4566. So far, the effort has been > in bug fixing. > >>> > >>> The first SDP version was published as RFC 2327 in 1998 (i.e., > 14 years > >>> ago), and was then revised as RFC 4566 in 2006. > >>> > >>> Lots of things have happened since then. We have SDP offer answer, > >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, > >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. > >>> > >>> From the point of view of a reader who takes 4566 (or its current > >>> 4566bis incarnation), I think it will be difficult for her or him to > >>> understand a protocol that ignores those other extensions. For > example, I > >>> recently post another e-mail where there is an apparent > contradiction > >>> between 4566 and ICE (see > >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). > >>> > >>> So, I was wondering if time has come to make not a bug correction in > >>> 4566bis, but also put that RFC in context with the other > extensions that > >>> exist. This may include: > >>> > >>> - Add minor extensions to the core document, similarly to what > we did > >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which > of these > >>> extensions make sense to include, this would be an exercise to > do, but > >>> let me give you one potential example: RFC 4574, the SDP "label" > >>> attribute is a 6 pages RFC. > >>> > >>> - Adding references to extensions, when it makes sense. For > example, ICE > >>> should be referred somewhere (see my previous post regarding the "o" > >>> line). I guess capneg could be also mentioned, perhaps others. > >>> > >>> I know this is a bigger effort than anticipated, but the result > could > >>> really help newcomers to this world. > >>> > >>> Now, it is your turn to express your opinions. Please do it. > >>> > >>> /Miguel > >> > >> -- > >> Miguel A. Garcia > >> +34-91-339-3608 > >> Ericsson Spain > >> _______________________________________________ > >> 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 > > _______________________________________________ > > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Wed Mar 7 01:58:46 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 5BBC721F8794 for ; Wed, 7 Mar 2012 01:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, 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 4-THSM2iz880 for ; Wed, 7 Mar 2012 01:58:45 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 07FB521F8792 for ; Wed, 7 Mar 2012 01:58:44 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-12-4f5731354003 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 31.D4.27041.531375F4; Wed, 7 Mar 2012 10:58:13 +0100 (CET) Received: from [159.107.24.251] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Mar 2012 10:58:08 +0100 Message-ID: <4F57312F.9010607@ericsson.com> Date: Wed, 7 Mar 2012 10:58:07 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EF12965.8030709@acm.org> In-Reply-To: <4EF12965.8030709@acm.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Error in RFC 5245 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, 07 Mar 2012 09:58:46 -0000 Hi: I am following up on this old e-mail by Marc, and we haven't seen a reaction. The issue is that there is a contradiction in RFC 5245, as Marc explains below: > Section 15.3 states that: > > '"ice-mismatch" is a media-level attribute only.[...]' > > But section 21.1.4 (and IANA) declares this attribute as a session level attribute. Needless to say, the IANA registry of SDP parameters follows section 21.1.4 and lists ice-mismatch as a session-level attribute I believe that the spirit of RFC 5245 is that ice-mismatch is a media-level only attribute. For example, Section 6.1 hints it: In some cases, the answer may omit a=candidate attributes for the media streams, and instead include an a=ice-mismatch attribute for one or more of the media streams in the SDP. and later Section 15.3: "ice-mismatch" is a media-level attribute only, and when present in an answer, indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. With this, I think it is clear that "ice-mismatch" is a media-level only attribute, and we should fix the RFC and the IANA registry. I think we should first file an Errata towards RFC 5245. Marc, can you file it? When we get it approved, we can work with our ADs to fix the IANA registry. /Miguel On 21/12/2011 1:33, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Section 15.3 states that: > > '"ice-mismatch" is a media-level attribute only.[...]' > > But section 21.1.4 (and IANA) declares this attribute as a session level attribute. > > It seems logical to have ice-mismatch as a media level attribute, but I guess > that something more than an errata is needed to fix the wrong IANA declaration. > > What is the process in this case? > > Thanks. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQIcBAEBCAAGBQJO8SlkAAoJECnERZXWan7EtB4P/2FYooLdQYaNT297tBFTgoJk > k8DWm79c+8NCm6WtlHwuisqWfTry9zRUS+Lr9ViCpid5hC1tv2l0cFP5tbR+jXsB > 0+9zlaorZ6AgbNZucGxOcV0tnVVfQN8pH7V74rSbChknEVL4buybLED2OGrJe1n8 > Q+0wHeT31J1Csc8s/wwzlePFl/J8FpRPAd9DIzSYvHlpCUpbnVuasEpvYwC4+XXp > XlR2HxtXw7D19sE9dz1xl1kAdYMlkyioaxZy8C3mNbM6BJxzTMB2FOjrb11M/ykV > zakIYGfX6HbzmyRf7Tu5s5XZY6Tv92R31RkcEOQbPrwycZtPJkn+iGHxd7ab5E0S > vPDxuu5LzoFcv9PSuYMIw7cWOXrbd/VLnXJErluU8GdhDBCVAvbckw9Wrm5COhlU > 52rRphlmlBq9dpcvNdsbiAzuT4PcKCBugiOrOX70QTOy4DnWDXTDeInuXqHE296/ > ztn7+iX0nLBqwyVLvTX6TwxusKs3lrj11g6y+6dfoqPS5hRjyq59VChYQm79qNd3 > P8hXdvLWx9yRKWg30k1DBsnb6cz7zWnDUaN2Ks6OOkN+nC1MKdV/m89qkCJ0eI28 > fV3Lb7Lb4A2pJ3sZq8MYu+0qV/LdcJeYdb/PIJk+Jm+Icj0dHU0EU86i0Wq9VcEL > pXAEb2PJntrS6oAv4YC+ > =bJdZ > -----END PGP SIGNATURE----- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Mar 7 02:49:25 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 7BFC021F86EF for ; Wed, 7 Mar 2012 02:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.379 X-Spam-Level: X-Spam-Status: No, score=-10.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 lIYMnzYhrtXE for ; Wed, 7 Mar 2012 02:49:24 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7105B21F86C2 for ; Wed, 7 Mar 2012 02:49:24 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-07-4f573d33bef8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CE.F0.27041.33D375F4; Wed, 7 Mar 2012 11:49:23 +0100 (CET) Received: from [159.107.24.251] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Mar 2012 11:49:22 +0100 Message-ID: <4F573D31.2060304@ericsson.com> Date: Wed, 7 Mar 2012 11:49:21 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> <4F566A1C.3040406@alum.mit.edu> In-Reply-To: <4F566A1C.3040406@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Wed, 07 Mar 2012 10:49:25 -0000 Hi Paul: Thanks for your comments, see inline answers. On 06/03/2012 20:48, Paul Kyzivat wrote: > On 3/6/12 4:34 AM, Simo.Veikkolainen@nokia.com wrote: >> We have submitted a new version (-10) of Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN), which can be found at http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt >> >> Changes in this version include: >> - The port number in "m=" line SHOULD be set to "9" (the discard port) but it MUST be ignored at reception >> - Clarified that the Discriminator byte is included in the cs-correlation:uuie attribute, but we don't specify a value for the Discriminator byte > > I know this has been discussed before, but it still bothers me: > > Is there a reason why the representation of this UUIE is so different > from the representation used in draft-ietf-cuss-sip-uui-isdn-02? > These things are talking about conveying the same thing in the same > manner. IMO it would be much better to be consistent about this. Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User SIP header field, whereas this draft uses a "cs-correlation" attribute in SDP? If this is the case, I guess there is a justification. The cuss draft comes from an angle of making visible in SIP the UUIE in ISDN, irrespective of their contents. The goal is to improve interoperability between SIP and ISDN. The CS descriptions drafts needs a correlation mechanism between two objects (a CS call and a RTP stream). It offers three mechanisms, of which, one happens to be the UUIE. These mechanisms are described in an SDP attribute. They are specific for the purpose of correlating two media streams. I think both mechanisms serve different purposes, and the only commonality between them is that it happens to be transporting the same information. I would not like to see, e.g., that the CS drafts uses two correlation mechanisms defined in SDP, and a third one in a SIP header. I don't see the point. I don't see any problem in leaving them as they are. > > Is it because implementations of this draft have already been deployed? I am not aware of an implementation of the CS descriptions draft, so this should not be a problem. > >> - Added a new example with audio and video streams > > While its good to seen the new example, as shown it has missed the main > issue that will arise, because it only shows the situation when one of > the proposed streams is rejected. > > If both streams are to be accepted, are they to result in one pstn phone > call, or two? I would think the intent would be to have only one. But in > that case, how is it represented in SDP so that its known that only one > call is made? Is there an assumption that if one phone number is used > for multiple m-lines, then the same call should be used for both? The idea is to have a single PSTN phone call, with audio and video components. I haven't heard of requirements indicating other thing. So, I agree with you that perhaps we ought to describe that for video calls, a single PSTN phone call is made. Yes, we miss some text there, thanks for catching this up. /Miguel > > Thanks, > Paul > >> - Added a new section "Considerations for Usage of Third Party Call Control (3PCC)" which recommends the Controller to use "-" as the connection address (to be in line with 0.0.0.0 which is used for IPv4). >> - Added a new paragraph to security considerations on privacy concerns that arise from including the phone number in the SDP > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Mar 7 02:56:23 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 029A621F86F0 for ; Wed, 7 Mar 2012 02:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 q2BXAnh+mZeI for ; Wed, 7 Mar 2012 02:56:21 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90E21F8796 for ; Wed, 7 Mar 2012 02:56:21 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-ab-4f573ed47afb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CA.62.27041.4DE375F4; Wed, 7 Mar 2012 11:56:20 +0100 (CET) Received: from [159.107.24.251] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Wed, 7 Mar 2012 11:56:19 +0100 Message-ID: <4F573ED3.2030409@ericsson.com> Date: Wed, 7 Mar 2012 11:56:19 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bert Greevenbosch References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 10:56:23 -0000 Bert, Here is another document with the same purpose. You can use it for inspiration. This is a bit more complex document, because it has to deal with several different protocols, rather than only one. http://tools.ietf.org/html/draft-ietf-opsawg-management-stds The other document that you need to consult is the IANA SDP Parameters registry at: http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml This contains a list of all the SDP extensions, and they all should be listed in the hitchhiker's guide. /Miguel On 07/03/2012 3:54, Bert Greevenbosch wrote: > Hi all, > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied most initial text from there, and in addition included an initial list of RFCs / drafts that seem relevant. > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ > > If the group is happy with this approach, I will be happy to maintain an editor's role, and write more text. Obviously other people's input will be highly appreciated, and indeed is needed. > > I look forward to your comments. > > Best regards, > Bert > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the draft. How to deal with this? > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 27 February 2012 04:53 > To: Gonzalo Camarillo; Mary Barnes > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > Hi, > > As a directorate member, I am willing to co-author such draft, should a decision to write one be taken. > > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 23. helmikuuta 2012 19:31 > To: Mary Barnes > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > I agree. > > Gonzalo > > On 23/02/2012 7:06 PM, Mary Barnes wrote: >> I would think that in order for the document to have integrity that at >> least one of the directorate members should at least be a co-author. >> Otherwise, I see a lot more stuff falling through the cracks and >> needing to be resolved during WGLC and later, which usually isn't a >> good thing. The SIP Hitchhiker's guide provides a good example in >> that the author was also a primary contributor to RFC3261, etc. >> >> Mary. >> >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >> > > >> wrote: >> >> Hi Mary, >> >> yes, the members of the SDP directorate would need to review such a >> guide. However, the fact that they agreed to be members of the >> directorate does not mean they will necessarily have cycles to >> significantly contribute to the creation of the guide. We need to make >> sure we have enough energy around this effort in order to start it. >> >> Cheers, >> >> Gonzalo >> >> On 15/02/2012 7:14 PM, Mary Barnes wrote: >> > I think this is a good idea. I would think the experts that can >> > contribute (and should review) can be found in the new SDP >> > directorate: >> > http://www.ietf.org/iesg/directorate/sdp.html >> > BTW, it would be nice to have a link to this page on the MMUSIC WG >> wiki: >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >> > >> > As far as whether to publish, I think it would be a good idea to >> > complete publication as IMHO that improves the integrity of the >> > information - i.e., more eyes review a published RFC than a draft. >> > It could later be updated to reflect more recent RFCs OR a "More of >> > Hitchhikers Guide" could be published. >> > >> > Thanks, >> > Mary. >> > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >> > > > wrote: >> >> Hi Miguel, Andrew, all, >> >> >> >> Sounds like a good idea. I would be happy to volunteer to play a >> central role in it (i.e. be the editor, create the initial draft, >> ...), but I would need support from other experts too. >> >> >> >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" >> has become an RFC (5411). That means that it has been frozen, and to >> add new info new individual or WG drafts are needed. >> >> >> >> Would this be the same approach for SDP? Currently, there are >> already quite some new drafts that extend SDP. How will future >> extensions be handled? Maybe it would be good to make it a permanent >> WG draft, which is updated every now and then. >> >> >> >> Best regards, >> >> Bert >> >> >> >> >> >> -----Original Message----- >> >> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Miguel A. Garcia >> >> Sent: 14 February 2012 15:42 >> >> To: Andrew Allen >> >> Cc: mmusic@ietf.org >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >> >> >> >> Sounds good to me too. If someone wants to start such draft... >> >> >> >> /Miguel >> >> >> >> On 13/02/2012 23:15, Andrew Allen wrote: >> >>> >> >>> What about considering a hitchhikers guide to SDP similar to >> what was done for SIP? >> >>> >> >>> One umbrella document that points the reader to all the SDP >> capabilities available that they might want to take advantage of. >> >>> >> >>> Just a suggestion. >> >>> >> >>> Andrew >> >>> >> >>> ----- Original Message ----- >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com >> ] >> >>> Sent: Saturday, January 28, 2012 06:23 AM >> >>> To: mmusic> >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >> >>> >> >>> >> >>> >> >>> Hi all, >> >>> >> >>> You know we are revising RFC 4566. So far, the effort has been >> in bug fixing. >> >>> >> >>> The first SDP version was published as RFC 2327 in 1998 (i.e., >> 14 years >> >>> ago), and was then revised as RFC 4566 in 2006. >> >>> >> >>> Lots of things have happened since then. We have SDP offer answer, >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. >> >>> >> >>> From the point of view of a reader who takes 4566 (or its current >> >>> 4566bis incarnation), I think it will be difficult for her or him to >> >>> understand a protocol that ignores those other extensions. For >> example, I >> >>> recently post another e-mail where there is an apparent >> contradiction >> >>> between 4566 and ICE (see >> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >> >>> >> >>> So, I was wondering if time has come to make not a bug correction in >> >>> 4566bis, but also put that RFC in context with the other >> extensions that >> >>> exist. This may include: >> >>> >> >>> - Add minor extensions to the core document, similarly to what >> we did >> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which >> of these >> >>> extensions make sense to include, this would be an exercise to >> do, but >> >>> let me give you one potential example: RFC 4574, the SDP "label" >> >>> attribute is a 6 pages RFC. >> >>> >> >>> - Adding references to extensions, when it makes sense. For >> example, ICE >> >>> should be referred somewhere (see my previous post regarding the "o" >> >>> line). I guess capneg could be also mentioned, perhaps others. >> >>> >> >>> I know this is a bigger effort than anticipated, but the result >> could >> >>> really help newcomers to this world. >> >>> >> >>> Now, it is your turn to express your opinions. Please do it. >> >>> >> >>> /Miguel >> >> >> >> -- >> >> Miguel A. Garcia >> >> +34-91-339-3608 >> >> Ericsson Spain >> >> _______________________________________________ >> >> 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 >> > _______________________________________________ >> > 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 > _______________________________________________ > 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 > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From wwwrun@rfc-editor.org Wed Mar 7 04:40:21 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 2B6E521F852D for ; Wed, 7 Mar 2012 04:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001, 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 kLGlyDESIJud for ; Wed, 7 Mar 2012 04:40:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7821F86B8 for ; Wed, 7 Mar 2012 04:40:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0AFC962179; Wed, 7 Mar 2012 04:40:12 -0800 (PST) To: jdrosen@jdrosen.net, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, fandreas@cisco.com, miguel.a.garcia@ericsson.com From: RFC Errata System Message-Id: <20120307124012.0AFC962179@rfc-editor.org> Date: Wed, 7 Mar 2012 04:40:12 -0800 (PST) Cc: petithug@acm.org, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Editorial Errata Reported] RFC5245 (3149) 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, 07 Mar 2012 12:40:21 -0000 The following errata report has been submitted for RFC5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3149 -------------------------------------- Type: Editorial Reported by: Marc Petit-huguenin Section: 21.1.4 Original Text ------------- Type of Attribute: session-level Corrected Text -------------- Type of Attribute: media-level Notes ----- Section 15.3 clearly says that "ice-mismatch" is media-level: '"ice-mismatch" is a media-level attribute only, and when present in an answer, indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute.' Section Section 6.1 also implies that "ice-mismatch" is media-level: "In some cases, the answer may omit a=candidate attributes for the media streams, and instead include an a=ice-mismatch attribute for one or more of the media streams in the SDP." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5245 (draft-ietf-mmusic-ice-19) -------------------------------------- Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Publication Date : April 2010 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From keith.drage@alcatel-lucent.com Wed Mar 7 06:25:08 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 60CE821F860E for ; Wed, 7 Mar 2012 06:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.456 X-Spam-Level: X-Spam-Status: No, score=-107.456 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, HELO_EQ_FR=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 JJoXrV5V9oUA for ; Wed, 7 Mar 2012 06:25:07 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id E2C1221F85DB for ; Wed, 7 Mar 2012 06:25:06 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q27EOca0027383 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 15:24:50 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 7 Mar 2012 15:24:42 +0100 From: "DRAGE, Keith (Keith)" To: "Miguel A. Garcia" , Bert Greevenbosch Date: Wed, 7 Mar 2012 15:24:41 +0100 Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP Thread-Index: Acz8UPhLdtyhqIOBRNq1QBXclwrtWAAHMlYw Message-ID: References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> In-Reply-To: <4F573ED3.2030409@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 14:25:08 -0000 I notice RFC 3264 is mentioned as one of the core specifications. This only becomes core when SDP is used in the context of SIP. If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a d= ifferent viewpoint of what is core and what is not. We may need to address these different viewpoints, unless you want to make = a guide that is entirely focused on SIP usage. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 07 March 2012 10:56 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >=20 > Bert, >=20 > Here is another document with the same purpose. You can use it for > inspiration. This is a bit more complex document, because it has to deal > with several different protocols, rather than only one. >=20 > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >=20 > The other document that you need to consult is the IANA SDP Parameters > registry at: >=20 > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >=20 > This contains a list of all the SDP extensions, and they all should be > listed in the hitchhiker's guide. >=20 > /Miguel >=20 > On 07/03/2012 3:54, Bert Greevenbosch wrote: > > Hi all, > > > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied > most initial text from there, and in addition included an initial list of > RFCs / drafts that seem relevant. > > > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > sdp/ > > > > If the group is happy with this approach, I will be happy to maintain a= n > editor's role, and write more text. Obviously other people's input will b= e > highly appreciated, and indeed is needed. > > > > I look forward to your comments. > > > > Best regards, > > Bert > > > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the > draft. How to deal with this? > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > Of Christer Holmberg > > Sent: 27 February 2012 04:53 > > To: Gonzalo Camarillo; Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > Hi, > > > > As a directorate member, I am willing to co-author such draft, should a > decision to write one be taken. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > Of Gonzalo Camarillo > > Sent: 23. helmikuuta 2012 19:31 > > To: Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > I agree. > > > > Gonzalo > > > > On 23/02/2012 7:06 PM, Mary Barnes wrote: > >> I would think that in order for the document to have integrity that at > >> least one of the directorate members should at least be a co-author. > >> Otherwise, I see a lot more stuff falling through the cracks and > >> needing to be resolved during WGLC and later, which usually isn't a > >> good thing. The SIP Hitchhiker's guide provides a good example in > >> that the author was also a primary contributor to RFC3261, etc. > >> > >> Mary. > >> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > >> >> > > >> wrote: > >> > >> Hi Mary, > >> > >> yes, the members of the SDP directorate would need to review such > a > >> guide. However, the fact that they agreed to be members of the > >> directorate does not mean they will necessarily have cycles to > >> significantly contribute to the creation of the guide. We need to > make > >> sure we have enough energy around this effort in order to start > it. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: > >> > I think this is a good idea. I would think the experts that > can > >> > contribute (and should review) can be found in the new SDP > >> > directorate: > >> > http://www.ietf.org/iesg/directorate/sdp.html > >> > BTW, it would be nice to have a link to this page on the MMUSI= C > WG > >> wiki: > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > >> > > >> > As far as whether to publish, I think it would be a good idea > to > >> > complete publication as IMHO that improves the integrity of th= e > >> > information - i.e., more eyes review a published RFC than a > draft. > >> > It could later be updated to reflect more recent RFCs OR a > "More of > >> > Hitchhikers Guide" could be published. > >> > > >> > Thanks, > >> > Mary. > >> > > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > >> > >> > wrote: > >> >> Hi Miguel, Andrew, all, > >> >> > >> >> Sounds like a good idea. I would be happy to volunteer to pla= y > a > >> central role in it (i.e. be the editor, create the initial draft, > >> ...), but I would need support from other experts too. > >> >> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to > SIP" > >> has become an RFC (5411). That means that it has been frozen, and > to > >> add new info new individual or WG drafts are needed. > >> >> > >> >> Would this be the same approach for SDP? Currently, there are > >> already quite some new drafts that extend SDP. How will future > >> extensions be handled? Maybe it would be good to make it a > permanent > >> WG draft, which is updated every now and then. > >> >> > >> >> Best regards, > >> >> Bert > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: mmusic-bounces@ietf.org > >> [mailto:mmusic-bounces@ietf.org] > On > >> Behalf Of Miguel A. Garcia > >> >> Sent: 14 February 2012 15:42 > >> >> To: Andrew Allen > >> >> Cc: mmusic@ietf.org > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> >> > >> >> Sounds good to me too. If someone wants to start such draft..= . > >> >> > >> >> /Miguel > >> >> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: > >> >>> > >> >>> What about considering a hitchhikers guide to SDP similar to > >> what was done for SIP? > >> >>> > >> >>> One umbrella document that points the reader to all the SDP > >> capabilities available that they might want to take advantage of. > >> >>> > >> >>> Just a suggestion. > >> >>> > >> >>> Andrew > >> >>> > >> >>> ----- Original Message ----- > >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com > >> ] > >> >>> Sent: Saturday, January 28, 2012 06:23 AM > >> >>> To: mmusic> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >> >>> > >> >>> > >> >>> > >> >>> Hi all, > >> >>> > >> >>> You know we are revising RFC 4566. So far, the effort has > been > >> in bug fixing. > >> >>> > >> >>> The first SDP version was published as RFC 2327 in 1998 > (i.e., > >> 14 years > >> >>> ago), and was then revised as RFC 4566 in 2006. > >> >>> > >> >>> Lots of things have happened since then. We have SDP offer > answer, > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, > comeida, > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in > the pipe. > >> >>> > >> >>> From the point of view of a reader who takes 4566 (or its > current > >> >>> 4566bis incarnation), I think it will be difficult for her o= r > him to > >> >>> understand a protocol that ignores those other extensions. > For > >> example, I > >> >>> recently post another e-mail where there is an apparent > >> contradiction > >> >>> between 4566 and ICE (see > >> >>> http://www.ietf.org/mail- > archive/web/mmusic/current/msg09089.html ). > >> >>> > >> >>> So, I was wondering if time has come to make not a bug > correction in > >> >>> 4566bis, but also put that RFC in context with the other > >> extensions that > >> >>> exist. This may include: > >> >>> > >> >>> - Add minor extensions to the core document, similarly to > what > >> we did > >> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know > which > >> of these > >> >>> extensions make sense to include, this would be an exercise > to > >> do, but > >> >>> let me give you one potential example: RFC 4574, the SDP > "label" > >> >>> attribute is a 6 pages RFC. > >> >>> > >> >>> - Adding references to extensions, when it makes sense. For > >> example, ICE > >> >>> should be referred somewhere (see my previous post regarding > the "o" > >> >>> line). I guess capneg could be also mentioned, perhaps > others. > >> >>> > >> >>> I know this is a bigger effort than anticipated, but the > result > >> could > >> >>> really help newcomers to this world. > >> >>> > >> >>> Now, it is your turn to express your opinions. Please do it. > >> >>> > >> >>> /Miguel > >> >> > >> >> -- > >> >> Miguel A. Garcia > >> >> +34-91-339-3608 > >> >> Ericsson Spain > >> >> _______________________________________________ > >> >> 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 > >> > _______________________________________________ > >> > 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 > > _______________________________________________ > > 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 > > >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From albrecht.schwarz@alcatel-lucent.com Wed Mar 7 06:59: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 629F921F84EB; Wed, 7 Mar 2012 06:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.17 X-Spam-Level: X-Spam-Status: No, score=-7.17 tagged_above=-999 required=5 tests=[AWL=3.079, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Lrqs3Mab1nMk; Wed, 7 Mar 2012 06:59:49 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CD4D221F8564; Wed, 7 Mar 2012 06:59:48 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q27EuvK9000658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 15:59:11 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 7 Mar 2012 15:58:59 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "DRAGE, Keith (Keith)" , "Miguel A. Garcia" , Bert Greevenbosch Date: Wed, 7 Mar 2012 15:58:58 +0100 Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP Thread-Index: Acz8UPhLdtyhqIOBRNq1QBXclwrtWAAHMlYwAADkzhA= Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9621626AD30B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "megaco@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 14:59:50 -0000 > If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a= different viewpoint of what is core and what is not. Good point. The Megaco/H.248 hitchhiker's guide to SDP should include at least, e.g.: 1) ITU-T H.248.1 Version 3 Amendment 2: "Summary - H.248 usage of SDP" 2) ITU-T H.248.15: "SDP H.248 package attribute" 3) ITU-T H.248.39: "H.248 SDP parameter identification and wildcarding" 4) ITU-T H.248.49: "Session description protocol RFC and capabilities packa= ges" 5) ITU-T H.248.80: "Usage of the revised SDP offer / answer model with H.24= 8" (Draft) 6) ETSI 183 046: "SDP Interworking between Call/Session Control Protocols (= SIP/SDP, RTSP/SDP; etc.) and the Gateway Control Protocol (H.248/SDP)" Such an "Megaco/H.248 hitchhiker's guide to SDP" should be incorporated in = an "Hitchhiker's guide to SDP" in my opinion. Regards Albrecht -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: Mittwoch, 7. M=E4rz 2012 15:25 To: Miguel A. Garcia; Bert Greevenbosch Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP I notice RFC 3264 is mentioned as one of the core specifications. This only becomes core when SDP is used in the context of SIP. If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a d= ifferent viewpoint of what is core and what is not. We may need to address these different viewpoints, unless you want to make = a guide that is entirely focused on SIP usage. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 07 March 2012 10:56 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >=20 > Bert, >=20 > Here is another document with the same purpose. You can use it for > inspiration. This is a bit more complex document, because it has to deal > with several different protocols, rather than only one. >=20 > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >=20 > The other document that you need to consult is the IANA SDP Parameters > registry at: >=20 > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >=20 > This contains a list of all the SDP extensions, and they all should be > listed in the hitchhiker's guide. >=20 > /Miguel >=20 > On 07/03/2012 3:54, Bert Greevenbosch wrote: > > Hi all, > > > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied > most initial text from there, and in addition included an initial list of > RFCs / drafts that seem relevant. > > > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > sdp/ > > > > If the group is happy with this approach, I will be happy to maintain a= n > editor's role, and write more text. Obviously other people's input will b= e > highly appreciated, and indeed is needed. > > > > I look forward to your comments. > > > > Best regards, > > Bert > > > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the > draft. How to deal with this? > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > Of Christer Holmberg > > Sent: 27 February 2012 04:53 > > To: Gonzalo Camarillo; Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > Hi, > > > > As a directorate member, I am willing to co-author such draft, should a > decision to write one be taken. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f > Of Gonzalo Camarillo > > Sent: 23. helmikuuta 2012 19:31 > > To: Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > I agree. > > > > Gonzalo > > > > On 23/02/2012 7:06 PM, Mary Barnes wrote: > >> I would think that in order for the document to have integrity that at > >> least one of the directorate members should at least be a co-author. > >> Otherwise, I see a lot more stuff falling through the cracks and > >> needing to be resolved during WGLC and later, which usually isn't a > >> good thing. The SIP Hitchhiker's guide provides a good example in > >> that the author was also a primary contributor to RFC3261, etc. > >> > >> Mary. > >> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > >> >> > > >> wrote: > >> > >> Hi Mary, > >> > >> yes, the members of the SDP directorate would need to review such > a > >> guide. However, the fact that they agreed to be members of the > >> directorate does not mean they will necessarily have cycles to > >> significantly contribute to the creation of the guide. We need to > make > >> sure we have enough energy around this effort in order to start > it. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: > >> > I think this is a good idea. I would think the experts that > can > >> > contribute (and should review) can be found in the new SDP > >> > directorate: > >> > http://www.ietf.org/iesg/directorate/sdp.html > >> > BTW, it would be nice to have a link to this page on the MMUSI= C > WG > >> wiki: > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > >> > > >> > As far as whether to publish, I think it would be a good idea > to > >> > complete publication as IMHO that improves the integrity of th= e > >> > information - i.e., more eyes review a published RFC than a > draft. > >> > It could later be updated to reflect more recent RFCs OR a > "More of > >> > Hitchhikers Guide" could be published. > >> > > >> > Thanks, > >> > Mary. > >> > > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > >> > >> > wrote: > >> >> Hi Miguel, Andrew, all, > >> >> > >> >> Sounds like a good idea. I would be happy to volunteer to pla= y > a > >> central role in it (i.e. be the editor, create the initial draft, > >> ...), but I would need support from other experts too. > >> >> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to > SIP" > >> has become an RFC (5411). That means that it has been frozen, and > to > >> add new info new individual or WG drafts are needed. > >> >> > >> >> Would this be the same approach for SDP? Currently, there are > >> already quite some new drafts that extend SDP. How will future > >> extensions be handled? Maybe it would be good to make it a > permanent > >> WG draft, which is updated every now and then. > >> >> > >> >> Best regards, > >> >> Bert > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: mmusic-bounces@ietf.org > >> [mailto:mmusic-bounces@ietf.org] > On > >> Behalf Of Miguel A. Garcia > >> >> Sent: 14 February 2012 15:42 > >> >> To: Andrew Allen > >> >> Cc: mmusic@ietf.org > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> >> > >> >> Sounds good to me too. If someone wants to start such draft..= . > >> >> > >> >> /Miguel > >> >> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: > >> >>> > >> >>> What about considering a hitchhikers guide to SDP similar to > >> what was done for SIP? > >> >>> > >> >>> One umbrella document that points the reader to all the SDP > >> capabilities available that they might want to take advantage of. > >> >>> > >> >>> Just a suggestion. > >> >>> > >> >>> Andrew > >> >>> > >> >>> ----- Original Message ----- > >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com > >> ] > >> >>> Sent: Saturday, January 28, 2012 06:23 AM > >> >>> To: mmusic> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >> >>> > >> >>> > >> >>> > >> >>> Hi all, > >> >>> > >> >>> You know we are revising RFC 4566. So far, the effort has > been > >> in bug fixing. > >> >>> > >> >>> The first SDP version was published as RFC 2327 in 1998 > (i.e., > >> 14 years > >> >>> ago), and was then revised as RFC 4566 in 2006. > >> >>> > >> >>> Lots of things have happened since then. We have SDP offer > answer, > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, > comeida, > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in > the pipe. > >> >>> > >> >>> From the point of view of a reader who takes 4566 (or its > current > >> >>> 4566bis incarnation), I think it will be difficult for her o= r > him to > >> >>> understand a protocol that ignores those other extensions. > For > >> example, I > >> >>> recently post another e-mail where there is an apparent > >> contradiction > >> >>> between 4566 and ICE (see > >> >>> http://www.ietf.org/mail- > archive/web/mmusic/current/msg09089.html ). > >> >>> > >> >>> So, I was wondering if time has come to make not a bug > correction in > >> >>> 4566bis, but also put that RFC in context with the other > >> extensions that > >> >>> exist. This may include: > >> >>> > >> >>> - Add minor extensions to the core document, similarly to > what > >> we did > >> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know > which > >> of these > >> >>> extensions make sense to include, this would be an exercise > to > >> do, but > >> >>> let me give you one potential example: RFC 4574, the SDP > "label" > >> >>> attribute is a 6 pages RFC. > >> >>> > >> >>> - Adding references to extensions, when it makes sense. For > >> example, ICE > >> >>> should be referred somewhere (see my previous post regarding > the "o" > >> >>> line). I guess capneg could be also mentioned, perhaps > others. > >> >>> > >> >>> I know this is a bigger effort than anticipated, but the > result > >> could > >> >>> really help newcomers to this world. > >> >>> > >> >>> Now, it is your turn to express your opinions. Please do it. > >> >>> > >> >>> /Miguel > >> >> > >> >> -- > >> >> Miguel A. Garcia > >> >> +34-91-339-3608 > >> >> Ericsson Spain > >> >> _______________________________________________ > >> >> 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 > >> > _______________________________________________ > >> > 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 > > _______________________________________________ > > 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 > > >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > 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 mary.ietf.barnes@gmail.com Wed Mar 7 07:03:08 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 32BF821F85AA for ; Wed, 7 Mar 2012 07:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 2uS8Wy-bDFB0 for ; Wed, 7 Mar 2012 07:03:06 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7921E8035 for ; Wed, 7 Mar 2012 07:03:05 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so6328920vcb.31 for ; Wed, 07 Mar 2012 07:03:05 -0800 (PST) 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; bh=R1spXouljxAwVkvc6fdQgN3nDoKKfpSBW+uTIERG2jg=; b=eWsg9gPlRLwMxVYdd8TmBpPiJ+HOG1yr7rbkzyvL9i9c6Wq02WLdDLzCtSGCD65Beg wjp7R0EeLB94F8Z2+hmxzi17uQ2JyZfvDW5qLukzX6yIrMWAs/gKLSTJyK4GpVNi0Xt1 Fe8LGF/k2yWurlKD8ODCFO4YV4hbpkeLHmv4X0+I3SbRabMbR6q2wK7iu1M2sYRwuZfv 5Jwh7PZp7cfbqM3X8s/TKKc9E2K025LAnqG2PAkSFLokVXOi8xS/2oD31vRHUnuIup1O nIinurGTy2erbr/Wb+2fOVVu+3BbG4tn6RLs2W8yW5qHHbXf1j1x2PDsYzm76ltMHp0M zE2Q== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr3553024vdh.38.1331132584788; Wed, 07 Mar 2012 07:03:04 -0800 (PST) Received: by 10.52.111.136 with HTTP; Wed, 7 Mar 2012 07:03:04 -0800 (PST) In-Reply-To: References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> Date: Wed, 7 Mar 2012 09:03:04 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf3079bc9edd82a604baa874dc Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 15:03:08 -0000 --20cf3079bc9edd82a604baa874dc Content-Type: text/plain; charset=ISO-8859-1 Per Albrecht response, I think we would open a can of worms if we want this to be a general guide on SDP for all usages. I would prefer to keep it limited to SIP at this time, which I think is no small task. Then another document, modeled after this one, could cover other usages if the interested parties think it would be helpful. Mary. On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I notice RFC 3264 is mentioned as one of the core specifications. > > This only becomes core when SDP is used in the context of SIP. > > If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a > different viewpoint of what is core and what is not. > > We may need to address these different viewpoints, unless you want to make > a guide that is entirely focused on SIP usage. > > Regards > > Keith > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > > Of Miguel A. Garcia > > Sent: 07 March 2012 10:56 > > To: Bert Greevenbosch > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > Bert, > > > > Here is another document with the same purpose. You can use it for > > inspiration. This is a bit more complex document, because it has to deal > > with several different protocols, rather than only one. > > > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > > > The other document that you need to consult is the IANA SDP Parameters > > registry at: > > > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > > > This contains a list of all the SDP extensions, and they all should be > > listed in the hitchhiker's guide. > > > > /Miguel > > > > On 07/03/2012 3:54, Bert Greevenbosch wrote: > > > Hi all, > > > > > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". > > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied > > most initial text from there, and in addition included an initial list of > > RFCs / drafts that seem relevant. > > > > > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > > sdp/ > > > > > > If the group is happy with this approach, I will be happy to maintain > an > > editor's role, and write more text. Obviously other people's input will > be > > highly appreciated, and indeed is needed. > > > > > > I look forward to your comments. > > > > > > Best regards, > > > Bert > > > > > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the > > draft. How to deal with this? > > > > > > > > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf > > Of Christer Holmberg > > > Sent: 27 February 2012 04:53 > > > To: Gonzalo Camarillo; Mary Barnes > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > > > > Hi, > > > > > > As a directorate member, I am willing to co-author such draft, should a > > decision to write one be taken. > > > > > > Regards, > > > > > > Christer > > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf > > Of Gonzalo Camarillo > > > Sent: 23. helmikuuta 2012 19:31 > > > To: Mary Barnes > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > I agree. > > > > > > Gonzalo > > > > > > On 23/02/2012 7:06 PM, Mary Barnes wrote: > > >> I would think that in order for the document to have integrity that at > > >> least one of the directorate members should at least be a co-author. > > >> Otherwise, I see a lot more stuff falling through the cracks and > > >> needing to be resolved during WGLC and later, which usually isn't a > > >> good thing. The SIP Hitchhiker's guide provides a good example in > > >> that the author was also a primary contributor to RFC3261, etc. > > >> > > >> Mary. > > >> > > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > > >> > >> > > > >> wrote: > > >> > > >> Hi Mary, > > >> > > >> yes, the members of the SDP directorate would need to review such > > a > > >> guide. However, the fact that they agreed to be members of the > > >> directorate does not mean they will necessarily have cycles to > > >> significantly contribute to the creation of the guide. We need to > > make > > >> sure we have enough energy around this effort in order to start > > it. > > >> > > >> Cheers, > > >> > > >> Gonzalo > > >> > > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: > > >> > I think this is a good idea. I would think the experts that > > can > > >> > contribute (and should review) can be found in the new SDP > > >> > directorate: > > >> > http://www.ietf.org/iesg/directorate/sdp.html > > >> > BTW, it would be nice to have a link to this page on the > MMUSIC > > WG > > >> wiki: > > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > >> > > > >> > As far as whether to publish, I think it would be a good idea > > to > > >> > complete publication as IMHO that improves the integrity of > the > > >> > information - i.e., more eyes review a published RFC than a > > draft. > > >> > It could later be updated to reflect more recent RFCs OR a > > "More of > > >> > Hitchhikers Guide" could be published. > > >> > > > >> > Thanks, > > >> > Mary. > > >> > > > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > > >> > > >> > wrote: > > >> >> Hi Miguel, Andrew, all, > > >> >> > > >> >> Sounds like a good idea. I would be happy to volunteer to > play > > a > > >> central role in it (i.e. be the editor, create the initial draft, > > >> ...), but I would need support from other experts too. > > >> >> > > >> >> As for practicalities, I see that the "Hitchhiker's Guide to > > SIP" > > >> has become an RFC (5411). That means that it has been frozen, and > > to > > >> add new info new individual or WG drafts are needed. > > >> >> > > >> >> Would this be the same approach for SDP? Currently, there are > > >> already quite some new drafts that extend SDP. How will future > > >> extensions be handled? Maybe it would be good to make it a > > permanent > > >> WG draft, which is updated every now and then. > > >> >> > > >> >> Best regards, > > >> >> Bert > > >> >> > > >> >> > > >> >> -----Original Message----- > > >> >> From: mmusic-bounces@ietf.org > > > >> [mailto:mmusic-bounces@ietf.org] > > On > > >> Behalf Of Miguel A. Garcia > > >> >> Sent: 14 February 2012 15:42 > > >> >> To: Andrew Allen > > >> >> Cc: mmusic@ietf.org > > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > > >> >> > > >> >> Sounds good to me too. If someone wants to start such > draft... > > >> >> > > >> >> /Miguel > > >> >> > > >> >> On 13/02/2012 23:15, Andrew Allen wrote: > > >> >>> > > >> >>> What about considering a hitchhikers guide to SDP similar to > > >> what was done for SIP? > > >> >>> > > >> >>> One umbrella document that points the reader to all the SDP > > >> capabilities available that they might want to take advantage of. > > >> >>> > > >> >>> Just a suggestion. > > >> >>> > > >> >>> Andrew > > >> >>> > > >> >>> ----- Original Message ----- > > >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com > > >> ] > > >> >>> Sent: Saturday, January 28, 2012 06:23 AM > > >> >>> To: mmusic> > > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > > >> >>> > > >> >>> > > >> >>> > > >> >>> Hi all, > > >> >>> > > >> >>> You know we are revising RFC 4566. So far, the effort has > > been > > >> in bug fixing. > > >> >>> > > >> >>> The first SDP version was published as RFC 2327 in 1998 > > (i.e., > > >> 14 years > > >> >>> ago), and was then revised as RFC 4566 in 2006. > > >> >>> > > >> >>> Lots of things have happened since then. We have SDP offer > > answer, > > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, > > comeida, > > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in > > the pipe. > > >> >>> > > >> >>> From the point of view of a reader who takes 4566 (or its > > current > > >> >>> 4566bis incarnation), I think it will be difficult for her > or > > him to > > >> >>> understand a protocol that ignores those other extensions. > > For > > >> example, I > > >> >>> recently post another e-mail where there is an apparent > > >> contradiction > > >> >>> between 4566 and ICE (see > > >> >>> http://www.ietf.org/mail- > > archive/web/mmusic/current/msg09089.html ). > > >> >>> > > >> >>> So, I was wondering if time has come to make not a bug > > correction in > > >> >>> 4566bis, but also put that RFC in context with the other > > >> extensions that > > >> >>> exist. This may include: > > >> >>> > > >> >>> - Add minor extensions to the core document, similarly to > > what > > >> we did > > >> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know > > which > > >> of these > > >> >>> extensions make sense to include, this would be an exercise > > to > > >> do, but > > >> >>> let me give you one potential example: RFC 4574, the SDP > > "label" > > >> >>> attribute is a 6 pages RFC. > > >> >>> > > >> >>> - Adding references to extensions, when it makes sense. For > > >> example, ICE > > >> >>> should be referred somewhere (see my previous post regarding > > the "o" > > >> >>> line). I guess capneg could be also mentioned, perhaps > > others. > > >> >>> > > >> >>> I know this is a bigger effort than anticipated, but the > > result > > >> could > > >> >>> really help newcomers to this world. > > >> >>> > > >> >>> Now, it is your turn to express your opinions. Please do it. > > >> >>> > > >> >>> /Miguel > > >> >> > > >> >> -- > > >> >> Miguel A. Garcia > > >> >> +34-91-339-3608 > > >> >> Ericsson Spain > > >> >> _______________________________________________ > > >> >> 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 > > >> > _______________________________________________ > > >> > 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 > > > _______________________________________________ > > > 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 > > > > > > > -- > > Miguel A. Garcia > > +34-91-339-3608 > > Ericsson Spain > > _______________________________________________ > > 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 > --20cf3079bc9edd82a604baa874dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per Albrecht response, I think we would open a can of worms if we want this= to be a general guide on SDP for all usages. =A0I would prefer to keep it = limited to SIP at this time, which I think is no small task. Then another d= ocument, modeled after this one, =A0could cover other usages if the interes= ted parties think it would be helpful.=A0

Mary.=A0

On Wed, Mar 7, 20= 12 at 8:24 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
I notice RFC 3264 is mentioned as one of the= core specifications.

This only becomes core when SDP is used in the context of SIP.

If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a d= ifferent viewpoint of what is core and what is not.

We may need to address these different viewpoints, unless you want to make = a guide that is entirely focused on SIP usage.

Regards

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On Behalf
> Of Miguel A. Garcia
> Sent: 07 March 2012 10:56
> To: Bert Greevenbosch
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
>
> Bert,
>
> Here is another document with the same purpose. You can use it for
> inspiration. This is a bit more complex document, because it has to de= al
> with several different protocols, rather than only one.
>
> http://tools.ietf.org/html/draft-ietf-opsawg-managemen= t-stds
>
> The other document that you need to consult is the IANA SDP Parameters=
> registry at:
>
> http://www.iana.org/assignments/sdp-parameters/sd= p-parameters.xml
>
> This contains a list of all the SDP extensions, and they all should be=
> listed in the hitchhiker's guide.
>
> /Miguel
>
> On 07/03/2012 3:54, Bert Greevenbosch wrote:
> > Hi all,
> >
> > On Monday, I have uploaded a v00 draft for "Hitchhiker's= Guide to SDP".
> It is based on the "Hitchhiker's Guide to SIP" (RFC 5411= ). I have copied
> most initial text from there, and in addition included an initial list= of
> RFCs / drafts that seem relevant.
> >
> > https://datatracker.ietf.org/doc/draft-g= reevenbosch-hitchhikersguide-
> sdp/
> >
> > If the group is happy with this approach, I will be happy to main= tain an
> editor's role, and write more text. Obviously other people's i= nput will be
> highly appreciated, and indeed is needed.
> >
> > I look forward to your comments.
> >
> > Best regards,
> > Bert
> >
> > P.S. Unfortunately, I forgot to include "mmusic" in the= name of the
> draft. How to deal with this?
> >
> >
> >
> > -----Original Message-----
> > From: mmusic-bounces@i= etf.org [mailto:mmusic-bounc= es@ietf.org] On Behalf
> Of Christer Holmberg
> > Sent: 27 February 2012 04:53
> > To: Gonzalo Camarillo; Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> >
> > Hi,
> >
> > As a directorate member, I am willing to co-author such draft, sh= ould a
> decision to write one be taken.
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: mmusic-bounces@i= etf.org [mailto:mmusic-bounc= es@ietf.org] On Behalf
> Of Gonzalo Camarillo
> > Sent: 23. helmikuuta 2012 19:31
> > To: Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> > I agree.
> >
> > Gonzalo
> >
> > On 23/02/2012 7:06 PM, Mary Barnes wrote:
> >> I would think that in order for the document to have integrit= y that at
> >> least one of the directorate members should at least be a co-= author.
> >> =A0 Otherwise, I see a lot more stuff falling through the cra= cks and
> >> needing to be resolved during WGLC and later, which usually i= sn't a
> >> good thing. =A0The SIP Hitchhiker's guide provides a good= example in
> >> that the author was also a primary contributor to RFC3261, et= c.
> >>
> >> Mary.
> >>
> >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo
> >> <Gonzalo= .Camarillo@ericsson.com
> >> <mailto:= Gonzalo.Camarillo@ericsson.com>>
> >> wrote:
> >>
> >> =A0 =A0 =A0Hi Mary,
> >>
> >> =A0 =A0 =A0yes, the members of the SDP directorate would need= to review such
> a
> >> =A0 =A0 =A0guide. However, the fact that they agreed to be me= mbers of the
> >> =A0 =A0 =A0directorate does not mean they will necessarily ha= ve cycles to
> >> =A0 =A0 =A0significantly contribute to the creation of the gu= ide. We need to
> make
> >> =A0 =A0 =A0sure we have enough energy around this effort in o= rder to start
> it.
> >>
> >> =A0 =A0 =A0Cheers,
> >>
> >> =A0 =A0 =A0Gonzalo
> >>
> >> =A0 =A0 =A0On 15/02/2012 7:14 PM, Mary Barnes wrote:
> >> =A0 =A0 =A0> =A0I think this is a good idea. =A0I would th= ink the experts that
> can
> >> =A0 =A0 =A0> =A0contribute (and should review) can be foun= d in the new SDP
> >> =A0 =A0 =A0> =A0directorate:
> >> =A0 =A0 =A0> =A0http://www.ietf.org/iesg/directorate/sdp.= html
> >> =A0 =A0 =A0> =A0BTW, it would be nice to have a link to th= is page on the MMUSIC
> WG
> >> =A0 =A0 =A0wiki:
> >> =A0 =A0 =A0> =A0http://trac.tools.ietf.org/wg/mmusic/tra= c/wiki
> >> =A0 =A0 =A0>
> >> =A0 =A0 =A0> =A0As far as whether to publish, I think it w= ould be a good idea
> to
> >> =A0 =A0 =A0> =A0complete publication as IMHO that improves= the integrity of the
> >> =A0 =A0 =A0> =A0information - i.e., more eyes review a pub= lished RFC than a
> draft.
> >> =A0 =A0 =A0> =A0It could later be updated to reflect more = recent RFCs OR a
> "More of
> >> =A0 =A0 =A0> =A0Hitchhikers Guide" could be published= .
> >> =A0 =A0 =A0>
> >> =A0 =A0 =A0> =A0Thanks,
> >> =A0 =A0 =A0> =A0Mary.
> >> =A0 =A0 =A0>
> >> =A0 =A0 =A0> =A0On Wed, Feb 15, 2012 at 12:29 AM, Bert Gre= evenbosch
> >> =A0 =A0 =A0> =A0<Bert.Greevenbosch@huawei.com
> >> =A0 =A0 =A0<mailto:Bert.Greevenbosch@huawei.com>> =A0wrote:
> >> =A0 =A0 =A0>> =A0Hi Miguel, Andrew, all,
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0Sounds like a good idea. I would be ha= ppy to volunteer to play
> a
> >> =A0 =A0 =A0central role in it (i.e. be the editor, create the= initial draft,
> >> =A0 =A0 =A0...), but I would need support from other experts = too.
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0As for practicalities, I see that the = "Hitchhiker's Guide to
> SIP"
> >> =A0 =A0 =A0has become an RFC (5411). That means that it has b= een frozen, and
> to
> >> =A0 =A0 =A0add new info new individual or WG drafts are neede= d.
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0Would this be the same approach for SD= P? Currently, there are
> >> =A0 =A0 =A0already quite some new drafts that extend SDP. How= will future
> >> =A0 =A0 =A0extensions be handled? Maybe it would be good to m= ake it a
> permanent
> >> =A0 =A0 =A0WG draft, which is updated every now and then.
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0Best regards,
> >> =A0 =A0 =A0>> =A0Bert
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0-----Original Message-----
> >> =A0 =A0 =A0>> =A0From: mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>
> >> =A0 =A0 =A0[mailto:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>]
> On
> >> =A0 =A0 =A0Behalf Of Miguel A. Garcia
> >> =A0 =A0 =A0>> =A0Sent: 14 February 2012 15:42
> >> =A0 =A0 =A0>> =A0To: Andrew Allen
> >> =A0 =A0 =A0>> =A0Cc: mmusic@ietf.org<mailto:mmusic@ie= tf.org>
> >> =A0 =A0 =A0>> =A0Subject: Re: [MMUSIC] Do we need to up= date in time 4566bis?
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0Sounds good to me too. If someone want= s to start such draft...
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0/Miguel
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0On 13/02/2012 23:15, Andrew Allen wrot= e:
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0What about considering a hitchhike= rs guide to SDP similar to
> >> =A0 =A0 =A0what was done for SIP?
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0One umbrella document that points = the reader to all the SDP
> >> =A0 =A0 =A0capabilities available that they might want to tak= e advantage of.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0Just a suggestion.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0Andrew
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0----- Original Message -----
> >> =A0 =A0 =A0>>> =A0From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com
> >> =A0 =A0 =A0<mailto:Miguel.A.Garcia@ericsson.com>]
> >> =A0 =A0 =A0>>> =A0Sent: Saturday, January 28, 2012 0= 6:23 AM
> >> =A0 =A0 =A0>>> =A0To: mmusic<mmusic@ietf.org<mailto:mmusic@ietf.org>>
> >> =A0 =A0 =A0>>> =A0Subject: [MMUSIC] Do we need to up= date in time 4566bis?
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0<as an individual>
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0Hi all,
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0You know we are revising RFC 4566.= So far, the effort has
> been
> >> =A0 =A0 =A0in bug fixing.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0The first SDP version was publishe= d as RFC 2327 in 1998
> (i.e.,
> >> =A0 =A0 =A014 years
> >> =A0 =A0 =A0>>> =A0ago), and was then revised as RFC = 4566 in 2006.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0Lots of things have happened since= then. We have SDP offer
> answer,
> >> =A0 =A0 =A0>>> =A0Grouping, QoS, ATM, Bandwidth modi= fiers, TCP media, SDES,
> comeida,
> >> =A0 =A0 =A0>>> =A0labels, BFCP, FEC, ICE, CapNeg, an= d many other that are in
> the pipe.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0 =A0 From the point of view of a r= eader who takes 4566 (or its
> current
> >> =A0 =A0 =A0>>> =A04566bis incarnation), I think it w= ill be difficult for her or
> him to
> >> =A0 =A0 =A0>>> =A0understand a protocol that ignores= those other extensions.
> For
> >> =A0 =A0 =A0example, I
> >> =A0 =A0 =A0>>> =A0recently post another e-mail where= there is an apparent
> >> =A0 =A0 =A0contradiction
> >> =A0 =A0 =A0>>> =A0between 4566 and ICE (see
> >> =A0 =A0 =A0>>> =A0http://www.ietf.org/mail-
> archive/web/mmusic/current/msg09089.html ).
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0So, I was wondering if time has co= me to make not a bug
> correction in
> >> =A0 =A0 =A0>>> =A04566bis, but also put that RFC in = context with the other
> >> =A0 =A0 =A0extensions that
> >> =A0 =A0 =A0>>> =A0exist. This may include:
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0- Add minor extensions to the core= document, similarly to
> what
> >> =A0 =A0 =A0we did
> >> =A0 =A0 =A0>>> =A0with IPv6 support (i.e., 4566 =3D = 2327 + 3266). I don't know
> which
> >> =A0 =A0 =A0of these
> >> =A0 =A0 =A0>>> =A0extensions make sense to include, = this would be an exercise
> to
> >> =A0 =A0 =A0do, but
> >> =A0 =A0 =A0>>> =A0let me give you one potential exam= ple: RFC 4574, the SDP
> "label"
> >> =A0 =A0 =A0>>> =A0attribute is a 6 pages RFC.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0- Adding references to extensions,= when it makes sense. For
> >> =A0 =A0 =A0example, ICE
> >> =A0 =A0 =A0>>> =A0should be referred somewhere (see = my previous post regarding
> the "o"
> >> =A0 =A0 =A0>>> =A0line). I guess capneg could be als= o mentioned, perhaps
> others.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0I know this is a bigger effort tha= n anticipated, but the
> result
> >> =A0 =A0 =A0could
> >> =A0 =A0 =A0>>> =A0really help newcomers to this worl= d.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0Now, it is your turn to express yo= ur opinions. Please do it.
> >> =A0 =A0 =A0>>>
> >> =A0 =A0 =A0>>> =A0/Miguel
> >> =A0 =A0 =A0>>
> >> =A0 =A0 =A0>> =A0--
> >> =A0 =A0 =A0>> =A0Miguel A. Garcia
> >> =A0 =A0 =A0>> =A0+34-91-339-3608<tel:%2B34-91-339-3608>
> >> =A0 =A0 =A0>> =A0Ericsson Spain
> >> =A0 =A0 =A0>> =A0______________________________________= _________
> >> =A0 =A0 =A0>> =A0mmusic mailing list
> >> =A0 =A0 =A0>> =A0mmu= sic@ietf.org<mailto:mmusic@ietf.o= rg>
> >> =A0 =A0 =A0>> =A0https://www.ietf.org/mailman/listinfo/= mmusic
> >> =A0 =A0 =A0>> =A0______________________________________= _________
> >> =A0 =A0 =A0>> =A0mmusic mailing list
> >> =A0 =A0 =A0>> =A0mmu= sic@ietf.org<mailto:mmusic@ietf.o= rg>
> >> =A0 =A0 =A0>> =A0https://www.ietf.org/mailman/listinfo/= mmusic
> >> =A0 =A0 =A0> =A0__________________________________________= _____
> >> =A0 =A0 =A0> =A0mmusic mailing list
> >> =A0 =A0 =A0> =A0mmusic@= ietf.org<mailto:mmusic@ietf.org>
> >> =A0 =A0 =A0> =A0https://www.ietf.org/mailman/listinfo/mmus= ic
> >> =A0 =A0 =A0>
> >>
> >>
> >
> > _______________________________________________
> > 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
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>
> --
> Miguel A. Garcia
> +34-91-339-36= 08
> Ericsson Spain
> _______________________________________________
> 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

--20cf3079bc9edd82a604baa874dc-- From keith.drage@alcatel-lucent.com Wed Mar 7 07:18:25 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 DAFA921F8707 for ; Wed, 7 Mar 2012 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.422 X-Spam-Level: X-Spam-Status: No, score=-107.422 tagged_above=-999 required=5 tests=[AWL=-1.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 yl1M6JJVH7PX for ; Wed, 7 Mar 2012 07:18:22 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 267DB21F85AA for ; Wed, 7 Mar 2012 07:18:21 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q27FGFGG005602 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 16:16:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 7 Mar 2012 16:16:27 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes Date: Wed, 7 Mar 2012 16:16:26 +0100 Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP Thread-Index: Acz8c2mXLXxm2Cw2TJGByqyMna7SkwAASlvQ Message-ID: References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE224C3693EFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 15:18:26 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE224C3693EFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure that is the right answer. There are many points where SDP used by H.248 has to be generated based on = what is received in the SDP received from SIP. If we do not address those r= elationships in some way we would appear to have a less than useful documen= t (and two separate documents would not do that). I would at least suggest we investigate whether it is possible rather to do= a combined document rather than eliminate that possibility at start. Regards Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 07 March 2012 15:03 To: DRAGE, Keith (Keith) Cc: Miguel A. Garcia; Bert Greevenbosch; mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP Per Albrecht response, I think we would open a can of worms if we want this= to be a general guide on SDP for all usages. I would prefer to keep it li= mited to SIP at this time, which I think is no small task. Then another doc= ument, modeled after this one, could cover other usages if the interested = parties think it would be helpful. Mary. On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) > wrote: I notice RFC 3264 is mentioned as one of the core specifications. This only becomes core when SDP is used in the context of SIP. If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a d= ifferent viewpoint of what is core and what is not. We may need to address these different viewpoints, unless you want to make = a guide that is entirely focused on SIP usage. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmu= sic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 07 March 2012 10:56 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > Bert, > > Here is another document with the same purpose. You can use it for > inspiration. This is a bit more complex document, because it has to deal > with several different protocols, rather than only one. > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > The other document that you need to consult is the IANA SDP Parameters > registry at: > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > This contains a list of all the SDP extensions, and they all should be > listed in the hitchhiker's guide. > > /Miguel > > On 07/03/2012 3:54, Bert Greevenbosch wrote: > > Hi all, > > > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied > most initial text from there, and in addition included an initial list of > RFCs / drafts that seem relevant. > > > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > sdp/ > > > > If the group is happy with this approach, I will be happy to maintain a= n > editor's role, and write more text. Obviously other people's input will b= e > highly appreciated, and indeed is needed. > > > > I look forward to your comments. > > > > Best regards, > > Bert > > > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the > draft. How to deal with this? > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:m= music-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: 27 February 2012 04:53 > > To: Gonzalo Camarillo; Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > Hi, > > > > As a directorate member, I am willing to co-author such draft, should a > decision to write one be taken. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:m= music-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > > Sent: 23. helmikuuta 2012 19:31 > > To: Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > I agree. > > > > Gonzalo > > > > On 23/02/2012 7:06 PM, Mary Barnes wrote: > >> I would think that in order for the document to have integrity that at > >> least one of the directorate members should at least be a co-author. > >> Otherwise, I see a lot more stuff falling through the cracks and > >> needing to be resolved during WGLC and later, which usually isn't a > >> good thing. The SIP Hitchhiker's guide provides a good example in > >> that the author was also a primary contributor to RFC3261, etc. > >> > >> Mary. > >> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > >> > >> >> > >> wrote: > >> > >> Hi Mary, > >> > >> yes, the members of the SDP directorate would need to review such > a > >> guide. However, the fact that they agreed to be members of the > >> directorate does not mean they will necessarily have cycles to > >> significantly contribute to the creation of the guide. We need to > make > >> sure we have enough energy around this effort in order to start > it. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: > >> > I think this is a good idea. I would think the experts that > can > >> > contribute (and should review) can be found in the new SDP > >> > directorate: > >> > http://www.ietf.org/iesg/directorate/sdp.html > >> > BTW, it would be nice to have a link to this page on the MMUSI= C > WG > >> wiki: > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > >> > > >> > As far as whether to publish, I think it would be a good idea > to > >> > complete publication as IMHO that improves the integrity of th= e > >> > information - i.e., more eyes review a published RFC than a > draft. > >> > It could later be updated to reflect more recent RFCs OR a > "More of > >> > Hitchhikers Guide" could be published. > >> > > >> > Thanks, > >> > Mary. > >> > > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > >> > > >> >> wrote: > >> >> Hi Miguel, Andrew, all, > >> >> > >> >> Sounds like a good idea. I would be happy to volunteer to pla= y > a > >> central role in it (i.e. be the editor, create the initial draft, > >> ...), but I would need support from other experts too. > >> >> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to > SIP" > >> has become an RFC (5411). That means that it has been frozen, and > to > >> add new info new individual or WG drafts are needed. > >> >> > >> >> Would this be the same approach for SDP? Currently, there are > >> already quite some new drafts that extend SDP. How will future > >> extensions be handled? Maybe it would be good to make it a > permanent > >> WG draft, which is updated every now and then. > >> >> > >> >> Best regards, > >> >> Bert > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: mmusic-bounces@ietf.org= > > >> [mailto:mmusic-bounces@ietf.org>] > On > >> Behalf Of Miguel A. Garcia > >> >> Sent: 14 February 2012 15:42 > >> >> To: Andrew Allen > >> >> Cc: mmusic@ietf.org> > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> >> > >> >> Sounds good to me too. If someone wants to start such draft..= . > >> >> > >> >> /Miguel > >> >> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: > >> >>> > >> >>> What about considering a hitchhikers guide to SDP similar to > >> what was done for SIP? > >> >>> > >> >>> One umbrella document that points the reader to all the SDP > >> capabilities available that they might want to take advantage of. > >> >>> > >> >>> Just a suggestion. > >> >>> > >> >>> Andrew > >> >>> > >> >>> ----- Original Message ----- > >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com<= mailto:Miguel.A.Garcia@ericsson.com> > >> >] > >> >>> Sent: Saturday, January 28, 2012 06:23 AM > >> >>> To: mmusic>> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >> >>> > >> >>> > >> >>> > >> >>> Hi all, > >> >>> > >> >>> You know we are revising RFC 4566. So far, the effort has > been > >> in bug fixing. > >> >>> > >> >>> The first SDP version was published as RFC 2327 in 1998 > (i.e., > >> 14 years > >> >>> ago), and was then revised as RFC 4566 in 2006. > >> >>> > >> >>> Lots of things have happened since then. We have SDP offer > answer, > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, > comeida, > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in > the pipe. > >> >>> > >> >>> From the point of view of a reader who takes 4566 (or its > current > >> >>> 4566bis incarnation), I think it will be difficult for her o= r > him to > >> >>> understand a protocol that ignores those other extensions. > For > >> example, I > >> >>> recently post another e-mail where there is an apparent > >> contradiction > >> >>> between 4566 and ICE (see > >> >>> http://www.ietf.org/mail- > archive/web/mmusic/current/msg09089.html ). > >> >>> > >> >>> So, I was wondering if time has come to make not a bug > correction in > >> >>> 4566bis, but also put that RFC in context with the other > >> extensions that > >> >>> exist. This may include: > >> >>> > >> >>> - Add minor extensions to the core document, similarly to > what > >> we did > >> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know > which > >> of these > >> >>> extensions make sense to include, this would be an exercise > to > >> do, but > >> >>> let me give you one potential example: RFC 4574, the SDP > "label" > >> >>> attribute is a 6 pages RFC. > >> >>> > >> >>> - Adding references to extensions, when it makes sense. For > >> example, ICE > >> >>> should be referred somewhere (see my previous post regarding > the "o" > >> >>> line). I guess capneg could be also mentioned, perhaps > others. > >> >>> > >> >>> I know this is a bigger effort than anticipated, but the > result > >> could > >> >>> really help newcomers to this world. > >> >>> > >> >>> Now, it is your turn to express your opinions. Please do it. > >> >>> > >> >>> /Miguel > >> >> > >> >> -- > >> >> Miguel A. Garcia > >> >> +34-91-339-3608 > >> >> Ericsson Spain > >> >> _______________________________________________ > >> >> 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 > >> > _______________________________________________ > >> > 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 > > _______________________________________________ > > 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 > > > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > 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 --_000_EDC0A1AE77C57744B664A310A0B23AE224C3693EFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure that is the right answer.

 

There are many points where SDP used b= y H.248 has to be generated based on what is received in the SDP received fro= m SIP. If we do not address those relationships in some way we would appear t= o have a less than useful document (and two separate documents would not do that).

 

I would at least suggest we investigat= e whether it is possible rather to do a combined document rather than eliminate that possibility at start.

 

Regards

 

Keith

 

From:= Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 07 March 2012 15:03 To: DRAGE, Keith (Keith)
Cc: Miguel A. Garcia; Bert Greevenbosch; mmusic@ietf.org
Subject: Re: [MMUSIC] Hitchh= iker's guide to SDP

 

Per Albrecht response, I think we would open a can of worms if we w= ant this to be a general guide on SDP for all usages.  I would prefer to k= eep it limited to SIP at this time, which I think is no small task. Then anothe= r document, modeled after this one,  could cover other usages if the interested parties think it would be helpful. 

 

Mary. <= /o:p>

On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.c= om> wrote:

I notice RFC 3264 is mentioned as one of the core specifications.
This only becomes core when SDP is used in the context of SIP.

If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a different viewpoint of what is core and what is not.

We may need to address these different viewpoints, unless you want to make = a guide that is entirely focused on SIP usage.

Regards

Keith


> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ietf.org<= /a>] On Behalf

> Bert,
>
> Here is another document with the same purpose. You can use it for
> inspiration. This is a bit more complex document, because it has to de= al
> with several different protocols, rather than only one.
>
> http://tools.ietf.org/html/draft-ietf-opsawg-management-s= tds
>
> The other document that you need to consult is the IANA SDP Parameters=
> registry at:
>
> http://www.iana.org/assignments/sdp-parameters/sdp-parame= ters.xml
>
> This contains a list of all the SDP extensions, and they all should be=
> listed in the hitchhiker's guide.
>
> /Miguel
>
> On 07/03/2012 3:54, Bert Greevenbosch wrote:
> > Hi all,
> >
> > On Monday, I have uploaded a v00 draft for "Hitchhiker's Gui= de to SDP".
> It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied
> most initial text from there, and in addition included an initial list= of
> RFCs / drafts that seem relevant.
> >
> > https://datatracker.ietf.org/doc/draft-greevenbosch-hitch= hikersguide-
> sdp/
> >
> > If the group is happy with this approach, I will be happy to main= tain an
> editor's role, and write more text. Obviously other people's input wil= l be
> highly appreciated, and indeed is needed.
> >
> > I look forward to your comments.
> >
> > Best regards,
> > Bert
> >
> > P.S. Unfortunately, I forgot to include "mmusic" in the name of the
> draft. How to deal with this?
> >
> >
> >
> > -----Original Message-----
> > From: mmusic-bounces@i= etf.org [mailto:mmusic-bounces@ietf.org<= /a>] On Behalf
> Of Christer Holmberg
> > Sent: 27 February 2012 04:53
> > To: Gonzalo Camarillo; Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> >
> > Hi,
> >
> > As a directorate member, I am willing to co-author such draft, sh= ould a
> decision to write one be taken.
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: mmusic-bounces@i= etf.org [mailto:mmusic-bounces@ietf.org<= /a>] On Behalf
> Of Gonzalo Camarillo
> > Sent: 23. helmikuuta 2012 19:31
> > To: Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> > I agree.
> >
> > Gonzalo
> >
> > On 23/02/2012 7:06 PM, Mary Barnes wrote:
> >> I would think that in order for the document to have integrit= y that at
> >> least one of the directorate members should at least be a co-author.
> >>   Otherwise, I see a lot more stuff falling through the cracks and
> >> needing to be resolved during WGLC and later, which usually i= sn't a
> >> good thing.  The SIP Hitchhiker's guide provides a good example in
> >> that the author was also a primary contributor to RFC3261, et= c.
> >>
> >> Mary.
> >>
> >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo
> >> <Gonzalo= .Camarillo@ericsson.com
> >> <mailto:= Gonzalo.Camarillo@ericsson.com>>
> >> wrote:
> >>
> >>      Hi Mary,
> >>
> >>      yes, the members of the SDP directorate w= ould need to review such
> a
> >>      guide. However, the fact that they agreed= to be members of the
> >>      directorate does not mean they will necessarily have cycles to
> >>      significantly contribute to the creation = of the guide. We need to
> make
> >>      sure we have enough energy around this ef= fort in order to start
> it.
> >>
> >>      Cheers,
> >>
> >>      Gonzalo
> >>
> >>      On 15/02/2012 7:14 PM, Mary Barnes wrote:=
> >>      >  I think this is a good idea.  I would think the experts that
> can
> >>      >  contribute (and should review)= can be found in the new SDP
> >>      >  directorate:
> >>      >  ht= tp://www.ietf.org/iesg/directorate/sdp.html
> >>      >  BTW, it would be nice to have = a link to this page on the MMUSIC
> WG
> >>      wiki:
> >>      >  h= ttp://trac.tools.ietf.org/wg/mmusic/trac/wiki
> >>      >
> >>      >  As far as whether to publish, = I think it would be a good idea
> to
> >>      >  complete publication as IMHO t= hat improves the integrity of the
> >>      >  information - i.e., more eyes review a published RFC than a
> draft.
> >>      >  It could later be updated to reflect more recent RFCs OR a
> "More of
> >>      >  Hitchhikers Guide" could = be published.
> >>      >
> >>      >  Thanks,
> >>      >  Mary.
> >>      >
> >>      >  On Wed, Feb 15, 2012 at 12:29 = AM, Bert Greevenbosch
> >>      >  <Bert.Greevenbosch@huawei.com
> >>      <mailto:Bert.Greevenbosch@huawei.com>>  wrote:
> >>      >>  Hi Miguel, Andrew, all, > >>      >>
> >>      >>  Sounds like a good idea. I would be happy to volunteer to play
> a
> >>      central role in it (i.e. be the editor, create the initial draft,
> >>      ...), but I would need support from other experts too.
> >>      >>
> >>      >>  As for practicalities, I s= ee that the "Hitchhiker's Guide to
> SIP"
> >>      has become an RFC (5411). That means that= it has been frozen, and
> to
> >>      add new info new individual or WG drafts = are needed.
> >>      >>
> >>      >>  Would this be the same approach for SDP? Currently, there are
> >>      already quite some new drafts that extend SDP. How will future
> >>      extensions be handled? Maybe it would be = good to make it a
> permanent
> >>      WG draft, which is updated every now and then.
> >>      >>
> >>      >>  Best regards,
> >>      >>  Bert
> >>      >>
> >>      >>
> >>      >>  -----Original Message-----=
> >>      >>  From: mmusic-bounces@ietf.org<mail= to:mmusic-bounces@ietf.org>
> >>      [mailto:mmusic-bounces@ietf.org<mail= to:mmusic-bounces@ietf.org>] > On
> >>      Behalf Of Miguel A. Garcia
> >>      >>  Sent: 14 February 2012 15:= 42
> >>      >>  To: Andrew Allen
> >>      >>  Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  Subject: Re: [MMUSIC] Do w= e need to update in time 4566bis?
> >>      >>
> >>      >>  Sounds good to me too. If someone wants to start such draft...
> >>      >>
> >>      >>  /Miguel
> >>      >>
> >>      >>  On 13/02/2012 23:15, Andre= w Allen wrote:
> >>      >>>
> >>      >>>  What about considering= a hitchhikers guide to SDP similar to
> >>      what was done for SIP?
> >>      >>>
> >>      >>>  One umbrella document = that points the reader to all the SDP
> >>      capabilities available that they might wa= nt to take advantage of.
> >>      >>>
> >>      >>>  Just a suggestion.
> >>      >>>
> >>      >>>  Andrew
> >>      >>>
> >>      >>>  ----- Original Message -----
> >>      >>>  From: Miguel A. Garcia [mailto:Miguel.A.Garcia@eri= csson.com
> >>      <mailto:Miguel.A.Garcia@ericsson.com>]
> >>      >>>  Sent: Saturday, Januar= y 28, 2012 06:23 AM
> >>      >>>  To: mmusic<mmusic@ietf.org<mailto:mmusic@ietf.org>>
> >>      >>>  Subject: [MMUSIC] Do w= e need to update in time 4566bis?
> >>      >>>
> >>      >>>  <as an individual&g= t;
> >>      >>>
> >>      >>>  Hi all,
> >>      >>>
> >>      >>>  You know we are revisi= ng RFC 4566. So far, the effort has
> been
> >>      in bug fixing.
> >>      >>>
> >>      >>>  The first SDP version = was published as RFC 2327 in 1998
> (i.e.,
> >>      14 years
> >>      >>>  ago), and was then rev= ised as RFC 4566 in 2006.
> >>      >>>
> >>      >>>  Lots of things have happened since then. We have SDP offer
> answer,
> >>      >>>  Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES,
> comeida,
> >>      >>>  labels, BFCP, FEC, ICE= , CapNeg, and many other that are in
> the pipe.
> >>      >>>
> >>      >>>     From the point= of view of a reader who takes 4566 (or its
> current
> >>      >>>  4566bis incarnation), = I think it will be difficult for her or
> him to
> >>      >>>  understand a protocol = that ignores those other extensions.
> For
> >>      example, I
> >>      >>>  recently post another e-mail where there is an apparent
> >>      contradiction
> >>      >>>  between 4566 and ICE (= see
> >>      >>>  http://www.ietf.org/ma= il-
> archive/web/mmusic/current/msg09089.html ).
> >>      >>>
> >>      >>>  So, I was wondering if time has come to make not a bug
> correction in
> >>      >>>  4566bis, but also put = that RFC in context with the other
> >>      extensions that
> >>      >>>  exist. This may includ= e:
> >>      >>>
> >>      >>>  - Add minor extensions= to the core document, similarly to
> what
> >>      we did
> >>      >>>  with IPv6 support (i.e= ., 4566 =3D 2327 + 3266). I don't know
> which
> >>      of these
> >>      >>>  extensions make sense = to include, this would be an exercise
> to
> >>      do, but
> >>      >>>  let me give you one potential example: RFC 4574, the SDP
> "label"
> >>      >>>  attribute is a 6 pages RFC.
> >>      >>>
> >>      >>>  - Adding references to extensions, when it makes sense. For
> >>      example, ICE
> >>      >>>  should be referred somewhere (see my previous post regarding
> the "o"
> >>      >>>  line). I guess capneg could be also mentioned, perhaps
> others.
> >>      >>>
> >>      >>>  I know this is a bigge= r effort than anticipated, but the
> result
> >>      could
> >>      >>>  really help newcomers = to this world.
> >>      >>>
> >>      >>>  Now, it is your turn t= o express your opinions. Please do it.
> >>      >>>
> >>      >>>  /Miguel
> >>      >>
> >>      >>  --
> >>      >>  Miguel A. Garcia
> >>      >>  +34-91-339-3608<tel:%2B34-91-339-3608>
> >>      >>  Ericsson Spain > >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  htt= ps://www.ietf.org/mailman/listinfo/mmusic
> >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  htt= ps://www.ietf.org/mailman/listinfo/mmusic
> >>      >  _______________________________________________
> >>      >  mmusic mailing list
> >>      >  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >  htt= ps://www.ietf.org/mailman/listinfo/mmusic
> >>      >
> >>
> >>
> >
> > _______________________________________________
> > 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
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>
> --
> Miguel A. Garcia
> +34-91-339-36= 08
> Ericsson Spain<= /st1:place>
> _______________________________________________
> 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

 

--_000_EDC0A1AE77C57744B664A310A0B23AE224C3693EFRMRSSXCHMBSC3d_-- From gsalguei@cisco.com Wed Mar 7 07:19:26 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 F319A21E80B2 for ; Wed, 7 Mar 2012 07:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 YQ2s0a2R4kxI for ; Wed, 7 Mar 2012 07:19:24 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id CB8ED21F85AA for ; Wed, 7 Mar 2012 07:19:23 -0800 (PST) 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 q27FJLmX013329 for ; Wed, 7 Mar 2012 10:19:21 -0500 (EST) Received: from dhcp-64-102-210-38.cisco.com (dhcp-64-102-210-38.cisco.com [64.102.210.38]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q27FJJW8018116; Wed, 7 Mar 2012 10:19:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_41C0E5FB-8720-4C8A-A34C-A59E6B214A9E" From: Gonzalo Salgueiro In-Reply-To: Date: Wed, 7 Mar 2012 10:19:19 -0500 Message-Id: References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> To: Mary Barnes X-Mailer: Apple Mail (2.1257) Cc: "DRAGE, Keith \(Keith\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 07 Mar 2012 15:19:26 -0000 --Apple-Mail=_41C0E5FB-8720-4C8A-A34C-A59E6B214A9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree. Limiting it to SIP seems sufficiently Herculean for one = document IMO. Gonzalo On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote: > Per Albrecht response, I think we would open a can of worms if we want = this to be a general guide on SDP for all usages. I would prefer to = keep it limited to SIP at this time, which I think is no small task. = Then another document, modeled after this one, could cover other usages = if the interested parties think it would be helpful.=20 >=20 > Mary.=20 >=20 > On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) = wrote: > I notice RFC 3264 is mentioned as one of the core specifications. >=20 > This only becomes core when SDP is used in the context of SIP. >=20 > If I am a Megaco / H.248 user of SDP I suspect therefore I come up = with a different viewpoint of what is core and what is not. >=20 > We may need to address these different viewpoints, unless you want to = make a guide that is entirely focused on SIP usage. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf > > Of Miguel A. Garcia > > Sent: 07 March 2012 10:56 > > To: Bert Greevenbosch > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > Bert, > > > > Here is another document with the same purpose. You can use it for > > inspiration. This is a bit more complex document, because it has to = deal > > with several different protocols, rather than only one. > > > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > > > The other document that you need to consult is the IANA SDP = Parameters > > registry at: > > > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > > > This contains a list of all the SDP extensions, and they all should = be > > listed in the hitchhiker's guide. > > > > /Miguel > > > > On 07/03/2012 3:54, Bert Greevenbosch wrote: > > > Hi all, > > > > > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to = SDP". > > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have = copied > > most initial text from there, and in addition included an initial = list of > > RFCs / drafts that seem relevant. > > > > > > = https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > > sdp/ > > > > > > If the group is happy with this approach, I will be happy to = maintain an > > editor's role, and write more text. Obviously other people's input = will be > > highly appreciated, and indeed is needed. > > > > > > I look forward to your comments. > > > > > > Best regards, > > > Bert > > > > > > P.S. Unfortunately, I forgot to include "mmusic" in the name of = the > > draft. How to deal with this? > > > > > > > > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf > > Of Christer Holmberg > > > Sent: 27 February 2012 04:53 > > > To: Gonzalo Camarillo; Mary Barnes > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > > > > Hi, > > > > > > As a directorate member, I am willing to co-author such draft, = should a > > decision to write one be taken. > > > > > > Regards, > > > > > > Christer > > > > > > -----Original Message----- > > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf > > Of Gonzalo Camarillo > > > Sent: 23. helmikuuta 2012 19:31 > > > To: Mary Barnes > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > I agree. > > > > > > Gonzalo > > > > > > On 23/02/2012 7:06 PM, Mary Barnes wrote: > > >> I would think that in order for the document to have integrity = that at > > >> least one of the directorate members should at least be a = co-author. > > >> Otherwise, I see a lot more stuff falling through the cracks = and > > >> needing to be resolved during WGLC and later, which usually isn't = a > > >> good thing. The SIP Hitchhiker's guide provides a good example = in > > >> that the author was also a primary contributor to RFC3261, etc. > > >> > > >> Mary. > > >> > > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > > >> > >> > > > >> wrote: > > >> > > >> Hi Mary, > > >> > > >> yes, the members of the SDP directorate would need to review = such > > a > > >> guide. However, the fact that they agreed to be members of = the > > >> directorate does not mean they will necessarily have cycles = to > > >> significantly contribute to the creation of the guide. We = need to > > make > > >> sure we have enough energy around this effort in order to = start > > it. > > >> > > >> Cheers, > > >> > > >> Gonzalo > > >> > > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: > > >> > I think this is a good idea. I would think the experts = that > > can > > >> > contribute (and should review) can be found in the new = SDP > > >> > directorate: > > >> > http://www.ietf.org/iesg/directorate/sdp.html > > >> > BTW, it would be nice to have a link to this page on the = MMUSIC > > WG > > >> wiki: > > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > > >> > > > >> > As far as whether to publish, I think it would be a good = idea > > to > > >> > complete publication as IMHO that improves the integrity = of the > > >> > information - i.e., more eyes review a published RFC than = a > > draft. > > >> > It could later be updated to reflect more recent RFCs OR = a > > "More of > > >> > Hitchhikers Guide" could be published. > > >> > > > >> > Thanks, > > >> > Mary. > > >> > > > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > > >> > > >> > wrote: > > >> >> Hi Miguel, Andrew, all, > > >> >> > > >> >> Sounds like a good idea. I would be happy to volunteer = to play > > a > > >> central role in it (i.e. be the editor, create the initial = draft, > > >> ...), but I would need support from other experts too. > > >> >> > > >> >> As for practicalities, I see that the "Hitchhiker's = Guide to > > SIP" > > >> has become an RFC (5411). That means that it has been = frozen, and > > to > > >> add new info new individual or WG drafts are needed. > > >> >> > > >> >> Would this be the same approach for SDP? Currently, = there are > > >> already quite some new drafts that extend SDP. How will = future > > >> extensions be handled? Maybe it would be good to make it a > > permanent > > >> WG draft, which is updated every now and then. > > >> >> > > >> >> Best regards, > > >> >> Bert > > >> >> > > >> >> > > >> >> -----Original Message----- > > >> >> From: = mmusic-bounces@ietf.org > > >> = [mailto:mmusic-bounces@ietf.org] > > On > > >> Behalf Of Miguel A. Garcia > > >> >> Sent: 14 February 2012 15:42 > > >> >> To: Andrew Allen > > >> >> Cc: mmusic@ietf.org > > >> >> Subject: Re: [MMUSIC] Do we need to update in time = 4566bis? > > >> >> > > >> >> Sounds good to me too. If someone wants to start such = draft... > > >> >> > > >> >> /Miguel > > >> >> > > >> >> On 13/02/2012 23:15, Andrew Allen wrote: > > >> >>> > > >> >>> What about considering a hitchhikers guide to SDP = similar to > > >> what was done for SIP? > > >> >>> > > >> >>> One umbrella document that points the reader to all the = SDP > > >> capabilities available that they might want to take = advantage of. > > >> >>> > > >> >>> Just a suggestion. > > >> >>> > > >> >>> Andrew > > >> >>> > > >> >>> ----- Original Message ----- > > >> >>> From: Miguel A. Garcia = [mailto:Miguel.A.Garcia@ericsson.com > > >> ] > > >> >>> Sent: Saturday, January 28, 2012 06:23 AM > > >> >>> To: mmusic> > > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > > >> >>> > > >> >>> > > >> >>> > > >> >>> Hi all, > > >> >>> > > >> >>> You know we are revising RFC 4566. So far, the effort = has > > been > > >> in bug fixing. > > >> >>> > > >> >>> The first SDP version was published as RFC 2327 in 1998 > > (i.e., > > >> 14 years > > >> >>> ago), and was then revised as RFC 4566 in 2006. > > >> >>> > > >> >>> Lots of things have happened since then. We have SDP = offer > > answer, > > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, = SDES, > > comeida, > > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are = in > > the pipe. > > >> >>> > > >> >>> =46rom the point of view of a reader who takes 4566 = (or its > > current > > >> >>> 4566bis incarnation), I think it will be difficult for = her or > > him to > > >> >>> understand a protocol that ignores those other = extensions. > > For > > >> example, I > > >> >>> recently post another e-mail where there is an apparent > > >> contradiction > > >> >>> between 4566 and ICE (see > > >> >>> http://www.ietf.org/mail- > > archive/web/mmusic/current/msg09089.html ). > > >> >>> > > >> >>> So, I was wondering if time has come to make not a bug > > correction in > > >> >>> 4566bis, but also put that RFC in context with the = other > > >> extensions that > > >> >>> exist. This may include: > > >> >>> > > >> >>> - Add minor extensions to the core document, similarly = to > > what > > >> we did > > >> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't = know > > which > > >> of these > > >> >>> extensions make sense to include, this would be an = exercise > > to > > >> do, but > > >> >>> let me give you one potential example: RFC 4574, the = SDP > > "label" > > >> >>> attribute is a 6 pages RFC. > > >> >>> > > >> >>> - Adding references to extensions, when it makes sense. = For > > >> example, ICE > > >> >>> should be referred somewhere (see my previous post = regarding > > the "o" > > >> >>> line). I guess capneg could be also mentioned, perhaps > > others. > > >> >>> > > >> >>> I know this is a bigger effort than anticipated, but = the > > result > > >> could > > >> >>> really help newcomers to this world. > > >> >>> > > >> >>> Now, it is your turn to express your opinions. Please = do it. > > >> >>> > > >> >>> /Miguel > > >> >> > > >> >> -- > > >> >> Miguel A. Garcia > > >> >> +34-91-339-3608 > > >> >> Ericsson Spain > > >> >> _______________________________________________ > > >> >> 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 > > >> > _______________________________________________ > > >> > 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 > > > _______________________________________________ > > > 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 > > > > > > > -- > > Miguel A. Garcia > > +34-91-339-3608 > > Ericsson Spain > > _______________________________________________ > > 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 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_41C0E5FB-8720-4C8A-A34C-A59E6B214A9E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I agree. Limiting it to SIP seems sufficiently Herculean for one document IMO.

Gonzalo

On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote:

Per Albrecht response, I think we would open a can of worms if we want this to be a general guide on SDP for all usages.  I would prefer to keep it limited to SIP at this time, which I think is no small task. Then another document, modeled after this one,  could cover other usages if the interested parties think it would be helpful. 

Mary. 

On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
I notice RFC 3264 is mentioned as one of the core specifications.

This only becomes core when SDP is used in the context of SIP.

If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a different viewpoint of what is core and what is not.

We may need to address these different viewpoints, unless you want to make a guide that is entirely focused on SIP usage.

Regards

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Miguel A. Garcia
> Sent: 07 March 2012 10:56
> To: Bert Greevenbosch
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
>
> Bert,
>
> Here is another document with the same purpose. You can use it for
> inspiration. This is a bit more complex document, because it has to deal
> with several different protocols, rather than only one.
>
> http://tools.ietf.org/html/draft-ietf-opsawg-management-stds
>
> The other document that you need to consult is the IANA SDP Parameters
> registry at:
>
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml
>
> This contains a list of all the SDP extensions, and they all should be
> listed in the hitchhiker's guide.
>
> /Miguel
>
> On 07/03/2012 3:54, Bert Greevenbosch wrote:
> > Hi all,
> >
> > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP".
> It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied
> most initial text from there, and in addition included an initial list of
> RFCs / drafts that seem relevant.
> >
> > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-
> sdp/
> >
> > If the group is happy with this approach, I will be happy to maintain an
> editor's role, and write more text. Obviously other people's input will be
> highly appreciated, and indeed is needed.
> >
> > I look forward to your comments.
> >
> > Best regards,
> > Bert
> >
> > P.S. Unfortunately, I forgot to include "mmusic" in the name of the
> draft. How to deal with this?
> >
> >
> >
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Christer Holmberg
> > Sent: 27 February 2012 04:53
> > To: Gonzalo Camarillo; Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> >
> > Hi,
> >
> > As a directorate member, I am willing to co-author such draft, should a
> decision to write one be taken.
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Gonzalo Camarillo
> > Sent: 23. helmikuuta 2012 19:31
> > To: Mary Barnes
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP
> >
> > I agree.
> >
> > Gonzalo
> >
> > On 23/02/2012 7:06 PM, Mary Barnes wrote:
> >> I would think that in order for the document to have integrity that at
> >> least one of the directorate members should at least be a co-author.
> >>   Otherwise, I see a lot more stuff falling through the cracks and
> >> needing to be resolved during WGLC and later, which usually isn't a
> >> good thing.  The SIP Hitchhiker's guide provides a good example in
> >> that the author was also a primary contributor to RFC3261, etc.
> >>
> >> Mary.
> >>
> >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo
> >> <Gonzalo.Camarillo@ericsson.com
> >> <mailto:Gonzalo.Camarillo@ericsson.com>>
> >> wrote:
> >>
> >>      Hi Mary,
> >>
> >>      yes, the members of the SDP directorate would need to review such
> a
> >>      guide. However, the fact that they agreed to be members of the
> >>      directorate does not mean they will necessarily have cycles to
> >>      significantly contribute to the creation of the guide. We need to
> make
> >>      sure we have enough energy around this effort in order to start
> it.
> >>
> >>      Cheers,
> >>
> >>      Gonzalo
> >>
> >>      On 15/02/2012 7:14 PM, Mary Barnes wrote:
> >>      >  I think this is a good idea.  I would think the experts that
> can
> >>      >  contribute (and should review) can be found in the new SDP
> >>      >  directorate:
> >>      >  http://www.ietf.org/iesg/directorate/sdp.html
> >>      >  BTW, it would be nice to have a link to this page on the MMUSIC
> WG
> >>      wiki:
> >>      >  http://trac.tools.ietf.org/wg/mmusic/trac/wiki
> >>      >
> >>      >  As far as whether to publish, I think it would be a good idea
> to
> >>      >  complete publication as IMHO that improves the integrity of the
> >>      >  information - i.e., more eyes review a published RFC than a
> draft.
> >>      >  It could later be updated to reflect more recent RFCs OR a
> "More of
> >>      >  Hitchhikers Guide" could be published.
> >>      >
> >>      >  Thanks,
> >>      >  Mary.
> >>      >
> >>      >  On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch
> >>      >  <Bert.Greevenbosch@huawei.com
> >>      <mailto:Bert.Greevenbosch@huawei.com>>  wrote:
> >>      >>  Hi Miguel, Andrew, all,
> >>      >>
> >>      >>  Sounds like a good idea. I would be happy to volunteer to play
> a
> >>      central role in it (i.e. be the editor, create the initial draft,
> >>      ...), but I would need support from other experts too.
> >>      >>
> >>      >>  As for practicalities, I see that the "Hitchhiker's Guide to
> SIP"
> >>      has become an RFC (5411). That means that it has been frozen, and
> to
> >>      add new info new individual or WG drafts are needed.
> >>      >>
> >>      >>  Would this be the same approach for SDP? Currently, there are
> >>      already quite some new drafts that extend SDP. How will future
> >>      extensions be handled? Maybe it would be good to make it a
> permanent
> >>      WG draft, which is updated every now and then.
> >>      >>
> >>      >>  Best regards,
> >>      >>  Bert
> >>      >>
> >>      >>
> >>      >>  -----Original Message-----
> >>      >>  From: mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>
> >>      [mailto:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>]
> On
> >>      Behalf Of Miguel A. Garcia
> >>      >>  Sent: 14 February 2012 15:42
> >>      >>  To: Andrew Allen
> >>      >>  Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  Subject: Re: [MMUSIC] Do we need to update in time 4566bis?
> >>      >>
> >>      >>  Sounds good to me too. If someone wants to start such draft...
> >>      >>
> >>      >>  /Miguel
> >>      >>
> >>      >>  On 13/02/2012 23:15, Andrew Allen wrote:
> >>      >>>
> >>      >>>  What about considering a hitchhikers guide to SDP similar to
> >>      what was done for SIP?
> >>      >>>
> >>      >>>  One umbrella document that points the reader to all the SDP
> >>      capabilities available that they might want to take advantage of.
> >>      >>>
> >>      >>>  Just a suggestion.
> >>      >>>
> >>      >>>  Andrew
> >>      >>>
> >>      >>>  ----- Original Message -----
> >>      >>>  From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com
> >>      <mailto:Miguel.A.Garcia@ericsson.com>]
> >>      >>>  Sent: Saturday, January 28, 2012 06:23 AM
> >>      >>>  To: mmusic<mmusic@ietf.org<mailto:mmusic@ietf.org>>
> >>      >>>  Subject: [MMUSIC] Do we need to update in time 4566bis?
> >>      >>>
> >>      >>>  <as an individual>
> >>      >>>
> >>      >>>  Hi all,
> >>      >>>
> >>      >>>  You know we are revising RFC 4566. So far, the effort has
> been
> >>      in bug fixing.
> >>      >>>
> >>      >>>  The first SDP version was published as RFC 2327 in 1998
> (i.e.,
> >>      14 years
> >>      >>>  ago), and was then revised as RFC 4566 in 2006.
> >>      >>>
> >>      >>>  Lots of things have happened since then. We have SDP offer
> answer,
> >>      >>>  Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES,
> comeida,
> >>      >>>  labels, BFCP, FEC, ICE, CapNeg, and many other that are in
> the pipe.
> >>      >>>
> >>      >>>     From the point of view of a reader who takes 4566 (or its
> current
> >>      >>>  4566bis incarnation), I think it will be difficult for her or
> him to
> >>      >>>  understand a protocol that ignores those other extensions.
> For
> >>      example, I
> >>      >>>  recently post another e-mail where there is an apparent
> >>      contradiction
> >>      >>>  between 4566 and ICE (see
> >>      >>>  http://www.ietf.org/mail-
> archive/web/mmusic/current/msg09089.html ).
> >>      >>>
> >>      >>>  So, I was wondering if time has come to make not a bug
> correction in
> >>      >>>  4566bis, but also put that RFC in context with the other
> >>      extensions that
> >>      >>>  exist. This may include:
> >>      >>>
> >>      >>>  - Add minor extensions to the core document, similarly to
> what
> >>      we did
> >>      >>>  with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know
> which
> >>      of these
> >>      >>>  extensions make sense to include, this would be an exercise
> to
> >>      do, but
> >>      >>>  let me give you one potential example: RFC 4574, the SDP
> "label"
> >>      >>>  attribute is a 6 pages RFC.
> >>      >>>
> >>      >>>  - Adding references to extensions, when it makes sense. For
> >>      example, ICE
> >>      >>>  should be referred somewhere (see my previous post regarding
> the "o"
> >>      >>>  line). I guess capneg could be also mentioned, perhaps
> others.
> >>      >>>
> >>      >>>  I know this is a bigger effort than anticipated, but the
> result
> >>      could
> >>      >>>  really help newcomers to this world.
> >>      >>>
> >>      >>>  Now, it is your turn to express your opinions. Please do it.
> >>      >>>
> >>      >>>  /Miguel
> >>      >>
> >>      >>  --
> >>      >>  Miguel A. Garcia
> >>      >>  +34-91-339-3608<tel:%2B34-91-339-3608>
> >>      >>  Ericsson Spain
> >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >>  _______________________________________________
> >>      >>  mmusic mailing list
> >>      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >>  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >  _______________________________________________
> >>      >  mmusic mailing list
> >>      >  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>      >  https://www.ietf.org/mailman/listinfo/mmusic
> >>      >
> >>
> >>
> >
> > _______________________________________________
> > 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
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> 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

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

--Apple-Mail=_41C0E5FB-8720-4C8A-A34C-A59E6B214A9E-- From pkyzivat@alum.mit.edu Wed Mar 7 08:44:29 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 3AE8D21F86D9 for ; Wed, 7 Mar 2012 08:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 zZ3ViFlo4pHD for ; Wed, 7 Mar 2012 08:44:28 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4497B21F86CA for ; Wed, 7 Mar 2012 08:44:23 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id idL61i0041YDfWL55gkPa7; Wed, 07 Mar 2012 16:44:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id igkP1i00M07duvL3ggkPnq; Wed, 07 Mar 2012 16:44:23 +0000 Message-ID: <4F579065.60009@alum.mit.edu> Date: Wed, 07 Mar 2012 11:44:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> <4F566A1C.3040406@alum.mit.edu> <4F573D31.2060304@ericsson.com> In-Reply-To: <4F573D31.2060304@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Wed, 07 Mar 2012 16:44:29 -0000 Miguel - comments inline. On 3/7/12 5:49 AM, Miguel A. Garcia wrote: > Hi Paul: > > Thanks for your comments, see inline answers. > > On 06/03/2012 20:48, Paul Kyzivat wrote: >> On 3/6/12 4:34 AM, Simo.Veikkolainen@nokia.com wrote: >>> We have submitted a new version (-10) of Session Description Protocol >>> (SDP) Extension For Setting Up Audio and Video Media Streams Over >>> Circuit-Switched Bearers In The Public Switched Telephone Network >>> (PSTN), which can be found at >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt >>> >>> Changes in this version include: >>> - The port number in "m=" line SHOULD be set to "9" (the discard >>> port) but it MUST be ignored at reception >>> - Clarified that the Discriminator byte is included in the >>> cs-correlation:uuie attribute, but we don't specify a value for the >>> Discriminator byte >> >> I know this has been discussed before, but it still bothers me: >> >> Is there a reason why the representation of this UUIE is so different >> from the representation used in draft-ietf-cuss-sip-uui-isdn-02? >> These things are talking about conveying the same thing in the same >> manner. IMO it would be much better to be consistent about this. > > Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User SIP > header field, whereas this draft uses a "cs-correlation" attribute in SDP? I'm not talking specifically about the header field. The situation is different here - you need to transport this in SDP rather than directly in SIP. What I am talking about is the representation of the UUI value. draft-ietf-cuss-sip-uui-isdn includes the discriminator byte and encodes the whole thing in hex. This draft does it differently. ISTM that these ought to use the same representation unless there is some justification for the difference. > If this is the case, I guess there is a justification. The cuss draft > comes from an angle of making visible in SIP the UUIE in ISDN, > irrespective of their contents. The goal is to improve interoperability > between SIP and ISDN. > > The CS descriptions drafts needs a correlation mechanism between two > objects (a CS call and a RTP stream). It offers three mechanisms, of > which, one happens to be the UUIE. These mechanisms are described in an > SDP attribute. They are specific for the purpose of correlating two > media streams. > > I think both mechanisms serve different purposes, and the only > commonality between them is that it happens to be transporting the same > information. I would not like to see, e.g., that the CS drafts uses two > correlation mechanisms defined in SDP, and a third one in a SIP header. > I don't see the point. I am not disputing use of an SDP parameter rather than a SIP header. > I don't see any problem in leaving them as they are. > > >> >> Is it because implementations of this draft have already been deployed? > > I am not aware of an implementation of the CS descriptions draft, so > this should not be a problem. > >> >>> - Added a new example with audio and video streams >> >> While its good to seen the new example, as shown it has missed the main >> issue that will arise, because it only shows the situation when one of >> the proposed streams is rejected. >> >> If both streams are to be accepted, are they to result in one pstn phone >> call, or two? I would think the intent would be to have only one. But in >> that case, how is it represented in SDP so that its known that only one >> call is made? Is there an assumption that if one phone number is used >> for multiple m-lines, then the same call should be used for both? > > The idea is to have a single PSTN phone call, with audio and video > components. I haven't heard of requirements indicating other thing. > > So, I agree with you that perhaps we ought to describe that for video > calls, a single PSTN phone call is made. Yes, we miss some text there, > thanks for catching this up. I figured you only had one call in mind. But because the phone number is specified in c=, which is media level, there is the potential that audio and video would have differing phone numbers, which would presumably exclude a single call. So there should probably be some explanation of that. Perhaps that there will only be one call per distinct combination of phone number and cs-correlation attribute. Or do you want to exclude the possibility of different phone numbers being supplied? If so, then I might be better to move the phone number from the c-line to a session level attribute. While its possible to specify the phone number once at session level, its also possible to do it at media level, where it might end up different. Also, I would think you would typically want to specify the cs-correlation at session level rather than media level. (In fact you show it that way in your new example.) But currently it is defined as being only media level. So you should probably change that. Thanks, Paul > /Miguel > > >> >> Thanks, >> Paul >> >>> - Added a new section "Considerations for Usage of Third Party Call >>> Control (3PCC)" which recommends the Controller to use "-" as the >>> connection address (to be in line with 0.0.0.0 which is used for IPv4). >>> - Added a new paragraph to security considerations on privacy >>> concerns that arise from including the phone number in the SDP >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From mike.severa@alcatel-lucent.com Wed Mar 7 09:59: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 646D221E8017 for ; Wed, 7 Mar 2012 09:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 tTZ42wU6GW9d for ; Wed, 7 Mar 2012 09:59:47 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5693521F8473 for ; Wed, 7 Mar 2012 09:59:47 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q27HxgjG014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Mar 2012 11:59:42 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q27HxfxL023763 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 11:59:42 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 7 Mar 2012 11:59:41 -0600 From: "Severa, Michael J (Mike)" To: Gonzalo Salgueiro , Mary Barnes Date: Wed, 7 Mar 2012 11:59:38 -0600 Thread-Topic: [MMUSIC] Hitchhiker's guide to SIP SDP Thread-Index: Acz8dbGSgqCqoq+GQh6jKIoHk/faSgAFfKjw Message-ID: References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DDF000BCD4FA4F43909CD45448BAE04E0AD7892DCDUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "DRAGE, Keith \(Keith\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SIP SDP 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, 07 Mar 2012 17:59:50 -0000 --_000_DDF000BCD4FA4F43909CD45448BAE04E0AD7892DCDUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the goal is to limit to SIP or even IMS environments then the title of t= he document should reflect that. SDP is used in many non-SIP environments. Mike ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Gonzalo Salgueiro Sent: Wednesday, March 07, 2012 7:19 AM To: Mary Barnes Cc: DRAGE, Keith (Keith); mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP I agree. Limiting it to SIP seems sufficiently Herculean for one document I= MO. Gonzalo On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote: Per Albrecht response, I think we would open a can of worms if we want this= to be a general guide on SDP for all usages. I would prefer to keep it li= mited to SIP at this time, which I think is no small task. Then another doc= ument, modeled after this one, could cover other usages if the interested = parties think it would be helpful. Mary. On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) > wrote: I notice RFC 3264 is mentioned as one of the core specifications. This only becomes core when SDP is used in the context of SIP. If I am a Megaco / H.248 user of SDP I suspect therefore I come up with a d= ifferent viewpoint of what is core and what is not. We may need to address these different viewpoints, unless you want to make = a guide that is entirely focused on SIP usage. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmu= sic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 07 March 2012 10:56 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > Bert, > > Here is another document with the same purpose. You can use it for > inspiration. This is a bit more complex document, because it has to deal > with several different protocols, rather than only one. > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > The other document that you need to consult is the IANA SDP Parameters > registry at: > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > This contains a list of all the SDP extensions, and they all should be > listed in the hitchhiker's guide. > > /Miguel > > On 07/03/2012 3:54, Bert Greevenbosch wrote: > > Hi all, > > > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied > most initial text from there, and in addition included an initial list of > RFCs / drafts that seem relevant. > > > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > sdp/ > > > > If the group is happy with this approach, I will be happy to maintain a= n > editor's role, and write more text. Obviously other people's input will b= e > highly appreciated, and indeed is needed. > > > > I look forward to your comments. > > > > Best regards, > > Bert > > > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the > draft. How to deal with this? > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:m= music-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: 27 February 2012 04:53 > > To: Gonzalo Camarillo; Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > > > Hi, > > > > As a directorate member, I am willing to co-author such draft, should a > decision to write one be taken. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:m= music-bounces@ietf.org] On Behalf > Of Gonzalo Camarillo > > Sent: 23. helmikuuta 2012 19:31 > > To: Mary Barnes > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > I agree. > > > > Gonzalo > > > > On 23/02/2012 7:06 PM, Mary Barnes wrote: > >> I would think that in order for the document to have integrity that at > >> least one of the directorate members should at least be a co-author. > >> Otherwise, I see a lot more stuff falling through the cracks and > >> needing to be resolved during WGLC and later, which usually isn't a > >> good thing. The SIP Hitchhiker's guide provides a good example in > >> that the author was also a primary contributor to RFC3261, etc. > >> > >> Mary. > >> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > >> > >> >> > >> wrote: > >> > >> Hi Mary, > >> > >> yes, the members of the SDP directorate would need to review such > a > >> guide. However, the fact that they agreed to be members of the > >> directorate does not mean they will necessarily have cycles to > >> significantly contribute to the creation of the guide. We need to > make > >> sure we have enough energy around this effort in order to start > it. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: > >> > I think this is a good idea. I would think the experts that > can > >> > contribute (and should review) can be found in the new SDP > >> > directorate: > >> > http://www.ietf.org/iesg/directorate/sdp.html > >> > BTW, it would be nice to have a link to this page on the MMUSI= C > WG > >> wiki: > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > >> > > >> > As far as whether to publish, I think it would be a good idea > to > >> > complete publication as IMHO that improves the integrity of th= e > >> > information - i.e., more eyes review a published RFC than a > draft. > >> > It could later be updated to reflect more recent RFCs OR a > "More of > >> > Hitchhikers Guide" could be published. > >> > > >> > Thanks, > >> > Mary. > >> > > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > >> > > >> >> wrote: > >> >> Hi Miguel, Andrew, all, > >> >> > >> >> Sounds like a good idea. I would be happy to volunteer to pla= y > a > >> central role in it (i.e. be the editor, create the initial draft, > >> ...), but I would need support from other experts too. > >> >> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to > SIP" > >> has become an RFC (5411). That means that it has been frozen, and > to > >> add new info new individual or WG drafts are needed. > >> >> > >> >> Would this be the same approach for SDP? Currently, there are > >> already quite some new drafts that extend SDP. How will future > >> extensions be handled? Maybe it would be good to make it a > permanent > >> WG draft, which is updated every now and then. > >> >> > >> >> Best regards, > >> >> Bert > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: mmusic-bounces@ietf.org= > > >> [mailto:mmusic-bounces@ietf.org>] > On > >> Behalf Of Miguel A. Garcia > >> >> Sent: 14 February 2012 15:42 > >> >> To: Andrew Allen > >> >> Cc: mmusic@ietf.org> > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? > >> >> > >> >> Sounds good to me too. If someone wants to start such draft..= . > >> >> > >> >> /Miguel > >> >> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: > >> >>> > >> >>> What about considering a hitchhikers guide to SDP similar to > >> what was done for SIP? > >> >>> > >> >>> One umbrella document that points the reader to all the SDP > >> capabilities available that they might want to take advantage of. > >> >>> > >> >>> Just a suggestion. > >> >>> > >> >>> Andrew > >> >>> > >> >>> ----- Original Message ----- > >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com<= mailto:Miguel.A.Garcia@ericsson.com> > >> >] > >> >>> Sent: Saturday, January 28, 2012 06:23 AM > >> >>> To: mmusic>> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >> >>> > >> >>> > >> >>> > >> >>> Hi all, > >> >>> > >> >>> You know we are revising RFC 4566. So far, the effort has > been > >> in bug fixing. > >> >>> > >> >>> The first SDP version was published as RFC 2327 in 1998 > (i.e., > >> 14 years > >> >>> ago), and was then revised as RFC 4566 in 2006. > >> >>> > >> >>> Lots of things have happened since then. We have SDP offer > answer, > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, > comeida, > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in > the pipe. > >> >>> > >> >>> From the point of view of a reader who takes 4566 (or its > current > >> >>> 4566bis incarnation), I think it will be difficult for her o= r > him to > >> >>> understand a protocol that ignores those other extensions. > For > >> example, I > >> >>> recently post another e-mail where there is an apparent > >> contradiction > >> >>> between 4566 and ICE (see > >> >>> http://www.ietf.org/mail- > archive/web/mmusic/current/msg09089.html ). > >> >>> > >> >>> So, I was wondering if time has come to make not a bug > correction in > >> >>> 4566bis, but also put that RFC in context with the other > >> extensions that > >> >>> exist. This may include: > >> >>> > >> >>> - Add minor extensions to the core document, similarly to > what > >> we did > >> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know > which > >> of these > >> >>> extensions make sense to include, this would be an exercise > to > >> do, but > >> >>> let me give you one potential example: RFC 4574, the SDP > "label" > >> >>> attribute is a 6 pages RFC. > >> >>> > >> >>> - Adding references to extensions, when it makes sense. For > >> example, ICE > >> >>> should be referred somewhere (see my previous post regarding > the "o" > >> >>> line). I guess capneg could be also mentioned, perhaps > others. > >> >>> > >> >>> I know this is a bigger effort than anticipated, but the > result > >> could > >> >>> really help newcomers to this world. > >> >>> > >> >>> Now, it is your turn to express your opinions. Please do it. > >> >>> > >> >>> /Miguel > >> >> > >> >> -- > >> >> Miguel A. Garcia > >> >> +34-91-339-3608 > >> >> Ericsson Spain > >> >> _______________________________________________ > >> >> 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 > >> > _______________________________________________ > >> > 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 > > _______________________________________________ > > 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 > > > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_DDF000BCD4FA4F43909CD45448BAE04E0AD7892DCDUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If the goal is to limit to SIP or even IMS=20 environments then the title of the document should reflect that.=20
 
SDP is used in many non-SIP environments.
 
Mike
 
From:=20 mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 Gonzalo Salgueiro
Sent: Wednesday, March 07, 2012 7:19=20 AM
To: Mary Barnes
Cc: DRAGE, Keith (Keith);=20 mmusic@ietf.org
Subject: Re: [MMUSIC] Hitchhiker's guide to=20 SDP

I agree. Limiting it to SIP seems sufficiently Herculean for one= =20 document IMO.

Gonzalo

On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote:
Per Albrecht response, I think we would open a ca= n of=20 worms if we want this to be a general guide on SDP for all usages.  = I=20 would prefer to keep it limited to SIP at this time, which I think is no = small=20 task. Then another document, modeled after this one,  could cover ot= her=20 usages if the interested parties think it would be helpful. 

Mary. 

On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Ke= ith)=20 <keith.drage@alcatel-lucent= .com>=20 wrote:
I notice RFC 3264 is mentioned as one of the core=20 specifications.

This only becomes core when SDP is used in the=20 context of SIP.

If I am a Megaco / H.248 user of SDP I suspect=20 therefore I come up with a different viewpoint of what is core and what= is=20 not.

We may need to address these different viewpoints, unless y= ou=20 want to make a guide that is entirely focused on SIP=20 usage.

Regards

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [ma= ilto:mmusic-bounces@ietf.org] On= =20 Behalf
> Of Miguel A. Garcia
> Sent: 07 March 2012=20 10:56
> To: Bert Greevenbosch
> Cc: mmusic@ietf.org
> Subject: Re= :=20 [MMUSIC] Hitchhiker's guide to SDP
>
> Bert,
>
> Here is another document wit= h the=20 same purpose. You can use it for
> inspiration. This is a bit mor= e=20 complex document, because it has to deal
> with several different= =20 protocols, rather than only one.
>
> http://tools.ietf.org/html/draft-ietf-opsawg-management= -stds
>
>=20 The other document that you need to consult is the IANA SDP=20 Parameters
> registry at:
>
> http://www.iana.org/assignments/sdp-parameters/sdp-para= meters.xml
>
>=20 This contains a list of all the SDP extensions, and they all should=20 be
> listed in the hitchhiker's guide.
>
>=20 /Miguel
>
> On 07/03/2012 3:54, Bert Greevenbosch wrote:>=20 > Hi all,
> >
> > On Monday, I have uploaded a v00= =20 draft for "Hitchhiker's Guide to SDP".
> It is based on the=20 "Hitchhiker's Guide to SIP" (RFC 5411). I have copied
> most init= ial=20 text from there, and in addition included an initial list of
> RF= Cs /=20 drafts that seem relevant.
> >
> > https://datatracker.ietf.org/doc/draft-greevenbosch-hit= chhikersguide-
>=20 sdp/
> >
> > If the group is happy with this approach= , I=20 will be happy to maintain an
> editor's role, and write more text= .=20 Obviously other people's input will be
> highly appreciated, and= =20 indeed is needed.
> >
> > I look forward to your=20 comments.
> >
> > Best regards,
> > Bert
= >=20 >
> > P.S. Unfortunately, I forgot to include "mmusic" in t= he=20 name of the
> draft. How to deal with this?
> >
>= =20 >
> >
> > -----Original Message-----
> > = From:=20 mmusic-bounces@ietf.org= =20 [mailto:mmusic-bounces@ietf.org] On= =20 Behalf
> Of Christer Holmberg
> > Sent: 27 February 2012= =20 04:53
> > To: Gonzalo Camarillo; Mary Barnes
> > Cc: = mmusic@ietf.org
> > Subjec= t: Re:=20 [MMUSIC] Hitchhiker's guide to SDP
> >
> >
> &g= t;=20 Hi,
> >
> > As a directorate member, I am willing to= =20 co-author such draft, should a
> decision to write one be=20 taken.
> >
> > Regards,
> >
> >=20 Christer
> >
> > -----Original Message-----
> &= gt;=20 From: mmusic-bounces@ietf.or= g=20 [mailto:mmusic-bounces@ietf.org] On= =20 Behalf
> Of Gonzalo Camarillo
> > Sent: 23. helmikuuta 2= 012=20 19:31
> > To: Mary Barnes
> > Cc: mmusic@ietf.org
> > Subjec= t: Re:=20 [MMUSIC] Hitchhiker's guide to SDP
> >
> > I=20 agree.
> >
> > Gonzalo
> >
> > On=20 23/02/2012 7:06 PM, Mary Barnes wrote:
> >> I would think t= hat=20 in order for the document to have integrity that at
> >> le= ast=20 one of the directorate members should at least be a co-author.
>= =20 >>   Otherwise, I see a lot more stuff falling through the c= racks=20 and
> >> needing to be resolved during WGLC and later, whic= h=20 usually isn't a
> >> good thing.  The SIP Hitchhiker's= =20 guide provides a good example in
> >> that the author was a= lso a=20 primary contributor to RFC3261, etc.
> >>
> >>= =20 Mary.
> >>
> >> On Thu, Feb 23, 2012 at 6:30 AM= ,=20 Gonzalo Camarillo
> >> <Gonzalo.Camarillo@ericss= on.com
>=20 >> <mailto:Gonzalo.Camarillo@ericss= on.com>>
>=20 >> wrote:
> >>
> >>      H= i=20 Mary,
> >>
> >>      yes, the me= mbers=20 of the SDP directorate would need to review such
> a
> >= >=20      guide. However, the fact that they agreed to be mem= bers=20 of the
> >>      directorate does not mean t= hey=20 will necessarily have cycles to
> >>    =20  significantly contribute to the creation of the guide. We need=20 to
> make
> >>      sure we have enoug= h=20 energy around this effort in order to start
> it.
>=20 >>
> >>      Cheers,
>=20 >>
> >>      Gonzalo
>=20 >>
> >>      On 15/02/2012 7:14 PM, Ma= ry=20 Barnes wrote:
> >>      >  I think t= his=20 is a good idea.  I would think the experts that
> can
>= ;=20 >>      >  contribute (and should review) = can=20 be found in the new SDP
> >>      >=20  directorate:
> >>      >  http://www.ietf.org/iesg/directorate/sdp.html
&g= t;=20 >>      >  BTW, it would be nice to have a= link=20 to this page on the MMUSIC
> WG
> >>    =20  wiki:
> >>      >  http://trac.tools.ietf.org/wg/mmusic/trac/wiki
&= gt;=20 >>      >
> >>      = >=20  As far as whether to publish, I think it would be a good idea
= >=20 to
> >>      >  complete publication= as=20 IMHO that improves the integrity of the
> >>    = =20  >  information - i.e., more eyes review a published RFC t= han=20 a
> draft.
> >>      >  It cou= ld=20 later be updated to reflect more recent RFCs OR a
> "More of
&= gt;=20 >>      >  Hitchhikers Guide" could be=20 published.
> >>      >
> >> &= nbsp;=20    >  Thanks,
> >>      &g= t;=20  Mary.
> >>      >
> >>= =20      >  On Wed, Feb 15, 2012 at 12:29 AM, Bert=20 Greevenbosch
> >>      >  <Bert.Greevenbosch@huawei.c= om
>=20 >>      <mailto:Bert.Greevenbosch@huawei.c= om>>=20  wrote:
> >>      >>  Hi Mig= uel,=20 Andrew, all,
> >>      >>
> >= >=20      >>  Sounds like a good idea. I would be = happy=20 to volunteer to play
> a
> >>      cen= tral=20 role in it (i.e. be the editor, create the initial draft,
> >&= gt;=20      ...), but I would need support from other experts=20 too.
> >>      >>
> >> &nb= sp;=20    >>  As for practicalities, I see that the=20 "Hitchhiker's Guide to
> SIP"
> >>     &nbs= p;has=20 become an RFC (5411). That means that it has been frozen, and
>=20 to
> >>      add new info new individual or = WG=20 drafts are needed.
> >>      >>
>= ;=20 >>      >>  Would this be the same appr= oach=20 for SDP? Currently, there are
> >>      alre= ady=20 quite some new drafts that extend SDP. How will future
> >>= =20      extensions be handled? Maybe it would be good to ma= ke it=20 a
> permanent
> >>      WG draft, whic= h is=20 updated every now and then.
> >>    =20  >>
> >>      >>  Best= =20 regards,
> >>      >>  Bert
&g= t;=20 >>      >>
> >>    =20  >>
> >>      >>=20  -----Original Message-----
> >>    =20  >>  From: mmusic-bounces@ietf.org<= mailto:mmusic-bounces@ietf.org>=
>=20 >>      [mailto:mmusic-bounces@ietf.org<= mailto:mmusic-bounces@ietf.org>= ]
>=20 On
> >>      Behalf Of Miguel A. Garcia
&= gt;=20 >>      >>  Sent: 14 February 2012=20 15:42
> >>      >>  To: Andrew=20 Allen
> >>      >>  Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>= ;=20      >>  Subject: Re: [MMUSIC] Do we need to= =20 update in time 4566bis?
> >>    =20  >>
> >>      >>  Soun= ds=20 good to me too. If someone wants to start such draft...
> >>= ;=20      >>
> >>      >&= gt;=20  /Miguel
> >>      >>
> >= ;>=20      >>  On 13/02/2012 23:15, Andrew Allen=20 wrote:
> >>      >>>
> >&g= t;=20      >>>  What about considering a hitchhi= kers=20 guide to SDP similar to
> >>      what was d= one=20 for SIP?
> >>      >>>
> >= >=20      >>>  One umbrella document that point= s the=20 reader to all the SDP
> >>      capabilities= =20 available that they might want to take advantage of.
> >> &= nbsp;=20    >>>
> >>      >>= >=20  Just a suggestion.
> >>    =20  >>>
> >>      >>>=20  Andrew
> >>      >>>
>= =20 >>      >>>  ----- Original Message= =20 -----
> >>      >>>  From: Mig= uel=20 A. Garcia [mailto:Miguel.A.Garcia@ericsson.c= om
>=20 >>      <mailto:Miguel.A.Garcia@ericsson.c= om>]
>=20 >>      >>>  Sent: Saturday, January= 28,=20 2012 06:23 AM
> >>      >>>  T= o:=20 mmusic<mmusic@ietf.org<mai= lto:mmusic@ietf.org>>
> >= ;>=20      >>>  Subject: [MMUSIC] Do we need to= =20 update in time 4566bis?
> >>    =20  >>>
> >>      >>>=20  <as an individual>
> >>    =20  >>>
> >>      >>>=20  Hi all,
> >>      >>>
>= =20 >>      >>>  You know we are revisin= g RFC=20 4566. So far, the effort has
> been
> >>    = ;=20  in bug fixing.
> >>    =20  >>>
> >>      >>>=20  The first SDP version was published as RFC 2327 in 1998
>=20 (i.e.,
> >>      14 years
> >> &= nbsp;=20    >>>  ago), and was then revised as RFC 4566 = in=20 2006.
> >>      >>>
> >>= ;=20      >>>  Lots of things have happened sin= ce=20 then. We have SDP offer
> answer,
> >>    = =20  >>>  Grouping, QoS, ATM, Bandwidth modifiers, TCP m= edia,=20 SDES,
> comeida,
> >>      >>>= ;=20  labels, BFCP, FEC, ICE, CapNeg, and many other that are in
>= ; the=20 pipe.
> >>      >>>
> >>= ;=20      >>>     From the point of view o= f a=20 reader who takes 4566 (or its
> current
> >>   &= nbsp;=20  >>>  4566bis incarnation), I think it will be diffi= cult=20 for her or
> him to
> >>      >>= >=20  understand a protocol that ignores those other extensions.
>= ;=20 For
> >>      example, I
> >> &n= bsp;=20    >>>  recently post another e-mail where ther= e is=20 an apparent
> >>      contradiction
>= =20 >>      >>>  between 4566 and ICE=20 (see
> >>      >>>  http://www.ietf.org/mail-
>=20 archive/web/mmusic/current/msg09089.html ).
> >>   &nb= sp;=20  >>>
> >>      >>>=20  So, I was wondering if time has come to make not a bug
>=20 correction in
> >>      >>>=20  4566bis, but also put that RFC in context with the other
>= =20 >>      extensions that
> >>   &n= bsp;=20  >>>  exist. This may include:
> >> &nbs= p;=20    >>>
> >>      >>= >=20  - Add minor extensions to the core document, similarly to
>= =20 what
> >>      we did
> >>  = ;=20    >>>  with IPv6 support (i.e., 4566 =3D 2327 = +=20 3266). I don't know
> which
> >>      = of=20 these
> >>      >>>  extension= s=20 make sense to include, this would be an exercise
> to
> >= ;>=20      do, but
> >>    =20  >>>  let me give you one potential example: RFC 457= 4,=20 the SDP
> "label"
> >>      >>&g= t;=20  attribute is a 6 pages RFC.
> >>    =20  >>>
> >>      >>> &n= bsp;-=20 Adding references to extensions, when it makes sense. For
> >&= gt;=20      example, ICE
> >>    =20  >>>  should be referred somewhere (see my previous = post=20 regarding
> the "o"
> >>      >>= >=20  line). I guess capneg could be also mentioned, perhaps
>=20 others.
> >>      >>>
> >&= gt;=20      >>>  I know this is a bigger effort t= han=20 anticipated, but the
> result
> >>    =20  could
> >>      >>>  rea= lly=20 help newcomers to this world.
> >>    =20  >>>
> >>      >>>=20  Now, it is your turn to express your opinions. Please do it.
&= gt;=20 >>      >>>
> >>    = ;=20  >>>  /Miguel
> >>    =20  >>
> >>      >>=20  --
> >>      >>  Miguel A.= =20 Garcia
> >>      >>  +34-91-339-3608<tel:%2B34-91-339-3608>=
>=20 >>      >>  Ericsson Spain
> >= >=20      >>=20  _______________________________________________
> >>= =20      >>  mmusic mailing list
> >>= =20      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>= ;=20      >>  https://www.ietf.org/mailman/listinfo/mmusic
>= ;=20 >>      >>=20  _______________________________________________
> >>= =20      >>  mmusic mailing list
> >>= =20      >>  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>= ;=20      >>  https://www.ietf.org/mailman/listinfo/mmusic
>= ;=20 >>      >=20  _______________________________________________
> >>= =20      >  mmusic mailing list
> >> &nb= sp;=20    >  mmusic@ietf.org<mailto:mmusic@ietf.org>
> >>= ;=20      >  https://www.ietf.org/mailman/listinfo/mmusic
>= ;=20 >>      >
> >>
> >>
= >=20 >
> > _______________________________________________
&g= t;=20 > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>= ; >=20 _______________________________________________
> > mmusic mai= ling=20 list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>= ; >=20 _______________________________________________
> > mmusic mai= ling=20 list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>= ;=20 >
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
&g= t;=20 _______________________________________________
> mmusic mailing= =20 list
> mmusic@ietf.org
= > https://www.ietf.org/mailman/listinfo/mmusic
___= ____________________________________________
mmusic=20 mailing list
mmusic@ietf.org<= BR>https://www.ietf.org/mailman/listinfo/mmusic

_____________________________________= __________
mmusic=20 mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

--_000_DDF000BCD4FA4F43909CD45448BAE04E0AD7892DCDUSNAVSXCHMBSC_-- From pkyzivat@alum.mit.edu Wed Mar 7 13:10:30 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 874FA21E805E for ; Wed, 7 Mar 2012 13:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 6tnqXDG93J7K for ; Wed, 7 Mar 2012 13:10:28 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7911E8086 for ; Wed, 7 Mar 2012 13:10:28 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id il4K1i00A1HzFnQ5DlAUgZ; Wed, 07 Mar 2012 21:10:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id ilAU1i00R07duvL3alAUlc; Wed, 07 Mar 2012 21:10:28 +0000 Message-ID: <4F57CEC3.6040002@alum.mit.edu> Date: Wed, 07 Mar 2012 16:10:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Hitchhiker's guide to SIP SDP 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, 07 Mar 2012 21:10:30 -0000 On 3/7/12 12:59 PM, Severa, Michael J (Mike) wrote: > If the goal is to limit to SIP or even IMS environments then the title > of the document should reflect that. > SDP is used in many non-SIP environments. I think you can be confident that it won't be limited to the IMS environment. (Unless the IMS community chooses to submit such a document.) Thanks, Paul > Mike > ------------------------------------------------------------------------ > *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Gonzalo Salgueiro > *Sent:* Wednesday, March 07, 2012 7:19 AM > *To:* Mary Barnes > *Cc:* DRAGE, Keith (Keith); mmusic@ietf.org > *Subject:* Re: [MMUSIC] Hitchhiker's guide to SDP > > I agree. Limiting it to SIP seems sufficiently Herculean for one > document IMO. > > Gonzalo > > On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote: > >> Per Albrecht response, I think we would open a can of worms if we want >> this to be a general guide on SDP for all usages. I would prefer to >> keep it limited to SIP at this time, which I think is no small task. >> Then another document, modeled after this one, could cover other >> usages if the interested parties think it would be helpful. >> >> Mary. >> >> On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) >> > > wrote: >> >> I notice RFC 3264 is mentioned as one of the core specifications. >> >> This only becomes core when SDP is used in the context of SIP. >> >> If I am a Megaco / H.248 user of SDP I suspect therefore I come up >> with a different viewpoint of what is core and what is not. >> >> We may need to address these different viewpoints, unless you want >> to make a guide that is entirely focused on SIP usage. >> >> Regards >> >> Keith >> >> > -----Original Message----- >> > From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org ] >> On Behalf >> > Of Miguel A. Garcia >> > Sent: 07 March 2012 10:56 >> > To: Bert Greevenbosch >> > Cc: mmusic@ietf.org >> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> > >> > Bert, >> > >> > Here is another document with the same purpose. You can use it for >> > inspiration. This is a bit more complex document, because it has >> to deal >> > with several different protocols, rather than only one. >> > >> > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >> > >> > The other document that you need to consult is the IANA SDP >> Parameters >> > registry at: >> > >> > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >> > >> > This contains a list of all the SDP extensions, and they all >> should be >> > listed in the hitchhiker's guide. >> > >> > /Miguel >> > >> > On 07/03/2012 3:54, Bert Greevenbosch wrote: >> > > Hi all, >> > > >> > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide >> to SDP". >> > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I >> have copied >> > most initial text from there, and in addition included an >> initial list of >> > RFCs / drafts that seem relevant. >> > > >> > > >> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- >> > sdp/ >> > > >> > > If the group is happy with this approach, I will be happy to >> maintain an >> > editor's role, and write more text. Obviously other people's >> input will be >> > highly appreciated, and indeed is needed. >> > > >> > > I look forward to your comments. >> > > >> > > Best regards, >> > > Bert >> > > >> > > P.S. Unfortunately, I forgot to include "mmusic" in the name >> of the >> > draft. How to deal with this? >> > > >> > > >> > > >> > > -----Original Message----- >> > > From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org ] >> On Behalf >> > Of Christer Holmberg >> > > Sent: 27 February 2012 04:53 >> > > To: Gonzalo Camarillo; Mary Barnes >> > > Cc: mmusic@ietf.org >> > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> > > >> > > >> > > Hi, >> > > >> > > As a directorate member, I am willing to co-author such draft, >> should a >> > decision to write one be taken. >> > > >> > > Regards, >> > > >> > > Christer >> > > >> > > -----Original Message----- >> > > From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org ] >> On Behalf >> > Of Gonzalo Camarillo >> > > Sent: 23. helmikuuta 2012 19:31 >> > > To: Mary Barnes >> > > Cc: mmusic@ietf.org >> > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> > > >> > > I agree. >> > > >> > > Gonzalo >> > > >> > > On 23/02/2012 7:06 PM, Mary Barnes wrote: >> > >> I would think that in order for the document to have >> integrity that at >> > >> least one of the directorate members should at least be a >> co-author. >> > >> Otherwise, I see a lot more stuff falling through the cracks and >> > >> needing to be resolved during WGLC and later, which usually >> isn't a >> > >> good thing. The SIP Hitchhiker's guide provides a good example in >> > >> that the author was also a primary contributor to RFC3261, etc. >> > >> >> > >> Mary. >> > >> >> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >> > >> > >> > >> > >> >> > >> wrote: >> > >> >> > >> Hi Mary, >> > >> >> > >> yes, the members of the SDP directorate would need to review such >> > a >> > >> guide. However, the fact that they agreed to be members of the >> > >> directorate does not mean they will necessarily have cycles to >> > >> significantly contribute to the creation of the guide. We need to >> > make >> > >> sure we have enough energy around this effort in order to start >> > it. >> > >> >> > >> Cheers, >> > >> >> > >> Gonzalo >> > >> >> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: >> > >> > I think this is a good idea. I would think the experts that >> > can >> > >> > contribute (and should review) can be found in the new SDP >> > >> > directorate: >> > >> > http://www.ietf.org/iesg/directorate/sdp.html >> > >> > BTW, it would be nice to have a link to this page on the MMUSIC >> > WG >> > >> wiki: >> > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >> > >> > >> > >> > As far as whether to publish, I think it would be a good idea >> > to >> > >> > complete publication as IMHO that improves the integrity of the >> > >> > information - i.e., more eyes review a published RFC than a >> > draft. >> > >> > It could later be updated to reflect more recent RFCs OR a >> > "More of >> > >> > Hitchhikers Guide" could be published. >> > >> > >> > >> > Thanks, >> > >> > Mary. >> > >> > >> > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >> > >> > > >> > >> > >> wrote: >> > >> >> Hi Miguel, Andrew, all, >> > >> >> >> > >> >> Sounds like a good idea. I would be happy to volunteer to play >> > a >> > >> central role in it (i.e. be the editor, create the initial draft, >> > >> ...), but I would need support from other experts too. >> > >> >> >> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to >> > SIP" >> > >> has become an RFC (5411). That means that it has been frozen, and >> > to >> > >> add new info new individual or WG drafts are needed. >> > >> >> >> > >> >> Would this be the same approach for SDP? Currently, there are >> > >> already quite some new drafts that extend SDP. How will future >> > >> extensions be handled? Maybe it would be good to make it a >> > permanent >> > >> WG draft, which is updated every now and then. >> > >> >> >> > >> >> Best regards, >> > >> >> Bert >> > >> >> >> > >> >> >> > >> >> -----Original Message----- >> > >> >> From: mmusic-bounces@ietf.org >> > > >> > >> [mailto:mmusic-bounces@ietf.org >> > >] >> > On >> > >> Behalf Of Miguel A. Garcia >> > >> >> Sent: 14 February 2012 15:42 >> > >> >> To: Andrew Allen >> > >> >> Cc: mmusic@ietf.org >> > > >> > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >> > >> >> >> > >> >> Sounds good to me too. If someone wants to start such draft... >> > >> >> >> > >> >> /Miguel >> > >> >> >> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: >> > >> >>> >> > >> >>> What about considering a hitchhikers guide to SDP similar to >> > >> what was done for SIP? >> > >> >>> >> > >> >>> One umbrella document that points the reader to all the SDP >> > >> capabilities available that they might want to take advantage of. >> > >> >>> >> > >> >>> Just a suggestion. >> > >> >>> >> > >> >>> Andrew >> > >> >>> >> > >> >>> ----- Original Message ----- >> > >> >>> From: Miguel A. Garcia >> [mailto:Miguel.A.Garcia@ericsson.com >> >> > >> > >] >> > >> >>> Sent: Saturday, January 28, 2012 06:23 AM >> > >> >>> To: mmusic> > >> >> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> Hi all, >> > >> >>> >> > >> >>> You know we are revising RFC 4566. So far, the effort has >> > been >> > >> in bug fixing. >> > >> >>> >> > >> >>> The first SDP version was published as RFC 2327 in 1998 >> > (i.e., >> > >> 14 years >> > >> >>> ago), and was then revised as RFC 4566 in 2006. >> > >> >>> >> > >> >>> Lots of things have happened since then. We have SDP offer >> > answer, >> > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, >> > comeida, >> > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in >> > the pipe. >> > >> >>> >> > >> >>> From the point of view of a reader who takes 4566 (or its >> > current >> > >> >>> 4566bis incarnation), I think it will be difficult for her or >> > him to >> > >> >>> understand a protocol that ignores those other extensions. >> > For >> > >> example, I >> > >> >>> recently post another e-mail where there is an apparent >> > >> contradiction >> > >> >>> between 4566 and ICE (see >> > >> >>> http://www.ietf.org/mail- >> > archive/web/mmusic/current/msg09089.html ). >> > >> >>> >> > >> >>> So, I was wondering if time has come to make not a bug >> > correction in >> > >> >>> 4566bis, but also put that RFC in context with the other >> > >> extensions that >> > >> >>> exist. This may include: >> > >> >>> >> > >> >>> - Add minor extensions to the core document, similarly to >> > what >> > >> we did >> > >> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know >> > which >> > >> of these >> > >> >>> extensions make sense to include, this would be an exercise >> > to >> > >> do, but >> > >> >>> let me give you one potential example: RFC 4574, the SDP >> > "label" >> > >> >>> attribute is a 6 pages RFC. >> > >> >>> >> > >> >>> - Adding references to extensions, when it makes sense. For >> > >> example, ICE >> > >> >>> should be referred somewhere (see my previous post regarding >> > the "o" >> > >> >>> line). I guess capneg could be also mentioned, perhaps >> > others. >> > >> >>> >> > >> >>> I know this is a bigger effort than anticipated, but the >> > result >> > >> could >> > >> >>> really help newcomers to this world. >> > >> >>> >> > >> >>> Now, it is your turn to express your opinions. Please do it. >> > >> >>> >> > >> >>> /Miguel >> > >> >> >> > >> >> -- >> > >> >> Miguel A. Garcia >> > >> >> +34-91-339-3608 >> > >> >> Ericsson Spain >> > >> >> _______________________________________________ >> > >> >> 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 >> > >> > _______________________________________________ >> > >> > 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 >> > > _______________________________________________ >> > > 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 >> > > >> > >> > -- >> > Miguel A. Garcia >> > +34-91-339-3608 >> > Ericsson Spain >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> 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 fandreas@cisco.com Wed Mar 7 18:22:32 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 1E54C21F8528 for ; Wed, 7 Mar 2012 18:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.866, 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 hLVv3TlpSDoD for ; Wed, 7 Mar 2012 18:22:30 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A76C821F8527 for ; Wed, 7 Mar 2012 18:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=3250; q=dns/txt; s=iport; t=1331173350; x=1332382950; h=message-id:date:from:mime-version:to:subject; bh=1YvhpAVgFLP6HXz0YcvNI5sWmNDycpwtxkk33iSAoRo=; b=cMCxM0QP2BX6gnEz6yY0wduzYj+5ZnOdjNEF1WVrQGY8/mh20J1I7Fb6 NWhJzQKAD/SD/dCtYSH6zBhuvhC5ifmSbR0Xe6BWWspZIHq5oLOnYCRwN E+kGYArHTY1BvEBjAr7NhDJwwtKz938H/DtVlW0xL7yd25SpUvAnz3wiQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHYXWE+tJXHA/2dsb2JhbABDgkWyZYEHgiMBZSAdFhgDAgECAUsNCAEBBRmHZguZOoEnAZ8LiimGRgSIUoxvkBeDAYE+ X-IronPort-AV: E=Sophos;i="4.73,550,1325462400"; d="scan'208,217";a="64666130" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 08 Mar 2012 02:22:30 +0000 Received: from fandreas-mac.local (rtp-fandreas-8711.cisco.com [10.117.7.82]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q282MTCA011234 for ; Thu, 8 Mar 2012 02:22:29 GMT Message-ID: <4F5817E6.6090008@cisco.com> Date: Wed, 07 Mar 2012 21:22:30 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------070107050105060306040604" Subject: [MMUSIC] Proposal to adopt draft-garcia-mmusic-sdp-miscellaneous-caps as WG item 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, 08 Mar 2012 02:22:32 -0000 This is a multi-part message in MIME format. --------------070107050105060306040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings One of the MMUSIC milestones is to "Submit SDP extensions for Media Titles and Media Bandwidth Capability Negotiations as Proposed Standard" by June 2012. We currently have draft-garcia-mmusic-sdp-miscellaneous-caps as an individual draft covering this milestone and the proposal is to adopt the draft as a WG item. It should be noted that: - 3GPP has a dependency on this draft and has asked if we can complete it soon (see http://www.ietf.org/mail-archive/web/mmusic/current/msg09187.html) - As presented and discussed in Taipei, the draft also covers negotiation of connection information ("c=") to allow alternative connection types. A primary use case for this is another of our WG items (namely "SDP extensions for audio media streams over Circuit- Switched bearers") where you may need to offer circuit-switched and IP based bearers as alternatives. Please let the chairs know if you have any concerns with adopting the above draft as a WG item. Thanks -- Flemming (MMUSIC co-chair) --------------070107050105060306040604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

One of the MMUSIC milestones is to "Submit SDP extensions for Media Titles and Media Bandwidth Capability Negotiations as Proposed Standard" by June 2012.

We currently have draft-garcia-mmusic-sdp-miscellaneous-caps as an individual draft covering this milestone and the proposal is to adopt the draft as a WG item.

It should be noted that:
- 3GPP has a dependency on this draft and has asked if we can complete it soon (see http://www.ietf.org/mail-archive/web/mmusic/current/msg09187.html)
- As presented and discussed in Taipei, the draft also covers negotiation of connection information ("c=") to allow alternative connection types. A primary use case for this is another of our WG items (namely "SDP extensions for audio media streams over Circuit- Switched bearers") where you may need to offer circuit-switched and IP based bearers as alternatives.

Please let the chairs know if you have any concerns with adopting the above draft as a WG item.

Thanks

-- Flemming (MMUSIC co-chair)








--------------070107050105060306040604-- From Bert.Greevenbosch@huawei.com Wed Mar 7 18:25:54 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 465BF21E8020 for ; Wed, 7 Mar 2012 18:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 q+NWaNSPywTT for ; Wed, 7 Mar 2012 18:25:52 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 58CF121E8029 for ; Wed, 7 Mar 2012 18:25:52 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00NM6O0P3Q@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 08 Mar 2012 10:24:25 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00L50O0O11@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 08 Mar 2012 10:24:25 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH91478; Thu, 08 Mar 2012 10:24:24 +0800 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 10:23:51 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.86]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 10:24:18 +0800 Date: Thu, 08 Mar 2012 02:24:17 +0000 From: Bert Greevenbosch In-reply-to: <4F57CEC3.6040002@alum.mit.edu> X-Originating-IP: [10.70.109.135] To: Paul Kyzivat , "mmusic@ietf.org" Message-id: <46A1DF3F04371240B504290A071B4DB62451164F@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Hitchhiker's guide to SIP SDP Thread-index: AQHM/IwmRzsBgCQQOkO8nzmCeEaz+5ZezjuAgADWL/A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <4F57CEC3.6040002@alum.mit.edu> Subject: Re: [MMUSIC] Hitchhiker's guide to SIP SDP 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, 08 Mar 2012 02:25:54 -0000 Hi all, Interesting discussion. When I created the new draft, I took the SIP guide and narrowed it down by pruning all SIP specific references. I then added references specific to SDP. So the current version of the draft is a guide to "core SDP", but not to dependent technologies. That's one approach, but indeed another would be to include dependent technologies like SIP and Megaco/H.248. A third approach could be to keep the core documents, and then add some describing sections for the dependent technologies, but without discussing each of the documents that make up those technologies deeply. Best regards, Bert -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 08 March 2012 05:10 To: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SIP SDP On 3/7/12 12:59 PM, Severa, Michael J (Mike) wrote: > If the goal is to limit to SIP or even IMS environments then the title > of the document should reflect that. > SDP is used in many non-SIP environments. I think you can be confident that it won't be limited to the IMS environment. (Unless the IMS community chooses to submit such a document.) Thanks, Paul > Mike > ------------------------------------------------------------------------ > *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Gonzalo Salgueiro > *Sent:* Wednesday, March 07, 2012 7:19 AM > *To:* Mary Barnes > *Cc:* DRAGE, Keith (Keith); mmusic@ietf.org > *Subject:* Re: [MMUSIC] Hitchhiker's guide to SDP > > I agree. Limiting it to SIP seems sufficiently Herculean for one > document IMO. > > Gonzalo > > On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote: > >> Per Albrecht response, I think we would open a can of worms if we want >> this to be a general guide on SDP for all usages. I would prefer to >> keep it limited to SIP at this time, which I think is no small task. >> Then another document, modeled after this one, could cover other >> usages if the interested parties think it would be helpful. >> >> Mary. >> >> On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) >> > > wrote: >> >> I notice RFC 3264 is mentioned as one of the core specifications. >> >> This only becomes core when SDP is used in the context of SIP. >> >> If I am a Megaco / H.248 user of SDP I suspect therefore I come up >> with a different viewpoint of what is core and what is not. >> >> We may need to address these different viewpoints, unless you want >> to make a guide that is entirely focused on SIP usage. >> >> Regards >> >> Keith >> >> > -----Original Message----- >> > From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org ] >> On Behalf >> > Of Miguel A. Garcia >> > Sent: 07 March 2012 10:56 >> > To: Bert Greevenbosch >> > Cc: mmusic@ietf.org >> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> > >> > Bert, >> > >> > Here is another document with the same purpose. You can use it for >> > inspiration. This is a bit more complex document, because it has >> to deal >> > with several different protocols, rather than only one. >> > >> > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >> > >> > The other document that you need to consult is the IANA SDP >> Parameters >> > registry at: >> > >> > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >> > >> > This contains a list of all the SDP extensions, and they all >> should be >> > listed in the hitchhiker's guide. >> > >> > /Miguel >> > >> > On 07/03/2012 3:54, Bert Greevenbosch wrote: >> > > Hi all, >> > > >> > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide >> to SDP". >> > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I >> have copied >> > most initial text from there, and in addition included an >> initial list of >> > RFCs / drafts that seem relevant. >> > > >> > > >> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- >> > sdp/ >> > > >> > > If the group is happy with this approach, I will be happy to >> maintain an >> > editor's role, and write more text. Obviously other people's >> input will be >> > highly appreciated, and indeed is needed. >> > > >> > > I look forward to your comments. >> > > >> > > Best regards, >> > > Bert >> > > >> > > P.S. Unfortunately, I forgot to include "mmusic" in the name >> of the >> > draft. How to deal with this? >> > > >> > > >> > > >> > > -----Original Message----- >> > > From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org ] >> On Behalf >> > Of Christer Holmberg >> > > Sent: 27 February 2012 04:53 >> > > To: Gonzalo Camarillo; Mary Barnes >> > > Cc: mmusic@ietf.org >> > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> > > >> > > >> > > Hi, >> > > >> > > As a directorate member, I am willing to co-author such draft, >> should a >> > decision to write one be taken. >> > > >> > > Regards, >> > > >> > > Christer >> > > >> > > -----Original Message----- >> > > From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org ] >> On Behalf >> > Of Gonzalo Camarillo >> > > Sent: 23. helmikuuta 2012 19:31 >> > > To: Mary Barnes >> > > Cc: mmusic@ietf.org >> > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> > > >> > > I agree. >> > > >> > > Gonzalo >> > > >> > > On 23/02/2012 7:06 PM, Mary Barnes wrote: >> > >> I would think that in order for the document to have >> integrity that at >> > >> least one of the directorate members should at least be a >> co-author. >> > >> Otherwise, I see a lot more stuff falling through the cracks and >> > >> needing to be resolved during WGLC and later, which usually >> isn't a >> > >> good thing. The SIP Hitchhiker's guide provides a good example in >> > >> that the author was also a primary contributor to RFC3261, etc. >> > >> >> > >> Mary. >> > >> >> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >> > >> > >> > >> > >> >> > >> wrote: >> > >> >> > >> Hi Mary, >> > >> >> > >> yes, the members of the SDP directorate would need to review such >> > a >> > >> guide. However, the fact that they agreed to be members of the >> > >> directorate does not mean they will necessarily have cycles to >> > >> significantly contribute to the creation of the guide. We need to >> > make >> > >> sure we have enough energy around this effort in order to start >> > it. >> > >> >> > >> Cheers, >> > >> >> > >> Gonzalo >> > >> >> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: >> > >> > I think this is a good idea. I would think the experts that >> > can >> > >> > contribute (and should review) can be found in the new SDP >> > >> > directorate: >> > >> > http://www.ietf.org/iesg/directorate/sdp.html >> > >> > BTW, it would be nice to have a link to this page on the MMUSIC >> > WG >> > >> wiki: >> > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >> > >> > >> > >> > As far as whether to publish, I think it would be a good idea >> > to >> > >> > complete publication as IMHO that improves the integrity of the >> > >> > information - i.e., more eyes review a published RFC than a >> > draft. >> > >> > It could later be updated to reflect more recent RFCs OR a >> > "More of >> > >> > Hitchhikers Guide" could be published. >> > >> > >> > >> > Thanks, >> > >> > Mary. >> > >> > >> > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >> > >> > > >> > >> > >> wrote: >> > >> >> Hi Miguel, Andrew, all, >> > >> >> >> > >> >> Sounds like a good idea. I would be happy to volunteer to play >> > a >> > >> central role in it (i.e. be the editor, create the initial draft, >> > >> ...), but I would need support from other experts too. >> > >> >> >> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to >> > SIP" >> > >> has become an RFC (5411). That means that it has been frozen, and >> > to >> > >> add new info new individual or WG drafts are needed. >> > >> >> >> > >> >> Would this be the same approach for SDP? Currently, there are >> > >> already quite some new drafts that extend SDP. How will future >> > >> extensions be handled? Maybe it would be good to make it a >> > permanent >> > >> WG draft, which is updated every now and then. >> > >> >> >> > >> >> Best regards, >> > >> >> Bert >> > >> >> >> > >> >> >> > >> >> -----Original Message----- >> > >> >> From: mmusic-bounces@ietf.org >> > > >> > >> [mailto:mmusic-bounces@ietf.org >> > >] >> > On >> > >> Behalf Of Miguel A. Garcia >> > >> >> Sent: 14 February 2012 15:42 >> > >> >> To: Andrew Allen >> > >> >> Cc: mmusic@ietf.org >> > > >> > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >> > >> >> >> > >> >> Sounds good to me too. If someone wants to start such draft... >> > >> >> >> > >> >> /Miguel >> > >> >> >> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: >> > >> >>> >> > >> >>> What about considering a hitchhikers guide to SDP similar to >> > >> what was done for SIP? >> > >> >>> >> > >> >>> One umbrella document that points the reader to all the SDP >> > >> capabilities available that they might want to take advantage of. >> > >> >>> >> > >> >>> Just a suggestion. >> > >> >>> >> > >> >>> Andrew >> > >> >>> >> > >> >>> ----- Original Message ----- >> > >> >>> From: Miguel A. Garcia >> [mailto:Miguel.A.Garcia@ericsson.com >> >> > >> > >] >> > >> >>> Sent: Saturday, January 28, 2012 06:23 AM >> > >> >>> To: mmusic> > >> >> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> Hi all, >> > >> >>> >> > >> >>> You know we are revising RFC 4566. So far, the effort has >> > been >> > >> in bug fixing. >> > >> >>> >> > >> >>> The first SDP version was published as RFC 2327 in 1998 >> > (i.e., >> > >> 14 years >> > >> >>> ago), and was then revised as RFC 4566 in 2006. >> > >> >>> >> > >> >>> Lots of things have happened since then. We have SDP offer >> > answer, >> > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, >> > comeida, >> > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in >> > the pipe. >> > >> >>> >> > >> >>> From the point of view of a reader who takes 4566 (or its >> > current >> > >> >>> 4566bis incarnation), I think it will be difficult for her or >> > him to >> > >> >>> understand a protocol that ignores those other extensions. >> > For >> > >> example, I >> > >> >>> recently post another e-mail where there is an apparent >> > >> contradiction >> > >> >>> between 4566 and ICE (see >> > >> >>> http://www.ietf.org/mail- >> > archive/web/mmusic/current/msg09089.html ). >> > >> >>> >> > >> >>> So, I was wondering if time has come to make not a bug >> > correction in >> > >> >>> 4566bis, but also put that RFC in context with the other >> > >> extensions that >> > >> >>> exist. This may include: >> > >> >>> >> > >> >>> - Add minor extensions to the core document, similarly to >> > what >> > >> we did >> > >> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know >> > which >> > >> of these >> > >> >>> extensions make sense to include, this would be an exercise >> > to >> > >> do, but >> > >> >>> let me give you one potential example: RFC 4574, the SDP >> > "label" >> > >> >>> attribute is a 6 pages RFC. >> > >> >>> >> > >> >>> - Adding references to extensions, when it makes sense. For >> > >> example, ICE >> > >> >>> should be referred somewhere (see my previous post regarding >> > the "o" >> > >> >>> line). I guess capneg could be also mentioned, perhaps >> > others. >> > >> >>> >> > >> >>> I know this is a bigger effort than anticipated, but the >> > result >> > >> could >> > >> >>> really help newcomers to this world. >> > >> >>> >> > >> >>> Now, it is your turn to express your opinions. Please do it. >> > >> >>> >> > >> >>> /Miguel >> > >> >> >> > >> >> -- >> > >> >> Miguel A. Garcia >> > >> >> +34-91-339-3608 >> > >> >> Ericsson Spain >> > >> >> _______________________________________________ >> > >> >> 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 >> > >> > _______________________________________________ >> > >> > 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 >> > > _______________________________________________ >> > > 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 >> > > >> > >> > -- >> > Miguel A. Garcia >> > +34-91-339-3608 >> > Ericsson Spain >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Thu Mar 8 05:12:07 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 868B321F86AB for ; Thu, 8 Mar 2012 05:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.389 X-Spam-Level: X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 FolJW0y3zfjP for ; Thu, 8 Mar 2012 05:12:05 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E447F21F8691 for ; Thu, 8 Mar 2012 05:12:04 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-22-4f58b02394ee Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 80.86.27041.320B85F4; Thu, 8 Mar 2012 14:12:04 +0100 (CET) Received: from [159.107.24.238] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Thu, 8 Mar 2012 14:12:03 +0100 Message-ID: <4F58B022.1080604@ericsson.com> Date: Thu, 8 Mar 2012 14:12:02 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bert Greevenbosch References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <4F57CEC3.6040002@alum.mit.edu> <46A1DF3F04371240B504290A071B4DB62451164F@szxeml509-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB62451164F@szxeml509-mbx.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Hitchhiker's guide to SIP SDP 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, 08 Mar 2012 13:12:07 -0000 I think we need to start and see how big the document can be, and that can give us an idea of the scope at a later time. My idea right now is that the document should describe all the usages of SDP documented in IETF documents. So, I am opening the scope to SIP, RTSP, H.248, and perhaps others. And I am closing it to extensions documented by third parties. /Miguel On 08/03/2012 3:24, Bert Greevenbosch wrote: > Hi all, > > Interesting discussion. When I created the new draft, I took the SIP guide and narrowed it down by pruning all SIP specific references. I then added references specific to SDP. > > So the current version of the draft is a guide to "core SDP", but not to dependent technologies. That's one approach, but indeed another would be to include dependent technologies like SIP and Megaco/H.248. > > A third approach could be to keep the core documents, and then add some describing sections for the dependent technologies, but without discussing each of the documents that make up those technologies deeply. > > Best regards, > Bert > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 08 March 2012 05:10 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SIP SDP > > On 3/7/12 12:59 PM, Severa, Michael J (Mike) wrote: >> If the goal is to limit to SIP or even IMS environments then the title >> of the document should reflect that. >> SDP is used in many non-SIP environments. > > I think you can be confident that it won't be limited to the IMS > environment. (Unless the IMS community chooses to submit such a document.) > > Thanks, > Paul > >> Mike >> ------------------------------------------------------------------------ >> *From:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On >> Behalf Of *Gonzalo Salgueiro >> *Sent:* Wednesday, March 07, 2012 7:19 AM >> *To:* Mary Barnes >> *Cc:* DRAGE, Keith (Keith); mmusic@ietf.org >> *Subject:* Re: [MMUSIC] Hitchhiker's guide to SDP >> >> I agree. Limiting it to SIP seems sufficiently Herculean for one >> document IMO. >> >> Gonzalo >> >> On Mar 7, 2012, at 10:03 AM, Mary Barnes wrote: >> >>> Per Albrecht response, I think we would open a can of worms if we want >>> this to be a general guide on SDP for all usages. I would prefer to >>> keep it limited to SIP at this time, which I think is no small task. >>> Then another document, modeled after this one, could cover other >>> usages if the interested parties think it would be helpful. >>> >>> Mary. >>> >>> On Wed, Mar 7, 2012 at 8:24 AM, DRAGE, Keith (Keith) >>> >> > wrote: >>> >>> I notice RFC 3264 is mentioned as one of the core specifications. >>> >>> This only becomes core when SDP is used in the context of SIP. >>> >>> If I am a Megaco / H.248 user of SDP I suspect therefore I come up >>> with a different viewpoint of what is core and what is not. >>> >>> We may need to address these different viewpoints, unless you want >>> to make a guide that is entirely focused on SIP usage. >>> >>> Regards >>> >>> Keith >>> >>> > -----Original Message----- >>> > From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org] >>> On Behalf >>> > Of Miguel A. Garcia >>> > Sent: 07 March 2012 10:56 >>> > To: Bert Greevenbosch >>> > Cc: mmusic@ietf.org >>> > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>> > >>> > Bert, >>> > >>> > Here is another document with the same purpose. You can use it for >>> > inspiration. This is a bit more complex document, because it has >>> to deal >>> > with several different protocols, rather than only one. >>> > >>> > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >>> > >>> > The other document that you need to consult is the IANA SDP >>> Parameters >>> > registry at: >>> > >>> > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >>> > >>> > This contains a list of all the SDP extensions, and they all >>> should be >>> > listed in the hitchhiker's guide. >>> > >>> > /Miguel >>> > >>> > On 07/03/2012 3:54, Bert Greevenbosch wrote: >>> > > Hi all, >>> > > >>> > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide >>> to SDP". >>> > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I >>> have copied >>> > most initial text from there, and in addition included an >>> initial list of >>> > RFCs / drafts that seem relevant. >>> > > >>> > > >>> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- >>> > sdp/ >>> > > >>> > > If the group is happy with this approach, I will be happy to >>> maintain an >>> > editor's role, and write more text. Obviously other people's >>> input will be >>> > highly appreciated, and indeed is needed. >>> > > >>> > > I look forward to your comments. >>> > > >>> > > Best regards, >>> > > Bert >>> > > >>> > > P.S. Unfortunately, I forgot to include "mmusic" in the name >>> of the >>> > draft. How to deal with this? >>> > > >>> > > >>> > > >>> > > -----Original Message----- >>> > > From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org] >>> On Behalf >>> > Of Christer Holmberg >>> > > Sent: 27 February 2012 04:53 >>> > > To: Gonzalo Camarillo; Mary Barnes >>> > > Cc: mmusic@ietf.org >>> > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>> > > >>> > > >>> > > Hi, >>> > > >>> > > As a directorate member, I am willing to co-author such draft, >>> should a >>> > decision to write one be taken. >>> > > >>> > > Regards, >>> > > >>> > > Christer >>> > > >>> > > -----Original Message----- >>> > > From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org] >>> On Behalf >>> > Of Gonzalo Camarillo >>> > > Sent: 23. helmikuuta 2012 19:31 >>> > > To: Mary Barnes >>> > > Cc: mmusic@ietf.org >>> > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>> > > >>> > > I agree. >>> > > >>> > > Gonzalo >>> > > >>> > > On 23/02/2012 7:06 PM, Mary Barnes wrote: >>> > >> I would think that in order for the document to have >>> integrity that at >>> > >> least one of the directorate members should at least be a >>> co-author. >>> > >> Otherwise, I see a lot more stuff falling through the cracks and >>> > >> needing to be resolved during WGLC and later, which usually >>> isn't a >>> > >> good thing. The SIP Hitchhiker's guide provides a good example in >>> > >> that the author was also a primary contributor to RFC3261, etc. >>> > >> >>> > >> Mary. >>> > >> >>> > >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >>> > >> >> >>> > >> >> >> >>> > >> wrote: >>> > >> >>> > >> Hi Mary, >>> > >> >>> > >> yes, the members of the SDP directorate would need to review such >>> > a >>> > >> guide. However, the fact that they agreed to be members of the >>> > >> directorate does not mean they will necessarily have cycles to >>> > >> significantly contribute to the creation of the guide. We need to >>> > make >>> > >> sure we have enough energy around this effort in order to start >>> > it. >>> > >> >>> > >> Cheers, >>> > >> >>> > >> Gonzalo >>> > >> >>> > >> On 15/02/2012 7:14 PM, Mary Barnes wrote: >>> > >> > I think this is a good idea. I would think the experts that >>> > can >>> > >> > contribute (and should review) can be found in the new SDP >>> > >> > directorate: >>> > >> > http://www.ietf.org/iesg/directorate/sdp.html >>> > >> > BTW, it would be nice to have a link to this page on the MMUSIC >>> > WG >>> > >> wiki: >>> > >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >>> > >> > >>> > >> > As far as whether to publish, I think it would be a good idea >>> > to >>> > >> > complete publication as IMHO that improves the integrity of the >>> > >> > information - i.e., more eyes review a published RFC than a >>> > draft. >>> > >> > It could later be updated to reflect more recent RFCs OR a >>> > "More of >>> > >> > Hitchhikers Guide" could be published. >>> > >> > >>> > >> > Thanks, >>> > >> > Mary. >>> > >> > >>> > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >>> > >> > >> >>> > >> >> >> wrote: >>> > >> >> Hi Miguel, Andrew, all, >>> > >> >> >>> > >> >> Sounds like a good idea. I would be happy to volunteer to play >>> > a >>> > >> central role in it (i.e. be the editor, create the initial draft, >>> > >> ...), but I would need support from other experts too. >>> > >> >> >>> > >> >> As for practicalities, I see that the "Hitchhiker's Guide to >>> > SIP" >>> > >> has become an RFC (5411). That means that it has been frozen, and >>> > to >>> > >> add new info new individual or WG drafts are needed. >>> > >> >> >>> > >> >> Would this be the same approach for SDP? Currently, there are >>> > >> already quite some new drafts that extend SDP. How will future >>> > >> extensions be handled? Maybe it would be good to make it a >>> > permanent >>> > >> WG draft, which is updated every now and then. >>> > >> >> >>> > >> >> Best regards, >>> > >> >> Bert >>> > >> >> >>> > >> >> >>> > >> >> -----Original Message----- >>> > >> >> From: mmusic-bounces@ietf.org >>> >> > >>> > >> [mailto:mmusic-bounces@ietf.org >>> >> >] >>> > On >>> > >> Behalf Of Miguel A. Garcia >>> > >> >> Sent: 14 February 2012 15:42 >>> > >> >> To: Andrew Allen >>> > >> >> Cc: mmusic@ietf.org >>> >> > >>> > >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >>> > >> >> >>> > >> >> Sounds good to me too. If someone wants to start such draft... >>> > >> >> >>> > >> >> /Miguel >>> > >> >> >>> > >> >> On 13/02/2012 23:15, Andrew Allen wrote: >>> > >> >>> >>> > >> >>> What about considering a hitchhikers guide to SDP similar to >>> > >> what was done for SIP? >>> > >> >>> >>> > >> >>> One umbrella document that points the reader to all the SDP >>> > >> capabilities available that they might want to take advantage of. >>> > >> >>> >>> > >> >>> Just a suggestion. >>> > >> >>> >>> > >> >>> Andrew >>> > >> >>> >>> > >> >>> ----- Original Message ----- >>> > >> >>> From: Miguel A. Garcia >>> [mailto:Miguel.A.Garcia@ericsson.com >>> >>> > >> >> >] >>> > >> >>> Sent: Saturday, January 28, 2012 06:23 AM >>> > >> >>> To: mmusic>> >> >> >>> > >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> Hi all, >>> > >> >>> >>> > >> >>> You know we are revising RFC 4566. So far, the effort has >>> > been >>> > >> in bug fixing. >>> > >> >>> >>> > >> >>> The first SDP version was published as RFC 2327 in 1998 >>> > (i.e., >>> > >> 14 years >>> > >> >>> ago), and was then revised as RFC 4566 in 2006. >>> > >> >>> >>> > >> >>> Lots of things have happened since then. We have SDP offer >>> > answer, >>> > >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, >>> > comeida, >>> > >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in >>> > the pipe. >>> > >> >>> >>> > >> >>> From the point of view of a reader who takes 4566 (or its >>> > current >>> > >> >>> 4566bis incarnation), I think it will be difficult for her or >>> > him to >>> > >> >>> understand a protocol that ignores those other extensions. >>> > For >>> > >> example, I >>> > >> >>> recently post another e-mail where there is an apparent >>> > >> contradiction >>> > >> >>> between 4566 and ICE (see >>> > >> >>> http://www.ietf.org/mail- >>> > archive/web/mmusic/current/msg09089.html ). >>> > >> >>> >>> > >> >>> So, I was wondering if time has come to make not a bug >>> > correction in >>> > >> >>> 4566bis, but also put that RFC in context with the other >>> > >> extensions that >>> > >> >>> exist. This may include: >>> > >> >>> >>> > >> >>> - Add minor extensions to the core document, similarly to >>> > what >>> > >> we did >>> > >> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know >>> > which >>> > >> of these >>> > >> >>> extensions make sense to include, this would be an exercise >>> > to >>> > >> do, but >>> > >> >>> let me give you one potential example: RFC 4574, the SDP >>> > "label" >>> > >> >>> attribute is a 6 pages RFC. >>> > >> >>> >>> > >> >>> - Adding references to extensions, when it makes sense. For >>> > >> example, ICE >>> > >> >>> should be referred somewhere (see my previous post regarding >>> > the "o" >>> > >> >>> line). I guess capneg could be also mentioned, perhaps >>> > others. >>> > >> >>> >>> > >> >>> I know this is a bigger effort than anticipated, but the >>> > result >>> > >> could >>> > >> >>> really help newcomers to this world. >>> > >> >>> >>> > >> >>> Now, it is your turn to express your opinions. Please do it. >>> > >> >>> >>> > >> >>> /Miguel >>> > >> >> >>> > >> >> -- >>> > >> >> Miguel A. Garcia >>> > >> >> +34-91-339-3608 >>> > >> >> Ericsson Spain >>> > >> >> _______________________________________________ >>> > >> >> 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 >>> > >> > _______________________________________________ >>> > >> > 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 >>> > > _______________________________________________ >>> > > 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 >>> > > >>> > >>> > -- >>> > Miguel A. Garcia >>> > +34-91-339-3608 >>> > Ericsson Spain >>> > _______________________________________________ >>> > 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 >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Simo.Veikkolainen@nokia.com Thu Mar 8 05:39:39 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 6612321F86B4 for ; Thu, 8 Mar 2012 05:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 ujr06KLJETXG for ; Thu, 8 Mar 2012 05:39:38 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6401021F8611 for ; Thu, 8 Mar 2012 05:39:38 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q28DdOjX027623; Thu, 8 Mar 2012 15:39:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 15:39:27 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.186]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Thu, 8 Mar 2012 14:39:26 +0100 From: To: , Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt Thread-Index: AQHM+3tLdQaPmKC0lECFviDRi6kLvJZdAYyAgAIKnS6AAVrokA== Date: Thu, 8 Mar 2012 13:39:25 +0000 Message-ID: References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> <4F566A1C.3040406@alum.mit.edu> <4F573D31.2060304@ericsson.com> <4F579065.60009@alum.mit.edu> In-Reply-To: <4F579065.60009@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IoztK79W28gvbdMo7B6DfwsdIR06An8I2UDaQmd03UvWU/z766xNMvXCWBc/yMePYkm5/qUrMzogd3WFmWpWApLUd1Re7e4m347Lxwl+/yYexmdYyCpu/q+En6V6AWbVmZRCV4GIhxMAjx9CS2Rl1w45RQJBR9DEOYUMeAk+d3GyJ5zBlA7rLisySd6BkAVnUOThP5WxEHsaLtD/FxrWjy/s459Ge1cTePSr9+1aWxVczmhbDBeZ7Xvyw8n5RotpXg== x-originating-ip: [88.114.28.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 13:39:27.0181 (UTC) FILETIME=[E1952FD0:01CCFD30] X-Nokia-AV: Clean Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Thu, 08 Mar 2012 13:39:39 -0000 See below [SV] -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 7. maaliskuuta 2012 18:44 To: Miguel A. Garcia Cc: mmusic@ietf.org; Veikkolainen Simo (Nokia-CTO/Espoo) Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt Miguel - comments inline. On 3/7/12 5:49 AM, Miguel A. Garcia wrote: > Hi Paul: > > Thanks for your comments, see inline answers. > > On 06/03/2012 20:48, Paul Kyzivat wrote: >> On 3/6/12 4:34 AM, Simo.Veikkolainen@nokia.com wrote: >>> We have submitted a new version (-10) of Session Description=20 >>> Protocol >>> (SDP) Extension For Setting Up Audio and Video Media Streams Over=20 >>> Circuit-Switched Bearers In The Public Switched Telephone Network=20 >>> (PSTN), which can be found at=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt >>> >>> Changes in this version include: >>> - The port number in "m=3D" line SHOULD be set to "9" (the discard >>> port) but it MUST be ignored at reception >>> - Clarified that the Discriminator byte is included in the=20 >>> cs-correlation:uuie attribute, but we don't specify a value for the=20 >>> Discriminator byte >> >> I know this has been discussed before, but it still bothers me: >> >> Is there a reason why the representation of this UUIE is so different=20 >> from the representation used in draft-ietf-cuss-sip-uui-isdn-02? >> These things are talking about conveying the same thing in the same=20 >> manner. IMO it would be much better to be consistent about this. > > Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User=20 > SIP header field, whereas this draft uses a "cs-correlation" attribute in= SDP? I'm not talking specifically about the header field. The situation is diffe= rent here - you need to transport this in SDP rather than directly in SIP. What I am talking about is the representation of the UUI value.=20 draft-ietf-cuss-sip-uui-isdn includes the discriminator byte and encodes th= e whole thing in hex. This draft does it differently. ISTM that these ought= to use the same representation unless there is some justification for the = difference. [SV] draft-ietf-cuss-sip-uui-04 seems to add encoding, package, and content= parameters to the UUI data itself. The actual content of the UUI seems to = be the protocol discriminator and uui data (hex encoding preferred), the sa= me as in sdp-cs draft. For our purposes only the "uui-data" part of the syn= tax in Section 4.1 of draft-ietf-cuss-sip-uui-04 would be needed, and not t= he "uui-param". I don't see much benefit in changing the syntax to be the s= ame in both drafts, but I guess it wouldn't hurt either. > If this is the case, I guess there is a justification. The cuss draft=20 > comes from an angle of making visible in SIP the UUIE in ISDN,=20 > irrespective of their contents. The goal is to improve=20 > interoperability between SIP and ISDN. > > The CS descriptions drafts needs a correlation mechanism between two=20 > objects (a CS call and a RTP stream). It offers three mechanisms, of=20 > which, one happens to be the UUIE. These mechanisms are described in=20 > an SDP attribute. They are specific for the purpose of correlating two=20 > media streams. > > I think both mechanisms serve different purposes, and the only=20 > commonality between them is that it happens to be transporting the=20 > same information. I would not like to see, e.g., that the CS drafts=20 > uses two correlation mechanisms defined in SDP, and a third one in a SIP = header. > I don't see the point. I am not disputing use of an SDP parameter rather than a SIP header. > I don't see any problem in leaving them as they are. > > >> >> Is it because implementations of this draft have already been deployed? > > I am not aware of an implementation of the CS descriptions draft, so=20 > this should not be a problem. > >> >>> - Added a new example with audio and video streams >> >> While its good to seen the new example, as shown it has missed the=20 >> main issue that will arise, because it only shows the situation when=20 >> one of the proposed streams is rejected. >> >> If both streams are to be accepted, are they to result in one pstn=20 >> phone call, or two? I would think the intent would be to have only=20 >> one. But in that case, how is it represented in SDP so that its known=20 >> that only one call is made? Is there an assumption that if one phone=20 >> number is used for multiple m-lines, then the same call should be used f= or both? > > The idea is to have a single PSTN phone call, with audio and video=20 > components. I haven't heard of requirements indicating other thing. > > So, I agree with you that perhaps we ought to describe that for video=20 > calls, a single PSTN phone call is made. Yes, we miss some text there,=20 > thanks for catching this up. I figured you only had one call in mind. But because the phone number is specified in c=3D, which is media level, th= ere is the potential that audio and video would have differing phone number= s, which would presumably exclude a single call. So there should probably b= e some explanation of that. Perhaps that there will only be one call per di= stinct combination of phone number and cs-correlation attribute. Or do you want to exclude the possibility of different phone numbers being = supplied? If so, then I might be better to move the phone number from the c= -line to a session level attribute. While its possible to specify the phone= number once at session level, its also possible to do it at media level, w= here it might end up different. [SV] I think only one phone number should be supplied; that is how the circ= uit-switched world works. So it might be better to specify the phone numbe= r once at session level - for other (IP based) media the address could be d= efined at media level, if they ever are offered together. Also, I would think you would typically want to specify the cs-correlation = at session level rather than media level. (In fact you show it that way in = your new example.) But currently it is defined as being only media level. S= o you should probably change that. [SV] I agree. - Simo Thanks, Paul > /Miguel > > >> >> Thanks, >> Paul >> >>> - Added a new section "Considerations for Usage of Third Party Call=20 >>> Control (3PCC)" which recommends the Controller to use "-" as the=20 >>> connection address (to be in line with 0.0.0.0 which is used for IPv4). >>> - Added a new paragraph to security considerations on privacy=20 >>> concerns that arise from including the phone number in the SDP >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From ron.even.tlv@gmail.com Thu Mar 8 05:42: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 320DA21F86A5 for ; Thu, 8 Mar 2012 05:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, 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 B0G6fmdNYLOa for ; Thu, 8 Mar 2012 05:42:19 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3F21F86A3 for ; Thu, 8 Mar 2012 05:42:19 -0800 (PST) Received: by werb10 with SMTP id b10so415899wer.31 for ; Thu, 08 Mar 2012 05:42:18 -0800 (PST) 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:content-transfer-encoding:x-mailer:thread-index :content-language; bh=+0H3GLB7kwL4IJXrGkCwi0SaA1PeQWQ511C1K9ZW7/k=; b=a0wtwCxTOUYCytj+T+YK3YqIz0Vtt0NY+fCYKTUAxo09ZP0YU4/r5NrRKmeOn1wfHy gvz8usa7ubVh3thr32OyJgKfF0pTcxuGYJP9wzzpb7tTQaxO4dIQxcEkuv8UiuirwPXR 1tAO6j1fPrqK0KQ1kql83UrnRUxu5pTA443dI9rtPwtZNekHxDNOgdwTeaYQwuZYrNjj Rx8GbJw178+QFsEb/kC/IyyXMzJKXCRmMK3wYLZPZJVCWNb+CYEv8Yv7Wm/Fj4KyJdmv nmNsRM4pyNASlYghDTRq9bXkWU9VmOhoyC8R3Pb1Yzloqeb0qdGhocduU0x/UgFYxU1t 0kUw== Received: by 10.180.78.233 with SMTP id e9mr35186780wix.0.1331214138342; Thu, 08 Mar 2012 05:42:18 -0800 (PST) Received: from windows8d787f9 (bzq-109-67-208-29.red.bezeqint.net. [109.67.208.29]) by mx.google.com with ESMTPS id k6sm44153948wiy.7.2012.03.08.05.42.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 05:42:16 -0800 (PST) From: "Roni Even" To: References: <20120224070144.20140.13888.idtracker@ietfa.amsl.com> In-Reply-To: <20120224070144.20140.13888.idtracker@ietfa.amsl.com> Date: Thu, 8 Mar 2012 15:41:03 +0200 Message-ID: <4f58b738.c652b40a.6d6e.14ad@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: Aczywl1P+AEIYoHRTF+KcnGiioq3lQKbTa0g Content-Language: en-us Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Thu, 08 Mar 2012 13:42:20 -0000 Hi, I have a question about the last rule in section 7.2 "A given SSRC SHOULD NOT transmit RTP packet using payload types that originate from different "m=" lines". My reading of section 5.2 in RFC 3550 bullet 1 is that the same SSRC should not be used for any two RTP streams in the SAME RTP session even if they are in the same m-line. Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Friday, February 24, 2012 9:02 AM > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation- > 00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiparty Multimedia > Session Control Working Group of the IETF. > > Title : Multiplexing Negotiation Using Session > Description Protocol (SDP) Port Numbers > Author(s) : Christer Holmberg > Harald Tveit Alvestrand > Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > Pages : 11 > Date : 2012-02-23 > > This specification defines a new SDP Grouping Framework SDP grouping > framework extension, "BUNDLE", that can be used with the Session > Description Protocol (SDP) Offer/Answer mechanism to negotiate the > usage of bundled media, which refers to the usage of a single 5- > tuple > for media associated with multiple SDP media descriptions ("m=" > lines). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle- > negotiation-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle- > negotiation-00.txt > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Thu Mar 8 09:08:03 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 D527A21F85C6 for ; Thu, 8 Mar 2012 09:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 gZ2dp2CDbDfz for ; Thu, 8 Mar 2012 09:08:01 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4AA21F85B1 for ; Thu, 8 Mar 2012 09:08:01 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id j57U1i00A0Fqzac555822R; Thu, 08 Mar 2012 17:08:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id j5811i01D07duvL3U581SU; Thu, 08 Mar 2012 17:08:01 +0000 Message-ID: <4F58E76F.3030201@alum.mit.edu> Date: Thu, 08 Mar 2012 12:07:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> <4F566A1C.3040406@alum.mit.edu> <4F573D31.2060304@ericsson.com> <4F579065.60009@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Thu, 08 Mar 2012 17:08:03 -0000 On 3/8/12 8:39 AM, Simo.Veikkolainen@nokia.com wrote: > See below [SV] > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 7. maaliskuuta 2012 18:44 > To: Miguel A. Garcia > Cc: mmusic@ietf.org; Veikkolainen Simo (Nokia-CTO/Espoo) > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt > > Miguel - comments inline. > > On 3/7/12 5:49 AM, Miguel A. Garcia wrote: >> Hi Paul: >> >> Thanks for your comments, see inline answers. >> >> On 06/03/2012 20:48, Paul Kyzivat wrote: >>> On 3/6/12 4:34 AM, Simo.Veikkolainen@nokia.com wrote: >>>> We have submitted a new version (-10) of Session Description >>>> Protocol >>>> (SDP) Extension For Setting Up Audio and Video Media Streams Over >>>> Circuit-Switched Bearers In The Public Switched Telephone Network >>>> (PSTN), which can be found at >>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt >>>> >>>> Changes in this version include: >>>> - The port number in "m=" line SHOULD be set to "9" (the discard >>>> port) but it MUST be ignored at reception >>>> - Clarified that the Discriminator byte is included in the >>>> cs-correlation:uuie attribute, but we don't specify a value for the >>>> Discriminator byte >>> >>> I know this has been discussed before, but it still bothers me: >>> >>> Is there a reason why the representation of this UUIE is so different >>> from the representation used in draft-ietf-cuss-sip-uui-isdn-02? >>> These things are talking about conveying the same thing in the same >>> manner. IMO it would be much better to be consistent about this. >> >> Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User >> SIP header field, whereas this draft uses a "cs-correlation" attribute in SDP? > > I'm not talking specifically about the header field. The situation is different here - you need to transport this in SDP rather than directly in SIP. > > What I am talking about is the representation of the UUI value. > draft-ietf-cuss-sip-uui-isdn includes the discriminator byte and encodes the whole thing in hex. This draft does it differently. ISTM that these ought to use the same representation unless there is some justification for the difference. > > [SV] draft-ietf-cuss-sip-uui-04 seems to add encoding, package, and content parameters to the UUI data itself. The actual content of the UUI seems to be the protocol discriminator and uui data (hex encoding preferred), the same as in sdp-cs draft. For our purposes only the "uui-data" part of the syntax in Section 4.1 of draft-ietf-cuss-sip-uui-04 would be needed, and not the "uui-param". I don't see much benefit in changing the syntax to be the same in both drafts, but I guess it wouldn't hurt either. All I'm thinking of here is consistency in the representation of the content - that it include the descriminator byte and that it be then encoded in hex. At least that way people that are familiar with UUI will be less inclined to get confused. >> If this is the case, I guess there is a justification. The cuss draft >> comes from an angle of making visible in SIP the UUIE in ISDN, >> irrespective of their contents. The goal is to improve >> interoperability between SIP and ISDN. >> >> The CS descriptions drafts needs a correlation mechanism between two >> objects (a CS call and a RTP stream). It offers three mechanisms, of >> which, one happens to be the UUIE. These mechanisms are described in >> an SDP attribute. They are specific for the purpose of correlating two >> media streams. >> >> I think both mechanisms serve different purposes, and the only >> commonality between them is that it happens to be transporting the >> same information. I would not like to see, e.g., that the CS drafts >> uses two correlation mechanisms defined in SDP, and a third one in a SIP header. >> I don't see the point. > > I am not disputing use of an SDP parameter rather than a SIP header. > >> I don't see any problem in leaving them as they are. >> >> >>> >>> Is it because implementations of this draft have already been deployed? >> >> I am not aware of an implementation of the CS descriptions draft, so >> this should not be a problem. >> >>> >>>> - Added a new example with audio and video streams >>> >>> While its good to seen the new example, as shown it has missed the >>> main issue that will arise, because it only shows the situation when >>> one of the proposed streams is rejected. >>> >>> If both streams are to be accepted, are they to result in one pstn >>> phone call, or two? I would think the intent would be to have only >>> one. But in that case, how is it represented in SDP so that its known >>> that only one call is made? Is there an assumption that if one phone >>> number is used for multiple m-lines, then the same call should be used for both? >> >> The idea is to have a single PSTN phone call, with audio and video >> components. I haven't heard of requirements indicating other thing. >> >> So, I agree with you that perhaps we ought to describe that for video >> calls, a single PSTN phone call is made. Yes, we miss some text there, >> thanks for catching this up. > > I figured you only had one call in mind. > > But because the phone number is specified in c=, which is media level, there is the potential that audio and video would have differing phone numbers, which would presumably exclude a single call. So there should probably be some explanation of that. Perhaps that there will only be one call per distinct combination of phone number and cs-correlation attribute. > > Or do you want to exclude the possibility of different phone numbers being supplied? If so, then I might be better to move the phone number from the c-line to a session level attribute. While its possible to specify the phone number once at session level, its also possible to do it at media level, where it might end up different. > > [SV] I think only one phone number should be supplied; that is how the circuit-switched world works. So it might be better to specify the phone number once at session level - for other (IP based) media the address could be defined at media level, if they ever are offered together. I'm not going to try to second guess you here. But I suppose it might be some work to require the phone number to be at session level unless you move it out of the c= line and into something that is only allowed at session level, like a session-level-only attribute. But if you leave it in the c= line then I think you must address the possibility that multiple c= lilnes have different values. At least explicitly call it out and say that behavior in that case is explicitly undefined. Thanks, Paul > Also, I would think you would typically want to specify the cs-correlation at session level rather than media level. (In fact you show it that way in your new example.) But currently it is defined as being only media level. So you should probably change that. > > [SV] I agree. > > - Simo > > Thanks, > Paul > >> /Miguel >> >> >>> >>> Thanks, >>> Paul >>> >>>> - Added a new section "Considerations for Usage of Third Party Call >>>> Control (3PCC)" which recommends the Controller to use "-" as the >>>> connection address (to be in line with 0.0.0.0 which is used for IPv4). >>>> - Added a new paragraph to security considerations on privacy >>>> concerns that arise from including the phone number in the SDP >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> > > From juberti@google.com Thu Mar 8 12:15: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 EEE4D21E8036 for ; Thu, 8 Mar 2012 12:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 MVDhQaMcNikp for ; Thu, 8 Mar 2012 12:15:53 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0650A21F84D4 for ; Thu, 8 Mar 2012 12:15:52 -0800 (PST) Received: by yhpp34 with SMTP id p34so559971yhp.31 for ; Thu, 08 Mar 2012 12:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=+FbDWB5yS80iQ81mM4sH4VFT9vrlybxCdyD2eTG080c=; b=k/F959lOuNiz/bJohA5XVBN8IIE0/oATOzlLwz1u//lsMn6UvNAccss+3cE58rukFi AsdPAPLApShCT9jg6VhScYtvnbn7xo6GA8qmtFHmtlYMArCv51+rn1/f/RlmkR4hVUtT BNpoJ0lpidClyo6b2CSF17/Yr3ayLYycX0BGMQD0i3CwxXw0TGS26XrerLOKJx5rg055 gCAaeU6v1BJC97ZASUV3Xdn/DYAUjqu0qQ623Zqr4Agqkk1WoqnXObS5/9GG+4ySOKVg OYj/3r0l+WmWjlJ20IcmiTvqGRzJo7cNyNQvyTGfwwoOFV/moxEXz7m5aftXw9Fl/R2i 9KtA== Received: by 10.50.154.200 with SMTP id vq8mr8920361igb.14.1331237752291; Thu, 08 Mar 2012 12:15:52 -0800 (PST) Received: by 10.50.154.200 with SMTP id vq8mr8920347igb.14.1331237752219; Thu, 08 Mar 2012 12:15:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.9.8 with HTTP; Thu, 8 Mar 2012 12:15:32 -0800 (PST) From: Justin Uberti Date: Thu, 8 Mar 2012 15:15:32 -0500 Message-ID: To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=14dae93408215528ea04bac0f123 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmH7aSao4VokiSPYCxsT+h09V5ddsOj+Q6+D4Fi/r8L/r0r5S5fgc8X+vPOr+WBwv8hPzKk/CGQMCd4lYPDsZo1CkzhcBg7mJoadqhbR9eAA65LzBHYrgDlQ+/91GqRJSNwGTKL Cc: Cullen Jennings , Christer Holmberg Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Thu, 08 Mar 2012 20:15:54 -0000 --14dae93408215528ea04bac0f123 Content-Type: text/plain; charset=UTF-8 Christer - One question on BUNDLE. Does anything in SDP/RTP prevent an endpoint from using the same IP/port for media outside of BUNDLE (i.e. multiplexing)? I'm wondering because I think BUNDLE will break if it talks to a non-BUNDLE endpoint that is already doing multiplexing (of which we have found a few examples); the BUNDLE endpoint won't be able to demux traffic by 5-tuple. Thoughts? --justin --14dae93408215528ea04bac0f123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer -

One question on BUNDLE. Does anything in SDP/= RTP prevent an endpoint from using the same IP/port for media outside of BU= NDLE (i.e. multiplexing)?

I'm wondering becaus= e I think BUNDLE will break if it talks to a non-BUNDLE endpoint that is al= ready doing multiplexing (of which we have found a few examples); the BUNDL= E endpoint won't be able to demux traffic by 5-tuple.

Thoughts?

--justin
--14dae93408215528ea04bac0f123-- From emil@sip-communicator.org Thu Mar 8 16:01: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 04C8F21F86D4 for ; Thu, 8 Mar 2012 16:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 V9Pr9VuyDvKk for ; Thu, 8 Mar 2012 16:01:54 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F288821F86D3 for ; Thu, 8 Mar 2012 16:01:53 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so784617wgb.13 for ; Thu, 08 Mar 2012 16:01:53 -0800 (PST) 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:cc :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=snYM7tgqdMmnxG+72Wld4Lz5e9ZYlQgXncCRig9IQhw=; b=MJRvEjwKnIrV5AovN2DQRusK/9NbIJXY/ResfhygQmd9b94vDKw3+obabw7KQNDc0o sNg5QveHC5pi9tAz8mmmwaYNa/B+1K/1EwScmPzFy4qfSt1bC/+C7iNlBPnpesBJAjsQ NvBy4KYybyHiObbzGSPtHx6q8phf7lCz8Sm2L2K3coTl/Z25KMkU6dNyQxh7Biay9eoQ AD5spBqYOqjVD/0rbmBSe7uaNPC4YrTflrK3Mr84N0klCfYEz9KpZOqIlUcfp/XL3id3 cFHZ7dXpLZdUt38yTSYi1kUtJeDlIRcTI+IT7Ni+UypPSOc+ymaARofOhayweQonfWQV KAvg== Received: by 10.180.95.34 with SMTP id dh2mr397229wib.15.1331251313249; Thu, 08 Mar 2012 16:01:53 -0800 (PST) Received: from camionet.local ([78.90.66.189]) by mx.google.com with ESMTPS id j3sm1045051wiw.1.2012.03.08.16.01.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 16:01:52 -0800 (PST) Message-ID: <4F59486E.5020202@jitsi.org> Date: Fri, 09 Mar 2012 02:01:50 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk8eZGC7ZKTwZBwIl85wTIwMdaN7ITJQWdBEydZ5trFNm/VFHnX1lTe0NZSdjiecndzln6r Cc: Dan Wing Subject: [MMUSIC] Fwd: New Version Notification for draft-kaplan-mmusic-latching-00.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, 09 Mar 2012 00:01:55 -0000 Hey all, Hadriel, Dan and I have just submitted a draft that explains common practices for achieving transparent relaying with Hosted NAT Traversal (HNT) and latching: http://tools.ietf.org/html/draft-kaplan-mmusic-latching The draft is purely informative and its goal is to simply serve as a reference when discussing these techniques, which, whether we like them or not, are quite popular and widely deployed today. We'd be happy to present the draft in Paris if timing permits and until then we'd love to have your feedback. Cheers, Emil -- http://jitsi.org -------- Original Message -------- Subject: New Version Notification for draft-kaplan-mmusic-latching-00.txt Date: Mon, 05 Mar 2012 03:34:09 -0800 From: internet-drafts@ietf.org To: emcho@jitsi.org CC: dwing@cisco.com, hkaplan@acmepacket.com A new version of I-D, draft-kaplan-mmusic-latching-00.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Filename: draft-kaplan-mmusic-latching Revision: 00 Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 14 Abstract: This document describes behavior of signalling intermediaries in RTC deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. The IETF Secretariat From harald@alvestrand.no Fri Mar 9 06:28: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 D0B1A21F8510 for ; Fri, 9 Mar 2012 06:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 uw4ldf-45B9i for ; Fri, 9 Mar 2012 06:28:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E657A21F850B for ; Fri, 9 Mar 2012 06:28:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05A9C39E288; Fri, 9 Mar 2012 15:28:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvCuPGB2xfdJ; Fri, 9 Mar 2012 15:28:39 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C3DDB39E0C0; Fri, 9 Mar 2012 15:28:39 +0100 (CET) Message-ID: <4F5A1397.40701@alvestrand.no> Date: Fri, 09 Mar 2012 15:28:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Roni Even References: <20120224070144.20140.13888.idtracker@ietfa.amsl.com> <4f58b738.c652b40a.6d6e.14ad@mx.google.com> In-Reply-To: <4f58b738.c652b40a.6d6e.14ad@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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, 09 Mar 2012 14:28:42 -0000 On 03/08/2012 02:41 PM, Roni Even wrote: > Hi, > I have a question about the last rule in section 7.2 > "A given SSRC SHOULD NOT transmit RTP packet using payload types that > originate from different "m=" lines". Roni, this text is a kind of compromise, and I think none of us are very happy with it. We need to consider: - Audio types routinely switch a single RTP stream, carried on one SSRC, between the audio codec and comfort noise. So we can't forbid sending different PT numbers on one SSRC in general. - Sending stuff with different clock rates on the same SSRC will certainly mess things up. But draft-ietf-avtext-multiple-clock-rates doesn't lay down a flat "THOU SHALT NOT" on this, so it seemed to us that it's not appropriate for this draft to do so either. - Nevertheless, we felt that there should be a recommendation not to do things that cause problems. The resulting text is the result. > My reading of section 5.2 in RFC 3550 > bullet 1 is that the same SSRC should not be used for any two RTP streams in > the SAME RTP session even if they are in the same m-line. That text does not speak to the same issue at all, in my reading. The situation this paragraph talks about involves one RTP stream. > Roni Even > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of internet-drafts@ietf.org >> Sent: Friday, February 24, 2012 9:02 AM >> To: i-d-announce@ietf.org >> Cc: mmusic@ietf.org >> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation- >> 00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiparty Multimedia >> Session Control Working Group of the IETF. >> >> Title : Multiplexing Negotiation Using Session >> Description Protocol (SDP) Port Numbers >> Author(s) : Christer Holmberg >> Harald Tveit Alvestrand >> Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt >> Pages : 11 >> Date : 2012-02-23 >> >> This specification defines a new SDP Grouping Framework SDP grouping >> framework extension, "BUNDLE", that can be used with the Session >> Description Protocol (SDP) Offer/Answer mechanism to negotiate the >> usage of bundled media, which refers to the usage of a single 5- >> tuple >> for media associated with multiple SDP media descriptions ("m=" >> lines). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle- >> negotiation-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle- >> negotiation-00.txt >> >> _______________________________________________ >> 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 thomas.belling@nsn.com Fri Mar 9 07:18: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 7564021F8518 for ; Fri, 9 Mar 2012 07:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.759 X-Spam-Level: X-Spam-Status: No, score=-6.759 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 wEsXcMJqNdaU for ; Fri, 9 Mar 2012 07:18:58 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B821F8513 for ; Fri, 9 Mar 2012 07:18:58 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q29FItVb008594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 16:18:55 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q29FIqoS008206; Fri, 9 Mar 2012 16:18:55 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 16:18:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 16:18:54 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F011E1715@DEMUEXC014.nsn-intra.net> In-Reply-To: <4F59486E.5020202@jitsi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Fwd: New Version Notification fordraft-kaplan-mmusic-latching-00.txt Thread-Index: Acz9h9ssnXRzXBZ4RyeOe0qvGeC/sgAf5vzA References: <4F59486E.5020202@jitsi.org> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Emil Ivov" , , "Dan Wing" X-OriginalArrivalTime: 09 Mar 2012 15:18:55.0186 (UTC) FILETIME=[F1343B20:01CCFE07] 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: 2535 X-purgate-ID: 151667::1331306335-000044A2-C4B22EA2/0-0/0-0 Subject: Re: [MMUSIC] Fwd: New Version Notification fordraft-kaplan-mmusic-latching-00.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, 09 Mar 2012 15:18:59 -0000 Dear Emil, Dan draft-ietf-mmusic-media-path-middleboxes also describes latching in Clause 5. What are the differences compared to this draft? Cheers, Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Emil Ivov Sent: Friday, March 09, 2012 1:02 AM To: mmusic@ietf.org Cc: Dan Wing Subject: [MMUSIC] Fwd: New Version Notification fordraft-kaplan-mmusic-latching-00.txt Hey all, Hadriel, Dan and I have just submitted a draft that explains common practices for achieving transparent relaying with Hosted NAT Traversal (HNT) and latching: http://tools.ietf.org/html/draft-kaplan-mmusic-latching The draft is purely informative and its goal is to simply serve as a reference when discussing these techniques, which, whether we like them or not, are quite popular and widely deployed today. We'd be happy to present the draft in Paris if timing permits and until then we'd love to have your feedback. Cheers, Emil -- http://jitsi.org -------- Original Message -------- Subject: New Version Notification for draft-kaplan-mmusic-latching-00.txt Date: Mon, 05 Mar 2012 03:34:09 -0800 From: internet-drafts@ietf.org To: emcho@jitsi.org CC: dwing@cisco.com, hkaplan@acmepacket.com A new version of I-D, draft-kaplan-mmusic-latching-00.txt has been successfully submitted by Emil Ivov and posted to the IETF repository. Filename: draft-kaplan-mmusic-latching Revision: 00 Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 14 Abstract: This document describes behavior of signalling intermediaries in RTC deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. The IETF Secretariat _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From dwing@cisco.com Fri Mar 9 08:00:29 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 3ACC221F8677 for ; Fri, 9 Mar 2012 08:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 tWAYTPqhWbBU for ; Fri, 9 Mar 2012 08:00:28 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9347021F8711 for ; Fri, 9 Mar 2012 08:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3193; q=dns/txt; s=iport; t=1331308818; x=1332518418; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=A4iANFuB6iI+7aZNOpmBL9R2uv+kQxHGWKjZvtiYidA=; b=cFzSyeRvZ5Kcb9EeJ4J/8czzKCq2hv/vRDJ57m9j04mLRwJFGNfOHJkD Bg5DshVQa9KqUSvkoSugkbvf9yysI6wdH8dX7YX8NzPtMSy1w1vALkbGJ yEyCwRJKP4jTDuCnXiRCmfgRRBXoBmA5ChX6vnz+LY1hvNT+kP32fKMF/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEEAGUoWk9Io8UY/2dsb2JhbABDpVOQZoIKAQEBAwEBAQEFCgEXEDQJBwcBAwIJDwIDAQEBKAcZDhUKCQgBAQQBEgsJDodjBQucJwGfBJBaBIhThQ6YBIME X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="7565650" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 09 Mar 2012 16:00:16 +0000 Received: from dwingWS ([10.32.240.195]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q29G0ElU032017; Fri, 9 Mar 2012 16:00:15 GMT From: "Dan Wing" To: "'Belling, Thomas \(NSN - DE/Munich\)'" , "'ext Emil Ivov'" , References: <4F59486E.5020202@jitsi.org> <1A8A7D59006A8240B27FF63C794CA57F011E1715@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F011E1715@DEMUEXC014.nsn-intra.net> Date: Fri, 9 Mar 2012 08:00:14 -0800 Message-ID: <091c01ccfe0d$b8646940$292d3bc0$@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: Acz9h9ssnXRzXBZ4RyeOe0qvGeC/sgAf5vzAAAGGx2A= Content-Language: en-us Subject: Re: [MMUSIC] Fwd: New Version Notification fordraft-kaplan-mmusic-latching-00.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, 09 Mar 2012 16:00:30 -0000 > -----Original Message----- > From: Belling, Thomas (NSN - DE/Munich) [mailto:thomas.belling@nsn.com] > Sent: Friday, March 09, 2012 7:19 AM > To: ext Emil Ivov; mmusic@ietf.org; Dan Wing > Subject: RE: [MMUSIC] Fwd: New Version Notification fordraft-kaplan- > mmusic-latching-00.txt > > Dear Emil, Dan > > draft-ietf-mmusic-media-path-middleboxes also describes latching in > Clause 5. > What are the differences compared to this draft? draft-kaplan-mmusic-latching goes into more detail, is intended to be a standalone description of only hosted NAT traversal, and does not confuse its description with 'MIDCOM agent'. -d > Cheers, Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > Nokia Siemens Networks > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf > Of ext Emil Ivov > Sent: Friday, March 09, 2012 1:02 AM > To: mmusic@ietf.org > Cc: Dan Wing > Subject: [MMUSIC] Fwd: New Version Notification > fordraft-kaplan-mmusic-latching-00.txt > > Hey all, > > Hadriel, Dan and I have just submitted a draft that explains common > practices for achieving transparent relaying with Hosted NAT Traversal > (HNT) and latching: > > http://tools.ietf.org/html/draft-kaplan-mmusic-latching > > The draft is purely informative and its goal is to simply serve as a > reference when discussing these techniques, which, whether we like them > or not, are quite popular and widely deployed today. > > We'd be happy to present the draft in Paris if timing permits and until > then we'd love to have your feedback. > > Cheers, > Emil > > -- > http://jitsi.org > > -------- Original Message -------- > Subject: New Version Notification for > draft-kaplan-mmusic-latching-00.txt > Date: Mon, 05 Mar 2012 03:34:09 -0800 > From: internet-drafts@ietf.org > To: emcho@jitsi.org > CC: dwing@cisco.com, hkaplan@acmepacket.com > > A new version of I-D, draft-kaplan-mmusic-latching-00.txt has been > successfully submitted by Emil Ivov and posted to the IETF repository. > > Filename: draft-kaplan-mmusic-latching > Revision: 00 > Title: Latching: Hosted NAT Traversal (HNT) for Media in > Real-Time > Communication > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 14 > > Abstract: > This document describes behavior of signalling intermediaries in RTC > deployments, sometimes referred to as Session Border Controllers > (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of > mechanisms, such as media relaying and latching, that such > intermediaries use to enable other RTC devices behind NATs to > communicate with each other. This document is non-normative, and is > only written to explain HNT in order to provide a reference to the > IETF community, as well as an informative description to > manufacturers, and users. > > > > > > The IETF Secretariat > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Hannes.Tschofenig@gmx.net Sun Mar 11 11:34:23 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 62B4521F8649 for ; Sun, 11 Mar 2012 11:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 SbWAF5nk6JK9 for ; Sun, 11 Mar 2012 11:34:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 58E8221F85A7 for ; Sun, 11 Mar 2012 11:34:22 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 18:34:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 11 Mar 2012 19:34:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Uvu84sAMUyih8GfhKK6/GX3D2bcrFDs8jS3m/XD WKB8OAvxASIaXD From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Mar 2012 20:34:20 +0200 Message-Id: To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Ecrit Org Subject: [MMUSIC] Status of draft-ietf-mmusic-media-loopback? 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: Sun, 11 Mar 2012 18:34:23 -0000 Hey guys,=20 in the ECRIT working group we have a document called PhoneBCP, see = http://datatracker.ietf.org/doc/draft-ietf-ecrit-phonebcp/, which has a = normative dependency on draft-ietf-mmusic-media-loopback. It is waiting = for a while already and we are getting nervous.=20 We are wondering what the status of your document is? Are there open = issues? What are the planned next steps to finish it?=20 Ciao Hannes From internet-drafts@ietf.org Mon Mar 12 00:03:04 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 E3CC021F8565; Mon, 12 Mar 2012 00:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Ti67Ayy2KJe0; Mon, 12 Mar 2012 00:03:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7539D21F854A; Mon, 12 Mar 2012 00:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312070303.18937.55225.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 00:03:03 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-01.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: Mon, 12 Mar 2012 07:03:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based Media = Transport in the Session Description Protocol (SDP) Author(s) : Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-01.txt Pages : 10 Date : 2012-03-12 SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-01.txt From salvatore.loreto@ericsson.com Mon Mar 12 00:07:03 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 6DF6C21F856F for ; Mon, 12 Mar 2012 00:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.909 X-Spam-Level: X-Spam-Status: No, score=-109.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 2O9zc9Uk-33B for ; Mon, 12 Mar 2012 00:07:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 61C9921F8569 for ; Mon, 12 Mar 2012 00:07:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-e5-4f5da095b99f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E0.61.17856.590AD5F4; Mon, 12 Mar 2012 08:07:01 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Mon, 12 Mar 2012 08:07:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 92E5C2323 for ; Mon, 12 Mar 2012 09:07:00 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7BAF551E50 for ; Mon, 12 Mar 2012 09:07:00 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 37E7B4F2F7 for ; Mon, 12 Mar 2012 09:07:00 +0200 (EET) Message-ID: <4F5DA093.7020900@ericsson.com> Date: Mon, 12 Mar 2012 09:06:59 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120312070303.18937.55225.idtracker@ietfa.amsl.com> In-Reply-To: <20120312070303.18937.55225.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-01.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: Mon, 12 Mar 2012 07:07:03 -0000 Hi there, I have submitted a new version of the draft, that other then fix some little mistakes define the DTLS/SCTP protocol identifier to allow the usage of SCTP on top of the Datagram Transport Layer Security (DTLS) protocol, as defined in [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP. SCTP over DTLS is used by the RTCWeb protocol suite for transporting non-media data between browsers. regards Salvatore -- Salvatore Loreto www.sloreto.com On 3/12/12 9:03 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) > Author(s) : Salvatore Loreto > Gonzalo Camarillo > Filename : draft-ietf-mmusic-sctp-sdp-01.txt > Pages : 10 > Date : 2012-03-12 > > SCTP (Stream Control Transmission Protocol) is a transport protocol > used to establish associations between two endpoints. This document > describes how to express media transport over SCTP in SDP (Session > Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' > and 'DTLS/SCTP' protocol identifiers for SDP. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-01.txt > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From atle.monrad@ericsson.com Mon Mar 12 02:22: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 0B81221F8722 for ; Mon, 12 Mar 2012 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.994 X-Spam-Level: X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.605, 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 LMqhVi-uQDBX for ; Mon, 12 Mar 2012 02:22:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DA68A21F86DD for ; Mon, 12 Mar 2012 02:22:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-ff-4f5dc067f339 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 16.CA.27041.760CD5F4; Mon, 12 Mar 2012 10:22:47 +0100 (CET) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.56]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 12 Mar 2012 10:22:47 +0100 From: Atle Monrad To: Paul Kyzivat , "Simo.Veikkolainen@nokia.com" Date: Mon, 12 Mar 2012 10:22:45 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt Thread-Index: Acz9Tgf2TIgAE+DFRRyYsSMxPfD6HgC4nZDA Message-ID: <7A051DFAA46D0246A82293C7CEF621E90686315B98@ESESSCMS0352.eemea.ericsson.se> References: <20120306092627.15924.35232.idtracker@ietfa.amsl.com> <4F566A1C.3040406@alum.mit.edu> <4F573D31.2060304@ericsson.com> <4F579065.60009@alum.mit.edu> <4F58E76F.3030201@alum.mit.edu> In-Reply-To: <4F58E76F.3030201@alum.mit.edu> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.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: Mon, 12 Mar 2012 09:22:55 -0000 Folks As I'm not near to the coding here, I'll not be too opinionated about the c= oding However, both draft-ietf-mmusic-sdp-cs and draft-ietf-cuss-sip-uui-isdn are= drafts that 3GPP is waiting for being finalised. Both drafts are referenced in 3GPP Rel-8, which has been completed years ag= o. Deployments are eagely waiting for both drafts to be completed. Kindly take this into account. thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 8. mars 2012 18:08 To: Simo.Veikkolainen@nokia.com Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt On 3/8/12 8:39 AM, Simo.Veikkolainen@nokia.com wrote: > See below [SV] > > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 7. maaliskuuta 2012 18:44 > To: Miguel A. Garcia > Cc: mmusic@ietf.org; Veikkolainen Simo (Nokia-CTO/Espoo) > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt > > Miguel - comments inline. > > On 3/7/12 5:49 AM, Miguel A. Garcia wrote: >> Hi Paul: >> >> Thanks for your comments, see inline answers. >> >> On 06/03/2012 20:48, Paul Kyzivat wrote: >>> On 3/6/12 4:34 AM, Simo.Veikkolainen@nokia.com wrote: >>>> We have submitted a new version (-10) of Session Description=20 >>>> Protocol >>>> (SDP) Extension For Setting Up Audio and Video Media Streams Over=20 >>>> Circuit-Switched Bearers In The Public Switched Telephone Network=20 >>>> (PSTN), which can be found at=20 >>>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt >>>> >>>> Changes in this version include: >>>> - The port number in "m=3D" line SHOULD be set to "9" (the discard >>>> port) but it MUST be ignored at reception >>>> - Clarified that the Discriminator byte is included in the=20 >>>> cs-correlation:uuie attribute, but we don't specify a value for the=20 >>>> Discriminator byte >>> >>> I know this has been discussed before, but it still bothers me: >>> >>> Is there a reason why the representation of this UUIE is so=20 >>> different from the representation used in draft-ietf-cuss-sip-uui-isdn-= 02? >>> These things are talking about conveying the same thing in the same=20 >>> manner. IMO it would be much better to be consistent about this. >> >> Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User=20 >> SIP header field, whereas this draft uses a "cs-correlation" attribute i= n SDP? > > I'm not talking specifically about the header field. The situation is dif= ferent here - you need to transport this in SDP rather than directly in SIP= . > > What I am talking about is the representation of the UUI value. > draft-ietf-cuss-sip-uui-isdn includes the discriminator byte and encodes = the whole thing in hex. This draft does it differently. ISTM that these oug= ht to use the same representation unless there is some justification for th= e difference. > > [SV] draft-ietf-cuss-sip-uui-04 seems to add encoding, package, and conte= nt parameters to the UUI data itself. The actual content of the UUI seems t= o be the protocol discriminator and uui data (hex encoding preferred), the = same as in sdp-cs draft. For our purposes only the "uui-data" part of the s= yntax in Section 4.1 of draft-ietf-cuss-sip-uui-04 would be needed, and not= the "uui-param". I don't see much benefit in changing the syntax to be the= same in both drafts, but I guess it wouldn't hurt either. All I'm thinking of here is consistency in the representation of the conten= t - that it include the descriminator byte and that it be then encoded in h= ex. At least that way people that are familiar with UUI will be less inclin= ed to get confused. >> If this is the case, I guess there is a justification. The cuss draft=20 >> comes from an angle of making visible in SIP the UUIE in ISDN,=20 >> irrespective of their contents. The goal is to improve=20 >> interoperability between SIP and ISDN. >> >> The CS descriptions drafts needs a correlation mechanism between two=20 >> objects (a CS call and a RTP stream). It offers three mechanisms, of=20 >> which, one happens to be the UUIE. These mechanisms are described in=20 >> an SDP attribute. They are specific for the purpose of correlating=20 >> two media streams. >> >> I think both mechanisms serve different purposes, and the only=20 >> commonality between them is that it happens to be transporting the=20 >> same information. I would not like to see, e.g., that the CS drafts=20 >> uses two correlation mechanisms defined in SDP, and a third one in a SIP= header. >> I don't see the point. > > I am not disputing use of an SDP parameter rather than a SIP header. > >> I don't see any problem in leaving them as they are. >> >> >>> >>> Is it because implementations of this draft have already been deployed? >> >> I am not aware of an implementation of the CS descriptions draft, so=20 >> this should not be a problem. >> >>> >>>> - Added a new example with audio and video streams >>> >>> While its good to seen the new example, as shown it has missed the=20 >>> main issue that will arise, because it only shows the situation when=20 >>> one of the proposed streams is rejected. >>> >>> If both streams are to be accepted, are they to result in one pstn=20 >>> phone call, or two? I would think the intent would be to have only=20 >>> one. But in that case, how is it represented in SDP so that its=20 >>> known that only one call is made? Is there an assumption that if one=20 >>> phone number is used for multiple m-lines, then the same call should be= used for both? >> >> The idea is to have a single PSTN phone call, with audio and video=20 >> components. I haven't heard of requirements indicating other thing. >> >> So, I agree with you that perhaps we ought to describe that for video=20 >> calls, a single PSTN phone call is made. Yes, we miss some text=20 >> there, thanks for catching this up. > > I figured you only had one call in mind. > > But because the phone number is specified in c=3D, which is media level, = there is the potential that audio and video would have differing phone numb= ers, which would presumably exclude a single call. So there should probably= be some explanation of that. Perhaps that there will only be one call per = distinct combination of phone number and cs-correlation attribute. > > Or do you want to exclude the possibility of different phone numbers bein= g supplied? If so, then I might be better to move the phone number from the= c-line to a session level attribute. While its possible to specify the pho= ne number once at session level, its also possible to do it at media level,= where it might end up different. > > [SV] I think only one phone number should be supplied; that is how the ci= rcuit-switched world works. So it might be better to specify the phone num= ber once at session level - for other (IP based) media the address could be= defined at media level, if they ever are offered together. I'm not going to try to second guess you here. But I suppose it might be so= me work to require the phone number to be at session level unless you move = it out of the c=3D line and into something that is only allowed at session = level, like a session-level-only attribute. But if you leave it in the c=3D= line then I think you must address the possibility that multiple c=3D liln= es have different values. At least explicitly call it out and say that beha= vior in that case is explicitly undefined. Thanks, Paul > Also, I would think you would typically want to specify the cs-correlatio= n at session level rather than media level. (In fact you show it that way i= n your new example.) But currently it is defined as being only media level.= So you should probably change that. > > [SV] I agree. > > - Simo > > Thanks, > Paul > >> /Miguel >> >> >>> >>> Thanks, >>> Paul >>> >>>> - Added a new section "Considerations for Usage of Third Party Call=20 >>>> Control (3PCC)" which recommends the Controller to use "-" as the=20 >>>> connection address (to be in line with 0.0.0.0 which is used for IPv4)= . >>>> - Added a new paragraph to security considerations on privacy=20 >>>> concerns that arise from including the phone number in the SDP >>> >>> >>> _______________________________________________ >>> 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 christer.holmberg@ericsson.com Mon Mar 12 03:15: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 014CC21F86D0 for ; Mon, 12 Mar 2012 03:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 G2vwk4qapvVn for ; Mon, 12 Mar 2012 03:15:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE221F865A for ; Mon, 12 Mar 2012 03:15:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-4b-4f5dccd83dfa Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 14.DE.17856.8DCCD5F4; Mon, 12 Mar 2012 11:15:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 12 Mar 2012 11:15:52 +0100 From: Christer Holmberg To: Justin Uberti , "mmusic@ietf.org" Date: Mon, 12 Mar 2012 11:11:21 +0100 Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: Acz9aEOanCQoYphETVG/D/U4mFhBFgC0DW21 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 10:15:55 -0000 Hi Justin, As is indicated in the introduction section of the draft, the usage of the = same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in or= der to allow it, an extension is needed - and BUNDLE is such extension :) I am not sure I understand the break issue. And, what do you mean by "non-BUNDLE endpoint that is already doing multipl= exing"? Do you mean an endpoint that uses the same IP/port for multiple m- = lines? If so, such endpoint breaks the SDP specification. BUT, even if such= endpoints exist, I still don't understand how BUNDLE would break things. Regards, Christer ________________________________ From: Justin Uberti [juberti@google.com] Sent: Thursday, March 08, 2012 10:15 PM To: mmusic@ietf.org Cc: Christer Holmberg; Cullen Jennings Subject: Re: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Christer - One question on BUNDLE. Does anything in SDP/RTP prevent an endpoint from u= sing the same IP/port for media outside of BUNDLE (i.e. multiplexing)? I'm wondering because I think BUNDLE will break if it talks to a non-BUNDLE= endpoint that is already doing multiplexing (of which we have found a few = examples); the BUNDLE endpoint won't be able to demux traffic by 5-tuple. Thoughts? --justin From internet-drafts@ietf.org Mon Mar 12 05:48: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 5D1DC21F87B2; Mon, 12 Mar 2012 05:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 UQVpDDKkc73V; Mon, 12 Mar 2012 05:48:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E175421F87A5; Mon, 12 Mar 2012 05:48:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312124826.6736.25476.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 05:48:26 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-29.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: Mon, 12 Mar 2012 12:48:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-29.txt Pages : 300 Date : 2012-03-12 This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-29.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-29.txt From HKaplan@acmepacket.com Mon Mar 12 09:29:11 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 56E1711E8091 for ; Mon, 12 Mar 2012 09:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 S45otSFTNK4G for ; Mon, 12 Mar 2012 09:29:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A90E511E808F for ; Mon, 12 Mar 2012 09:29:10 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:29:06 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:29:06 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #2: Rules for Answerer payload type selection Thread-Index: AQHNAG09uF2WeKAKIUW5RemaqhyJow== Date: Mon, 12 Mar 2012 16:29:05 +0000 Message-ID: <2053E037-A8A4-4F01-BD3F-3B9FF989E50C@acmepacket.com> References: <063.2ea57b41e0be5050c487b56fc2e0d848@trac.tools.ietf.org> In-Reply-To: <063.2ea57b41e0be5050c487b56fc2e0d848@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8304500BC7B8C146BCB4089D2A698634@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [MMUSIC] [mmusic] #2: Rules for Answerer payload type selection 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, 12 Mar 2012 16:29:11 -0000 I propose we remove the payload types from the: a=3D: =85 attribute, because they are repetitive and complicate the logic, since it's= bizarre to not have them match the m-line (other than for the encap mode, = but that has its own rtpmap anyway). So I propose the offer/answer just have this: a=3Dloopback-source Or a=3Dloopback-mirror without specifying the payload types in those attributes - just use the m-l= ine like normal SDP. -hadriel On Nov 22, 2011, at 3:47 AM, mmusic issue tracker wrote: > #2: Rules for Answerer payload type selection >=20 > From Magnus: >=20 > Section 5.4 > I am missing clear rules for the cases when I might exclude payload > types from loopback-mode attributes compared to the m=3D lines. Are this > only the loopback payload types? What happens if I exclude a regular > media payload format? >=20 > --=20 > -----------------------------+------------------------ > Reporter: hkaplan@=85 | Owner: hkaplan@=85 > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: media-loopback | Version: 1.0 > Severity: In WG Last Call | Keywords: > -----------------------------+------------------------ >=20 > Ticket URL: > mmusic >=20 From HKaplan@acmepacket.com Mon Mar 12 09:33: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 C0CFA21F8721 for ; Mon, 12 Mar 2012 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 L2ZPrYVxR7Li for ; Mon, 12 Mar 2012 09:33:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6D121F846F for ; Mon, 12 Mar 2012 09:33:40 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:33:37 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:33:36 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #4: #4: Multi-stream demultiplexing Thread-Index: AQHNAG3fbjdXAv8vvkm7oGIIHntWJg== Date: Mon, 12 Mar 2012 16:33:35 +0000 Message-ID: References: <063.2b351d5217e1a7d41df6a2b9b08298a8@trac.tools.ietf.org> In-Reply-To: <063.2b351d5217e1a7d41df6a2b9b08298a8@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] [mmusic] #4: #4: Multi-stream demultiplexing 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, 12 Mar 2012 16:33:43 -0000 I propose we simply limit the loopback source to sending only one stream fo= r a given RTP session. There's no need to complicate this further.=20 -hadriel On Jan 31, 2012, at 12:44 PM, mmusic issue tracker wrote: > #4: #4: Multi-stream demultiplexing >=20 > From Magnus: 22. Section 6. > Media loopback, if a loopback source would send more than one stream how > does the loopback mirror indicate which source is which in its return > stream? SDES CNAME could be copied but would be confusing for anyone > monitoring this stream as SSRCs from both end-points would appear to > have the same CNAME. The ssrc-grouping could possibly be used, but I > think one needs to consider the effect of that the SSRCs to be grouped > are not on the same end-point. I don't even know if my SRCNAME proposal > could deal with this case well. >=20 > --=20 > --------------------------+----------------------------------------------= -- > Reporter: hkaplan@=85 | Owner: draft-ietf-mmusic-media-loopbac= k@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: media- | Version: 1.0 > loopback | Keywords: > Severity: In WG Last | > Call | > --------------------------+----------------------------------------------= -- >=20 > Ticket URL: > mmusic >=20 From HKaplan@acmepacket.com Mon Mar 12 09:44:03 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 DBD3B21F87A5 for ; Mon, 12 Mar 2012 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 uIvtG5P53jjV for ; Mon, 12 Mar 2012 09:44:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 448C021F87A8 for ; Mon, 12 Mar 2012 09:44:03 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:44:02 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:44:02 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #5: #5: Marker bit handling Thread-Index: AQHNAG9TqOq4PEwydEycrGyzEhK/dQ== Date: Mon, 12 Mar 2012 16:44:01 +0000 Message-ID: References: <063.e1029da131b62c6b604af950aed417f9@trac.tools.ietf.org> In-Reply-To: <063.e1029da131b62c6b604af950aed417f9@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3184421895CD4A4B97E6988378C03082@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] [mmusic] #5: #5: Marker bit handling 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, 12 Mar 2012 16:44:04 -0000 I propose a variation to Magnus' suggested behavior: all fragment packets h= ave the marker bit set to 1, except the last/final fragment, and all non-fr= agmented do not have it set. This is logically equivalent to Magnus' proposal, just flipping the bit so = that "normal" is 0, exception is 1. (also note that this is for encapsulated-mode, where the packet has an inne= r header bit-field which identifies whether it is fragmented, whether it's = the first fragment, last fragment, etc.) -hadriel On Jan 31, 2012, at 12:45 PM, mmusic issue tracker wrote: > #5: #5: Marker bit handling >=20 > From Magnus: > 23. Section 7.1.1: > Marker (M) bit: If the received RTP packet is looped back in > multiple RTP packets, the M bit is set to 1 in the last packet, > otherwise it is set to 0. >=20 > I don't like this definition as it means that complete non fragment > packets will have a m=3D0 the same as non last fragements. would it not b= e > better to define it so that all packets have m=3D1 except non-last > fragments. >=20 > --=20 > --------------------------+----------------------------------------------= -- > Reporter: hkaplan@=85 | Owner: draft-ietf-mmusic-media-loopbac= k@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: media- | Version: 1.0 > loopback | Keywords: > Severity: In WG Last | > Call | > --------------------------+----------------------------------------------= -- >=20 > Ticket URL: > mmusic >=20 From HKaplan@acmepacket.com Mon Mar 12 09:44:46 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 D7E0C21F87C6 for ; Mon, 12 Mar 2012 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 qyxKIPYJ2b6i for ; Mon, 12 Mar 2012 09:44:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4867621F87C3 for ; Mon, 12 Mar 2012 09:44:46 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:44:45 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:44:45 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #6: Clock-rate per payload type Thread-Index: AQHNAG9t2SuN2/d4HESlu4FdocF0pA== Date: Mon, 12 Mar 2012 16:44:45 +0000 Message-ID: References: <063.51ae082f90ef143996ba440744be8ed8@trac.tools.ietf.org> In-Reply-To: <063.51ae082f90ef143996ba440744be8ed8@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <51BFE8D95BEACF44889CD491C65FDBB3@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] [mmusic] #6: Clock-rate per payload type 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, 12 Mar 2012 16:44:47 -0000 I propose we accept the suggestion. -hadriel On Jan 31, 2012, at 12:48 PM, mmusic issue tracker wrote: > #6: Clock-rate per payload type >=20 > From Magnus: > 24.section 7.1.1.: > The RTP timestamp MUST use the same clock rate used by the > loopback-source. >=20 > I think this needs to be defined as the same clock rate used by the > packet being encapsulated. Otherwise this becomes ambigous when the > loopback source have payload types with multiple rates. >=20 > --=20 > --------------------------+----------------------------------------------= -- > Reporter: hkaplan@=85 | Owner: draft-ietf-mmusic-media-loopbac= k@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: media- | Version: 1.0 > loopback | Keywords: > Severity: In WG Last | > Call | > --------------------------+----------------------------------------------= -- >=20 > Ticket URL: > mmusic >=20 From HKaplan@acmepacket.com Mon Mar 12 09:51:07 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 E00C721E8062 for ; Mon, 12 Mar 2012 09:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 aGJk8hCIitaF for ; Mon, 12 Mar 2012 09:51:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 369B921E8048 for ; Mon, 12 Mar 2012 09:51:07 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:51:04 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:51:04 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #7: Encapsulated packet format Thread-Index: AQHNAHBPYWqlTjRsOEe8sTaxjxtq1Q== Date: Mon, 12 Mar 2012 16:51:04 +0000 Message-ID: <7008E938-7E9D-4555-B2CB-B42DC169F71B@acmepacket.com> References: <063.de10303cc890e70e8d8a6c55265441d8@trac.tools.ietf.org> In-Reply-To: <063.de10303cc890e70e8d8a6c55265441d8@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <139ED2396568654BA9397CB10A7177BF@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] [mmusic] #7: Encapsulated packet format 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, 12 Mar 2012 16:51:08 -0000 Yup, I've read it multiple times and I too think it's confusing. I believe the intent was this=85 you receive an RTP packet "Foo" of this: [ Foo RTP+extensions ][ audio/video payload ] You send back this: [ local RTP+extensions ][ 7.1.2 header ][ Foo RTP+extensions ][ audio/video= payload ] I will try to clarify the text to match that. -hadriel On Jan 31, 2012, at 12:50 PM, mmusic issue tracker wrote: > #7: Encapsulated packet format >=20 > From Magnus: > 25. Section 7.1.2: >=20 > Payload strucutre. I think it is unclear. Which of the following options > do you really want. >=20 > Outer RTP header > (optional CSRC list or Header ext) > Receive timestamp > Inner RTP packet { > - RTP header > - (optional CSRC list or Header ext) > - RTP payload > } >=20 > or >=20 > Outer RTP header > (optional CSRC list or Header ext) > RTP Payload header { > Receive timestamp > Inner RTP packet header fields as specified in 7.1.2 > } > Inner RTP payload >=20 > Note that the second doesn't echo back the extension header >=20 > In general the text is not clear that the inner RTP payload should be > included. >=20 > --=20 > --------------------------+----------------------------------------------= -- > Reporter: hkaplan@=85 | Owner: draft-ietf-mmusic-media-loopbac= k@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: media- | Version: 1.0 > loopback | Keywords: > Severity: In WG Last | > Call | > --------------------------+----------------------------------------------= -- >=20 > Ticket URL: > mmusic >=20 From HKaplan@acmepacket.com Mon Mar 12 09:55: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 00E6E21F85E0 for ; Mon, 12 Mar 2012 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 nn1ZEG0d6RBm for ; Mon, 12 Mar 2012 09:55:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5B68421F8803 for ; Mon, 12 Mar 2012 09:55:54 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:55:38 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:55:38 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #8: Mirrored packet field overwriting Thread-Index: AQHNAHDyr5Kw1usHLk2xlR1XgfXBrA== Date: Mon, 12 Mar 2012 16:55:37 +0000 Message-ID: <6339BF8B-D2A9-4E6B-929E-4C48F76A071B@acmepacket.com> References: <063.36a21c8ae2201648ed1fc600bd2822b5@trac.tools.ietf.org> In-Reply-To: <063.36a21c8ae2201648ed1fc600bd2822b5@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B05830B2D2841478146E2AE23A0DF0C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] [mmusic] #8: Mirrored packet field overwriting 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, 12 Mar 2012 16:55:58 -0000 Yeah I agree with this comment. I propose the padding/extension bits get left alone. -hadriel On Jan 31, 2012, at 12:51 PM, mmusic issue tracker wrote: > #8: Mirrored packet field overwriting >=20 > From Magnus: > 26. Section 7.1.2: > You decide to overwrite the version field in the packet echoed back that > is likely fine, however, why are you overwriting the P and X bits? Why > not include the header extension in what is being echoed back so that > mirror doesn't have to remove them in case they are present. >=20 > --=20 > --------------------------+----------------------------------------------= -- > Reporter: hkaplan@=85 | Owner: draft-ietf-mmusic-media-loopbac= k@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: media- | Version: 1.0 > loopback | Keywords: > Severity: In WG Last | > Call | > --------------------------+----------------------------------------------= -- >=20 > Ticket URL: > mmusic >=20 From HKaplan@acmepacket.com Mon Mar 12 09:57:21 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 CF82C21F87B7 for ; Mon, 12 Mar 2012 09:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 XLJH4LjCNmYy for ; Mon, 12 Mar 2012 09:57:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B015E21F8772 for ; Mon, 12 Mar 2012 09:57:19 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 12:57:18 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 12:57:18 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [mmusic] #11: Padding in mirrored packets Thread-Index: AQHNAHEusTc0adjNK0+uTXMtj9tE1Q== Date: Mon, 12 Mar 2012 16:57:17 +0000 Message-ID: <65765E2A-BDFA-485D-B6D6-613F4C2D57C2@acmepacket.com> References: <063.4bd7c6dda0aff547eeb6d5483307c23f@trac.tools.ietf.org> In-Reply-To: <063.4bd7c6dda0aff547eeb6d5483307c23f@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6CF5F1B286A99C45B4384AF700AF3E05@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [MMUSIC] [mmusic] #11: Padding in mirrored packets 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, 12 Mar 2012 16:57:21 -0000 Probably because the Padding bit was overwritten. ;) Yeah, I don't see the rationale for this either. I propose we leave the padding alone. -hadriel On Jan 31, 2012, at 1:03 PM, mmusic issue tracker wrote: > #11: Padding in mirrored packets >=20 > From Magnus: >=20 > 29. Section 7.1.2: > "Any padding octets in the original packet MUST NOT be included in > the loopback packet generated by a loopback-mirror." >=20 > What is the motivation behind this? If the reason I want to do packet > loopback is to find out if somebody is manipulating the packets between > the source and the mirror you need to include the whole packet as it is, > not throw away parts of it. What if padding is added or removed on path. > That might matter for the one doing the active measurement. >=20 > --=20 > --------------------------+----------------------------------------------= -- > Reporter: hkaplan@=85 | Owner: draft-ietf-mmusic-media-loopbac= k@=85 > Type: defect | Status: new > Priority: minor | Milestone: milestone1 > Component: media- | Version: 1.0 > loopback | Keywords: > Severity: In WG Last | > Call | > --------------------------+----------------------------------------------= -- >=20 > Ticket URL: > mmusic >=20 From juberti@google.com Mon Mar 12 09:59:06 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 92CA321F87D3 for ; Mon, 12 Mar 2012 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gIt83s+lJqmp for ; Mon, 12 Mar 2012 09:59:05 -0700 (PDT) Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B07321F87A8 for ; Mon, 12 Mar 2012 09:59:04 -0700 (PDT) Received: by faaa25 with SMTP id a25so202694faa.31 for ; Mon, 12 Mar 2012 09:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=tn+wG12xvmh3vqZ6vwvo0WAK1tJBQgtGhyJOKoIw7BA=; b=YRXyXQK72jtGGhE/yYlchWAo58GFpxfaNMFndmoRtCqrHgz3Ns3yolmBRObyDaZt0f XHR4It6hqfLex0F+iDsfd8z/IU2rUBdaIBuOIIeMAjktt8qLtTmxar6m0KBCmrU3cGen EY+/GbdAtDgrLgxT2luj0iD06nfIlU2NmdBDanP3zFL+3rh8FO+97T7DvtikB6jyOJZz ZdiJO7x4RWDdfKN8FSUo4TO1mpV7XEjtZGOBA768wqutoxvVXEZNIbjZLu29J+Su6Onl s6KrRzpzqSaevTx2d2A1OtEh4EunOhFSqO0bA7AfD7nIJKCYaW8Iy490ALjRLF6yUv+T TsBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=tn+wG12xvmh3vqZ6vwvo0WAK1tJBQgtGhyJOKoIw7BA=; b=BXDwdVtdiyRC0D31c6T0sLwxWh/JpEqDTkA0a9bGa3CHuXfitz0xus/gJAs8+0lloa +ltgKMlkDqUu6XfqXQqwhmsBW1vSm7ZuGOXxi1gG6RyKAAilZh+an9VUlvfgyWXFUqHa qFFQOL2TwpjsbpJzpVQiFA4bCzrnjSFAVsJ2NYnhcYvDnonESGnGCSIs35rIeI13+z51 dAbDOMJHYXVpuKlEQSaE/bTTnSRHbjSYaCfgem3p60W/v01aYf3B1QqJM9IVehHIKMXM FSA4te4rYocOcBhqTw7eVjz1+UKHjLxtGqopE5vlIxOHKSfm07pxwWS8v2jiGfObCZYC LIfA== Received: by 10.224.183.133 with SMTP id cg5mr8762111qab.88.1331571542371; Mon, 12 Mar 2012 09:59:02 -0700 (PDT) Received: by 10.224.183.133 with SMTP id cg5mr8762100qab.88.1331571542280; Mon, 12 Mar 2012 09:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Mon, 12 Mar 2012 09:58:42 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Mon, 12 Mar 2012 12:58:42 -0400 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf302d4d72c54c0a04bb0ea871 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmxzmFQ8+H1KPbNXXBkwzh6x1YBcSWHy0sVfJXSNdJf2lsHnvow7tlUuhw82Ec7aNMPrFK9aqfl400YpouUMxk8ojv3Wf8inLkIWp0EfaoEse7hi5fvBFNq/yUr/LIo37diKAyJ Cc: Cullen Jennings , "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 16:59:06 -0000 --20cf302d4d72c54c0a04bb0ea871 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 12, 2012 at 6:11 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Justin, > > As is indicated in the introduction section of the draft, the usage of the > same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in > order to allow it, an extension is needed - and BUNDLE is such extension :) > Right, but my question is whether it is forbidden, or merely unspecified. Consider the case of a gateway, which predates BUNDLE and thinks it is being clever by doing BUNDLE-type multiplexing (demuxing by remote address) without signaling this in any way, other than the same port for each m= line. This gateway would work with existing clients, but break when it talks to a BUNDLE client, even though BUNDLE is not negotiated, since it can't demux by remote address. One reason for such gateways to exist would be to allow media to be sent to a known "common" port, such as port 443. > I am not sure I understand the break issue. > > And, what do you mean by "non-BUNDLE endpoint that is already doing > multiplexing"? Do you mean an endpoint that uses the same IP/port for > multiple m- lines? If so, such endpoint breaks the SDP specification. BUT, > even if such endpoints exist, I still don't understand how BUNDLE would > break things. > Yes, an endpoint that uses the same IP/port for multiple m= lines. > > Regards, > > Christer > > ________________________________ > From: Justin Uberti [juberti@google.com] > Sent: Thursday, March 08, 2012 10:15 PM > To: mmusic@ietf.org > Cc: Christer Holmberg; Cullen Jennings > Subject: Re: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt > > Christer - > > One question on BUNDLE. Does anything in SDP/RTP prevent an endpoint from > using the same IP/port for media outside of BUNDLE (i.e. multiplexing)? > > I'm wondering because I think BUNDLE will break if it talks to a > non-BUNDLE endpoint that is already doing multiplexing (of which we have > found a few examples); the BUNDLE endpoint won't be able to demux traffic > by 5-tuple. > > Thoughts? > > --justin > --20cf302d4d72c54c0a04bb0ea871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 12, 2012 at 6:11 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:
Hi Justin,

As is indicated in the introduction section of the draft, the usage of the = same IP/port for multiple m- lines is "unspecified" in SDP. There= for, in order to allow it, an extension is needed - and BUNDLE is such exte= nsion :)

Right, but my question is whether it is fo= rbidden, or merely unspecified. Consider the case of a gateway, which preda= tes BUNDLE and thinks it is being clever by doing BUNDLE-type multiplexing = (demuxing by remote address) without signaling this in any way, other than = the same port for each m=3D line. This gateway would work with existing cli= ents, but break when it talks to a BUNDLE client, even though BUNDLE is not= negotiated, since it can't demux by remote address.

One reason for such gateways to exist would be to allow= media to be sent to a known "common" port, such as port 443.


I am not sure I understand the break issue.

And, what do you mean by "non-BUNDLE endpoint that is already doing mu= ltiplexing"? Do you mean an endpoint that uses the same IP/port for mu= ltiple m- lines? If so, such endpoint breaks the SDP specification. BUT, ev= en if such endpoints exist, I still don't understand how BUNDLE would b= reak things.

Yes, an endpoint that uses the same IP/por= t for multiple m=3D lines.=C2=A0

Regards,

Christer

________________________________
From: Justin Uberti [juberti@google.c= om]
Sent: Thursday, March 08, 2012 10:15 PM
To: mmusic@ietf.org
Cc: Christer Holmberg; Cullen Jennings
Subject: Re: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt

Christer -

One question on BUNDLE. Does anything in SDP/RTP prevent an endpoint from u= sing the same IP/port for media outside of BUNDLE (i.e. multiplexing)?

I'm wondering because I think BUNDLE will break if it talks to a non-BU= NDLE endpoint that is already doing multiplexing (of which we have found a = few examples); the BUNDLE endpoint won't be able to demux traffic by 5-= tuple.

Thoughts?

--justin

--20cf302d4d72c54c0a04bb0ea871-- From pkyzivat@alum.mit.edu Mon Mar 12 11:04: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 AD3FA21F8968 for ; Mon, 12 Mar 2012 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 45d5Vt+FnmEM for ; Mon, 12 Mar 2012 11:04:53 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18621F8963 for ; Mon, 12 Mar 2012 11:04:52 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id khpj1i0031ap0As5Bi4tLV; Mon, 12 Mar 2012 18:04:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id ki4t1i00f07duvL3ii4tk6; Mon, 12 Mar 2012 18:04:53 +0000 Message-ID: <4F5E3AC2.7070600@alum.mit.edu> Date: Mon, 12 Mar 2012 14:04:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120312070303.18937.55225.idtracker@ietfa.amsl.com> <4F5DA093.7020900@ericsson.com> In-Reply-To: <4F5DA093.7020900@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-01.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: Mon, 12 Mar 2012 18:04:53 -0000 On 3/12/12 3:06 AM, Salvatore Loreto wrote: > Hi there, > > I have submitted a new version of the draft, that other then fix some > little mistakes > define the DTLS/SCTP protocol identifier > to allow the usage of SCTP on top of the Datagram Transport Layer > Security (DTLS) protocol, > as defined in [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP. > > SCTP over DTLS is used by the RTCWeb protocol suite for transporting > non-media data between browsers. > > regards > Salvatore Generally this seems good, but I see a mistake (copy/paste error?) in Section 7.2: Throughout this section (two occurrences) s/connection:new/connection:existing/ Thanks, Paul From christer.holmberg@ericsson.com Mon Mar 12 11:33: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 B8E7721E804A for ; Mon, 12 Mar 2012 11:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.237 X-Spam-Level: X-Spam-Status: No, score=-10.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 H0JOnv--ZJjR for ; Mon, 12 Mar 2012 11:33:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E509321E803B for ; Mon, 12 Mar 2012 11:33:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-f1-4f5e4168b424 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E1.10.27041.8614E5F4; Mon, 12 Mar 2012 19:33:12 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 12 Mar 2012 19:33:12 +0100 From: Christer Holmberg To: Justin Uberti Date: Mon, 12 Mar 2012 19:33:11 +0100 Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: Ac0AcW1qmpmwXDBpTouFKqEHIZcjWAACoQhl Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A5644@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 18:33:14 -0000 Hi, >> As is indicated in the introduction section of the draft, the usage of t= he same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in >> order to allow it, an extension is needed - and BUNDLE is such extension= :) > > > Right, but my question is whether it is forbidden, or merely unspecified. I don't think it's forbidden, but as the semantics is undefined, it's not v= ery useful. RFC 4566 (SDP) says: "The semantics of multiple "m=3D" lines using the same transport address are undefined. This implies that, unlike limited past practice, there is no implicit grouping defined by such means and an explicit grouping framework (for example, [18]) should instead be used to express the intended semantics." So, I think it is very clear that an extension, which defines the semantics= , is needed. > Consider the case of a gateway, which predates BUNDLE and thinks it is be= ing clever by doing BUNDLE-type > multiplexing (demuxing by remote address) without signaling this in any w= ay, other than the same port > for each m=3D line. This gateway would work with existing clients, ...unless the clients will reject the SDP. And, as we know from recent discussions, RTP multiplexing is not only about= the port and address. It's about single vs multiple RTP sessions, how the = multiplexing is implemented on the RTP level, etc etc etc. Without mechanis= ms to negotiate/indicate such things I am not sure how things would work. > but break when it talks to a BUNDLE client, even though BUNDLE is not ne= gotiated, since it can't demux by remote address. > > One reason for such gateways to exist would be to allow media to be sent = to a known "common" port, such as port 443. Again, such gateways are not standards compliant, in my opinion. Having said that, however, a BUNDLE implementation can always choose to acc= ept the same address/port in the remote SDP even if BUNDLE is not indicated= . Regards, Christer From juberti@google.com Mon Mar 12 11:55:56 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 AC97F21E8067 for ; Mon, 12 Mar 2012 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 tYZURi913tAP for ; Mon, 12 Mar 2012 11:55:55 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51E7321E8066 for ; Mon, 12 Mar 2012 11:55:55 -0700 (PDT) Received: by eeke51 with SMTP id e51so1474768eek.31 for ; Mon, 12 Mar 2012 11:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=QiBqz+iznaSIFc0ftXC7Xvk98wD+5Qlz/RIDhT+iGe4=; b=AlwAoBk94la/cjA94tPaehDCFe2ImSPa9zbOuzjRHBNMRhwUdkEAjfWO+FN8zSwXZP YIQMDXZO9xubA4r+YtM4ZKhJ4sAtadFIl8SXcEEqFb9MvdXGlZGizKqEGbhhDia6MbB6 duZgZL9Saya3eNDZqkvDFqlVhcgyzn9cIIMUZ3SzNqUqORUpIDuMlrCDmrStCweBQguN nD9YdKWXpu+FCcR0F2w0lL6gBIyx7jqgzNsVy3fOS5z3OQ+CCePiSIHYS3T4FpxtFN0e di3WKvo6h+M0VQdpUWnPJmi7hXHXmfSBmSsF5Uf5hH8dmuq7ecljU4R5wfKGdoI1Ga+e CDKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=QiBqz+iznaSIFc0ftXC7Xvk98wD+5Qlz/RIDhT+iGe4=; b=lv4dnrb2PiUpxeSFbQqo0zTVGzqE665gqr4hEObG/8QGj9CnanbIgbWmNS2HrIvXlI 6phZ1v4ZsQLlCea9c2HPi8LnRYN+2xW+UIwB8AYL5amu3fzcyoFvg3jOiUi1zYJ3aoqn uLPyhLtiTzEivp09uHtmtG7/HF5CLtatJDRyabpOjtxB86Gk4Dy37aHGHvXozAsUQuRu px6LYUNDwmZkMlpKztLSkRdu0fcQHm8C5pPz/ipWu+pWxj9lsyLzqb49KRr6r7cop7oJ 8R+ofNTWeax+depuagMWZiKBfeks7s39+l0pyq8A+PTQghEslCCRHz120/vh24iOD75m TQmw== Received: by 10.229.136.10 with SMTP id p10mr2857408qct.46.1331578553597; Mon, 12 Mar 2012 11:55:53 -0700 (PDT) Received: by 10.229.136.10 with SMTP id p10mr2857394qct.46.1331578553303; Mon, 12 Mar 2012 11:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Mon, 12 Mar 2012 11:55:33 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C411A5644@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C411A5644@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Mon, 12 Mar 2012 14:55:33 -0400 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00248c6a6646a902e104bb104a70 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmJftceK1PLno959xHaOh74/9/Ct8K+Ad86JvJu8+A9i3ArkK9cuYa4v7XEWR4eSHF2xrb7RloTmNg+8GhPjqcI6GaPaJJbOtCP/VMZmqM9uB0bXAzxxJCaatROHrdkG0uL5vOy Cc: Cullen Jennings , Bernard Aboba , "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 18:55:56 -0000 --00248c6a6646a902e104bb104a70 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 12, 2012 at 2:33 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> As is indicated in the introduction section of the draft, the usage of > the same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, in > >> order to allow it, an extension is needed - and BUNDLE is such > extension :) > > > > > > Right, but my question is whether it is forbidden, or merely unspecified. > > I don't think it's forbidden, but as the semantics is undefined, it's not > very useful. > In the course of our BUNDLE implementation, we (Google) noticed that we are using these kinds of gateways, so this functionality is useful in at least some situations. I suspect we are not the only ones to find it useful. > > RFC 4566 (SDP) says: > > "The semantics of multiple "m=" lines using the same transport > address are undefined. This implies that, unlike limited past > practice, there is no implicit grouping defined by such means and > an explicit grouping framework (for example, [18]) should instead > be used to express the intended semantics." > > So, I think it is very clear that an extension, which defines the > semantics, is needed. > I am not questioning the usefulness of BUNDLE, which I think is very important. But this edge case affects us, and it may affect other existing applications or devices. > Consider the case of a gateway, which predates BUNDLE and thinks it is > being clever by doing BUNDLE-type > > multiplexing (demuxing by remote address) without signaling this in any > way, other than the same port > > for each m= line. This gateway would work with existing clients, > > ...unless the clients will reject the SDP. > > And, as we know from recent discussions, RTP multiplexing is not only > about the port and address. It's about single vs multiple RTP sessions, how > the multiplexing is implemented on the RTP level, etc etc etc. Without > mechanisms to negotiate/indicate such things I am not sure how things would > work. > I agree, if both sides are muxing. If only one side is muxing (the case I am referring to here), it is clear there are multiple RTP sessions, and this can all be handled without knowledge of the RTP details. > > > but break when it talks to a BUNDLE client, even though BUNDLE is not > negotiated, since it can't demux by remote address. > > > > One reason for such gateways to exist would be to allow media to be sent > to a known "common" port, such as port 443. > > Again, such gateways are not standards compliant, in my opinion. > Perhaps, but they exist, at least to some extent. The question is, what can we do about it? Ideally, BUNDLE would find some way to work even when talking to something that is expecting different source ports. > > Having said that, however, a BUNDLE implementation can always choose to > accept the same address/port in the remote SDP even if BUNDLE is not > indicated. > This will not work since the gateway will not have provided the BUNDLE implementation with the necessary SSRC information to demux, and it won't understand the SSRC information the BUNDLE client sends to it. > > Regards, > > Christer > --00248c6a6646a902e104bb104a70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 12, 2012 at 2:33 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>> As is indicated in the introduction section of the draft, the usag= e of the same IP/port for multiple m- lines is "unspecified" in S= DP. Therefor, in
>> order to allow it, an extension is needed - and BUNDLE is such ext= ension :)
>
>
> Right, but my question is whether it is forbidden, or merely unspecifi= ed.

I don't think it's forbidden, but as the semantics is undefin= ed, it's not very useful.

In the co= urse of our BUNDLE implementation, we (Google) noticed that we are using th= ese kinds of gateways, so this functionality is useful in at least some sit= uations. I suspect we are not the only ones to find it useful.

RFC 4566 (SDP) says:

=C2=A0 =C2=A0 =C2=A0"The semantics of multiple "m=3D" lines= using the same transport
=C2=A0 =C2=A0 =C2=A0address are undefined. =C2=A0This implies that, unlike= limited past
=C2=A0 =C2=A0 =C2=A0practice, there is no implicit grouping defined by suc= h means and
=C2=A0 =C2=A0 =C2=A0an explicit grouping framework (for example, [18]) sho= uld instead
=C2=A0 =C2=A0 =C2=A0be used to express the intended semantics."

So, I think it is very clear that an extension, which defines the semantics= , is needed.

I am not questioning the u= sefulness of BUNDLE, which I think is very important. But this edge case af= fects us, and it may affect other existing applications or devices.

> Consider the case of a gateway, which predates BUNDL= E and thinks it is being clever by doing BUNDLE-type
> multiplexing (demuxing by remote address) without signaling this in an= y way, other than the same port
> for each m=3D line. This gateway would work with existing clients,

...unless the clients will reject the SDP.

And, as we know from recent discussions, RTP multiplexing is not only about= the port and address. It's about single vs multiple RTP sessions, how = the multiplexing is implemented on the RTP level, etc etc etc. Without mech= anisms to negotiate/indicate such things I am not sure how things would wor= k.

I agree, if both sides are muxing. If only= one side is muxing (the case I am referring to here), it is clear there ar= e multiple RTP sessions, and this can all be handled without knowledge of t= he RTP details.=C2=A0

> but break when it talks to a BUNDLE client, even =C2=A0though BUNDLE i= s not negotiated, since it can't demux by remote address.
>
> One reason for such gateways to exist would be to allow media to be se= nt to a known "common" port, such as port 443.

Again, such gateways are not standards compliant, in my opinion.
<= /blockquote>

Perhaps, but they exist, at least to some e= xtent. The question is, what can we do about it? Ideally, BUNDLE would find= some way to work even when talking to something that is expecting differen= t source ports.

Having said that, however, a BUNDLE implementation can always choose to acc= ept the same address/port in the remote SDP even if BUNDLE is not indicated= .

This will not work since the gateway = will not have provided the BUNDLE implementation with the necessary SSRC in= formation to demux, and it won't understand the SSRC information the BU= NDLE client sends to it.

Regards,

Christer

--00248c6a6646a902e104bb104a70-- From christer.holmberg@ericsson.com Mon Mar 12 12:21: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 874FD21F89BC for ; Mon, 12 Mar 2012 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 JRJ8+8CzmPI1 for ; Mon, 12 Mar 2012 12:21:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E321F89BA for ; Mon, 12 Mar 2012 12:21:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-5a-4f5e4cbcb195 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8A.D8.17856.CBC4E5F4; Mon, 12 Mar 2012 20:21:33 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 12 Mar 2012 20:21:32 +0100 From: Christer Holmberg To: Justin Uberti Date: Mon, 12 Mar 2012 20:21:31 +0100 Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: Ac0AgcCVVgqu0K+TQdy3WcOs70fmhwAAGEst Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A5645@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C411A5644@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Bernard Aboba , "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 19:21:35 -0000 Hi, >>>> As is indicated in the introduction section of the draft, the usage of= the same IP/port for multiple m- lines is "unspecified" in SDP. Therefor, = in >>>> order to allow it, an extension is needed - and BUNDLE is such extensi= on :) >>> >>> >>> Right, but my question is whether it is forbidden, or merely unspecifie= d. >> >> I don't think it's forbidden, but as the semantics is undefined, it's no= t very useful. >> > In the course of our BUNDLE implementation, we (Google) noticed that we a= re using these kinds of gateways, so this functionality=20 > is useful in at least some situations. I suspect we are not the only ones= to find it useful. > >> RFC 4566 (SDP) says: >> >> "The semantics of multiple "m=3D" lines using the same transport >> address are undefined. This implies that, unlike limited past >> practice, there is no implicit grouping defined by such means and >> an explicit grouping framework (for example, [18]) should instead >> be used to express the intended semantics." >> >> So, I think it is very clear that an extension, which defines the semant= ics, is needed. > > I am not questioning the usefulness of BUNDLE, which I think is very impo= rtant. But this edge=20 > case affects us, and it may affect other existing applications or devices= . > >>>> Consider the case of a gateway, which predates BUNDLE and thinks it is= being clever by doing BUNDLE-type >>>> multiplexing (demuxing by remote address) without signaling this in an= y way, other than the same port >>>> for each m=3D line. This gateway would work with existing clients, >>> >>> ...unless the clients will reject the SDP. >> >> And, as we know from recent discussions, RTP multiplexing is not only ab= out the port and address. It's about single vs multiple RTP sessions, how=20 >> the multiplexing is implemented on the RTP level, etc etc etc. Without m= echanisms to negotiate/indicate such things I am not sure how things=20 >> would work. > > I agree, if both sides are muxing. If only one side is muxing (the case I= am referring to here), it is clear there are multiple RTP sessions, and=20 > this can all be handled without knowledge of the RTP details.=20 > > but break when it talks to a BUNDLE client, even though BUNDLE is not ne= gotiated, since it can't demux by remote address. > > One reason for such gateways to exist would be to allow media to be sent = to a known "common" port, such as port 443. > > Again, such gateways are not standards compliant, in my opinion. > > Perhaps, but they exist, at least to some extent. The question is, what c= an we do about it? Ideally, BUNDLE would find some way to work even when ta= lking to something that is expecting different source ports. > >> Having said that, however, a BUNDLE implementation can always choose to = accept the same address/port in the remote SDP even if BUNDLE is not indica= ted. > > This will not work since the gateway will not have provided the BUNDLE im= plementation with the necessary SSRC information to demux, and it won't=20 > understand the SSRC information the BUNDLE client sends to it. So, the gateway wants to use the same local address/port, and it *expects*= the remote side to use separate address/ports, right? If so, what do these gateways do if they still receive SDP with the same lo= cal address/port? I guess we could always say that if a BUNDLE client *receives* a non-BUNDLE= offer, but still with the same local address/port, it must reply with diff= erent address/ports - eventhough we normally don't specify procedures based= on non-standard behaviors. And, if a BUNDLE client *sends* a BUNDLE offer, I assume the gateway would = reject it, and in that case I think the draft already says that the BUNDLE = client should send a new non-BUNDLE offer. Regards, Christer Regards, Christer= From pkyzivat@alum.mit.edu Mon Mar 12 12:38: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 B89C621E809A for ; Mon, 12 Mar 2012 12:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 6xvyn2-8LVI2 for ; Mon, 12 Mar 2012 12:38:33 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 068F021E808F for ; Mon, 12 Mar 2012 12:38:32 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id kiuA1i0061uE5Es56jeZgb; Mon, 12 Mar 2012 19:38:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id kjeZ1i00B07duvL3cjeZ2Z; Mon, 12 Mar 2012 19:38:33 +0000 Message-ID: <4F5E50B7.8040304@alum.mit.edu> Date: Mon, 12 Mar 2012 15:38:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C411A5644@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 19:38:33 -0000 On 3/12/12 2:55 PM, Justin Uberti wrote: > > > On Mon, Mar 12, 2012 at 2:33 PM, Christer Holmberg > > > wrote: > > Hi, > > >> As is indicated in the introduction section of the draft, the > usage of the same IP/port for multiple m- lines is "unspecified" in > SDP. Therefor, in > >> order to allow it, an extension is needed - and BUNDLE is such > extension :) > > > > > > Right, but my question is whether it is forbidden, or merely > unspecified. > > I don't think it's forbidden, but as the semantics is undefined, > it's not very useful. > > > In the course of our BUNDLE implementation, we (Google) noticed that we > are using these kinds of gateways, so this functionality is useful in at > least some situations. I suspect we are not the only ones to find it useful. Probably not. But all all those currently using this undefined behavior using it in consistent ways? Thanks, Paul From Martin.Stiemerling@neclab.eu Mon Mar 12 12:40:56 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 C9BF621E809F for ; Mon, 12 Mar 2012 12:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 bQ+xJ5OdmLLt for ; Mon, 12 Mar 2012 12:40:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C13C621E809D for ; Mon, 12 Mar 2012 12:40:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 52AD1100863 for ; Mon, 12 Mar 2012 20:41:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogHD+2Mbwg5P for ; Mon, 12 Mar 2012 20:41:04 +0100 (CET) Received: from ENCELADUS.office.hd (unknown [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 31E91100857 for ; Mon, 12 Mar 2012 20:40:59 +0100 (CET) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 20:40:28 +0100 Message-ID: <4F5E5128.9080001@neclab.eu> Date: Mon, 12 Mar 2012 20:40:24 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <20120312124826.6736.25476.idtracker@ietfa.amsl.com> In-Reply-To: <20120312124826.6736.25476.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-29.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: Mon, 12 Mar 2012 19:40:56 -0000 Dear all, There is finally an updated RTSP 2.0 draft which incorporates all comments we have received during the WGLC. Thanks to the reviewers and especially to Flemming for his very extensive review. Please review the changes. Martin On 03/12/2012 01:48 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Real Time Streaming Protocol 2.0 (RTSP) > Author(s) : Henning Schulzrinne > Anup Rao > Rob Lanphier > Magnus Westerlund > Martin Stiemerling > Filename : draft-ietf-mmusic-rfc2326bis-29.txt > Pages : 300 > Date : 2012-03-12 > > This memorandum defines RTSP version 2.0 which obsoletes RTSP version > 1.0 defined in RFC 2326. > > The Real Time Streaming Protocol, or RTSP, is an application-level > protocol for setup and control of the delivery of data with real-time > properties. RTSP provides an extensible framework to enable > controlled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 3550). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-29.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-29.txt > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From juberti@google.com Mon Mar 12 12:56:27 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 6C6CD21E808F for ; Mon, 12 Mar 2012 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.785 X-Spam-Level: X-Spam-Status: No, score=-102.785 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Huflpw261oJQ for ; Mon, 12 Mar 2012 12:56:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1282721E80BA for ; Mon, 12 Mar 2012 12:56:25 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1496227eaa.31 for ; Mon, 12 Mar 2012 12:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=IyyPdKqWDcpAr+im3OL3h6lpOCAXkdbvJ2GhV1wCns0=; b=oYgNzHQ9Uek6vmLHRb1epXN4W0IboJO+A5iw8/uj3A7Jh8/4G07bbWG7PW2NkG7Ou1 +++gMcuwA+WepU1QV7BtQh4sRbteBaO3fkKusrNthQ8X84wV8PVjI64dFFQ5ENOZDAUo E/2q44nrrSNUVxcYm/Vpr/mjkJxEKt7sQnDntZJMYZn0einsc8KMdOCElhD5cMHTzTWU PVEp0ORpc25Yjes887xdHeWxv6+4if7KjAUgpopYIJu+Uu3O1zGgY9iNhDZ/mK2yQJdu fnFeN4fESH8Euj3ghzRq8A824Jalpuma4hTRrybZdfIso9ng11AoAU3qTLK5bwp8y5iq ///w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=IyyPdKqWDcpAr+im3OL3h6lpOCAXkdbvJ2GhV1wCns0=; b=DeJOervaVWk33eRAymnfLWM4qD9cMH/OJi/CllaSr/gT01xnF7jFrtmTTw6M+zeMtq 6e7B6oYv2NGveffQrSRStgDdYzEI8bzZwvWLY7wrXGdHPyfznnGIJXCuPEQBMIuKZ9AG rNxpvxLLJHmxWHl5taSmfQ1wEVi5u3NTswen5NGxbWsBfvRBFSQk+wnGsGTxKmcgF0YX MGLP7lqqCZLTdKsz6N9fKGwFulBDkT+IoIPS/Vc8eEUVUyt/LeB0Zd/CwJDtBqqt8SAx AWaxBRkoQV6mwjPoIsyY0r0ysEjoyBGKp2qPmCSFO3Czjj+Oxrw6F/+QY6j95hNWpQtb 706g== Received: by 10.229.136.10 with SMTP id p10mr2929111qct.46.1331582184537; Mon, 12 Mar 2012 12:56:24 -0700 (PDT) Received: by 10.229.136.10 with SMTP id p10mr2929093qct.46.1331582184221; Mon, 12 Mar 2012 12:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.161.134 with HTTP; Mon, 12 Mar 2012 12:56:04 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C411A5645@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C411A563F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C411A5644@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C411A5645@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Mon, 12 Mar 2012 15:56:04 -0400 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=00248c6a6646146b0804bb11239f X-System-Of-Record: true X-Gm-Message-State: ALoCoQlmD+UmSfcsMnRoxVmdp0sAJ4x7f48FABYuJhUUH+WvBGXUjLWhNyvWcMqYsgdfcy0xqS2vQ3FTPq1K0ZJv9Co4tCTFXax67Ep/6/DYkR+RxKsKWhuCi7rUflW3pm+sbBP1lPIN Cc: Cullen Jennings , Bernard Aboba , "mmusic@ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.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: Mon, 12 Mar 2012 19:56:27 -0000 --00248c6a6646146b0804bb11239f Content-Type: text/plain; charset=UTF-8 On Mon, Mar 12, 2012 at 3:21 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >>>> As is indicated in the introduction section of the draft, the usage > of the same IP/port for multiple m- lines is "unspecified" in SDP. > Therefor, in > >>>> order to allow it, an extension is needed - and BUNDLE is such > extension :) > >>> > >>> > >>> Right, but my question is whether it is forbidden, or merely > unspecified. > >> > >> I don't think it's forbidden, but as the semantics is undefined, it's > not very useful. > >> > > In the course of our BUNDLE implementation, we (Google) noticed that we > are using these kinds of gateways, so this functionality > > is useful in at least some situations. I suspect we are not the only > ones to find it useful. > > > >> RFC 4566 (SDP) says: > >> > >> "The semantics of multiple "m=" lines using the same transport > >> address are undefined. This implies that, unlike limited past > >> practice, there is no implicit grouping defined by such means and > >> an explicit grouping framework (for example, [18]) should instead > >> be used to express the intended semantics." > >> > >> So, I think it is very clear that an extension, which defines the > semantics, is needed. > > > > I am not questioning the usefulness of BUNDLE, which I think is very > important. But this edge > > case affects us, and it may affect other existing applications or > devices. > > > >>>> Consider the case of a gateway, which predates BUNDLE and thinks it > is being clever by doing BUNDLE-type > >>>> multiplexing (demuxing by remote address) without signaling this in > any way, other than the same port > >>>> for each m= line. This gateway would work with existing clients, > >>> > >>> ...unless the clients will reject the SDP. > >> > >> And, as we know from recent discussions, RTP multiplexing is not only > about the port and address. It's about single vs multiple RTP sessions, how > >> the multiplexing is implemented on the RTP level, etc etc etc. Without > mechanisms to negotiate/indicate such things I am not sure how things > >> would work. > > > > I agree, if both sides are muxing. If only one side is muxing (the case > I am referring to here), it is clear there are multiple RTP sessions, and > > this can all be handled without knowledge of the RTP details. > > > > but break when it talks to a BUNDLE client, even though BUNDLE is not > negotiated, since it can't demux by remote address. > > > > One reason for such gateways to exist would be to allow media to be sent > to a known "common" port, such as port 443. > > > > Again, such gateways are not standards compliant, in my opinion. > > > > Perhaps, but they exist, at least to some extent. The question is, what > can we do about it? Ideally, BUNDLE would find some way to work even when > talking to something that is expecting different source ports. > > > >> Having said that, however, a BUNDLE implementation can always choose to > accept the same address/port in the remote SDP even if BUNDLE is not > indicated. > > > > This will not work since the gateway will not have provided the BUNDLE > implementation with the necessary SSRC information to demux, and it won't > > understand the SSRC information the BUNDLE client sends to it. > > So, the gateway wants to use the same local address/port, and it > *expects* the remote side to use separate address/ports, right? > Yes, I believe it assumes this will be the case. > > If so, what do these gateways do if they still receive SDP with the same > local address/port? > I haven't tested yet, but I assume they end up picking one source address and ignoring the traffic from the other one. > > I guess we could always say that if a BUNDLE client *receives* a > non-BUNDLE offer, but still with the same local address/port, it must reply > with different address/ports - eventhough we normally don't specify > procedures based on non-standard behaviors. > OK. > > And, if a BUNDLE client *sends* a BUNDLE offer, I assume the gateway would > reject it, and in that case I think the draft already says that the BUNDLE > client should send a new non-BUNDLE offer. > > It's not optimal, since it requires a new allocation of candidates, but I think this would work for this scenario. This implies that WebRTC needs some way to control local use of BUNDLE. The same approach would also have to be used for another edge case where a BUNDLE client communicates with a non-BUNDLE client that uses a TURN server that demultiplexes off of a single port (e.g. 443). Thanks, --justin --00248c6a6646146b0804bb11239f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 12, 2012 at 3:21 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

>>>> As is indicated in the introduction section of the draft, = the usage of the same IP/port for multiple m- lines is "unspecified&qu= ot; in SDP. Therefor, in
>>>> order to allow it, an extension is needed - and BUNDLE is = such extension :)
>>>
>>>
>>> Right, but my question is whether it is forbidden, or merely u= nspecified.
>>
>> I don't think it's forbidden, but as the semantics is unde= fined, it's not very useful.
>>
> In the course of our BUNDLE implementation, we (Google) noticed that w= e are using these kinds of gateways, so this functionality
> is useful in at least some situations. I suspect we are not the only o= nes to find it useful.
>
>> RFC 4566 (SDP) says:
>>
>> =C2=A0 =C2=A0 "The semantics of multiple "m=3D" lin= es using the same transport
>> =C2=A0 =C2=A0 address are undefined. =C2=A0This implies that, unli= ke limited past
>> =C2=A0 =C2=A0 practice, there is no implicit grouping defined by s= uch means and
>> =C2=A0 =C2=A0 an explicit grouping framework (for example, [18]) s= hould instead
>> =C2=A0 =C2=A0 be used to express the intended semantics."
>>
>> So, I think it is very clear that an extension, which defines the = semantics, is needed.
>
> I am not questioning the usefulness of BUNDLE, which I think is very i= mportant. But this edge
> case affects us, and it may affect other existing applications or devi= ces.
>
>>>> Consider the case of a gateway, which predates BUNDLE and = thinks it is being clever by doing BUNDLE-type
>>>> multiplexing (demuxing by remote address) without signalin= g this in any way, other than the same port
>>>> for each m=3D line. This gateway would work with existing = clients,
>>>
>>> ...unless the clients will reject the SDP.
>>
>> And, as we know from recent discussions, RTP multiplexing is not o= nly about the port and address. It's about single vs multiple RTP sessi= ons, how
>> the multiplexing is implemented on the RTP level, etc etc etc. Wit= hout mechanisms to negotiate/indicate such things I am not sure how things<= br> >> would work.
>
> I agree, if both sides are muxing. If only one side is muxing (the cas= e I am referring to here), it is clear there are multiple RTP sessions, and=
> this can all be handled without knowledge of the RTP details.
>
> but break when it talks to a BUNDLE client, even =C2=A0though BUNDLE i= s not negotiated, since it can't demux by remote address.
>
> One reason for such gateways to exist would be to allow media to be se= nt to a known "common" port, such as port 443.
>
> Again, such gateways are not standards compliant, in my opinion.
>
> Perhaps, but they exist, at least to some extent. The question is, wha= t can we do about it? Ideally, BUNDLE would find some way to work even when= talking to something that is expecting different source ports.
>
>> Having said that, however, a BUNDLE implementation can always choo= se to accept the same address/port in the remote SDP even if BUNDLE is not = indicated.
>
> This will not work since the gateway will not have provided the BUNDLE= implementation with the necessary SSRC information to demux, and it won= 9;t
> understand the SSRC information the BUNDLE client sends to it.

So, the gateway wants to use the same local address/port, and = =C2=A0it *expects* the remote side to use separate address/ports, right?

Yes, I believe it assumes this will be th= e case.

If so, what do these gateways do if they still receive SDP with the same lo= cal address/port?

I haven't tested = yet, but I assume they end up picking one source address and ignoring the t= raffic from the other one.=C2=A0

I guess we could always say that if a BUNDLE client *receives* a non-BUNDLE= offer, but still with the same local address/port, it must reply with diff= erent address/ports - eventhough we normally don't specify procedures b= ased on non-standard behaviors.

OK.
=C2=A0

And, if a BUNDLE client *sends* a BUNDLE offer, I assume the gateway would = reject it, and in that case I think the draft already says that the BUNDLE = client should send a new non-BUNDLE offer.


It's not optimal, since it require= s a new allocation of candidates, but I think this would work for this scen= ario. This implies that WebRTC needs some way to control local use of BUNDL= E.

The same approach would also have to be used for anothe= r edge case where a BUNDLE client communicates with a non-BUNDLE client tha= t uses a TURN server that demultiplexes off of a single port (e.g. 443).
=C2=A0
Thanks,
--justin
--00248c6a6646146b0804bb11239f-- From internet-drafts@ietf.org Mon Mar 12 14:44:09 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 8388B21E804A; Mon, 12 Mar 2012 14:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 aMeAlf+ARJ6a; Mon, 12 Mar 2012 14:44:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65221E801F; Mon, 12 Mar 2012 14:43:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312214354.26822.50156.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:43:54 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-17.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: Mon, 12 Mar 2012 21:44:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) f= or Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Arjun Roychowdhury Chelliah SivaChelvan Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-17.txt Pages : 32 Date : 2012-03-12 The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-17.txt From HKaplan@acmepacket.com Mon Mar 12 14:47:26 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 D0E9A21E807F; Mon, 12 Mar 2012 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 S2OricjH2OXy; Mon, 12 Mar 2012 14:47:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2274821E803A; Mon, 12 Mar 2012 14:47:26 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 12 Mar 2012 17:47:24 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Mon, 12 Mar 2012 17:47:24 -0400 From: Hadriel Kaplan To: "" Thread-Topic: I-D Action: draft-ietf-mmusic-media-loopback-17.txt Thread-Index: AQHNAJm1VZNxhkR0IUuz2KSoEPL3sQ== Date: Mon, 12 Mar 2012 21:47:24 +0000 Message-ID: <55BFE6E9-1BC7-4085-AF46-BC89DBAEB51D@acmepacket.com> References: <20120312214354.26822.50156.idtracker@ietfa.amsl.com> In-Reply-To: <20120312214354.26822.50156.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <60F4F905884AF34BBB4451E4A9DB56C6@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , "" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-17.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: Mon, 12 Mar 2012 21:47:26 -0000 FYI - this one just fixes the editorial comments from Magnus and Miguel. Another one's coming out in a couple hours with the other comments resolved= - unless someone disagrees with my suggestions of how to fix them so far. -hadriel On Mar 12, 2012, at 5:43 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Multiparty Multimedia Session Contr= ol Working Group of the IETF. >=20 > Title : An Extension to the Session Description Protocol (SDP)= for Media Loopback > Author(s) : Hadriel Kaplan > Kaynam Hedayat > Nagarjuna Venna > Paul E. Jones > Arjun Roychowdhury > Chelliah SivaChelvan > Nathan Stratton > Filename : draft-ietf-mmusic-media-loopback-17.txt > Pages : 32 > Date : 2012-03-12 >=20 > The wide deployment of Voice over IP (VoIP), Text and Video over IP > services has introduced new challenges in managing and maintaining > real-time voice/real-time Text/video quality, reliability, and > overall performance. In particular, media delivery is an area that > needs attention. One method of meeting these challenges is > monitoring the media delivery performance by looping media back to > the transmitter. This is typically referred to as "active > monitoring" of services. Media loopback is especially popular in > ensuring the quality of transport to the edge of a given VoIP, > Real-time Text or Video over IP service. Today in networks that > deliver real-time media, short of running 'ping' and 'traceroute' > to the edge, service providers are left without the necessary tools > to actively monitor, manage, and diagnose quality issues with their > service. The extension defined herein adds new SDP media > attributes which enables establishment of media sessions where the > media is looped back to the transmitter. Such media sessions will > serve as monitoring and troubleshooting tools by providing the > means for measurement of more advanced VoIP, Real-time Text and > Video over IP performance metrics. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-17.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-17.tx= t >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Mon Mar 12 15:02:01 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 C5F1D21E8116; Mon, 12 Mar 2012 15:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 vKl9yStzv87b; Mon, 12 Mar 2012 15:02:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21EF21E8112; Mon, 12 Mar 2012 15:02:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312220200.3479.56616.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:02:00 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-13.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: Mon, 12 Mar 2012 22:02:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : SDP Media Capabilities Negotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-13.txt Pages : 57 Date : 2012-03-12 Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilitie= s-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities= -13.txt From trac+mmusic@trac.tools.ietf.org Mon Mar 12 15:15:54 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 503DF21E80B5 for ; Mon, 12 Mar 2012 15:15:54 -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 VPZlcOEWqg83 for ; Mon, 12 Mar 2012 15:15:53 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D197321E808B for ; Mon, 12 Mar 2012 15:15:53 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S7DWU-0006Om-BV; Mon, 12 Mar 2012 18:15:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mmusic issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com X-Trac-Project: mmusic Date: Mon, 12 Mar 2012 22:15:22 -0000 X-URL: http://tools.ietf.org/mmusic/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/mmusic/trac/ticket/1#comment:1 Message-ID: <078.5e78a4c58f5da39abfaa5ed5ec258227@trac.tools.ietf.org> References: <063.dd932850aa2e7e04e8bf51bcfe9041ab@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <063.dd932850aa2e7e04e8bf51bcfe9041ab@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-mmusic-media-loopback@tools.ietf.org, hkaplan@acmepacket.com, mmusic@ietf.org X-SA-Exim-Mail-From: trac+mmusic@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120312221553.D197321E808B@ietfa.amsl.com> Resent-Date: Mon, 12 Mar 2012 15:15:53 -0700 (PDT) Resent-From: trac+mmusic@trac.tools.ietf.org Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [mmusic] #1: How to reject a loopback offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:15:54 -0000 #1: How to reject a loopback offer Changes (by hkaplan@…): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: hkaplan@… | Owner: draft-ietf-mmusic-media-loopback@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: media- | Version: 1.0 loopback | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: mmusic From internet-drafts@ietf.org Mon Mar 12 16:07:49 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 B920121E81D0; Mon, 12 Mar 2012 16:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 6l5iy06pvEed; Mon, 12 Mar 2012 16:07:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2883021E81C0; Mon, 12 Mar 2012 16:07:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312230749.6064.2958.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:07:49 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-01.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: Mon, 12 Mar 2012 23:07:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : The Session Description Protocol (SDP) 'trafficclass' At= tribute Author(s) : James Polk Subha Dhesikan Paul E. Jones Filename : draft-ietf-mmusic-traffic-class-for-sdp-01.txt Pages : 21 Date : 2012-03-12 This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp= -01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-= 01.txt From atle.monrad@ericsson.com Tue Mar 13 00:53: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 F3E7321F88AA for ; Tue, 13 Mar 2012 00:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.403, 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 31fIwlQWnalD for ; Tue, 13 Mar 2012 00:53:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A562221F87EE for ; Tue, 13 Mar 2012 00:53:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-9f-4f5efce5756f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E7.30.17856.5ECFE5F4; Tue, 13 Mar 2012 08:53:09 +0100 (CET) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.56]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 13 Mar 2012 08:53:08 +0100 From: Atle Monrad To: Flemming Andreasen , mmusic Date: Tue, 13 Mar 2012 08:53:07 +0100 Thread-Topic: [MMUSIC] Proposal to adopt draft-garcia-mmusic-sdp-miscellaneous-caps as WG item Thread-Index: Acz80lMXCmsmbe8zR9KgCxyH4AQ5QAEGuvEw Message-ID: <7A051DFAA46D0246A82293C7CEF621E90686315CC0@ESESSCMS0352.eemea.ericsson.se> References: <4F5817E6.6090008@cisco.com> In-Reply-To: <4F5817E6.6090008@cisco.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: multipart/alternative; boundary="_000_7A051DFAA46D0246A82293C7CEF621E90686315CC0ESESSCMS0352e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Proposal to adopt draft-garcia-mmusic-sdp-miscellaneous-caps as WG item 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, 13 Mar 2012 07:53:12 -0000 --_000_7A051DFAA46D0246A82293C7CEF621E90686315CC0ESESSCMS0352e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Flemming / all As I've said before, I support this. This is one of the topics that 3GPP needs and bringing this forward is appr= eciated. I understand that to meet the June 2012 milestone may be hard, but to adopt= the draft as a WG-item is a good step in the right direction. Note also th= at this is one of the outstanding 3GPP Rel-8 dependencies. As Rel-8 is in d= eployment since quite some time now, it is appreciated if you try to someho= w keep the milestone ... /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen Sent: 8. mars 2012 03:23 To: mmusic Subject: [MMUSIC] Proposal to adopt draft-garcia-mmusic-sdp-miscellaneous-c= aps as WG item Greetings One of the MMUSIC milestones is to "Submit SDP extensions for Media Titles = and Media Bandwidth Capability Negotiations as Proposed Standard" by June 2= 012. We currently have draft-garcia-mmusic-sdp-miscellaneous-caps as an individu= al draft covering this milestone and the proposal is to adopt the draft as = a WG item. It should be noted that: - 3GPP has a dependency on this draft and has asked if we can complete it s= oon (see http://www.ietf.org/mail-archive/web/mmusic/current/msg09187.html) - As presented and discussed in Taipei, the draft also covers negotiation o= f connection information ("c=3D") to allow alternative connection types. A = primary use case for this is another of our WG items (namely "SDP extension= s for audio media streams over Circuit- Switched bearers") where you may ne= ed to offer circuit-switched and IP based bearers as alternatives. Please let the chairs know if you have any concerns with adopting the above= draft as a WG item. Thanks -- Flemming (MMUSIC co-chair) --_000_7A051DFAA46D0246A82293C7CEF621E90686315CC0ESESSCMS0352e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Flemming / all
 
As I've said before, I support=20 this.
 
This is one of the topics that 3GPP ne= eds and=20 bringing this forward is appreciated.
 
I understand that to meet the June 2012 mileston= e may=20 be hard, but to adopt the draft as a WG-item is a good step in the right=20 direction. Note also that this is one of the outstanding 3GPP Rel-8=20 dependencies. As Rel-8 is in deployment since quite some time now, it is=20 appreciated if you try to somehow keep the milestone ...
 
/atle
 

________________________________=


Atle Monrad
3GPP CT=20 Chairman
Standardization and Regulation,
Group Function Technology an= d=20 Portfolio Management Ericsson

 

 

From: mmusic-bounces@ietf.org=20 [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming=20 Andreasen
Sent: 8. mars 2012 03:23
To:=20 mmusic
Subject: [MMUSIC] Proposal to adopt=20 draft-garcia-mmusic-sdp-miscellaneous-caps as WG item

Greetings

One of the MMUSIC milestones is to "Submit=20 SDP extensions for Media Titles and Media Bandwidth Capability Negotiations= as=20 Proposed Standard" by June 2012.

We currently have=20 draft-garcia-mmusic-sdp-miscellaneous-caps as an individual draft covering = this=20 milestone and the proposal is to adopt the draft as a WG item.

It s= hould=20 be noted that:
- 3GPP has a dependency on this draft and has asked if we= can=20 complete it soon (see = http://www.ietf.org/mail-archive/web/mmusic/current/msg09187.html)
-= =20 As presented and discussed in Taipei, the draft also covers negotiation of= =20 connection information ("c=3D") to allow alternative connection types. A pr= imary=20 use case for this is another of our WG items (namely "SDP extensions for au= dio=20 media streams over Circuit- Switched bearers") where you may need to offer= =20 circuit-switched and IP based bearers as alternatives.

Please let t= he=20 chairs know if you have any concerns with adopting the above draft as a WG = item.=20

Thanks

-- Flemming (MMUSIC=20 co-chair)








--_000_7A051DFAA46D0246A82293C7CEF621E90686315CC0ESESSCMS0352e_-- From jmpolk@cisco.com Tue Mar 13 16:48: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 5D3AD21E8054 for ; Tue, 13 Mar 2012 16:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.804 X-Spam-Level: X-Spam-Status: No, score=-109.804 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1uZyw0Gb08lb for ; Tue, 13 Mar 2012 16:48:32 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C65E121E8013 for ; Tue, 13 Mar 2012 16:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1368; q=dns/txt; s=iport; t=1331682512; x=1332892112; h=message-id:date:to:from:subject:mime-version; bh=QxzXsXSAWRu+zXRyTyr3H+dosqeq+UgkA5kqoB4gdvI=; b=NFq4dSH/HbwRes3JXSkYcqNnU7Wwf6PSI969h41VjtRduvtHZZDsENfD 3rjCaqIQbDAIAfxp/ld9pIci+PLfRjRPTBaOe3SwVPXQdLVcZiaHQ5ZZy cbUWbU+U9i6kHDW+gcxGsn2GRBjzgGS9IVqo6hMDponXWGSV8wrF/CP3C g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJTbX0+rRDoH/2dsb2JhbABDtW+BB4IiASUCVjopYBmHZwybF4EnAZ5yjVSDIgSIVZ0egwM X-IronPort-AV: E=Sophos;i="4.73,580,1325462400"; d="scan'208";a="35893409" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Mar 2012 23:48:32 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2DNmWXM020353 for ; Tue, 13 Mar 2012 23:48:32 GMT Message-Id: <201203132348.q2DNmWXM020353@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Mar 2012 18:48:31 -0500 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp uploaded 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, 13 Mar 2012 23:48:33 -0000 I've uploaded the next version of http://www.ietf.org/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-01.txt These are the following changes made between the WG -00 version and the -01 version: - removed the non-SDP applications Netflix and VOD - switched the adjective 'desktop' to 'avconf' - Labeled each of the figures. - clarified the differences between Multimedia-Streaming and Broadcast parent categories. - defined Video surveillance - added the concept of a 'qualified' adjective, and modified the ABNF accordingly. - deleted the idea of a 'cac-class' as a separate component, and made the equivalent a qualified adjective. - modified the answerer behavior because of the removal of the 'cac-class' component. - created an IANA registry for qualified adjectives - general clean-up of the doc. Did *not* do the following in this version: - add the ability to have more than one trafficclass attribute based on the codec chosen, as feedback indicated this was a bad idea. - no swap of the Multimedia-Conferencing parent category with the offered Collaboration parent category, as doing this did not solve any perceived problems. - add more to the 'how does this get processed' portion of Section 3. That will come in the next revision. Comments are welcome James From Bert.Greevenbosch@huawei.com Tue Mar 13 18:25: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 5698F11E8073 for ; Tue, 13 Mar 2012 18:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 ea15pL+ydESO for ; Tue, 13 Mar 2012 18:25:32 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BEE3221E8015 for ; Tue, 13 Mar 2012 18:25:31 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0U004IYPAB83@szxga04-in.huawei.com> for mmusic@ietf.org; Wed, 14 Mar 2012 09:25:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0U0080PPABK4@szxga04-in.huawei.com> for mmusic@ietf.org; Wed, 14 Mar 2012 09:25:23 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHV10325; Wed, 14 Mar 2012 09:24:45 +0800 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Mar 2012 09:24:06 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.93]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 14 Mar 2012 09:24:40 +0800 Date: Wed, 14 Mar 2012 01:24:40 +0000 From: Bert Greevenbosch In-reply-to: <4F573ED3.2030409@ericsson.com> X-Originating-IP: [10.70.109.135] To: "Miguel A. Garcia" Message-id: <46A1DF3F04371240B504290A071B4DB62467DFD6@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] Hitchhiker's guide to SDP Thread-index: AQHM8ibrK1fnIxUm3UOSjsFPFGU6nZZKMLAAgAAGtYCABO9jgIAN0jKAgAE+dYCAB9ANkA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 14 Mar 2012 01:25:36 -0000 Hi Miguel, all, Thanks for these references. I consulted the IANA site when writing the first draft, but in light of the current discussion on the scope of the document, I may have to do that again. The other reference (from opsawg) indeed contains some references to SIP. Do I correctly sense that it is the general feeling of the group that SIP should be in scope of the document? How about Megaco/H.248 and RTSP? Best regards, Bert -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: 07 March 2012 18:56 To: Bert Greevenbosch Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP Bert, Here is another document with the same purpose. You can use it for inspiration. This is a bit more complex document, because it has to deal with several different protocols, rather than only one. http://tools.ietf.org/html/draft-ietf-opsawg-management-stds The other document that you need to consult is the IANA SDP Parameters registry at: http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml This contains a list of all the SDP extensions, and they all should be listed in the hitchhiker's guide. /Miguel On 07/03/2012 3:54, Bert Greevenbosch wrote: > Hi all, > > On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied most initial text from there, and in addition included an initial list of RFCs / drafts that seem relevant. > > https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ > > If the group is happy with this approach, I will be happy to maintain an editor's role, and write more text. Obviously other people's input will be highly appreciated, and indeed is needed. > > I look forward to your comments. > > Best regards, > Bert > > P.S. Unfortunately, I forgot to include "mmusic" in the name of the draft. How to deal with this? > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 27 February 2012 04:53 > To: Gonzalo Camarillo; Mary Barnes > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > Hi, > > As a directorate member, I am willing to co-author such draft, should a decision to write one be taken. > > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 23. helmikuuta 2012 19:31 > To: Mary Barnes > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > I agree. > > Gonzalo > > On 23/02/2012 7:06 PM, Mary Barnes wrote: >> I would think that in order for the document to have integrity that at >> least one of the directorate members should at least be a co-author. >> Otherwise, I see a lot more stuff falling through the cracks and >> needing to be resolved during WGLC and later, which usually isn't a >> good thing. The SIP Hitchhiker's guide provides a good example in >> that the author was also a primary contributor to RFC3261, etc. >> >> Mary. >> >> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >> > > >> wrote: >> >> Hi Mary, >> >> yes, the members of the SDP directorate would need to review such a >> guide. However, the fact that they agreed to be members of the >> directorate does not mean they will necessarily have cycles to >> significantly contribute to the creation of the guide. We need to make >> sure we have enough energy around this effort in order to start it. >> >> Cheers, >> >> Gonzalo >> >> On 15/02/2012 7:14 PM, Mary Barnes wrote: >> > I think this is a good idea. I would think the experts that can >> > contribute (and should review) can be found in the new SDP >> > directorate: >> > http://www.ietf.org/iesg/directorate/sdp.html >> > BTW, it would be nice to have a link to this page on the MMUSIC WG >> wiki: >> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >> > >> > As far as whether to publish, I think it would be a good idea to >> > complete publication as IMHO that improves the integrity of the >> > information - i.e., more eyes review a published RFC than a draft. >> > It could later be updated to reflect more recent RFCs OR a "More of >> > Hitchhikers Guide" could be published. >> > >> > Thanks, >> > Mary. >> > >> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >> > > > wrote: >> >> Hi Miguel, Andrew, all, >> >> >> >> Sounds like a good idea. I would be happy to volunteer to play a >> central role in it (i.e. be the editor, create the initial draft, >> ...), but I would need support from other experts too. >> >> >> >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" >> has become an RFC (5411). That means that it has been frozen, and to >> add new info new individual or WG drafts are needed. >> >> >> >> Would this be the same approach for SDP? Currently, there are >> already quite some new drafts that extend SDP. How will future >> extensions be handled? Maybe it would be good to make it a permanent >> WG draft, which is updated every now and then. >> >> >> >> Best regards, >> >> Bert >> >> >> >> >> >> -----Original Message----- >> >> From: mmusic-bounces@ietf.org >> [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Miguel A. Garcia >> >> Sent: 14 February 2012 15:42 >> >> To: Andrew Allen >> >> Cc: mmusic@ietf.org >> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >> >> >> >> Sounds good to me too. If someone wants to start such draft... >> >> >> >> /Miguel >> >> >> >> On 13/02/2012 23:15, Andrew Allen wrote: >> >>> >> >>> What about considering a hitchhikers guide to SDP similar to >> what was done for SIP? >> >>> >> >>> One umbrella document that points the reader to all the SDP >> capabilities available that they might want to take advantage of. >> >>> >> >>> Just a suggestion. >> >>> >> >>> Andrew >> >>> >> >>> ----- Original Message ----- >> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com >> ] >> >>> Sent: Saturday, January 28, 2012 06:23 AM >> >>> To: mmusic> >> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >> >>> >> >>> >> >>> >> >>> Hi all, >> >>> >> >>> You know we are revising RFC 4566. So far, the effort has been >> in bug fixing. >> >>> >> >>> The first SDP version was published as RFC 2327 in 1998 (i.e., >> 14 years >> >>> ago), and was then revised as RFC 4566 in 2006. >> >>> >> >>> Lots of things have happened since then. We have SDP offer answer, >> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, >> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. >> >>> >> >>> From the point of view of a reader who takes 4566 (or its current >> >>> 4566bis incarnation), I think it will be difficult for her or him to >> >>> understand a protocol that ignores those other extensions. For >> example, I >> >>> recently post another e-mail where there is an apparent >> contradiction >> >>> between 4566 and ICE (see >> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >> >>> >> >>> So, I was wondering if time has come to make not a bug correction in >> >>> 4566bis, but also put that RFC in context with the other >> extensions that >> >>> exist. This may include: >> >>> >> >>> - Add minor extensions to the core document, similarly to what >> we did >> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which >> of these >> >>> extensions make sense to include, this would be an exercise to >> do, but >> >>> let me give you one potential example: RFC 4574, the SDP "label" >> >>> attribute is a 6 pages RFC. >> >>> >> >>> - Adding references to extensions, when it makes sense. For >> example, ICE >> >>> should be referred somewhere (see my previous post regarding the "o" >> >>> line). I guess capneg could be also mentioned, perhaps others. >> >>> >> >>> I know this is a bigger effort than anticipated, but the result >> could >> >>> really help newcomers to this world. >> >>> >> >>> Now, it is your turn to express your opinions. Please do it. >> >>> >> >>> /Miguel >> >> >> >> -- >> >> Miguel A. Garcia >> >> +34-91-339-3608 >> >> Ericsson Spain >> >> _______________________________________________ >> >> 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 >> > _______________________________________________ >> > 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 > _______________________________________________ > 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 > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Mar 14 01:04: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 2F61121F8598 for ; Wed, 14 Mar 2012 01:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 YMhkBkJ64fBg for ; Wed, 14 Mar 2012 01:04:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6DD21F86D0 for ; Wed, 14 Mar 2012 01:04:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-6f-4f60510f5e6f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A3.C4.17856.F01506F4; Wed, 14 Mar 2012 09:04:31 +0100 (CET) Received: from [159.107.24.217] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 14 Mar 2012 09:04:31 +0100 Message-ID: <4F60510E.60206@ericsson.com> Date: Wed, 14 Mar 2012 09:04:30 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bert Greevenbosch References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <46A1DF3F04371240B504290A071B4DB62467DFD6@szxeml509-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB62467DFD6@szxeml509-mbx.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 14 Mar 2012 08:04:35 -0000 Hi: Let me restate my opinion, as an individual contributor, not as a chair. I think the document, for it to be useful, has to list the usages/extensions of SDP in *any* IETF document. This includes SIP, H.248/MEGACO, and RTSP as a least. So, I believe the document should have at least 4 sections, one where you discuss core documents used by any protocol (probably RFC 4566bis, perhaps a few others as well). And then the document should list extensions that are believed to be useful with only one particular protocol (that one being SIP, H.248, or RTSP). That leaves outside the scope of the document those extensions that are created in non-RFCs, for example, in ITU-T, ETSI, OMA, or 3GPP documents (assuming there are those extensions, I don't know). So we restrict the document to IETF-created extensions used by IETF-created protocols. Of course, we can start listing SDP extensions to SIP documents, bearing in mind that this is not the final goal. So, we can leave for a next iteration the addition of additional extensions used by other protocols. How about that? /Miguel On 14/03/2012 2:24, Bert Greevenbosch wrote: > Hi Miguel, all, > > Thanks for these references. I consulted the IANA site when writing the first draft, but in light of the current discussion on the scope of the document, I may have to do that again. > > The other reference (from opsawg) indeed contains some references to SIP. > > Do I correctly sense that it is the general feeling of the group that SIP should be in scope of the document? How about Megaco/H.248 and RTSP? > > Best regards, > Bert > > > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 07 March 2012 18:56 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > Bert, > > Here is another document with the same purpose. You can use it for > inspiration. This is a bit more complex document, because it has to deal > with several different protocols, rather than only one. > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > The other document that you need to consult is the IANA SDP Parameters > registry at: > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > This contains a list of all the SDP extensions, and they all should be > listed in the hitchhiker's guide. > > /Miguel > > On 07/03/2012 3:54, Bert Greevenbosch wrote: >> Hi all, >> >> On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied most initial text from there, and in addition included an initial list of RFCs / drafts that seem relevant. >> >> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ >> >> If the group is happy with this approach, I will be happy to maintain an editor's role, and write more text. Obviously other people's input will be highly appreciated, and indeed is needed. >> >> I look forward to your comments. >> >> Best regards, >> Bert >> >> P.S. Unfortunately, I forgot to include "mmusic" in the name of the draft. How to deal with this? >> >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 27 February 2012 04:53 >> To: Gonzalo Camarillo; Mary Barnes >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> >> >> Hi, >> >> As a directorate member, I am willing to co-author such draft, should a decision to write one be taken. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: 23. helmikuuta 2012 19:31 >> To: Mary Barnes >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> >> I agree. >> >> Gonzalo >> >> On 23/02/2012 7:06 PM, Mary Barnes wrote: >>> I would think that in order for the document to have integrity that at >>> least one of the directorate members should at least be a co-author. >>> Otherwise, I see a lot more stuff falling through the cracks and >>> needing to be resolved during WGLC and later, which usually isn't a >>> good thing. The SIP Hitchhiker's guide provides a good example in >>> that the author was also a primary contributor to RFC3261, etc. >>> >>> Mary. >>> >>> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >>> >> > >>> wrote: >>> >>> Hi Mary, >>> >>> yes, the members of the SDP directorate would need to review such a >>> guide. However, the fact that they agreed to be members of the >>> directorate does not mean they will necessarily have cycles to >>> significantly contribute to the creation of the guide. We need to make >>> sure we have enough energy around this effort in order to start it. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 15/02/2012 7:14 PM, Mary Barnes wrote: >>> > I think this is a good idea. I would think the experts that can >>> > contribute (and should review) can be found in the new SDP >>> > directorate: >>> > http://www.ietf.org/iesg/directorate/sdp.html >>> > BTW, it would be nice to have a link to this page on the MMUSIC WG >>> wiki: >>> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >>> > >>> > As far as whether to publish, I think it would be a good idea to >>> > complete publication as IMHO that improves the integrity of the >>> > information - i.e., more eyes review a published RFC than a draft. >>> > It could later be updated to reflect more recent RFCs OR a "More of >>> > Hitchhikers Guide" could be published. >>> > >>> > Thanks, >>> > Mary. >>> > >>> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >>> > >> > wrote: >>> >> Hi Miguel, Andrew, all, >>> >> >>> >> Sounds like a good idea. I would be happy to volunteer to play a >>> central role in it (i.e. be the editor, create the initial draft, >>> ...), but I would need support from other experts too. >>> >> >>> >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" >>> has become an RFC (5411). That means that it has been frozen, and to >>> add new info new individual or WG drafts are needed. >>> >> >>> >> Would this be the same approach for SDP? Currently, there are >>> already quite some new drafts that extend SDP. How will future >>> extensions be handled? Maybe it would be good to make it a permanent >>> WG draft, which is updated every now and then. >>> >> >>> >> Best regards, >>> >> Bert >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Miguel A. Garcia >>> >> Sent: 14 February 2012 15:42 >>> >> To: Andrew Allen >>> >> Cc: mmusic@ietf.org >>> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >>> >> >>> >> Sounds good to me too. If someone wants to start such draft... >>> >> >>> >> /Miguel >>> >> >>> >> On 13/02/2012 23:15, Andrew Allen wrote: >>> >>> >>> >>> What about considering a hitchhikers guide to SDP similar to >>> what was done for SIP? >>> >>> >>> >>> One umbrella document that points the reader to all the SDP >>> capabilities available that they might want to take advantage of. >>> >>> >>> >>> Just a suggestion. >>> >>> >>> >>> Andrew >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com >>> ] >>> >>> Sent: Saturday, January 28, 2012 06:23 AM >>> >>> To: mmusic> >>> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >>> >>> >>> >>> >>> >>> >>> >>> Hi all, >>> >>> >>> >>> You know we are revising RFC 4566. So far, the effort has been >>> in bug fixing. >>> >>> >>> >>> The first SDP version was published as RFC 2327 in 1998 (i.e., >>> 14 years >>> >>> ago), and was then revised as RFC 4566 in 2006. >>> >>> >>> >>> Lots of things have happened since then. We have SDP offer answer, >>> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, comeida, >>> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in the pipe. >>> >>> >>> >>> From the point of view of a reader who takes 4566 (or its current >>> >>> 4566bis incarnation), I think it will be difficult for her or him to >>> >>> understand a protocol that ignores those other extensions. For >>> example, I >>> >>> recently post another e-mail where there is an apparent >>> contradiction >>> >>> between 4566 and ICE (see >>> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >>> >>> >>> >>> So, I was wondering if time has come to make not a bug correction in >>> >>> 4566bis, but also put that RFC in context with the other >>> extensions that >>> >>> exist. This may include: >>> >>> >>> >>> - Add minor extensions to the core document, similarly to what >>> we did >>> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which >>> of these >>> >>> extensions make sense to include, this would be an exercise to >>> do, but >>> >>> let me give you one potential example: RFC 4574, the SDP "label" >>> >>> attribute is a 6 pages RFC. >>> >>> >>> >>> - Adding references to extensions, when it makes sense. For >>> example, ICE >>> >>> should be referred somewhere (see my previous post regarding the "o" >>> >>> line). I guess capneg could be also mentioned, perhaps others. >>> >>> >>> >>> I know this is a bigger effort than anticipated, but the result >>> could >>> >>> really help newcomers to this world. >>> >>> >>> >>> Now, it is your turn to express your opinions. Please do it. >>> >>> >>> >>> /Miguel >>> >> >>> >> -- >>> >> Miguel A. Garcia >>> >> +34-91-339-3608 >>> >> Ericsson Spain >>> >> _______________________________________________ >>> >> 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 >>> > _______________________________________________ >>> > 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 >> _______________________________________________ >> 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 >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From keith.drage@alcatel-lucent.com Wed Mar 14 03:54:27 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 1B96421F8743 for ; Wed, 14 Mar 2012 03:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.55 X-Spam-Level: X-Spam-Status: No, score=-109.55 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 ze5kUG9DCop3 for ; Wed, 14 Mar 2012 03:54:25 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4821F873C for ; Wed, 14 Mar 2012 03:54:25 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2EArm4M027698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Mar 2012 11:54:07 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 14 Mar 2012 11:52:55 +0100 From: "DRAGE, Keith (Keith)" To: "Miguel A. Garcia" , Bert Greevenbosch Date: Wed, 14 Mar 2012 11:52:54 +0100 Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP Thread-Index: Ac0BuSNEyvgg9ALFSfOFA4yhrRaJ6gAFgdWA Message-ID: References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <46A1DF3F04371240B504290A071B4DB62467DFD6@szxeml509-mbx.china.huawei.com> <4F60510E.60206@ericsson.com> In-Reply-To: <4F60510E.60206@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 14 Mar 2012 10:54:27 -0000 +1 on what Miguel says. I support the structure Miguel proposes. I believe that within that structure it should contain all the IETF created= documents that are references from the SDP tables in IANA. There may be ot= her documents associated with these that also need to be mentioned, but thi= s will form the bulk of the documents required. SIP is only in scope in so far as it creates a variant of SDP for its own u= se. Remember there is the SIP hitchhikers guide that should cover SIP exten= sions, and if you believe it is more appropriate to the scope of that docum= ent, then SIPCORE should revise the SIP hitchhikers guide. If this proves ultimately to be a document that then becomes unmanageable, = then we can think then about how we constrain the structure. Note that we s= eem to be talking about a document listing 60 approved RFCs and a maximum o= f another 20 or so that are in progress nearing completion. The reference list for the SIP hitchhikers guide was well over a 100. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: 14 March 2012 08:05 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > Hi: > > Let me restate my opinion, as an individual contributor, not as a chair. > > I think the document, for it to be useful, has to list the > usages/extensions of SDP in *any* IETF document. This includes SIP, > H.248/MEGACO, and RTSP as a least. > > So, I believe the document should have at least 4 sections, one where you > discuss core documents used by any protocol (probably RFC 4566bis, > perhaps a few others as well). And then the document should list > extensions that are believed to be useful with only one particular > protocol (that one being SIP, H.248, or RTSP). > > That leaves outside the scope of the document those extensions that are > created in non-RFCs, for example, in ITU-T, ETSI, OMA, or 3GPP documents > (assuming there are those extensions, I don't know). So we restrict the > document to IETF-created extensions used by IETF-created protocols. > > Of course, we can start listing SDP extensions to SIP documents, bearing > in mind that this is not the final goal. So, we can leave for a next > iteration the addition of additional extensions used by other protocols. > > How about that? > > /Miguel > > > On 14/03/2012 2:24, Bert Greevenbosch wrote: > > Hi Miguel, all, > > > > Thanks for these references. I consulted the IANA site when writing the > first draft, but in light of the current discussion on the scope of the > document, I may have to do that again. > > > > The other reference (from opsawg) indeed contains some references to > SIP. > > > > Do I correctly sense that it is the general feeling of the group that > SIP should be in scope of the document? How about Megaco/H.248 and RTSP? > > > > Best regards, > > Bert > > > > > > > > -----Original Message----- > > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > > Sent: 07 March 2012 18:56 > > To: Bert Greevenbosch > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > > > Bert, > > > > Here is another document with the same purpose. You can use it for > > inspiration. This is a bit more complex document, because it has to dea= l > > with several different protocols, rather than only one. > > > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > > > The other document that you need to consult is the IANA SDP Parameters > > registry at: > > > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > > > This contains a list of all the SDP extensions, and they all should be > > listed in the hitchhiker's guide. > > > > /Miguel > > > > On 07/03/2012 3:54, Bert Greevenbosch wrote: > >> Hi all, > >> > >> On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP"= . > It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied > most initial text from there, and in addition included an initial list of > RFCs / drafts that seem relevant. > > >> > >> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide- > sdp/ > >> > >> If the group is happy with this approach, I will be happy to maintain > an editor's role, and write more text. Obviously other people's input wil= l > be highly appreciated, and indeed is needed. > >> > >> I look forward to your comments. > >> > >> Best regards, > >> Bert > >> > >> P.S. Unfortunately, I forgot to include "mmusic" in the name of the > draft. How to deal with this? > >> > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > >> Sent: 27 February 2012 04:53 > >> To: Gonzalo Camarillo; Mary Barnes > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > >> > >> > >> Hi, > >> > >> As a directorate member, I am willing to co-author such draft, should = a > decision to write one be taken. > >> > >> Regards, > >> > >> Christer > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > >> Sent: 23. helmikuuta 2012 19:31 > >> To: Mary Barnes > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > >> > >> I agree. > >> > >> Gonzalo > >> > >> On 23/02/2012 7:06 PM, Mary Barnes wrote: > >>> I would think that in order for the document to have integrity that a= t > >>> least one of the directorate members should at least be a co-author. > >>> Otherwise, I see a lot more stuff falling through the cracks and > >>> needing to be resolved during WGLC and later, which usually isn't a > >>> good thing. The SIP Hitchhiker's guide provides a good example in > >>> that the author was also a primary contributor to RFC3261, etc. > >>> > >>> Mary. > >>> > >>> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo > >>> >>> > > >>> wrote: > >>> > >>> Hi Mary, > >>> > >>> yes, the members of the SDP directorate would need to review > such a > >>> guide. However, the fact that they agreed to be members of the > >>> directorate does not mean they will necessarily have cycles to > >>> significantly contribute to the creation of the guide. We need > to make > >>> sure we have enough energy around this effort in order to start > it. > >>> > >>> Cheers, > >>> > >>> Gonzalo > >>> > >>> On 15/02/2012 7:14 PM, Mary Barnes wrote: > >>> > I think this is a good idea. I would think the experts tha= t > can > >>> > contribute (and should review) can be found in the new SDP > >>> > directorate: > >>> > http://www.ietf.org/iesg/directorate/sdp.html > >>> > BTW, it would be nice to have a link to this page on the > MMUSIC WG > >>> wiki: > >>> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki > >>> > > >>> > As far as whether to publish, I think it would be a good > idea to > >>> > complete publication as IMHO that improves the integrity of > the > >>> > information - i.e., more eyes review a published RFC than a > draft. > >>> > It could later be updated to reflect more recent RFCs OR a > "More of > >>> > Hitchhikers Guide" could be published. > >>> > > >>> > Thanks, > >>> > Mary. > >>> > > >>> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch > >>> > >>> > wrote: > >>> >> Hi Miguel, Andrew, all, > >>> >> > >>> >> Sounds like a good idea. I would be happy to volunteer to > play a > >>> central role in it (i.e. be the editor, create the initial > draft, > >>> ...), but I would need support from other experts too. > >>> >> > >>> >> As for practicalities, I see that the "Hitchhiker's Guide > to SIP" > >>> has become an RFC (5411). That means that it has been frozen, > and to > >>> add new info new individual or WG drafts are needed. > >>> >> > >>> >> Would this be the same approach for SDP? Currently, there > are > >>> already quite some new drafts that extend SDP. How will future > >>> extensions be handled? Maybe it would be good to make it a > permanent > >>> WG draft, which is updated every now and then. > >>> >> > >>> >> Best regards, > >>> >> Bert > >>> >> > >>> >> > >>> >> -----Original Message----- > >>> >> From: mmusic-bounces@ietf.org bounces@ietf.org> > >>> [mailto:mmusic-bounces@ietf.org= ] > On > >>> Behalf Of Miguel A. Garcia > >>> >> Sent: 14 February 2012 15:42 > >>> >> To: Andrew Allen > >>> >> Cc: mmusic@ietf.org > >>> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis= ? > >>> >> > >>> >> Sounds good to me too. If someone wants to start such > draft... > >>> >> > >>> >> /Miguel > >>> >> > >>> >> On 13/02/2012 23:15, Andrew Allen wrote: > >>> >>> > >>> >>> What about considering a hitchhikers guide to SDP similar > to > >>> what was done for SIP? > >>> >>> > >>> >>> One umbrella document that points the reader to all the > SDP > >>> capabilities available that they might want to take advantage > of. > >>> >>> > >>> >>> Just a suggestion. > >>> >>> > >>> >>> Andrew > >>> >>> > >>> >>> ----- Original Message ----- > >>> >>> From: Miguel A. Garcia > [mailto:Miguel.A.Garcia@ericsson.com > >>> ] > >>> >>> Sent: Saturday, January 28, 2012 06:23 AM > >>> >>> To: mmusic> > >>> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? > >>> >>> > >>> >>> > >>> >>> > >>> >>> Hi all, > >>> >>> > >>> >>> You know we are revising RFC 4566. So far, the effort has > been > >>> in bug fixing. > >>> >>> > >>> >>> The first SDP version was published as RFC 2327 in 1998 > (i.e., > >>> 14 years > >>> >>> ago), and was then revised as RFC 4566 in 2006. > >>> >>> > >>> >>> Lots of things have happened since then. We have SDP offe= r > answer, > >>> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, > comeida, > >>> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are i= n > the pipe. > >>> >>> > >>> >>> From the point of view of a reader who takes 4566 (or > its current > >>> >>> 4566bis incarnation), I think it will be difficult for he= r > or him to > >>> >>> understand a protocol that ignores those other extensions= . > For > >>> example, I > >>> >>> recently post another e-mail where there is an apparent > >>> contradiction > >>> >>> between 4566 and ICE (see > >>> >>> http://www.ietf.org/mail- > archive/web/mmusic/current/msg09089.html ). > >>> >>> > >>> >>> So, I was wondering if time has come to make not a bug > correction in > >>> >>> 4566bis, but also put that RFC in context with the other > >>> extensions that > >>> >>> exist. This may include: > >>> >>> > >>> >>> - Add minor extensions to the core document, similarly to > what > >>> we did > >>> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't k= now > which > >>> of these > >>> >>> extensions make sense to include, this would be an > exercise to > >>> do, but > >>> >>> let me give you one potential example: RFC 4574, the SDP > "label" > >>> >>> attribute is a 6 pages RFC. > >>> >>> > >>> >>> - Adding references to extensions, when it makes sense. > For > >>> example, ICE > >>> >>> should be referred somewhere (see my previous post > regarding the "o" > >>> >>> line). I guess capneg could be also mentioned, perhaps > others. > >>> >>> > >>> >>> I know this is a bigger effort than anticipated, but the > result > >>> could > >>> >>> really help newcomers to this world. > >>> >>> > >>> >>> Now, it is your turn to express your opinions. Please do > it. > >>> >>> > >>> >>> /Miguel > >>> >> > >>> >> -- > >>> >> Miguel A. Garcia > >>> >> +34-91-339-3608 > >>> >> Ericsson Spain > >>> >> _______________________________________________ > >>> >> 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 > >>> > _______________________________________________ > >>> > 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 > >> _______________________________________________ > >> 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 > >> > > > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From aallen@rim.com Wed Mar 14 05:44:27 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 BF97121F87A7 for ; Wed, 14 Mar 2012 05:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 VkXfEHRqqfOb for ; Wed, 14 Mar 2012 05:44:26 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1410E21F86F7 for ; Wed, 14 Mar 2012 05:44:25 -0700 (PDT) X-AuditID: 0a412830-b7fc16d000000702-50-4f6092a6c79e Received: from XHT108CNC.rim.net (xht108cnc.rim.net [10.65.22.54]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 0F.B9.01794.6A2906F4; Wed, 14 Mar 2012 12:44:22 +0000 (GMT) Received: from XCT103ADS.rim.net (10.67.111.44) by XHT108CNC.rim.net (10.65.22.54) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 14 Mar 2012 08:44:22 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0339.001; Wed, 14 Mar 2012 07:44:21 -0500 From: Andrew Allen To: "Miguel.A.Garcia@ericsson.com" , "Bert.Greevenbosch@huawei.com" Thread-Topic: [MMUSIC] Hitchhiker's guide to SDP Thread-Index: AQHM8ibtxPSzTH4vN06GOklK+LBscpZLG2EAgAAGtoCABO9jgIAOig+AgACGmICACk/WAIAAb7cA///6Xc8= Date: Wed, 14 Mar 2012 12:44:20 +0000 Message-ID: In-Reply-To: <4F60510E.60206@ericsson.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsXC5ShmprtsUoK/wewtlha/n6xgtVjzaQW7 xdTlj1kcmD1+fb3K5tFy5C2rx5IlP5kCmKMaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLL EpMrFVwyi5NzEjNzU4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpe cn5KZl66rZJnsL+uhYWppa6hkp0uEkj4x51x/oNtwZK0ivbtx9gbGH96dzFyckgImEisevWf BcIWk7hwbz0biC0k0MMkcXmaYBcjF5C9lFGi7+N/dghnC6NE8+9XrCBVbALKEst/z2AEsUUE mhglWo+JdzFycDALqEtcXRwEEhYW0JdYdeAtK0SJgcSXBWdZIOwkiX0Xt4HFWQRUJd7+XQBm 8wq4SWxqfsMOYnMKaEkcuH6BCcRmFJCV2H32OpjNLCAucevJfCaIowUkluw5zwxhi0q8fPyP FcJWlHjSuJkFol5P4sbUKWwQtrbEsoWvmSF2CUqcnPmEBeJhaYkdJ9cwTmAUn4VkxSwk7bOQ tM9C0r6AkWUVo2BuRrGBmWFyXrJeUWauXl5qySZGcELRMNjBOGGv1iFGAQ5GJR5eg9YEfyHW xLLiytxDjBIczEoivM9YgUK8KYmVValF+fFFpTmpxYcYLYChMpFZijs5H5js8krijQ0MUDhK 4rxLVmr5CwmkA9NUdmpqQWoRTCsTB6dUA6NME98md9WrfmY7pJlqHO7d2nG/ROzicavVHtsc 68ozJx19c5zRQVb7i/L60Ku2vWFqzzdyRxzg5X187oQ+49Y1O3/kG1qs2P3h/JfaRvuH9oa+ r3s2LrOSm32ogzXmiyN3StyBCa++PFPkushRx7HFfr1a0THl3gcqX1+eUZ65896ur25+BxWV WIozEg21mIuKEwEm/y4VQQMAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 14 Mar 2012 12:44:27 -0000 +1 Maybe also having a reference to the IANA registry where to look for other p= roprietary extension attributes that have been registered with IANA would al= so be useful. ----- Original Message ----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Wednesday, March 14, 2012 03:04 AM=0A= To: Bert Greevenbosch Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Hitchhiker's guide to SDP Hi: Let me restate my opinion, as an individual contributor, not as a chair. I think the document, for it to be useful, has to list the usages/extensions of SDP in *any* IETF document. This includes SIP, H.248/MEGACO, and RTSP as a least. So, I believe the document should have at least 4 sections, one where you discuss core documents used by any protocol (probably RFC 4566bis, perhaps a few others as well). And then the document should list extensions that are believed to be useful with only one particular protocol (that one being SIP, H.248, or RTSP). That leaves outside the scope of the document those extensions that are created in non-RFCs, for example, in ITU-T, ETSI, OMA, or 3GPP documents (assuming there are those extensions, I don't know). So we restrict the document to IETF-created extensions used by IETF-created protocols. Of course, we can start listing SDP extensions to SIP documents, bearing in mind that this is not the final goal. So, we can leave for a next iteration the addition of additional extensions used by other protocols. How about that? /Miguel On 14/03/2012 2:24, Bert Greevenbosch wrote: > Hi Miguel, all, > > Thanks for these references. I consulted the IANA site when writing the fi= rst draft, but in light of the current discussion on the scope of the docume= nt, I may have to do that again. > > The other reference (from opsawg) indeed contains some references to SIP. > > Do I correctly sense that it is the general feeling of the group that SIP= should be in scope of the document? How about Megaco/H.248 and RTSP? > > Best regards, > Bert > > > > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 07 March 2012 18:56 > To: Bert Greevenbosch > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Hitchhiker's guide to SDP > > Bert, > > Here is another document with the same purpose. You can use it for > inspiration. This is a bit more complex document, because it has to deal > with several different protocols, rather than only one. > > http://tools.ietf.org/html/draft-ietf-opsawg-management-stds > > The other document that you need to consult is the IANA SDP Parameters > registry at: > > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml > > This contains a list of all the SDP extensions, and they all should be > listed in the hitchhiker's guide. > > /Miguel > > On 07/03/2012 3:54, Bert Greevenbosch wrote: >> Hi all, >> >> On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to SDP". I= t is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I have copied most= initial text from there, and in addition included an initial list of RFCs /= drafts that seem relevant. >> >> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ >> >> If the group is happy with this approach, I will be happy to maintain an= editor's role, and write more text. Obviously other people's input will be= highly appreciated, and indeed is needed. >> >> I look forward to your comments. >> >> Best regards, >> Bert >> >> P.S. Unfortunately, I forgot to include "mmusic" in the name of the draft= . How to deal with this? >> >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Christer Holmberg >> Sent: 27 February 2012 04:53 >> To: Gonzalo Camarillo; Mary Barnes >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> >> >> Hi, >> >> As a directorate member, I am willing to co-author such draft, should a d= ecision to write one be taken. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Gonzalo Camarillo >> Sent: 23. helmikuuta 2012 19:31 >> To: Mary Barnes >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> >> I agree. >> >> Gonzalo >> >> On 23/02/2012 7:06 PM, Mary Barnes wrote: >>> I would think that in order for the document to have integrity that at >>> least one of the directorate members should at least be a co-author. >>> Otherwise, I see a lot more stuff falling through the cracks and >>> needing to be resolved during WGLC and later, which usually isn't a >>> good thing. The SIP Hitchhiker's guide provides a good example in >>> that the author was also a primary contributor to RFC3261, etc. >>> >>> Mary. >>> >>> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >>> >> > >>> wrote: >>> >>> Hi Mary, >>> >>> yes, the members of the SDP directorate would need to review such= a >>> guide. However, the fact that they agreed to be members of the >>> directorate does not mean they will necessarily have cycles to >>> significantly contribute to the creation of the guide. We need to= make >>> sure we have enough energy around this effort in order to start it= . >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 15/02/2012 7:14 PM, Mary Barnes wrote: >>> > I think this is a good idea. I would think the experts that c= an >>> > contribute (and should review) can be found in the new SDP >>> > directorate: >>> > http://www.ietf.org/iesg/directorate/sdp.html >>> > BTW, it would be nice to have a link to this page on the MMUSI= C WG >>> wiki: >>> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >>> > >>> > As far as whether to publish, I think it would be a good idea= to >>> > complete publication as IMHO that improves the integrity of th= e >>> > information - i.e., more eyes review a published RFC than a dr= aft. >>> > It could later be updated to reflect more recent RFCs OR a "Mo= re of >>> > Hitchhikers Guide" could be published. >>> > >>> > Thanks, >>> > Mary. >>> > >>> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >>> > >> > wrote: >>> >> Hi Miguel, Andrew, all, >>> >> >>> >> Sounds like a good idea. I would be happy to volunteer to pla= y a >>> central role in it (i.e. be the editor, create the initial draft, >>> ...), but I would need support from other experts too. >>> >> >>> >> As for practicalities, I see that the "Hitchhiker's Guide to= SIP" >>> has become an RFC (5411). That means that it has been frozen, and= to >>> add new info new individual or WG drafts are needed. >>> >> >>> >> Would this be the same approach for SDP? Currently, there are >>> already quite some new drafts that extend SDP. How will future >>> extensions be handled? Maybe it would be good to make it a permane= nt >>> WG draft, which is updated every now and then. >>> >> >>> >> Best regards, >>> >> Bert >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: mmusic-bounces@ietf.org >>> [mailto:mmusic-bounces@ietf.org] O= n >>> Behalf Of Miguel A. Garcia >>> >> Sent: 14 February 2012 15:42 >>> >> To: Andrew Allen >>> >> Cc: mmusic@ietf.org >>> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >>> >> >>> >> Sounds good to me too. If someone wants to start such draft..= . >>> >> >>> >> /Miguel >>> >> >>> >> On 13/02/2012 23:15, Andrew Allen wrote: >>> >>> >>> >>> What about considering a hitchhikers guide to SDP similar to >>> what was done for SIP? >>> >>> >>> >>> One umbrella document that points the reader to all the SDP >>> capabilities available that they might want to take advantage of. >>> >>> >>> >>> Just a suggestion. >>> >>> >>> >>> Andrew >>> >>> >>> >>> ----- Original Message ----- >>> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com >>> ] >>> >>> Sent: Saturday, January 28, 2012 06:23 AM >>> >>> To: mmusic> >>> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >>> >>> >>> >>> >>> >>> >>> >>> Hi all, >>> >>> >>> >>> You know we are revising RFC 4566. So far, the effort has be= en >>> in bug fixing. >>> >>> >>> >>> The first SDP version was published as RFC 2327 in 1998 (i.e= ., >>> 14 years >>> >>> ago), and was then revised as RFC 4566 in 2006. >>> >>> >>> >>> Lots of things have happened since then. We have SDP offer a= nswer, >>> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, co= meida, >>> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in t= he pipe. >>> >>> >>> >>> From the point of view of a reader who takes 4566 (or it= s current >>> >>> 4566bis incarnation), I think it will be difficult for her o= r him to >>> >>> understand a protocol that ignores those other extensions. F= or >>> example, I >>> >>> recently post another e-mail where there is an apparent >>> contradiction >>> >>> between 4566 and ICE (see >>> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089= .html ). >>> >>> >>> >>> So, I was wondering if time has come to make not a bug corre= ction in >>> >>> 4566bis, but also put that RFC in context with the other >>> extensions that >>> >>> exist. This may include: >>> >>> >>> >>> - Add minor extensions to the core document, similarly to wh= at >>> we did >>> >>> with IPv6 support (i.e., 4566 =3D 2327 + 3266). I don't know= which >>> of these >>> >>> extensions make sense to include, this would be an exercise= to >>> do, but >>> >>> let me give you one potential example: RFC 4574, the SDP "la= bel" >>> >>> attribute is a 6 pages RFC. >>> >>> >>> >>> - Adding references to extensions, when it makes sense. For >>> example, ICE >>> >>> should be referred somewhere (see my previous post regarding= the "o" >>> >>> line). I guess capneg could be also mentioned, perhaps other= s. >>> >>> >>> >>> I know this is a bigger effort than anticipated, but the res= ult >>> could >>> >>> really help newcomers to this world. >>> >>> >>> >>> Now, it is your turn to express your opinions. Please do it. >>> >>> >>> >>> /Miguel >>> >> >>> >> -- >>> >> Miguel A. Garcia >>> >> +34-91-339-3608 >>> >> Ericsson Spain >>> >> _______________________________________________ >>> >> 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 >>> > _______________________________________________ >>> > 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 >> _______________________________________________ >> 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 >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Wed Mar 14 13:57:51 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 21E3321F884A for ; Wed, 14 Mar 2012 13:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 LtEO5gKxSQ+2 for ; Wed, 14 Mar 2012 13:57:50 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8E98121F8843 for ; Wed, 14 Mar 2012 13:57:50 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id lSCK1i00A1ZXKqc56YxrwK; Wed, 14 Mar 2012 20:57:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id lYxq1i00y07duvL3hYxq5J; Wed, 14 Mar 2012 20:57:50 +0000 Message-ID: <4F61064D.6010007@alum.mit.edu> Date: Wed, 14 Mar 2012 16:57:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120312230749.6064.2958.idtracker@ietfa.amsl.com> In-Reply-To: <20120312230749.6064.2958.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-01.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: Wed, 14 Mar 2012 20:57:51 -0000 In section 3, the way qualified-adjective is defined, the values for q-adjective ("admitted", ...) can be used not only with "aq" (e.g. aq:admitted), but can also be used with any other extension-mech that might later be defined. That is ok if it is your intent. Is it? I'm not at all clear what the distinction is between qualifed and unqualified adjectives. I suspect you could get the effect you want by discarding the distinction between qualified and unqualified adjectives, and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as adjectives. Thanks, Paul From Christian.Groves@nteczone.com Wed Mar 14 20:44: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 324A511E8074 for ; Wed, 14 Mar 2012 20:44: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=[AWL=0.000, 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 HPelSxYauWSc for ; Wed, 14 Mar 2012 20:44:41 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 019AB11E8093 for ; Wed, 14 Mar 2012 20:44:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAKxkYU920ZpX/2dsb2JhbAAMN7lIAQEBBAEBATUbGAMXBAsRBAEBAQkeBw8CFh8JCBMGAgEBBYgMulOKOYZGBKYCgnqBSA Received: from ppp118-209-154-87.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.154.87]) by ipmail06.adl2.internode.on.net with ESMTP; 15 Mar 2012 14:14:39 +1030 Message-ID: <4F6165A3.20409@nteczone.com> Date: Thu, 15 Mar 2012 14:44:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <46A1DF3F04371240B504290A071B4DB62467DFD6@szxeml509-mbx.china.huawei.com> <4F60510E.60206@ericsson.com> In-Reply-To: <4F60510E.60206@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 15 Mar 2012 03:44:43 -0000 Hello Miguel, I would support the addition of H.248/Megaco to the document as a user of SDP. I'm not sure that there are IETF defined documents that extends SDP for H.248 only. H.248/Megaco defines how SDP is used rather than extending it. There is H.248.15 which is listed in IANA that defines a new SDP attribute but this isn't an IETF document but is related to Megaco/H.248 which was. Likewise as Albrecht pointed out there's several other documents: H.248.39, .49 and .80 which also describe how SDP is used rather than extend anything. I'm not sure how this fits in with your proposal? Regards, Christian On 14/03/2012 7:04 PM, Miguel A. Garcia wrote: > Hi: > > Let me restate my opinion, as an individual contributor, not as a chair. > > I think the document, for it to be useful, has to list the > usages/extensions of SDP in *any* IETF document. This includes SIP, > H.248/MEGACO, and RTSP as a least. > > So, I believe the document should have at least 4 sections, one where > you discuss core documents used by any protocol (probably RFC 4566bis, > perhaps a few others as well). And then the document should list > extensions that are believed to be useful with only one particular > protocol (that one being SIP, H.248, or RTSP). > > That leaves outside the scope of the document those extensions that > are created in non-RFCs, for example, in ITU-T, ETSI, OMA, or 3GPP > documents (assuming there are those extensions, I don't know). So we > restrict the document to IETF-created extensions used by IETF-created > protocols. > > Of course, we can start listing SDP extensions to SIP documents, > bearing in mind that this is not the final goal. So, we can leave for > a next iteration the addition of additional extensions used by other > protocols. > > How about that? > > /Miguel > > > On 14/03/2012 2:24, Bert Greevenbosch wrote: >> Hi Miguel, all, >> >> Thanks for these references. I consulted the IANA site when writing >> the first draft, but in light of the current discussion on the scope >> of the document, I may have to do that again. >> >> The other reference (from opsawg) indeed contains some references to >> SIP. >> >> Do I correctly sense that it is the general feeling of the group that >> SIP should be in scope of the document? How about Megaco/H.248 and RTSP? >> >> Best regards, >> Bert >> >> >> >> -----Original Message----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: 07 March 2012 18:56 >> To: Bert Greevenbosch >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >> >> Bert, >> >> Here is another document with the same purpose. You can use it for >> inspiration. This is a bit more complex document, because it has to deal >> with several different protocols, rather than only one. >> >> http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >> >> The other document that you need to consult is the IANA SDP Parameters >> registry at: >> >> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >> >> This contains a list of all the SDP extensions, and they all should be >> listed in the hitchhiker's guide. >> >> /Miguel >> >> On 07/03/2012 3:54, Bert Greevenbosch wrote: >>> Hi all, >>> >>> On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to >>> SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I >>> have copied most initial text from there, and in addition included >>> an initial list of RFCs / drafts that seem relevant. >>> >>> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ >>> >>> >>> If the group is happy with this approach, I will be happy to >>> maintain an editor's role, and write more text. Obviously other >>> people's input will be highly appreciated, and indeed is needed. >>> >>> I look forward to your comments. >>> >>> Best regards, >>> Bert >>> >>> P.S. Unfortunately, I forgot to include "mmusic" in the name of the >>> draft. How to deal with this? >>> >>> >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Christer Holmberg >>> Sent: 27 February 2012 04:53 >>> To: Gonzalo Camarillo; Mary Barnes >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>> >>> >>> Hi, >>> >>> As a directorate member, I am willing to co-author such draft, >>> should a decision to write one be taken. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Gonzalo Camarillo >>> Sent: 23. helmikuuta 2012 19:31 >>> To: Mary Barnes >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>> >>> I agree. >>> >>> Gonzalo >>> >>> On 23/02/2012 7:06 PM, Mary Barnes wrote: >>>> I would think that in order for the document to have integrity that at >>>> least one of the directorate members should at least be a co-author. >>>> Otherwise, I see a lot more stuff falling through the cracks and >>>> needing to be resolved during WGLC and later, which usually isn't a >>>> good thing. The SIP Hitchhiker's guide provides a good example in >>>> that the author was also a primary contributor to RFC3261, etc. >>>> >>>> Mary. >>>> >>>> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >>>> >>> > >>>> wrote: >>>> >>>> Hi Mary, >>>> >>>> yes, the members of the SDP directorate would need to review >>>> such a >>>> guide. However, the fact that they agreed to be members of the >>>> directorate does not mean they will necessarily have cycles to >>>> significantly contribute to the creation of the guide. We >>>> need to make >>>> sure we have enough energy around this effort in order to >>>> start it. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> On 15/02/2012 7:14 PM, Mary Barnes wrote: >>>> > I think this is a good idea. I would think the experts that can >>>> > contribute (and should review) can be found in the new SDP >>>> > directorate: >>>> > http://www.ietf.org/iesg/directorate/sdp.html >>>> > BTW, it would be nice to have a link to this page on the MMUSIC WG >>>> wiki: >>>> > http://trac.tools.ietf.org/wg/mmusic/trac/wiki >>>> > >>>> > As far as whether to publish, I think it would be a good idea to >>>> > complete publication as IMHO that improves the integrity of the >>>> > information - i.e., more eyes review a published RFC than a draft. >>>> > It could later be updated to reflect more recent RFCs OR a >>>> "More of >>>> > Hitchhikers Guide" could be published. >>>> > >>>> > Thanks, >>>> > Mary. >>>> > >>>> > On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >>>> > >>> > wrote: >>>> >> Hi Miguel, Andrew, all, >>>> >> >>>> >> Sounds like a good idea. I would be happy to volunteer to play a >>>> central role in it (i.e. be the editor, create the initial >>>> draft, >>>> ...), but I would need support from other experts too. >>>> >> >>>> >> As for practicalities, I see that the "Hitchhiker's Guide to SIP" >>>> has become an RFC (5411). That means that it has been frozen, >>>> and to >>>> add new info new individual or WG drafts are needed. >>>> >> >>>> >> Would this be the same approach for SDP? Currently, there are >>>> already quite some new drafts that extend SDP. How will future >>>> extensions be handled? Maybe it would be good to make it a >>>> permanent >>>> WG draft, which is updated every now and then. >>>> >> >>>> >> Best regards, >>>> >> Bert >>>> >> >>>> >> >>>> >> -----Original Message----- >>>> >> From: mmusic-bounces@ietf.org >>>> >>>> [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Miguel A. Garcia >>>> >> Sent: 14 February 2012 15:42 >>>> >> To: Andrew Allen >>>> >> Cc: mmusic@ietf.org >>>> >> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >>>> >> >>>> >> Sounds good to me too. If someone wants to start such draft... >>>> >> >>>> >> /Miguel >>>> >> >>>> >> On 13/02/2012 23:15, Andrew Allen wrote: >>>> >>> >>>> >>> What about considering a hitchhikers guide to SDP similar to >>>> what was done for SIP? >>>> >>> >>>> >>> One umbrella document that points the reader to all the SDP >>>> capabilities available that they might want to take advantage >>>> of. >>>> >>> >>>> >>> Just a suggestion. >>>> >>> >>>> >>> Andrew >>>> >>> >>>> >>> ----- Original Message ----- >>>> >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com >>>> ] >>>> >>> Sent: Saturday, January 28, 2012 06:23 AM >>>> >>> To: mmusic> >>>> >>> Subject: [MMUSIC] Do we need to update in time 4566bis? >>>> >>> >>>> >>> >>>> >>> >>>> >>> Hi all, >>>> >>> >>>> >>> You know we are revising RFC 4566. So far, the effort has been >>>> in bug fixing. >>>> >>> >>>> >>> The first SDP version was published as RFC 2327 in 1998 (i.e., >>>> 14 years >>>> >>> ago), and was then revised as RFC 4566 in 2006. >>>> >>> >>>> >>> Lots of things have happened since then. We have SDP offer >>>> answer, >>>> >>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, >>>> comeida, >>>> >>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in >>>> the pipe. >>>> >>> >>>> >>> From the point of view of a reader who takes 4566 (or its >>>> current >>>> >>> 4566bis incarnation), I think it will be difficult for her or >>>> him to >>>> >>> understand a protocol that ignores those other extensions. For >>>> example, I >>>> >>> recently post another e-mail where there is an apparent >>>> contradiction >>>> >>> between 4566 and ICE (see >>>> >>> >>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >>>> >>> >>>> >>> So, I was wondering if time has come to make not a bug >>>> correction in >>>> >>> 4566bis, but also put that RFC in context with the other >>>> extensions that >>>> >>> exist. This may include: >>>> >>> >>>> >>> - Add minor extensions to the core document, similarly to what >>>> we did >>>> >>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which >>>> of these >>>> >>> extensions make sense to include, this would be an exercise to >>>> do, but >>>> >>> let me give you one potential example: RFC 4574, the SDP "label" >>>> >>> attribute is a 6 pages RFC. >>>> >>> >>>> >>> - Adding references to extensions, when it makes sense. For >>>> example, ICE >>>> >>> should be referred somewhere (see my previous post regarding >>>> the "o" >>>> >>> line). I guess capneg could be also mentioned, perhaps others. >>>> >>> >>>> >>> I know this is a bigger effort than anticipated, but the result >>>> could >>>> >>> really help newcomers to this world. >>>> >>> >>>> >>> Now, it is your turn to express your opinions. Please do it. >>>> >>> >>>> >>> /Miguel >>>> >> >>>> >> -- >>>> >> Miguel A. Garcia >>>> >> +34-91-339-3608 >>>> >> Ericsson Spain >>>> >> _______________________________________________ >>>> >> 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 >>>> > _______________________________________________ >>>> > 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 >>> _______________________________________________ >>> 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 miguel.a.garcia@ericsson.com Thu Mar 15 01:17:56 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 6E88621F8661 for ; Thu, 15 Mar 2012 01:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 j82PH6qN7O8Y for ; Thu, 15 Mar 2012 01:17:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BE7BD21F865B for ; Thu, 15 Mar 2012 01:17:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-ec-4f61a5b06ddf Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.91.27041.0B5A16F4; Thu, 15 Mar 2012 09:17:52 +0100 (CET) Received: from [159.107.24.252] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Thu, 15 Mar 2012 09:17:51 +0100 Message-ID: <4F61A5AF.9060901@ericsson.com> Date: Thu, 15 Mar 2012 09:17:51 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christian Groves References: <4F3A1055.10804@ericsson.com> <46A1DF3F04371240B504290A071B4DB623286CB6@szxeml509-mbs.china.huawei.com> <4F463159.5040903@ericsson.com> <4F4677D3.2090406@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3F4BAA07@ESESSCMS0356.eemea.ericsson.se> <46A1DF3F04371240B504290A071B4DB624510133@szxeml509-mbx.china.huawei.com> <4F573ED3.2030409@ericsson.com> <46A1DF3F04371240B504290A071B4DB62467DFD6@szxeml509-mbx.china.huawei.com> <4F60510E.60206@ericsson.com> <4F6165A3.20409@nteczone.com> In-Reply-To: <4F6165A3.20409@nteczone.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Hitchhiker's guide to SDP 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, 15 Mar 2012 08:17:57 -0000 Hi Christian: I believe the H.248/Megaco core protocol was a joint effort by the IETF and ITU-T, therefore, I think it should be listed. Now, if ITU-T has extensions, such as H.248.15 and alike, that have been defined only by ITU-T, I think the IETF should not enter to describe them, because we (IETF) do not have the expertise, and probably we will not do a good job here. We can always make a note indicating that ITU-T has additional usages of SDP defined in [list specifications here]. /Miguel On 15/03/2012 4:44, Christian Groves wrote: > Hello Miguel, > > I would support the addition of H.248/Megaco to the document as a user > of SDP. I'm not sure that there are IETF defined documents that extends > SDP for H.248 only. H.248/Megaco defines how SDP is used rather than > extending it. There is H.248.15 which is listed in IANA that defines a > new SDP attribute but this isn't an IETF document but is related to > Megaco/H.248 which was. Likewise as Albrecht pointed out there's several > other documents: H.248.39, .49 and .80 which also describe how SDP is > used rather than extend anything. > > I'm not sure how this fits in with your proposal? > > Regards, Christian > > On 14/03/2012 7:04 PM, Miguel A. Garcia wrote: >> Hi: >> >> Let me restate my opinion, as an individual contributor, not as a chair. >> >> I think the document, for it to be useful, has to list the >> usages/extensions of SDP in *any* IETF document. This includes SIP, >> H.248/MEGACO, and RTSP as a least. >> >> So, I believe the document should have at least 4 sections, one where >> you discuss core documents used by any protocol (probably RFC 4566bis, >> perhaps a few others as well). And then the document should list >> extensions that are believed to be useful with only one particular >> protocol (that one being SIP, H.248, or RTSP). >> >> That leaves outside the scope of the document those extensions that >> are created in non-RFCs, for example, in ITU-T, ETSI, OMA, or 3GPP >> documents (assuming there are those extensions, I don't know). So we >> restrict the document to IETF-created extensions used by IETF-created >> protocols. >> >> Of course, we can start listing SDP extensions to SIP documents, >> bearing in mind that this is not the final goal. So, we can leave for >> a next iteration the addition of additional extensions used by other >> protocols. >> >> How about that? >> >> /Miguel >> >> >> On 14/03/2012 2:24, Bert Greevenbosch wrote: >>> Hi Miguel, all, >>> >>> Thanks for these references. I consulted the IANA site when writing >>> the first draft, but in light of the current discussion on the scope >>> of the document, I may have to do that again. >>> >>> The other reference (from opsawg) indeed contains some references to >>> SIP. >>> >>> Do I correctly sense that it is the general feeling of the group that >>> SIP should be in scope of the document? How about Megaco/H.248 and RTSP? >>> >>> Best regards, >>> Bert >>> >>> >>> >>> -----Original Message----- >>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>> Sent: 07 March 2012 18:56 >>> To: Bert Greevenbosch >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>> >>> Bert, >>> >>> Here is another document with the same purpose. You can use it for >>> inspiration. This is a bit more complex document, because it has to deal >>> with several different protocols, rather than only one. >>> >>> http://tools.ietf.org/html/draft-ietf-opsawg-management-stds >>> >>> The other document that you need to consult is the IANA SDP Parameters >>> registry at: >>> >>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml >>> >>> This contains a list of all the SDP extensions, and they all should be >>> listed in the hitchhiker's guide. >>> >>> /Miguel >>> >>> On 07/03/2012 3:54, Bert Greevenbosch wrote: >>>> Hi all, >>>> >>>> On Monday, I have uploaded a v00 draft for "Hitchhiker's Guide to >>>> SDP". It is based on the "Hitchhiker's Guide to SIP" (RFC 5411). I >>>> have copied most initial text from there, and in addition included >>>> an initial list of RFCs / drafts that seem relevant. >>>> >>>> https://datatracker.ietf.org/doc/draft-greevenbosch-hitchhikersguide-sdp/ >>>> >>>> >>>> If the group is happy with this approach, I will be happy to >>>> maintain an editor's role, and write more text. Obviously other >>>> people's input will be highly appreciated, and indeed is needed. >>>> >>>> I look forward to your comments. >>>> >>>> Best regards, >>>> Bert >>>> >>>> P.S. Unfortunately, I forgot to include "mmusic" in the name of the >>>> draft. How to deal with this? >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: 27 February 2012 04:53 >>>> To: Gonzalo Camarillo; Mary Barnes >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>>> >>>> >>>> Hi, >>>> >>>> As a directorate member, I am willing to co-author such draft, >>>> should a decision to write one be taken. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: 23. helmikuuta 2012 19:31 >>>> To: Mary Barnes >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Hitchhiker's guide to SDP >>>> >>>> I agree. >>>> >>>> Gonzalo >>>> >>>> On 23/02/2012 7:06 PM, Mary Barnes wrote: >>>>> I would think that in order for the document to have integrity that at >>>>> least one of the directorate members should at least be a co-author. >>>>> Otherwise, I see a lot more stuff falling through the cracks and >>>>> needing to be resolved during WGLC and later, which usually isn't a >>>>> good thing. The SIP Hitchhiker's guide provides a good example in >>>>> that the author was also a primary contributor to RFC3261, etc. >>>>> >>>>> Mary. >>>>> >>>>> On Thu, Feb 23, 2012 at 6:30 AM, Gonzalo Camarillo >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi Mary, >>>>> >>>>> yes, the members of the SDP directorate would need to review >>>>> such a >>>>> guide. However, the fact that they agreed to be members of the >>>>> directorate does not mean they will necessarily have cycles to >>>>> significantly contribute to the creation of the guide. We >>>>> need to make >>>>> sure we have enough energy around this effort in order to >>>>> start it. >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>>>> On 15/02/2012 7:14 PM, Mary Barnes wrote: >>>>>> I think this is a good idea. I would think the experts that can >>>>>> contribute (and should review) can be found in the new SDP >>>>>> directorate: >>>>>> http://www.ietf.org/iesg/directorate/sdp.html >>>>>> BTW, it would be nice to have a link to this page on the MMUSIC WG >>>>> wiki: >>>>>> http://trac.tools.ietf.org/wg/mmusic/trac/wiki >>>>>> >>>>>> As far as whether to publish, I think it would be a good idea to >>>>>> complete publication as IMHO that improves the integrity of the >>>>>> information - i.e., more eyes review a published RFC than a draft. >>>>>> It could later be updated to reflect more recent RFCs OR a >>>>> "More of >>>>>> Hitchhikers Guide" could be published. >>>>>> >>>>>> Thanks, >>>>>> Mary. >>>>>> >>>>>> On Wed, Feb 15, 2012 at 12:29 AM, Bert Greevenbosch >>>>>> >>>> > wrote: >>>>>>> Hi Miguel, Andrew, all, >>>>>>> >>>>>>> Sounds like a good idea. I would be happy to volunteer to play a >>>>> central role in it (i.e. be the editor, create the initial >>>>> draft, >>>>> ...), but I would need support from other experts too. >>>>>>> >>>>>>> As for practicalities, I see that the "Hitchhiker's Guide to SIP" >>>>> has become an RFC (5411). That means that it has been frozen, >>>>> and to >>>>> add new info new individual or WG drafts are needed. >>>>>>> >>>>>>> Would this be the same approach for SDP? Currently, there are >>>>> already quite some new drafts that extend SDP. How will future >>>>> extensions be handled? Maybe it would be good to make it a >>>>> permanent >>>>> WG draft, which is updated every now and then. >>>>>>> >>>>>>> Best regards, >>>>>>> Bert >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mmusic-bounces@ietf.org >>>>> >>>>> [mailto:mmusic-bounces@ietf.org] On >>>>> Behalf Of Miguel A. Garcia >>>>>>> Sent: 14 February 2012 15:42 >>>>>>> To: Andrew Allen >>>>>>> Cc: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Do we need to update in time 4566bis? >>>>>>> >>>>>>> Sounds good to me too. If someone wants to start such draft... >>>>>>> >>>>>>> /Miguel >>>>>>> >>>>>>> On 13/02/2012 23:15, Andrew Allen wrote: >>>>>>>> >>>>>>>> What about considering a hitchhikers guide to SDP similar to >>>>> what was done for SIP? >>>>>>>> >>>>>>>> One umbrella document that points the reader to all the SDP >>>>> capabilities available that they might want to take advantage >>>>> of. >>>>>>>> >>>>>>>> Just a suggestion. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com >>>>> ] >>>>>>>> Sent: Saturday, January 28, 2012 06:23 AM >>>>>>>> To: mmusic> >>>>>>>> Subject: [MMUSIC] Do we need to update in time 4566bis? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> You know we are revising RFC 4566. So far, the effort has been >>>>> in bug fixing. >>>>>>>> >>>>>>>> The first SDP version was published as RFC 2327 in 1998 (i.e., >>>>> 14 years >>>>>>>> ago), and was then revised as RFC 4566 in 2006. >>>>>>>> >>>>>>>> Lots of things have happened since then. We have SDP offer >>>>> answer, >>>>>>>> Grouping, QoS, ATM, Bandwidth modifiers, TCP media, SDES, >>>>> comeida, >>>>>>>> labels, BFCP, FEC, ICE, CapNeg, and many other that are in >>>>> the pipe. >>>>>>>> >>>>>>>> From the point of view of a reader who takes 4566 (or its >>>>> current >>>>>>>> 4566bis incarnation), I think it will be difficult for her or >>>>> him to >>>>>>>> understand a protocol that ignores those other extensions. For >>>>> example, I >>>>>>>> recently post another e-mail where there is an apparent >>>>> contradiction >>>>>>>> between 4566 and ICE (see >>>>>>>> >>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09089.html ). >>>>>>>> >>>>>>>> So, I was wondering if time has come to make not a bug >>>>> correction in >>>>>>>> 4566bis, but also put that RFC in context with the other >>>>> extensions that >>>>>>>> exist. This may include: >>>>>>>> >>>>>>>> - Add minor extensions to the core document, similarly to what >>>>> we did >>>>>>>> with IPv6 support (i.e., 4566 = 2327 + 3266). I don't know which >>>>> of these >>>>>>>> extensions make sense to include, this would be an exercise to >>>>> do, but >>>>>>>> let me give you one potential example: RFC 4574, the SDP "label" >>>>>>>> attribute is a 6 pages RFC. >>>>>>>> >>>>>>>> - Adding references to extensions, when it makes sense. For >>>>> example, ICE >>>>>>>> should be referred somewhere (see my previous post regarding >>>>> the "o" >>>>>>>> line). I guess capneg could be also mentioned, perhaps others. >>>>>>>> >>>>>>>> I know this is a bigger effort than anticipated, but the result >>>>> could >>>>>>>> really help newcomers to this world. >>>>>>>> >>>>>>>> Now, it is your turn to express your opinions. Please do it. >>>>>>>> >>>>>>>> /Miguel >>>>>>> >>>>>>> -- >>>>>>> Miguel A. Garcia >>>>>>> +34-91-339-3608 >>>>>>> Ericsson Spain >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 >>>> >>> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Fri Mar 16 00:51: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 8032A21F8733 for ; Fri, 16 Mar 2012 00:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 bBFNEw4Vr0Yn for ; Fri, 16 Mar 2012 00:51:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 80C8621F873A for ; Fri, 16 Mar 2012 00:51:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-3f-4f62f1198c91 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.AD.27041.911F26F4; Fri, 16 Mar 2012 08:51:53 +0100 (CET) Received: from [159.107.24.214] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Mar 2012 08:51:52 +0100 Message-ID: <4F62F117.7040709@ericsson.com> Date: Fri, 16 Mar 2012 08:51:51 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Draft agenda fro MMUSIC@IETF 83 Paris 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, 16 Mar 2012 07:51:55 -0000 A draft agenda for the MMUSIC meeting in Paris has been posted: http://www.ietf.org/proceedings/83/agenda/agenda-83-mmusic.htm As you can see, we are really packed this time. /Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From dwing@cisco.com Sat Mar 17 19:43: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 4ADFF21F853C for ; Sat, 17 Mar 2012 19:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.356 X-Spam-Level: X-Spam-Status: No, score=-109.356 tagged_above=-999 required=5 tests=[AWL=1.243, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fApZPUHrddPO for ; Sat, 17 Mar 2012 19:43:44 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A851721F84A0 for ; Sat, 17 Mar 2012 19:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=498; q=dns/txt; s=iport; t=1332038624; x=1333248224; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=dJGI7NrLdvi0iOHP5VUdCctkUmnNWzFhFQSLJtijlKA=; b=ibCBccJzDUHmcUFKeAecks6eay7pHZ02Gqfb/A/f9oJRP/8c8ZHR+TrU j1AbeMK3eYja48V3rSK0fYAFl1T1P+gS1g7NshbGUZek4u7NHd4BOGGK4 +tca1DnqRpo93ZtTaQcm7Q2mimVh+/vpTZbrVri8j0QT5DXFir3QgGph1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFACxLZU+rRDoJ/2dsb2JhbABCpmCPYYEHghAICgEXED8NBRhQIxwBBAEdF4dnmneeJZB8BIhWhROWP4FogwY X-IronPort-AV: E=Sophos;i="4.73,604,1325462400"; d="scan'208";a="34008192" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 Mar 2012 02:43:43 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2I2hgXw020443; Sun, 18 Mar 2012 02:43:42 GMT From: "Dan Wing" To: , , Date: Sat, 17 Mar 2012 19:43:42 -0700 Message-ID: <066801cd04b0$eeb49660$cc1dc320$@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: Ac0EsO5XjwtterDRS7W6k8MnqLerdQ== Content-Language: en-us Cc: mmusic@ietf.org Subject: [MMUSIC] hen to send keymod (draft-zhou-mmusic-sdes-keymod-00) 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: Sun, 18 Mar 2012 02:43:45 -0000 To be effective, draft-zhou-mmusic-sdes-keymod needs the Answerer to send the "keymod" extension if it knows, or believes, the INVITE was re-targeted or forked. I have two questions: I see for the described re-targeting case (Section 5.1 of draft-zhou-mmusic-sdes-keymod-00), a "cause" parameter [RFC4458] can be a useful indicator that a call was re-targeted. Is the "cause" parameter always present when a call is re-targeted? How does the Answerer know if a call was forked? -d From fluffy@iii.ca Mon Mar 19 07:00:57 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 968AF21F8656; Mon, 19 Mar 2012 07:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.165, 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 sWr3LGp2ITp8; Mon, 19 Mar 2012 07:00:57 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 092D821F8647; Mon, 19 Mar 2012 07:00:56 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7010222E25E; Mon, 19 Mar 2012 10:00:50 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2012 08:00:48 -0600 Message-Id: To: "mmusic@ietf.org WG" , rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MMUSIC] ICE and draft-ietf-mmusic-sctp-sdp 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, 19 Mar 2012 14:00:57 -0000 I like draft-ietf-mmusic-sctp-sdp but I'd like to see it have more stuff = in it. Specifically I would like it to=20 1) clearly define how to do the SDP for use of SCTP over DTLS over UPD = with ICE. This is the use case we need to solve=20 2) make sure it works with bundle=20 3) SCTP has sub addresses (SCTP Channels), I think these need to be = negotiated as well in some cases so I would like to see an optional way = of negotiating and signaling the channels including correlation with = some sort of application defined label=20 Cullen=20 From wwwrun@rfc-editor.org Mon Mar 19 18:47:39 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 3309721F87B1; Mon, 19 Mar 2012 18:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 KxBbcxTxI7o4; Mon, 19 Mar 2012 18:47:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A105E21F87B0; Mon, 19 Mar 2012 18:47:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0B467B1E002; Mon, 19 Mar 2012 18:46:45 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120320014645.0B467B1E002@rfc-editor.org> Date: Mon, 19 Mar 2012 18:46:45 -0700 (PDT) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 6544 on TCP Candidates with Interactive Connectivity Establishment (ICE) 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, 20 Mar 2012 01:47:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6544 Title: TCP Candidates with Interactive Connectivity Establishment (ICE) Author: J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach Status: Standards Track Stream: IETF Date: March 2012 Mailbox: jdrosen@jdrosen.net, ari.keranen@ericsson.com, bbl@lowekamp.net, adam@nostrum.com Pages: 29 Characters: 72318 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-ice-tcp-16.txt URL: http://www.rfc-editor.org/rfc/rfc6544.txt Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From salvatore.loreto@ericsson.com Tue Mar 20 01:30:38 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 C405111E807F for ; Tue, 20 Mar 2012 01:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.995 X-Spam-Level: X-Spam-Status: No, score=-109.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 O2YAHQDrnOoe for ; Tue, 20 Mar 2012 01:30:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D030711E8074 for ; Tue, 20 Mar 2012 01:30:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-ed-4f68402c5eea Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F4.F6.27041.C20486F4; Tue, 20 Mar 2012 09:30:36 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 09:30:35 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C655D2320 for ; Tue, 20 Mar 2012 10:30:35 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CEFC152635 for ; Tue, 20 Mar 2012 10:30:35 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5E55F5260E for ; Tue, 20 Mar 2012 10:30:35 +0200 (EET) Message-ID: <4F68402A.1090109@ericsson.com> Date: Tue, 20 Mar 2012 09:30:34 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120312070303.18937.55225.idtracker@ietfa.amsl.com> <4F5DA093.7020900@ericsson.com> <4F5E3AC2.7070600@alum.mit.edu> In-Reply-To: <4F5E3AC2.7070600@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-01.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: Tue, 20 Mar 2012 08:30:38 -0000 On 3/12/12 7:04 PM, Paul Kyzivat wrote: > > On 3/12/12 3:06 AM, Salvatore Loreto wrote: >> Hi there, >> >> I have submitted a new version of the draft, that other then fix some >> little mistakes >> define the DTLS/SCTP protocol identifier >> to allow the usage of SCTP on top of the Datagram Transport Layer >> Security (DTLS) protocol, >> as defined in [I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP. >> >> SCTP over DTLS is used by the RTCWeb protocol suite for transporting >> non-media data between browsers. >> >> regards >> Salvatore > Generally this seems good, but I see a mistake (copy/paste error?) in > Section 7.2: > > Throughout this section (two occurrences) > s/connection:new/connection:existing/ thanks Paul, good catch I have fixed it in my personal copy cheers Salvatore > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Salvatore Loreto, PhD www.sloreto.com From salvatore.loreto@ericsson.com Tue Mar 20 01:56:48 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 61A9221F8721 for ; Tue, 20 Mar 2012 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.019 X-Spam-Level: X-Spam-Status: No, score=-110.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dfM4p5xK5PF8 for ; Tue, 20 Mar 2012 01:56:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65521F870A for ; Tue, 20 Mar 2012 01:56:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-61-4f68464e4ee2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.E7.17856.E46486F4; Tue, 20 Mar 2012 09:56:46 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 09:56:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3C1F62320 for ; Tue, 20 Mar 2012 10:56:45 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 46E1D52635 for ; Tue, 20 Mar 2012 10:56:45 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D6A0A5260E for ; Tue, 20 Mar 2012 10:56:44 +0200 (EET) Message-ID: <4F68464C.5080500@ericsson.com> Date: Tue, 20 Mar 2012 09:56:44 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <4F68460B.8060200@ericsson.com> In-Reply-To: <4F68460B.8060200@ericsson.com> X-Forwarded-Message-Id: <4F68460B.8060200@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] [rtcweb] ICE and draft-ietf-mmusic-sctp-sdp 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, 20 Mar 2012 08:56:48 -0000 Hi Cullen, On 3/19/12 3:00 PM, Cullen Jennings wrote: > I like draft-ietf-mmusic-sctp-sdp but I'd like to see it have more stuff in it. Specifically I would like it to > > 1) clearly define how to do the SDP for use of SCTP over DTLS over UPD with ICE. This is the use case we need to solve right, in Quebec we decided not to specify the ICE usage for *plain* SCTP in this draft... but for sure we have to define the usage of SCTP over DTLS with ICE in the draft > > 2) make sure it works with bundle +1 > > 3) SCTP has sub addresses (SCTP Channels), I think these need to be negotiated as well in some cases so I would like to see an optional way of negotiating and signaling the channels including correlation with some sort of application defined label yep, we can define a way to signal/negotiate the number of channels we want initially in the association vs having this number configured; and eventually even go further e.g. negotiate the addition of channels, and perhaps some sort of correlation of a channel with an application defined label Salvatore -- Salvatore Loreto, PhD www.sloreto.com From gonzalo.camarillo@ericsson.com Tue Mar 20 02:14:00 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 13C5621F876F for ; Tue, 20 Mar 2012 02:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.061 X-Spam-Level: X-Spam-Status: No, score=-110.061 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, 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 CYlTowD6a9ex for ; Tue, 20 Mar 2012 02:13:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3974921F875E for ; Tue, 20 Mar 2012 02:13:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-76-4f684a56de41 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.F1.27041.65A486F4; Tue, 20 Mar 2012 10:13:58 +0100 (CET) Received: from [131.160.36.191] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 10:13:57 +0100 Message-ID: <4F684A51.3040205@ericsson.com> Date: Tue, 20 Mar 2012 11:13:53 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Flemming Andreasen , Miguel Angel Garcia X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: [MMUSIC] SDP review of draft-ietf-avtext-rams-scenarios 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, 20 Mar 2012 09:14:00 -0000 Flemming, Miguel Angel, I have just requested the publication of the following AVTEXT draft. https://datatracker.ietf.org/doc/draft-ietf-avtext-rams-scenarios/ This draft contains a few SDP examples. Even if it does not define any new SDP extension, I would like somebody from the SDP directorate to have a quick look at it to make sure all SDPs in the draft are correct. Could you please get someone to do this? http://www.ietf.org/iesg/directorate/sdp.html I am cc:ing the MMUSIC list in case somebody else also wants to have a look at the draft. Thanks, Gonzalo From miguel.a.garcia@ericsson.com Tue Mar 20 02:33:52 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 8F2C721F85FF for ; Tue, 20 Mar 2012 02:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 MOj6hlx6CUcK for ; Tue, 20 Mar 2012 02:33:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 924C421F8596 for ; Tue, 20 Mar 2012 02:33:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-5b-4f684efed56d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.F6.27041.EFE486F4; Tue, 20 Mar 2012 10:33:50 +0100 (CET) Received: from [159.107.24.222] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 10:33:49 +0100 Message-ID: <4F684EFC.3000006@ericsson.com> Date: Tue, 20 Mar 2012 10:33:48 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4F684A51.3040205@ericsson.com> In-Reply-To: <4F684A51.3040205@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] SDP review of draft-ietf-avtext-rams-scenarios 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, 20 Mar 2012 09:33:52 -0000 Thanks Gonzalo, we will find someone to take a look at it. And thank you for copying the list, perhaps some volunteer can also take a look at the examples and post comments. /Miguel On 20/03/2012 10:13, Gonzalo Camarillo wrote: > Flemming, Miguel Angel, > > I have just requested the publication of the following AVTEXT draft. > > https://datatracker.ietf.org/doc/draft-ietf-avtext-rams-scenarios/ > > This draft contains a few SDP examples. Even if it does not define any > new SDP extension, I would like somebody from the SDP directorate to > have a quick look at it to make sure all SDPs in the draft are correct. > Could you please get someone to do this? > > http://www.ietf.org/iesg/directorate/sdp.html > > I am cc:ing the MMUSIC list in case somebody else also wants to have a > look at the draft. > > Thanks, > > Gonzalo > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Tue Mar 20 04:06:57 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 BA19F21F8675 for ; Tue, 20 Mar 2012 04:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 VZoVeltGcVON for ; Tue, 20 Mar 2012 04:06:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C689021F8671 for ; Tue, 20 Mar 2012 04:06:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-38-4f6864cf936b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A1.B7.17856.FC4686F4; Tue, 20 Mar 2012 12:06:56 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 20 Mar 2012 12:06:55 +0100 From: Christer Holmberg To: "mmusic@ietf.org" , "abegen@cisco.com" Date: Tue, 20 Mar 2012 12:06:55 +0100 Thread-Topic: SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 Thread-Index: Ac0GiBlimkSKNBncTMOtbfnALwkuTA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41456CAB@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: [MMUSIC] SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 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, 20 Mar 2012 11:06:57 -0000 Hi, I am the assigned SDP directorate reviewer for draft-ietf-avtext-rams-scena= rios-03. For background on 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: ------------ The draft contain both technical and editorial issues that need to be dealt= with before published. (I also think it needs to be verified that the RTP level multiplexing parts= are aligned with the discussions taking place in AVTCORE etc, but that is = outside the scope of this review). New SDP information elements: ---------------------------------------- The draft does not define any new SDP information elements. Technical: ------------ QT1: Same address:port for multiple m- lines At least in the example in section 3.1 the same address:port is used for mu= ltiple m- lines, which is not allowed. The text does say: "Note that the multicast destination ports in the above SDP do not matter,= and they could be the same or different." ...but I am not really sure what that means. =20 However, the same comment also applies to the example in section 5.1, where= the same address:port is also used for multiple m- lines, and there I can'= t find any text saying that the ports don't matter. QT2: RFC 5956 already has the problem identified in QT1. The bigger problem is that the problem above is introduced already in RFC 5= 956 (Forward Error Correction Grouping Semantics) - or, in fact already in = RFC 4756 (which is obsoleted by 5956). The RFC does mention that semantics = need to be defined for the usage of the same address:port, but I can't find= any such semantics defined in the RFC, nor is it listed in the requirement= s section of the RFC. ? Also, some of the issues we have identified in the = BUNDLE work, associated with the usage of the same address:port, don't seem= to be addressed in the RFC. As the RFC has been produced in MMUSIC, I think we need to discuss how to f= ix it. A 5956bis, where BUNDLE is used? Editorial: ----------- QE2: Destination port terminology The scenario chapters talk about "destination port", but it is a little unc= lear what it means, and what the SDP examples show. To me it sounds like th= ey show SDPs (either offers or answers) received by someone. QE3: Missing SDP information Mandatory SDP information elements (e.g. v=3D and o=3D) are missing from th= e SDP examples. Regards, Christer From abegen@cisco.com Tue Mar 20 13:18:07 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 B397721F85A8 for ; Tue, 20 Mar 2012 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 HkjpPYw6QhuK for ; Tue, 20 Mar 2012 13:18:07 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F023921F85A3 for ; Tue, 20 Mar 2012 13:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2629; q=dns/txt; s=iport; t=1332274687; x=1333484287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d8syilYX92oqDNkCbnb6eoDmEcdCD++nO16KReWgSV4=; b=MDd+CisRfKXQFMxTA/qUX3Io3xcxzJ9l5CY92lwauJhPNAsEMwf9wsdF 5k62WnkINE5v3mkC22GQfNzzOP/0CCcdFql4BKqOIzcBEs0ZOmlV69xZP JUi1H8X7o8dB5U1z4pdpeDGQxW2MVr1WSmEa0ocTijYLgFWIljqdEnOS1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB/laE+rRDoJ/2dsb2JhbABEtmSBB4IJAQEBAwESAWYFCwIBCCIkMiUBAQQBDQ0ah2MEAZgEnzSQHmMEpB6BaIJn X-IronPort-AV: E=Sophos;i="4.73,619,1325462400"; d="scan'208";a="36855688" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 20 Mar 2012 20:18:06 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2KKI5jU004697; Tue, 20 Mar 2012 20:18:05 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Tue, 20 Mar 2012 13:18:05 -0700 From: "Ali C. Begen (abegen)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 Thread-Index: Ac0GiBlimkSKNBncTMOtbfnALwkuTAATUA8w Date: Tue, 20 Mar 2012 20:18:04 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C41456CAB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41456CAB@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18786.001 x-tm-as-result: No--41.931800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gonzalo Camarillo Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 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, 20 Mar 2012 20:18:07 -0000 Hi Christer, Thanks for the review. > Technical: > ------------ >=20 > QT1: Same address:port for multiple m- lines >=20 > At least in the example in section 3.1 the same address:port is used for = multiple m- lines, which is not allowed. They have different c=3D lines.=20 =20 > The text does say: >=20 > "Note that the multicast destination ports in the above SDP do not matte= r, and they could be the same or different." >=20 > ...but I am not really sure what that means. In the example, I can change the port in the second m line to something els= e, that is still a valid example for this draft. But, since the example has= different c lines, I think this is still a valid SDP with the same port us= ed in both m lines. =20 > However, the same comment also applies to the example in section 5.1, whe= re the same address:port is also used for > multiple m- lines, and there I can't find any text saying that the ports = don't matter. I can repeat the same comment if you agree with the above. =20 > QT2: RFC 5956 already has the problem identified in QT1. Well, when we did the review for 5956, I was told that using different c li= nes would make using the same port in different m lines OK. =20 > The bigger problem is that the problem above is introduced already in RFC= 5956 (Forward Error Correction Grouping > Semantics) - or, in fact already in RFC 4756 (which is obsoleted by 5956)= . The RFC does mention that semantics need to be > defined for the usage of the same address:port, but I can't find any such= semantics defined in the RFC, nor is it listed in the > requirements section of the RFC. ? Also, some of the issues we have ident= ified in the BUNDLE work, associated with the usage > of the same address:port, don't seem to be addressed in the RFC. >=20 > As the RFC has been produced in MMUSIC, I think we need to discuss how to= fix it. A 5956bis, where BUNDLE is used? >=20 >=20 > Editorial: > ----------- >=20 > QE2: Destination port terminology >=20 > The scenario chapters talk about "destination port", but it is a little u= nclear what it means, and what the SDP examples show. > To me it sounds like they show SDPs (either offers or answers) received b= y someone. These are multicast flows so the destination port means where the packets a= re going to (from the source to the receivers). =20 >=20 > QE3: Missing SDP information >=20 > Mandatory SDP information elements (e.g. v=3D and o=3D) are missing from = the SDP examples. I can add these. Thanks. -acbegen =20 >=20 > Regards, >=20 > Christer From zhou.sujing@zte.com.cn Tue Mar 20 18:33:09 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 D532021E8084 for ; Tue, 20 Mar 2012 18:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.569 X-Spam-Level: X-Spam-Status: No, score=-94.569 tagged_above=-999 required=5 tests=[AWL=-1.779, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 53sc7VbkLtSO for ; Tue, 20 Mar 2012 18:33:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7B321E8020 for ; Tue, 20 Mar 2012 18:33:08 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280978252052; Wed, 21 Mar 2012 08:58:58 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 95246.2712434073; Wed, 21 Mar 2012 09:32:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2L1WmNF062079; Wed, 21 Mar 2012 09:32:48 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <066801cd04b0$eeb49660$cc1dc320$@com> To: "Dan Wing" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 21 Mar 2012 09:32:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-21 09:32:49, Serialize complete at 2012-03-21 09:32:49 Content-Type: multipart/alternative; boundary="=_alternative 00087F28482579C8_=" X-MAIL: mse02.zte.com.cn q2L1WmNF062079 Cc: xie.zhenhua@zte.com.cn, tian.tian1@zte.com.cn, mmusic@ietf.org Subject: [MMUSIC] =?gb2312?b?tPC4tDogaGVuIHRvIHNlbmQga2V5bW9kIChkcmFmdC16?= =?gb2312?b?aG91LW1tdXNpYy1zZGVzLWtleW1vZC0wMCk=?= 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, 21 Mar 2012 01:33:10 -0000 This is a multipart message in MIME format. --=_alternative 00087F28482579C8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrCBXaW5nDQoNCiAgICBZb3VyIHBvaW50IGlzIGdvb2QsIEkgbWF5IHVwZGF0ZSBvdXIgZHJh ZnQgKGluIDAxIHZlcnNpb24pIGxpa2UgdGhlIA0KZm9sbG93aW5nIHBhcmFncmFwaDoNCiIgMy4x LiAgR2VuZXJhdGluZyB0aGUgSW5pdGlhbCBPZmZlciAtIFVuaWNhc3QgU3RyZWFtcw0KDQogICBU aGUgZ2VuZXJhdGlvbiBvZiB0aGUgaW5pdGlhbCBvZmZlciBmb3IgYSB1bmljYXN0IHN0cmVhbSBN VVNUIGZvbGxvdw0KICAgdGhhdCBvZiB0aGUgY3J5cHRvIGF0dHJpYnV0ZSBSRkM0NTY4IFtSRkM0 NTY4XSwgYW5kIE1BWQ0KDQogICBhbHNvIGluY2x1ZGUgYW4gYWRkaXRpb25hbCAia2V5bW9kIiBw YXJhbWV0ZXIgd2l0aCBrZXltb2QtdmFsIGJlaW5nDQogICBOVUxMLiAgSXQgaW5kaWNhdGVzIHRv IHRoZSB1bHRpbWF0ZSBhbnN3ZXJlciB0aGF0IHRoZSBvZmZlcmVyIHdhbnRzDQogICB0byBlbXBs b3kgdGhlIG1lY2hhbmlzbSBzcGVjaWZpZWQgaW4NCg0KICAgdGhpcyBkb2N1bWVudCwgYSBrZXkg YWdyZWVtZW50IG1lY2hhbmlzbSB3aXRoIGEgaGlnaGVyIHNlY3VyaXR5IGxldmVsDQogICB0aGFu IHRoZSBvcmlnaW5hbCBTREVTLiANCiINClNvIHRoYXQgYW5zd2VyZXIgZG9lcyBub3QgbmVlZCB0 byBrbm93IGl0IGlzIGluIGEgcmUtdGFyZ2V0aW5nIG9yIGZvcmtpbmcgDQpzY2VuYXJpbywNCml0 IGlzIG9mZmVyZXIgc3VnZ2VzdGluZyB1c2Uga2V5bW9kIG1lY2hhbmlzbS4NCiANCg0KDQpSZWdh cmRzfn5+DQoNCi1TdWppbmcgWmhvdQ0KDQoiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5jb20+INC0 09ogMjAxMi0wMy0xOCAxMDo0Mzo0MjoNCg0KPiBUbyBiZSBlZmZlY3RpdmUsIGRyYWZ0LXpob3Ut bW11c2ljLXNkZXMta2V5bW9kIG5lZWRzIHRoZSBBbnN3ZXJlciB0byANCnNlbmQNCj4gdGhlICJr ZXltb2QiIGV4dGVuc2lvbiBpZiBpdCBrbm93cywgb3IgYmVsaWV2ZXMsIHRoZSBJTlZJVEUgd2Fz IA0KcmUtdGFyZ2V0ZWQNCj4gb3IgZm9ya2VkLiAgSSBoYXZlIHR3byBxdWVzdGlvbnM6DQo+IA0K PiBJIHNlZSBmb3IgdGhlIGRlc2NyaWJlZCByZS10YXJnZXRpbmcgY2FzZSAoU2VjdGlvbiA1LjEg b2YNCj4gZHJhZnQtemhvdS1tbXVzaWMtc2Rlcy1rZXltb2QtMDApLCBhICJjYXVzZSIgcGFyYW1l dGVyIFtSRkM0NDU4XSBjYW4gYmUgDQphDQo+IHVzZWZ1bCBpbmRpY2F0b3IgdGhhdCBhIGNhbGwg d2FzIHJlLXRhcmdldGVkLiAgSXMgdGhlICJjYXVzZSIgcGFyYW1ldGVyDQo+IGFsd2F5cyBwcmVz ZW50IHdoZW4gYSBjYWxsIGlzIHJlLXRhcmdldGVkPw0KPiANCj4gSG93IGRvZXMgdGhlIEFuc3dl cmVyIGtub3cgaWYgYSBjYWxsIHdhcyBmb3JrZWQ/DQo+IA0KPiAtZA0KPiANCj4gDQo+IA0KPiAN Cj4gDQoNCg== --=_alternative 00087F28482579C8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6wgV2luZzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBZb3Vy IHBvaW50IGlzIGdvb2QsIEkNCm1heSB1cGRhdGUgb3VyIGRyYWZ0IChpbiAwMSB2ZXJzaW9uKSBs aWtlIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7IDMuMS4gJm5ic3A7R2VuZXJhdGluZyB0aGUgSW5pdGlhbA0K T2ZmZXIgLSBVbmljYXN0IFN0cmVhbXM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtUaGUgZ2VuZXJhdGlvbiBvZiB0aGUgaW5pdGlh bA0Kb2ZmZXIgZm9yIGEgdW5pY2FzdCBzdHJlYW0gTVVTVCBmb2xsb3c8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0aGF0IG9mIHRoZSBjcnlw dG8gYXR0cmlidXRlDQpSRkM0NTY4IFtSRkM0NTY4XSwgYW5kIE1BWTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2Fsc28gaW5jbHVk ZSBhbiBhZGRpdGlvbmFsDQomcXVvdDtrZXltb2QmcXVvdDsgcGFyYW1ldGVyIHdpdGgga2V5bW9k LXZhbCBiZWluZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO05VTEwuICZuYnNwO0l0IGluZGljYXRlcw0KdG8gdGhlIHVsdGltYXRlIGFuc3dl cmVyIHRoYXQgdGhlIG9mZmVyZXIgd2FudHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0byBlbXBsb3kgdGhlIG1lY2hhbmlzbQ0Kc3BlY2lm aWVkIGluPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7dGhpcyBkb2N1bWVudCwgYSBrZXkgYWdyZWVtZW50DQptZWNoYW5pc20gd2l0 aCBhIGhpZ2hlciBzZWN1cml0eSBsZXZlbDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RoYW4gdGhlIG9yaWdpbmFsIFNERVMuDQombmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gdGhhdCBhbnN3ZXJlciBkb2Vz IG5vdCBuZWVkIHRvIGtub3cNCml0IGlzIGluIGEgcmUtdGFyZ2V0aW5nIG9yIGZvcmtpbmcgc2Nl bmFyaW8sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pdCBpcyBv ZmZlcmVyIHN1Z2dlc3RpbmcgdXNlIGtleW1vZA0KbWVjaGFuaXNtLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1 amluZyBaaG91PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7RGFuIFdp bmcmcXVvdDsgJmx0O2R3aW5nQGNpc2NvLmNvbSZndDsg0LTT2g0KMjAxMi0wMy0xOCAxMDo0Mzo0 Mjo8YnI+DQo8YnI+DQomZ3Q7IFRvIGJlIGVmZmVjdGl2ZSwgZHJhZnQtemhvdS1tbXVzaWMtc2Rl cy1rZXltb2QgbmVlZHMgdGhlIEFuc3dlcmVyDQp0byBzZW5kPGJyPg0KJmd0OyB0aGUgJnF1b3Q7 a2V5bW9kJnF1b3Q7IGV4dGVuc2lvbiBpZiBpdCBrbm93cywgb3IgYmVsaWV2ZXMsIHRoZSBJTlZJ VEUNCndhcyByZS10YXJnZXRlZDxicj4NCiZndDsgb3IgZm9ya2VkLiAmbmJzcDtJIGhhdmUgdHdv IHF1ZXN0aW9uczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBzZWUgZm9yIHRoZSBkZXNjcmliZWQg cmUtdGFyZ2V0aW5nIGNhc2UgKFNlY3Rpb24gNS4xIG9mPGJyPg0KJmd0OyBkcmFmdC16aG91LW1t dXNpYy1zZGVzLWtleW1vZC0wMCksIGEgJnF1b3Q7Y2F1c2UmcXVvdDsgcGFyYW1ldGVyIFtSRkM0 NDU4XQ0KY2FuIGJlIGE8YnI+DQomZ3Q7IHVzZWZ1bCBpbmRpY2F0b3IgdGhhdCBhIGNhbGwgd2Fz IHJlLXRhcmdldGVkLiAmbmJzcDtJcyB0aGUgJnF1b3Q7Y2F1c2UmcXVvdDsNCnBhcmFtZXRlcjxi cj4NCiZndDsgYWx3YXlzIHByZXNlbnQgd2hlbiBhIGNhbGwgaXMgcmUtdGFyZ2V0ZWQ/PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEhvdyBkb2VzIHRoZSBBbnN3ZXJlciBrbm93IGlmIGEgY2FsbCB3YXMg Zm9ya2VkPzxicj4NCiZndDsgPGJyPg0KJmd0OyAtZDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 00087F28482579C8_=-- From christer.holmberg@ericsson.com Tue Mar 20 23:52:15 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 E9F5321E8019 for ; Tue, 20 Mar 2012 23:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 XT42f2JJV6sS for ; Tue, 20 Mar 2012 23:52:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BA09521E8018 for ; Tue, 20 Mar 2012 23:52:14 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-ce-4f697a9d42d0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.16.27041.D9A796F4; Wed, 21 Mar 2012 07:52:13 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 21 Mar 2012 07:52:13 +0100 From: Christer Holmberg To: "Ali C. Begen (abegen)" , "mmusic@ietf.org" Date: Wed, 21 Mar 2012 07:52:12 +0100 Thread-Topic: SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 Thread-Index: Ac0GiBlimkSKNBncTMOtbfnALwkuTAATUA8wABY3CdA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C414570DE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C41456CAB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 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, 21 Mar 2012 06:52:16 -0000 Hi Ali, >> Technical: >> ------------ >>=20 >> QT1: Same address:port for multiple m- lines >>=20 >> At least in the example in section 3.1 the same address:port is used for= multiple m- lines, which is not allowed. > > They have different c=3D lines.=20 > >> The text does say: >>=20 >> "Note that the multicast destination ports in the above SDP do not matt= er, and they could be the same or different." >>=20 >> ...but I am not really sure what that means. > > In the example, I can change the port in the second m line to something e= lse, that is still a valid example for this draft. But, since the example h= as different c lines, I think this is still a valid SDP with the same port = used in both m lines. > >> However, the same comment also applies to the example in section 5.1,=20 >> where the same address:port is also used for multiple m- lines, and ther= e I can't find any text saying that the ports don't matter. > >I can repeat the same comment if you agree with the above. >=20 >>> QT2: RFC 5956 already has the problem identified in QT1. >> >> Well, when we did the review for 5956, I was told that using different c= lines would make using the same port in different m lines OK. That is true. It's my mistake for not detecting the different c lines. So, if you are using different c lines in every place where you use the sam= e port then my technical issue is solved :) =20 >> Editorial: >> ----------- >>=20 >> QE2: Destination port terminology >>=20 >> The scenario chapters talk about "destination port", but it is a little = unclear what it means, and what the SDP examples show. >> To me it sounds like they show SDPs (either offers or answers) received = by someone. > > These are multicast flows so the destination port means where the packets= are going to (from the source to the receivers). =20 Yes. But, what are the SDP examples showing? Normally we show Offer and/or = Answer examples, in which case the SDP bodies contain local ports (from the= offerer/answer's perspective). =20 >> QE3: Missing SDP information >>=20 >> Mandatory SDP information elements (e.g. v=3D and o=3D) are missing from= the SDP examples. > > I can add these. Thanks! :) Regards, Christer From ron.even.tlv@gmail.com Wed Mar 21 02:11:30 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 0400021F8652 for ; Wed, 21 Mar 2012 02:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.277, 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 S30KiWZ2uZ2p for ; Wed, 21 Mar 2012 02:11:29 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7A0921F864E for ; Wed, 21 Mar 2012 02:11:28 -0700 (PDT) Received: by werb10 with SMTP id b10so887813wer.31 for ; Wed, 21 Mar 2012 02:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=Tg0iGj8vd/LQNpxYfs3lXWKKbAHOy+p0B+XUtJsL3qw=; b=oPOwCoCa6Lh/PbGssTT4b5MBOECE8kL75wM1Aekh26Hq+mvDalaPGa/9d+tdp+RZY5 14r4Rp/UyrN+txqLzdGrdSNkldkv5p2HTi/B/SoZ/f3aghTkruwO1Ejtoaq+AtLwE2+A gLhuYZIQUAkwWmqWv8kcVa8R9uaDYwWbncEb1z+kbOCQbS7yABwCJk8aUV4xSTQkfbkh nCBzIeJDuqz4MO+Tgqkxza61ccdGinBnwE+2V1EMPNSNmc11kxk07wgiprQinpICbuTA KwrwL37p2qjO+IfGS2QxOXUEIhUt8juwccF8N8z2KpWEvplEkqMJ/YT0vxBD19MNchME 1zmg== Received: by 10.180.14.73 with SMTP id n9mr7150087wic.16.1332321082930; Wed, 21 Mar 2012 02:11:22 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id fz9sm3043309wib.3.2012.03.21.02.11.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 02:11:22 -0700 (PDT) From: "Roni Even" To: Date: Wed, 21 Mar 2012 11:10:19 +0200 Message-ID: <4f699b3a.e967b40a.7238.ffff8945@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024A_01CD0753.35A331E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0HQnAh5UUeVUyaSUuDDYly4Sq1rQ== Content-Language: en-us Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-00 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, 21 Mar 2012 09:11:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_024A_01CD0753.35A331E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I read the draft, some comments and typos 1. In section 2 the text about bundle media says that RTCP mux is optional. Section 6.1 5th bullet mandate RTCP multiplexing and the example in section 10 do not have RTCP-MUX. I am wondering if we need to mandate RTCP-MUX when defining this grouping attribute in MMUSIC. Maybe for RTCweb it can be mandated but I think that here we should make this optional as in section 2. 2. In section 6.2 " If the SDP Offerer is not able to separate multiple media received on a single port, it MUST send a new SDP Offer ", I am not sure how does the offerer know it cannot separate multiple media in a single port since by sending BUNDLE grouping it says it can separate and the assumption is that that the answer will have allow different 5-tuple for each m-line, is it based on the answer or is this based on some application logic. 3. Also in the same section "If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has reasons to believe ". What are reasons to believe, I think that this will be when the answer do not understand BUNDLE and do not support multiple m-lines of same media type for example it may reject the offer (sending for example 488 or 606). Are there other cases. 4. In section 6.3 the last paragraph and mostly the last sentence is true if the answerer understand BUNDLE but does not want to use it by omitting the bundle attribute in the response. Otherwise I am not sure how you can have a "MUST" in the last sentence. Typo: Both section 2 and 3 have the RFC2119 reference. In section 6.2 second paragraph "proceudres" In section 6.3 "session-evel " In section 12 " athmosphere" should be " atmosphere" Roni Even _____ ------=_NextPart_000_024A_01CD0753.35A331E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read the = draft, some comments and typos

 

1.       = In section 2 the text = about bundle media says that RTCP mux is optional.  Section 6.1 = 5th bullet mandate RTCP multiplexing and the example in = section 10 do not have RTCP-MUX.  I am wondering if we need to = mandate RTCP-MUX when defining this grouping attribute in MMUSIC. Maybe = for RTCweb it can be mandated but I think that here we should make this = optional as in section 2.

2.       = In section 6.2 " If = the SDP Offerer is not able to separate multiple media received on  = a single port, it MUST send a new SDP Offer ", I am not sure how = does the offerer know it cannot separate multiple media in a single port = since by sending BUNDLE grouping it says it can separate and the = assumption is that that the answer will have allow different 5-tuple for = each m-line, is it based on the answer or is this based on some = application logic.  

3.       = Also in the same section = "If an SDP Offer, offering a "BUNDLE" group, and the SDP = Offerer has  reasons to believe  ". What are reasons to = believe, I think that this will be when the answer do not understand = BUNDLE and do not support multiple m-lines of same media type for = example it may reject the offer (sending for example 488 or 606). Are = there other cases.  

4.       = In section 6.3 the last = paragraph and mostly the last sentence is true if the answerer = understand BUNDLE but does not want to use it by omitting the bundle = attribute in the response. Otherwise I am not sure how you can have a = "MUST" in the last sentence.

 

 

 

 

Typo:

Both section = 2 and 3 have the RFC2119 reference.

 

In section = 6.2 second paragraph "proceudres" =  

 

In = section 6.3 = "session-evel " =

 

In = section 12 " athmosphere" = should be " atmosphere"

 

 

Roni = Even

 

 

 

 

------=_NextPart_000_024A_01CD0753.35A331E0-- From christer.holmberg@ericsson.com Wed Mar 21 03:44:54 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 E227421F8516 for ; Wed, 21 Mar 2012 03:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.28 X-Spam-Level: X-Spam-Status: No, score=-10.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 lk-awECEzLFs for ; Wed, 21 Mar 2012 03:44:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0E46E21F850D for ; Wed, 21 Mar 2012 03:44:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-66-4f69b1244895 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 18.CC.27041.521B96F4; Wed, 21 Mar 2012 11:44:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 21 Mar 2012 11:44:52 +0100 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Date: Wed, 21 Mar 2012 11:44:51 +0100 Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-00 Thread-Index: Ac0HQnAh5UUeVUyaSUuDDYly4Sq1rQABoC7Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41457308@ESESSCMS0356.eemea.ericsson.se> References: <4f699b3a.e967b40a.7238.ffff8945@mx.google.com> In-Reply-To: <4f699b3a.e967b40a.7238.ffff8945@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-00 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, 21 Mar 2012 10:44:55 -0000 Hi Roni, > I read the draft, some comments and typos > > 1. In section 2 the text about bundle media says that RTCP mux is optiona= l.=A0 Section 6.1 5th bullet mandate RTCP multiplexing and the example in=20 > section 10 do not have RTCP-MUX. =A0I am wondering if we need to mandate = RTCP-MUX when defining this grouping attribute in MMUSIC. Maybe=20 > for RTCweb it can be mandated but I think that here we should make this o= ptional as in section 2. The original intention of section 2 was to say that all RTCP streams share = the same port , but that they may or may not share the port with the RTP st= reams.=20 I agree that section 6.1 currently mandates that the RTCP streams and RTP s= treams are multiplexed on a single port. I will need to think a little more= about it, but at the moment I see no reason why not making it optional.=20 I can add it as an open issue in my Paris presentation. > 2. In section 6.2 " If the SDP Offerer is not able to separate multiple m= edia received on=A0 a single port, it MUST send a new SDP Offer ", I am not= sure=20 > how does the offerer know it cannot separate multiple media in a single p= ort since by sending BUNDLE grouping it says it can separate and the assump= tion > is that that the answer will have allow different 5-tuple for each m-line= , is it based on the answer or is this based on some application logic. =A0 I will need to think about what the reasoning behind the text was. > 3. Also in the same section "If an SDP Offer, offering a "BUNDLE" group, = and the SDP Offerer has=A0 reasons to believe =A0". What are reasons to bel= ieve, I think > that this will be when the answer do not understand BUNDLE and do not sup= port multiple m-lines of same media type for example it may reject the offe= r > (sending for example 488 or 606). Are there other cases. =A0 Yes. But, 488/606 can be sent for a number of reasons, and there might not = be an explicit indicator saying "I do not accept your offer which uses the = same port for multiple m- lines". So, the client might make the assumption based on additional information, p= reviously sent Offers, configuration etc. > 4. In section 6.3 the last paragraph and mostly the last sentence is true= if the answerer understand BUNDLE but does not want to use it by omitting = the=20 > bundle attribute in the response. Otherwise I am not sure how you can hav= e a "MUST" in the last sentence. True, but I assume that the procedures apply to entities that do support th= e BUNDLE mechanism. But, if you want, I can modify the first sentence of the last paragraph to: "If the SDP Answerer supports the BUNDLE grouping extension, but does not accept the..." > Typo: > Both section 2 and 3 have the RFC2119 reference. I think that is the part of the template, but I'll double check. > In section 6.2 second paragraph "proceudres" =A0 > > In section 6.3 "session-evel "=20 > > In section 12 " athmosphere" should be " atmosphere" Will be fixed. Thanks! Regards, Christer From abegen@cisco.com Wed Mar 21 12:19:52 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 E57BC21E80BD for ; Wed, 21 Mar 2012 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 9jUUAwwIuq24 for ; Wed, 21 Mar 2012 12:19:52 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4574821E80BC for ; Wed, 21 Mar 2012 12:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=988; q=dns/txt; s=iport; t=1332357592; x=1333567192; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1+dl9dFYe3eEF8geRUBPrZtkafAez8D5XqipqIFE8BA=; b=RKkzr/fcXlhKiO1jRawjx3bP4CM+ecuVXHUyGbCENVqTSXU4E/HWfdT/ cpw7VJbd0RCmYO1PBXEFQNXDMI+xdl8onvZn2d7NhhxK3A0FT3B9TC7gH RrpMAtfnlnwhdTmcGTn6Z0WxECGsFPpjeaRj9LpjshjuUvIVRToMFjNgv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANAoak+rRDoJ/2dsb2JhbABEtwmBB4IJAQEBAwESAWYQAgEIIiQyJQEBBAENDRqHYwQBmH+fApAeYwSkHoFogmc X-IronPort-AV: E=Sophos;i="4.73,624,1325462400"; d="scan'208";a="37017026" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 21 Mar 2012 19:19:52 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2LJJpxk005694; Wed, 21 Mar 2012 19:19:51 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Wed, 21 Mar 2012 12:19:51 -0700 From: "Ali C. Begen (abegen)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 Thread-Index: Ac0GiBlimkSKNBncTMOtbfnALwkuTAATUA8wABY3CdAAGjtMgA== Date: Wed, 21 Mar 2012 19:19:50 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C41456CAB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C414570DE@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C414570DE@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18788.001 x-tm-as-result: No--34.272100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gonzalo Camarillo Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-avtext-rams-scenarios-03 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, 21 Mar 2012 19:19:53 -0000 Thank Christer. One comment below. > >> QE2: Destination port terminology > >> > >> The scenario chapters talk about "destination port", but it is a littl= e unclear what it means, and what the SDP examples > show. > >> To me it sounds like they show SDPs (either offers or answers) receive= d by someone. > > > > These are multicast flows so the destination port means where the packe= ts are going to (from the source to the receivers). >=20 > Yes. But, what are the SDP examples showing? Normally we show Offer and/o= r Answer examples, in which case the SDP > bodies contain local ports (from the offerer/answer's perspective). Well, it is a multicast flow and the only port that makes sense in the mult= icast context is the port the multicast packets are destined to. I.e., the = port the receivers have to listen to in order to receive the multicast pack= ets. Can the meaning of the port in the SDP examples be understood in a dif= ferent way? -acbegen From tireddy@cisco.com Wed Mar 21 11:07: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 1CC6321F8582 for ; Wed, 21 Mar 2012 11:07: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 u2ueygwQEu7J for ; Wed, 21 Mar 2012 11:07:40 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id F317821F8578 for ; Wed, 21 Mar 2012 11:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=3440; q=dns/txt; s=iport; t=1332353259; x=1333562859; h=mime-version:subject:date:message-id:from:to:cc; bh=42urCld4c8JvLE49SdGPYkf1nMduQQmlKt0D6tHKX9U=; b=SKoYBRTw5oBCem7IfjdQ9ZPI0QqSknXwP7V51E1PFwjNt++HcsYnJUJT kpann72dJ1/Jus4L4thtjIfXG66LMNz89OmBrXk2weZKFmP1mTgajAmki KPrdsCHX9nUWaGuzrAVz4Wn++mt2Zl695dT7H/MEY/TzedE21QpHnN9A8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABAYak9Io8UY/2dsb2JhbABEgka1SoILAQQSAQkRA0kSAQweBhgHVwEECxAah2iZAJ8NjV+CP2MEiFSbSoFogm8 X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208,217";a="8349847" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 21 Mar 2012 18:07:37 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2LI7ahX023732; Wed, 21 Mar 2012 18:07:36 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 23:37:36 +0530 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_01CD078D.7EB681F4" Date: Wed, 21 Mar 2012 23:37:34 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC0180765E609@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-singh-avtcore-mprtp-04 Thread-Index: Ac0HjXzHVLt3+JLqRsmdFDw32fkukw== From: "Tirumaleswar Reddy (tireddy)" To: X-OriginalArrivalTime: 21 Mar 2012 18:07:36.0429 (UTC) FILETIME=[7EE459D0:01CD078D] X-Mailman-Approved-At: Wed, 21 Mar 2012 14:36:09 -0700 Cc: mmusic@ietf.org, "Dan Wing \(dwing\)" Subject: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04 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, 21 Mar 2012 18:07:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD078D.7EB681F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Varun - =20 I have few comments related to the draft =20 a)How is the situation handled when new network paths become available/disabled after the call is setup ? (3G enabled/disabled after the call is setup) b)There is little information related to IPv6. How SIP Client would pick among list of ULA, link-local addresses, IPv6 global addresses with different precedence using ICE (refer to draft-keranen-mmusic-ice-adress-selection) ? =20 Regards, Tiru. =20 ------_=_NextPart_001_01CD078D.7EB681F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Varun –

 

I have few comments related to the = draft

 

a)How is the situation handled when new network = paths become available/disabled after the call is setup ?

    (3G enabled/disabled after the = call is setup)

b)There is little information related to IPv6. How = SIP Client would pick among list of ULA, link-local addresses, IPv6 global addresses with different precedence using ICE (refer to draft-keranen-mmusic-ice-adress-selection) ?

 

Regards,

Tiru.

 

------_=_NextPart_001_01CD078D.7EB681F4-- From miguel.a.garcia@ericsson.com Thu Mar 22 08:02: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 238C421F868A for ; Thu, 22 Mar 2012 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 RbObqSRJC8pn for ; Thu, 22 Mar 2012 08:02:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5D54D21F853A for ; Thu, 22 Mar 2012 08:02:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-20-4f6b3f018a1e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.27.17856.10F3B6F4; Thu, 22 Mar 2012 16:02:26 +0100 (CET) Received: from [159.107.48.37] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 16:02:25 +0100 Message-ID: <4F6B3F01.1010007@ericsson.com> Date: Thu, 22 Mar 2012 16:02:25 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] SDP directorate: Review of draft-ietf-avtcore-feedback-supression-rtp 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, 22 Mar 2012 15:02:28 -0000 We have received a request from the AVTCORE WG to review the following draft: https://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/ While someone from the SDP directorate will be allocated to conduct a review in the next few days, we announce it here on the list in case additional people want to take a look at the document, from the SDP point of view. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From vsingh.ietf@gmail.com Thu Mar 22 08:29: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 CC34621F860B for ; Thu, 22 Mar 2012 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 hzL5IWUSegoV for ; Thu, 22 Mar 2012 08:29:58 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7A8321F8602 for ; Thu, 22 Mar 2012 08:29:57 -0700 (PDT) Received: by werb10 with SMTP id b10so2311064wer.31 for ; Thu, 22 Mar 2012 08:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SoTH4qsUZ7Sphw0n+kXHBZ2rFUejag5DlFR7YAsKX7M=; b=NCAvSOMOqD3ozfSwDKOzrTDk/AQzBVX96gG2BfEuZDVvpGsf99CmAk8s1sKZn2/piP HbuQtB3Ar/MSQVvliTyMOCtKGE7KZaQQOrPhlFSlpp7IIuJKNDYQ37K4/jgiUY2F2LvI ZLgchhtSCtzah6OCuZ+Z/OV0CAoLF9LqBoFxhyCya+CYgDR86aheseXWN5sJdvSuoWMb /giGHJVsb0tcv3Kq1UKXGsR5G2bdsP7n+wqa/O4kCkYfk6vBt1E08emIr7Kfm+DjgDz2 SYalIH74kyaKiUwtKui0xYd0qrJ9uffH/eifEzwaq2XiNv0z0Tb/H3mlJ9LNYh2fD4a9 lQHQ== Received: by 10.216.141.212 with SMTP id g62mr5013531wej.2.1332430196769; Thu, 22 Mar 2012 08:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.96.134 with HTTP; Thu, 22 Mar 2012 08:29:36 -0700 (PDT) In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC0180765E609@XMB-BGL-41B.cisco.com> References: <454A16E4DA86094EB66BB2C1DBBBC0180765E609@XMB-BGL-41B.cisco.com> From: Varun Singh Date: Thu, 22 Mar 2012 17:29:36 +0200 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?J=F6rg_Ott?= , mmusic@ietf.org, "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04 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, 22 Mar 2012 15:29:58 -0000 Hi Tiru, Response inline. On Wed, Mar 21, 2012 at 20:07, Tirumaleswar Reddy (tireddy) wrote: > Hi Varun =96 > > I have few comments related to the draft > > a)How is the situation handled when new network paths become > available/disabled after the call is setup ? > > =A0=A0=A0 (3G enabled/disabled after the call is setup) > This is a local decision and MPRTP will use all available paths. Either the application or ICE or something else needs to tell MPRTP when an interface is available or unavailable. At the media level (in the worst case) the sending endpoint will discover a path is unavailable when a subflow reports 100% loss and it will stop using it. Alternatively, if the endpoint discovers that one of its interface is disabled it can advertise a new set of interfaces (excluding the disabled interface from the set) to the other endpoint. > b)There is little information related to IPv6. How SIP Client would pick > among list of ULA, link-local addresses, IPv6 global addresses with > different precedence using ICE (refer to > draft-keranen-mmusic-ice-adress-selection) ? > It is also a local decision. This should not be different from the choices made by an endpoint using a single path. if an endpoint is using ICE then it just inherits the ICE priorities. For both these queries, do you have something specific in mind? Cheers, Varun --=20 http://www.netlab.tkk.fi/~varun/ From tireddy@cisco.com Fri Mar 23 04:36:17 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 6F8F421F8512 for ; Fri, 23 Mar 2012 04:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 IVeLOSBzsYlO for ; Fri, 23 Mar 2012 04:36:12 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id E595F21F850B for ; Fri, 23 Mar 2012 04:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=2846; q=dns/txt; s=iport; t=1332502572; x=1333712172; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=aC6xzkuzvzzlolUCfGlgdsnotlwY0oVJ+idL1IQ9IZY=; b=koCup6FqJOWwhMJDCQfdNbUuq+amNG9FXultyGmcx81i/TP3s5l18EeE YqEYDEiEHV7+sSyTMJqQEhfx6tkEiDQgii//HP/tDBkE9uoUj9kSFjOZt VAcqyk1g9oq4pLugPnBuV1ZYjDBvBZeewbPBh7rq37YTkkxIi4AinqBnb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAGpfbE9Io8UY/2dsb2JhbABEFrh4ggkBAQEDARIBHUkMBAIBCA4DBAEBAQoGFwEGASAlCQgBAQQLCAgah2MFmUaefolthjVjBIgkMZg7A4MRgWiCbw X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="8487166" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 23 Mar 2012 11:36:02 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NBZx46018813; Fri, 23 Mar 2012 11:35:59 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 17:05:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2012 17:05:56 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC0180765E90B@XMB-BGL-41B.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04 Thread-Index: Ac0IQLFxdXv7hkk0StqnlJTywoFB2AAoKzEA References: <454A16E4DA86094EB66BB2C1DBBBC0180765E609@XMB-BGL-41B.cisco.com> From: "Tirumaleswar Reddy (tireddy)" To: "Varun Singh" X-OriginalArrivalTime: 23 Mar 2012 11:35:58.0788 (UTC) FILETIME=[1E086040:01CD08E9] Cc: =?iso-8859-1?Q?J=F6rg_Ott?= , mmusic@ietf.org, "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04 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, 23 Mar 2012 11:36:17 -0000 > -----Original Message----- > From: Varun Singh [mailto:vsingh.ietf@gmail.com] > Sent: Thursday, March 22, 2012 9:00 PM > To: Tirumaleswar Reddy (tireddy) > Cc: J=F6rg Ott; mmusic@ietf.org; Dan Wing (dwing) > Subject: Re: [MMUSIC] Comments on draft-singh-avtcore-mprtp-04 >=20 > Hi Tiru, >=20 > Response inline. >=20 > On Wed, Mar 21, 2012 at 20:07, Tirumaleswar Reddy (tireddy) > wrote: > > Hi Varun - > > > > I have few comments related to the draft > > > > a)How is the situation handled when new network paths become > > available/disabled after the call is setup ? > > > > =A0=A0=A0 (3G enabled/disabled after the call is setup) > > >=20 > This is a local decision and MPRTP will use all available paths. > Either the application or ICE or something else needs to tell MPRTP > when an interface is available or unavailable. >=20 > At the media level (in the worst case) the sending endpoint will > discover a path is unavailable when a subflow reports 100% loss and it > will stop using it. Alternatively, if the endpoint discovers that one > of its interface is disabled it can advertise a new set of interfaces > (excluding the disabled interface from the set) to the other endpoint. Please refer RFC 6419 on the problems and behavior of various OS related = to MIF. For example Section 3.1.2 Connection Manager only selects the = best possible connection for the app based on the destination. The = default connection manager always prefers wired over wireless. >=20 > > b)There is little information related to IPv6. How SIP Client would > pick > > among list of ULA, link-local addresses, IPv6 global addresses with > > different precedence using ICE (refer to > > draft-keranen-mmusic-ice-adress-selection) ? > > >=20 > It is also a local decision. This should not be different from the > choices made by an endpoint using a single path. if an endpoint is > using ICE then it just inherits the ICE priorities. For example consider a IPv6 Mobile Node making SIP call in PMIPv6. This = node could be assigned both MAG and LMA prefixes. Let's say the = destination is reachable through both the prefixes. But the issue is = only LMA prefix would offer mobility if Mobile Node moves out of the = hotspot MAG prefix will not be available. In a different region he may = get a different MAG prefix. But if we consider a branch with multiple = ISP - such complexities may not arise. The problem in this case would be = the SIP client being provided the list of host candidate addresses with = the preference provided by RFC 3484 (and using ICE). You will need = support from OS to achieve this. >=20 >=20 > For both these queries, do you have something specific in mind? >=20 > Cheers, > Varun >=20 >=20 > -- > http://www.netlab.tkk.fi/~varun/ From abegen@cisco.com Sat Mar 24 20:19:51 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 83FA621E8011 for ; Sat, 24 Mar 2012 20:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 1rdIFZgVmMIh for ; Sat, 24 Mar 2012 20:19:50 -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 5ADA021F84EC for ; Sat, 24 Mar 2012 20:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=992; q=dns/txt; s=iport; t=1332645590; x=1333855190; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=njxuPvLGvtL34EnHmxpa/nEtWOho1w5GsyxFL+xG4RA=; b=fLK7f1WryYMY7par6LZKKExscO1kNY5Cz3mzQlBmErGuELra0b5XIFRG qfLpn5dULpf39v/rlFB0B5bzDM3e+4ZrWMbJWxbhSKq3b08lWROu/NMvG wOjhFvZ0E36JzI8S5ahCChZ5KgqfuRmcl8hrIhqlp9ed9987HQYzNs2HB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGOObk+tJV2c/2dsb2JhbABDuCOBB4ILAQQSAWYSASpWJgEEAQ0NARmHaAuZWp4NkEVjBIgknAGBaIJn X-IronPort-AV: E=Sophos;i="4.73,644,1325462400"; d="scan'208";a="69180221" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 25 Mar 2012 03:19:49 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2P3JnZ5003724; Sun, 25 Mar 2012 03:19:49 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Sat, 24 Mar 2012 20:19:49 -0700 From: "Ali C. Begen (abegen)" To: "mmusic@ietf.org" , "draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org" Thread-Topic: SDP Directorate review of draft-ietf-avtcore-feedback-supression-rtp-15 Thread-Index: Ac0KIbIbwNCjlHeeQbWshAF885HnwA== Date: Sun, 25 Mar 2012 03:19:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18794.001 x-tm-as-result: No--29.455300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] SDP Directorate review of draft-ietf-avtcore-feedback-supression-rtp-15 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: Sun, 25 Mar 2012 03:19:51 -0000 I am the assigned SDP directorate reviewer for draft-ietf-avtcore-feedback-= supression-rtp-15. For background on 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: The draft does not contain any technical errors, there are just a few edito= rial issues. New SDP information elements: The draft defines new SDP elements in Section 8. Two values are added to th= e '"ack" and "nack" Attribute Values' sub-registry of the SDP registry. Two= FMT values are also registered in the RTPFB and PSFB payload type registir= ies.=20 Technical: No technical issues. Editorial: 1) Please hyphen "third-party" at all times 2) Section 8, the long name for the "pslei" should be "Payload Specific Thi= rd-Party Loss Early Indication". 3) Section 2.1, PSLEI should be Payload Specific Third-Party Loss Early I= ndication From bill.wu@huawei.com Sun Mar 25 02:07: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 839C021F8568 for ; Sun, 25 Mar 2012 02:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.033 X-Spam-Level: **** X-Spam-Status: No, score=4.033 tagged_above=-999 required=5 tests=[AWL=-2.755, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 1N-GonSzoF1u for ; Sun, 25 Mar 2012 02:07:20 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB0D421F8554 for ; Sun, 25 Mar 2012 02:07:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER22020; Sun, 25 Mar 2012 05:07:19 -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; Sun, 25 Mar 2012 02:04:11 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 25 Mar 2012 02:04:09 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.188]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Sun, 25 Mar 2012 17:04:05 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , "mmusic@ietf.org" , "draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org" Thread-Topic: SDP Directorate review of draft-ietf-avtcore-feedback-supression-rtp-15 Thread-Index: Ac0KIbIbwNCjlHeeQbWshAF885HnwAAQ88CA Date: Sun, 25 Mar 2012 09:04:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.90] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Sun, 25 Mar 2012 11:33:58 -0700 Subject: [MMUSIC] =?gb2312?b?tPC4tDogU0RQIERpcmVjdG9yYXRlIHJldmlldyBvZiBk?= =?gb2312?b?cmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMTU=?= 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: Sun, 25 Mar 2012 09:07:20 -0000 TWFueSB0aGFua3MsIEkgd2lsbCBmaXggdGhlc2UgdGhyZWUgbml0cyBpbiB0aGUgdXBkYXRlIGxh dGVyIGFmdGVyIEkgZ2V0IHRoZSBkaXJlY3Rpb24gZnJvbSBvdXIgQUQuDQoNClJlZ2FyZHMhDQot UWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pIFtt YWlsdG86YWJlZ2VuQGNpc2NvLmNvbV0gDQq3osvNyrG85DogMjAxMsTqM9TCMjXI1SAxMToyMA0K ytW8/sjLOiBtbXVzaWNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBy ZXNzaW9uLXJ0cEB0b29scy5pZXRmLm9yZw0Ks63LzTogUm9iZXJ0IFNwYXJrcyAocmpzcGFya3NA bm9zdHJ1bS5jb20pDQrW98ziOiBTRFAgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYt YXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0xNQ0KDQpJIGFtIHRoZSBhc3NpZ25lZCBT RFAgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1z dXByZXNzaW9uLXJ0cC0xNS4gRm9yIGJhY2tncm91bmQgb24gU0RQIGRpcmVjdG9yYXRlLCBwbGVh c2Ugc2VlIHRoZSBGQVEgYXQgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9z ZHAuaHRtbD4uDQoNClBsZWFzZSB3YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50 IHNoZXBoZXJkIG9yIEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0 Lg0KDQpTdW1tYXJ5Og0KVGhlIGRyYWZ0IGRvZXMgbm90IGNvbnRhaW4gYW55IHRlY2huaWNhbCBl cnJvcnMsIHRoZXJlIGFyZSBqdXN0IGEgZmV3IGVkaXRvcmlhbCBpc3N1ZXMuDQoNCk5ldyBTRFAg aW5mb3JtYXRpb24gZWxlbWVudHM6DQpUaGUgZHJhZnQgZGVmaW5lcyBuZXcgU0RQIGVsZW1lbnRz IGluIFNlY3Rpb24gOC4gVHdvIHZhbHVlcyBhcmUgYWRkZWQgdG8gdGhlICciYWNrIiBhbmQgIm5h Y2siIEF0dHJpYnV0ZSBWYWx1ZXMnIHN1Yi1yZWdpc3RyeSBvZiB0aGUgU0RQIHJlZ2lzdHJ5LiBU d28gRk1UIHZhbHVlcyBhcmUgYWxzbyByZWdpc3RlcmVkIGluIHRoZSBSVFBGQiBhbmQgUFNGQiBw YXlsb2FkIHR5cGUgcmVnaXN0aXJpZXMuIA0KDQpUZWNobmljYWw6DQpObyB0ZWNobmljYWwgaXNz dWVzLg0KDQpFZGl0b3JpYWw6DQoxKSBQbGVhc2UgaHlwaGVuICJ0aGlyZC1wYXJ0eSIgYXQgYWxs IHRpbWVzDQoyKSBTZWN0aW9uIDgsIHRoZSBsb25nIG5hbWUgZm9yIHRoZSAicHNsZWkiIHNob3Vs ZCBiZSAiUGF5bG9hZCBTcGVjaWZpYyBUaGlyZC1QYXJ0eSBMb3NzIEVhcmx5IEluZGljYXRpb24i Lg0KMykgU2VjdGlvbiAyLjEsICAgUFNMRUkgc2hvdWxkIGJlIFBheWxvYWQgU3BlY2lmaWMgVGhp cmQtUGFydHkgTG9zcyBFYXJseSBJbmRpY2F0aW9uDQo= From internet-drafts@ietf.org Sun Mar 25 17:39:08 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 1586621E8056; Sun, 25 Mar 2012 17:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.573 X-Spam-Level: X-Spam-Status: No, score=-101.573 tagged_above=-999 required=5 tests=[AWL=1.026, 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 jT-Jm5Ej-ymm; Sun, 25 Mar 2012 17:39:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9058421F8453; Sun, 25 Mar 2012 17:39:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326003907.13022.96409.idtracker@ietfa.amsl.com> Date: Sun, 25 Mar 2012 17:39:07 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-18.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: Mon, 26 Mar 2012 00:39:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) a= nd Real-time Transport Protocol (RTP) for Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Arjun Roychowdhury Chelliah SivaChelvan Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-18.txt Pages : 34 Date : 2012-03-25 The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-18.txt From HKaplan@acmepacket.com Sun Mar 25 17:55: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 DD46021E8051 for ; Sun, 25 Mar 2012 17:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.102, 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 BVTOkJ0MzyRX for ; Sun, 25 Mar 2012 17:55:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3629B21E8028 for ; Sun, 25 Mar 2012 17:55:58 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 20:55:54 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 20:55:54 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: draft-ietf-mmusic-media-loopback-18 submitted Thread-Index: AQHNCusxTaWMmFXU60mAdcUfGAl1Aw== Date: Mon, 26 Mar 2012 00:55:53 +0000 Message-ID: <19E7C6E8-3577-4A7E-B9D4-ACCA5DEA9924@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_19E7C6E835774A7EB9D4ACCA5DEA9924acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: [MMUSIC] draft-ietf-mmusic-media-loopback-18 submitted 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, 26 Mar 2012 00:55:59 -0000 --_000_19E7C6E835774A7EB9D4ACCA5DEA9924acmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, As will be mentioned in the MMUSIC WG Monday morning, two weeks ago draft-i= etf-mmusic-media-loopback-17 was submitted to address the 34 editorial comm= ents from WGLC of draft-16. To address the 37 technical comments, draft-ietf-mmusic-media-loopback-18 w= as just submitted. The new draft is available here: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18 To see a diff view of this new draft-18 to draft-16 (the one before either = the editorial or technical comment resolution), go here: http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-media-loopback-16.tx= t;url2=3Ddraft-ietf-mmusic-media-loopback-18.txt Diff views for draft-18 to draft-17, or draft-17 to draft-16, are available= on the draft tools page as normal. -hadriel --_000_19E7C6E835774A7EB9D4ACCA5DEA9924acmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Howdy,
As will be mentioned in the MMUSIC WG Monday morning, two weeks ago&nb= sp;draft-ietf-mmusic-media-loopback-17 was submitted to address the 34 edit= orial comments from WGLC of draft-16.

To address the 37 technical comments, draft-ietf-mmusic-media-loo= pback-18 was just submitted.

The new draft is available here:
http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-18

To see a diff view of this new draft-18 to draft-16 (the one before ei= ther the editorial or technical comment resolution), go here:

Diff views for draft-18 to draft-17, or draft-17 to draft-16, are avai= lable on the draft tools page as normal.

-hadriel

--_000_19E7C6E835774A7EB9D4ACCA5DEA9924acmepacketcom_-- From internet-drafts@ietf.org Sun Mar 25 23:33:16 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 0689C21E8083; Sun, 25 Mar 2012 23:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 3p6rv5uO86s4; Sun, 25 Mar 2012 23:33:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CA421F845D; Sun, 25 Mar 2012 23:33:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326063314.28926.25210.idtracker@ietfa.amsl.com> Date: Sun, 25 Mar 2012 23:33:14 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-00.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: Mon, 26 Mar 2012 06:33:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Miscellanoues Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-00.txt Pages : 19 Date : 2012-03-25 SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for each session or media). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-miscellaneous-cap= s-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-miscellaneous-caps= -00.txt From ietf@meetecho.com Mon Mar 26 00:10:11 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 9202421E8095 for ; Mon, 26 Mar 2012 00:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7OmHh-KdjNP9 for ; Mon, 26 Mar 2012 00:10:10 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out24.aruba.it [62.149.158.64]) by ietfa.amsl.com (Postfix) with SMTP id E00D021E808F for ; Mon, 26 Mar 2012 00:10:08 -0700 (PDT) Received: (qmail 29196 invoked by uid 89); 26 Mar 2012 07:10:04 -0000 Received: from unknown (HELO smtp6.aruba.it) (62.149.158.226) by smtplq03.aruba.it with SMTP; 26 Mar 2012 07:10:04 -0000 Received: (qmail 11203 invoked by uid 89); 26 Mar 2012 07:10:04 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp6.ad.aruba.it with SMTP; 26 Mar 2012 07:10:04 -0000 Message-ID: <4F70164D.5080701@meetecho.com> Date: Mon, 26 Mar 2012 09:10:05 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp6.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [MMUSIC] Meetecho support for MMUSIC WG meeting session 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, 26 Mar 2012 07:10:11 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Monday's MMUSIC WG meeting session. Access to the on-line session (including audio and video streams) is available: http://www.meetecho.com/ietf83/mmusic The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From HKaplan@acmepacket.com Mon Mar 26 00:37:34 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 9AB3921F84F7 for ; Mon, 26 Mar 2012 00:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, 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 NCZXHS4MykBy for ; Mon, 26 Mar 2012 00:37:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF5A221F8464 for ; Mon, 26 Mar 2012 00:37:32 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 26 Mar 2012 03:37:26 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 03:37:25 -0400 From: Hadriel Kaplan To: Gonzalo Salgueiro Thread-Topic: [MMUSIC] draft-ietf-mmusic-media-path-middleboxes-04 Thread-Index: AQHNCyNJ8RqjWvprA0GlZnDJcjd6oA== Date: Mon, 26 Mar 2012 07:37:24 +0000 Message-ID: <2719ACB7-F164-488D-A917-E50078ADD244@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_2719ACB7F164488DA917E50078ADD244acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-media-path-middleboxes-04 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, 26 Mar 2012 07:37:34 -0000 --_000_2719ACB7F164488DA917E50078ADD244acmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had some comments in here: http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html But not specific comments since I was confused what the purpose of the draf= t was - and I still am. :) So before providing point-by-point comments, can you explain what the purpo= se of publishing the draft as an Informational RFC would be? Would we reference this RFC in future WG RFCs? Would we expect implementors to read it for some reason? I'm just trying to figure out if we're publishing it because (1) work has a= lready been done and RFC numbers are free, or if it's because (2) we/others= need it or think we might need it for something in the future. If it's the former reason #1, I'm cool with that and sure publish it as is. If it's the latter reason #2, then I'll review it during WGLC but I think i= t has issues and is already out of date. -hadriel p.s. and I'm not trying to be mean or difficult - there are a lot of drafts= written for informational purposes for a limited period of time, that real= ly don't need to be published as RFCs forever - I submit a lot of I-Ds like= that for example. On Jan 30, 2012, at 8:22 AM, Gonzalo Salgueiro wrote: Folks: Pursuant to the discussions we had on the list regarding the complet= ion of the middlebox interactions draft [1], I have released -04 of the Mid= dlebox Interactions draft. It is available in the archives [2]. This version includes the comments of the reviewers assigned by the WG chai= rs. More specifically the major changes in this version are: 1) Added an additional preliminary recommendation (REC #5); 2) Updated references; 3) Variety of minor edits, nits, and grammatical issues; The diff between -03 and -04 is available at [3]. [1] http://www.ietf.org/mail-archive/web/mmusic/current/msg08558.html [2] http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-04 [3] http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middl= eboxes-04.txt Consensus from the reviewers is that this "draft looks to be in a good shap= e" and is "quite readable and useful". There was some discussion around the= possibility of changing the terminology from "SIP ALG" to something like "= SIP proxy" or "SIP user agent" or "SIP B2BUA". There were various differing= viewpoints and consensus was not reached. Thank you all for review comments and feedback. Regards, - Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_2719ACB7F164488DA917E50078ADD244acmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <78035C8AAE17DC4DA9E1F9351F64C28A@acmepacket.com> Content-Transfer-Encoding: quoted-printable

I had some comments in here:

But not specific comments since I was confused what the purpose of the= draft was - and I still am.  :)

So before providing point-by-point comments, can you explain what the = purpose of publishing the draft as an Informational RFC would be?
Would we reference this RFC in future WG RFCs?
Would we expect implementors to read it for some reason?

I'm just trying to figure out if we're publishing it because (1) work = has already been done and RFC numbers are free, or if it's because (2) we/o= thers need it or think we might need it for something in the future.
If it's the former reason #1, I'm cool with that and sure publish it a= s is.
If it's the latter reason #2, then I'll review it during WGLC but I th= ink it has issues and is already out of date.

-hadriel
p.s. and I'm not trying to be mean or difficult - there are a lot of d= rafts written for informational purposes for a limited period of time, that= really don't need to be published as RFCs forever - I submit a lot of I-Ds= like that for example.


On Jan 30, 2012, at 8:22 AM, Gonzalo Salgueiro wrote:

Folks: Pursuant to the discussions we had on the list regarding t= he completion of the middlebox interactions draft [1], I have released= -04 of the Middlebox Interactions draft. It is available in the = archives [2].

This version includes the comments of the reviewers assigned by the WG chai= rs.

More specifically the major changes in this version are:

 1) Added an additional preliminary recommendation (REC #5);
 2) Updated references;
 3) Variety of minor edits, nits, and grammatical issues;

The diff between -03 and -04 is available at [3].

[1] http://www.ietf.org/mail-archive/web/mmusic/current/msg08558.ht= ml
[2] http://tools.ietf.org/html/draft-ietf-mmusic-media-path-mi= ddleboxes-04
[3] http://tools.ietf.org/rfcdiff?url2=3Ddraft-i= etf-mmusic-media-path-middleboxes-04.txt

Consensus from the reviewers is that this "draft looks to be in a good= shape" and is "quite readable and useful". There was s= ome discussion around the possibility of changing the terminology from = ;"SIP ALG" to something like "SIP proxy" or "= SIP user agent" or "SIP B2BUA". There were various differing viewpoints and consens= us was not reached.

Thank you all for review comments and feedback.

Regards,

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

--_000_2719ACB7F164488DA917E50078ADD244acmepacketcom_-- From zhou.sujing@zte.com.cn Mon Mar 26 03:37: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 822BD21F8505 for ; Mon, 26 Mar 2012 03:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.914 X-Spam-Level: X-Spam-Status: No, score=-96.914 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 zQmMRUE-zvGy for ; Mon, 26 Mar 2012 03:37:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A110A21F84FE for ; Mon, 26 Mar 2012 03:37:57 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280978252052; Mon, 26 Mar 2012 18:02:30 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 42250.978252052; Mon, 26 Mar 2012 18:37:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2QAbdPc076729 for ; Mon, 26 Mar 2012 18:37:39 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <20120326081245.4711.62920.idtracker@ietfa.amsl.com> To: mmusic@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 26 Mar 2012 11:37:37 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-26 18:37:41, Serialize complete at 2012-03-26 18:37:41 Content-Type: multipart/alternative; boundary="=_alternative 003A5CE4C12579CD_=" X-MAIL: mse01.zte.com.cn q2QAbdPc076729 Subject: [MMUSIC] draft-zhou-mmusic-sdes-keymod-01 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, 26 Mar 2012 10:37:58 -0000 This is a multipart message in MIME format. --=_alternative 003A5CE4C12579CD_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksYWxsDQogIEkgaGF2ZSB1cGRhdGVkIG15IGRyYWZ0IGludG8gMDEgdmVyc2lvbiwgYW5kIHRo ZSBwcmVzZW50YXRpb24gSSBkaWQgaW4gDQp0aGUgbW9ybmluZyBpcyBhY3R1bGx5IGJhc2VkIG9u IDAxIHZlcnNpb24uDQpBbnkgb25lIGludGVyZXN0IGluIGFkb3B0aW5nIGl0IGFzIFdHIGl0ZW0/ IA0KDQoNClJlZ2FyZHN+fn4NCg0KLVN1amluZyBaaG91DQoNCklFVEYgSS1EIFN1Ym1pc3Npb24g VG9vbCA8aWRzdWJtaXNzaW9uQGlldGYub3JnPiDQtNPaIDIwMTItMDMtMjYgMTA6MTI6NDU6DQoN Cj4gRm9sbG93IHRoaXMgbGluayB0byBjb25maXJtIHlvdXIgQXV0by1Qb3N0IG9mDQo+IEktRCBk cmFmdC16aG91LW1tdXNpYy1zZGVzLWtleW1vZC0wMToNCj4gDQo+IEktRCBTdWJtaXNzaW9uIFRv b2wgVVJMOiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi4NCj4gDQpvcmcvc3VibWl0L3N0YXR1cy80 MDM1MC9jb25maXJtL2I3ZjQyY2IzNTg1ZWUyNmE0MjMzNGFkZGZiMDc0OTI3YTIwMTA4ZjcvDQo+ IA0KPiBSZW1lbWJlciB0aGF0IHlvdSBjYW4gY2FuY2VsIHRoZSBzdWJtaXNzaW9uIGZyb206DQo+ IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLg0KPiBvcmcvc3VibWl0L3N0YXR1cy80MDM1MC82OWE2 ZGNjZWU5NDNiM2NjZDdkODYzNzMwZjlkZDg0ZC8NCj4gDQoNCg== --=_alternative 003A5CE4C12579CD_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLGFsbDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEkgaGF2ZSB1cGRhdGVkIG15IGRy YWZ0IGludG8NCjAxIHZlcnNpb24sIGFuZCB0aGUgcHJlc2VudGF0aW9uIEkgZGlkIGluIHRoZSBt b3JuaW5nIGlzIGFjdHVsbHkgYmFzZWQNCm9uIDAxIHZlcnNpb24uPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Bbnkgb25lIGludGVyZXN0IGluIGFkb3B0aW5nIGl0 IGFzIFdHDQppdGVtPyA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgJmx0O2lk c3VibWlzc2lvbkBpZXRmLm9yZyZndDsNCtC009ogMjAxMi0wMy0yNiAxMDoxMjo0NTo8YnI+DQo8 YnI+DQomZ3Q7IEZvbGxvdyB0aGlzIGxpbmsgdG8gY29uZmlybSB5b3VyIEF1dG8tUG9zdCBvZjxi cj4NCiZndDsgSS1EIGRyYWZ0LXpob3UtbW11c2ljLXNkZXMta2V5bW9kLTAxOjxicj4NCiZndDsg PGJyPg0KJmd0OyBJLUQgU3VibWlzc2lvbiBUb29sIFVSTDogaHR0cDovL2RhdGF0cmFja2VyLmll dGYuPGJyPg0KJmd0OyBvcmcvc3VibWl0L3N0YXR1cy80MDM1MC9jb25maXJtL2I3ZjQyY2IzNTg1 ZWUyNmE0MjMzNGFkZGZiMDc0OTI3YTIwMTA4ZjcvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlbWVt YmVyIHRoYXQgeW91IGNhbiBjYW5jZWwgdGhlIHN1Ym1pc3Npb24gZnJvbTo8YnI+DQomZ3Q7IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLjxicj4NCiZndDsgb3JnL3N1Ym1pdC9zdGF0dXMvNDAzNTAv NjlhNmRjY2VlOTQzYjNjY2Q3ZDg2MzczMGY5ZGQ4NGQvPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+ PC90dD4NCg== --=_alternative 003A5CE4C12579CD_=-- From pkyzivat@alum.mit.edu Mon Mar 26 03:56:25 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 1BBF221F859A for ; Mon, 26 Mar 2012 03:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, 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 kUF4+NG2trAh for ; Mon, 26 Mar 2012 03:56:24 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3C21F8549 for ; Mon, 26 Mar 2012 03:56:23 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id qAuR1i0050EZKEL5CAwQfQ; Mon, 26 Mar 2012 10:56:24 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta01.westchester.pa.mail.comcast.net with comcast id qAwF1i00q5EhBnE3MAwJD7; Mon, 26 Mar 2012 10:56:22 +0000 Message-ID: <4F704B52.4010801@alum.mit.edu> Date: Mon, 26 Mar 2012 12:56:18 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 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, 26 Mar 2012 10:56:25 -0000 James, We've had other discussions on "immersive". This is other stuff I had that didn't seem worth bringing up in the meeting: In section 3, the way qualified-adjective is defined, the values for q-adjective ("admitted", ...) can be used not only with "aq" (e.g. aq:admitted), but can also be used with any other extension-mech that might later be defined. That is ok if it is your intent. Is it? I'm not at all clear what the distinction is between qualifed and unqualified adjectives. I suspect you could get the effect you want by discarding the distinction between qualified and unqualified adjectives, and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as adjectives. Thanks, Paul From pkyzivat@alum.mit.edu Mon Mar 26 03:59:46 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 5323521F860E for ; Mon, 26 Mar 2012 03:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] 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 TICFy8FHra6S for ; Mon, 26 Mar 2012 03:59:46 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id CB05721F85D4 for ; Mon, 26 Mar 2012 03:59:45 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id qAsq1i0011ap0As54Azm2G; Mon, 26 Mar 2012 10:59:46 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta22.westchester.pa.mail.comcast.net with comcast id qAzd1i00R5EhBnE3iAzfBr; Mon, 26 Mar 2012 10:59:44 +0000 Message-ID: <4F704C1C.5090205@alum.mit.edu> Date: Mon, 26 Mar 2012 12:59:40 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-bundle-negotiation-00 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, 26 Mar 2012 10:59:46 -0000 Christer, Here are a few relatively small things I noted while reviewing before the meeting: AFAICT, in section 6.2, there is no requirement that the value in a=bundle in the answer be the same as in the offer. There probably should be. Also, in last paragraph of this section, something is missing – something about the offer having been rejected. Section 6.3 also probably needs to specify using same bundle parameter as in the offer. Section 8.2: is it really necessary to include the same candidate info for each m-line? Isn’t once enough? This might cause trouble if the answerer doesn’t support bundle, but not otherwise. So it ought to be safe in the first answer and normally subsequent o/a in the dialog. It could be safe in initial o/a too of offerer knows answerer will support. And even it its wrong, the offerer could fix by sending another o/a. Thanks, Paul From paulej@packetizer.com Tue Mar 27 09: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 9257221E80CF for ; Tue, 27 Mar 2012 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 9rWK+c0kkmFC for ; Tue, 27 Mar 2012 09:55:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B854F21E80F2 for ; Tue, 27 Mar 2012 09:55:11 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2RGt9bP012332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 12:55:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332867310; bh=8W1cebJIZCOSKxzf3C+8EKFTqQoDOBE2E06v3m5qDNI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TKj+B1TeYC8z5a7TmaeU4rKVVy/LZ7Z6/RRgVO/9qoG8EUM6tiGMuxr2GL/WvdXKr WPskV78PDUtFFgerZ1sHvfZgMu+HHUIiZatnUcbOekmewr3XKQx0cox33YfAGkUmcv YSBcMrA72TWl4A078juaNmFTIPs18b+eFj8FNpZU= From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'IETF MMUSIC WG'" References: <4F704B52.4010801@alum.mit.edu> In-Reply-To: <4F704B52.4010801@alum.mit.edu> Date: Tue, 27 Mar 2012 12:55:12 -0400 Message-ID: <00d001cd0c3a$609311e0$21b935a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsPB4L4TgjBR7hmlR9VpxDqIUTLZY/9E8A Content-Language: en-us Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 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, 27 Mar 2012 16:55:22 -0000 Paul, The previous draft had it that way (somewhat). We had "admitted" and "non-admitted" at the end. However, it was suggested that we group related things together. So, for indicating "admitted" or "non-admitted" or "none", we defined the "admission qualifier" (aq). There may be other adjective groups that we might define in the future (or now if people can think of useful examples). As one perhaps less useful example might be to indicate the resolution of a video. So, there might be a "res:1080|720|360" or "res:high|medium|low". One benefit in defining groups of adjectives is that if you are looking for the admission qualifier value, for example, then you can find the "aq:" adjective. You may not know what "" means, but at least you can identify that it is the admission qualifier value. So, it's there just to provide a grouping construct and to allow for identification of the group, even if the value in the group is not recognized. Paul > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Monday, March 26, 2012 6:56 AM > To: IETF MMUSIC WG > Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 > > James, > > We've had other discussions on "immersive". This is other stuff I had that > didn't seem worth bringing up in the meeting: > > In section 3, the way qualified-adjective is defined, the values for q- > adjective ("admitted", ...) can be used not only with "aq" (e.g. > aq:admitted), but can also be used with any other extension-mech that > might later be defined. > > That is ok if it is your intent. Is it? > > I'm not at all clear what the distinction is between qualifed and > unqualified adjectives. I suspect you could get the effect you want by > discarding the distinction between qualified and unqualified adjectives, > and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as > adjectives. > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Mar 27 10:13: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 F035821F8821 for ; Tue, 27 Mar 2012 10:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 L7+5IaBV55bz for ; Tue, 27 Mar 2012 10:13:44 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id CFC6121F881D for ; Tue, 27 Mar 2012 10:13:43 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta01.westchester.pa.mail.comcast.net with comcast id qgs41i0010cZkys51hDkUd; Tue, 27 Mar 2012 17:13:44 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta10.westchester.pa.mail.comcast.net with comcast id qhDX1i01x5EhBnE3WhDauQ; Tue, 27 Mar 2012 17:13:41 +0000 Message-ID: <4F71F53A.9030606@alum.mit.edu> Date: Tue, 27 Mar 2012 19:13:30 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4F704B52.4010801@alum.mit.edu> <00d001cd0c3a$609311e0$21b935a0$@packetizer.com> In-Reply-To: <00d001cd0c3a$609311e0$21b935a0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'IETF MMUSIC WG' Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 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, 27 Mar 2012 17:13:45 -0000 On 3/27/12 6:55 PM, Paul E. Jones wrote: > Paul, > > The previous draft had it that way (somewhat). We had "admitted" and > "non-admitted" at the end. However, it was suggested that we group related > things together. So, for indicating "admitted" or "non-admitted" or "none", > we defined the "admission qualifier" (aq). There may be other adjective > groups that we might define in the future (or now if people can think of > useful examples). > > As one perhaps less useful example might be to indicate the resolution of a > video. So, there might be a "res:1080|720|360" or "res:high|medium|low". > > One benefit in defining groups of adjectives is that if you are looking for > the admission qualifier value, for example, then you can find the > "aq:" adjective. You may not know what"" means, but at > least you can identify that it is the admission qualifier value. > > So, it's there just to provide a grouping construct and to allow for > identification of the group, even if the value in the group is not > recognized. I see the value in the grouping. I just don't see the value in introducing formal syntax for that grouping. I think it would make the parser simpler to achieve the sort of grouping you are talking about through an informal naming convention on the attributes. You could have exactly the same names you do now if you simply permitted ":" as a valid character anywhere in attribute names. Or, you can simply settle for some other separator character in the convention, like "-", as in "aq-accepted". The special syntax for qualified attributes leaves me expecting more - some special significance to qualifiers in general and the aq qualifier. Thanks, Paul > Paul > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Monday, March 26, 2012 6:56 AM >> To: IETF MMUSIC WG >> Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 >> >> James, >> >> We've had other discussions on "immersive". This is other stuff I had that >> didn't seem worth bringing up in the meeting: >> >> In section 3, the way qualified-adjective is defined, the values for q- >> adjective ("admitted", ...) can be used not only with "aq" (e.g. >> aq:admitted), but can also be used with any other extension-mech that >> might later be defined. >> >> That is ok if it is your intent. Is it? >> >> I'm not at all clear what the distinction is between qualifed and >> unqualified adjectives. I suspect you could get the effect you want by >> discarding the distinction between qualified and unqualified adjectives, >> and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as >> adjectives. >> >> Thanks, >> Paul >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From jmpolk@cisco.com Wed Mar 28 00:55:34 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 90FEE21F891E for ; Wed, 28 Mar 2012 00:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.035 X-Spam-Level: X-Spam-Status: No, score=-110.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Yo2QchTmHVh9 for ; Wed, 28 Mar 2012 00:55:33 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5B21F891D for ; Wed, 28 Mar 2012 00:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1993; q=dns/txt; s=iport; t=1332921333; x=1334130933; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=tGMESSNtd/v0NvuiXp6Fep4IsfFWBH46j9D7Fo1eDEY=; b=Ktmtlz462ZS8BO5VVk+rB8ntNYDEAJnCZauBD/Mc6bkBz9nOvktlItm6 uVIqJLqt+jgb472+fXjeSsl5yWJWUqM+q2lw9/pC+4gPxcPU4F8oPHerL B0fpmoH5E2OiMJtWR/PqNo6VsEOHoYOX7Ies++2tk8pLXFk6glz7jkpur c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANjCck+rRDoI/2dsb2JhbABFDrhdgQeCCQEBAQQBAQEPASUCNBsHBA4KHhAZDjAGARIih2cMmyifDgSQHGMEiFibToFogjBV X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="34875439" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 28 Mar 2012 07:55:32 +0000 Received: from jmpolk-wxp01.cisco.com (sjc-vpn5-1091.cisco.com [10.21.92.67]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2S7tUHB017808; Wed, 28 Mar 2012 07:55:31 GMT Message-Id: <201203280755.q2S7tUHB017808@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Mar 2012 02:55:29 -0500 To: Paul Kyzivat , IETF MMUSIC WG From: "James M. Polk" In-Reply-To: <4F704B52.4010801@alum.mit.edu> References: <4F704B52.4010801@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 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, 28 Mar 2012 07:55:34 -0000 Paul in-line At 05:56 AM 3/26/2012, Paul Kyzivat wrote: >James, > >We've had other discussions on "immersive". Yes we have, however, that indication we still have use for, so it'll need to be replaced with something unique that can mean what we intent here for "immersive". Any suggestions? >This is other stuff I had that didn't seem worth bringing up in the meeting: > >In section 3, the way qualified-adjective is defined, the values for >q-adjective ("admitted", ...) can be used not only with "aq" (e.g. >aq:admitted), but can also be used with any other extension-mech >that might later be defined. > >That is ok if it is your intent. Is it? The "qualified" aspect of the adjectives came from the idea of reducing the cac-class component back into being an adjective, which is exactly what it is. That's #1. #2 was that we believe we have use for a admission adjective maining "none", defined that CAC wasn't attempted for this traffic flow. Now, just having a generic adjective "none" begs the question "none what"? If we qualified what the "none" applied to (i.e., about admission specifically), the "none" is given context that can be used. There may be a different reasons to have some other traffic class have an adjective of "none", but a different context. That's where this all came from. Now, that said, what you have below is interesting (i.e., "...defining "aq-admitted", "aq-non-admitted", and "aq-none" as adjectives...") James >I'm not at all clear what the distinction is between qualifed and >unqualified adjectives. I suspect you could get the effect you want >by discarding the distinction between qualified and unqualified >adjectives, and simply defining "aq-admitted", "aq-non-admitted", >and "aq-none" as adjectives. > > Thanks, > Paul >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From jmpolk@cisco.com Wed Mar 28 00:58:56 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 168E121F894F for ; Wed, 28 Mar 2012 00:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.046 X-Spam-Level: X-Spam-Status: No, score=-110.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 rg3Oq9IZ454R for ; Wed, 28 Mar 2012 00:58:55 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1761321F893C for ; Wed, 28 Mar 2012 00:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2779; q=dns/txt; s=iport; t=1332921533; x=1334131133; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=zcESHQEYpbQrXJPvFquzPKxcvzcChjeO1E+Cz8ndM5k=; b=IOBlhhcQ83gWjIAR7RGoVX6rOrtkgu07Xuo9urpfKAterKcR7uBnmqia LveEU4e6vp9VW6IS1u1GKlcsYzNGnnE0Ld5Ko9vp459bMgDnUbXw6m5dp UHS8qhehspqM2VzUrqY1SB6ebcAvot3AwDxm/HqdciLWi7r0s8CZcUaKP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHjEck+rRDoH/2dsb2JhbAA7Cg64X4EHggkBAQEEAQEBDwElAjQCFQQHBBEEAQEBHgkHGQ4fCQgGARIih2cMmyefDgSKboYkBIhYm06BaIIwVQ X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="35413660" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 28 Mar 2012 07:58:53 +0000 Received: from jmpolk-wxp01.cisco.com (sjc-vpn5-1091.cisco.com [10.21.92.67]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2S7wo7X018457; Wed, 28 Mar 2012 07:58:51 GMT Message-Id: <201203280758.q2S7wo7X018457@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Mar 2012 02:58:49 -0500 To: "Paul E. Jones" , "'Paul Kyzivat'" , "'IETF MMUSIC WG'" From: "James M. Polk" In-Reply-To: <00d001cd0c3a$609311e0$21b935a0$@packetizer.com> References: <4F704B52.4010801@alum.mit.edu> <00d001cd0c3a$609311e0$21b935a0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 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, 28 Mar 2012 07:58:56 -0000 At 11:55 AM 3/27/2012, Paul E. Jones wrote: >Paul, > >The previous draft had it that way (somewhat). We had "admitted" and >"non-admitted" at the end. However, it was suggested that we group related >things together. So, for indicating "admitted" or "non-admitted" or "none", >we defined the "admission qualifier" (aq). There may be other adjective >groups that we might define in the future (or now if people can think of >useful examples). > >As one perhaps less useful example might be to indicate the resolution of a >video. So, there might be a "res:1080|720|360" or "res:high|medium|low". to further beat this horse (made along the previous note) is this, just having a adjective as "low" doesn't mean much to anyone, and is limiting future traffic classes to not being able to use "low" with a different meaning. "res:low" (or your suggestion of a "res-low") gives context to the adjective. James >One benefit in defining groups of adjectives is that if you are looking for >the admission qualifier value, for example, then you can find the >"aq:" adjective. You may not know what "" means, but at >least you can identify that it is the admission qualifier value. > >So, it's there just to provide a grouping construct and to allow for >identification of the group, even if the value in the group is not >recognized. > >Paul > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: Monday, March 26, 2012 6:56 AM > > To: IETF MMUSIC WG > > Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 > > > > James, > > > > We've had other discussions on "immersive". This is other stuff I had that > > didn't seem worth bringing up in the meeting: > > > > In section 3, the way qualified-adjective is defined, the values for q- > > adjective ("admitted", ...) can be used not only with "aq" (e.g. > > aq:admitted), but can also be used with any other extension-mech that > > might later be defined. > > > > That is ok if it is your intent. Is it? > > > > I'm not at all clear what the distinction is between qualifed and > > unqualified adjectives. I suspect you could get the effect you want by > > discarding the distinction between qualified and unqualified adjectives, > > and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as > > adjectives. > > > > Thanks, > > Paul > > _______________________________________________ > > 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 jmpolk@cisco.com Wed Mar 28 01:00:46 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 EFB3C21F8962 for ; Wed, 28 Mar 2012 01:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.057 X-Spam-Level: X-Spam-Status: No, score=-110.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fI8g4ow5m2wn for ; Wed, 28 Mar 2012 01:00:43 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 57DE421F892C for ; Wed, 28 Mar 2012 01:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3284; q=dns/txt; s=iport; t=1332921643; x=1334131243; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=97NUDqpZeWVkB9Mahn0sa5HjFVM6JSSZRdGshSKRUzE=; b=fPkXVwSm7AOctlkkgsnUKwHJ/SzbqP2X5leVVkoLHxYF05hEHUi8+mBJ 3r+cdsKw//EY++bvzVRcNzYq/IMmCniiyX89HA/G9rCTvatByyrx02yrV c5J16neX7TTYoTZaqq8XHzovyB2ALV4bK/O+D/DuoIvHQE8R9SAj7NdmC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACDEck+rRDoG/2dsb2JhbAA5Cg64aIEHggkBAQEDAQEBAQ8BJQI0AgkFBwQHBA4DBAEBAR4JBxkOHwkIBgESIodjBAyfApcoBIpuhiQEiFibToFogjBV X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="34875981" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 28 Mar 2012 08:00:43 +0000 Received: from jmpolk-wxp01.cisco.com (sjc-vpn5-1091.cisco.com [10.21.92.67]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2S80fY9019634; Wed, 28 Mar 2012 08:00:42 GMT Message-Id: <201203280800.q2S80fY9019634@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Mar 2012 03:00:39 -0500 To: Paul Kyzivat , "Paul E. Jones" From: "James M. Polk" In-Reply-To: <4F71F53A.9030606@alum.mit.edu> References: <4F704B52.4010801@alum.mit.edu> <00d001cd0c3a$609311e0$21b935a0$@packetizer.com> <4F71F53A.9030606@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: 'IETF MMUSIC WG' Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 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, 28 Mar 2012 08:00:46 -0000 At 12:13 PM 3/27/2012, Paul Kyzivat wrote: >On 3/27/12 6:55 PM, Paul E. Jones wrote: >>Paul, >> >>The previous draft had it that way (somewhat). We had "admitted" and >>"non-admitted" at the end. However, it was suggested that we group related >>things together. So, for indicating "admitted" or "non-admitted" or "none", >>we defined the "admission qualifier" (aq). There may be other adjective >>groups that we might define in the future (or now if people can think of >>useful examples). >> >>As one perhaps less useful example might be to indicate the resolution of a >>video. So, there might be a "res:1080|720|360" or "res:high|medium|low". >> >>One benefit in defining groups of adjectives is that if you are looking for >>the admission qualifier value, for example, then you can find the >>"aq:" adjective. You may not know what"" means, but at >>least you can identify that it is the admission qualifier value. >> >>So, it's there just to provide a grouping construct and to allow for >>identification of the group, even if the value in the group is not >>recognized. > >I see the value in the grouping. I just don't see the value in >introducing formal syntax for that grouping. I think it would make >the parser simpler to achieve the sort of grouping you are talking >about through an informal naming convention on the attributes. You >could have exactly the same names you do now if you simply permitted >":" as a valid character anywhere in attribute names. Or, you can >simply settle for some other separator character in the convention, >like "-", as in "aq-accepted". > >The special syntax for qualified attributes leaves me expecting more >- some special significance to qualifiers in general and the aq qualifier. Like I said, this is a good suggestion you have here. James > Thanks, > Paul > >>Paul >> >>>-----Original Message----- >>>From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >>>Of Paul Kyzivat >>>Sent: Monday, March 26, 2012 6:56 AM >>>To: IETF MMUSIC WG >>>Subject: Re: [MMUSIC] draft-ietf-mmusic-traffic-class-for-sdp-01 >>> >>>James, >>> >>>We've had other discussions on "immersive". This is other stuff I had that >>>didn't seem worth bringing up in the meeting: >>> >>>In section 3, the way qualified-adjective is defined, the values for q- >>>adjective ("admitted", ...) can be used not only with "aq" (e.g. >>>aq:admitted), but can also be used with any other extension-mech that >>>might later be defined. >>> >>>That is ok if it is your intent. Is it? >>> >>>I'm not at all clear what the distinction is between qualifed and >>>unqualified adjectives. I suspect you could get the effect you want by >>>discarding the distinction between qualified and unqualified adjectives, >>>and simply defining "aq-admitted", "aq-non-admitted", and "aq-none" as >>>adjectives. >>> >>> Thanks, >>> Paul >>>_______________________________________________ >>>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