From pkyzivat@alum.mit.edu Thu Nov 1 14:16: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 8E26221F96F1 for ; Thu, 1 Nov 2012 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LngVNSidWsY7 for ; Thu, 1 Nov 2012 14:16:44 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8629721F9737 for ; Thu, 1 Nov 2012 14:16:43 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id JFb31k0060cZkys54MGnd8; Thu, 01 Nov 2012 21:16:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id JMGh1k0093ZTu2S3WMGhUu; Thu, 01 Nov 2012 21:16:41 +0000 Message-ID: <5092E6B7.8030401@alum.mit.edu> Date: Thu, 01 Nov 2012 17:16:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.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: [MMUSIC] Comments on draft-holmberg-mmusic-sdp-mmt-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: Thu, 01 Nov 2012 21:16:44 -0000 Here are a number of comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00, written as I prepare for the meeting. Section 5.2.2.1: I understand why an offerer would typically *want* to group one or more media descriptions for specific media types with an "anymedia" media description. But why MUST that be done? Why can't an offerer just offer the anymedia description if he isn't interested in backward compatibility? Section 6.1 It is unclear to me whether the value "anymedia" that is defined he is legitimate according to 4566. Section 8.2.1 of 4566 says: The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level media content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing top-level media content types, a Standards Track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [8]. The above suggests that the name needs to be a top level media content type, except for the "where possible". (And it's unclear what sort of exceptions "where possible" was intended to cover. The above uses the iana registry for "Media Types", which is shared with MIME usage. And from my quick scan it is not evident how to register a new top level type. So, I think it might actually require a revision to 4566 to make this change - breaking this case out and exempting it from the registration process. If so then I think it would be helpful to choose something more distinctive than "anymedia" to denote this quite different case. I suggest "*". (This is syntactically valid in the field according to the existing 4566 syntax, so it *ought* to be backward compatible.) Section 7 - mmtype attribute: Note that the use of payload types in m-lines is only for those with one of the RTP proto values. For UDP the media subtype is placed in the field of the m-line rather than in rtpmap. But with some rewording and explanation what you propose should work in most practical cases using the value directly. E.g. a=mmtype: PCMU/8000 audio a=mmtype: H261/90000 video The only time it wouldn't work is if you wanted to use a common subtype for two top level (e.g. both audio/foo and video/foo). That isn't likely. (I'm having a separate discussion about how the new SCTP... values might describe the assignment of SCTP streams for particular purposes. At some point we *might* end up having a way to specify use of RTP over an SCTP stream. That then might start to interact with this if we wanted to mix audio/video in one such stream. But maybe it is premature to deal with that.) Section 7.3.2: I think you need to say *something* about O/A. I guess what makes sense is that 7.3.1 applies independently to the offer and the answer. Section 10: *Something* needs to be done about "anymedia" or whatever replaces it. As currently written you would need to register a new media type value. With my suggestions you might avoid that but have to identify this draft as an extension to 4566. Unfortunately it is a bad time to revise 4566, since there is a 4566bis pending. Conceivably this whole thing could be added in to 4566bis, if the schedule works for that. Thanks, Paul From pkyzivat@alum.mit.edu Thu Nov 1 16:04: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 99D5B21F9503 for ; Thu, 1 Nov 2012 16:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF2Q0i4QMQMg for ; Thu, 1 Nov 2012 16:04:03 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B421F94F0 for ; Thu, 1 Nov 2012 16:04:02 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id JANw1k0041ZXKqc53P47Q6; Thu, 01 Nov 2012 23:04:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id JP5H1k00V3ZTu2S3hP5Hdq; Thu, 01 Nov 2012 23:05:17 +0000 Message-ID: <5092FFE0.6080304@alum.mit.edu> Date: Thu, 01 Nov 2012 19:04:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.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: [MMUSIC] Comments on draft-westerlund-mmusic-max-ssrc-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: Thu, 01 Nov 2012 23:04:04 -0000 I just reviewed this and have some comments: In Section 4.4 on o/a usage, *an* offerer must use this mechanism in the *initial* offer, while *the* answerer must use the mechanism in *each* subsequent *offer* and *answer*. IIUC this means the initial offerer on the initial o/a of a session might use the mechanism on the initial offer and never again, while the answerer of the initial o/a has to use it on every offer and answer. This is very asymmetric, and I suspect not what you intend. I *think* what you intend is that a supporter generating an initial offer in a session must use the mechanism. Then, if the answer doesn't use the mechanism the offerer should cease using it in subsequent o/a exchanges in the session. OTOH, if the initial answer uses the mechanism then it should be used by both ends for all subsequent o/a exchanges. Is that what you intended? That makes more sense. But this won't necessarily work right if there is a B2BUA that passes SDP through unchanged, and then at some point replaces a one session with another on one side of the B2BUA. (I.e. a 3pcc transfer.) If the other end of the new session differs in support for this draft from the replaced endpoint it won't be properly negotiated for the new session. This can be solved by the B2BUA editing the SDP, but that is a high burden for some B2BUAs. ISTM that there is no real harm in an end that supports this *always* including it in offers. A smaller point: Is there any reason not to also allow this as a session level attribute, applying to all the media descriptions that don't have their own? It could be convenient to just put the following at session level: a=max-send-ssrc:{*:1} a=max-recv-ssrc:{*:1} And finally, section 5 has an example with the following which must be wrong because it is missing a ":": a=max-send-ssrc:{* 1} Thanks, Paul From pkyzivat@alum.mit.edu Thu Nov 1 17:04: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 6321221F93E7 for ; Thu, 1 Nov 2012 17:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob9Ig5-r2z6n for ; Thu, 1 Nov 2012 17:04:35 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id B171021F93F1 for ; Thu, 1 Nov 2012 17:04:35 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id JQ1D1k0091HzFnQ54Q4gDP; Fri, 02 Nov 2012 00:04:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id JQ4f1k00A3ZTu2S3aQ4fVA; Fri, 02 Nov 2012 00:04:39 +0000 Message-ID: <50930E11.2090306@alum.mit.edu> Date: Thu, 01 Nov 2012 20:04:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.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: [MMUSIC] Comments on draft-ietf-mmusic-traffic-class-for-sdp-02 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 Nov 2012 00:04:36 -0000 I have some comments on this new version of the document. (Sorry!) Section 3: I know we have been through this many times, and its much better now. But I still see one issue: The ABNF says an adjective is a tcl-token, which allows "-" and alphanumerics. But then the text says that an adjective and be preceded by underscore ("_") to indicate that it is non-standard. This means you are *extending* the syntax in text beyond what the ABNF allows. IMO that is a very bad idea. Instead, I recommend altering the syntax to permit the underscore in adjectives in the way you intend it to be used. I would suggest some syntax for this but I don't know if you want to permit non-standard qualified adjectives. Also, as we have previously discussed, this way of using non-standard adjectives is quite analogous to the use "P-" or "X-" headers that has been found troublesome and generally banned. So I expect this might have trouble getting through IESG review. I thought we had discussed having the non-standard adjectives be registered using a first-come-first-served registration policy. ISTM that the portion of this section that discusses "aq" ought to be in its own section, and then referenced from the iana considerations section. Section 6.4: I don't find any explanation of how or if to register qualified adjectives. The section title says "Unqualified Adjective Registration", but the inital set of registered values includes "aq" (the qualifier part of qualified adjectives), and some values intended to be qualfied by "aq:" (such as "admitted"). This certainly implies to me that I can use each of these as an unqualified adjective. If the intent is to register such things then I would expect to see the full qualified adjectives listed for registration. E.g. "aq:admitted" Thanks, Paul From zhengyli@cisco.com Fri Nov 2 02:31: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 9DA8E21F949C for ; Fri, 2 Nov 2012 02:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4yLJLSYQYVN for ; Fri, 2 Nov 2012 02:31:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8921F9497 for ; Fri, 2 Nov 2012 02:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1543; q=dns/txt; s=iport; t=1351848688; x=1353058288; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+0ncZjWRSa/3QU5FaBDv0KvLsyEM9fPnLmpaLOQSlA4=; b=VVKhQ88dTYw7IYnT2vLT3UaLm0MvmqenM0YWkOiaYdX3jU3bXrpqMNeL nblNH6mSJTwdftZYEYwu9KZs3PeuwGErErH6a7dEbZ+V8mUcP5Tvl7cxw i7rqYIULXLLHP3GhdSGMrVOABlbFhivw+eEymuDet+Nkw/CrCKOmLrNA9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADWSk1CtJXG9/2dsb2JhbABEwzeBCIIeAQEBBAEBAQ8BJzQLDAYBCBEEAQELFAkuCxQJCAIEAQ0FCBqHaAubcqAIjAEahUBhA5cVjT2Ba4JvgWQ1 X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208";a="137854142" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 02 Nov 2012 09:31:27 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA29VRQj017693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Nov 2012 09:31:27 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 04:31:26 -0500 From: "Rockson Li (zhengyli)" To: "Muthu Arul Mozhi Perumal (mperumal)" , "Miguel A. Garcia" , mmusic Thread-Topic: [MMUSIC] WG Poll for consensus on WG item: latching draft Thread-Index: AQHNuNzUzJ0x999+ZEeB01vxNs+Dyg== Date: Fri, 2 Nov 2012 09:31:26 +0000 Message-ID: <6FFCD2B684E3EE4A96850F334095D677033EFB69@xmb-aln-x12.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.37.45] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--41.830700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:31:28 -0000 +1 On 10/18/12 8:09 PM, "Muthu Arul Mozhi Perumal (mperumal)" wrote: >I support it. I think it is quite informative. > >Muthu > >|-----Original Message----- >|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >Of Miguel A. Garcia >|Sent: Thursday, October 18, 2012 2:13 PM >|To: mmusic >|Cc: Flemming Andreasen (fandreas); Dan Wing (dwing) >|Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft >| >|At the last IETF meeting we had a presentation of the following draft: >| >|http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/ >| >|At that time, there was interest in adopting this document as WG item. We >|currently have a milestone to submit an informational document describing >|current practices in hosted NAT traversal, where this document fits. >| >|We would like to poll the working group to reconfirm the consensus on >|adopting the above mentioned draft as a working group item. >| >|If you support this work or have problems with the adoption of this >|document as WG item, please indicate it by replying to this e-mail within >|the next 5 days. >| >| Miguel and Flemming (co-chairs) >|-- >|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 harald@alvestrand.no Fri Nov 2 03:35:19 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 7B90421F9755 for ; Fri, 2 Nov 2012 03:35:19 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK+lwD08UzNl for ; Fri, 2 Nov 2012 03:35:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 89E1821F9765 for ; Fri, 2 Nov 2012 03:35:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A77F39E173 for ; Fri, 2 Nov 2012 11:35:15 +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 AJlM4JRF3VsX for ; Fri, 2 Nov 2012 11:35:14 +0100 (CET) Received: from [172.19.2.38] (unknown [91.217.168.220]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D8A1339E020 for ; Fri, 2 Nov 2012 11:35:13 +0100 (CET) Message-ID: <5093A1E0.2040905@alvestrand.no> Date: Fri, 02 Nov 2012 11:35:12 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20121022190754.7463.41798.idtracker@ietfa.amsl.com> <50878520.3020009@ericsson.com> In-Reply-To: <50878520.3020009@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-02.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 Nov 2012 10:35:19 -0000 On 10/24/2012 08:05 AM, Salvatore Loreto wrote: > Hi there, > > I have updated the draft trying to capture the result of the > discussion we had in this mailing list > writing down for SCTP a syntax similar to that used for RTP, > i.e. with "channle numbers" being used in a way analogous to payload > type numbers. FWIW, I think locking ourselves into this scheme is a Very Bad Idea. It will make it impossible to do many of the novel and interesting applications envisaged by WebRTC participants. If you want to have the ability to declare some scoping for SCTP usage, I think we should at least: - Extend the "a=streams" parameter to take a range, including "*" for "unlimited". a=streams:1-* would mean that one expects to use at least 1 stream, but no upper limit. a=streams:0-255 would mean that one may or may not use streams, but can't support more than 255. - Extend the "a=datachannel" syntax to take a default notation, and not limit other fields. a=datachannel:* RTCWeb would then mean that all datachannels not explicitly specified will use the RTCWeb protocol, and label and other options will be passed using the RTCWeb initialization protocol. I would like to just hardcode in my browser that it always sends m=application 1234 DTLS/SCTP 0 a=streams:0-* a=datachannel:* RTCWeb and really have SDP O/A stay out of the way of datachannel setup. I don't see the need to do more. But others may have other needs. > > The proposal is a very first attempt to see if this is the direction > we want to go > and it is obviously incomplete lacking the possibility to define > all the properties of the specific channel... > > feedback and comments are very welcome and necessary at this point > > best regards > Salvatore > > > > > On 10/22/12 10:07 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 : 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-02.txt >> Pages : 13 >> Date : 2012-10-22 >> >> Abstract: >> 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. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 harald@alvestrand.no Fri Nov 2 03:39: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 940CC21F93A7 for ; Fri, 2 Nov 2012 03:39:11 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdOcAgClYpbz for ; Fri, 2 Nov 2012 03:39:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4911621F9395 for ; Fri, 2 Nov 2012 03:39:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7432E39E173 for ; Fri, 2 Nov 2012 11:39:06 +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 iUekpUzIvQ7a for ; Fri, 2 Nov 2012 11:39:05 +0100 (CET) Received: from [172.19.2.38] (unknown [91.217.168.220]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9A6E039E020 for ; Fri, 2 Nov 2012 11:39:05 +0100 (CET) Message-ID: <5093A2C9.9040001@alvestrand.no> Date: Fri, 02 Nov 2012 11:39:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SCTP question: Where does it multiplex? 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 Nov 2012 10:39:11 -0000 As currently specified, the DTLS/SCTP protocol is carefully specified in such a way that it can ride on the same 5-tuple as an SRTP session. I'd like to keep that property when we SDP-negotiate it. The proposed syntax for DTLS/SCTP seems to be m= DTLS/SCTP I see two ways to define this as a multiplex: - Give the same port number as another m= line in the same SDP session - Give a meaningless port number, and use the a=group:BUNDLE (of whatever flavor) to give which port number it's actually multiplexed together with. The best way to do this may be obvious after the BUNDLE discussion, but in case there are other considerations .... are there thoughts? Harald From pkyzivat@alum.mit.edu Fri Nov 2 07:42: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 521B021F8AFB for ; Fri, 2 Nov 2012 07:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.716 X-Spam-Level: X-Spam-Status: No, score=0.716 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy63gHLBosiB for ; Fri, 2 Nov 2012 07:42:27 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 60C5621F8AF9 for ; Fri, 2 Nov 2012 07:42:27 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id JcTD1k00227AodY59eiXKF; Fri, 02 Nov 2012 14:42:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id Jeiz1k0053ZTu2S3feizC3; Fri, 02 Nov 2012 14:42:59 +0000 Message-ID: <5093DBD0.1070906@alum.mit.edu> Date: Fri, 02 Nov 2012 10:42:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20121022190754.7463.41798.idtracker@ietfa.amsl.com> <50878520.3020009@ericsson.com> <5093A1E0.2040905@alvestrand.no> In-Reply-To: <5093A1E0.2040905@alvestrand.no> 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-02.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 Nov 2012 14:42:28 -0000 Harald, (Speaking as co-chair of CLUE) In clue we have some goals that overlap with this work and with rtcweb. For one thing, we want to ensure that an webrtc client browser can act as a clue client. That means that the things that one must do to act as a clue client should be things that can be done from a browser using webrtc APIs and rtcweb protocols. But of course we also expect clue clients that are *not* webrtc clients, that are built on a native sip infrastructure. And so we require that all combinations of native and webrtc clients to interoperate. Also, in clue we need a single reliable bi-directional data channel for clue-specific signaling. We have mostly been considering the same SDP/DTLS/UDP transport that rtcweb is, partly because you guys have already done most of the work of defining it, and partly because we hope that means the APIs you define for it will mean that a browser based clue client will be able to implement that part of clue without needing any new clue-specific APIs. (Note that we only need *one* channel over the transport for this purpose. We don't care which one, but of course we do care that the two ends agree on what one it is.) (The following point is more speculative - we haven't really considered it formally in clue, though there have been a few passing discussions here and there. And so this part is personal, not as chair.) It is also the case that a clue client (either flavor) is likely to have need to simultaneously implement BFCP. This isn't really special to clue. When webrtc is used to hook a browser into any sip conference it may be necessary to use BFCP to access the advanced features of the conference. It would be *nice* if the clue protocol and the bfcp protocol could coexist over a single SCTP transport, each taking its own channel. That would also make it possible for a webrtc cient to implement bfcp using the webrtc datachannel APIs. (If bfcp is run over TCP or UDP then AFAIK a webrtc client would not be able to support it.) Of course there is currently no definition for bfcp over SCPT, and the work is still wrapping up to define it over UDP. So this is more wishful thinking on my part than anything else. *If* we had both a clue protocol binding and a bfcp binding to SCTP data channels, then there would be a need for a way to set up a session that contains an SCTP transport m-line, and the channels to be used for clue and/or bfcp. This would be needed both natively, and with webrtc/rtcweb. The stuff that Salvatore is proposing in the sctp-sdp draft will hopefully support that. (End of personal speculative part.) *** Note: I am *not* arguing that channels may only be used if they have been negotiated in SDP. I think we should be able to work it out so that some channels are reserved in SDP and others can be used based on implicit agreement and/or by dynamic run-time negotiation. Obviously some work is required to make those things coexist, but that isn't rocket science. What I want to avoid is the need for clue to support dynamic assignment of the channels it needs using some rtcweb-specific channel assignment protocol. Nor would I like to see some standardized static assignment of channels to protocols. (E.g. BFCP always uses channel 10 and CLUE always uses channel 11.) AFAICT, the alternative to the above is that a webrtc clue client would be forced to run "its end" of the clue and bfcp protocols in the web server rather than the browser, and then exchange that information with the browser via translation to html or to a separate rtcweb data channel. While this is *possible*, it seems less than ideal. Also, even ignoring rtcweb compatibility, when running native sip, I think we will want a way, in SDP, to negotiate one SCTP channel for the clue protocol and maybe another for bfcp (if that becomes supported). Thanks, Paul On 11/2/12 6:35 AM, Harald Alvestrand wrote: > On 10/24/2012 08:05 AM, Salvatore Loreto wrote: >> Hi there, >> >> I have updated the draft trying to capture the result of the >> discussion we had in this mailing list >> writing down for SCTP a syntax similar to that used for RTP, >> i.e. with "channle numbers" being used in a way analogous to payload >> type numbers. > FWIW, I think locking ourselves into this scheme is a Very Bad Idea. It > will make it impossible to do many of the novel and interesting > applications envisaged by WebRTC participants. > > If you want to have the ability to declare some scoping for SCTP usage, > I think we should at least: > > - Extend the "a=streams" parameter to take a range, including "*" for > "unlimited". > a=streams:1-* would mean that one expects to use at least 1 stream, but > no upper limit. > a=streams:0-255 would mean that one may or may not use streams, but > can't support more than 255. > > - Extend the "a=datachannel" syntax to take a default notation, and not > limit other fields. > a=datachannel:* RTCWeb would then mean that all datachannels not > explicitly specified will use the RTCWeb protocol, and label and other > options will be passed using the RTCWeb initialization protocol. > > I would like to just hardcode in my browser that it always sends > > m=application 1234 DTLS/SCTP 0 > a=streams:0-* > a=datachannel:* RTCWeb > > and really have SDP O/A stay out of the way of datachannel setup. I > don't see the need to do more. > But others may have other needs. > >> >> The proposal is a very first attempt to see if this is the direction >> we want to go >> and it is obviously incomplete lacking the possibility to define >> all the properties of the specific channel... >> >> feedback and comments are very welcome and necessary at this point >> >> best regards >> Salvatore >> >> >> >> >> On 10/22/12 10:07 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 : 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-02.txt >>> Pages : 13 >>> Date : 2012-10-22 >>> >>> Abstract: >>> 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. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-02 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 pkyzivat@alum.mit.edu Fri Nov 2 07:53: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 E648021F8A28 for ; Fri, 2 Nov 2012 07:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16F-mLjqAc2X for ; Fri, 2 Nov 2012 07:53:32 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 369BF21F8614 for ; Fri, 2 Nov 2012 07:53:32 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id JbKp1k0030Fqzac5Feu6w4; Fri, 02 Nov 2012 14:54:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id JetK1k00K3ZTu2S3UetKzb; Fri, 02 Nov 2012 14:53:19 +0000 Message-ID: <5093DE68.80508@alum.mit.edu> Date: Fri, 02 Nov 2012 10:53:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> In-Reply-To: <5093A2C9.9040001@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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 Nov 2012 14:53:33 -0000 On 11/2/12 6:39 AM, Harald Alvestrand wrote: > As currently specified, the DTLS/SCTP protocol is carefully specified in > such a way that it can ride on the same 5-tuple as an SRTP session. I'd > like to keep that property when we SDP-negotiate it. It is? How? Where is that specified? Thanks, Paul > The proposed syntax for DTLS/SCTP seems to be > > m= DTLS/SCTP mostly meaningless> > > I see two ways to define this as a multiplex: > > - Give the same port number as another m= line in the same SDP session > - Give a meaningless port number, and use the a=group:BUNDLE (of > whatever flavor) to give which port number it's actually multiplexed > together with. > > The best way to do this may be obvious after the BUNDLE discussion, but > in case there are other considerations .... are there thoughts? > > Harald > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From ben@nostrum.com Fri Nov 2 11:47: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 DA7271F0C82 for ; Fri, 2 Nov 2012 11:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPemtyfOS3-x for ; Fri, 2 Nov 2012 11:47:15 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 568921F0C7F for ; Fri, 2 Nov 2012 11:47:15 -0700 (PDT) Received: from [10.12.11.26] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA2IlDUJ053133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Nov 2012 13:47:14 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <508DA17F.8000701@alum.mit.edu> Date: Fri, 2 Nov 2012 13:47:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <80E6D387-9BA3-4D3F-9010-219E0C1F05CB@nostrum.com> References: <507FC10D.60500@ericsson.com> <508CFE3B.1050000@ericsson.com> <508DA17F.8000701@alum.mit.edu> To: mmusic@ietf.org X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:47:16 -0000 On Oct 28, 2012, at 4:19 PM, Paul Kyzivat wrote: > I support this - I think it is desirable to have this behavior = documented, since behavior similar to this is fairly widespread. = Hopefully having it documented will help prevent gratuitous variation. +1, with a bit of trepidation. But Paul has the right of it. From eckelcu@cisco.com Fri Nov 2 19:06: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 D24691F0C9C for ; Fri, 2 Nov 2012 19:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zl47eXOmdQW for ; Fri, 2 Nov 2012 19:06:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 91F161F0C9D for ; Fri, 2 Nov 2012 19:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1351908378; x=1353117978; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=48EA0aQwTsfCWCnEKoxPAorNU0FS5AWTvvBq0UcE7rg=; b=LBQIKkEJDJGIu2d4b1W2wltTEubtRIbc5+U+yfNEQ0+zwa1ciFH1yhtt /XkAF/otcsc6b/eSnNEAQVOBqr53rEHxTda1yET/ID7Wzeij771MmFmBK L9ObktvWEwWFu8eTWu/xhjriPWMfc5TCE5OPiEcNJ84U7LM2fndmY9qxD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANV6lFCtJXG+/2dsb2JhbABEDsMfgQiCHgEBAQMBAQEBDwEnNBAHBAIBCA4DBAEBCxQJBycLFAkIAgQBEggah2IGC5wEoAEEjACFWmEDpFKBa4IyPYIZ X-IronPort-AV: E=Sophos;i="4.80,702,1344211200"; d="scan'208";a="138363994" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 03 Nov 2012 02:06:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA326ICG029405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 02:06:18 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Fri, 2 Nov 2012 21:06:17 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , IETF MMUSIC WG Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-traffic-class-for-sdp-02 Thread-Index: AQHNuI2nFvIdbeLQH0SHrq50DRVfk5fXXRzw Date: Sat, 3 Nov 2012 02:06:16 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828101823@xmb-aln-x08.cisco.com> References: <50930E11.2090306@alum.mit.edu> In-Reply-To: <50930E11.2090306@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.89.67] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19332.000 x-tm-as-result: No--43.615700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-traffic-class-for-sdp-02 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 Nov 2012 02:06:22 -0000 Please see inline. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, November 01, 2012 8:05 PM > To: IETF MMUSIC WG > Subject: [MMUSIC] Comments on draft-ietf-mmusic-traffic-class-for-sdp-02 >=20 > I have some comments on this new version of the document. (Sorry!) >=20 > Section 3: >=20 > I know we have been through this many times, and its much better now. > But I still see one issue: >=20 > The ABNF says an adjective is a tcl-token, which allows "-" and > alphanumerics. But then the text says that an adjective and be preceded > by underscore ("_") to indicate that it is non-standard. This means you > are *extending* the syntax in text beyond what the ABNF allows. IMO that > is a very bad idea. >=20 > Instead, I recommend altering the syntax to permit the underscore in > adjectives in the way you intend it to be used. I would suggest some > syntax for this but I don't know if you want to permit non-standard > qualified adjectives. I'd like to recommend removing the text regarding the '_' and leaving the A= BNF as is. At IETF 84 I thought we agreed to address this by lowering the b= ar to register a new adjective. Cheers, Charles > Also, as we have previously discussed, this way of using non-standard > adjectives is quite analogous to the use "P-" or "X-" headers that has > been found troublesome and generally banned. So I expect this might have > trouble getting through IESG review. I thought we had discussed having > the non-standard adjectives be registered using a > first-come-first-served registration policy. >=20 > ISTM that the portion of this section that discusses "aq" ought to be in > its own section, and then referenced from the iana considerations section= . >=20 > Section 6.4: >=20 > I don't find any explanation of how or if to register qualified > adjectives. The section title says "Unqualified Adjective Registration", > but the inital set of registered values includes "aq" (the qualifier > part of qualified adjectives), and some values intended to be qualfied > by "aq:" (such as "admitted"). This certainly implies to me that I can > use each of these as an unqualified adjective. >=20 > If the intent is to register such things then I would expect to see the > full qualified adjectives listed for registration. E.g. "aq:admitted" >=20 > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Sat Nov 3 02:37: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 1942121F9C60 for ; Sat, 3 Nov 2012 02:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgJDwQuAyY+k for ; Sat, 3 Nov 2012 02:37:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ED29B21F9C5B for ; Sat, 3 Nov 2012 02:37:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f936d0000018b3-8f-5094e5db6ee4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 91.1B.06323.BD5E4905; Sat, 3 Nov 2012 10:37:31 +0100 (CET) Received: from [159.107.105.35] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sat, 3 Nov 2012 10:37:31 +0100 Message-ID: <5094E5D9.2080501@ericsson.com> Date: Sat, 3 Nov 2012 10:37:29 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <507FC10D.60500@ericsson.com> In-Reply-To: <507FC10D.60500@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje7tp1MCDF4+NrC4eO0hk8WanRNY LN5f0LWYe/k5u8XU5Y9ZHFg9Nk3ezOYx5fdGVo8lS34yefx/ExjAEsVlk5Kak1mWWqRvl8CV 8eP5V8aCa5wV3+d9Z2xgvMXexcjJISFgIvF//RpmCFtM4sK99WwgtpDASUaJqxd4uxi5gOzV jBLH728Da+AV0Jb4PfUNWBGLgIrEtuYpjCA2m4C5ROvGjUA1HByiAsESc67xQ5QLSpyc+YQF xBYRMJVom7WFBWQms8AaRon++UdYQeqFBdwknt7WgtirKfFx32yw8ZwCWhInHveCjWcWsJW4 MOc6C4QtL7H97RxmmPrJN5cyT2AUnIVk3SwkLbOQtCxgZF7FyJ6bmJmTXm6+iREYvge3/DbY wbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMX1Fj66ufREdNXq u+/3NV3bsVqu6322UOmCz20Jt3pEbUQy/3tNl5H7n/LeZr+/gdXPmW56U+5ff7fH5k5k4Ixt dnGHRB5euqHkOVP9ZcTVc4uLFEpmySjnL3a2WFn/tvls0Cv3iDs/mas35Wgxiip75d8IOTpx W975pIxSB0WzxQzf9v04fE6JpTgj0VCLuag4EQCFXGKlLQIAAA== Cc: Flemming Andreasen , mmusic , Dan Wing Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 09:37:35 -0000 This is to close the WG poll for consensus on the latching draft, as a WG item. We have received a few indications of this document being of interest for the working group to document this current practice. We have received no objections. With this, we can accept this document as WG item. Please authors, submit a new version as WG item (draft-ietf-mmusic-...) as early as possible. /Miguel On 18/10/2012 10:42, Miguel A. Garcia wrote: > At the last IETF meeting we had a presentation of the following draft: > > http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/ > > At that time, there was interest in adopting this document as WG item. We > currently have a milestone to submit an informational document describing > current practices in hosted NAT traversal, where this document fits. > > We would like to poll the working group to reconfirm the consensus on > adopting the above mentioned draft as a working group item. > > If you support this work or have problems with the adoption of this > document as WG item, please indicate it by replying to this e-mail within > the next 5 days. > > Miguel and Flemming (co-chairs) -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From eckelcu@cisco.com Sat Nov 3 23:23: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 2897021F84AF for ; Sat, 3 Nov 2012 23:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZYa8yUoadV5 for ; Sat, 3 Nov 2012 23:23:11 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A22921F8450 for ; Sat, 3 Nov 2012 23:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3013; q=dns/txt; s=iport; t=1352010191; x=1353219791; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=31BshKNTDayAIb+A/PdqRpUuc/RtxO7DnD8hggYjbKc=; b=Znej31yEevWcr58YKpNS48s6Vncsf6EXJDlu6WcnBo/I57CtcZwDZzlH WDiS2gku0Yfu8Pn7pLO+8VwJ42ICf/cGdqAIc2wS9CHmysFl4pUaF3q2u L5dtFJr6rXzPhzbs0MJTtU/saw1Gne3Nrov2jxw+uAOidunChgk26OLxm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPYIllCtJV2Y/2dsb2JhbABDwzmBCIIgAQQSASdRASoUQiYBBBsah2iYbIErnxCRXGEDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,707,1344211200"; d="scan'208";a="138565491" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2012 06:23:10 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA46NAcd026003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Nov 2012 06:23:10 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 01:23:10 -0500 From: "Charles Eckel (eckelcu)" To: "mmusic@ietf.org" Thread-Topic: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01 Thread-Index: Ac26VNtR0qWHHOkKTYGtONEogV5B3Q== Date: Sun, 4 Nov 2012 06:23:09 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--43.082000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-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: Sun, 04 Nov 2012 06:23:12 -0000 I have a few of comments on this draft, mostly in regard to the description= of the offer/answer procedures. 1) Section 6.2 end as follows: If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has reasons to believe that the rejection is due to the usage of a single port number value for multiple "m=3D" lines, the SDP Offerer SHOULD send a new SDP Offer, without a "BUNDLE" group, where a separate port number value is provide for each "m=3D" line of the SDP offer. I think this was meant to be as follows: If an SDP Offer, offering a "BUNDLE" group, is rejected, and the SDP Off= erer has reasons to believe that the rejection is due to the usage of a single port number value for multiple "m=3D" lines, the SDP Offerer SHOULD send a new SDP Offer, without a "BUNDLE" group, where a separate port number value is provide for each "m=3D" line of the SDP offer. Additionally, on what basis would the offerer have "reasons to believe the = rejection is due to the usage of a single port number value"? Perhaps if it= is the initial INVITE, this assumption is made, whereas if this is a re-IN= VITE following a previously successful negotiation, it is assumed to be som= e other case? This seems strange to me. I think it is better to remove the = "reasons to believe" qualifier. 2) Section 6.4.2, reads: The total proposed bandwidth is the sum of the proposed bandwidth for each "m=3D" line associated with a negotiated BUNDLE group. I'm afraid this is an overly simplistic approach. For example, a typical vi= deo call with content sharing includes one audio m-line and 2 video m-lines= . The bandwidth is declared at the session level as well as at the media le= vel, but the sum of the media levels is typically greater than that of the = session level. When content sharing occurs, it steals some bandwidth from t= he main video. In the case of BUNDLED m-lines, the proposed bandwidth shoul= d therefore be the lesser of the sum of the BUNDLE m-lines and the session = bandwidth. 3) Section 7.2 reads, o - A given SSRC SHOULD NOT transmit RTP packets using payload types that originates from different "m=3D" lines. NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC. If transmission of multiple media types are done with time overlap RTP and RTCP fails to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [ref to draft-ietf-avtext-multiple-clock-rates]. Why not replace the text in the bullet point with the text from the note, i= .e. o - A given SSRC SHOULD NOT be used for sending multiple media types . =20 NOTE: If transmission of multiple media types is done with time overlap, RTP and RTCP fail to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [ref to draft-ietf-avtext-multiple-clock-rates]. Cheers, Charles From jmpolk@cisco.com Sun Nov 4 00: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 75E2921F9752 for ; Sun, 4 Nov 2012 00:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dESfPmk1g82p for ; Sun, 4 Nov 2012 00:02:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CD04721F962B for ; Sun, 4 Nov 2012 00:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3050; q=dns/txt; s=iport; t=1352012547; x=1353222147; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=x5z/hu9tblgINd87idKfKvn0r6TKl9ZByL/wkvf29XI=; b=Tn3XBF40HQDDxqRLNrtWvClbhTek/lhmpZtzRGpnB0SgKbNYUciJD1eh edpKlci/FDr0dCP/HRvQiWiV2taxh361OhHnJ1wpqupfZJboHuKzdzaK+ g3oCuYkGkJmYGTN0S1w3lZcgyNFOHuu6qRmHZK4z0+7SShrGL0W2HrOnT M=; X-IronPort-AV: E=Sophos;i="4.80,709,1344211200"; d="scan'208";a="138547749" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 04 Nov 2012 07:02:27 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA472R8L026343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 07:02:27 GMT Message-Id: <201211040702.qA472R8L026343@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 01:02:26 -0500 To: "Charles Eckel (eckelcu)" , Paul Kyzivat , IETF MMUSIC WG From: James Polk In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828101823@xmb-aln-x08.cisco.c om> References: <50930E11.2090306@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828101823@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-traffic-class-for-sdp-02 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, 04 Nov 2012 07:02:28 -0000 At 09:06 PM 11/2/2012, Charles Eckel (eckelcu) wrote: >Please see inline. > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, November 01, 2012 8:05 PM > > To: IETF MMUSIC WG > > Subject: [MMUSIC] Comments on draft-ietf-mmusic-traffic-class-for-sdp-02 > > > > I have some comments on this new version of the document. (Sorry!) > > > > Section 3: > > > > I know we have been through this many times, and its much better now. > > But I still see one issue: > > > > The ABNF says an adjective is a tcl-token, which allows "-" and > > alphanumerics. But then the text says that an adjective and be preceded > > by underscore ("_") to indicate that it is non-standard. This means you > > are *extending* the syntax in text beyond what the ABNF allows. IMO that > > is a very bad idea. > > > > Instead, I recommend altering the syntax to permit the underscore in > > adjectives in the way you intend it to be used. I would suggest some > > syntax for this but I don't know if you want to permit non-standard > > qualified adjectives. > >I'd like to recommend removing the text regarding the '_' and >leaving the ABNF as is. At IETF 84 I thought we agreed to address >this by lowering the bar to register a new adjective. The -03 version at http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-03.txt has removed the '_' from all the text. >Cheers, >Charles > > > Also, as we have previously discussed, this way of using non-standard > > adjectives is quite analogous to the use "P-" or "X-" headers that has > > been found troublesome and generally banned. So I expect this might have > > trouble getting through IESG review. I thought we had discussed having > > the non-standard adjectives be registered using a > > first-come-first-served registration policy. > > > > ISTM that the portion of this section that discusses "aq" ought to be in > > its own section, and then referenced from the iana considerations section. > > > > Section 6.4: > > > > I don't find any explanation of how or if to register qualified > > adjectives. The section title says "Unqualified Adjective Registration", > > but the inital set of registered values includes "aq" (the qualifier > > part of qualified adjectives), and some values intended to be qualfied > > by "aq:" (such as "admitted"). This certainly implies to me that I can > > use each of these as an unqualified adjective. > > > > If the intent is to register such things then I would expect to see the > > full qualified adjectives listed for registration. E.g. "aq:admitted" > > > > 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 eckelcu@cisco.com Sun Nov 4 16:42: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 6555821F8805 for ; Sun, 4 Nov 2012 16:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9y7ydahP40H for ; Sun, 4 Nov 2012 16:42:55 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B7DFF21F8804 for ; Sun, 4 Nov 2012 16:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1384; q=dns/txt; s=iport; t=1352076175; x=1353285775; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=86XzW58ItmgiGCbgLMrwhlpwF4ezs0yx9EnW4ovuZlM=; b=RQKTb6f6+E/imEsYioxayoKLwQvGIO5hlEEanHkcYoILDH0rsKVhSo2V MPGM+GVLHiMFJnsre0JjzU8NsJ9blof3SMsc/i3rXet0ycFPka05e4YYt orTMhGinodyNTv9d9iUJCK4gwnCOeiqRWYMZHOxnG7ma07A6XXEVm5Zq6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACYKl1CtJV2b/2dsb2JhbABEwzuBCIIgAQQSASdRASoUQiYBBBsah2iYO4ErnwaRXGEDpFSBa4JvgVskGg X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138686624" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2012 00:42:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA50gtCV013170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Nov 2012 00:42:55 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 18:42:54 -0600 From: "Charles Eckel (eckelcu)" To: "mmusic@ietf.org" Thread-Topic: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 Thread-Index: Ac267nvcN3J2CS9eTQqf4SWGCPoMTw== Date: Mon, 5 Nov 2012 00:42:53 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.39] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--27.195500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-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, 05 Nov 2012 00:42:56 -0000 I read the draft, and I have some concerns it with. It seems that in genera= l one needs to duplicate much of the information from each individual media= description in the anymedia media description. I think I could live with t= hat; however, the bigger problem is in regard to figuring out what needs to= be specified in the anymedia media description. In the good cases, you mer= ely duplicate the SDP attributes from each individual media description in = the anymedia media description. In the bad case, you need to define new SDP= attributes. Here are some related comments in regard to specific section of the existin= g draft. 1) Section 5.2.2.2 seems to imply that accepting/rejecting an anymedia medi= a description is always an all of nothing matter. If it contains 2 audio li= nes and 2 video lines, I need to accept all of them or none of them. It tha= t is the intent, it seems pretty limiting to me. 2) Section 6.3 says directionality of anymedia applies to all media lines. = This seems limiting as well. I may want to temporarily stop a video stream = (i.e. make inactive or recvonly), but continue to have the audio be sendrec= v. 3) Section 6.4, I think you need to be able to specify the bandwidth for ea= ch media stream in the anymedia group, so new syntax will be needed to deal= with the bandwidth attribute. Cheers, Charles From christer.holmberg@ericsson.com Sun Nov 4 17:00: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 16CA021F8783 for ; Sun, 4 Nov 2012 17:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tW-OR0i6+A2 for ; Sun, 4 Nov 2012 17:00:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C917221F8774 for ; Sun, 4 Nov 2012 17:00:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-33-50970f9de10e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E2.13.11564.D9F07905; Mon, 5 Nov 2012 02:00:13 +0100 (CET) Received: from ESESSHC011.ericsson.se (153.88.183.51) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 5 Nov 2012 02:00:12 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 02:00:13 +0100 From: Christer Holmberg To: "'Charles Eckel (eckelcu)'" , "mmusic@ietf.org" Thread-Topic: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 Thread-Index: Ac267nvcN3J2CS9eTQqf4SWGCPoMTwAARGUg Date: Mon, 5 Nov 2012 01:00:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje5c/ukBBrcPqFtsmvWFzWLq8scs DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAldGz+4LbAVr+SoOnN7O3sC4lbuLkZNDQsBE 4lXHcWYIW0ziwr31bF2MXBxCAicZJWYcaIZydjBK7Dq+D6xKSGAxo8Ss3WJdjBwcbAIWEt3/ tEHCIgJREu/WfGUEsYUFXCUez5zACBF3k1h8aS8bhG0ksenUZiaQVhYBFYlbtwJBTF4Bb4mP 021ATCEBL4kpR+JATE6gaM9sdpA+RqDDvp9awwRiMwuIS9x6Mp8J4mABiSV7zkMdLyrx8vE/ VghbUeLjq32MEPU6Egt2f2KDsLUlli18DVbPKyAocXLmExaIl7QlWhZPYJ/AKD4LyYpZSNpn IWmfhaR9ASPLKkb23MTMnPRyw02MwJg5uOW37g7GU+dEDjFKc7AoifNyJe33FxJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDI96BxTX/9dFYNd4e+zedPs5jdWjvh6cvfyp4CCaaWu9Vvudk7 WS2ffz/D+4jimqZojv+q88P/pm8+uX7JpNCFG/w4rU5fqpd81STzZ1/+mS/Xn1WLG3fEOXIY GrxhOrp0dtDLnkv2Gu15x/OLd/YGnPQ+LhBwO0m77s6surcOFjw9YWtS56xWYinOSDTUYi4q TgQANIjdTGcCAAA= Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-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, 05 Nov 2012 01:00:16 -0000 Hi Charles, =20 >I read the draft, and I have some concerns it with. It seems that in gener= al one needs to duplicate much of the information from each individual medi= a description in the anymedia media description. I think I could live with = that;=20 >however, the bigger problem is in regard to figuring out what needs to be = specified in the anymedia media description. In the good cases, you merely = duplicate the SDP attributes from each individual media description in the = anymedia=20 >media description. In the bad case, you need to define new SDP attributes. >Here are some related comments in regard to specific section of the existi= ng draft. > >1) Section 5.2.2.2 seems to imply that accepting/rejecting an anymedia med= ia description is always an all of nothing matter. If it contains 2 audio l= ines and 2 video lines, I need to accept all of them or none of them. It th= at is the=20 >intent, it seems pretty limiting to me. That is not the intent. However, it is related to a more general (not specific to muliplexing) ques= tion that needs to be clarified - how individual sources/streams within an = SDP m- line are rejected. >2) Section 6.3 says directionality of anymedia applies to all media lines.= This seems limiting as well. I may want to temporarily stop a video stream= (i.e. make inactive or recvonly), but continue to have the audio be sendre= cv. You can use the ssrc attribute to set the directionality for individual sou= rces/streams. >3) Section 6.4, I think you need to be able to specify the bandwidth for e= ach media stream in the anymedia group, so new syntax will be needed to dea= l with the bandwidth attribute. Yes. But, again, it is a generic thing for when you have multiple sources/stream= s per m- line. Regards, Christer From eckelcu@cisco.com Sun Nov 4 19:29: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 0CC5021F8968 for ; Sun, 4 Nov 2012 19:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.719 X-Spam-Level: X-Spam-Status: No, score=-8.719 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVCtblF8GKtY for ; Sun, 4 Nov 2012 19:29:15 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E847A21F847D for ; Sun, 4 Nov 2012 19:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3997; q=dns/txt; s=iport; t=1352086155; x=1353295755; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gKdoS5OmV8RBwkGQ05TvLLBLId//oemvqGpMvnQxM9o=; b=lBIub8uzy6QfJiQ6QXABMnU42RChXsN4ekNA1GivUf7tjtZw4R889DEy uPemP4FMudXi+x2ZZZoKTgM6sv9JnNVQ5PEnMbah5wcMa5ocPmZDp1m/3 pPIzmAQdO0MCwErBboiOpBAx6aptB/UicDiyTwkAFh3Jlg+3r0K3xgNTQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKcxl1CtJXG9/2dsb2JhbABEwzmBCIIeAQEBAwESASdLBAIBCBEEAQELFAkHMhQJCAEBBAESCBqHYgaZaZ8TjAGFW2EDpFSBa4JvgVsgBBo X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138762226" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2012 03:29:14 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA53TEDF023489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 03:29:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 21:29:14 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 Thread-Index: Ac267nvcN3J2CS9eTQqf4SWGCPoMTwAARGUgAAP/nPA= Date: Mon, 5 Nov 2012 03:29:14 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.112.248] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--39.677800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-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, 05 Nov 2012 03:29:16 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, November 04, 2012 8:00 PM > To: Charles Eckel (eckelcu); mmusic@ietf.org > Subject: RE: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 >=20 >=20 > Hi Charles, >=20 > >I read the draft, and I have some concerns it with. It seems that in gen= eral > one needs to duplicate much of the information from each individual media > description in the anymedia media description. I think I could live with = that; > >however, the bigger problem is in regard to figuring out what needs to b= e > specified in the anymedia media description. In the good cases, you merel= y > duplicate the SDP attributes from each individual media description in th= e > anymedia > >media description. In the bad case, you need to define new SDP attribute= s. > >Here are some related comments in regard to specific section of the > existing draft. > > > >1) Section 5.2.2.2 seems to imply that accepting/rejecting an anymedia > media description is always an all of nothing matter. If it contains 2 au= dio > lines and 2 video lines, I need to accept all of them or none of them. It= that > is the > >intent, it seems pretty limiting to me. >=20 > That is not the intent. >=20 > However, it is related to a more general (not specific to muliplexing) > question that needs to be clarified - how individual sources/streams with= in > an SDP m- line are rejected. Okay, that is true; but the need for such a mechanism is more common needed= if all media is in a single description rather than in multiple media desc= riptions that are then bundled. The anymedia syntax really forces the issue= for even relatively simple use cases. > >2) Section 6.3 says directionality of anymedia applies to all media line= s. > This seems limiting as well. I may want to temporarily stop a video strea= m > (i.e. make inactive or recvonly), but continue to have the audio be sendr= ecv. >=20 > You can use the ssrc attribute to set the directionality for individual > sources/streams. >=20 > >3) Section 6.4, I think you need to be able to specify the bandwidth for > each media stream in the anymedia group, so new syntax will be needed to > deal with the bandwidth attribute. >=20 > Yes. >=20 > But, again, it is a generic thing for when you have multiple sources/stre= ams > per m- line. In the case of multiple m-lines, you can assign a bandwidth per m-line and = have the session bandwidth cap the total bandwidth for the session. With an= ymedia and a single m-line, you lose the granularity you previously had at = the m-line level and are left with specifying the bandwidth for the anymedi= a line as a whole. For example, today I might offer the following for a video call with conten= t sharing: v=3D0 =09 o=3Danonymous 1240218157 1240218157 IN IP4 10.193.128.35=20 s=3D-=20 i=3DmyUserAgent=20 c=3DIN IP4 10.193.128.35=20 b=3DTIAS:512000 t=3D0 0=20 m=3Daudio 6000 RTP/AVP 0 18 101 a=3Drtpmap:0 PCMU/8000=20 a=3Drtpmap:18 G729/8000=20 a=3Drtpmap:101 telephone-event/8000=20 a=3Dfmtp:101 0-15=20 m=3Dvideo 6002 RTP/AVP 96 b=3DTIAS:512000=20 a=3Drtpmap:96 H264/90000=20 a=3Dfmtp:96 profile-level-id=3D428014=20 a=3Dcontent:main m=3Dvideo 6002 RTP/AVP 96 b=3DTIAS:256000=20 a=3Drtpmap:96 H264/90000=20 a=3Dfmtp:96 profile-level-id=3D428014 a=3Dcontent:slides In this case, depending on the answer, the audio will take between 8k and 6= 4k, the main video can take the remainder of the 512k until content sharing= starts, and once content sharing starts, the main video could drop down a = bit to free some bandwidth for the content . With mmt, all I can specify is 512k for the total. I cannot subdivide it pe= r media stream as above. To do so, I would need to specify some new SDP and= /or encode the SSRC values I plan to use in SDP.=20 Cheers, Charles >=20 > Regards, >=20 > Christer From internet-drafts@ietf.org Mon Nov 5 05:25: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 C2D9F21F8514; Mon, 5 Nov 2012 05:25:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjI4VKQrEwPK; Mon, 5 Nov 2012 05:25:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CA721F853B; Mon, 5 Nov 2012 05:25:49 -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.35 Message-ID: <20121105132549.16948.80610.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 05:25:49 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-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: Mon, 05 Nov 2012 13:25:49 -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 Wor= king Group of the IETF. Title : Latching: Hosted NAT Traversal (HNT) for Media in Real-T= ime Communication Author(s) : Emil Ivov Hadriel Kaplan Dan Wing Filename : draft-ietf-mmusic-latching-00.txt Pages : 15 Date : 2012-11-05 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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-latching-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From harald@alvestrand.no Mon Nov 5 06:55: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 BD83C21F8798 for ; Mon, 5 Nov 2012 06:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N-yZgyhvDMt for ; Mon, 5 Nov 2012 06:55:38 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9750A21F8783 for ; Mon, 5 Nov 2012 06:55:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C7AD439E197 for ; Mon, 5 Nov 2012 15:55:33 +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 tDQudYNn5LGp for ; Mon, 5 Nov 2012 15:55:33 +0100 (CET) Received: from [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:64:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0235C39E091 for ; Mon, 5 Nov 2012 15:55:32 +0100 (CET) Message-ID: <5097D363.3080207@alvestrand.no> Date: Mon, 05 Nov 2012 15:55:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <5093DE68.80508@alum.mit.edu> In-Reply-To: <5093DE68.80508@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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 Nov 2012 14:55:40 -0000 On 11/02/2012 03:53 PM, Paul Kyzivat wrote: > On 11/2/12 6:39 AM, Harald Alvestrand wrote: >> As currently specified, the DTLS/SCTP protocol is carefully specified in >> such a way that it can ride on the same 5-tuple as an SRTP session. I'd >> like to keep that property when we SDP-negotiate it. > > It is? How? Where is that specified? RFC 5764 section 5.1.2 (DTLS/SCTP packets are DTLS packets). From harald@alvestrand.no Mon Nov 5 07:45: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 4FEDC21F8514 for ; Mon, 5 Nov 2012 07:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.71 X-Spam-Level: X-Spam-Status: No, score=-107.71 tagged_above=-999 required=5 tests=[AWL=-2.711, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYfzKjVl-P5h for ; Mon, 5 Nov 2012 07:45:28 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA65821F84DB for ; Mon, 5 Nov 2012 07:45:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7732739E197 for ; Mon, 5 Nov 2012 16:45:27 +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 hnL51hYZy2Bc for ; Mon, 5 Nov 2012 16:45:26 +0100 (CET) Received: from [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5BA6339E091 for ; Mon, 5 Nov 2012 16:45:24 +0100 (CET) Message-ID: <5097DF12.2020209@alvestrand.no> Date: Mon, 05 Nov 2012 16:45:22 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-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 Nov 2012 15:45:29 -0000 On 11/04/2012 07:23 AM, Charles Eckel (eckelcu) wrote: > 2) Section 6.4.2, reads: > > The total proposed bandwidth is the sum of the proposed bandwidth for > each "m=" line associated with a negotiated BUNDLE group. > > I'm afraid this is an overly simplistic approach. For example, a typical video call with content sharing includes one audio m-line and 2 video m-lines. The bandwidth is declared at the session level as well as at the media level, but the sum of the media levels is typically greater than that of the session level. When content sharing occurs, it steals some bandwidth from the main video. In the case of BUNDLED m-lines, the proposed bandwidth should therefore be the lesser of the sum of the BUNDLE m-lines and the session bandwidth. > I'm not sure this really matters; what we're trying to compute is the b= parameter for the "implied RTP session" in the BUNDLE group. What matters is that it's computed consistently, which argues for the simplest possible computation. Last time I looked b=CT was scoped to a whole conference ("supplied for the session"), while b=AS was scoped to a single RTP session. But I may be misinterpreting RFC 4566 section 5.8. But yes, that's one of the advantages of the MMT approach - the sender gets to specify instead of the receiver having to compute. From fandreas@cisco.com Mon Nov 5 11:00: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 0CB1821F87F1 for ; Mon, 5 Nov 2012 11:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrwYk-sw3eCZ for ; Mon, 5 Nov 2012 10:59:59 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EB54F21F877E for ; Mon, 5 Nov 2012 10:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5370; q=dns/txt; s=iport; t=1352141999; x=1353351599; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=a7J0/9r4owBd6S+2W2eYaQ5napvgn9jUBm+c4LAWQRQ=; b=I5oDidicAGe72rJT24QlASitnqTGwLNqSLMlTNsXUwHuNwDhtS4H6NYf uvWuAA4sTwZc9rI2/OB6FpN5QPi64BPCYXmsg0W7RMPPCc5KNistKTukZ /9jOkKZ8gXywoKm0d3RtUR8oWkffWi1+ZjnZw1oqXEyrKVDjPtu3XvthI M=; X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="scan'208";a="63241501" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 05 Nov 2012 18:59:39 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.246.145]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA5IxcHw000842; Mon, 5 Nov 2012 18:59:38 GMT Message-ID: <50980C99.9090906@cisco.com> Date: Mon, 05 Nov 2012 13:59:37 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-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, 05 Nov 2012 19:00:00 -0000 Taking a step back, the big issue I have with the various "bundle"-like proposals is how we deal with parameters/attributes that have to be reconciled across multiple media descriptions. I have yet to see solutions for how to deal with that in a generic manner. What I like about the "mmt"-style proposal is that we avoid that issue by treating the multiplexed media stream as a single media description and hence we explicitly provide the parameters/attributes we want to use for that multiplexed media description. As you note, we lose some expressiveness in the process of doing that. Use of source-specific media attributes (RFC 5576) brings some of that back, but not everything. We have other parameters and, as you note, a potential need to specify things at the "stream"-level (which could consist of more than one SSRC), however you could probably come up with a solution similar to RFC 5576 for those (level of indirection for the actual parameter/attribute). It's a more verbose solution than the "bundle"-like approaches, but it also provides a clearer and cleaner solution IMO (of course the middlebox guys will probably tell us shortly that this will never make it through their boxes) Thanks -- Flemming (as Individual) On 11/4/12 10:29 PM, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Sunday, November 04, 2012 8:00 PM >> To: Charles Eckel (eckelcu); mmusic@ietf.org >> Subject: RE: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 >> >> >> Hi Charles, >> >>> I read the draft, and I have some concerns it with. It seems that in general >> one needs to duplicate much of the information from each individual media >> description in the anymedia media description. I think I could live with that; >>> however, the bigger problem is in regard to figuring out what needs to be >> specified in the anymedia media description. In the good cases, you merely >> duplicate the SDP attributes from each individual media description in the >> anymedia >>> media description. In the bad case, you need to define new SDP attributes. >>> Here are some related comments in regard to specific section of the >> existing draft. >>> 1) Section 5.2.2.2 seems to imply that accepting/rejecting an anymedia >> media description is always an all of nothing matter. If it contains 2 audio >> lines and 2 video lines, I need to accept all of them or none of them. It that >> is the >>> intent, it seems pretty limiting to me. >> That is not the intent. >> >> However, it is related to a more general (not specific to muliplexing) >> question that needs to be clarified - how individual sources/streams within >> an SDP m- line are rejected. > Okay, that is true; but the need for such a mechanism is more common needed if all media is in a single description rather than in multiple media descriptions that are then bundled. The anymedia syntax really forces the issue for even relatively simple use cases. > >>> 2) Section 6.3 says directionality of anymedia applies to all media lines. >> This seems limiting as well. I may want to temporarily stop a video stream >> (i.e. make inactive or recvonly), but continue to have the audio be sendrecv. >> >> You can use the ssrc attribute to set the directionality for individual >> sources/streams. >> >>> 3) Section 6.4, I think you need to be able to specify the bandwidth for >> each media stream in the anymedia group, so new syntax will be needed to >> deal with the bandwidth attribute. >> >> Yes. >> >> But, again, it is a generic thing for when you have multiple sources/streams >> per m- line. > In the case of multiple m-lines, you can assign a bandwidth per m-line and have the session bandwidth cap the total bandwidth for the session. With anymedia and a single m-line, you lose the granularity you previously had at the m-line level and are left with specifying the bandwidth for the anymedia line as a whole. > For example, today I might offer the following for a video call with content sharing: > > v=0 > o=anonymous 1240218157 1240218157 IN IP4 10.193.128.35 > s=- > i=myUserAgent > c=IN IP4 10.193.128.35 > b=TIAS:512000 > t=0 0 > m=audio 6000 RTP/AVP 0 18 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > m=video 6002 RTP/AVP 96 > b=TIAS:512000 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=428014 > a=content:main > m=video 6002 RTP/AVP 96 > b=TIAS:256000 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=428014 > a=content:slides > > In this case, depending on the answer, the audio will take between 8k and 64k, the main video can take the remainder of the 512k until content sharing starts, and once content sharing starts, the main video could drop down a bit to free some bandwidth for the content . > With mmt, all I can specify is 512k for the total. I cannot subdivide it per media stream as above. To do so, I would need to specify some new SDP and/or encode the SSRC values I plan to use in SDP. > > Cheers, > Charles > > >> Regards, >> >> Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From eckelcu@cisco.com Mon Nov 5 12:04: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 13C1221F8201 for ; Mon, 5 Nov 2012 12:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[AWL=-3.100, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyCZtWIMtaQF for ; Mon, 5 Nov 2012 12:04:26 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1D521F84E2 for ; Mon, 5 Nov 2012 12:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2471; q=dns/txt; s=iport; t=1352145866; x=1353355466; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aeEzR3kXA+yAlXG9jeK4oSs9ZEMMzf5NB4ntmkz10ZA=; b=SwXwkMPR/NY8hPtvWhbj8wR7b09B70LwjPWu2lm6bh/1LiRF5GCEPB1N N3jW0TfEQM3JAQ0xuw1pt8iUrU7b39b1hv4jSjsWk5D00ZvELhpMaqkSr o+v/4CxrYDn+BrjitPtrW36nMDORevokoTPYXePXjVvVXP7gRG1RcgOPE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKoamFCtJV2Z/2dsb2JhbABEwzSBCIIeAQEBAwEBAQEPAScuBhAHBAIBCBEEAQEBChQFBAcnCxQJCAIEARIIARmHYgYLmnSgDIwBGoVBYQOkVIFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="scan'208";a="138998357" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 20:04:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5K4PSM011881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 20:04:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 14:04:25 -0600 From: "Charles Eckel (eckelcu)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01) Thread-Index: AQHNu2yZJyuQHhZlfUCEbmtj3UUmnZfbqLRg Date: Mon, 5 Nov 2012 20:04:24 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> <5097DF12.2020209@alvestrand.no> In-Reply-To: <5097DF12.2020209@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--55.857000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-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 Nov 2012 20:04:27 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Monday, November 05, 2012 10:45 AM > To: mmusic@ietf.org > Subject: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft- > ietf-mmusic-sdp-bundle-negotiation-01) >=20 > On 11/04/2012 07:23 AM, Charles Eckel (eckelcu) wrote: > > 2) Section 6.4.2, reads: > > > > The total proposed bandwidth is the sum of the proposed bandwidth f= or > > each "m=3D" line associated with a negotiated BUNDLE group. > > > > I'm afraid this is an overly simplistic approach. For example, a typica= l video > call with content sharing includes one audio m-line and 2 video m-lines. = The > bandwidth is declared at the session level as well as at the media level,= but > the sum of the media levels is typically greater than that of the session > level. When content sharing occurs, it steals some bandwidth from the mai= n > video. In the case of BUNDLED m-lines, the proposed bandwidth should > therefore be the lesser of the sum of the BUNDLE m-lines and the session > bandwidth. > > > I'm not sure this really matters; what we're trying to compute is the b= =3D > parameter for the "implied RTP session" in the BUNDLE group. What > matters is that it's computed consistently, which argues for the > simplest possible computation. >=20 > Last time I looked b=3DCT was scoped to a whole conference ("supplied for > the session"), while b=3DAS was scoped to a single RTP session. But I may > be misinterpreting RFC 4566 section 5.8. I recommend using b=3DTIAS, as defined in RFC 3890. This parameter may be u= sed at either the session or the media level, and it scope accordingly.=20 What needs to be avoided is summing up the b=3DTIAS/AS values from the bund= led media lines and using that as that bandwidth for the bundle even if it = exceeds the b=3DTIAS/AS/CT value from the session level. > But yes, that's one of the advantages of the MMT approach - the sender > gets to specify instead of the receiver having to compute. The MMT approach has different challenges when it comes to bandwidth. That = is being tracked in another thread (http://www.ietf.org/mail-archive/web/mm= usic/current/msg09817.html). Cheers, Charles >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Mon Nov 5 13:18: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 554DC21F850A for ; Mon, 5 Nov 2012 13:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=-3.329, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJErbCReNMgf for ; Mon, 5 Nov 2012 13:18:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A8D5C21F8468 for ; Mon, 5 Nov 2012 13:18:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61E6E39E197; Mon, 5 Nov 2012 22:18:46 +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 5mby86wvwhnn; Mon, 5 Nov 2012 22:18:45 +0100 (CET) Received: from [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 12EF839E091; Mon, 5 Nov 2012 22:18:44 +0100 (CET) Message-ID: <50982D33.3060909@alvestrand.no> Date: Mon, 05 Nov 2012 22:18:43 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> <5097DF12.2020209@alvestrand.no> <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-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 Nov 2012 21:18:49 -0000 On 11/05/2012 09:04 PM, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >> Sent: Monday, November 05, 2012 10:45 AM >> To: mmusic@ietf.org >> Subject: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft- >> ietf-mmusic-sdp-bundle-negotiation-01) >> >> On 11/04/2012 07:23 AM, Charles Eckel (eckelcu) wrote: >>> 2) Section 6.4.2, reads: >>> >>> The total proposed bandwidth is the sum of the proposed bandwidth for >>> each "m=" line associated with a negotiated BUNDLE group. >>> >>> I'm afraid this is an overly simplistic approach. For example, a typical video >> call with content sharing includes one audio m-line and 2 video m-lines. The >> bandwidth is declared at the session level as well as at the media level, but >> the sum of the media levels is typically greater than that of the session >> level. When content sharing occurs, it steals some bandwidth from the main >> video. In the case of BUNDLED m-lines, the proposed bandwidth should >> therefore be the lesser of the sum of the BUNDLE m-lines and the session >> bandwidth. >> I'm not sure this really matters; what we're trying to compute is the b= >> parameter for the "implied RTP session" in the BUNDLE group. What >> matters is that it's computed consistently, which argues for the >> simplest possible computation. >> >> Last time I looked b=CT was scoped to a whole conference ("supplied for >> the session"), while b=AS was scoped to a single RTP session. But I may >> be misinterpreting RFC 4566 section 5.8. > I recommend using b=TIAS, as defined in RFC 3890. This parameter may be used at either the session or the media level, and it scope accordingly. > What needs to be avoided is summing up the b=TIAS/AS values from the bundled media lines and using that as that bandwidth for the bundle even if it exceeds the b=TIAS/AS/CT value from the session level. If one of the bundling approaches is chosen, would you recommend setting the RTP session (=media level) bandwidth as min(SDP session b= line, sum(media b= line))? > >> But yes, that's one of the advantages of the MMT approach - the sender >> gets to specify instead of the receiver having to compute. > The MMT approach has different challenges when it comes to bandwidth. That is being tracked in another thread (http://www.ietf.org/mail-archive/web/mmusic/current/msg09817.html). > > Cheers, > Charles > >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Mon Nov 5 13:24: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 6F54E21F8643 for ; Mon, 5 Nov 2012 13:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.695 X-Spam-Level: X-Spam-Status: No, score=-108.695 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lER8y1ZaEO9C for ; Mon, 5 Nov 2012 13:24:07 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40E21F862C for ; Mon, 5 Nov 2012 13:24:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F9E239E197 for ; Mon, 5 Nov 2012 22:23:58 +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 4c4rZf5KvjQQ for ; Mon, 5 Nov 2012 22:23:57 +0100 (CET) Received: from [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011] (unknown [IPv6:2001:df8:0:16:ed78:3a9f:6634:b011]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0982439E091 for ; Mon, 5 Nov 2012 22:23:56 +0100 (CET) Message-ID: <50982E6B.1010904@alvestrand.no> Date: Mon, 05 Nov 2012 22:23:55 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMT bandwidth limits (Re: comments on draft-holmberg-mmusic-sdp-mmt-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, 05 Nov 2012 21:24:08 -0000 On 11/05/2012 04:29 AM, Charles Eckel (eckelcu) wrote: > In the case of multiple m-lines, you can assign a bandwidth per m-line and have the session bandwidth cap the total bandwidth for the session. With anymedia and a single m-line, you lose the granularity you previously had at the m-line level and are left with specifying the bandwidth for the anymedia line as a whole. > For example, today I might offer the following for a video call with content sharing: > > v=0 > o=anonymous 1240218157 1240218157 IN IP4 10.193.128.35 > s=- > i=myUserAgent > c=IN IP4 10.193.128.35 > b=TIAS:512000 > t=0 0 > m=audio 6000 RTP/AVP 0 18 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:18 G729/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > m=video 6002 RTP/AVP 96 > b=TIAS:512000 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=428014 > a=content:main > m=video 6002 RTP/AVP 96 > b=TIAS:256000 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=428014 > a=content:slides > > In this case, depending on the answer, the audio will take between 8k and 64k, the main video can take the remainder of the 512k until content sharing starts, and once content sharing starts, the main video could drop down a bit to free some bandwidth for the content . > With mmt, all I can specify is 512k for the total. I cannot subdivide it per media stream as above. To do so, I would need to specify some new SDP and/or encode the SSRC values I plan to use in SDP. I'm curious - if I send this in an offer, is there any part of the SDP description that says that the respondent, when sending, should cut down on his video bandwidth if video + audio would otherwise be > 512K? I don't see any "priority" flags in there. (another thing that confuses me a bit is how b= represents bandwidth in the 2 directions for a point-to-point session - if A sends an offer with session b=TIAS:512K, and B sends A an answer with session b=TIAS:512K, and they both start sending video at 300K, are they below the cap or above the cap? Again, it's probably clear to those who've been around here for a while) Harald From eckelcu@cisco.com Mon Nov 5 15:46:31 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 A369121F85E3 for ; Mon, 5 Nov 2012 15:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=-2.933, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLLCRNrAl6w1 for ; Mon, 5 Nov 2012 15:46:30 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BC72921F850E for ; Mon, 5 Nov 2012 15:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3179; q=dns/txt; s=iport; t=1352159190; x=1353368790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IQNkU5hCtJPzVtA5ZfFPAyeNNM71E7O5OthQc9GeUKg=; b=IUgmNXUKbIrkI+noJEI9S98nhjxHax8KZ1Kw1hHXomx+aHarqSS2eFJO IYO8Zt5+jjjVVr218+QB+YSGl9vVIWQj+NGLEN+G2Vxa9jqx56Kuy7Mre 0v0DFJb59yF0ywXd/7UKVUcUx0A30oludMcAC+rhQmTwcx8/ep1nlnKEv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHpOmFCtJV2c/2dsb2JhbABEwzOBCIIeAQEBAwEBAQEPAScuBgsFBwQCAQgRBAEBAQoUBQQHJwsUCQgCBA4FCAEZh2IGC5p/oBaLfBqDYYF5YQOhMYMjgWuCYg2BZBce X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139122432" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2012 23:46:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA5NkU7R019225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:46:30 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:46:29 -0600 From: "Charles Eckel (eckelcu)" To: Harald Alvestrand Thread-Topic: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01) Thread-Index: AQHNu5smlSCAWyidW0qMav9BRQT7i5fb5+wA Date: Mon, 5 Nov 2012 23:46:29 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828108022@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> <5097DF12.2020209@alvestrand.no> <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> <50982D33.3060909@alvestrand.no> In-Reply-To: <50982D33.3060909@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.191] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--54.992600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-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 Nov 2012 23:46:31 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, November 05, 2012 4:19 PM > To: Charles Eckel (eckelcu) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft- > ietf-mmusic-sdp-bundle-negotiation-01) >=20 > On 11/05/2012 09:04 PM, Charles Eckel (eckelcu) wrote: > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >> Sent: Monday, November 05, 2012 10:45 AM > >> To: mmusic@ietf.org > >> Subject: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft- > >> ietf-mmusic-sdp-bundle-negotiation-01) > >> > >> On 11/04/2012 07:23 AM, Charles Eckel (eckelcu) wrote: > >>> 2) Section 6.4.2, reads: > >>> > >>> The total proposed bandwidth is the sum of the proposed bandwidt= h > for > >>> each "m=3D" line associated with a negotiated BUNDLE group. > >>> > >>> I'm afraid this is an overly simplistic approach. For example, a typi= cal > video > >> call with content sharing includes one audio m-line and 2 video m-line= s. > The > >> bandwidth is declared at the session level as well as at the media lev= el, > but > >> the sum of the media levels is typically greater than that of the sess= ion > >> level. When content sharing occurs, it steals some bandwidth from the > main > >> video. In the case of BUNDLED m-lines, the proposed bandwidth should > >> therefore be the lesser of the sum of the BUNDLE m-lines and the sessi= on > >> bandwidth. > >> I'm not sure this really matters; what we're trying to compute is the = b=3D > >> parameter for the "implied RTP session" in the BUNDLE group. What > >> matters is that it's computed consistently, which argues for the > >> simplest possible computation. > >> > >> Last time I looked b=3DCT was scoped to a whole conference ("supplied = for > >> the session"), while b=3DAS was scoped to a single RTP session. But I = may > >> be misinterpreting RFC 4566 section 5.8. > > I recommend using b=3DTIAS, as defined in RFC 3890. This parameter may = be > used at either the session or the media level, and it scope accordingly. > > What needs to be avoided is summing up the b=3DTIAS/AS values from the > bundled media lines and using that as that bandwidth for the bundle even = if > it exceeds the b=3DTIAS/AS/CT value from the session level. > If one of the bundling approaches is chosen, would you recommend setting > the RTP session (=3Dmedia level) bandwidth as min(SDP session b=3D line, > sum(media b=3D line))? Yes. Cheers, Charles > >> But yes, that's one of the advantages of the MMT approach - the sender > >> gets to specify instead of the receiver having to compute. > > The MMT approach has different challenges when it comes to bandwidth. > That is being tracked in another thread (http://www.ietf.org/mail- > archive/web/mmusic/current/msg09817.html). > > > > Cheers, > > Charles > > > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Mon Nov 5 15:58: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 B75FD21F845E for ; Mon, 5 Nov 2012 15:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=-3.367, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwylsaam7-58 for ; Mon, 5 Nov 2012 15:58:32 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D9F3311E80A3 for ; Mon, 5 Nov 2012 15:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3497; q=dns/txt; s=iport; t=1352159912; x=1353369512; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ThjsHL4w5CWOPZKewdpph2yw7TYwsfy9/1/GboMjSr4=; b=E6jXW1oIum/EwvHTggCy6cOW6h4JifBa2/b5eRBoxwoYEIVUM53LMvo3 7sb1nWs6TpeI1qKeBtlUr63cL0rosTdJI5k2YiCOipuVPcQ4aqF1kK3bM B5ooiXfMz3S1lhHEVKLLpkyUMRV+YlqvAyml8chni3p+WmN/oTZ0YcXkQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHFRmFCtJV2b/2dsb2JhbABEwzKBCIIeAQEBAwEBAQEPASc0EAcEAgEIEQQBAQEKFAkHJwsUCQgCBAESCBqHYgYLmwKgEgSLfIN7gXlhA6RUgWuCYg2CGQ X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139125360" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2012 23:58:31 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA5NwV8u024170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:58:31 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:58:30 -0600 From: "Charles Eckel (eckelcu)" To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] MMT bandwidth limits (Re: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00) Thread-Index: AQHNu5vn4unUpqCYCEaU5rC485NR+5fb6a2Q Date: Mon, 5 Nov 2012 23:58:29 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828108043@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> <50982E6B.1010904@alvestrand.no> In-Reply-To: <50982E6B.1010904@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.191] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--60.435100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] MMT bandwidth limits (Re: comments on draft-holmberg-mmusic-sdp-mmt-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, 05 Nov 2012 23:58:32 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Monday, November 05, 2012 4:24 PM > To: mmusic@ietf.org > Subject: [MMUSIC] MMT bandwidth limits (Re: comments on draft- > holmberg-mmusic-sdp-mmt-negotiation-00) >=20 > On 11/05/2012 04:29 AM, Charles Eckel (eckelcu) wrote: > > In the case of multiple m-lines, you can assign a bandwidth per m-line = and > have the session bandwidth cap the total bandwidth for the session. With > anymedia and a single m-line, you lose the granularity you previously had= at > the m-line level and are left with specifying the bandwidth for the > anymedia line as a whole. > > For example, today I might offer the following for a video call with co= ntent > sharing: > > > > v=3D0 > > o=3Danonymous 1240218157 1240218157 IN IP4 10.193.128.35 > > s=3D- > > i=3DmyUserAgent > > c=3DIN IP4 10.193.128.35 > > b=3DTIAS:512000 > > t=3D0 0 > > m=3Daudio 6000 RTP/AVP 0 18 101 > > a=3Drtpmap:0 PCMU/8000 > > a=3Drtpmap:18 G729/8000 > > a=3Drtpmap:101 telephone-event/8000 > > a=3Dfmtp:101 0-15 > > m=3Dvideo 6002 RTP/AVP 96 > > b=3DTIAS:512000 > > a=3Drtpmap:96 H264/90000 > > a=3Dfmtp:96 profile-level-id=3D428014 > > a=3Dcontent:main > > m=3Dvideo 6002 RTP/AVP 96 > > b=3DTIAS:256000 > > a=3Drtpmap:96 H264/90000 > > a=3Dfmtp:96 profile-level-id=3D428014 > > a=3Dcontent:slides > > > > In this case, depending on the answer, the audio will take between 8k a= nd > 64k, the main video can take the remainder of the 512k until content shar= ing > starts, and once content sharing starts, the main video could drop down a= bit > to free some bandwidth for the content . > > With mmt, all I can specify is 512k for the total. I cannot subdivide i= t per > media stream as above. To do so, I would need to specify some new SDP > and/or encode the SSRC values I plan to use in SDP. > I'm curious - if I send this in an offer, is there any part of the SDP > description that says that the respondent, when sending, should cut down > on his video bandwidth if video + audio would otherwise be > 512K? >=20 > I don't see any "priority" flags in there. There is no explicit priority. It is up to the application to decide. RFC 3= 890 does say: At the SDP session level, the TIAS value is the maximal amount of bandwidth needed when all declared media streams are used. This MAY be less than the sum of all the individual media streams values. This is due to the possibility that not all streams have their maximum at the same point in time.=20 > (another thing that confuses me a bit is how b=3D represents bandwidth in > the 2 directions for a point-to-point session - if A sends an offer with > session b=3DTIAS:512K, and B sends A an answer with session b=3DTIAS:512K= , > and they both start sending video at 300K, are they below the cap or > above the cap? That is fine. This is just a statement of the maximum bandwidth the impleme= ntation is willing to receive. The values can be asymmetric, and this is ju= st a maximum. It does not indicate anything about how much the implementati= on will send. Cheers, Charles > Again, it's probably clear to those who've been around here for a while) =20 > Harald >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Mon Nov 5 16:06: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 8A88221F85A8 for ; Mon, 5 Nov 2012 16:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.213 X-Spam-Level: X-Spam-Status: No, score=-8.213 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+tZA1W-1tJH for ; Mon, 5 Nov 2012 16:06:27 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 486B521F87EF for ; Mon, 5 Nov 2012 16:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6536; q=dns/txt; s=iport; t=1352160384; x=1353369984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9/QvXWUa8akmmHp/mn/AUs+qtH44G4olOjAa7iO4/+I=; b=G/bReo8JYiMznjkTjm8w3gwt8av7LbbpLRgdthuJ6sElWzY7rjyutZyN jIRO8wGwZ4tyuULr6876JY4TYVjbHBgLzpPJhNOoNBSYJbk+Ru9OuPLif 8bbsIKxZryCpZkwHd9H6SxFcXbWQ/JhkKdkNaKdf8HNTmDvnXadVvou3U o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABNUmFCtJXG+/2dsb2JhbABEwzOBCIIeAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAEBBA4FCBMHh2gLmnyPZJAxBIt8hXRhA6RUgWuCb4FbIAQa X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139092736" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 06 Nov 2012 00:06:23 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA606NKY028348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 00:06:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 18:06:23 -0600 From: "Charles Eckel (eckelcu)" To: "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00 Thread-Index: Ac267nvcN3J2CS9eTQqf4SWGCPoMTwAARGUgAAP/nPAALpyOgAACHf8A Date: Tue, 6 Nov 2012 00:06:23 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882810806C@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281074BD@xmb-aln-x08.cisco.com> <7594FB04B1934943A5C02806D1A2204B024E1B@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C0882810758B@xmb-aln-x08.cisco.com> <50980C99.9090906@cisco.com> In-Reply-To: <50980C99.9090906@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.191] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--59.078200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-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: Tue, 06 Nov 2012 00:06:32 -0000 Hi Flemming, You may very well be right, and I think Christer agrees with your assessmen= t as well. I do not necessarily disagree, but I am not sure that I agree ei= ther. The bandwidth attribute is one example for which I think BUNDLE works bette= r than MMT. However, bandwidth may be the exception and it may be that the = majority of SDP attributes are more straightforward with MMT. An example or two would probably help convince me, or maybe a beer :) Cheers, Charles > -----Original Message----- > From: Flemming Andreasen (fandreas) > Sent: Monday, November 05, 2012 2:00 PM > To: Charles Eckel (eckelcu) > Cc: Christer Holmberg; mmusic@ietf.org > Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt- > negotiation-00 >=20 > Taking a step back, the big issue I have with the various "bundle"-like > proposals is how we deal with parameters/attributes that have to be > reconciled across multiple media descriptions. I have yet to see > solutions for how to deal with that in a generic manner. >=20 > What I like about the "mmt"-style proposal is that we avoid that issue > by treating the multiplexed media stream as a single media description > and hence we explicitly provide the parameters/attributes we want to use > for that multiplexed media description. As you note, we lose some > expressiveness in the process of doing that. Use of source-specific > media attributes (RFC 5576) brings some of that back, but not > everything. We have other parameters and, as you note, a potential need > to specify things at the "stream"-level (which could consist of more > than one SSRC), however you could probably come up with a solution > similar to RFC 5576 for those (level of indirection for the actual > parameter/attribute). It's a more verbose solution than the > "bundle"-like approaches, but it also provides a clearer and cleaner > solution IMO (of course the middlebox guys will probably tell us shortly > that this will never make it through their boxes) >=20 > Thanks >=20 > -- Flemming (as Individual) >=20 >=20 > On 11/4/12 10:29 PM, Charles Eckel (eckelcu) wrote: > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Sunday, November 04, 2012 8:00 PM > >> To: Charles Eckel (eckelcu); mmusic@ietf.org > >> Subject: RE: comments on draft-holmberg-mmusic-sdp-mmt-negotiation- > 00 > >> > >> > >> Hi Charles, > >> > >>> I read the draft, and I have some concerns it with. It seems that in > general > >> one needs to duplicate much of the information from each individual > media > >> description in the anymedia media description. I think I could live wi= th > that; > >>> however, the bigger problem is in regard to figuring out what needs t= o > be > >> specified in the anymedia media description. In the good cases, you > merely > >> duplicate the SDP attributes from each individual media description in > the > >> anymedia > >>> media description. In the bad case, you need to define new SDP > attributes. > >>> Here are some related comments in regard to specific section of the > >> existing draft. > >>> 1) Section 5.2.2.2 seems to imply that accepting/rejecting an anymedi= a > >> media description is always an all of nothing matter. If it contains 2= audio > >> lines and 2 video lines, I need to accept all of them or none of them.= It > that > >> is the > >>> intent, it seems pretty limiting to me. > >> That is not the intent. > >> > >> However, it is related to a more general (not specific to muliplexing) > >> question that needs to be clarified - how individual sources/streams > within > >> an SDP m- line are rejected. > > Okay, that is true; but the need for such a mechanism is more common > needed if all media is in a single description rather than in multiple me= dia > descriptions that are then bundled. The anymedia syntax really forces the > issue for even relatively simple use cases. > > > >>> 2) Section 6.3 says directionality of anymedia applies to all media l= ines. > >> This seems limiting as well. I may want to temporarily stop a video > stream > >> (i.e. make inactive or recvonly), but continue to have the audio be > sendrecv. > >> > >> You can use the ssrc attribute to set the directionality for individua= l > >> sources/streams. > >> > >>> 3) Section 6.4, I think you need to be able to specify the bandwidth = for > >> each media stream in the anymedia group, so new syntax will be needed > to > >> deal with the bandwidth attribute. > >> > >> Yes. > >> > >> But, again, it is a generic thing for when you have multiple > sources/streams > >> per m- line. > > In the case of multiple m-lines, you can assign a bandwidth per m-line = and > have the session bandwidth cap the total bandwidth for the session. With > anymedia and a single m-line, you lose the granularity you previously had= at > the m-line level and are left with specifying the bandwidth for the > anymedia line as a whole. > > For example, today I might offer the following for a video call with co= ntent > sharing: > > > > v=3D0 > > o=3Danonymous 1240218157 1240218157 IN IP4 10.193.128.35 > > s=3D- > > i=3DmyUserAgent > > c=3DIN IP4 10.193.128.35 > > b=3DTIAS:512000 > > t=3D0 0 > > m=3Daudio 6000 RTP/AVP 0 18 101 > > a=3Drtpmap:0 PCMU/8000 > > a=3Drtpmap:18 G729/8000 > > a=3Drtpmap:101 telephone-event/8000 > > a=3Dfmtp:101 0-15 > > m=3Dvideo 6002 RTP/AVP 96 > > b=3DTIAS:512000 > > a=3Drtpmap:96 H264/90000 > > a=3Dfmtp:96 profile-level-id=3D428014 > > a=3Dcontent:main > > m=3Dvideo 6002 RTP/AVP 96 > > b=3DTIAS:256000 > > a=3Drtpmap:96 H264/90000 > > a=3Dfmtp:96 profile-level-id=3D428014 > > a=3Dcontent:slides > > > > In this case, depending on the answer, the audio will take between 8k a= nd > 64k, the main video can take the remainder of the 512k until content shar= ing > starts, and once content sharing starts, the main video could drop down a= bit > to free some bandwidth for the content . > > With mmt, all I can specify is 512k for the total. I cannot subdivide i= t per > media stream as above. To do so, I would need to specify some new SDP > and/or encode the SSRC values I plan to use in SDP. > > > > Cheers, > > Charles > > > > > >> Regards, > >> > >> Christer > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > . > > From fandreas@cisco.com Mon Nov 5 19:07: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 3249511E80A5 for ; Mon, 5 Nov 2012 19:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAxKYe4SQthL for ; Mon, 5 Nov 2012 19:07:35 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AE7CC21F850E for ; Mon, 5 Nov 2012 19:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1360; q=dns/txt; s=iport; t=1352171255; x=1353380855; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=2aGL2Ub4oC6qb533qPIvp3rmCav8wk8gtWPb/PhNuDw=; b=lL96ySeH3T7Q6nvMi4+fN/nvty9KTtq6G+gIJXkSsSTaQkxbWgJKM4qW 2+VYt4p5SWMetFE4J3e8k1UBWsU4yIDodZJl4wnlpkX0adZCuOr4WH/Vh wKUSqwo57QYeT6YMy454OZh3PTaph8hTRcyejGsJrYJGuaeyyHuqSLqIr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIF+mFCrRDoJ/2dsb2JhbABEwzWBCII3ASVAATwWGAMCAQIBSw0BBwEBFweHZ5sGoCOMEINngloDiFqNIY5ZgWuCYiuBPQ X-IronPort-AV: E=Sophos;i="4.80,719,1344211200"; d="scan'208";a="63206193" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 06 Nov 2012 03:07:20 +0000 Received: from dhcp-407c.meeting.ietf.org ([10.86.254.65]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA637JSc032477; Tue, 6 Nov 2012 03:07:20 GMT Message-ID: <50987EE7.7090602@cisco.com> Date: Mon, 05 Nov 2012 22:07:19 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-westerlund-mmusic-max-ssrc@tool.ietf.org Subject: [MMUSIC] Comments on draft-westerlund-mmusic-max-ssrc-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: Tue, 06 Nov 2012 03:07:36 -0000 Hi A few high-level questions/comments on this draft: 1) The draft concerns itself with resource constraints within a single media description, however in practice, limitations will often span media description boundaries due to use of shared resources. Why the limited scope ? 2) The draft only considers resource limitations in terms of codecs, however there are many other potential limiting factors to be considered (endpoint-wise and network-wise). For example, use of security mechanisms may impact what can be supported, the frequency with which packets are sent, etc. Why is the scope limited to only the codecs themselves ? 3) SDP Media Capabilities provide a general framework and partial solution to indicate resource constraints that span media descriptions. While it does not cover the specific issue being handled here (multiple instances of a given codec), it provides a more general framework that lends itself to 1) and 2) above. Any particular reason to not use this framework ? Lastly, given the royalty-bearing IPR disclosure associated with the draft (please correct me if I misread this), I think it would be desirable to make a clear distinction between the problem to solve and the solution proposed to see if we can find a royalty-free approach. Thanks -- Flemming (as Individual) From magnus.westerlund@ericsson.com Tue Nov 6 05:01: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 F41FD21F88E1 for ; Tue, 6 Nov 2012 05:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nQCsYFgPmk2 for ; Tue, 6 Nov 2012 05:01:05 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93021F88DE for ; Tue, 6 Nov 2012 05:01:04 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-0b-50990a0fd8b8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 52.CF.06323.F0A09905; Tue, 6 Nov 2012 14:01:03 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 6 Nov 2012 14:01:02 +0100 Message-ID: <50990A0D.305@ericsson.com> Date: Tue, 6 Nov 2012 08:01:01 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+JvjS4/18wAgz39ghZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtorm5gL9klXfN/6jaWBcbVYFyMnh4SAicTWh1MYIWwxiQv3 1rN1MXJxCAmcZJSYsrQdylnGKNE49TQzSBWvgLpE28WpTCA2i4CKxOxvL9hAbDYBC4mbPxrB bFGBYIk9x9YyQtQLSpyc+YQFxBYB6m3d3McKYgsLaEnM62xkgdgsKfH2/Suw+cwCehJTrrYw QtjyEs1bZ4PFhQS0JRqaOlgnMPLPQjJ2FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAyog1t+G+xg 3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MVTPm7qltzt5yd8qj yKfft1y1Z3e1dcmZvKNC5NOqTYWVHov0+749+vjaSeXGprydpz53CZwsujTjWM+0H5xSlV1c Dx+V+dV+inOuvFO7IUhVLutffqP/kdzNfBfDbylqf9LftcDpvOSXyqd/fdcvZJcpvj4noS7m 9/7sL/LHmEN7J+xVjl98X4mlOCPRUIu5qDgRAMIJ9J72AQAA Subject: [MMUSIC] Relation between SRCNAME and MSID 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 Nov 2012 13:01:09 -0000 Hi, I got to reading the MSID this morning and as it was some questions how SRCNMANE (draft-westerlund-avtext-rtcp-sdes-srcname-02) relates to MSID (draft-alvestrand-mmusic-msid-01) I will give my view on this. So SRCNAME is a hierarchical structure who's root is a media stream source, i.e. a camera or a microphone. Its primary usage is to bind SSRCs that are all related to that media source together. A simple example would be if one produced simulcast, i.e. alternative encodings, of the same media source V1, you can have a source name that is V1.enc1 for the first encoding, V2.enc2 for the second one, and so on. When you apply RTP retransmission or FEC you do that to a particular SSRC, which then is one of the encodings. Or even more complex if an encoding is an SVC MST stream, then you have several streams in different RTP sessions for the different layers, and your FEC or retransmissions only applies to one of these substreams. Thus you can have a SSRC that carries a SRCNAME of V1.enc1.baselayer and use that label for both the media stream and on the FEC SSRC to tie them together. So SRCNAME shares a property with MSID that is that is ties SSRCs both within and across RTP Sessions together. So MSID, especially in its usage with WebRTC to create the WebRTC MediaStream actually have an interesting relation to SRCNAMES. As MSID are application level groupings of particular mediaStreamTracks, a MSID can be used to tie in RTP media stream and its related SSRCs (the ones carrying the FEC or the layers) into a MediaStream object. Lets try an simple example to illustrate. A WebRTC end-point has one video camera (V1) and one microphone (A1). The video is to be provided at two different encodings V1.enc1 and V1.enc2 in SRCNAME terms. But for a WebRTC application it can actually select to deal with these two encodings as two different WebRTC MediaStreams which I will give MSID values Var1 and Var2, where the variants contain one video encoding and the audio In SDP using a=ssrc to provide the SRCNAME it would look like this m=video a=ssrc: 1111 SRCNAME:V1.enc1 a=ssrc: 1111 msid:Var1 v1 a=ssrc: 2222 SRCNAME:V1.enc2 a=ssrc: 2222 msid:Var2 v1 a=audio a=ssrc: 3333 SRCNAME:A1 a=ssrc: 3333 msid:Var1 a1 a=ssrc: 3333 msid:Var2 a1 In other words a given SSRC might actually be a MediaStreamTrack in multiple MediaStreams and thus have multiple MSIDs. While a SSRC will only have one SRCNAME, but that one may specify to a higher detail. If we would have RTP retransmission in the above, a question around MSID arises. Should all SSRCs that are part of representing be given a MSID or would it be simpler to just label the media entry point to the hierarchical relations SRCNAME is capable of expressing? And I need to point out that MSID can't replace the SRCNAME as currently defined as it doesn't make clear the hierarchical relation of the SSRCs. If you are interested in discussion SRCNAME please show up in AVTEXT on Wednesday at 1300-1430. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Tue Nov 6 06:04: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 67EE521F8917 for ; Tue, 6 Nov 2012 06:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mFdqjpP0Zm5 for ; Tue, 6 Nov 2012 06:04:54 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA30E21F8914 for ; Tue, 6 Nov 2012 06:04:54 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so442774pbb.31 for ; Tue, 06 Nov 2012 06:04:54 -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=AQtYaxlFMPTwot1mFkdbLX8YDcOemAyKuAeCyheh68M=; b=zJecFHCpv50HdTIS6Jv7VVorMR3p3umlpkBO2qpZiYakd3b4GQ+3UgDNaI5k6qnaPT X3xbbMAtqh1zWjnZ0MtxCjjlfkDY2YwfDeB4L8g/9iS5YxwrkrO98N9eTvIydrt73ean DmgFe5DFbyQGytlH1oxLzei4HdCIYJv6Pk4EWC1UsOS4scKtrnzAP8YLJqXI63rAApk0 tlR2v8we2KrdFjzGd2N0AadBiibA5pja5aTNZI6o/LA7StG0JLO1dsyzZUDwBjrk8vya dp+DqDUYrlSriYKe23wMI9i9KDMTrDELl+Q8D7FCjv0CxScrfuTAkQjrMmDxicu8tKEu WQMg== Received: by 10.68.115.75 with SMTP id jm11mr3730742pbb.28.1352210694490; Tue, 06 Nov 2012 06:04:54 -0800 (PST) Received: from RoniE ([2001:df8:0:16:fcb4:4f05:b023:df17]) by mx.google.com with ESMTPS id m7sm7285079paz.3.2012.11.06.06.04.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 06:04:53 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , "'mmusic \(E-mail\)'" References: <50990A0D.305@ericsson.com> In-Reply-To: <50990A0D.305@ericsson.com> Date: Tue, 6 Nov 2012 09:02:18 -0500 Message-ID: <004f01cdbc27$57633bc0$0629b340$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK3qumR9zd0Tpbn0anlgsM+d1sGsJYI9s7w Content-Language: en-us Subject: Re: [MMUSIC] Relation between SRCNAME and MSID 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 Nov 2012 14:04:55 -0000 Hi, I had the same question when looking at mapping RTP streams to CLUE = media capture and after trying to address simulcast in that environment it = looked to me that srcname can be used for mapping since if we look at hierarchy = of CNAME.srcname we can say that if we have an endpoint that have multiple media sources (e.g. 3 cameras) this can be reflected using the same = CNAME with srcnames V1,V2 and V3.=20 If using srcname for the simulcast case it make sense not to have a different identifier for the non simulcast case. Roni Even =20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: 06 November, 2012 8:01 AM To: mmusic (E-mail) Subject: [MMUSIC] Relation between SRCNAME and MSID Hi, I got to reading the MSID this morning and as it was some questions how SRCNMANE (draft-westerlund-avtext-rtcp-sdes-srcname-02) relates to MSID (draft-alvestrand-mmusic-msid-01) I will give my view on this. So SRCNAME is a hierarchical structure who's root is a media stream = source, i.e. a camera or a microphone. Its primary usage is to bind SSRCs that = are all related to that media source together. A simple example would be if = one produced simulcast, i.e. alternative encodings, of the same media source = V1, you can have a source name that is V1.enc1 for the first encoding, = V2.enc2 for the second one, and so on. When you apply RTP retransmission or FEC = you do that to a particular SSRC, which then is one of the encodings. Or = even more complex if an encoding is an SVC MST stream, then you have several streams in different RTP sessions for the different layers, and your FEC = or retransmissions only applies to one of these substreams. Thus you can = have a SSRC that carries a SRCNAME of V1.enc1.baselayer and use that label for = both the media stream and on the FEC SSRC to tie them together. So SRCNAME = shares a property with MSID that is that is ties SSRCs both within and across = RTP Sessions together. So MSID, especially in its usage with WebRTC to create the WebRTC MediaStream actually have an interesting relation to SRCNAMES. As MSID = are application level groupings of particular mediaStreamTracks, a MSID can = be used to tie in RTP media stream and its related SSRCs (the ones carrying = the FEC or the layers) into a MediaStream object. Lets try an simple example = to illustrate. A WebRTC end-point has one video camera (V1) and one microphone (A1). The video is to be provided at two different encodings V1.enc1 and V1.enc2 in SRCNAME terms. But for a WebRTC application it can actually select to deal with these two encodings as two different WebRTC = MediaStreams which I will give MSID values Var1 and Var2, where the variants contain = one video encoding and the audio In SDP using a=3Dssrc to provide the SRCNAME it would look like this m=3Dvideo a=3Dssrc: 1111 SRCNAME:V1.enc1 a=3Dssrc: 1111 msid:Var1 v1 a=3Dssrc: 2222 SRCNAME:V1.enc2 a=3Dssrc: 2222 msid:Var2 v1 a=3Daudio a=3Dssrc: 3333 SRCNAME:A1 a=3Dssrc: 3333 msid:Var1 a1 a=3Dssrc: 3333 msid:Var2 a1 In other words a given SSRC might actually be a MediaStreamTrack in = multiple MediaStreams and thus have multiple MSIDs. While a SSRC will only have = one SRCNAME, but that one may specify to a higher detail. If we would have RTP retransmission in the above, a question around MSID arises. Should all SSRCs that are part of representing be given a MSID = or would it be simpler to just label the media entry point to the = hierarchical relations SRCNAME is capable of expressing? And I need to point out that MSID can't replace the SRCNAME as currently defined as it doesn't make = clear the hierarchical relation of the SSRCs. If you are interested in discussion SRCNAME please show up in AVTEXT on Wednesday at 1300-1430. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From jonathan@vidyo.com Tue Nov 6 08:12: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 34D0F21F8A48 for ; Tue, 6 Nov 2012 08:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kvzNX7GIf0u for ; Tue, 6 Nov 2012 08:12:24 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 922B521F8A39 for ; Tue, 6 Nov 2012 08:12:24 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DE80D8BEAEA for ; Tue, 6 Nov 2012 11:12:23 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 7FB668BEACB for ; Tue, 6 Nov 2012 11:12:23 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Tue, 6 Nov 2012 11:12:14 -0500 From: Jonathan Lennox To: "mmusic@ietf.org" Date: Tue, 6 Nov 2012 11:12:21 -0500 Thread-Topic: Another minor update for ICE: rel-addr privacy in relay candidates Thread-Index: Ac28OXvCJFi0CJvMT/eTxFRoNEMQ4w== Message-ID: 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 Subject: [MMUSIC] Another minor update for ICE: rel-addr privacy in relay candidates 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 Nov 2012 16:12:25 -0000 Hi, All -- I wanted to mention another minor issue with ICE. This was an issue Justin= Uberti raised back in February. Right now, relayed candidates must include the corresponding server-reflexi= ve address in their rel-addr field. I believe the motivation was so middle= boxes could give any special network treatment they needed between the NAT = and the TURN server. In privacy cases, however, where an endpoint is deliberately sending only r= elayed candidates to conceal its location, this is clearly terrible. The conclusion on the list at that time was to send 0.0.0.0:0, or equivalen= t, for the rel-addr in this case. This should presumably be recommended in= the ICE-bis draft. An alternative might be to omit rel-addr entirely in these cases, but stric= t 5245 parsers might fail if you did that. -- Jonathan Lennox jonathan@vidyo.com From internet-drafts@ietf.org Tue Nov 6 15:02:10 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A4D21F8BBF; Tue, 6 Nov 2012 15:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2poLgkS7IhF; Tue, 6 Nov 2012 15:02:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9F21F8BC3; Tue, 6 Nov 2012 15:02:09 -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.35 Message-ID: <20121106230209.2061.14535.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 15:02:09 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-24.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 Nov 2012 23:02:10 -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 Wor= king 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 Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-24.txt Pages : 33 Date : 2012-11-06 Abstract: 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 types and 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-24 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From martin.thomson@gmail.com Wed Nov 7 05:59: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 63D8521F88E9 for ; Wed, 7 Nov 2012 05:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csd+8i4V2AZO for ; Wed, 7 Nov 2012 05:59:43 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4321F8893 for ; Wed, 7 Nov 2012 05:59:42 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so1409674lbo.31 for ; Wed, 07 Nov 2012 05:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3+C2BGwdS4zv0mYGukS6TO1y/TDcldDWb/LMqA0jpqI=; b=dYRENGESTZBfF7uLzWJNcWNrpHSqEKg0W6iU8qYDwVYu9urNs7tqlcytE0RxH243IE SYp08JVgDpq4FfJhp8phQVHYF1yXMjAawk50QxAGqVzU3flI095ganxbH2CDzeHR5M4l dEC3ZDprvC//W1TkVz6gAZawqPTrBvl8wPha/2GzRUCKQ1KgYFIFDxA/db3WLfsmAx1b daQyV/vwbCgzwwWH2TLN5DfDWPAgHkff0kE0euDk+OZqm+Hd1qMakLDjPUTgM5+xL6HA MQFFTZRHPzmOpLSMT9BtqnP5M7C2bhqLPod6dRuhjSEWkZsLLiGZJVbdSlrAoCQJXvaj bh6w== MIME-Version: 1.0 Received: by 10.112.28.169 with SMTP id c9mr1912266lbh.59.1352296781420; Wed, 07 Nov 2012 05:59:41 -0800 (PST) Received: by 10.112.83.2 with HTTP; Wed, 7 Nov 2012 05:59:41 -0800 (PST) Date: Wed, 7 Nov 2012 08:59:41 -0500 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] Signaling trickle support 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 Nov 2012 13:59:43 -0000 Matthew, Justin and I were discussing the problem of signaling trickle ICE support and the following proposal was made: The 24th bit in SDP is currently set to zero. This bit is specifically reserved for forward compatibility purposes. We can use this bit. Set this bit to one to indicate support for trickle ICE. This meets the "works if supported, fails if it doesn't criteria". This solution may also be appropriate for bundle/mmt/whatever. From emil@sip-communicator.org Wed Nov 7 07:18: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 2B2F321F8B4C for ; Wed, 7 Nov 2012 07:18:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOLs7P1Nm9T1 for ; Wed, 7 Nov 2012 07:18:49 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5643321F8904 for ; Wed, 7 Nov 2012 07:18:49 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1336456pbb.31 for ; Wed, 07 Nov 2012 07:18:49 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=RphGnOT5RaGrY+9JEFR7suHteShkeVvzNE7gXhDJIGw=; b=ir7S4P833RHhdSXr/C/+Sbr2yfUs4/AQxD0H0sEFczmSyvnSMg33YmLEPa+gxMuNeb ptQnvvxxzFHd+adGkJ1NXkeMCz2GilfPM6wD+8UdP/Uzgc95wqSqaX04nfc8qGVdHMLw eam663ZkpAs56arc0umVzCeNg6g3MSqPEwXTxA3/nZ9cEbN+XPzc1qhLpbp26kK8VYNi tCMl+ln4nHQkGfySuqqtyJz/+00HNIyG4os30iSDo+N6gpsFP6Cxin8YRIrM3Xtgdzqh YrUY6miuKIhA3XWCKqLZWF5rr1hkKBVluhKheAMEj7V8eJ91MnGw/k9VLjp34hzNPsvl +oOg== Received: by 10.68.135.101 with SMTP id pr5mr14421058pbb.140.1352301529083; Wed, 07 Nov 2012 07:18:49 -0800 (PST) Received: from dhcp-9339.meeting.ietf.org (dhcp-9339.meeting.ietf.org. [130.129.11.57]) by mx.google.com with ESMTPS id b6sm14419904pav.33.2012.11.07.07.18.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 07:18:47 -0800 (PST) Message-ID: <509A7BD7.5020203@jitsi.org> Date: Wed, 07 Nov 2012 10:18:47 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Martin Thomson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk5vwaOsLh6HLhF4/2/P0BWPclXyz0BcRE4Lye0jvJjPjM5lcsMdr9HY+mYO2qCFY0cRKTK Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 15:18:50 -0000 Hey Martin, On 07.11.12, 08:59, Martin Thomson wrote: > Matthew, Justin and I were discussing the problem of signaling trickle > ICE support and the following proposal was made: > > The 24th bit in SDP is currently set to zero. This bit is > specifically reserved for forward compatibility purposes. We can use > this bit. Set this bit to one to indicate support for trickle ICE. bit 24? So, you mean setting the version to 1? Is that it? Could you please point us to the spec you have in mind? Emil -- https://jitsi.org From emil@sip-communicator.org Wed Nov 7 09:01: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 7041A21F8C34 for ; Wed, 7 Nov 2012 09:01:01 -0800 (PST) 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_63=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsywODdsoDoI for ; Wed, 7 Nov 2012 09:01:00 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D139921F8C30 for ; Wed, 7 Nov 2012 09:00:57 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so805833dan.31 for ; Wed, 07 Nov 2012 09:00:57 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=701irYdRoZl3RtIk3wXVkKd5vP+mmB5MkcuBoWCi/AY=; b=PbA47OtW2EodvumOACH2MQ6gYXnGDDYBc+/w/QP31NLdWZ93gfnwiqsiJKcmPJ4u9d nXdlcvKhEdl23981tKGxx1QOzrT+vmLpBDrtGxWxK9AYFgeh2/c7l+Yu/Fo/su28srn2 w5zAEhF7rzlM0Q8GKPhuYyqvEzmAmZ5i54/+s7KYZaRvSCbAV1RPBYTeI34xOQLRgvuP igLqYZwP4o/JNMlq1J7LomSF9z1xvRUiAwE/STnWch0+hAjeH65nqZ58oK3sxWC/dkvO yicSGYx7lsy517HkDm6nEqU535E++GS9Mo2PcPyarPOzwAt5GMvC5+ivVwlSr/nFzNfQ +2Tg== Received: by 10.66.77.74 with SMTP id q10mr13940686paw.81.1352307657619; Wed, 07 Nov 2012 09:00:57 -0800 (PST) Received: from dhcp-9339.meeting.ietf.org (dhcp-9339.meeting.ietf.org. [130.129.11.57]) by mx.google.com with ESMTPS id b6sm14542905pav.33.2012.11.07.09.00.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:00:56 -0800 (PST) Message-ID: <509A93C7.6070002@jitsi.org> Date: Wed, 07 Nov 2012 12:00:55 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Martin Thomson References: <509A7BD7.5020203@jitsi.org> In-Reply-To: <509A7BD7.5020203@jitsi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnrNH5KTlr66FKFblD96IV39R6/aD6PB/MOzoiLClalD3Ag4MlmDQab9dqTWH8U1J6tYvLB Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 17:01:01 -0000 On 07.11.12, 10:18, Emil Ivov wrote: > Hey Martin, > > On 07.11.12, 08:59, Martin Thomson wrote: >> Matthew, Justin and I were discussing the problem of signaling trickle >> ICE support and the following proposal was made: >> >> The 24th bit in SDP is currently set to zero. This bit is >> specifically reserved for forward compatibility purposes. We can use >> this bit. Set this bit to one to indicate support for trickle ICE. > > bit 24? So, you mean setting the version to 1? Is that it? OK, it appears (from our offline chat) that this is indeed what you meant. So, I couldn't find anything in 4566 or 3264 that says an offer MUST be rejected in the case where the version number is different from 0, but I might be missing some text (could you please point me to the right place if you have it?) That said I think it's a great idea and we should even take it further! For example we could give v=2 a meaning of bundle support. v=3 would then mean cundle. v=4 would of course be MMT. Then, v=5 would be trickle+bundle, v=6: trickle+cundle, v=7: trickle+mmt, v=8: bundle+mmt, v=9: cundle+mmt, v=10:trickle+bundle+mmt. And of course if we get a rejection for v=10, we would then be able to reissue three separate offers for v=1, v=2, and v=4 and this way we'll know exactly why the offer failed. Now all that's left is to put this into text and go for WGLC because it is crystal clear no one will have a problem with it ;) Emil -- https://jitsi.org From pkyzivat@alum.mit.edu Wed Nov 7 11:27: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 EA93921F8B96 for ; Wed, 7 Nov 2012 11:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8HWigxvFB1O for ; Wed, 7 Nov 2012 11:27:36 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 931E321F8B7A for ; Wed, 7 Nov 2012 11:27:36 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Ldgp1k0060QkzPwAFjTcov; Wed, 07 Nov 2012 19:27:36 +0000 Received: from dhcp-16c4.meeting.ietf.org ([IPv6:2001:df8:0:16:fc32:ae85:9fdc:8ea6]) by omta02.emeryville.ca.mail.comcast.net with comcast id LjTb1k0070Hux3C8NjTbUl; Wed, 07 Nov 2012 19:27:36 +0000 Message-ID: <509AB627.1090507@alum.mit.edu> Date: Wed, 07 Nov 2012 14:27:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 19:27:37 -0000 On 11/7/12 8:59 AM, Martin Thomson wrote: > Matthew, Justin and I were discussing the problem of signaling trickle > ICE support and the following proposal was made: > > The 24th bit in SDP is currently set to zero. This bit is > specifically reserved for forward compatibility purposes. We can use > this bit. Set this bit to one to indicate support for trickle ICE. > > This meets the "works if supported, fails if it doesn't criteria". > > This solution may also be appropriate for bundle/mmt/whatever. After some side discussion, I guess you are talking about bits in the value of the v= field ??? If so, I still have no idea what you are talking about. The syntax for the value of v= is 1*DIGIT. You can choose to represent that in binary and then choose bit 24 if you want, but that has no significance in 4566. Assigning a new SDP version to signal Trickle ICE support seems like an incredibly bad idea. Thanks, Paul From miguel.a.garcia@ericsson.com Wed Nov 7 23:30: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 E1BCF21F87AB for ; Wed, 7 Nov 2012 23:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqBbfwf+BbbH for ; Wed, 7 Nov 2012 23:30:21 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 340DA21F878C for ; Wed, 7 Nov 2012 23:30:18 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-db-509b5f89e57c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B3.81.11564.98F5B905; Thu, 8 Nov 2012 08:30:17 +0100 (CET) Received: from [159.107.105.22] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 8 Nov 2012 08:30:16 +0100 Message-ID: <509B5F87.1010807@ericsson.com> Date: Thu, 8 Nov 2012 08:30:15 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat , Martin Thomson , Emil Ivov References: <509AB627.1090507@alum.mit.edu> In-Reply-To: <509AB627.1090507@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+JvjW5n/OwAg+t3xC3W7JzAYnHtzD9G i6nLH7NYrNhwgNWBxePv+w9MHjtn3WX3WLLkJ5PH/zeBASxRXDYpqTmZZalF+nYJXBk3n+xm KWjgq1h38iVjA+MPri5GTg4JAROJvZceskPYYhIX7q1n62Lk4hASOMko0bvhEhOEs5pR4uHN RhaQKl4BbYlb3+4zdjFycLAIqEh8PugCEmYTMJdo3biRHSQsKhAsMecaP0S1oMTJmU/AOkUE SiWmXWpnBbGZBYQlLpw/zgRiCwvoS2yc/hesVUigQKLxqCJImFNAR+LI91nMEOW2EhfmXGeB sOUltr+dAxYXEtCUmHxzKfMERsFZSLbNQtIyC0nLAkbmVYzsuYmZOenlhpsYgUF7cMtv3R2M p86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExNagzo6lj4dPTyqd8 5zCq8/i9NY9nttkvpaty4SqLud5FhkzV9oZulgLdg5P8VQ07nm7+kVmU59u0X82JdfIHn8m3 lbU+ixxJKn7r03FD52z1rH696jsVG1+f+nn3p4nbM/VvqsVTEiWTHabNq8lvMDrfMYttjfP1 Nx89hNw6r8a6vTnn76DEUpyRaKjFXFScCABIFpbBKAIAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 07:30:22 -0000 As an individual... I concur with Paul, changing the v= version in the SDP is a very bad idea. Let met quote RFC 4566: The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. /Miguel On 07/11/2012 20:27, Paul Kyzivat wrote: > On 11/7/12 8:59 AM, Martin Thomson wrote: >> Matthew, Justin and I were discussing the problem of signaling trickle >> ICE support and the following proposal was made: >> >> The 24th bit in SDP is currently set to zero. This bit is >> specifically reserved for forward compatibility purposes. We can use >> this bit. Set this bit to one to indicate support for trickle ICE. >> >> This meets the "works if supported, fails if it doesn't criteria". >> >> This solution may also be appropriate for bundle/mmt/whatever. > > After some side discussion, I guess you are talking about bits in the > value of the v= field ??? > > If so, I still have no idea what you are talking about. The syntax for > the value of v= is 1*DIGIT. You can choose to represent that in binary > and then choose bit 24 if you want, but that has no significance in 4566. > > Assigning a new SDP version to signal Trickle ICE support seems like an > incredibly bad idea. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Thu Nov 8 06:23: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 C11D121F8B1C for ; Thu, 8 Nov 2012 06:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niy5wukvfref for ; Thu, 8 Nov 2012 06:23:21 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC6EE21F86AD for ; Thu, 8 Nov 2012 06:23:20 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-02-509bc0577add Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8B.DD.26143.750CB905; Thu, 8 Nov 2012 15:23:19 +0100 (CET) Received: from ESESSHC024.ericsson.se (153.88.183.90) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 15:23:19 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:23:18 +0100 From: Christer Holmberg To: Miguel Garcia A , Paul Kyzivat , Martin Thomson , Emil Ivov Thread-Topic: [MMUSIC] Signaling trickle support Thread-Index: AQHNvPAlxnRXHMZpMESqiCBifKq6VZfesT2AgADJ6YCAAIPUIA== Date: Thu, 8 Nov 2012 14:23:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> In-Reply-To: <509B5F87.1010807@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW74gdkBBl8P6Vis2TmBxeLamX+M FlOXP2axWLHhAKsDi8ff9x+YPHbOusvusWTJTyaP/28CA1iiuGxSUnMyy1KL9O0SuDI2bZrA XHBLsGL+wa8sDYwT+LoYOTkkBEwkeuecZIOwxSQu3FsPZHNxCAmcZJS4feoqC4Szg1Hi3J5G VghnMaPEgcWHmboYOTjYBCwkuv9pg8RFBJYwSpw8f54dJM4soC5xdXEQyFRhAX2JrbM3M4PY IgIGEt0vHkPZThIbnm9lArFZBFQkbh98DnYFr4C3RNPG1WA1QgKTGCW2Pw8DsTkFdCQu7lnB CGIzAl36/dQasF5mAXGJW0/mM0F8ICCxZM95ZghbVOLl43+sELaixMdX+xgh6nUkFuz+xAZh a0ssW/iaGWKvoMTJmU9YIPZqS7QsnsA+gVFiFpIVs5C0z0LSPgtJ+wJGllWM7LmJmTnp5Uab GIGxd3DLb9UdjHfOiRxilOZgURLntd66x19IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY+BS /ikBMTccud/7vdzd4OzexCxiy52dIbrb1Kn08wymaXJSEVX7XJ4/Kp/42jVyvn3Hgeky5zes fMF1/NepJf8PNjF2Z8z9dX3Z+bl1F/+kS17LEv+/qDY/mPViM7NOmem0Sp8Tc3kP139NNXrb xlWnc3djfOmljfOOm8nE7ApmMd0YIrfSVYmlOCPRUIu5qDgRAM9L0A2LAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 14:23:21 -0000 +1 Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Miguel A. Garcia Sent: 8. marraskuuta 2012 9:30 To: Paul Kyzivat; Martin Thomson; Emil Ivov Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Signaling trickle support As an individual... I concur with Paul, changing the v=3D version in the SDP is a very bad idea= . Let met quote RFC 4566: The "v=3D" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. This means that if you define another version different than zero, then, as= a side effect, you are creating a different version of SDP than the one sp= ecified in RFC 4566. So, you will need to create an RFC specifying how such= version of SDP works. /Miguel On 07/11/2012 20:27, Paul Kyzivat wrote: > On 11/7/12 8:59 AM, Martin Thomson wrote: >> Matthew, Justin and I were discussing the problem of signaling=20 >> trickle ICE support and the following proposal was made: >> >> The 24th bit in SDP is currently set to zero. This bit is=20 >> specifically reserved for forward compatibility purposes. We can use=20 >> this bit. Set this bit to one to indicate support for trickle ICE. >> >> This meets the "works if supported, fails if it doesn't criteria". >> >> This solution may also be appropriate for bundle/mmt/whatever. > > After some side discussion, I guess you are talking about bits in the=20 > value of the v=3D field ??? > > If so, I still have no idea what you are talking about. The syntax for=20 > the value of v=3D is 1*DIGIT. You can choose to represent that in binary= =20 > and then choose bit 24 if you want, but that has no significance in 4566. > > Assigning a new SDP version to signal Trickle ICE support seems like=20 > an incredibly bad idea. > > Thanks, > Paul > > _______________________________________________ > 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 keith.drage@alcatel-lucent.com Thu Nov 8 06:31:10 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDB521F8B56 for ; Thu, 8 Nov 2012 06:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.963 X-Spam-Level: X-Spam-Status: No, score=-109.963 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5FRM+mqdqvl for ; Thu, 8 Nov 2012 06:31:10 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B15A021F8438 for ; Thu, 8 Nov 2012 06:31:09 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8EV0Bd009301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 8 Nov 2012 15:31:05 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 8 Nov 2012 15:30:38 +0100 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Date: Thu, 8 Nov 2012 15:30:37 +0100 Thread-Topic: Comments on draft-ietf-mmusic-sdp-cs-13 Thread-Index: Ac29vZ71kMoO3AjiTZWJZmxC3uJsNw== Message-ID: 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 Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-cs-13 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 Nov 2012 14:31:10 -0000 Neither of these comments are much beyond editorial. Just discovered while = working through the document. 1) 5.6.3 of draft-ietf-mmusic-sdp-cs-13 contains the text: o Note that it if delivery of the Answer is delayed for some reason, the c= ircuit-switched call attempt may arrive at the Offerer before the Answer ha= s been processed. In this case, since the=09 correlation mechanisms are negotiated as part of the Offer/Answer=09 exchange, the Answerer cannot know whether or not the incoming=09 circuit-switched call attempt is correlated with the session being negotia= ted, the Offerer SHOULD answer the circuit-switched call=09 attempt only after it has received and processed the Answer.=09 Can we please not start a sentence that contains the condition for implemen= ting a normative requirement with the words "Note that". 2) Section 5.6 is the only part that indicates a dependence on SDP offer/an= swer as defined in RFC 3264. There are other normative parts of this docume= nt that are at least based on the prerequisite that RFC 3264 is being used.= The normative reference would appear to need to be more general. Does any = of this document have a life outside RFC 3264? Regards Keith =09 From fandreas@cisco.com Thu Nov 8 07: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 0CC8821F8B7E for ; Thu, 8 Nov 2012 07:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmKLtyU63yn9 for ; Thu, 8 Nov 2012 07:01:54 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 519BC21F8B79 for ; Thu, 8 Nov 2012 07:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2858; q=dns/txt; s=iport; t=1352386914; x=1353596514; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tTLc9JjW89Rp00VaIGU2YsRB/AwhmCamrUyGvXp8gBk=; b=AMW6u7JLiZG7EOAnieu2QnpZTEvfbzzFtWR9h6nKRCc/XaI4jD4Z0V4D d2g+KTp7Ic9o/8SN0Guv/DuduHBEtc08t24ahOXyR0q+FLFw2e+SAYDBs ti8GtJC9uDb2b80/9JRWSz0E9xJjUfjloQMunYAWyquNBlDbSaahxTUaF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADbJm1CrRDoJ/2dsb2JhbABEw2uBCIIeAQEBBAEBAQ8BJTYLDAQLEQQBAQEJHgcPAhYfCQgGAQwBBQIBARcHh2cMm3OgLwSMEoZHA4hajSGOWIFrgw0 X-IronPort-AV: E=Sophos;i="4.80,738,1344211200"; d="scan'208";a="63518623" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Nov 2012 15:01:29 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.254.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA8F1RDd025569; Thu, 8 Nov 2012 15:01:28 GMT Message-ID: <509BC947.709@cisco.com> Date: Thu, 08 Nov 2012 10:01:27 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Christer Holmberg , Martin Thomson References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 15:01:55 -0000 This is very different from the way we normally handle extensions in SDP both from a pure signaling and negotiation point of view. I share the sentiment of others that this does not look like a good idea but would like to understand if there were other considerations for suggesting this radically different approach. Thanks -- Flemming On 11/8/12 9:23 AM, Christer Holmberg wrote: > +1 > > Regards, > > Christer > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia > Sent: 8. marraskuuta 2012 9:30 > To: Paul Kyzivat; Martin Thomson; Emil Ivov > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Signaling trickle support > > As an individual... > > I concur with Paul, changing the v= version in the SDP is a very bad idea. > > Let met quote RFC 4566: > > > The "v=" field gives the version of the Session Description Protocol. > This memo defines version 0. There is no minor version number. > > > This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. > > /Miguel > > On 07/11/2012 20:27, Paul Kyzivat wrote: >> On 11/7/12 8:59 AM, Martin Thomson wrote: >>> Matthew, Justin and I were discussing the problem of signaling >>> trickle ICE support and the following proposal was made: >>> >>> The 24th bit in SDP is currently set to zero. This bit is >>> specifically reserved for forward compatibility purposes. We can use >>> this bit. Set this bit to one to indicate support for trickle ICE. >>> >>> This meets the "works if supported, fails if it doesn't criteria". >>> >>> This solution may also be appropriate for bundle/mmt/whatever. >> After some side discussion, I guess you are talking about bits in the >> value of the v= field ??? >> >> If so, I still have no idea what you are talking about. The syntax for >> the value of v= is 1*DIGIT. You can choose to represent that in binary >> and then choose bit 24 if you want, but that has no significance in 4566. >> >> Assigning a new SDP version to signal Trickle ICE support seems like >> an incredibly bad idea. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 > . > From emil@sip-communicator.org Thu Nov 8 07:13: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 4F37721F85A1 for ; Thu, 8 Nov 2012 07:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O42Ao5HQ5Pm2 for ; Thu, 8 Nov 2012 07:13:03 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4579921F85B2 for ; Thu, 8 Nov 2012 07:13:03 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2192716pad.31 for ; Thu, 08 Nov 2012 07:12:58 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=L5AGb0KrJCiTrkNPcLETecFmRcbNt2TZE9EIuWlMjyY=; b=XM57KKzvHWtcxqkEQ9+/WrbZDgXnFVb2yrMCuxlmSOdVJ2s7Q6RRCjef26WglZNFDT YT2ENNSnLCRaN1MbU750e11J28xaFJsidrQXMWyp4JIvMY3QO5/NE9ACmEaJDWDR8i5N u49JpQEHwwtHr3cZg447j7kmr8JwFNhoHCfREvYKKbeaA0GHAr4sIFctYvXRFKLgiNIb QC6uSWZ0MCYliRtiOVUbo/cJgg/5zZtppEZeIftKGR6Gjsdk9XZMh7peF18tqEnT4fVA GZQquuGmDoNpdmm1Ho9eacOCDW1kLU6zvQ1bbVB7A/MrnojePSVLWe0Uf0fXrbdZGfbc +aHw== Received: by 10.69.1.35 with SMTP id bd3mr10080593pbd.141.1352387578438; Thu, 08 Nov 2012 07:12:58 -0800 (PST) Received: from dhcp-9339.meeting.ietf.org ([2001:df8:0:8:81d2:7599:1e9e:8532]) by mx.google.com with ESMTPS id c8sm16272473pav.4.2012.11.08.07.12.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 07:12:57 -0800 (PST) Message-ID: <509BCBFB.2020305@jitsi.org> Date: Thu, 08 Nov 2012 10:12:59 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> In-Reply-To: <509BC947.709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn6V4tGhQ2zeSN3SDXx5t6Jw+9j+wxsf2A1FCaZIzTbzVkeh4ZBUVPuLmayfYJZp8W8dRB+ Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 15:13:04 -0000 I actually think this was supposed to be a joke. At least that's how I got it. Emil On 08.11.12, 10:01, Flemming Andreasen wrote: > This is very different from the way we normally handle extensions in SDP > both from a pure signaling and negotiation point of view. I share the > sentiment of others that this does not look like a good idea but would > like to understand if there were other considerations for suggesting > this radically different approach. > > Thanks > > -- Flemming > > On 11/8/12 9:23 AM, Christer Holmberg wrote: >> +1 >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >> Sent: 8. marraskuuta 2012 9:30 >> To: Paul Kyzivat; Martin Thomson; Emil Ivov >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Signaling trickle support >> >> As an individual... >> >> I concur with Paul, changing the v= version in the SDP is a very bad idea. >> >> Let met quote RFC 4566: >> >> >> The "v=" field gives the version of the Session Description Protocol. >> This memo defines version 0. There is no minor version number. >> >> >> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >> >> /Miguel >> >> On 07/11/2012 20:27, Paul Kyzivat wrote: >>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>> Matthew, Justin and I were discussing the problem of signaling >>>> trickle ICE support and the following proposal was made: >>>> >>>> The 24th bit in SDP is currently set to zero. This bit is >>>> specifically reserved for forward compatibility purposes. We can use >>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>> >>>> This meets the "works if supported, fails if it doesn't criteria". >>>> >>>> This solution may also be appropriate for bundle/mmt/whatever. >>> After some side discussion, I guess you are talking about bits in the >>> value of the v= field ??? >>> >>> If so, I still have no idea what you are talking about. The syntax for >>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>> and then choose bit 24 if you want, but that has no significance in 4566. >>> >>> Assigning a new SDP version to signal Trickle ICE support seems like >>> an incredibly bad idea. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> 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 >> . >> > > -- https://jitsi.org From martin.thomson@gmail.com Thu Nov 8 07:46: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 33AFC21F899B for ; Thu, 8 Nov 2012 07:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.896 X-Spam-Level: X-Spam-Status: No, score=-3.896 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaX2bJ9X8smt for ; Thu, 8 Nov 2012 07:46:50 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62821F894E for ; Thu, 8 Nov 2012 07:46:50 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2487496lbo.31 for ; Thu, 08 Nov 2012 07:46:49 -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=4/PEXG6yzprfJmlfI05O89PyC4qQ3YTWCJuuLZUQ1d0=; b=j2Vk24DmJyN5DZQmGh0Xgq6P46NPbLyptUM/Gk9ixfu2tDNmj5/bXt6IENkJLuZ10C lc2jcMrJvZwwQIGRk1Qn1jpfYplYkr7zG2WQMPDCyp0CobDhoOE1HZ9vMzM/ArgGHi0S 7fRaV6wmHeMRX+PsSIlyIDG2lHxnS0Rrsf3Te73XVbtZlfe+ryh+7XCKQbjKMmsTHast xXQ0cKEPEPnjgKKeOSgbHuBqp0XaJ1CRyTc0Bq1VsnA51wPD/NlxyVpt73m1PO6m6S8x VTIanRendfGaYg1zInrLomH0YqEb8UrGVh6AboFQ7gdl/hFqYvRpWSV+Fnpz+uay87fR cTYQ== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr7939693lab.30.1352389609452; Thu, 08 Nov 2012 07:46:49 -0800 (PST) Received: by 10.112.83.2 with HTTP; Thu, 8 Nov 2012 07:46:49 -0800 (PST) In-Reply-To: <509BCBFB.2020305@jitsi.org> References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> Date: Thu, 8 Nov 2012 10:46:49 -0500 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: Flemming Andreasen , "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 15:46:52 -0000 Trolled. Though to be honest, I don't see a way around this particular problem. The idea of using a Require: trickle header is fraught with problems; the idea that you might use an a= line doesn't give you the characteristics you desire. I just don't know how to cause the failure that is needed when this isn't supported. Besides, the failure modes all lead to an expenditure of time that is worse than the simple candidate gathering scenarios (reflexive, relay), though not "other" gathering methods (UPnP, etc...). half-trickle is a reasonable solution. On 8 November 2012 10:12, Emil Ivov wrote: > I actually think this was supposed to be a joke. At least that's how I > got it. > > Emil > > On 08.11.12, 10:01, Flemming Andreasen wrote: >> This is very different from the way we normally handle extensions in SDP >> both from a pure signaling and negotiation point of view. I share the >> sentiment of others that this does not look like a good idea but would >> like to understand if there were other considerations for suggesting >> this radically different approach. >> >> Thanks >> >> -- Flemming >> >> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>> +1 >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>> Sent: 8. marraskuuta 2012 9:30 >>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>> Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] Signaling trickle support >>> >>> As an individual... >>> >>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>> >>> Let met quote RFC 4566: >>> >>> >>> The "v=" field gives the version of the Session Description Protocol. >>> This memo defines version 0. There is no minor version number. >>> >>> >>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>> >>> /Miguel >>> >>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>> Matthew, Justin and I were discussing the problem of signaling >>>>> trickle ICE support and the following proposal was made: >>>>> >>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>> specifically reserved for forward compatibility purposes. We can use >>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>> >>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>> >>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>> After some side discussion, I guess you are talking about bits in the >>>> value of the v= field ??? >>>> >>>> If so, I still have no idea what you are talking about. The syntax for >>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>> >>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>> an incredibly bad idea. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> 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 >>> . >>> >> >> > > -- > https://jitsi.org From fandreas@cisco.com Thu Nov 8 07:53:10 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916DE21F8786 for ; Thu, 8 Nov 2012 07:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBnBr8OI4gPq for ; Thu, 8 Nov 2012 07:53:09 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C686C21F8595 for ; Thu, 8 Nov 2012 07:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4205; q=dns/txt; s=iport; t=1352389989; x=1353599589; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EP4LFJowG766imXH3kwagNaWPnqlP/oZo6C0R50fqLI=; b=BJCWwVMJhNHQPQt4eRSSQemTFBCuxSvyzeqykQQhluupvqYJOVcJhGia eekmVqWvZFpzD+YN+PaeYtsiIWoVmCcxfLLbCCqlGY794OCOKOmDBUsDD ls6gnbARJQIUxes3r5aThOHfy9WWdrSXspsEN7SMzxTdMF38yjaB31VZz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGHUm1CrRDoG/2dsb2JhbABEhhi9U4EIgh4BAQEDAQEBAQ8BEBU2CgEFBwQLEQQBAQECAgUWCAMCAgkDAgECARUfCQgGDQEFAgEBFweHYgUMm3CNJZMKBIEginKFNIETA4hajSGOWIFrgw0 X-IronPort-AV: E=Sophos;i="4.80,738,1344211200"; d="scan'208";a="60416013" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 08 Nov 2012 15:53:09 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.254.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA8Fr7vv008978; Thu, 8 Nov 2012 15:53:08 GMT Message-ID: <509BD563.9080808@cisco.com> Date: Thu, 08 Nov 2012 10:53:07 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Martin Thomson References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 15:53:10 -0000 On 11/8/12 10:46 AM, Martin Thomson wrote: > Trolled. > > Though to be honest, I don't see a way around this particular problem. > The idea of using a Require: trickle header is fraught with problems; > the idea that you might use an a= line doesn't give you the > characteristics you desire. I just don't know how to cause the > failure that is needed when this isn't supported. Can we capture the desired characteristics and failure mode for starters ? > Besides, the failure modes all lead to an expenditure of time that is > worse than the simple candidate gathering scenarios (reflexive, > relay), though not "other" gathering methods (UPnP, etc...). Is there a requirement here that needs to be written down ? > half-trickle is a reasonable solution. Sorry - what's half-trickle ? -- Flemming > On 8 November 2012 10:12, Emil Ivov wrote: >> I actually think this was supposed to be a joke. At least that's how I >> got it. >> >> Emil >> >> On 08.11.12, 10:01, Flemming Andreasen wrote: >>> This is very different from the way we normally handle extensions in SDP >>> both from a pure signaling and negotiation point of view. I share the >>> sentiment of others that this does not look like a good idea but would >>> like to understand if there were other considerations for suggesting >>> this radically different approach. >>> >>> Thanks >>> >>> -- Flemming >>> >>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>> +1 >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>>> Sent: 8. marraskuuta 2012 9:30 >>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>> Cc: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Signaling trickle support >>>> >>>> As an individual... >>>> >>>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>>> >>>> Let met quote RFC 4566: >>>> >>>> >>>> The "v=" field gives the version of the Session Description Protocol. >>>> This memo defines version 0. There is no minor version number. >>>> >>>> >>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>>> >>>> /Miguel >>>> >>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>> trickle ICE support and the following proposal was made: >>>>>> >>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>> specifically reserved for forward compatibility purposes. We can use >>>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>>> >>>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>>> >>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>> After some side discussion, I guess you are talking about bits in the >>>>> value of the v= field ??? >>>>> >>>>> If so, I still have no idea what you are talking about. The syntax for >>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>>> >>>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>>> an incredibly bad idea. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> . >>>> >>> >> -- >> https://jitsi.org > . > From emil@sip-communicator.org Thu Nov 8 08:29: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 18DAB21F8460 for ; Thu, 8 Nov 2012 08:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqtUhy5cnwLR for ; Thu, 8 Nov 2012 08:29:58 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2403821F8459 for ; Thu, 8 Nov 2012 08:29:55 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2289802pbb.31 for ; Thu, 08 Nov 2012 08:29:54 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=nNT+F9jpt19r+9sA9IvxCsG6n/P2vxJVa+39Y6o+8zQ=; b=SQimkmOUQVGqgl97F7PzfRWD9R5Xd/BoanZArPClVyiZdiQhoNRTLr2S3/NueT+R7t eIHPTQD21W8FA2S08Xg5KunputSvOFu03EVmXYcPaT0+fuCbEr9GEICRlVUxAiU1hiQC qJsIlc9NsrKXyP4xvxRSmGCOw6MHttzEIG76AOYROk16b/EzUZHwxP1NWIhersk0fAKp kyhCnZ3Ij/wUSDa2GPNKXCFwjoQkJyzlkCiISu/y6By4bn4ewRMu7ctScg2Ue/zoND6C aGSPf/e/hBF09ruPjHfnb0nIf+EEzvHX9AELDYJoaaNNGlVYp2iH76nlEJkQ0g3J2xWv O76w== Received: by 10.66.87.132 with SMTP id ay4mr23480102pab.67.1352392194840; Thu, 08 Nov 2012 08:29:54 -0800 (PST) Received: from dhcp-9339.meeting.ietf.org ([2001:df8:0:8:81d2:7599:1e9e:8532]) by mx.google.com with ESMTPS id o11sm16174724pby.8.2012.11.08.08.29.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:29:51 -0800 (PST) Message-ID: <509BDE01.9060705@jitsi.org> Date: Thu, 08 Nov 2012 11:29:53 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> In-Reply-To: <509BD563.9080808@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnIYO9a+h3jXWT7ovklUYGoLeyFdvr/L98UHJxBbXRo9gFvuUFyn51jFWAdYyW0BDyoJgEf Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 16:29:59 -0000 Hey Flemming, On 08.11.12, 10:53, Flemming Andreasen wrote: > > On 11/8/12 10:46 AM, Martin Thomson wrote: >> Trolled. >> >> Though to be honest, I don't see a way around this particular problem. >> The idea of using a Require: trickle header is fraught with problems; >> the idea that you might use an a= line doesn't give you the >> characteristics you desire. I just don't know how to cause the >> failure that is needed when this isn't supported. > Can we capture the desired characteristics and failure mode for starters ? The "really" desired characteristic is knowing in advance whether or not the remote party can do trickle so that you know whether you can afford to send an empty offer without causing it to freak out. Since protocols like SIP don't really have things like XMPP disco and Cap Neg that would have allowed it, we were considering other options. One such option would be to send a trickle offer and format it in a way that would cause a non-trickle answerer to reject it in a _predictable_ way. This would allow the offerer to retry with a regular ICE offer. >> Besides, the failure modes all lead to an expenditure of time that is >> worse than the simple candidate gathering scenarios (reflexive, >> relay), though not "other" gathering methods (UPnP, etc...). > Is there a requirement here that needs to be written down ? The point that Martin is making is that sending an offer and then waiting for the failure may potentially take longer than just gathering your candidates. This is true especially in cases where the offerer is only planning on using a single port, on a single interface, with a single STUN/TURN server and no other candidate gathering mechanisms. But then, if this really is the case, the offerer knows it and can choose not to do the probing. >> half-trickle is a reasonable solution. > Sorry - what's half-trickle ? We had that in the slides on Tuesday but it's not yet in the draft. The idea is that if you can't confirm support for trickle in the answerer, you just send a vanilla ICE offer and you also indicate you do support trickle. A trickle ICE answerer can then trickle candidates and in general you get half the optimizations of Trickle ICE. You even get more than that in case the offerer is able to predictively gather candidates before the call is initiated. We'll describe this in the next version. Cheers, Emil > > -- Flemming > > >> On 8 November 2012 10:12, Emil Ivov wrote: >>> I actually think this was supposed to be a joke. At least that's how I >>> got it. >>> >>> Emil >>> >>> On 08.11.12, 10:01, Flemming Andreasen wrote: >>>> This is very different from the way we normally handle extensions in SDP >>>> both from a pure signaling and negotiation point of view. I share the >>>> sentiment of others that this does not look like a good idea but would >>>> like to understand if there were other considerations for suggesting >>>> this radically different approach. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>>> +1 >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>>>> Sent: 8. marraskuuta 2012 9:30 >>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>>> Cc: mmusic@ietf.org >>>>> Subject: Re: [MMUSIC] Signaling trickle support >>>>> >>>>> As an individual... >>>>> >>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>>>> >>>>> Let met quote RFC 4566: >>>>> >>>>> >>>>> The "v=" field gives the version of the Session Description Protocol. >>>>> This memo defines version 0. There is no minor version number. >>>>> >>>>> >>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>>>> >>>>> /Miguel >>>>> >>>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>>> trickle ICE support and the following proposal was made: >>>>>>> >>>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>>> specifically reserved for forward compatibility purposes. We can use >>>>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>>>> >>>>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>>>> >>>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>>> After some side discussion, I guess you are talking about bits in the >>>>>> value of the v= field ??? >>>>>> >>>>>> If so, I still have no idea what you are talking about. The syntax for >>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>>>> >>>>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>>>> an incredibly bad idea. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> . >>>>> >>>> >>> -- >>> https://jitsi.org >> . >> > > -- https://jitsi.org From fandreas@cisco.com Thu Nov 8 11:07: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 75B9D21F880F for ; Thu, 8 Nov 2012 11:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvbJk3MMeUSR for ; Thu, 8 Nov 2012 11:07:33 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1F921F8878 for ; Thu, 8 Nov 2012 11:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6639; q=dns/txt; s=iport; t=1352401653; x=1353611253; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0BUHFXk3RatFgEG8gcrAphDV3g3aMugy4ZMv/xcWhHE=; b=ESNnI9MKJRV3+Zm6cWUXC7FFimP0qCx/zy+Q7mdXQlsw8+2yk1667kR6 Y6TZrD35F7Kc27aN/DucLdGnC4/ia9GjEDvuEa0YlBhhmSPLfTGKFIEc2 qM1x3n3lpm4364TlC/0SLigrNrfxygkgeSgWEc90q6O9gNO/uMcoIFvWs g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD4CnFCrRDoH/2dsb2JhbABEhhi9RIEIgh4BAQEDAQEBAQ8BEBU2CwUHBAsOAwQBAQECAgUeAwICDwIWHwkIBg0BBQIBARcHh2IFDJtzjSWTDQSBIIpyhTSBEwOIWo0hjliBa4MN X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208";a="60955783" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 08 Nov 2012 19:07:33 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.254.144]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA8J7VpZ010219; Thu, 8 Nov 2012 19:07:31 GMT Message-ID: <509C02F2.10303@cisco.com> Date: Thu, 08 Nov 2012 14:07:30 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Emil Ivov References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> In-Reply-To: <509BDE01.9060705@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 19:07:34 -0000 On 11/8/12 11:29 AM, Emil Ivov wrote: > Hey Flemming, > > On 08.11.12, 10:53, Flemming Andreasen wrote: >> On 11/8/12 10:46 AM, Martin Thomson wrote: >>> Trolled. >>> >>> Though to be honest, I don't see a way around this particular problem. >>> The idea of using a Require: trickle header is fraught with problems; >>> the idea that you might use an a= line doesn't give you the >>> characteristics you desire. I just don't know how to cause the >>> failure that is needed when this isn't supported. >> Can we capture the desired characteristics and failure mode for starters ? > The "really" desired characteristic is knowing in advance whether or not > the remote party can do trickle so that you know whether you can afford > to send an empty offer without causing it to freak out. Why would you send an empty offer ? > Since protocols like SIP don't really have things like XMPP disco and > Cap Neg that would have allowed it, we were considering other options. > One such option would be to send a trickle offer and format it in a way > that would cause a non-trickle answerer to reject it in a _predictable_ > way. This would allow the offerer to retry with a regular ICE offer. I thought the point with trickle-ICE was to reduce call setup latency and hence you would want to make sure that things complete in as few round-trips as possible. This doesn't seem to line up with that (?). > >>> Besides, the failure modes all lead to an expenditure of time that is >>> worse than the simple candidate gathering scenarios (reflexive, >>> relay), though not "other" gathering methods (UPnP, etc...). >> Is there a requirement here that needs to be written down ? > The point that Martin is making is that sending an offer and then > waiting for the failure may potentially take longer than just gathering > your candidates. This is true especially in cases where the offerer is > only planning on using a single port, on a single interface, with a > single STUN/TURN server and no other candidate gathering mechanisms. I would agree with that. > > But then, if this really is the case, the offerer knows it and can > choose not to do the probing. Agreed. >>> half-trickle is a reasonable solution. >> Sorry - what's half-trickle ? > We had that in the slides on Tuesday but it's not yet in the draft. The > idea is that if you can't confirm support for trickle in the answerer, Do you mean: if you don't know if the answerer supports it before sending an offer to him [since confirming support in the answer should be easy] ? > you just send a vanilla ICE offer and you also indicate you do support > trickle. A trickle ICE answerer can then trickle candidates and in > general you get half the optimizations of Trickle ICE. You even get more > than that in case the offerer is able to predictively gather candidates > before the call is initiated. Agreed. > > We'll describe this in the next version. Ok - thanks for the explanation. -- Flemming > > Cheers, > Emil > >> -- Flemming >> >> >>> On 8 November 2012 10:12, Emil Ivov wrote: >>>> I actually think this was supposed to be a joke. At least that's how I >>>> got it. >>>> >>>> Emil >>>> >>>> On 08.11.12, 10:01, Flemming Andreasen wrote: >>>>> This is very different from the way we normally handle extensions in SDP >>>>> both from a pure signaling and negotiation point of view. I share the >>>>> sentiment of others that this does not look like a good idea but would >>>>> like to understand if there were other considerations for suggesting >>>>> this radically different approach. >>>>> >>>>> Thanks >>>>> >>>>> -- Flemming >>>>> >>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>>>> +1 >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> -----Original Message----- >>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>>>>> Sent: 8. marraskuuta 2012 9:30 >>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>>>> Cc: mmusic@ietf.org >>>>>> Subject: Re: [MMUSIC] Signaling trickle support >>>>>> >>>>>> As an individual... >>>>>> >>>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>>>>> >>>>>> Let met quote RFC 4566: >>>>>> >>>>>> >>>>>> The "v=" field gives the version of the Session Description Protocol. >>>>>> This memo defines version 0. There is no minor version number. >>>>>> >>>>>> >>>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>>>>> >>>>>> /Miguel >>>>>> >>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>>>> trickle ICE support and the following proposal was made: >>>>>>>> >>>>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>>>> specifically reserved for forward compatibility purposes. We can use >>>>>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>>>>> >>>>>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>>>>> >>>>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>>>> After some side discussion, I guess you are talking about bits in the >>>>>>> value of the v= field ??? >>>>>>> >>>>>>> If so, I still have no idea what you are talking about. The syntax for >>>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>>>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>>>>> >>>>>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>>>>> an incredibly bad idea. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> . >>>>>> >>>> -- >>>> https://jitsi.org >>> . >>> >> From emil@sip-communicator.org Thu Nov 8 11:25: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 4A6D521F8533 for ; Thu, 8 Nov 2012 11:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2FJq9O3KEnO for ; Thu, 8 Nov 2012 11:25:25 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3289521F84C4 for ; Thu, 8 Nov 2012 11:25:25 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2365915pad.31 for ; Thu, 08 Nov 2012 11:25:25 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=HEr6bPbQi0hK3uVUGjpJlXEvCdmA2BOjr42RU5yYCFY=; b=J7zCz5WDhuzq5h3ldj3M0nGKKBXZ5SKPyFuihHFXcq8MdwDF9VuUhuDJtkeotS5u+F VR0HiG4kkRnZAbWANkkEzUqV0WjA6ldaK4Ew4WhdEjaI15zQ4mQlL3/YEC0cdBRcZVbO I87OnYX4rA5y11hWcTTExLyB1RSYk1/GfhRl+b3nW7RRtmUmFlfh9uN3BoZxU3K82T8W 0dViJReVbHClT4IMYqis4QAJCISIjn8LB3vlI/qnWhz6sQ5Ppv4v4KY3594Dvh1lsKm1 h5TzJRaU6zCs0ekqA9rdGNbxub7WWR6ReTbCva/3sc58E7ipTgMK0eA0Uc00P+/yfd6n LbDQ== Received: by 10.66.76.162 with SMTP id l2mr24931506paw.36.1352402724897; Thu, 08 Nov 2012 11:25:24 -0800 (PST) Received: from dhcp-4225.meeting.ietf.org ([2001:df8:0:64:15d2:1438:5e06:e012]) by mx.google.com with ESMTPS id n7sm16559752pav.26.2012.11.08.11.25.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 11:25:23 -0800 (PST) Message-ID: <509C0724.3050300@jitsi.org> Date: Thu, 08 Nov 2012 14:25:24 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> In-Reply-To: <509C02F2.10303@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmaxUg6r9DEj+C75AvfUv6yFblnodQ+HBU1o11WOjkQ1rSuS/+wKaDf1ZnIhAcsNOWVgRAc Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 19:25:26 -0000 Hey Flemming, On 08.11.12, 14:07, Flemming Andreasen wrote: > > On 11/8/12 11:29 AM, Emil Ivov wrote: >> Hey Flemming, >> >> On 08.11.12, 10:53, Flemming Andreasen wrote: >>> On 11/8/12 10:46 AM, Martin Thomson wrote: >>>> Trolled. >>>> >>>> Though to be honest, I don't see a way around this particular problem. >>>> The idea of using a Require: trickle header is fraught with problems; >>>> the idea that you might use an a= line doesn't give you the >>>> characteristics you desire. I just don't know how to cause the >>>> failure that is needed when this isn't supported. >>> Can we capture the desired characteristics and failure mode for starters ? >> The "really" desired characteristic is knowing in advance whether or not >> the remote party can do trickle so that you know whether you can afford >> to send an empty offer without causing it to freak out. > Why would you send an empty offer ? Normally the offer should contain only candidates that are readily available (such as host candidates). However if the offerer does not wish to disclose those for privacy reasons, then it would just send an offer with no candidates. This is for example how Chrome currently behaves. It also places 0.0.0.0:1 in the c= and m= lines. That's currently explain in section 4 of the draft: http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4 >> Since protocols like SIP don't really have things like XMPP disco and >> Cap Neg that would have allowed it, we were considering other options. >> One such option would be to send a trickle offer and format it in a way >> that would cause a non-trickle answerer to reject it in a _predictable_ >> way. This would allow the offerer to retry with a regular ICE offer. > I thought the point with trickle-ICE was to reduce call setup latency It is. > and hence you would want to make sure that things complete in as few > round-trips as possible. This doesn't seem to line up with that (?). The thing is that in cases where trickle ICE support cannot be pre-confirmed you have to fall back to half trickle. The probing requests would hence allow for an optimisation compared to that. With half-trickle the offerer has to gather all candidates anyway so, while doing so, they might as well try and check if they really need to complete it before sending their first offer. >>>> Besides, the failure modes all lead to an expenditure of time that is >>>> worse than the simple candidate gathering scenarios (reflexive, >>>> relay), though not "other" gathering methods (UPnP, etc...). >>> Is there a requirement here that needs to be written down ? >> The point that Martin is making is that sending an offer and then >> waiting for the failure may potentially take longer than just gathering >> your candidates. This is true especially in cases where the offerer is >> only planning on using a single port, on a single interface, with a >> single STUN/TURN server and no other candidate gathering mechanisms. > I would agree with that. >> >> But then, if this really is the case, the offerer knows it and can >> choose not to do the probing. > Agreed. >>>> half-trickle is a reasonable solution. >>> Sorry - what's half-trickle ? >> We had that in the slides on Tuesday but it's not yet in the draft. The >> idea is that if you can't confirm support for trickle in the answerer, > Do you mean: if you don't know if the answerer supports it before > sending an offer to him Yes. That's what I meant. The offerer needs to know that in advance in order to decide how to form their offer. Cheers, Emil > [since confirming support in the answer should > be easy] ? >> you just send a vanilla ICE offer and you also indicate you do support >> trickle. A trickle ICE answerer can then trickle candidates and in >> general you get half the optimizations of Trickle ICE. You even get more >> than that in case the offerer is able to predictively gather candidates >> before the call is initiated. > Agreed. >> >> We'll describe this in the next version. > Ok - thanks for the explanation. > > -- Flemming >> >> Cheers, >> Emil >> >>> -- Flemming >>> >>> >>>> On 8 November 2012 10:12, Emil Ivov wrote: >>>>> I actually think this was supposed to be a joke. At least that's how I >>>>> got it. >>>>> >>>>> Emil >>>>> >>>>> On 08.11.12, 10:01, Flemming Andreasen wrote: >>>>>> This is very different from the way we normally handle extensions in SDP >>>>>> both from a pure signaling and negotiation point of view. I share the >>>>>> sentiment of others that this does not look like a good idea but would >>>>>> like to understand if there were other considerations for suggesting >>>>>> this radically different approach. >>>>>> >>>>>> Thanks >>>>>> >>>>>> -- Flemming >>>>>> >>>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>>>>> +1 >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>>>>>> Sent: 8. marraskuuta 2012 9:30 >>>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>>>>> Cc: mmusic@ietf.org >>>>>>> Subject: Re: [MMUSIC] Signaling trickle support >>>>>>> >>>>>>> As an individual... >>>>>>> >>>>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>>>>>> >>>>>>> Let met quote RFC 4566: >>>>>>> >>>>>>> >>>>>>> The "v=" field gives the version of the Session Description Protocol. >>>>>>> This memo defines version 0. There is no minor version number. >>>>>>> >>>>>>> >>>>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>>>>>> >>>>>>> /Miguel >>>>>>> >>>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>>>>> trickle ICE support and the following proposal was made: >>>>>>>>> >>>>>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>>>>> specifically reserved for forward compatibility purposes. We can use >>>>>>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>>>>>> >>>>>>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>>>>>> >>>>>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>>>>> After some side discussion, I guess you are talking about bits in the >>>>>>>> value of the v= field ??? >>>>>>>> >>>>>>>> If so, I still have no idea what you are talking about. The syntax for >>>>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>>>>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>>>>>> >>>>>>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>>>>>> an incredibly bad idea. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> . >>>>>>> >>>>> -- >>>>> https://jitsi.org >>>> . >>>> >>> > > -- https://jitsi.org From btv1==659fe4ddd09==HKaplan@acmepacket.com Thu Nov 8 11:34: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 5D4D521F86D3 for ; Thu, 8 Nov 2012 11:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oe1q6aSbu+W for ; Thu, 8 Nov 2012 11:34:35 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id C084A21F8453 for ; Thu, 8 Nov 2012 11:34:35 -0800 (PST) X-ASG-Debug-ID: 1352403274-03fc201610aae00001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id eCcVmMJK5hFavQIX (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Nov 2012 14:34:34 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 14:34:34 -0500 From: Hadriel Kaplan To: Emil Ivov Thread-Topic: [MMUSIC] Signaling trickle support X-ASG-Orig-Subj: Re: [MMUSIC] Signaling trickle support Thread-Index: AQHNvegUkYrAQCO5bEGeQueiE/rh2w== Date: Thu, 8 Nov 2012 19:34:33 +0000 Message-ID: References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> In-Reply-To: <509C0724.3050300@jitsi.org> 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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352403274 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113659 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Flemming Andreasen , "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 19:34:36 -0000 On Nov 8, 2012, at 2:25 PM, Emil Ivov wrote: > Hey Flemming, >=20 > On 08.11.12, 14:07, Flemming Andreasen wrote: >>>=20 >> Why would you send an empty offer ? >=20 > Normally the offer should contain only candidates that are readily > available (such as host candidates). However if the offerer does not > wish to disclose those for privacy reasons, then it would just send an > offer with no candidates. This is for example how Chrome currently behave= s. >=20 > It also places 0.0.0.0:1 in the c=3D and m=3D lines. >=20 > That's currently explain in section 4 of the draft: >=20 > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4 >=20 For SIP, why not just send an offerless INVITE? (it might even work sometim= es ;) Likewise for RTCWeb, send a request for a session without SDP whatsoever, a= nd make the other side send an offer first (and write your JS to support th= at case). -hadriel From emil@sip-communicator.org Thu Nov 8 11:48:19 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 B700A21F8AED for ; Thu, 8 Nov 2012 11:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-elo8Iy8o6K for ; Thu, 8 Nov 2012 11:48:19 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B581921F88A0 for ; Thu, 8 Nov 2012 11:48:18 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2421985pbb.31 for ; Thu, 08 Nov 2012 11:48:18 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=KgyDCpyhUJ+/jEj6OEFR9JhBClEap4y/TurtzfhTs5s=; b=ThBcR702Yx0RRK+4tfW5R0yzJuOzBIECcBC13Fw8Z8nlNXbApi5NcYGTqKYYvHvP1z bEpM2xigLdyFa8ImUNP8o8Fh7Vg7vM1FwZ6fW85cc+qilwEFaMcWt1/ZD2I/FTOFPrYp f37vuERdg3cuVyjSadkdbLSYtmR8Q0Oe5oKXKKqcc8ad0kLx0/tKZ+2Odae7r2m6KG2c mVekuw5EMbFYbINEcWYtc2Xam+NchN1z6L3M0ivVLdpnSopdiXIk/JXSaygJjt6zf845 K6oLWiPUzFAV7FL4/P+EcXQaKWDMujOSiid2WpUgBhq+NYsWvnEgKfx99II2Gg6XOV95 gBsg== Received: by 10.66.86.165 with SMTP id q5mr18924180paz.18.1352404098556; Thu, 08 Nov 2012 11:48:18 -0800 (PST) Received: from dhcp-4225.meeting.ietf.org (dhcp-4225.meeting.ietf.org. [130.129.66.37]) by mx.google.com with ESMTPS id qt3sm13873793pbb.32.2012.11.08.11.48.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 11:48:17 -0800 (PST) Message-ID: <509C0C82.5080200@jitsi.org> Date: Thu, 08 Nov 2012 14:48:18 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl/pwzhrC0uYTm5NgYSagBbo/1gGGjF7rbiuNG+9RyUKuPhfe4nPeE7Ee/Amss/wGreR5iD Cc: Flemming Andreasen , "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 19:48:19 -0000 Hey Hadriel, On 08.11.12, 14:34, Hadriel Kaplan wrote: > > > On Nov 8, 2012, at 2:25 PM, Emil Ivov wrote: > >> Hey Flemming, >> >> On 08.11.12, 14:07, Flemming Andreasen wrote: >>>> >>> Why would you send an empty offer ? >> >> Normally the offer should contain only candidates that are readily >> available (such as host candidates). However if the offerer does not >> wish to disclose those for privacy reasons, then it would just send an >> offer with no candidates. This is for example how Chrome currently behaves. >> >> It also places 0.0.0.0:1 in the c= and m= lines. >> >> That's currently explain in section 4 of the draft: >> >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4 >> > > For SIP, why not just send an offerless INVITE? (it might even work sometimes ;) > > Likewise for RTCWeb, send a request for a session without SDP whatsoever, and make the other side send an offer first (and write your JS to support that case). I was thinking along those lines at one point too: http://www.ietf.org/mail-archive/web/mmusic/current/msg09681.html Christer made a comment that this would work badly with legacy: http://www.ietf.org/mail-archive/web/mmusic/current/msg09698.html And besides, that would also prevent you from letting the offerer (and the calling user) choose what kind of call/content they'd like to have (i.e. audio or video or a conference or a slide show, etc). Cheers, Emil -- https://jitsi.org From fandreas@cisco.com Thu Nov 8 14:21:31 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 8942421F85A1 for ; Thu, 8 Nov 2012 14:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Yvykgm5ZCoN for ; Thu, 8 Nov 2012 14:21:30 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E531321F853B for ; Thu, 8 Nov 2012 14:21:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8574; q=dns/txt; s=iport; t=1352413290; x=1353622890; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OIPgI5qimyFoyc+BIuZ1Y+i746t2zKJ8PMjg8y0USxU=; b=cxioAX5A8NLA/lwvtH9iTcEk8yXAsvsQIuY9uKKZ3AWOVVd1eI8XXT/9 xQgEoWdReymcroIH7MBUG1xqZSM2PZbPZWaqCiCPqqny68aoBGWQAep2r j/EgubhQafmfveItiw3kqYDTE4qnKaCK14hWLSuF8H/xNwEsDK8GRZ75Q 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADQwnFCQ/khM/2dsb2JhbABEhhi9K4EIgh4BAQEDAQEBAQ8BEBU2CgEFBwQLDgMEAQEBAgIFFggDAgIJAwIBAgEVHwkIBg0BBQIBARcHh2IGC5wkjSWTAIEginKFNIETA4haiW+DMoEcjTyBa4MN X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="9436343" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 08 Nov 2012 22:21:28 +0000 Received: from dhcp-407c.meeting.ietf.org ([10.86.246.202]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8MLRn1019365; Thu, 8 Nov 2012 22:21:27 GMT Message-ID: <509C3066.6020209@cisco.com> Date: Thu, 08 Nov 2012 17:21:26 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Emil Ivov References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> In-Reply-To: <509C0724.3050300@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 22:21:31 -0000 On 11/8/12 2:25 PM, Emil Ivov wrote: > Hey Flemming, > > On 08.11.12, 14:07, Flemming Andreasen wrote: >> On 11/8/12 11:29 AM, Emil Ivov wrote: >>> Hey Flemming, >>> >>> On 08.11.12, 10:53, Flemming Andreasen wrote: >>>> On 11/8/12 10:46 AM, Martin Thomson wrote: >>>>> Trolled. >>>>> >>>>> Though to be honest, I don't see a way around this particular problem. >>>>> The idea of using a Require: trickle header is fraught with problems; >>>>> the idea that you might use an a= line doesn't give you the >>>>> characteristics you desire. I just don't know how to cause the >>>>> failure that is needed when this isn't supported. >>>> Can we capture the desired characteristics and failure mode for starters ? >>> The "really" desired characteristic is knowing in advance whether or not >>> the remote party can do trickle so that you know whether you can afford >>> to send an empty offer without causing it to freak out. >> Why would you send an empty offer ? > Normally the offer should contain only candidates that are readily > available (such as host candidates). However if the offerer does not > wish to disclose those for privacy reasons, then it would just send an > offer with no candidates. This is for example how Chrome currently behaves. > > It also places 0.0.0.0:1 in the c= and m= lines. > > That's currently explain in section 4 of the draft: > > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4 Ok (that's not an empty offer though). > >>> Since protocols like SIP don't really have things like XMPP disco and >>> Cap Neg that would have allowed it, we were considering other options. >>> One such option would be to send a trickle offer and format it in a way >>> that would cause a non-trickle answerer to reject it in a _predictable_ >>> way. This would allow the offerer to retry with a regular ICE offer. >> I thought the point with trickle-ICE was to reduce call setup latency > It is. > >> and hence you would want to make sure that things complete in as few >> round-trips as possible. This doesn't seem to line up with that (?). > The thing is that in cases where trickle ICE support cannot be > pre-confirmed you have to fall back to half trickle. The probing > requests would hence allow for an optimisation compared to that. Somewhat unclear to me as it builds upon an assumption that it is somehow "more efficient"to probe than to collect candidates. Clarifying the criteria for something being "more efficient" would also be helpful here (what is it truly that we are after; setup delay reduction, fewer NAT bindings, ...) > With half-trickle the offerer has to gather all candidates anyway so, > while doing so, they might as well try and check if they really need to > complete it before sending their first offer. Unclear to me since you can collect candidates before you know who to send the offer to. Thanks -- Flemming >>>>> Besides, the failure modes all lead to an expenditure of time that is >>>>> worse than the simple candidate gathering scenarios (reflexive, >>>>> relay), though not "other" gathering methods (UPnP, etc...). >>>> Is there a requirement here that needs to be written down ? >>> The point that Martin is making is that sending an offer and then >>> waiting for the failure may potentially take longer than just gathering >>> your candidates. This is true especially in cases where the offerer is >>> only planning on using a single port, on a single interface, with a >>> single STUN/TURN server and no other candidate gathering mechanisms. >> I would agree with that. >>> But then, if this really is the case, the offerer knows it and can >>> choose not to do the probing. >> Agreed. >>>>> half-trickle is a reasonable solution. >>>> Sorry - what's half-trickle ? >>> We had that in the slides on Tuesday but it's not yet in the draft. The >>> idea is that if you can't confirm support for trickle in the answerer, >> Do you mean: if you don't know if the answerer supports it before >> sending an offer to him > Yes. That's what I meant. The offerer needs to know that in advance in > order to decide how to form their offer. > > Cheers, > Emil > >> [since confirming support in the answer should >> be easy] ? >>> you just send a vanilla ICE offer and you also indicate you do support >>> trickle. A trickle ICE answerer can then trickle candidates and in >>> general you get half the optimizations of Trickle ICE. You even get more >>> than that in case the offerer is able to predictively gather candidates >>> before the call is initiated. >> Agreed. >>> We'll describe this in the next version. >> Ok - thanks for the explanation. >> >> -- Flemming >>> Cheers, >>> Emil >>> >>>> -- Flemming >>>> >>>> >>>>> On 8 November 2012 10:12, Emil Ivov wrote: >>>>>> I actually think this was supposed to be a joke. At least that's how I >>>>>> got it. >>>>>> >>>>>> Emil >>>>>> >>>>>> On 08.11.12, 10:01, Flemming Andreasen wrote: >>>>>>> This is very different from the way we normally handle extensions in SDP >>>>>>> both from a pure signaling and negotiation point of view. I share the >>>>>>> sentiment of others that this does not look like a good idea but would >>>>>>> like to understand if there were other considerations for suggesting >>>>>>> this radically different approach. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- Flemming >>>>>>> >>>>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>>>>>>> Sent: 8. marraskuuta 2012 9:30 >>>>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>>>>>> Cc: mmusic@ietf.org >>>>>>>> Subject: Re: [MMUSIC] Signaling trickle support >>>>>>>> >>>>>>>> As an individual... >>>>>>>> >>>>>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>>>>>>> >>>>>>>> Let met quote RFC 4566: >>>>>>>> >>>>>>>> >>>>>>>> The "v=" field gives the version of the Session Description Protocol. >>>>>>>> This memo defines version 0. There is no minor version number. >>>>>>>> >>>>>>>> >>>>>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>>>>>>> >>>>>>>> /Miguel >>>>>>>> >>>>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>>>>>> trickle ICE support and the following proposal was made: >>>>>>>>>> >>>>>>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>>>>>> specifically reserved for forward compatibility purposes. We can use >>>>>>>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>>>>>>> >>>>>>>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>>>>>>> >>>>>>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>>>>>> After some side discussion, I guess you are talking about bits in the >>>>>>>>> value of the v= field ??? >>>>>>>>> >>>>>>>>> If so, I still have no idea what you are talking about. The syntax for >>>>>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>>>>>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>>>>>>> >>>>>>>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>>>>>>> an incredibly bad idea. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> . >>>>>>>> >>>>>> -- >>>>>> https://jitsi.org >>>>> . >>>>> >> From emil@sip-communicator.org Thu Nov 8 15:24: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 4E22221F86B0 for ; Thu, 8 Nov 2012 15:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8bWzb-5lAOC for ; Thu, 8 Nov 2012 15:24:42 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDD621F866B for ; Thu, 8 Nov 2012 15:24:42 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1484622dan.31 for ; Thu, 08 Nov 2012 15:24:41 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=9i2FxxG1a9eSWd4PKc0ptZBXMXC7kwN/r8WmeP8z/8g=; b=OleTCQIwQoVhqEED71iqNfVsZFmBEYhPxNHOs1he63HcfYKy/pfbnUOZ1akyVbhuSc ODqBYGpoUMhUvpxZpjdyvcIZ8EzCuiqF3N5hTW9j0Mc2+h4jlK6FvrdUWVh8mhD8unin C0anwms/MGh28qSXyA/xqkvgBinu4ikN0k9nYJsxfXJiYViZicZRmhzNjT2KDv+vXEQD SfmkVCS4HMVJ7X3DR3ZdQrZtnPYpmmTOrHYEe/cwlmFR9fiOvl+UxyOjMXJTyTrCB4aN f2pkmsoksIBvk2GvI7tsGFddZXG3y5KrllQBZ4V7koYc4QVoFzondp4rENuR3Q68NbTp ynOg== Received: by 10.68.241.133 with SMTP id wi5mr28359075pbc.48.1352417081770; Thu, 08 Nov 2012 15:24:41 -0800 (PST) Received: from dhcp-4225.meeting.ietf.org ([2001:df8:0:64:6945:2d5c:a862:4354]) by mx.google.com with ESMTPS id is3sm4783882pbc.6.2012.11.08.15.24.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 15:24:40 -0800 (PST) Message-ID: <509C3F33.8060809@jitsi.org> Date: Thu, 08 Nov 2012 18:24:35 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> In-Reply-To: <509C3066.6020209@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkHgts39mRXEtcmayjjuDIoV/99DjqsocvMmVget2m5+icqm5wfc9tqcxb1d2UiYjDobvhI Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 23:24:43 -0000 Hey Flemming, On 08.11.12, 17:21, Flemming Andreasen wrote: >>>> Since protocols like SIP don't really have things like XMPP disco and >>>> Cap Neg that would have allowed it, we were considering other options. >>>> One such option would be to send a trickle offer and format it in a way >>>> that would cause a non-trickle answerer to reject it in a _predictable_ >>>> way. This would allow the offerer to retry with a regular ICE offer. >>> I thought the point with trickle-ICE was to reduce call setup latency >> It is. >> >>> and hence you would want to make sure that things complete in as few >>> round-trips as possible. This doesn't seem to line up with that (?). >> The thing is that in cases where trickle ICE support cannot be >> pre-confirmed you have to fall back to half trickle. The probing >> requests would hence allow for an optimisation compared to that. > Somewhat unclear to me as it builds upon an assumption that it is > somehow "more efficient"to probe than to collect candidates. Indeed, this would not always be the case and it would basically come down to comparing one signalling RTT to the duration of candidate gathering. As you agreed in one of your previous mails, the relation may vary: Executing a single STUN transaction is likely to be less time consuming than a signalling RTT. Candidate gathering however may also last a lot longer than a single offer/answer exchange. However, an agent that has several interfaces and uses them to gather candidates for three streams that don't have bundle nor RTCP muxing is going to need quite some time to complete a harvest. Add to this UPnP allocations and a second STUN server and you could easily find the signalling RTT tens of times shorter than the candidate gathering. In all cases the UA would have a fairly good idea of what to expect so it could easily determine whether or not a probe would make sense. > Clarifying > the criteria for something being "more efficient" would also be helpful > here (what is it truly that we are after; setup delay reduction, fewer > NAT bindings, ...) I believe we can agree that in the context of trickle the only thing that matters is call setup duration. >> With half-trickle the offerer has to gather all candidates anyway so, >> while doing so, they might as well try and check if they really need to >> complete it before sending their first offer. > Unclear to me since you can collect candidates before you know who to > send the offer to. You could ... but not always. A hard phone can easily do this when someone picks it up. A softphone however doesn't have a clear early cue about a pending call initiation so the only way would be to always maintain a set of active candidates and to keep them alive. Not necessarily the most desirable option, especially for large deployments. A web page could be even worse, especially in cases where the calling functionality is only a side feature (e.g. a support or a customer service call option). Cheers, Emil > Thanks > > -- Flemming >>>>>> Besides, the failure modes all lead to an expenditure of time that is >>>>>> worse than the simple candidate gathering scenarios (reflexive, >>>>>> relay), though not "other" gathering methods (UPnP, etc...). >>>>> Is there a requirement here that needs to be written down ? >>>> The point that Martin is making is that sending an offer and then >>>> waiting for the failure may potentially take longer than just gathering >>>> your candidates. This is true especially in cases where the offerer is >>>> only planning on using a single port, on a single interface, with a >>>> single STUN/TURN server and no other candidate gathering mechanisms. >>> I would agree with that. >>>> But then, if this really is the case, the offerer knows it and can >>>> choose not to do the probing. >>> Agreed. >>>>>> half-trickle is a reasonable solution. >>>>> Sorry - what's half-trickle ? >>>> We had that in the slides on Tuesday but it's not yet in the draft. The >>>> idea is that if you can't confirm support for trickle in the answerer, >>> Do you mean: if you don't know if the answerer supports it before >>> sending an offer to him >> Yes. That's what I meant. The offerer needs to know that in advance in >> order to decide how to form their offer. >> >> Cheers, >> Emil >> >>> [since confirming support in the answer should >>> be easy] ? >>>> you just send a vanilla ICE offer and you also indicate you do support >>>> trickle. A trickle ICE answerer can then trickle candidates and in >>>> general you get half the optimizations of Trickle ICE. You even get more >>>> than that in case the offerer is able to predictively gather candidates >>>> before the call is initiated. >>> Agreed. >>>> We'll describe this in the next version. >>> Ok - thanks for the explanation. >>> >>> -- Flemming >>>> Cheers, >>>> Emil >>>> >>>>> -- Flemming >>>>> >>>>> >>>>>> On 8 November 2012 10:12, Emil Ivov wrote: >>>>>>> I actually think this was supposed to be a joke. At least that's how I >>>>>>> got it. >>>>>>> >>>>>>> Emil >>>>>>> >>>>>>> On 08.11.12, 10:01, Flemming Andreasen wrote: >>>>>>>> This is very different from the way we normally handle extensions in SDP >>>>>>>> both from a pure signaling and negotiation point of view. I share the >>>>>>>> sentiment of others that this does not look like a good idea but would >>>>>>>> like to understand if there were other considerations for suggesting >>>>>>>> this radically different approach. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> -- Flemming >>>>>>>> >>>>>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Miguel A. Garcia >>>>>>>>> Sent: 8. marraskuuta 2012 9:30 >>>>>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>>>>>>> Cc: mmusic@ietf.org >>>>>>>>> Subject: Re: [MMUSIC] Signaling trickle support >>>>>>>>> >>>>>>>>> As an individual... >>>>>>>>> >>>>>>>>> I concur with Paul, changing the v= version in the SDP is a very bad idea. >>>>>>>>> >>>>>>>>> Let met quote RFC 4566: >>>>>>>>> >>>>>>>>> >>>>>>>>> The "v=" field gives the version of the Session Description Protocol. >>>>>>>>> This memo defines version 0. There is no minor version number. >>>>>>>>> >>>>>>>>> >>>>>>>>> This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works. >>>>>>>>> >>>>>>>>> /Miguel >>>>>>>>> >>>>>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>>>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>>>>>>> trickle ICE support and the following proposal was made: >>>>>>>>>>> >>>>>>>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>>>>>>> specifically reserved for forward compatibility purposes. We can use >>>>>>>>>>> this bit. Set this bit to one to indicate support for trickle ICE. >>>>>>>>>>> >>>>>>>>>>> This meets the "works if supported, fails if it doesn't criteria". >>>>>>>>>>> >>>>>>>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>>>>>>> After some side discussion, I guess you are talking about bits in the >>>>>>>>>> value of the v= field ??? >>>>>>>>>> >>>>>>>>>> If so, I still have no idea what you are talking about. The syntax for >>>>>>>>>> the value of v= is 1*DIGIT. You can choose to represent that in binary >>>>>>>>>> and then choose bit 24 if you want, but that has no significance in 4566. >>>>>>>>>> >>>>>>>>>> Assigning a new SDP version to signal Trickle ICE support seems like >>>>>>>>>> an incredibly bad idea. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> . >>>>>>>>> >>>>>>> -- >>>>>>> https://jitsi.org >>>>>> . >>>>>> >>> > > -- https://jitsi.org From palmarti@cisco.com Fri Nov 9 04:45: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 727C221F867C for ; Fri, 9 Nov 2012 04:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLEK5HA8EwnR for ; Fri, 9 Nov 2012 04:45:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1A32321F8675 for ; Fri, 9 Nov 2012 04:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11144; q=dns/txt; s=iport; t=1352465153; x=1353674753; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2Y4vdYykB/MDjvU4w9md1Xdg/JYDQelwsLzGduQ7sHk=; b=WLjayeWYFIbtKsJho1O1De4Wlt81gOsqg9d0Tnz0HQnVSNZ8n96uzNEc 0hu7+6uLglj533gz6QrIc67bOrQxtrr0QIYjNI1fbY9dA8IO+ComECoGy Oo2PqFG6KHKbSDY7BV6kqzcMzO1MGhlCZRIOiuBjPvN66q+w8g0lSyl/X Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALj6nFCtJV2Z/2dsb2JhbABEw0qBCIIeAQEBAwEBAQEPAVsEBwUHBAIBCA4DBAEBAQodBycLFAkIAgQOBQgTB4diBgudBKAPBIwShWdhA4gliiSSCoFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140544045" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2012 12:45:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA9CjTBJ013670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 12:45:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 06:45:28 -0600 From: "Pal Martinsen (palmarti)" To: Emil Ivov Thread-Topic: [MMUSIC] Signaling trickle support Thread-Index: AQHNvPBFbiFQG76VOEudS1kVJ+wHIZffJpWAgADJ6YCAAHNpgIAACqiAgAADOYCAAAl0gIAAAcKAgAAKRoCAACwJAIAABQEAgAAxLwCAABGlgIAA374A Date: Fri, 9 Nov 2012 12:45:27 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB0EA57C@xmb-rcd-x06.cisco.com> References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> In-Reply-To: <509C3F33.8060809@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.68] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--56.093500-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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 12:45:54 -0000 On Nov 9, 2012, at 24:24 AM, Emil Ivov wrote: > Hey Flemming, >=20 > On 08.11.12, 17:21, Flemming Andreasen wrote: >>>>> Since protocols like SIP don't really have things like XMPP disco and >>>>> Cap Neg that would have allowed it, we were considering other options= . >>>>> One such option would be to send a trickle offer and format it in a w= ay >>>>> that would cause a non-trickle answerer to reject it in a _predictabl= e_ >>>>> way. This would allow the offerer to retry with a regular ICE offer. >>>> I thought the point with trickle-ICE was to reduce call setup latency >>> It is. >>>=20 >>>> and hence you would want to make sure that things complete in as few >>>> round-trips as possible. This doesn't seem to line up with that (?). >>> The thing is that in cases where trickle ICE support cannot be >>> pre-confirmed you have to fall back to half trickle. The probing >>> requests would hence allow for an optimisation compared to that. >> Somewhat unclear to me as it builds upon an assumption that it is=20 >> somehow "more efficient"to probe than to collect candidates. >=20 > Indeed, this would not always be the case and it would basically come > down to comparing one signalling RTT to the duration of candidate > gathering. >=20 > As you agreed in one of your previous mails, the relation may vary: >=20 > Executing a single STUN transaction is likely to be less time consuming > than a signalling RTT. Candidate gathering however may also last a lot > longer than a single offer/answer exchange. >=20 > However, an agent that has several interfaces and uses them to gather > candidates for three streams that don't have bundle nor RTCP muxing is > going to need quite some time to complete a harvest. >From our experience single allocation takes aprox 30ms. This includes one r= edirect due to alternate server and one extra roundtrip because of authenti= cation. The time the TURN server is using to process the request is neglica= ble and so it is RTT that is important. If the RTT is to large media would= be troublesome anyway due to excessive jitter and delay. Number of media lines and interfaces does not matter as this is done in par= allel (or pretty close to). Our implementation have 5 media lines (Audio, 2= x Video, BFCP, FECC), resulting in 9 TURN allocations.=20 What we have been struggling with is delay in the signaling path. We have s= een delays in the range of 3-5 seconds for the 200OK to traverse the signal= ing path. That caused some failing ICE calls due to to large skew and we di= d not complete the transactions in what we have set as a reasonable time.=20 > Add to this UPnP > allocations and a second STUN server and you could easily find the > signalling RTT tens of times shorter than the candidate gathering. >=20 My understanding is that UPnP or PCP can be used to open pinholes without t= he need for keepalives. So in theory this can be done when the endpoints registers. At least if we = are not overly concerned about the extra port allocations on the NAT. But I agree with the point. Additional steps to gather "better" candidates = can take time. > In all cases the UA would have a fairly good idea of what to expect so > it could easily determine whether or not a probe would make sense. >=20 >> Clarifying=20 >> the criteria for something being "more efficient" would also be helpful= =20 >> here (what is it truly that we are after; setup delay reduction, fewer=20 >> NAT bindings, ...) >=20 > I believe we can agree that in the context of trickle the only thing > that matters is call setup duration. >=20 Personally I see great benefit in having the ability to add candidates (and= remove them) without doing a update or re-invite. This would make mobility= scenarios easier, and developing a smarter and more optimized media experi= ence can be a lot easier. =20 .-. P=E5l-Erik >>> With half-trickle the offerer has to gather all candidates anyway so, >>> while doing so, they might as well try and check if they really need to >>> complete it before sending their first offer. >> Unclear to me since you can collect candidates before you know who to=20 >> send the offer to. >=20 > You could ... but not always. A hard phone can easily do this when > someone picks it up. A softphone however doesn't have a clear early cue > about a pending call initiation so the only way would be to always > maintain a set of active candidates and to keep them alive. Not > necessarily the most desirable option, especially for large deployments. >=20 > A web page could be even worse, especially in cases where the calling > functionality is only a side feature (e.g. a support or a customer > service call option). >=20 > Cheers, > Emil >=20 >> Thanks >>=20 >> -- Flemming >>>>>>> Besides, the failure modes all lead to an expenditure of time that = is >>>>>>> worse than the simple candidate gathering scenarios (reflexive, >>>>>>> relay), though not "other" gathering methods (UPnP, etc...). >>>>>> Is there a requirement here that needs to be written down ? >>>>> The point that Martin is making is that sending an offer and then >>>>> waiting for the failure may potentially take longer than just gatheri= ng >>>>> your candidates. This is true especially in cases where the offerer i= s >>>>> only planning on using a single port, on a single interface, with a >>>>> single STUN/TURN server and no other candidate gathering mechanisms. >>>> I would agree with that. >>>>> But then, if this really is the case, the offerer knows it and can >>>>> choose not to do the probing. >>>> Agreed. >>>>>>> half-trickle is a reasonable solution. >>>>>> Sorry - what's half-trickle ? >>>>> We had that in the slides on Tuesday but it's not yet in the draft. T= he >>>>> idea is that if you can't confirm support for trickle in the answerer= , >>>> Do you mean: if you don't know if the answerer supports it before >>>> sending an offer to him >>> Yes. That's what I meant. The offerer needs to know that in advance in >>> order to decide how to form their offer. >>>=20 >>> Cheers, >>> Emil >>>=20 >>>> [since confirming support in the answer should >>>> be easy] ? >>>>> you just send a vanilla ICE offer and you also indicate you do suppor= t >>>>> trickle. A trickle ICE answerer can then trickle candidates and in >>>>> general you get half the optimizations of Trickle ICE. You even get m= ore >>>>> than that in case the offerer is able to predictively gather candidat= es >>>>> before the call is initiated. >>>> Agreed. >>>>> We'll describe this in the next version. >>>> Ok - thanks for the explanation. >>>>=20 >>>> -- Flemming >>>>> Cheers, >>>>> Emil >>>>>=20 >>>>>> -- Flemming >>>>>>=20 >>>>>>=20 >>>>>>> On 8 November 2012 10:12, Emil Ivov wrote: >>>>>>>> I actually think this was supposed to be a joke. At least that's h= ow I >>>>>>>> got it. >>>>>>>>=20 >>>>>>>> Emil >>>>>>>>=20 >>>>>>>> On 08.11.12, 10:01, Flemming Andreasen wrote: >>>>>>>>> This is very different from the way we normally handle extensions= in SDP >>>>>>>>> both from a pure signaling and negotiation point of view. I share= the >>>>>>>>> sentiment of others that this does not look like a good idea but = would >>>>>>>>> like to understand if there were other considerations for suggest= ing >>>>>>>>> this radically different approach. >>>>>>>>>=20 >>>>>>>>> Thanks >>>>>>>>>=20 >>>>>>>>> -- Flemming >>>>>>>>>=20 >>>>>>>>> On 11/8/12 9:23 AM, Christer Holmberg wrote: >>>>>>>>>> +1 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Christer >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] O= n Behalf Of Miguel A. Garcia >>>>>>>>>> Sent: 8. marraskuuta 2012 9:30 >>>>>>>>>> To: Paul Kyzivat; Martin Thomson; Emil Ivov >>>>>>>>>> Cc: mmusic@ietf.org >>>>>>>>>> Subject: Re: [MMUSIC] Signaling trickle support >>>>>>>>>>=20 >>>>>>>>>> As an individual... >>>>>>>>>>=20 >>>>>>>>>> I concur with Paul, changing the v=3D version in the SDP is a ve= ry bad idea. >>>>>>>>>>=20 >>>>>>>>>> Let met quote RFC 4566: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The "v=3D" field gives the version of the Session Descrip= tion Protocol. >>>>>>>>>> This memo defines version 0. There is no minor version n= umber. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> This means that if you define another version different than zer= o, then, as a side effect, you are creating a different version of SDP than= the one specified in RFC 4566. So, you will need to create an RFC specifyi= ng how such version of SDP works. >>>>>>>>>>=20 >>>>>>>>>> /Miguel >>>>>>>>>>=20 >>>>>>>>>> On 07/11/2012 20:27, Paul Kyzivat wrote: >>>>>>>>>>> On 11/7/12 8:59 AM, Martin Thomson wrote: >>>>>>>>>>>> Matthew, Justin and I were discussing the problem of signaling >>>>>>>>>>>> trickle ICE support and the following proposal was made: >>>>>>>>>>>>=20 >>>>>>>>>>>> The 24th bit in SDP is currently set to zero. This bit is >>>>>>>>>>>> specifically reserved for forward compatibility purposes. We = can use >>>>>>>>>>>> this bit. Set this bit to one to indicate support for trickle= ICE. >>>>>>>>>>>>=20 >>>>>>>>>>>> This meets the "works if supported, fails if it doesn't criter= ia". >>>>>>>>>>>>=20 >>>>>>>>>>>> This solution may also be appropriate for bundle/mmt/whatever. >>>>>>>>>>> After some side discussion, I guess you are talking about bits = in the >>>>>>>>>>> value of the v=3D field ??? >>>>>>>>>>>=20 >>>>>>>>>>> If so, I still have no idea what you are talking about. The syn= tax for >>>>>>>>>>> the value of v=3D is 1*DIGIT. You can choose to represent that = in binary >>>>>>>>>>> and then choose bit 24 if you want, but that has no significanc= e in 4566. >>>>>>>>>>>=20 >>>>>>>>>>> Assigning a new SDP version to signal Trickle ICE support seems= like >>>>>>>>>>> an incredibly bad idea. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> . >>>>>>>>>>=20 >>>>>>>> -- >>>>>>>> https://jitsi.org >>>>>>> . >>>>>>>=20 >>>>=20 >>=20 >>=20 >=20 > --=20 > https://jitsi.org > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Fri Nov 9 06:24: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 94D0521F8582 for ; Fri, 9 Nov 2012 06:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cstQmH4Vl8tS for ; Fri, 9 Nov 2012 06:24:00 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C394721F8559 for ; Fri, 9 Nov 2012 06:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4033; q=dns/txt; s=iport; t=1352471040; x=1353680640; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KWiNunKVbKIcUnkA5qSCiorK9pflH4TOVoGZ6uEnTyo=; b=bLXtiaLuUCcroVMTX0GsgKbbos3qBxWseQDClY495o8SNfeBUxsIyQxS RfBXg/GHUlXmZGHWjPmZAfYbfhlGDWJRMEE9M9eFxN7Ep03sDol4wT0pf glcDPQKQazBagdT7kQtkRN0rS9PRpOA47ObM98IIj/Ez6xlA9rbzXUrGG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ4RnVCrRDoH/2dsb2JhbABEhhm5cINBgQiCHgEBAQMBEgEQFToGAQULCw4KAgIFFgsCAgkDAgECAUUGDQEHAQEeh2IFnS2NJZJsgSCQJ4ETA4hajSGOWIFrgw0 X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="61024356" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 09 Nov 2012 14:24:00 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.245.2]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA9ENwZ7005925; Fri, 9 Nov 2012 14:23:59 GMT Message-ID: <509D1200.3070702@cisco.com> Date: Fri, 09 Nov 2012 09:24:00 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Emil Ivov References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> In-Reply-To: <509C3F33.8060809@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 14:24:01 -0000 On 11/8/12 6:24 PM, Emil Ivov wrote: > Hey Flemming, > > On 08.11.12, 17:21, Flemming Andreasen wrote: >>>>> Since protocols like SIP don't really have things like XMPP disco and >>>>> Cap Neg that would have allowed it, we were considering other options. >>>>> One such option would be to send a trickle offer and format it in a way >>>>> that would cause a non-trickle answerer to reject it in a _predictable_ >>>>> way. This would allow the offerer to retry with a regular ICE offer. >>>> I thought the point with trickle-ICE was to reduce call setup latency >>> It is. >>> >>>> and hence you would want to make sure that things complete in as few >>>> round-trips as possible. This doesn't seem to line up with that (?). >>> The thing is that in cases where trickle ICE support cannot be >>> pre-confirmed you have to fall back to half trickle. The probing >>> requests would hence allow for an optimisation compared to that. >> Somewhat unclear to me as it builds upon an assumption that it is >> somehow "more efficient"to probe than to collect candidates. > Indeed, this would not always be the case and it would basically come > down to comparing one signalling RTT to the duration of candidate > gathering. > > As you agreed in one of your previous mails, the relation may vary: I still agree with that :-) > Executing a single STUN transaction is likely to be less time consuming > than a signalling RTT. Candidate gathering however may also last a lot > longer than a single offer/answer exchange. > > However, an agent that has several interfaces and uses them to gather > candidates for three streams that don't have bundle nor RTCP muxing is > going to need quite some time to complete a harvest. Add to this UPnP > allocations and a second STUN server and you could easily find the > signalling RTT tens of times shorter than the candidate gathering. Because of the min. 20 ms Ta timer constraints, which apply cross-media stream ? Can somebody refresh my mind as to why that is (e.g. are residential NATs at this point generally not capable of creating NAT bindings faster than at 20 ms intervals) ? > In all cases the UA would have a fairly good idea of what to expect so > it could easily determine whether or not a probe would make sense. > >> Clarifying >> the criteria for something being "more efficient" would also be helpful >> here (what is it truly that we are after; setup delay reduction, fewer >> NAT bindings, ...) > I believe we can agree that in the context of trickle the only thing > that matters is call setup duration. Ok - so reducing the number of NAT binding allocations is explicitly not a concern (only the time it takes to create those bindings, if that time is in the critical path for the actual call setup). >>> With half-trickle the offerer has to gather all candidates anyway so, >>> while doing so, they might as well try and check if they really need to >>> complete it before sending their first offer. >> Unclear to me since you can collect candidates before you know who to >> send the offer to. > You could ... but not always. A hard phone can easily do this when > someone picks it up. A softphone however doesn't have a clear early cue > about a pending call initiation so the only way would be to always > maintain a set of active candidates and to keep them alive. Not > necessarily the most desirable option, especially for large deployments. I'm not sure I see much difference between hard and soft-phones here. For each, there is some sort of interaction before the call is initiated giving you a bit of a head-start to gather candidates. If we are trying to optimize out several seconds that may not help much, however if we are in the 100's ms range, then it will. > A web page could be even worse, especially in cases where the calling > functionality is only a side feature (e.g. a support or a customer > service call option). Why would a web page be worse ? Thanks -- Flemming From emil@sip-communicator.org Fri Nov 9 06:43: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 C528C21F85AB for ; Fri, 9 Nov 2012 06:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7vFtvpuPiXV for ; Fri, 9 Nov 2012 06:43:51 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3CDC21F8546 for ; Fri, 9 Nov 2012 06:43:51 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3075919pbb.31 for ; Fri, 09 Nov 2012 06:43:51 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=xkU3pYuTsjsE5iYCBKbEuC/NwJerLnysHcBlYupIQ/4=; b=Hi1SnuyiriyJQvUVkwTC4aebgGQARu/BFdNXpvyEdulxXTos2E3+wQmhSIzMyrkJOO D5yyDpxphSkqayjoY4VTK5BiWSjmVUt0ovJQDo6AMqWnUImRmwIEWcdOcPYknc5sYpZV OtakWfOb8z7v5WbVJzimK/dpnulrjr6yYgwRSFGrmEX1GEqAuyLEapvi4WiTsxrkhBZI OfZnE/4c/a9kowArJFjbK+05Jyw5sH8MDLJ6oNPiBnBmY+omXw3AER0xYpb/bX4CJfyB 2ECtF+bK0Fqzi94RnYQcbFKg0tNWVsSGMNiPigUVRK5AvTECsP92QncuBT8Nua/nnyra eHkg== Received: by 10.66.84.40 with SMTP id v8mr32207889pay.47.1352472231551; Fri, 09 Nov 2012 06:43:51 -0800 (PST) Received: from dhcp-9339.meeting.ietf.org ([2001:df8:0:8:10a1:8c3f:cc5:e74c]) by mx.google.com with ESMTPS id n11sm17816618pby.67.2012.11.09.06.43.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 06:43:50 -0800 (PST) Message-ID: <509D16A3.7040007@jitsi.org> Date: Fri, 09 Nov 2012 09:43:47 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> In-Reply-To: <509D1200.3070702@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQni4MYSKP0oWogAx8RYGfHiDNOg6M+1O7A3DBkXbsbrME3Xd0OkIgXFncJKp7gRG2u6C/UK Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 14:43:52 -0000 On 09.11.12, 09:24, Flemming Andreasen wrote: > > On 11/8/12 6:24 PM, Emil Ivov wrote: >> Hey Flemming, >> >> On 08.11.12, 17:21, Flemming Andreasen wrote: >>>>>> Since protocols like SIP don't really have things like XMPP disco and >>>>>> Cap Neg that would have allowed it, we were considering other options. >>>>>> One such option would be to send a trickle offer and format it in a way >>>>>> that would cause a non-trickle answerer to reject it in a _predictable_ >>>>>> way. This would allow the offerer to retry with a regular ICE offer. >>>>> I thought the point with trickle-ICE was to reduce call setup latency >>>> It is. >>>> >>>>> and hence you would want to make sure that things complete in as few >>>>> round-trips as possible. This doesn't seem to line up with that (?). >>>> The thing is that in cases where trickle ICE support cannot be >>>> pre-confirmed you have to fall back to half trickle. The probing >>>> requests would hence allow for an optimisation compared to that. >>> Somewhat unclear to me as it builds upon an assumption that it is >>> somehow "more efficient"to probe than to collect candidates. >> Indeed, this would not always be the case and it would basically come >> down to comparing one signalling RTT to the duration of candidate >> gathering. >> >> As you agreed in one of your previous mails, the relation may vary: > I still agree with that :-) >> Executing a single STUN transaction is likely to be less time consuming >> than a signalling RTT. Candidate gathering however may also last a lot >> longer than a single offer/answer exchange. >> >> However, an agent that has several interfaces and uses them to gather >> candidates for three streams that don't have bundle nor RTCP muxing is >> going to need quite some time to complete a harvest. Add to this UPnP >> allocations and a second STUN server and you could easily find the >> signalling RTT tens of times shorter than the candidate gathering. > Because of the min. 20 ms Ta timer constraints, which apply cross-media > stream ? Yes, although not only. In the case of UPnP you may also have to spend some time in discovery. Other gathering mechanisms may involve different delays. > Can somebody refresh my mind as to why that is (e.g. are > residential NATs at this point generally not capable of creating NAT > bindings faster than at 20 ms intervals) ? I believe the idea was to maintain a bitrate that would be similar to the one you will be using during the call. Otherwise you may end up with packet bursts and packet drops that could delay conn checks. >> In all cases the UA would have a fairly good idea of what to expect so >> it could easily determine whether or not a probe would make sense. >> >>> Clarifying >>> the criteria for something being "more efficient" would also be helpful >>> here (what is it truly that we are after; setup delay reduction, fewer >>> NAT bindings, ...) >> I believe we can agree that in the context of trickle the only thing >> that matters is call setup duration. > Ok - so reducing the number of NAT binding allocations is explicitly not > a concern (only the time it takes to create those bindings, if that time > is in the critical path for the actual call setup). In the context of Trickle ICE - yes. >>>> With half-trickle the offerer has to gather all candidates anyway so, >>>> while doing so, they might as well try and check if they really need to >>>> complete it before sending their first offer. >>> Unclear to me since you can collect candidates before you know who to >>> send the offer to. >> You could ... but not always. A hard phone can easily do this when >> someone picks it up. A softphone however doesn't have a clear early cue >> about a pending call initiation so the only way would be to always >> maintain a set of active candidates and to keep them alive. Not >> necessarily the most desirable option, especially for large deployments. > I'm not sure I see much difference between hard and soft-phones here. > For each, there is some sort of interaction before the call is initiated > giving you a bit of a head-start to gather candidates. If we are trying > to optimize out several seconds that may not help much, however if we > are in the 100's ms range, then it will. Well, in our case for instance (Jitsi) the user is constantly interacting with the application and the majority of these interactions do not end with a call. IMs for example are a lot more frequent, and then you also have other use cases such checking presence for others, setting a presence status for the user, checking contact details, viewing call history, etc. All in all, you only know for sure that a call is being made, once the call button is pressed. >> A web page could be even worse, especially in cases where the calling >> functionality is only a side feature (e.g. a support or a customer >> service call option). > Why would a web page be worse ? Because it could offer even more non-call use cases than a dedicated application such as a softphone/messenger. Calls could be a relatively corner use case for many web pages. Imagine for example a product page on Amazon with a "Call the vendor" button. Calls would be relatively rare and there would be no way to predict them until the button is pressed. Emil -- https://jitsi.org From fandreas@cisco.com Fri Nov 9 06:58: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 D943021F8510 for ; Fri, 9 Nov 2012 06:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XsCTJ3cXuwm for ; Fri, 9 Nov 2012 06:58:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 294A321F8506 for ; Fri, 9 Nov 2012 06:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1411; q=dns/txt; s=iport; t=1352473119; x=1353682719; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q2TMXihni2O4LI99xpvJ0julV8jZGNi5bqdwgcdJCeI=; b=VcMEAQWWXh2fqoIgJl4AyCB0KzT09jTsQ6f+9XzJ1DD/OCyJ0T420PuL 9Obv/AgffvcjFS+T4X1GVwed+4ZKSr8cqE7LgJPjQ8irAwsQZw3hS4hwn z84gr2McxWirNMMUnPmtWpDFULjAn//AOY4+tVz6ma6dk26QEV+0FILO7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABoZnVCtJXHB/2dsb2JhbABEhhm9KIEIgh4BAQEEEgEQFUABEAsOCgICBRYLAgIJAwIBAgFFBg0BBwEBHodonTqNJ5JsgSKQKYETA4hajSGOWIFrgw0 X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140584384" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2012 14:58:38 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.245.2]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA9Ewani022173; Fri, 9 Nov 2012 14:58:37 GMT Message-ID: <509D1A1E.3020303@cisco.com> Date: Fri, 09 Nov 2012 09:58:38 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Emil Ivov References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> <509D16A3.7040007@jitsi.org> In-Reply-To: <509D16A3.7040007@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 14:58:40 -0000 On 11/9/12 9:43 AM, Emil Ivov wrote: > >>> Executing a single STUN transaction is likely to be less time consuming >>> than a signalling RTT. Candidate gathering however may also last a lot >>> longer than a single offer/answer exchange. >>> >>> However, an agent that has several interfaces and uses them to gather >>> candidates for three streams that don't have bundle nor RTCP muxing is >>> going to need quite some time to complete a harvest. Add to this UPnP >>> allocations and a second STUN server and you could easily find the >>> signalling RTT tens of times shorter than the candidate gathering. >> Because of the min. 20 ms Ta timer constraints, which apply cross-media >> stream ? > Yes, although not only. In the case of UPnP you may also have to spend > some time in discovery. > > Other gathering mechanisms may involve different delays. > >> Can somebody refresh my mind as to why that is (e.g. are >> residential NATs at this point generally not capable of creating NAT >> bindings faster than at 20 ms intervals) ? > I believe the idea was to maintain a bitrate that would be similar to > the one you will be using during the call. Otherwise you may end up with > packet bursts and packet drops that could delay conn checks. That only explains why it applies within a media stream (which I can understand), not why it applies cross-media stream. -- Flemming From harald@alvestrand.no Fri Nov 9 08:09: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 6CDB021F896F for ; Fri, 9 Nov 2012 08:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.966 X-Spam-Level: X-Spam-Status: No, score=-109.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBBF9+oJ8E76 for ; Fri, 9 Nov 2012 08:09:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A7E3021F8828 for ; Fri, 9 Nov 2012 08:09:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D92739E1C6 for ; Fri, 9 Nov 2012 17:09:20 +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 IHiKkaJrRYLp for ; Fri, 9 Nov 2012 17:09:19 +0100 (CET) Received: from [IPv6:2001:df8:0:64:64b4:1954:eff9:cc33] (unknown [IPv6:2001:df8:0:64:64b4:1954:eff9:cc33]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0716939E1C2 for ; Fri, 9 Nov 2012 17:09:18 +0100 (CET) Message-ID: <509D2AAD.50300@alvestrand.no> Date: Fri, 09 Nov 2012 17:09:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 16:09:22 -0000 On 11/07/2012 02:59 PM, Martin Thomson wrote: > Matthew, Justin and I were discussing the problem of signaling trickle > ICE support and the following proposal was made: > > The 24th bit in SDP is currently set to zero. This bit is > specifically reserved for forward compatibility purposes. We can use > this bit. Set this bit to one to indicate support for trickle ICE. hm... the 24th bit in SDP is zero, but setting it would make it SDQ.... why not set the 22nd bit and make it SDT (SDP with Trickle)? > > This meets the "works if supported, fails if it doesn't criteria". I don't think it meets the "reverts to old behaviour if it doesn't work" criterion that previous attempts to extend SDP have jumped through Möbius hoops to maintain. But it's tempting. > > This solution may also be appropriate for bundle/mmt/whatever. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ietf@meetecho.com Fri Nov 9 09:06: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 3E36B21F8775 for ; Fri, 9 Nov 2012 09:06:39 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOklrIjpUwTH for ; Fri, 9 Nov 2012 09:06:39 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id E8ADF21F876F for ; Fri, 9 Nov 2012 09:06:35 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV6Z1k00v0ELJoa01V6ago; Fri, 09 Nov 2012 18:06:34 +0100 Message-ID: <509D3817.3020205@meetecho.com> Date: Fri, 09 Nov 2012 18:06:31 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Meetecho session recording 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 Nov 2012 17:06:39 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From emil@sip-communicator.org Fri Nov 9 12:16: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 7C55621F8820 for ; Fri, 9 Nov 2012 12:16:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM5FJeJpCHLG for ; Fri, 9 Nov 2012 12:16:04 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14921F896F for ; Fri, 9 Nov 2012 12:16:04 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id g10so943119ghb.31 for ; Fri, 09 Nov 2012 12:16:04 -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:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Z9up1F1HY4paoo1nFjxoKIpHfQdbgSdRSxjHAOVVtrg=; b=p0g/kv9EOkDx/169GW5nL728h4lieKYONK9bLTemj4cH4dnfwwTzoLi1BpWMauhlVe W6VdBtt+a6zfUUyZJ2JMe0k2hRYXYKYscf+VDKdC3G78BXBGNX23WPgFLUecHeth2/aA KEaiFEOnMa5Vci794GFyn0EBGFjbRIof3oAiN/7AFTuBKmsHfzE4dX5enEnu9HpP0F9G lLkVf65MFivnCzke57LwMs3MpDVk22b4Cf0NO1rLEaORr5NfaOs6vy1izqPtOlMVKXHO SzpqizTxzRUeyKdxV2hjlKHLh/F8+59n0Gc4asmBHzGjmgB4F+HQECYe4LAfYJ7u5k7f VprQ== Received: by 10.236.77.74 with SMTP id c50mr12936916yhe.43.1352492163905; Fri, 09 Nov 2012 12:16:03 -0800 (PST) Received: from camionet.local ([70.158.103.10]) by mx.google.com with ESMTPS id d66sm30892725yhe.1.2012.11.09.12.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 12:16:03 -0800 (PST) Message-ID: <509D6481.40305@jitsi.org> Date: Fri, 09 Nov 2012 15:16:01 -0500 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> <509D16A3.7040007@jitsi.org> <509D1A1E.3020303@cisco.com> In-Reply-To: <509D1A1E.3020303@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkbx7APO4lASZ/ymsEbDqIo3Tuux3UlQ0qDk8U9hPSd6h6+XDbyfApg73CMFrbZNz8q79yk Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 20:16:06 -0000 On 09.11.12, 09:58, Flemming Andreasen wrote: > > On 11/9/12 9:43 AM, Emil Ivov wrote: >> >>>> Executing a single STUN transaction is likely to be less time consuming >>>> than a signalling RTT. Candidate gathering however may also last a lot >>>> longer than a single offer/answer exchange. >>>> >>>> However, an agent that has several interfaces and uses them to gather >>>> candidates for three streams that don't have bundle nor RTCP muxing is >>>> going to need quite some time to complete a harvest. Add to this UPnP >>>> allocations and a second STUN server and you could easily find the >>>> signalling RTT tens of times shorter than the candidate gathering. >>> Because of the min. 20 ms Ta timer constraints, which apply cross-media >>> stream ? >> Yes, although not only. In the case of UPnP you may also have to spend >> some time in discovery. >> >> Other gathering mechanisms may involve different delays. >> >>> Can somebody refresh my mind as to why that is (e.g. are >>> residential NATs at this point generally not capable of creating NAT >>> bindings faster than at 20 ms intervals) ? >> I believe the idea was to maintain a bitrate that would be similar to >> the one you will be using during the call. Otherwise you may end up with >> packet bursts and packet drops that could delay conn checks. > > That only explains why it applies within a media stream (which I can > understand), not why it applies cross-media stream. True. I wasn't around at the time though so I have no idea how it ended up being the cross-stream minimum. Emil -- https://jitsi.org From carl_klatsky@cable.comcast.com Mon Nov 12 12:46: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 D07B521F8773 for ; Mon, 12 Nov 2012 12:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.407 X-Spam-Level: X-Spam-Status: No, score=-99.407 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLyILOqqsFH2 for ; Mon, 12 Nov 2012 12:46:16 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0C13F21F8765 for ; Mon, 12 Nov 2012 12:46:15 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.33880333; Mon, 12 Nov 2012 15:38:04 -0500 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.98]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 15:46:10 -0500 From: "Klatsky, Carl" To: "'mmusic@ietf.org'" Thread-Topic: Comments on draft-ietf-mmusic-media-loopback-24 Thread-Index: Ac3BFr6o1ZSoiOVOTf6tsuFIerSDYw== Date: Mon, 12 Nov 2012 20:46:09 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E8772B4C899@PACDCEXMB15.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.176] Content-Type: multipart/alternative; boundary="_000_6C15A6B88541034E912E94C2D8BC3E8772B4C899PACDCEXMB15cabl_" MIME-Version: 1.0 Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-24 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 Nov 2012 20:46:17 -0000 --_000_6C15A6B88541034E912E94C2D8BC3E8772B4C899PACDCEXMB15cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A colleague of mine forwarded me this draft and I had two comments if someo= ne on the distro has input: 1) When setting up the media loopback, are there any restrictions on t= ype of codec used? Could even telephone-events codec be specified? 2) Although this draft is centered around media, can it be extended to= for use as means to test the caller ID set connected to an analog telephon= y interface? The approach outlined in this draft seems to imply no interac= tion with the end subscriber is needed. If the network operator wanted to = silently send a test pattern to the caller ID set, perhaps this same loopba= ck mechanism can be used with either an additional SDP attribute or some ch= ange in the SIP header itself. A related application would be to advance t= he timestamp on the caller ID set following Daylight Savings Time transitio= n. Typically that is not updated until the next inbound call following the= DST change. A loopback call could signal to the device to update the call= er ID set but without ringing / alerting the end subscriber without the nee= d to wait for an inbound call. Regards, Carl Klatsky Comcast --_000_6C15A6B88541034E912E94C2D8BC3E8772B4C899PACDCEXMB15cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A colleague of mine forwarded me this draft and I ha= d two comments if someone on the distro has input:

 

1)      When setting up the media loopback, are there any r= estrictions on type of codec used?  Could even telephone-events codec = be specified?

2)      Although this draft is centered around media, can i= t be extended to for use as means to test the caller ID set connected to an= analog telephony interface?  The approach outlined in this draft seem= s to imply no interaction with the end subscriber is needed.  If the network operator wanted to silently sen= d a test pattern to the caller ID set, perhaps this same loopback mechanism= can be used with either an additional SDP attribute or some change in the = SIP header itself.  A related application would be to advance the timestamp on the caller ID set following Daylight = Savings Time transition.  Typically that is not updated until the next= inbound call following the DST change.  A loopback call could signal = to the device to update the caller ID set but without ringing / alerting the end subscriber without the need to wait= for an inbound call.

 

 

Regards,

 

Carl Klatsky

Comcast

--_000_6C15A6B88541034E912E94C2D8BC3E8772B4C899PACDCEXMB15cabl_-- From harald@alvestrand.no Tue Nov 13 01:02: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 8CA0C21F8672 for ; Tue, 13 Nov 2012 01:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.554 X-Spam-Level: X-Spam-Status: No, score=-109.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEcR4wukvSbL for ; Tue, 13 Nov 2012 01:02:08 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA121F866F for ; Tue, 13 Nov 2012 01:02:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EDB8739E151 for ; Tue, 13 Nov 2012 10:02:05 +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 vI5JklNRSFZF for ; Tue, 13 Nov 2012 10:02:04 +0100 (CET) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2C05C39E091 for ; Tue, 13 Nov 2012 10:02:04 +0100 (CET) Message-ID: <50A20CE5.5000200@alvestrand.no> Date: Tue, 13 Nov 2012 10:03:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> In-Reply-To: <509D1200.3070702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 09:02:09 -0000 On 11/09/2012 03:24 PM, Flemming Andreasen wrote: > > On 11/8/12 6:24 PM, Emil Ivov wrote: >> Hey Flemming, >> >> On 08.11.12, 17:21, Flemming Andreasen wrote: >>>>>> Since protocols like SIP don't really have things like XMPP disco >>>>>> and >>>>>> Cap Neg that would have allowed it, we were considering other >>>>>> options. >>>>>> One such option would be to send a trickle offer and format it in >>>>>> a way >>>>>> that would cause a non-trickle answerer to reject it in a >>>>>> _predictable_ >>>>>> way. This would allow the offerer to retry with a regular ICE offer. >>>>> I thought the point with trickle-ICE was to reduce call setup latency >>>> It is. >>>> >>>>> and hence you would want to make sure that things complete in as few >>>>> round-trips as possible. This doesn't seem to line up with that (?). >>>> The thing is that in cases where trickle ICE support cannot be >>>> pre-confirmed you have to fall back to half trickle. The probing >>>> requests would hence allow for an optimisation compared to that. >>> Somewhat unclear to me as it builds upon an assumption that it is >>> somehow "more efficient"to probe than to collect candidates. >> Indeed, this would not always be the case and it would basically come >> down to comparing one signalling RTT to the duration of candidate >> gathering. >> >> As you agreed in one of your previous mails, the relation may vary: > I still agree with that :-) >> Executing a single STUN transaction is likely to be less time consuming >> than a signalling RTT. Candidate gathering however may also last a lot >> longer than a single offer/answer exchange. >> >> However, an agent that has several interfaces and uses them to gather >> candidates for three streams that don't have bundle nor RTCP muxing is >> going to need quite some time to complete a harvest. Add to this UPnP >> allocations and a second STUN server and you could easily find the >> signalling RTT tens of times shorter than the candidate gathering. > Because of the min. 20 ms Ta timer constraints, which apply > cross-media stream ? Can somebody refresh my mind as to why that is > (e.g. are residential NATs at this point generally not capable of > creating NAT bindings faster than at 20 ms intervals) ? I have been told that in BEHAVE testing, NATs were found that would behave incoherently at short binding creation intervals, but none were found that couldn't handle one new binding every 20 ms, so this was set at the minimum interval for potentially binding-creation actions. Harald From dwing@cisco.com Tue Nov 13 08:39: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 B8DB121F8771 for ; Tue, 13 Nov 2012 08:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.567 X-Spam-Level: X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PiQfgbNlyiW for ; Tue, 13 Nov 2012 08:39:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11C21F8754 for ; Tue, 13 Nov 2012 08:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1435; q=dns/txt; s=iport; t=1352824740; x=1354034340; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=t7XKwIUW1pWFGK17lhe8L/59OelhM1kM+9LxTZRBHNg=; b=LgrHm/lQO+4Ac3/ZkYI0NvdnLt7iX5AefjQ8Y5c0KkkFOH+ppABuDnJ6 8fn9VksfQUHsu67TfUtO9j/gyDZE0QNmnBzo7vgktHBjnMHWoR9tWhAVr 1hy5oV3TzY2HtBm9NgSms2k7sK70xJIVFxWdRrIV1f46NFdSgnM2fARWm 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="63937145" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Nov 2012 16:38:58 +0000 Received: from DWINGWS01 ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qADGcvdX026824; Tue, 13 Nov 2012 16:38:57 GMT From: "Dan Wing" To: "'Harald Alvestrand'" , References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> <50A20CE5.5000200@alvestrand.no> In-Reply-To: <50A20CE5.5000200@alvestrand.no> Date: Tue, 13 Nov 2012 08:38:57 -0800 Message-ID: <072901cdc1bd$60d2cd60$22786820$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF5U1EuloMoYZvzG1BBtSh9mddWSgCrW9/YAYdem3MCf0vC8QJ0NOmXAbLMyTYC6mpDdwJjoGn4AXDCSqMBe2jtagKXiXomAWxNIdICOu0tSwK2YjucAeqUdUGXsTossA== Content-Language: en-us Cc: Flemming Andreasen Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 16:39:01 -0000 Harald Alvestrand wrote: > On 11/09/2012 03:24 PM, Flemming Andreasen wrote: ... > > Because of the min. 20 ms Ta timer constraints, which apply > > cross-media stream ? Can somebody refresh my mind as to why that is > > (e.g. are residential NATs at this point generally not capable of > > creating NAT bindings faster than at 20 ms intervals) ? > > I have been told that in BEHAVE testing, NATs were found that would > behave incoherently at short binding creation intervals, but none were > found that couldn't handle one new binding every 20 ms, so this was set > at the minimum interval for potentially binding-creation actions. The behavior was noticed during deployment, not BEHAVE testing -- otherwise I would have a nice BEHAVE test report to cite. And that NAT behavior, combined with ephemeral source ports for DNS queries, is probably what is tripping up both Microsoft and Chromium, causing them to limit themselves to 6 (or so) DNS queries at a time, http://code.google.com/p/chromium/issues/detail?id=122566. I am told Windows 8 also restricts its number of simultaneous DNS queries. If that NAT behavior is really what is tripping up Windows and Chromium, it would be spiffy if -- instead of limiting the number of outstanding queries -- the software would pace the queries, or use different behavior when querying the local caching nameserver which shouldn't suffer that problem. -d From fandreas@cisco.com Tue Nov 13 09:57: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 843A221F8592 for ; Tue, 13 Nov 2012 09:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxuTFenxTjy3 for ; Tue, 13 Nov 2012 09:57:00 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CE9C821F8577 for ; Tue, 13 Nov 2012 09:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1352829420; x=1354039020; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=H6x1bbrBHwXlr10POIt+eCRExtk3vi6t4qRsBX/+r8o=; b=kpfAa0AsYrOvgrrCIAPk4aeb6cHjoigeKJ/OLr1hlxeszU8P9i5eiUr1 smOs8tUG4i7PI2u7Q01C7UMXm5B3zj2DnLWbVey9PFZ14QEb0RirzzU71 sno8tVF6cE45pTzDKdsX6uLumhtCMaYk+JklP/tbueTF/6IkFP/opVtsI k=; X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="142003075" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2012 17:56:57 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qADHuuLV004986; Tue, 13 Nov 2012 17:56:56 GMT Message-ID: <50A289F2.1030004@cisco.com> Date: Tue, 13 Nov 2012 12:57:06 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dan Wing References: <509AB627.1090507@alum.mit.edu> <509B5F87.1010807@ericsson.com> <7594FB04B1934943A5C02806D1A2204B027800@ESESSMB209.ericsson.se> <509BC947.709@cisco.com> <509BCBFB.2020305@jitsi.org> <509BD563.9080808@cisco.com> <509BDE01.9060705@jitsi.org> <509C02F2.10303@cisco.com> <509C0724.3050300@jitsi.org> <509C3066.6020209@cisco.com> <509C3F33.8060809@jitsi.org> <509D1200.3070702@cisco.com> <50A20CE5.5000200@alvestrand.no> <072901cdc1bd$60d2cd60$22786820$@cisco.com> In-Reply-To: <072901cdc1bd$60d2cd60$22786820$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Signaling trickle support 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 Nov 2012 17:57:01 -0000 On 11/13/12 11:38 AM, Dan Wing wrote: > Harald Alvestrand wrote: >> On 11/09/2012 03:24 PM, Flemming Andreasen wrote: > ... >>> Because of the min. 20 ms Ta timer constraints, which apply >>> cross-media stream ? Can somebody refresh my mind as to why that is >>> (e.g. are residential NATs at this point generally not capable of >>> creating NAT bindings faster than at 20 ms intervals) ? >> I have been told that in BEHAVE testing, NATs were found that would >> behave incoherently at short binding creation intervals, but none were >> found that couldn't handle one new binding every 20 ms, so this was set >> at the minimum interval for potentially binding-creation actions. > The behavior was noticed during deployment, not BEHAVE testing -- > otherwise I would have a nice BEHAVE test report to cite. Does the concern remain today or can we start being more aggressive in some of these ? I've been told (second hand) that Google Maps routinely opens 50 TCP connections at a time, but don't have any details as to the speed with which they are opened. Anybody have any further insights or similar examples (that seem to work in practice) ? > And that NAT behavior, combined with ephemeral source ports for DNS > queries, is probably what is tripping up both Microsoft and Chromium, > causing them to limit themselves to 6 (or so) DNS queries at a time, > http://code.google.com/p/chromium/issues/detail?id=122566. I am > told Windows 8 also restricts its number of simultaneous DNS queries. > If that NAT behavior is really what is tripping up Windows and > Chromium, it would be spiffy if -- instead of limiting the number > of outstanding queries -- the software would pace the queries, or > use different behavior when querying the local caching nameserver > which shouldn't suffer that problem. Interesting - thanks for the data point(er). -- Flemming > -d > > > . > From harald@alvestrand.no Thu Nov 15 00:47: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 523A121F87E7 for ; Thu, 15 Nov 2012 00:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.084 X-Spam-Level: X-Spam-Status: No, score=-110.084 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbSceFT3cLKk for ; Thu, 15 Nov 2012 00:47:32 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1B03021F87DB for ; Thu, 15 Nov 2012 00:47:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9028939E151 for ; Thu, 15 Nov 2012 09:47:29 +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 TXntSjWfrESk for ; Thu, 15 Nov 2012 09:47:28 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:f1a7:8f70:3a07:f9d9] (unknown [IPv6:2001:470:de0a:27:f1a7:8f70:3a07:f9d9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9FD2739E020 for ; Thu, 15 Nov 2012 09:47:28 +0100 (CET) Message-ID: <50A4AC20.5030306@alvestrand.no> Date: Thu, 15 Nov 2012 09:47:28 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------000700080305030900070404" Subject: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 08:47:33 -0000 This is a multi-part message in MIME format. --------------000700080305030900070404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've been searching RFC 4566 (SDP) for this info, but came up blank.... in an M-line, we typically have m=video blabla 111 112 113 a=rtpmap:111 .... a=rtpmap:112 ... a=rtpmap:113 .... Section 5.14 says this: If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session. Now, the questions... 1) In offer/answer, does this sequence in an offer mean that the offerer prefers that the answerer use codec 111, if supported? 2) in offer/answer, does this sequence in an answer mean that the answerer prefers that the offerer use codec 111? 3) is there any preference expressed between codec 112 and codec 113? 4) Should the sequence of a=rtpmap: lines be completely ignored, or does it matter? I'm trying to fix a bug, and want to make sure I fix it according to spec. Harald --------------000700080305030900070404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've been searching RFC 4566 (SDP) for this info, but came up blank....

in an M-line, we typically have

m=video blabla 111 112 113
a=rtpmap:111 ....
a=rtpmap:112 ...
a=rtpmap:113 ....

Section 5.14 says this:

      If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
      sub-fields contain RTP payload type numbers.  When a list of
      payload type numbers is given, this implies that all of these
      payload formats MAY be used in the session, but the first of these
      formats SHOULD be used as the default format for the session.
Now, the questions...

1) In offer/answer, does this sequence in an offer mean that the offerer prefers that the answerer use codec 111, if supported?

2) in offer/answer, does this sequence in an answer mean that the answerer prefers that the offerer use codec 111?

3) is there any preference expressed between codec 112 and codec 113?

4) Should the sequence of a=rtpmap: lines be completely ignored, or does it matter?

I'm trying to fix a bug, and want to make sure I fix it according to spec.

               Harald



--------------000700080305030900070404-- From harald@alvestrand.no Thu Nov 15 00:57: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 F36B121F87E7 for ; Thu, 15 Nov 2012 00:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.814 X-Spam-Level: X-Spam-Status: No, score=-109.814 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF69YeBVZxfv for ; Thu, 15 Nov 2012 00:57:40 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AB19F21F878C for ; Thu, 15 Nov 2012 00:57:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 477CD39E151 for ; Thu, 15 Nov 2012 09:57:37 +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 e8eohFCjb3Am for ; Thu, 15 Nov 2012 09:57:35 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:f1a7:8f70:3a07:f9d9] (unknown [IPv6:2001:470:de0a:27:f1a7:8f70:3a07:f9d9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A4C4739E020 for ; Thu, 15 Nov 2012 09:57:35 +0100 (CET) Message-ID: <50A4AE7F.4040403@alvestrand.no> Date: Thu, 15 Nov 2012 09:57:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> In-Reply-To: <50A4AC20.5030306@alvestrand.no> Content-Type: multipart/alternative; boundary="------------010009050004020006050505" Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 08:57:41 -0000 This is a multi-part message in MIME format. --------------010009050004020006050505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Found some answers in RFC 3264. On 11/15/2012 09:47 AM, Harald Alvestrand wrote: > I've been searching RFC 4566 (SDP) for this info, but came up blank.... > > in an M-line, we typically have > > m=video blabla 111 112 113 > a=rtpmap:111 .... > a=rtpmap:112 ... > a=rtpmap:113 .... > > Section 5.14 says this: > > If the sub-field is "RTP/AVP" or "RTP/SAVP" the > sub-fields contain RTP payload type numbers. When a list of > payload type numbers is given, this implies that all of these > payload formats MAY be used in the session, but the first of these > formats SHOULD be used as the default format for the session. > > Now, the questions... > > 1) In offer/answer, does this sequence in an offer mean that the > offerer prefers that the answerer use codec 111, if supported? 3264 5.1: In all cases, the formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it. > > 2) in offer/answer, does this sequence in an answer mean that the > answerer prefers that the offerer use codec 111? 3264 6.1: The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer. > > 3) is there any preference expressed between codec 112 and codec 113? Clear from 3264. If we ever update 4566, might want to harmonize those. > > 4) Should the sequence of a=rtpmap: lines be completely ignored, or > does it matter? I hope the answer is "completely ignored", have found no evidence to the contrary. > > I'm trying to fix a bug, and want to make sure I fix it according to spec. > > Harald > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------010009050004020006050505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Found some answers in RFC 3264.

On 11/15/2012 09:47 AM, Harald Alvestrand wrote:
I've been searching RFC 4566 (SDP) for this info, but came up blank....

in an M-line, we typically have

m=video blabla 111 112 113
a=rtpmap:111 ....
a=rtpmap:112 ...
a=rtpmap:113 ....

Section 5.14 says this:

      If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
      sub-fields contain RTP payload type numbers.  When a list of
      payload type numbers is given, this implies that all of these
      payload formats MAY be used in the session, but the first of these
      formats SHOULD be used as the default format for the session.
Now, the questions...

1) In offer/answer, does this sequence in an offer mean that the offerer prefers that the answerer use codec 111, if supported?

3264 5.1:

   In all cases, the formats in the "m=" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.


2) in offer/answer, does this sequence in an answer mean that the answerer prefers that the offerer use codec 111?
3264 6.1:

  The
   media formats in the "m=" line MUST be listed in order of preference,
   with the first format listed being preferred.  In this case,
   preferred means that the offerer SHOULD use the format with the
   highest preference from the answer.



3) is there any preference expressed between codec 112 and codec 113?
Clear from 3264. If we ever update 4566, might want to harmonize those.

4) Should the sequence of a=rtpmap: lines be completely ignored, or does it matter?

I hope the answer is "completely ignored", have found no evidence to the contrary.


I'm trying to fix a bug, and want to make sure I fix it according to spec.

               Harald





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

--------------010009050004020006050505-- From ernst.horvath@siemens-enterprise.com Thu Nov 15 01:05: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 EBE1A21F85C4 for ; Thu, 15 Nov 2012 01:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW+g7g6xU8Rj for ; Thu, 15 Nov 2012 01:05:10 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E2D3721F851A for ; Thu, 15 Nov 2012 01:05:09 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C89571EB8466; Thu, 15 Nov 2012 10:05:08 +0100 (CET) Received: from MCHP03MSX.global-ad.net ([169.254.2.205]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 10:05:08 +0100 From: "Horvath, Ernst" To: Harald Alvestrand , mmusic Thread-Topic: [MMUSIC] Wisdom sought: Prioritization of codecs Thread-Index: AQHNww3eTvf8wKkeykCBHwLiw7dS7Zfql1xg Date: Thu, 15 Nov 2012 09:05:07 +0000 Message-ID: References: <50A4AC20.5030306@alvestrand.no> In-Reply-To: <50A4AC20.5030306@alvestrand.no> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_C2BCA7974025BD459349BED0D06E48BB0129EE62MCHP03MSXglobal_" MIME-Version: 1.0 Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 09:05:11 -0000 --_000_C2BCA7974025BD459349BED0D06E48BB0129EE62MCHP03MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, RFC 3264 states that codecs are listed in order of preference, most preferr= ed first, in both offer and answer. When selecting the acceptable codecs fr= om the offered list the answerer should keep the order unless there is good= reason not to do so. The offerer must be prepared to receive an answer wit= h codecs arranged in a different order. Although both sides can then use an= y of the negotiated codecs it is recommended they use the first in the list= . Regards, Ernst ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: Donnerstag, 15. November 2012 09:47 To: mmusic Subject: [MMUSIC] Wisdom sought: Prioritization of codecs I've been searching RFC 4566 (SDP) for this info, but came up blank.... in an M-line, we typically have m=3Dvideo blabla 111 112 113 a=3Drtpmap:111 .... a=3Drtpmap:112 ... a=3Drtpmap:113 .... Section 5.14 says this: If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session. Now, the questions... 1) In offer/answer, does this sequence in an offer mean that the offerer pr= efers that the answerer use codec 111, if supported? 2) in offer/answer, does this sequence in an answer mean that the answerer = prefers that the offerer use codec 111? 3) is there any preference expressed between codec 112 and codec 113? 4) Should the sequence of a=3Drtpmap: lines be completely ignored, or does = it matter? I'm trying to fix a bug, and want to make sure I fix it according to spec. Harald --_000_C2BCA7974025BD459349BED0D06E48BB0129EE62MCHP03MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Harald,
 
RFC 3264 states that codecs are listed in order of preferenc= e, most preferred first, in both offer and answer. When selecting the accep= table codecs from the offered list the answerer should keep the order unless there is good reason not to do so. The offere= r must be prepared to receive an answer with codecs arranged in a different= order. Although both sides can then use any of the negotiated codecs = it is recommended they use the first in the list.
 
Regards,
Ernst

From: mmusic-bounces@ietf.org [mail= to:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Donnerstag, 15. November 2012 09:47
To: mmusic
Subject: [MMUSIC] Wisdom sought: Prioritization of codecs

I've been searching RFC 4566 (SDP) for this info, but came up blank....

in an M-line, we typically have

m=3Dvideo blabla 111 112 113
a=3Drtpmap:111 ....
a=3Drtpmap:112 ...
a=3Drtpmap:113 ....

Section 5.14 says this:

      If the <proto> sub-field is "RTP/AVP" or &q=
uot;RTP/SAVP" the <fmt>
      sub-fields contain RTP payload type numbers.  When a list of
      payload type numbers is given, this implies that all of these
      payload formats MAY be used in the session, but the first of these
      formats SHOULD be used as the default format for the session.
Now, the questions...

1) In offer/answer, does this sequence in an offer mean that the offerer pr= efers that the answerer use codec 111, if supported?

2) in offer/answer, does this sequence in an answer mean that the answerer = prefers that the offerer use codec 111?

3) is there any preference expressed between codec 112 and codec 113?

4) Should the sequence of a=3Drtpmap: lines be completely ignored, or does = it matter?

I'm trying to fix a bug, and want to make sure I fix it according to spec.<= br>
            &nb= sp;  Harald



--_000_C2BCA7974025BD459349BED0D06E48BB0129EE62MCHP03MSXglobal_-- From Simo.Veikkolainen@nokia.com Thu Nov 15 01:06:18 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 1CA7421F86A6 for ; Thu, 15 Nov 2012 01:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9g9Q8hK4ixV for ; Thu, 15 Nov 2012 01:06:15 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E74F421F87EA for ; Thu, 15 Nov 2012 01:06:14 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAF963wE023156; Thu, 15 Nov 2012 11:06:04 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 11:06:02 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.80]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0318.003; Thu, 15 Nov 2012 09:06:02 +0000 From: To: , , , Thread-Topic: E.164 and visual separators in draft-ietf-mmusic-sdp-cs Thread-Index: Ac3DEGXfrPAdBGk/TW6QWq/Xh+eM1g== Date: Thu, 15 Nov 2012 09:06:01 +0000 Message-ID: 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: XyNKkw7TEHXS2OcfARBaXWR9O9Mb2ID5/iXRFxlBB1rANS5f/I/LxLjD3bRObMSFWt+RqxPiPwAO+YD8Q2XFOzWn95d+5/rAglLPu0gFYk4UNtR6h+x+VmJ2NB4oQbKrQJo3UusHiCWmNRe2tLy9iNwp962GlwdFAawRcn9tKeu034CLiby85ct1rhN/+Be0bg4MTcDIDlbPmqL+0Usi5n/AgMch64TCTw48cn3iu2reAGOzQ4pxwTrtNbiRLc5bPSyf8tSeabVERRKBVTxwuw== x-originating-ip: [10.236.8.80] Content-Type: multipart/alternative; boundary="_000_D09DAE6B636851459F7575D146EFB54B1A3BD4C3008AM1MPN1025mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 15 Nov 2012 09:06:02.0856 (UTC) FILETIME=[6FF0D680:01CDC310] X-Nokia-AV: Clean Subject: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 09:06:18 -0000 --_000_D09DAE6B636851459F7575D146EFB54B1A3BD4C3008AM1MPN1025mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Flemming, Paul, Keith, and all, When going through http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt= for publication, Flemming had a comment on the format of global telephone = numbers. The draft currently says in Section 5.2.1: This memo exclusively uses the international representation of E.164 numbers, i.e., those initiated with a '+' sign. The syntax (see Section 5.7) refers to the representation of a 'global-number' construction already specified in RFC 3966 [RFC3966]. This representation requires the presence of the '+' sign. Additionally, this representation allows for the presence of one or more 'visual- separator' constructions. Implementations confirming to this specification and using the "E164" address type together with the "PSTN" network type MUST only use international E.164, i.e., those starting with a '+' sign and SHOULD NOT use visual-separators. This was discussed earlier on the list, see http://www.ietf.org/mail-archi= ve/web/mmusic/current/msg09630.html Flemming's comment was that referencing to RFC3966 but saying that the synt= ax is invalid because we only use parts of it is not a good idea. The question is, could we just refer to RFC3966 and allow visual separators= ? In my understanding the tradeoff is between slightly increased complexity i= n parser implementation versus being clear on the syntax. I would be inclin= ed to prefer the latter. Regards, Simo --_000_D09DAE6B636851459F7575D146EFB54B1A3BD4C3008AM1MPN1025mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Flemming, Paul, Keith, and all,

 

When going through http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt for publicatio= n, Flemming had a comment on the format of global telephone numbers.

 

The draft currently says in Section 5.2.1:

 

  This memo exclusively uses the international r= epresentation of E.164

   numbers, i.e., those initiated with a '+'= sign.  The syntax (see

   Section 5.7) refers to the representation of = a 'global-number'

   construction already specified in RFC 3966 [R= FC3966].  This

   representation requires the presence of the '= +' sign.  Additionally,

   this representation allows for the presence o= f one or more 'visual-

   separator' constructions.  Implementatio= ns confirming to this

   specification and using the "E164" = address type together with the

   "PSTN" network type MUST only use i= nternational E.164, i.e., those

   starting with a '+' sign and SHOULD NOT u= se visual-separators.

 

This was discussed earlier on the list, see  http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html=

 

Flemming’s comment was that referencing to RFC= 3966 but saying that the syntax is invalid because we only use parts of it = is not a good idea.

 

The question is, could we just refer to RFC3966 and = allow visual separators?

 

In my understanding the tradeoff is between slightly= increased complexity in parser implementation versus being clear on the sy= ntax. I would be inclined to prefer the latter.

 

Regards,

Simo

 

 

 

 

--_000_D09DAE6B636851459F7575D146EFB54B1A3BD4C3008AM1MPN1025mg_-- From pkyzivat@alum.mit.edu Thu Nov 15 06:56:19 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 309C221F892B for ; Thu, 15 Nov 2012 06:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08OLcaq1UbvN for ; Thu, 15 Nov 2012 06:56:18 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 78ABC21F8527 for ; Thu, 15 Nov 2012 06:56:18 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id PoFr1k00217dt5G54qwHpE; Thu, 15 Nov 2012 14:56:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id PqwH1k00T3ZTu2S3ZqwHxu; Thu, 15 Nov 2012 14:56:17 +0000 Message-ID: <50A50290.10604@alum.mit.edu> Date: Thu, 15 Nov 2012 09:56:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: fandreas@cisco.com, keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 14:56:19 -0000 On 11/15/12 4:06 AM, Simo.Veikkolainen@nokia.com wrote: > Hi Flemming, Paul, Keith, and all, > > When going through > http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt for > publication, Flemming had a comment on the format of global telephone > numbers. > > The draft currently says in Section 5.2.1: > > This memo exclusively uses the international representation of E.164 > > numbers, i.e., those initiated with a '+' sign. The syntax (see > > Section 5.7) refers to the representation of a 'global-number' > > construction already specified in RFC 3966 [RFC3966]. This > > representation requires the presence of the '+' sign. Additionally, > > this representation allows for the presence of one or more 'visual- > > separator' constructions. Implementations confirming to this > > specification and using the "E164" address type together with the > > "PSTN" network type MUST only use international E.164, i.e., those > > starting with a '+' sign and SHOULD NOT use visual-separators. > > This was discussed earlier on the list, see > http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html > > Flemming’s comment was that referencing to RFC3966 but saying that the > syntax is invalid because we only use parts of it is not a good idea. > > The question is, could we just refer to RFC3966 and allow visual > separators? > > In my understanding the tradeoff is between slightly increased > complexity in parser implementation versus being clear on the syntax. I > would be inclined to prefer the latter. My personal preference is, like yours, to go with 3966 and permit separators. IIRC the reason for text saying not to use separators was that some others were opposed to having them. (Early versions of the draft allowed only digits and didn't refer to 3966.) Thanks, Paul From magnus.westerlund@ericsson.com Thu Nov 15 07:08: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 B5E0C21F893A for ; Thu, 15 Nov 2012 07:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.159 X-Spam-Level: X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuLnxanSkYwK for ; Thu, 15 Nov 2012 07:08:23 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED5821F8932 for ; Thu, 15 Nov 2012 07:08:22 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-e9-50a5056403fe Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.1C.11564.46505A05; Thu, 15 Nov 2012 16:08:20 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 15 Nov 2012 16:08:19 +0100 Message-ID: <50A50563.2000802@ericsson.com> Date: Thu, 15 Nov 2012 16:08:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <505FD907.9070800@cisco.com> <50771F8D.8040004@cisco.com> In-Reply-To: <50771F8D.8040004@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+JvjW4K69IAg/2fVS3u9r5gsnh/Qddi 6vLHLA7MHlN+b2T1WLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgydr++xFJwQL1iyYp57A2M T+S7GDk5JARMJB5N72GCsMUkLtxbz9bFyMUhJHCSUaJn3UNmCGc5o8TEWzOBqjg4eAW0JR63 xIKYLAKqEuu7hEF62QQsJG7+aGQDsUUFgiX2HFvLCGLzCghKnJz5hAWkXASoc+oCC5Aws0Co xL23F8BKhAXcJfrXbQWzhQRcJSat2ckMYnMKaEo8OHuQFeI0SYm3718xQ/TqSUy52sIIYctL NG+dzQzRqy3R0NTBOoFRaBaSzbOQtMxC0rKAkXkVI3tuYmZOernhJkZg4B7c8lt3B+OpcyKH GKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKxRbH5Tsn+i7owsYRW/ruMs //193x/bxt0q8O++1PGAiiJLrZIHCgllew58uFs0UXt71QG520e8Dy/ZdmGC5JE4hWq1qGOV QQn3FPaETL2jWfFyWvf+51GOxRyerC5qPDe975deYfO7U7N+jey7DoZDwoc2PV9jPHEDt6/f Cb+V4X9bLFd+e6HEUpyRaKjFXFScCACGiH7PKgIAAA== Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05 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 Nov 2012 15:08:23 -0000 Hi Flemming, Thanks for the comments. On 2012-10-11 21:35, Flemming Andreasen wrote: > I have reviewed the RTSP NAT Evaluation document and have several > comments on it, both technical and editorial. I will provide the main > technical comments below and send the minor and editorial comments > directly to the authors in a more "user-friendly" format. > > > Major comments > > - STUN based on either RFC 3489 or RFC 5389 (or both). The draft > discusses use of STUN as a NAT traversal mechanism (with some RTSP > operational "extensions"), and in so doing it references both RFC 3489 > (which is obsolete) and RFC 5389 (the replacement). Furthermore, in > several places, it bases and describes operation on now defunct > (obsolete) RFC 3489 logic and messages instead of RFC 5389. This either > needs to be rectified, or we should have a very good explanation in the > document as to why we are using RFC 3489 (and then be clear which parts > are based on RFC 3489 and which are based on RFC 5389). I intended to go with an background explanation. This document was evaluating RTSP NAT proposals at a time and in a context which is significantly before RFC 5389. Yes, the limits to the classification techniques exist and should be correctly described. But the fact that they was considered can not be undone in a document intended to document the considerations done at that time of picking ICE as a solution. Which is now 7+ year into history. > > - "Symmetric RTP" is called out as a potential solution for NAT > traversal with 3 different variations. Note that symmetric RTP is > defined in RFC 4961, and what is described in this document as > "symmetric RTP" looks a lot more like latching to me, with all the > potential issues that brings (and then some due to the shared use of > ports and hence shared SSRC space between different clients, as noted in > the document). The document needs to clear up its terminology in this > area ("connect", "binding", latch, symmetric RTP, etc.) and be clearer > about what is being proposed (which is latching as far as I can tell, > however it makes reference to certain mechanisms that aren't fully > described, e.g. binding packets with random nonces). Yes, it is what called latching today. When this was originally written latching wasn't called latching in this community. But I will work through the text to try avoid any missunderstandings. There is after all a basic requirement on latching that one uses symmetric RTP after the latching or things don't work. > > > Other significant comments > > - The draft intends to investigate and outline different RTSP NAT > traversal proposals with the goal of picking one for further detailed > specification (which can be found in the draft-ietf-mmusic-rtsp-nat > spec). There is a mixture of RFC 2119 language and more informal > language in several of these descriptions. Given that these are > high-level descriptions and have not been specified in detail, I do not > think we should give any other impression and hence I think RFC 2119 > language should be avoided. Fully agreed. There should be no RFC 2119 language in this doc. > > - The draft suggests that the RTSP server needs to enforce that > signaling and media come from the same IP-address as a security remedy > in several places, however this may not work with larger scale NATs > (e.g. carrier-grade NATs) where the NAT may be using more than one > external IP-address. It is more than a suggestion. It is an fact that servers implements this protection. If a CGN fails to give a host the same IP address then unfortunately that client will not get any content. I will claim it is the CGN that is more broken than the security mechanism. > > - The comparison section is missing two of the alternatives considered > (namely ALG and TCP tunneling). Also, the comparison chart would lead > most people to a different solution than the one chosen. To some extent, > I think it's because the requirements list is a simplified list of all > the considerations behind each of the proposals (as more fully explained > in the document overall). There are additional drawbacks to some of > these other solutions that do not show up in the table (e.g. > unauthenticated "latching" and requirement for RTSP server to have > public IP-address). It would be worthwhile briefly recapping those and > hence further motivate the choice of ICE in this section. Ok, will see what I can do with reasonable work effort. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fandreas@cisco.com Thu Nov 15 07:51: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 8343F21F8988 for ; Thu, 15 Nov 2012 07:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRo4JZRDeA8w for ; Thu, 15 Nov 2012 07:51:22 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C177021F84DD for ; Thu, 15 Nov 2012 07:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9785; q=dns/txt; s=iport; t=1352994682; x=1354204282; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=SZAWXe6CdNNoBM3Ohe+hoIMO4BiuqN+0tURKB4EPg3o=; b=mdTgUv+KzOG+HubSzd72pxl6ErRs5kg5+mPj9DCGDz71gqrqHPVltJWn jR3bhg6ACUiIXh3713SG6vv04Ih40lZFh2ZWGEIg5vSYdty6XY3OPKL7Y Urvqvznn/Ds7f9M3ivuFeAmUuCXmRa6YeMkNzOZRVun4gV18Sy+Bmx9eJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAMEOpVCtJXG9/2dsb2JhbABEgkmJM7dLgQiCHgEBAQMBEgEaSwEFCwsYCRYPCQMCAQIBRRMBBQIBAQUZh2MGC5xkoAyMS4YSA4hajSKBHI08gWuDDYFGFw X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142802242" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2012 15:51:21 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAFFpJr0015445; Thu, 15 Nov 2012 15:51:19 GMT Message-ID: <50A50F77.7060906@cisco.com> Date: Thu, 15 Nov 2012 10:51:19 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Simo.Veikkolainen@nokia.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080405050107010403050803" Cc: keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 15:51:25 -0000 This is a multi-part message in MIME format. --------------080405050107010403050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/15/12 4:06 AM, Simo.Veikkolainen@nokia.com wrote: > > Hi Flemming, Paul, Keith, and all, > > When going through > http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt > for > publication, Flemming had a comment on the format of global telephone > numbers. > > The draft currently says in Section 5.2.1: > > This memo exclusively uses the international representation of E.164 > > numbers, i.e., those initiated with a '+' sign. The syntax (see > > Section 5.7) refers to the representation of a 'global-number' > > construction already specified in RFC 3966 [RFC3966]. This > > representation requires the presence of the '+' sign. Additionally, > > this representation allows for the presence of one or more 'visual- > > separator' constructions. Implementations confirming to this > > specification and using the "E164" address type together with the > > "PSTN" network type MUST only use international E.164, i.e., those > > starting with a '+' sign and SHOULD NOT use visual-separators. > > This was discussed earlier on the list, see > http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html > > Flemming's comment was that referencing to RFC3966 but saying that the > syntax is invalid because we only use parts of it is not a good idea. > > The question is, could we just refer to RFC3966 and allow visual > separators? > To be clear, the "global-number" production in RFC 3966 allows for a number of parameters that are not part of the International E.164 format and thus I have two concerns with the current text 1) The visual-separator exclusion although the ABNF allows for it 2) The apparent disconnect between all of these optional extra parameters and the above text suggesting they are not allowed. Thanks -- Flemming > In my understanding the tradeoff is between slightly increased > complexity in parser implementation versus being clear on the syntax. > I would be inclined to prefer the latter. > > Regards, > > Simo > --------------080405050107010403050803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/15/12 4:06 AM, Simo.Veikkolainen@nokia.com wrote:

Hi Flemming, Paul, Keith, and all,

 

When going through http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt for publication, Flemming had a comment on the format of global telephone numbers.

 

The draft currently says in Section 5.2.1:

 

  This memo exclusively uses the international representation of E.164

   numbers, i.e., those initiated with a '+' sign.  The syntax (see

   Section 5.7) refers to the representation of a 'global-number'

   construction already specified in RFC 3966 [RFC3966].  This

   representation requires the presence of the '+' sign.  Additionally,

   this representation allows for the presence of one or more 'visual-

   separator' constructions.  Implementations confirming to this

   specification and using the "E164" address type together with the

   "PSTN" network type MUST only use international E.164, i.e., those

   starting with a '+' sign and SHOULD NOT use visual-separators.

 

This was discussed earlier on the list, see  http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html

 

Flemming’s comment was that referencing to RFC3966 but saying that the syntax is invalid because we only use parts of it is not a good idea.

 

The question is, could we just refer to RFC3966 and allow visual separators?

 

To be clear, the "global-number" production in RFC 3966 allows for a number of parameters that are not part of the International E.164 format and thus I have two concerns with the current text
1) The visual-separator exclusion although the ABNF allows for it
2) The apparent disconnect between all of these optional extra parameters and the above text suggesting they are not allowed.

Thanks

-- Flemming

In my understanding the tradeoff is between slightly increased complexity in parser implementation versus being clear on the syntax. I would be inclined to prefer the latter.

 

Regards,

Simo

 

 

 

 


--------------080405050107010403050803-- From fandreas@cisco.com Thu Nov 15 07:59: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 E5C4621F853B for ; Thu, 15 Nov 2012 07:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48mqzOZ4tBeU for ; Thu, 15 Nov 2012 07:59:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BFFEB21F8514 for ; Thu, 15 Nov 2012 07:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6260; q=dns/txt; s=iport; t=1352995154; x=1354204754; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OpxS+2ogTptQgcrPIMV49kS6GD7qUXONt8MgZRdvjJY=; b=TTbLL1wn4jrt86Sshu7bdeeTVMG1D1Gj5oeU6TZ8b6uY2fcK+Aasw1rx 0P1E9gkFUTK9M/NlH77VNGO8/5hociGkH0BefMPKh0b5dG3QvXrkFzwOv t0bRclySkg2ERfaSedGgdTJ3GTtP3OxLnvSfQyXTtOmR6o46ZUSyzJRYR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHEQpVCtJXG//2dsb2JhbABEwxeBCIIeAQEBAwEMBgEfAQUvEQEFCQILGAkWCAcJAwIBAgEJKxEGDQEFAgEBEAcHh2MGnGqgDASMN4YiA4hajSKOWIFrgw0 X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142847902" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2012 15:59:14 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAFFxCFF032656; Thu, 15 Nov 2012 15:59:13 GMT Message-ID: <50A51150.7070409@cisco.com> Date: Thu, 15 Nov 2012 10:59:12 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <505FD907.9070800@cisco.com> <50771F8D.8040004@cisco.com> <50A50563.2000802@ericsson.com> In-Reply-To: <50A50563.2000802@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05 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 Nov 2012 15:59:16 -0000 On 11/15/12 10:08 AM, Magnus Westerlund wrote: > Hi Flemming, > > Thanks for the comments. > > On 2012-10-11 21:35, Flemming Andreasen wrote: >> I have reviewed the RTSP NAT Evaluation document and have several >> comments on it, both technical and editorial. I will provide the main >> technical comments below and send the minor and editorial comments >> directly to the authors in a more "user-friendly" format. >> >> >> Major comments >> >> - STUN based on either RFC 3489 or RFC 5389 (or both). The draft >> discusses use of STUN as a NAT traversal mechanism (with some RTSP >> operational "extensions"), and in so doing it references both RFC 3489 >> (which is obsolete) and RFC 5389 (the replacement). Furthermore, in >> several places, it bases and describes operation on now defunct >> (obsolete) RFC 3489 logic and messages instead of RFC 5389. This either >> needs to be rectified, or we should have a very good explanation in the >> document as to why we are using RFC 3489 (and then be clear which parts >> are based on RFC 3489 and which are based on RFC 5389). > I intended to go with an background explanation. This document was > evaluating RTSP NAT proposals at a time and in a context which is > significantly before RFC 5389. Yes, the limits to the classification > techniques exist and should be correctly described. But the fact that > they was considered can not be undone in a document intended to document > the considerations done at that time of picking ICE as a solution. Which > is now 7+ year into history. Perhaps this is a more general question since we have at least other document in the WG with a similar issue: - For documents that have been underway for a long time, and the technology/references they describe has since evolved, should we base this on the original technology and knowledge at the time or should it reflect the state of affairs at time of publication ? I tend to think it should be the latter, although I don't see anything with also including references to older technology, as long as the limitations are noted, the new technology is called out, and we don't make any normative recommendations around use of the old technology unless there is a very good reason to do so. In the specific case, is there any particular reason (apart from this obviously being more/new work again) why we wouldn't reference RFC 5389 at this point and possibly note the limitations of the RFC 3489 approach as well (for background) ? >> - "Symmetric RTP" is called out as a potential solution for NAT >> traversal with 3 different variations. Note that symmetric RTP is >> defined in RFC 4961, and what is described in this document as >> "symmetric RTP" looks a lot more like latching to me, with all the >> potential issues that brings (and then some due to the shared use of >> ports and hence shared SSRC space between different clients, as noted in >> the document). The document needs to clear up its terminology in this >> area ("connect", "binding", latch, symmetric RTP, etc.) and be clearer >> about what is being proposed (which is latching as far as I can tell, >> however it makes reference to certain mechanisms that aren't fully >> described, e.g. binding packets with random nonces). > Yes, it is what called latching today. When this was originally written > latching wasn't called latching in this community. But I will work > through the text to try avoid any missunderstandings. There is after all > a basic requirement on latching that one uses symmetric RTP after the > latching or things don't work. Ok. >> >> Other significant comments >> >> - The draft intends to investigate and outline different RTSP NAT >> traversal proposals with the goal of picking one for further detailed >> specification (which can be found in the draft-ietf-mmusic-rtsp-nat >> spec). There is a mixture of RFC 2119 language and more informal >> language in several of these descriptions. Given that these are >> high-level descriptions and have not been specified in detail, I do not >> think we should give any other impression and hence I think RFC 2119 >> language should be avoided. > Fully agreed. There should be no RFC 2119 language in this doc. > >> - The draft suggests that the RTSP server needs to enforce that >> signaling and media come from the same IP-address as a security remedy >> in several places, however this may not work with larger scale NATs >> (e.g. carrier-grade NATs) where the NAT may be using more than one >> external IP-address. > It is more than a suggestion. It is an fact that servers implements this > protection. If a CGN fails to give a host the same IP address then > unfortunately that client will not get any content. I will claim it is > the CGN that is more broken than the security mechanism. > Ok - I think it's worth calling out explicitly. >> - The comparison section is missing two of the alternatives considered >> (namely ALG and TCP tunneling). Also, the comparison chart would lead >> most people to a different solution than the one chosen. To some extent, >> I think it's because the requirements list is a simplified list of all >> the considerations behind each of the proposals (as more fully explained >> in the document overall). There are additional drawbacks to some of >> these other solutions that do not show up in the table (e.g. >> unauthenticated "latching" and requirement for RTSP server to have >> public IP-address). It would be worthwhile briefly recapping those and >> hence further motivate the choice of ICE in this section. > Ok, will see what I can do with reasonable work effort. Sounds good. Thanks -- Flemming > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > . > From fandreas@cisco.com Thu Nov 15 08:12: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 CB88521F896F for ; Thu, 15 Nov 2012 08:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqtjVPVYCLNw for ; Thu, 15 Nov 2012 08:12:58 -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 B7B6A21F8945 for ; Thu, 15 Nov 2012 08:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9632; q=dns/txt; s=iport; t=1352995978; x=1354205578; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=fVin0hvjWZtKE6vk09L2FBBRdMH/oP7zzQUNcOJk8XU=; b=VXYAcj1qoi41AoVBYxpoJ1myBYPbE7cuA+WG3bz2TmQsa7rZD+eIBQet HtLSeTfyHU/TejAp4rvDwYhm2g7O8XH4Ubai8J/U5NJkfw4Gcwcwl+Lg7 ObSJO4+QL6ZXA7vBAV7lvMKRYUUPscUnFB29emAn9w59Cym1aa4wQiAn0 A=; X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142813181" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 15 Nov 2012 16:12:58 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAFGCvRp010628; Thu, 15 Nov 2012 16:12:57 GMT Message-ID: <50A51489.9060506@cisco.com> Date: Thu, 15 Nov 2012 11:12:57 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> In-Reply-To: <50A4AE7F.4040403@alvestrand.no> Content-Type: multipart/alternative; boundary="------------060506010702050700040409" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 16:12:59 -0000 This is a multi-part message in MIME format. --------------060506010702050700040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/15/12 3:57 AM, Harald Alvestrand wrote: > Found some answers in RFC 3264. > That's the right place to look assuming this is all for use in an Offer/Answer context. > On 11/15/2012 09:47 AM, Harald Alvestrand wrote: >> I've been searching RFC 4566 (SDP) for this info, but came up blank.... >> >> in an M-line, we typically have >> >> m=video blabla 111 112 113 >> a=rtpmap:111 .... >> a=rtpmap:112 ... >> a=rtpmap:113 .... >> >> Section 5.14 says this: >> >> If the sub-field is "RTP/AVP" or "RTP/SAVP" the >> sub-fields contain RTP payload type numbers. When a list of >> payload type numbers is given, this implies that all of these >> payload formats MAY be used in the session, but the first of these >> formats SHOULD be used as the default format for the session. >> >> Now, the questions... >> >> 1) In offer/answer, does this sequence in an offer mean that the >> offerer prefers that the answerer use codec 111, if supported? > > 3264 5.1: > > In all cases, the formats in the "m=" line MUST be listed in order of > preference, with the first format listed being preferred. In this > case, preferred means that the recipient of the offer SHOULD use the > format with the highest preference that is acceptable to it. > >> >> 2) in offer/answer, does this sequence in an answer mean that the >> answerer prefers that the offerer use codec 111? > 3264 6.1: > > The > media formats in the "m=" line MUST be listed in order of preference, > with the first format listed being preferred. In this case, > preferred means that the offerer SHOULD use the format with the > highest preference from the answer. > > >> >> 3) is there any preference expressed between codec 112 and codec 113? > Clear from 3264. If we ever update 4566, might want to harmonize those. 4566bis is work-in-progress - do you see a disconnect between 4566 and 3264 (or are you just looking to repeat the information in 4566) ? >> >> 4) Should the sequence of a=rtpmap: lines be completely ignored, or >> does it matter? > > I hope the answer is "completely ignored", have found no evidence to > the contrary. > It should not matter, but I don't think we have any text explicitly stating that anywhere. -- Flemming >> >> I'm trying to fix a bug, and want to make sure I fix it according to >> spec. >> >> Harald >> >> >> >> >> >> _______________________________________________ >> 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 --------------060506010702050700040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/15/12 3:57 AM, Harald Alvestrand wrote:
Found some answers in RFC 3264.

That's the right place to look assuming this is all for use in an Offer/Answer context.


On 11/15/2012 09:47 AM, Harald Alvestrand wrote:
I've been searching RFC 4566 (SDP) for this info, but came up blank....

in an M-line, we typically have

m=video blabla 111 112 113
a=rtpmap:111 ....
a=rtpmap:112 ...
a=rtpmap:113 ....

Section 5.14 says this:

      If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
      sub-fields contain RTP payload type numbers.  When a list of
      payload type numbers is given, this implies that all of these
      payload formats MAY be used in the session, but the first of these
      formats SHOULD be used as the default format for the session.
Now, the questions...

1) In offer/answer, does this sequence in an offer mean that the offerer prefers that the answerer use codec 111, if supported?

3264 5.1:

   In all cases, the formats in the "m=" line MUST be listed in order of
   preference, with the first format listed being preferred.  In this
   case, preferred means that the recipient of the offer SHOULD use the
   format with the highest preference that is acceptable to it.


2) in offer/answer, does this sequence in an answer mean that the answerer prefers that the offerer use codec 111?
3264 6.1:

  The
   media formats in the "m=" line MUST be listed in order of preference,
   with the first format listed being preferred.  In this case,
   preferred means that the offerer SHOULD use the format with the
   highest preference from the answer.



3) is there any preference expressed between codec 112 and codec 113?
Clear from 3264. If we ever update 4566, might want to harmonize those.
4566bis is work-in-progress - do you see a disconnect between 4566 and 3264 (or are you just looking to repeat the information in 4566) ?


4) Should the sequence of a=rtpmap: lines be completely ignored, or does it matter?

I hope the answer is "completely ignored", have found no evidence to the contrary.

It should not matter, but I don't think we have any text explicitly stating that anywhere.

-- Flemming



I'm trying to fix a bug, and want to make sure I fix it according to spec.

               Harald





_______________________________________________
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

--------------060506010702050700040409-- From adam@nostrum.com Thu Nov 15 08:38: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 DA2CA21F853C for ; Thu, 15 Nov 2012 08:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFjQqxI5bYBV for ; Thu, 15 Nov 2012 08:37:59 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A164B21F8512 for ; Thu, 15 Nov 2012 08:37:59 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAFGbr0O069597 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 10:37:53 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A51A61.1070905@nostrum.com> Date: Thu, 15 Nov 2012 10:37:53 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <50A50F77.7060906@cisco.com> In-Reply-To: <50A50F77.7060906@cisco.com> Content-Type: multipart/alternative; boundary="------------000304020805050108080405" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 16:38:01 -0000 This is a multi-part message in MIME format. --------------000304020805050108080405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/15/12 09:51, Flemming Andreasen wrote: > To be clear, the "global-number" production in RFC 3966 allows for a > number of parameters that are not part of the International E.164 > format and thus I have two concerns with the current text > 1) The visual-separator exclusion although the ABNF allows for it > 2) The apparent disconnect between all of these optional extra > parameters and the above text suggesting they are not allowed. I don't think these really are issues. There are a lot of specifications where the ABNF would allow for certain productions, while the normative specification making use of that ABNF restricts those productions. For example, there is nothing in the ABNF of RFC 3261 that restricts SIP messages from having multiple CSeq header fields, although it doing so certainly isn't allowed. /a --------------000304020805050108080405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/15/12 09:51, Flemming Andreasen wrote:
To be clear, the "global-number" production in RFC 3966 allows for a number of parameters that are not part of the International E.164 format and thus I have two concerns with the current text
  1) The visual-separator exclusion although the ABNF allows for it
2) The apparent disconnect between all of these optional extra parameters and the above text suggesting they are not allowed.

I don't think these really are issues. There are a lot of specifications where the ABNF would allow for certain productions, while the normative specification making use of that ABNF restricts those productions. For example, there is nothing in the ABNF of RFC 3261 that restricts SIP messages from having multiple CSeq header fields, although it doing so certainly isn't allowed.

/a
--------------000304020805050108080405-- From pkyzivat@alum.mit.edu Thu Nov 15 08:43: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 9EA9921F86D1 for ; Thu, 15 Nov 2012 08:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfhzKlRi3kIU for ; Thu, 15 Nov 2012 08:43:50 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 95AE021F867F for ; Thu, 15 Nov 2012 08:43:49 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id Po9M1k0011GhbT85FsjoVr; Thu, 15 Nov 2012 16:43:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id Psjo1k00w3ZTu2S3TsjovW; Thu, 15 Nov 2012 16:43:48 +0000 Message-ID: <50A51BC3.5010503@alum.mit.edu> Date: Thu, 15 Nov 2012 11:43:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A50F77.7060906@cisco.com> In-Reply-To: <50A50F77.7060906@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 16:43:50 -0000 At end... On 11/15/12 10:51 AM, Flemming Andreasen wrote: > > On 11/15/12 4:06 AM, Simo.Veikkolainen@nokia.com wrote: >> >> Hi Flemming, Paul, Keith, and all, >> >> When going through >> http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt >> for >> publication, Flemming had a comment on the format of global telephone >> numbers. >> >> The draft currently says in Section 5.2.1: >> >> This memo exclusively uses the international representation of E.164 >> >> numbers, i.e., those initiated with a '+' sign. The syntax (see >> >> Section 5.7) refers to the representation of a 'global-number' >> >> construction already specified in RFC 3966 [RFC3966]. This >> >> representation requires the presence of the '+' sign. Additionally, >> >> this representation allows for the presence of one or more 'visual- >> >> separator' constructions. Implementations confirming to this >> >> specification and using the "E164" address type together with the >> >> "PSTN" network type MUST only use international E.164, i.e., those >> >> starting with a '+' sign and SHOULD NOT use visual-separators. >> >> This was discussed earlier on the list, see >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html >> >> Flemming’s comment was that referencing to RFC3966 but saying that the >> syntax is invalid because we only use parts of it is not a good idea. >> >> The question is, could we just refer to RFC3966 and allow visual >> separators? >> > To be clear, the "global-number" production in RFC 3966 allows for a > number of parameters that are not part of the International E.164 format > and thus I have two concerns with the current text > 1) The visual-separator exclusion although the ABNF allows for it > 2) The apparent disconnect between all of these optional extra > parameters and the above text suggesting they are not allowed. IIRC there was discussion on this. There are a number of symbols defined in 3966 that *could* be used here: telephone-subscriber, global-number, global-number-digits. All of them permit separators. Which one to choose depends on how much flexibility one wants to permit. The flexibility brings with it more parsing demands which people might object to if the flexibility will never be used. I don't really care which one it is. global-number-digits is probably enough for common uses. Thanks, Paul From internet-drafts@ietf.org Thu Nov 15 08:43: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 2DE4521F88DE; Thu, 15 Nov 2012 08:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvIQLdonHfyx; Thu, 15 Nov 2012 08:43:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14A821F88A9; Thu, 15 Nov 2012 08:43:55 -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.36 Message-ID: <20121115164355.9950.57327.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 08:43:55 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-14.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, 15 Nov 2012 16:43:56 -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 Wor= king Group of the IETF. Title : A Network Address Translator (NAT) Traversal mechanism f= or media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-14.txt Pages : 31 Date : 2012-11-15 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Thu Nov 15 08:57: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 5D42D21F84F3 for ; Thu, 15 Nov 2012 08:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdJ-0igPjV9U for ; Thu, 15 Nov 2012 08:57:42 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 979EA21F8AFC for ; Thu, 15 Nov 2012 08:57:42 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id PnTL1k0021swQuc59sxiD4; Thu, 15 Nov 2012 16:57:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id Psxh1k00l3ZTu2S3bsxhuN; Thu, 15 Nov 2012 16:57:41 +0000 Message-ID: <50A51F04.5090502@alum.mit.edu> Date: Thu, 15 Nov 2012 11:57:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> In-Reply-To: <50A4AE7F.4040403@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 16:57:43 -0000 Harald, While the specs aren't entirely clear, after some searching and study they become *reasonably* clear as you have found. But this is only true in the context of a particular usage profile - that the RTP session will contain only one RTP stream, and that stream will use only a single codec. If you move outside of that usage profile then the existing text is really deficient. And we are often outside that profile. One example is telephone-events. That is a separate "codec" that is never used alone, it is always used in conjunction with another codec. You may prefer G711 for most audio, but still prefer telephone-events for DTMF tones. The whole notion of codec preference breaks down even more for multiplexed streams. You may very explicitly prefer/require different streams to use different codecs. So I don't think we can rely too much on parsing the existing text for guidance on how to use SDP to represent multiplexed sessions. (Unless of course we use bundle, with a separate m-line for each stream.) AFAIK we are breaking new ground here. Thanks, Paul On 11/15/12 3:57 AM, Harald Alvestrand wrote: > Found some answers in RFC 3264. > > On 11/15/2012 09:47 AM, Harald Alvestrand wrote: >> I've been searching RFC 4566 (SDP) for this info, but came up blank.... >> >> in an M-line, we typically have >> >> m=video blabla 111 112 113 >> a=rtpmap:111 .... >> a=rtpmap:112 ... >> a=rtpmap:113 .... >> >> Section 5.14 says this: >> >> If the sub-field is "RTP/AVP" or "RTP/SAVP" the >> sub-fields contain RTP payload type numbers. When a list of >> payload type numbers is given, this implies that all of these >> payload formats MAY be used in the session, but the first of these >> formats SHOULD be used as the default format for the session. >> >> Now, the questions... >> >> 1) In offer/answer, does this sequence in an offer mean that the >> offerer prefers that the answerer use codec 111, if supported? > > 3264 5.1: > > In all cases, the formats in the "m=" line MUST be listed in order of > preference, with the first format listed being preferred. In this > case, preferred means that the recipient of the offer SHOULD use the > format with the highest preference that is acceptable to it. > > >> >> 2) in offer/answer, does this sequence in an answer mean that the >> answerer prefers that the offerer use codec 111? > 3264 6.1: > > The > media formats in the "m=" line MUST be listed in order of preference, > with the first format listed being preferred. In this case, > preferred means that the offerer SHOULD use the format with the > highest preference from the answer. > > > >> >> 3) is there any preference expressed between codec 112 and codec 113? > Clear from 3264. If we ever update 4566, might want to harmonize those. >> >> 4) Should the sequence of a=rtpmap: lines be completely ignored, or >> does it matter? > > I hope the answer is "completely ignored", have found no evidence to the > contrary. > >> >> I'm trying to fix a bug, and want to make sure I fix it according to spec. >> >> Harald >> >> >> >> >> >> _______________________________________________ >> 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 carl_klatsky@cable.comcast.com Thu Nov 15 09:48: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 788E221F89E4 for ; Thu, 15 Nov 2012 09:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=2.912, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJB5gx3hhiSH for ; Thu, 15 Nov 2012 09:48:37 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A6BD621F8A7B for ; Thu, 15 Nov 2012 09:48:37 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.42054120; Thu, 15 Nov 2012 10:23:30 -0700 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.242]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 12:48:28 -0500 From: "Klatsky, Carl" To: "'mmusic@ietf.org'" Thread-Topic: Multiple media streams in SDP Thread-Index: Ac3DWWnuwzmY26JqRPGci3acuFs8OA== Date: Thu, 15 Nov 2012 17:48:27 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E8773820390@PACDCEXMB15.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.176] Content-Type: multipart/alternative; boundary="_000_6C15A6B88541034E912E94C2D8BC3E8773820390PACDCEXMB15cabl_" MIME-Version: 1.0 Subject: [MMUSIC] Multiple media streams in 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 Nov 2012 17:48:38 -0000 --_000_6C15A6B88541034E912E94C2D8BC3E8773820390PACDCEXMB15cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Question on the use of multiple media stream in SDP. When multiple streams= each of (more than one m=3D line) of type RTP/AVP are offered and answere= d, does that imply that the RTP media packets for each stream gets their ow= n unique synchronization source (SSRC) identifier? Regards, Carl Klatsky --_000_6C15A6B88541034E912E94C2D8BC3E8773820390PACDCEXMB15cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Question on the use of multiple media stream in SDP.=   When multiple streams each of  (more than one m=3D line) of typ= e RTP/AVP are offered and answered, does that imply that the RTP media pack= ets for each stream gets their own unique synchronization source (SSRC) identifier?

 

Regards,

 

Carl Klatsky

 

--_000_6C15A6B88541034E912E94C2D8BC3E8773820390PACDCEXMB15cabl_-- From fandreas@cisco.com Thu Nov 15 09:58: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 47C9921F8947 for ; Thu, 15 Nov 2012 09:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoiEhL+cCUgY for ; Thu, 15 Nov 2012 09:58:33 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49D21F88A9 for ; Thu, 15 Nov 2012 09:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4162; q=dns/txt; s=iport; t=1353002312; x=1354211912; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7hmK5UoEhGPJsuRBk7/ezu5QkCIrxvnquIuNlRNXGxM=; b=QV3xwTMnLXqYKJiADm0PQm1a0JUVVjXdaIHPe+IEy8yngCFR6sjY94GG uMBmlOnMJdSOaRxugT9j5UeUf6/9ppyZltt6fY9Xhu6wAJGug03Onr0SG nLNkqN8lnS1t4ET5TT4OH6Q340iViZnNyGR6BNyxJADC/+BxjlGPraFJt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAKMspVCtJXG+/2dsb2JhbABEi3yyfINEgQiCHgEBAQQSAWUBEAsEFAkWDwkDAgECAUUGDQEHAQEeh2ucfaAJkl0DiFqNIo5YgWuDDQ X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142649505" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2012 17:58:32 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFHwUFL002978; Thu, 15 Nov 2012 17:58:31 GMT Message-ID: <50A52D46.5020803@cisco.com> Date: Thu, 15 Nov 2012 12:58:30 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Roach References: <50A50F77.7060906@cisco.com> <50A51A61.1070905@nostrum.com> In-Reply-To: <50A51A61.1070905@nostrum.com> Content-Type: multipart/alternative; boundary="------------030504080208070505050003" Cc: keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 17:58:34 -0000 This is a multi-part message in MIME format. --------------030504080208070505050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/15/12 11:37 AM, Adam Roach wrote: > On 11/15/12 09:51, Flemming Andreasen wrote: >> To be clear, the "global-number" production in RFC 3966 allows for a >> number of parameters that are not part of the International E.164 >> format and thus I have two concerns with the current text >> 1) The visual-separator exclusion although the ABNF allows for it >> 2) The apparent disconnect between all of these optional extra >> parameters and the above text suggesting they are not allowed. > > I don't think these really are issues. There are a lot of > specifications where the ABNF would allow for certain productions, > while the normative specification making use of that ABNF restricts > those productions. For example, there is nothing in the ABNF of RFC > 3261 that restricts SIP messages from having multiple CSeq header > fields, although it doing so certainly isn't allowed. > I think there is a big difference between having an ABNF that includes terminals and non-terminals in productions that may not be used at all as opposed to having an ABNF with certain semantic restrictions on what constitutes valid semantic values based on otherwise valid syntax. The former is generally well understood and accepted whereas the latter is not (and for good reason IMO - what's the point of having an ABNF otherwise ?). -- Flemming > /a --------------030504080208070505050003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/15/12 11:37 AM, Adam Roach wrote:
On 11/15/12 09:51, Flemming Andreasen wrote:
To be clear, the "global-number" production in RFC 3966 allows for a number of parameters that are not part of the International E.164 format and thus I have two concerns with the current text
  1) The visual-separator exclusion although the ABNF allows for it
2) The apparent disconnect between all of these optional extra parameters and the above text suggesting they are not allowed.

I don't think these really are issues. There are a lot of specifications where the ABNF would allow for certain productions, while the normative specification making use of that ABNF restricts those productions. For example, there is nothing in the ABNF of RFC 3261 that restricts SIP messages from having multiple CSeq header fields, although it doing so certainly isn't allowed.


I think there is a big difference between having an ABNF that includes terminals and non-terminals in productions that may not be used at all as opposed to having an ABNF with certain semantic restrictions on what constitutes valid semantic values based on otherwise valid syntax. The former is generally well understood and accepted whereas the latter is not (and for good reason IMO - what's the point of having an ABNF otherwise ?).

-- Flemming

/a

--------------030504080208070505050003-- From adam@nostrum.com Thu Nov 15 10:25: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 83EF421F8618 for ; Thu, 15 Nov 2012 10:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SobI4KqWYkY for ; Thu, 15 Nov 2012 10:25:01 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BDFFB21F85B3 for ; Thu, 15 Nov 2012 10:25:00 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAFIOmdb080277 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 12:24:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A53370.3010906@nostrum.com> Date: Thu, 15 Nov 2012 12:24:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <50A50F77.7060906@cisco.com> <50A51A61.1070905@nostrum.com> <50A52D46.5020803@cisco.com> In-Reply-To: <50A52D46.5020803@cisco.com> Content-Type: multipart/alternative; boundary="------------010108000807070204030605" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 18:25:01 -0000 This is a multi-part message in MIME format. --------------010108000807070204030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/15/12 11:58, Flemming Andreasen wrote: > > On 11/15/12 11:37 AM, Adam Roach wrote: >> >> I don't think these really are issues. There are a lot of >> specifications where the ABNF would allow for certain productions, >> while the normative specification making use of that ABNF restricts >> those productions. For example, there is nothing in the ABNF of RFC >> 3261 that restricts SIP messages from having multiple CSeq header >> fields, although it doing so certainly isn't allowed. >> > > I think there is a big difference between having an ABNF that includes > terminals and non-terminals in productions that may not be used at all > as opposed to having an ABNF with certain semantic restrictions on > what constitutes valid semantic values based on otherwise valid > syntax. The former is generally well understood and accepted whereas > the latter is not (and for good reason IMO - what's the point of > having an ABNF otherwise ?). You raise a good point. So, yeah, it looks like we probably want to take on an existing ABNF (with all its warts and optional things) or define our own (which would be trivial -- a plus sign followed by one or more digits is some of the most straightforward ABNF you'll ever see written). /a --------------010108000807070204030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/15/12 11:58, Flemming Andreasen wrote:

On 11/15/12 11:37 AM, Adam Roach wrote:

I don't think these really are issues. There are a lot of specifications where the ABNF would allow for certain productions, while the normative specification making use of that ABNF restricts those productions. For example, there is nothing in the ABNF of RFC 3261 that restricts SIP messages from having multiple CSeq header fields, although it doing so certainly isn't allowed.


I think there is a big difference between having an ABNF that includes terminals and non-terminals in productions that may not be used at all as opposed to having an ABNF with certain semantic restrictions on what constitutes valid semantic values based on otherwise valid syntax. The former is generally well understood and accepted whereas the latter is not (and for good reason IMO - what's the point of having an ABNF otherwise ?).
You raise a good point. So, yeah, it looks like we probably want to take on an existing ABNF (with all its warts and optional things) or define our own (which would be trivial -- a plus sign followed by one or more digits is some of the most straightforward ABNF you'll ever see written).

/a
--------------010108000807070204030605-- From adam@nostrum.com Thu Nov 15 11:55: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 A906821F8522 for ; Thu, 15 Nov 2012 11:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJscDpV1TeqA for ; Thu, 15 Nov 2012 11:55:14 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9290E21F8421 for ; Thu, 15 Nov 2012 11:55:14 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAFJt1GH089083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 13:55:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A54895.7030006@nostrum.com> Date: Thu, 15 Nov 2012 13:55:01 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> In-Reply-To: <50A51F04.5090502@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 19:55:15 -0000 On 11/15/12 10:57, Paul Kyzivat wrote: > The whole notion of codec preference breaks down even more for > multiplexed streams. You may very explicitly prefer/require different > streams to use different codecs. > > So I don't think we can rely too much on parsing the existing text for > guidance on how to use SDP to represent multiplexed sessions. (Unless > of course we use bundle, with a separate m-line for each stream.) > AFAIK we are breaking new ground here. This kind of "we fixed this problem once and get to fix it all over again" issue is exactly the kind of thing I was speaking to at the microphone in MMUSIC in Atlanta. The further we drift from the established semantics of SDP, the less applicable previously developed mechanisms become. Bundle and similar approaches that maintain one m= line per stream allow us to leverage 14 years of extensions and clarifications. If we decide to split from that (rather fundamental, IMHO) characteristic of SDP, we are effectively forking the protocol, and throwing away years of prior work. /a From pkyzivat@alum.mit.edu Thu Nov 15 12:09: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 BE72221F85CC for ; Thu, 15 Nov 2012 12:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anNUSe7VDmRK for ; Thu, 15 Nov 2012 12:09:38 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 0F66A21F8477 for ; Thu, 15 Nov 2012 12:09:37 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id Pnjf1k0041vXlb851w9dWb; Thu, 15 Nov 2012 20:09:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Pw9d1k00D3ZTu2S3dw9dRE; Thu, 15 Nov 2012 20:09:37 +0000 Message-ID: <50A54C00.1060008@alum.mit.edu> Date: Thu, 15 Nov 2012 15:09:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A50F77.7060906@cisco.com> <50A51A61.1070905@nostrum.com> <50A52D46.5020803@cisco.com> In-Reply-To: <50A52D46.5020803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 20:09:38 -0000 On 11/15/12 12:58 PM, Flemming Andreasen wrote: > > On 11/15/12 11:37 AM, Adam Roach wrote: >> On 11/15/12 09:51, Flemming Andreasen wrote: >>> To be clear, the "global-number" production in RFC 3966 allows for a >>> number of parameters that are not part of the International E.164 >>> format and thus I have two concerns with the current text >>> 1) The visual-separator exclusion although the ABNF allows for it >>> 2) The apparent disconnect between all of these optional extra >>> parameters and the above text suggesting they are not allowed. >> >> I don't think these really are issues. There are a lot of >> specifications where the ABNF would allow for certain productions, >> while the normative specification making use of that ABNF restricts >> those productions. For example, there is nothing in the ABNF of RFC >> 3261 that restricts SIP messages from having multiple CSeq header >> fields, although it doing so certainly isn't allowed. >> > > I think there is a big difference between having an ABNF that includes > terminals and non-terminals in productions that may not be used at all > as opposed to having an ABNF with certain semantic restrictions on what > constitutes valid semantic values based on otherwise valid syntax. The > former is generally well understood and accepted whereas the latter is > not (and for good reason IMO - what's the point of having an ABNF > otherwise ?). Yes, I agree that this kind of constraint is a bit more of a stretch than the usual sort of things we revert to text for. (But I often have to make a tradeoff when constructing ABNF, between constraints that *can* be done syntactically with complex ANBF, and more forgiving ABNF and textual constraints.) This is at least the third place I have come across in the last few months that had a need to represent a phone number, and where a reference into the 3966 ABNF could *almost* fit the bill. The last time was with TERQ. There I raised the possibility to Jon P that maybe it is time to revise 3966, so that it is more suited to being a source of definitions of phone number stuff that can be referenced. I have mixed feelings about that - I think it would be a good thing to do, but I don't know how many will consider it worth the trouble. Thanks, Paul From pkyzivat@alum.mit.edu Thu Nov 15 12:16: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 01BC421F8552 for ; Thu, 15 Nov 2012 12:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9rRvFbYNohq for ; Thu, 15 Nov 2012 12:16:20 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6069E21F857D for ; Thu, 15 Nov 2012 12:16:20 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id PnQJ1k0090bG4ec51wGK7y; Thu, 15 Nov 2012 20:16:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id PwGK1k00m3ZTu2S3PwGKmQ; Thu, 15 Nov 2012 20:16:19 +0000 Message-ID: <50A54D92.9010108@alum.mit.edu> Date: Thu, 15 Nov 2012 15:16:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adam Roach References: <50A50F77.7060906@cisco.com> <50A51A61.1070905@nostrum.com> <50A52D46.5020803@cisco.com> <50A53370.3010906@nostrum.com> In-Reply-To: <50A53370.3010906@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 20:16:21 -0000 On 11/15/12 1:24 PM, Adam Roach wrote: > On 11/15/12 11:58, Flemming Andreasen wrote: >> >> On 11/15/12 11:37 AM, Adam Roach wrote: >>> >>> I don't think these really are issues. There are a lot of >>> specifications where the ABNF would allow for certain productions, >>> while the normative specification making use of that ABNF restricts >>> those productions. For example, there is nothing in the ABNF of RFC >>> 3261 that restricts SIP messages from having multiple CSeq header >>> fields, although it doing so certainly isn't allowed. >>> >> >> I think there is a big difference between having an ABNF that includes >> terminals and non-terminals in productions that may not be used at all >> as opposed to having an ABNF with certain semantic restrictions on >> what constitutes valid semantic values based on otherwise valid >> syntax. The former is generally well understood and accepted whereas >> the latter is not (and for good reason IMO - what's the point of >> having an ABNF otherwise ?). > You raise a good point. So, yeah, it looks like we probably want to take > on an existing ABNF (with all its warts and optional things) or define > our own (which would be trivial -- a plus sign followed by one or more > digits is some of the most straightforward ABNF you'll ever see written). Yes, that is where this draft started. (Without the "+".) Certainly it would "work". But it seems wrong to me. There ought to be an authoritative source for the syntax. Also, I wonder if some of that extra syntax might actually be useful in getting the CS call established in special situations. Maybe even local numbers might be useful in some situations. I'll admit that the separators are not *necessary* in any case. But forbidding those might just mean that the application will need to add code to strip them from whatever source it uses for its local number. At least this way its better defined what should be stripped. Thanks, Paul From pkyzivat@alum.mit.edu Thu Nov 15 13:32:55 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AD421F8AFA for ; Thu, 15 Nov 2012 13:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiJZHeTWp6A1 for ; Thu, 15 Nov 2012 13:32:54 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B021F89AA for ; Thu, 15 Nov 2012 13:32:41 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id Po0B1k0040Fqzac55xYhsA; Thu, 15 Nov 2012 21:32:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id PxYg1k00K3ZTu2S3UxYg6H; Thu, 15 Nov 2012 21:32:41 +0000 Message-ID: <50A55F78.4010603@alum.mit.edu> Date: Thu, 15 Nov 2012 16:32:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adam Roach References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> In-Reply-To: <50A54895.7030006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 21:32:55 -0000 On 11/15/12 2:55 PM, Adam Roach wrote: > On 11/15/12 10:57, Paul Kyzivat wrote: >> The whole notion of codec preference breaks down even more for >> multiplexed streams. You may very explicitly prefer/require different >> streams to use different codecs. >> >> So I don't think we can rely too much on parsing the existing text for >> guidance on how to use SDP to represent multiplexed sessions. (Unless >> of course we use bundle, with a separate m-line for each stream.) >> AFAIK we are breaking new ground here. > > This kind of "we fixed this problem once and get to fix it all over > again" issue is exactly the kind of thing I was speaking to at the > microphone in MMUSIC in Atlanta. The further we drift from the > established semantics of SDP, the less applicable previously developed > mechanisms become. Bundle and similar approaches that maintain one m= > line per stream allow us to leverage 14 years of extensions and > clarifications. If we decide to split from that (rather fundamental, > IMHO) characteristic of SDP, we are effectively forking the protocol, > and throwing away years of prior work. I would like to agree with you. But when multiplexing RTP streams it is problematic to prearrange every stream in SDP. That requires knowing in advance how many there will be, what their SSRCs will be, and what the mapping from SSRC to codec will be. We are still thrashing that out for CLUE. We have some use cases where it seems we can't do all of that in advance, and doing an O/A after we get packets is too late. Maybe we will find a way around that. Too early to tell. And AFAIK RTCWEB has only been planning to use bundle to give a separate m-line for audio and one for video, not necessarily a separate one for every media stream. I think there is still an implication that a given m-line might be multiplexed, and might use different codecs (among those that are negotiated) for the different multiplexed streams. And even our 14 years of experience on this haven't resulted in a spec that fully lines up with what is deployed in the wild. There is an assumption in the specs that if you offer multiple codecs and the answer accepts multiple codecs, then you can accept packets in any of the negotiated codecs, and switch among them, even though we know implementations that depend on only one codec being used. (With a special case for telephone-events.) We are now encountering applications that have more complex needs than were anticipated over those 14 years. It's nice if we can reuse what we have without change to meet those needs. But lets not constrain new applications to the sorts of things we had in mind 14 years ago. Thanks, Paul From adam@nostrum.com Thu Nov 15 13:53: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 7292F21F8B19 for ; Thu, 15 Nov 2012 13:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXn7sBn32WUP for ; Thu, 15 Nov 2012 13:53:24 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5721F8A48 for ; Thu, 15 Nov 2012 13:53:23 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAFLrJlG000947 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 15:53:19 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A5644F.4010809@nostrum.com> Date: Thu, 15 Nov 2012 15:53:19 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A55F78.4010603@alum.mit.edu> In-Reply-To: <50A55F78.4010603@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 21:53:25 -0000 On 11/15/12 15:32, Paul Kyzivat wrote: > On 11/15/12 2:55 PM, Adam Roach wrote: >> On 11/15/12 10:57, Paul Kyzivat wrote: >>> The whole notion of codec preference breaks down even more for >>> multiplexed streams. You may very explicitly prefer/require different >>> streams to use different codecs. >>> >>> So I don't think we can rely too much on parsing the existing text for >>> guidance on how to use SDP to represent multiplexed sessions. (Unless >>> of course we use bundle, with a separate m-line for each stream.) >>> AFAIK we are breaking new ground here. >> >> This kind of "we fixed this problem once and get to fix it all over >> again" issue is exactly the kind of thing I was speaking to at the >> microphone in MMUSIC in Atlanta. The further we drift from the >> established semantics of SDP, the less applicable previously developed >> mechanisms become. Bundle and similar approaches that maintain one m= >> line per stream allow us to leverage 14 years of extensions and >> clarifications. If we decide to split from that (rather fundamental, >> IMHO) characteristic of SDP, we are effectively forking the protocol, >> and throwing away years of prior work. > > I would like to agree with you. But when multiplexing RTP streams it > is problematic to prearrange every stream in SDP. That requires > knowing in advance how many there will be, what their SSRCs will be, > and what the mapping from SSRC to codec will be. > > We are still thrashing that out for CLUE. We have some use cases where > it seems we can't do all of that in advance, and doing an O/A after we > get packets is too late. Maybe we will find a way around that. Too > early to tell. I need to catch up on CLUE before I can talk to that very much. I'd been pretty much ignoring CLUE; but in Atlanta, it became clear that CLUE's impact was going to seep out into every other working group in RAI. > And AFAIK RTCWEB has only been planning to use bundle to give a > separate m-line for audio and one for video, not necessarily a > separate one for every media stream. I don't think that's a settled question. > And even our 14 years of experience on this haven't resulted in a spec > that fully lines up with what is deployed in the wild. There is an > assumption in the specs that if you offer multiple codecs and the > answer accepts multiple codecs, then you can accept packets in any of > the negotiated codecs, and switch among them, even though we know > implementations that depend on only one codec being used. (With a > special case for telephone-events.) True. It would be good if we could document this set of unstated assumptions as a "current practices" document at some point (note the lack of "best" before "current practices"). > We are now encountering applications that have more complex needs than > were anticipated over those 14 years. It's nice if we can reuse what > we have without change to meet those needs. But lets not constrain new > applications to the sorts of things we had in mind 14 years ago. I don't think it's necessary to do so. I've spent some time thinking on this problem, and have a half-formed proposal that I plan to bring forth once I'm more comfortable that it provides a satisfying user experience. I just think we're rushing down a path of throwing out a lot of good to get rid of a little bit of bad. I'd like to see more discussion around less radical changes to SDP to achieve the goals of CLUE and RTCWEB. /a From eckelcu@cisco.com Thu Nov 15 14:59: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 14FC521F89FF for ; Thu, 15 Nov 2012 14:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n9+Jw-yxoQh for ; Thu, 15 Nov 2012 14:59:15 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB711E8097 for ; Thu, 15 Nov 2012 14:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=930; q=dns/txt; s=iport; t=1353020355; x=1354229955; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yhDx7pP4T9TMVacJ6oQcByCPVP2IYq5PVEQ90OULbaQ=; b=RvcDUSzYtENBORQnyqxrS/Bk1TV6fE0X95XwZ+PKH7u7vMLAQosaZzo2 O3HZhxGoqWYUz1F7c3A9Fch4hYxwEq6FFeH87MJ1sJHXiVTO/D5SqUPJN FdQgCZArjGMGXgC8C3gZDMFv2IEiiWKhPOvgtWaM5UM1SpvCPJRYn53KJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoFAKtypVCtJXHB/2dsb2JhbABEhVa8bIEIgh4BAQEEEgEnSwQCAQgRBAEBCxQJBzIUCQgBAQQBEggah2oBnQ6gAYwxhUthA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142967950" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2012 22:59:15 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAFMxESH008640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 22:59:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 16:59:14 -0600 From: "Charles Eckel (eckelcu)" To: "Klatsky, Carl" , "'mmusic@ietf.org'" Thread-Topic: Multiple media streams in SDP Thread-Index: Ac3DWWnuwzmY26JqRPGci3acuFs8OAAKxJPg Date: Thu, 15 Nov 2012 22:59:14 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882812C9A5@xmb-aln-x08.cisco.com> References: <6C15A6B88541034E912E94C2D8BC3E8773820390@PACDCEXMB15.cable.comcast.com> In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E8773820390@PACDCEXMB15.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--35.861100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Multiple media streams in 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 Nov 2012 22:59:20 -0000 As currently defined (i.e. without SHIM or BUNDLE), each m-line corresponds= to a separate RTP session, each with its own SSRC space. An implementation= would be free to use the same or different SSRCs across RTP sessions, depe= nding on the circumstances. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Klatsky, Carl > Sent: Thursday, November 15, 2012 9:48 AM > To: 'mmusic@ietf.org' > Subject: [MMUSIC] Multiple media streams in SDP >=20 > Hi, >=20 >=20 >=20 > Question on the use of multiple media stream in SDP. When multiple > streams each of (more than one m=3D line) of type RTP/AVP are offered an= d > answered, does that imply that the RTP media packets for each stream gets > their own unique synchronization source (SSRC) identifier? >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Carl Klatsky >=20 >=20 From magnus.westerlund@ericsson.com Fri Nov 16 02:19: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 DA87C21F8C31 for ; Fri, 16 Nov 2012 02:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.163 X-Spam-Level: X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuwyAM2DL6NP for ; Fri, 16 Nov 2012 02:19:55 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A455921F8B89 for ; Fri, 16 Nov 2012 02:19:54 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-45-50a613496f97 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A6.05.06323.94316A05; Fri, 16 Nov 2012 11:19:53 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 16 Nov 2012 11:19:52 +0100 Message-ID: <50A61348.7080600@ericsson.com> Date: Fri, 16 Nov 2012 11:19:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Flemming Andreasen References: <505FD907.9070800@cisco.com> <50771F8D.8040004@cisco.com> <50A50563.2000802@ericsson.com> <50A51150.7070409@cisco.com> In-Reply-To: <50A51150.7070409@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvja6n8LIAgx2TRC3u9r5gsnh/Qddi 6vLHLA7MHlN+b2T1WLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgyFq1ewlywS6Xi0cxe1gbG FbJdjJwcEgImEneOPWeHsMUkLtxbz9bFyMUhJHCSUeLkmZ/MEM5yRondzadYQap4BbQlpn3Y DmazCKhKzDl6jQXEZhOwkLj5o5ENxBYVCJbYc2wtI0S9oMTJmU+Aajg4RIB6py6wAAkzC4RK 3Ht7AaxEWMBdon/dVjBbSKCJUeLd7AoQm1NAU6L9/SFmiOMkJd6+f8UM0asnMeVqCyOELS/R vHU2M0SvtkRDUwfrBEahWUg2z0LSMgtJywJG5lWM7LmJmTnp5eabGIHBe3DLb4MdjJvuix1i lOZgURLn1VPd7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcVKEYFHH5ZvbH05K42EMyt67 NOKmjn7Ft5b4CU+Wv45LfGv37KpK/PVw83dO24VZv4oJBx8U26heJ/b295YWByerAIWKc0nM sQv2LtaTYEplqXvewlr0TtSuQ/Ol5uSpMfeFpt5MEt7+b9G94ual/U2SB7g4smp07GbOiG2e 6mp+k2vHrxecSizFGYmGWsxFxYkALhsCtCwCAAA= Cc: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05 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 Nov 2012 10:19:56 -0000 On 2012-11-15 16:59, Flemming Andreasen wrote: > > On 11/15/12 10:08 AM, Magnus Westerlund wrote: >> Hi Flemming, >> >> Thanks for the comments. >> >> On 2012-10-11 21:35, Flemming Andreasen wrote: >>> - STUN based on either RFC 3489 or RFC 5389 (or both). The draft >>> discusses use of STUN as a NAT traversal mechanism (with some RTSP >>> operational "extensions"), and in so doing it references both RFC 3489 >>> (which is obsolete) and RFC 5389 (the replacement). Furthermore, in >>> several places, it bases and describes operation on now defunct >>> (obsolete) RFC 3489 logic and messages instead of RFC 5389. This either >>> needs to be rectified, or we should have a very good explanation in the >>> document as to why we are using RFC 3489 (and then be clear which parts >>> are based on RFC 3489 and which are based on RFC 5389). >> I intended to go with an background explanation. This document was >> evaluating RTSP NAT proposals at a time and in a context which is >> significantly before RFC 5389. Yes, the limits to the classification >> techniques exist and should be correctly described. But the fact that >> they was considered can not be undone in a document intended to document >> the considerations done at that time of picking ICE as a solution. Which >> is now 7+ year into history. > Perhaps this is a more general question since we have at least other > document in the WG with a similar issue: > > - For documents that have been underway for a long time, and the > technology/references they describe has since evolved, should we base > this on the original technology and knowledge at the time or should it > reflect the state of affairs at time of publication ? > > I tend to think it should be the latter, although I don't see anything > with also including references to older technology, as long as the > limitations are noted, the new technology is called out, and we don't > make any normative recommendations around use of the old technology > unless there is a very good reason to do so. I would tend to agree with you. At the same time I am feeling the authors pain with having to make substantial changes to the document which likely was correct, but which requires more work due to the slow publication of the document. And in retrospect we probably should have published this document a long time ago. It isn't really dependent on the technical specifications. > > In the specific case, is there any particular reason (apart from this > obviously being more/new work again) why we wouldn't reference RFC 5389 > at this point and possibly note the limitations of the RFC 3489 approach > as well (for background) ? Not for the functionality that is present in RFC 5389 I don't see any issues. But for this document, I will clearly be required to reference both. >>> >>> Other significant comments >>> >>> - The draft intends to investigate and outline different RTSP NAT >>> traversal proposals with the goal of picking one for further detailed >>> specification (which can be found in the draft-ietf-mmusic-rtsp-nat >>> spec). There is a mixture of RFC 2119 language and more informal >>> language in several of these descriptions. Given that these are >>> high-level descriptions and have not been specified in detail, I do not >>> think we should give any other impression and hence I think RFC 2119 >>> language should be avoided. >> Fully agreed. There should be no RFC 2119 language in this doc. >> >>> - The draft suggests that the RTSP server needs to enforce that >>> signaling and media come from the same IP-address as a security remedy >>> in several places, however this may not work with larger scale NATs >>> (e.g. carrier-grade NATs) where the NAT may be using more than one >>> external IP-address. >> It is more than a suggestion. It is an fact that servers implements this >> protection. If a CGN fails to give a host the same IP address then >> unfortunately that client will not get any content. I will claim it is >> the CGN that is more broken than the security mechanism. >> > Ok - I think it's worth calling out explicitly. Sure. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From soohongp@gmail.com Fri Nov 16 18:41: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 94E0A21F8B05; Fri, 16 Nov 2012 18:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.008 X-Spam-Level: * X-Spam-Status: No, score=1.008 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01s7rnIu2zN0; Fri, 16 Nov 2012 18:41:27 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6DF221F8AE4; Fri, 16 Nov 2012 18:41:26 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1566266bku.31 for ; Fri, 16 Nov 2012 18:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PVnblALcVJn00mAn81iCggOwy1v7gYwnt77BSC/j5DA=; b=Nn+ThegMmdS2sd7ZjeCyYr/0u/UD5RwQkUswhLW0ETYbGDxYmVQknYbQx3COAmiC3W KCC3LlDqgccNMlbPfB9+sqYQ/l76A0BfsDX5eREnTFirSnYOqkWpUSe3LyQog3BrKcCh B7Dap1146AUuZgo1li/MRymBy9Zux25sSFuS/CnrRziFa42cvBHSml8JhwKesYbePuiR 5ca7tXwl555ThP6krsdlImEVD7GLoSnfjStR45jsxD3Vd+bhD7Q9Tl6FaP5VfudBB8hZ ocgxxc28kEDPuS+CfC5pxeG7+twgUo2V1M9sNQiB1tUEdWfbunLTAi/d6rzcb9oFVydw xuyw== MIME-Version: 1.0 Received: by 10.204.6.87 with SMTP id 23mr2723673bky.78.1353120085816; Fri, 16 Nov 2012 18:41:25 -0800 (PST) Received: by 10.204.60.81 with HTTP; Fri, 16 Nov 2012 18:41:25 -0800 (PST) Date: Sat, 17 Nov 2012 11:41:25 +0900 Message-ID: From: Daniel Park To: mmusic@ietf.org, wg2193@eeca16.sogang.ac.kr, monica@ittimes.co.kr, mskang@kt.co.kr, multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [MMUSIC] (no subject) 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, 17 Nov 2012 02:41:27 -0000 http://www.77wonder.com/wp-content/plugins/akismet/google235.html From soohongp@gmail.com Sat Nov 17 20:37: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 6FA8D21F8593; Sat, 17 Nov 2012 20:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.519 X-Spam-Level: X-Spam-Status: No, score=0.519 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shOBM3sWWcq4; Sat, 17 Nov 2012 20:37:43 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D738921F84BB; Sat, 17 Nov 2012 20:37:42 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1776467bku.31 for ; Sat, 17 Nov 2012 20:37:42 -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 :content-type; bh=BfcEIoeBMwUm/AkmYdQS3lotD5Rv16mHCN7vdFF1OJo=; b=BjoPLKs05oMIuSuxgHHKrCtHwE6AhxMx8A6DvigEhF9OVwkRFknQq87XQprcwcZcv5 iOFlFKXfDC+MbAX8hfIJ2N0oR9ZwCuXVMyY7fFxH0kWqtfFNplncXvk7maBM+L7kbwX5 WFZlS5aW+gZFVKTz/5Yo+RWgmLFtqzmOqDGUtktWeaGO0YOw+NES/rF5yoS30yH9xCZk ylpc1H6IQgUIsAPXTQVS6Jdx7kCXbJBCV64Nv81UmW/+IYnJy6vcYc3YCnGW6zKBX8Qt Lm2uhU3XNCN9oo4g7zW0s0aUsrH+2W+tzDj6OBPQu9U5TuMaWCdmSw6kmx7ForuVvidR r8Xg== MIME-Version: 1.0 Received: by 10.204.4.133 with SMTP id 5mr3711449bkr.21.1353213461950; Sat, 17 Nov 2012 20:37:41 -0800 (PST) Received: by 10.204.60.81 with HTTP; Sat, 17 Nov 2012 20:37:41 -0800 (PST) Received: by 10.204.60.81 with HTTP; Sat, 17 Nov 2012 20:37:41 -0800 (PST) In-Reply-To: References: Date: Sun, 18 Nov 2012 13:37:41 +0900 Message-ID: From: Daniel Park To: mskang@kt.co.kr, mmusic@ietf.org, multimob@ietf.org, monica@ittimes.co.kr, wg2193@eeca16.sogang.ac.kr Content-Type: multipart/alternative; boundary=0015175884c4b4710004cebd8f4b Subject: Re: [MMUSIC] [multimob] (no subject) spam. Please ignore 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 Nov 2012 04:37:44 -0000 --0015175884c4b4710004cebd8f4b Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable I do not know why this mail is forwarded...it is spam..please ignore it. sorry. Soohong Daniel Park from my Galaxy Note 2012. 11. 17. =BF=C0=C0=FC 11:41=BF=A1 "Daniel Park" = =B4=D4=C0=CC =C0=DB=BC=BA: --0015175884c4b4710004cebd8f4b Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

I do not know why this mail is forwarded...it is spam..please ignore it.= sorry.

Soohong Daniel Park from my Galaxy Note

2012. 11. 17. =BF=C0=C0=FC 11:41=BF=A1 "Dan= iel Park" <soohongp@gmail.com= >=B4=D4=C0=CC =C0=DB=BC=BA:
--0015175884c4b4710004cebd8f4b-- From harald@alvestrand.no Sun Nov 18 21:13: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 100EB21F8477 for ; Sun, 18 Nov 2012 21:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.251 X-Spam-Level: X-Spam-Status: No, score=-110.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGC9bb4kiX12 for ; Sun, 18 Nov 2012 21:13:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4E29321F8466 for ; Sun, 18 Nov 2012 21:13:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC1FD39E15B for ; Mon, 19 Nov 2012 06:12:55 +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 wxe1p8Nj0541 for ; Mon, 19 Nov 2012 06:12:54 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9D44B39E091 for ; Mon, 19 Nov 2012 06:12:54 +0100 (CET) Message-ID: <50A9BFD4.3000601@alvestrand.no> Date: Mon, 19 Nov 2012 06:12:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> In-Reply-To: <50A54895.7030006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 05:13:06 -0000 On 11/15/2012 08:55 PM, Adam Roach wrote: > On 11/15/12 10:57, Paul Kyzivat wrote: >> The whole notion of codec preference breaks down even more for >> multiplexed streams. You may very explicitly prefer/require different >> streams to use different codecs. >> >> So I don't think we can rely too much on parsing the existing text >> for guidance on how to use SDP to represent multiplexed sessions. >> (Unless of course we use bundle, with a separate m-line for each >> stream.) AFAIK we are breaking new ground here. > > This kind of "we fixed this problem once and get to fix it all over > again" issue is exactly the kind of thing I was speaking to at the > microphone in MMUSIC in Atlanta. The further we drift from the > established semantics of SDP, the less applicable previously developed > mechanisms become. Bundle and similar approaches that maintain one m= > line per stream allow us to leverage 14 years of extensions and > clarifications. If we decide to split from that (rather fundamental, > IMHO) characteristic of SDP, we are effectively forking the protocol, > and throwing away years of prior work. actually my caricature of the history of SDP is 4 years of multicast, where multiple streams per RTP session was the norm, 10 years of telephony, with only one stream of each type that mattered in each direction, and 12 months of trying to get multiple streams working again. While beating down the resistance of the RTP people against having different media types in one RTP session, I've been told over and over again that having multiple media streams of the *same* media type in one RTP session is just fine and dandy "because that's what we designed RTP to do", and now we're finally getting explicit about addressing the idea of whether we tolerate more than one media stream per - where the only control surface unit that's been used for the 10 years of telephony is the M-line. The M-line is problematic because it binds together multiple things: - A top level media type - A set of parameters for media transmission *in all directions* (bound to payload type) - Transport information (the "RTP session" data) SDP M-lines are already problematic as soon as you want different parameters in the two directions. It only goes downhill from there when one does multiple flows with varying characteristics. As I said in Atlanta: SDP M-lines have been walking with one foot on the "I'm an RTP session" bank of the canal and with the other foot on the "I'm a media stream description" bank of the canal. The canal is growing wider. Fast. From bernard_aboba@hotmail.com Sun Nov 18 22:17: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 6336521F841C for ; Sun, 18 Nov 2012 22:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPLhGI4DWpQS for ; Sun, 18 Nov 2012 22:17:49 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id CFF2D21F8593 for ; Sun, 18 Nov 2012 22:17:48 -0800 (PST) Received: from BLU169-DS7 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Nov 2012 22:17:48 -0800 X-Originating-IP: [24.16.96.166] X-EIP: [eh+oP/pH8a0F+Up+WL/UaauZ273r+0fg] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Adam Roach'" References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A55F78.4010603@alum.mit.edu> <50A5644F.4010809@nostrum.com> In-Reply-To: <50A5644F.4010809@nostrum.com> Date: Sun, 18 Nov 2012 22:18:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIY0NCXfQL/jr3BC5sqZUn4Hq7olwG+Ww+KAdBghisCwzAqgwK1Mx+aAqFoSRiW/U4zUA== Content-Language: en-us X-OriginalArrivalTime: 19 Nov 2012 06:17:48.0295 (UTC) FILETIME=[98C41170:01CDC61D] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Wisdom sought: Prioritization of codecs 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 Nov 2012 06:17:49 -0000 Adam Roach said: "I need to catch up on CLUE before I can talk to that very much. I'd been pretty much ignoring CLUE; but in Atlanta, it became clear that CLUE's impact was going to seep out into every other working group in RAI." [BA] I think it is probably correct to say that the questions asked in CLUE are relevant to many other working groups in RAI, including RTCWEB. Today even a moderately priced computer can support multiple monitors, as well as multiple cameras, each of which can support a layered codec, and the cost of business-grade telepresence systems has come down by an order of magnitude in the last few years. Given these trends, it is inevitable that WebRTC will eventually support these scenarios. Thinking that through now will avoid a lot of pain later. Adam said: "I just think we're rushing down a path of throwing out a lot of good to get rid of a little bit of bad. I'd like to see more discussion around less radical changes to SDP to achieve the goals of CLUE and RTCWEB." [BA] It certainly makes sense to ensure that the WebRTC architecture can handle CLUE scenarios. In fact, I do believe that some basic CLUE scenarios (such as support for multiple cameras and monitors) are already implementable in some WebRTC implementations, without much in the way of SDP or API changes. From Simo.Veikkolainen@nokia.com Mon Nov 19 02:05: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 032C521F84CF for ; Mon, 19 Nov 2012 02:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9nLyWjKo1XB for ; Mon, 19 Nov 2012 02:05:15 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 10A4521F84BA for ; Mon, 19 Nov 2012 02:05:14 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAJA51u4004074; Mon, 19 Nov 2012 12:05:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Nov 2012 12:05:01 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.81]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0318.003; Mon, 19 Nov 2012 10:05:00 +0000 From: To: , Thread-Topic: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs Thread-Index: Ac3DEGXfrPAdBGk/TW6QWq/Xh+eM1gAOKeeAAAGgV4AAAtDFAAAA6yQAAAPk4wAAs0fxsA== Date: Mon, 19 Nov 2012 10:05:00 +0000 Message-ID: References: <50A50F77.7060906@cisco.com> <50A51A61.1070905@nostrum.com> <50A52D46.5020803@cisco.com> <50A53370.3010906@nostrum.com> <50A54D92.9010108@alum.mit.edu> In-Reply-To: <50A54D92.9010108@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+/nZJb9Kg7IgOCD2Iz6qB3pdCaFry0QXOXWt+heZzjv6/j9MtGobVS4cDXyRZluFqU0cOBuR/jmKgjPc8zalLa4V6isfmenIkwANvQtCpRZFOnC2s6Crp7arTHl5Paj/exBWh1uFnubY5FGBRtvu+9aWqEbpxTB3cz7JwbBeOJaCd8Sh0NQTiqke9px/05hMk89FshnZNSfR5aMzf0nJvGjyteeCPN1AWvBsdIydWO/iCLTm728bKv73TBm+JtEmnVziebowGrixHXOgftrRirDhuT2b8VdNE= x-originating-ip: [172.21.81.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2012 10:05:01.0405 (UTC) FILETIME=[56BB90D0:01CDC63D] X-Nokia-AV: Clean Cc: fandreas@cisco.com, keith.drage@ALCATEL-LUCENT.COM, mmusic@ietf.org Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs 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 Nov 2012 10:05:16 -0000 See at the end. -----Original Message----- From: ext Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 15. marraskuuta 2012 22:16 To: Adam Roach Cc: Flemming Andreasen; Veikkolainen Simo (Nokia-CTO/Espoo); keith.drage@AL= CATEL-LUCENT.COM; mmusic@ietf.org Subject: Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-= cs On 11/15/12 1:24 PM, Adam Roach wrote: > On 11/15/12 11:58, Flemming Andreasen wrote: >> >> On 11/15/12 11:37 AM, Adam Roach wrote: >>> >>> I don't think these really are issues. There are a lot of=20 >>> specifications where the ABNF would allow for certain productions,=20 >>> while the normative specification making use of that ABNF restricts=20 >>> those productions. For example, there is nothing in the ABNF of RFC >>> 3261 that restricts SIP messages from having multiple CSeq header=20 >>> fields, although it doing so certainly isn't allowed. >>> >> >> I think there is a big difference between having an ABNF that=20 >> includes terminals and non-terminals in productions that may not be=20 >> used at all as opposed to having an ABNF with certain semantic=20 >> restrictions on what constitutes valid semantic values based on=20 >> otherwise valid syntax. The former is generally well understood and=20 >> accepted whereas the latter is not (and for good reason IMO - what's=20 >> the point of having an ABNF otherwise ?). > You raise a good point. So, yeah, it looks like we probably want to=20 > take on an existing ABNF (with all its warts and optional things) or=20 > define our own (which would be trivial -- a plus sign followed by one=20 > or more digits is some of the most straightforward ABNF you'll ever see w= ritten). Yes, that is where this draft started. (Without the "+".) Certainly it woul= d "work". But it seems wrong to me. There ought to be an authoritative sour= ce for the syntax. Also, I wonder if some of that extra syntax might actually be useful in get= ting the CS call established in special situations. Maybe even local number= s might be useful in some situations. I'll admit that the separators are not *necessary* in any case. But forbidd= ing those might just mean that the application will need to add code to str= ip them from whatever source it uses for its local number. At least this wa= y its better defined what should be stripped. [Simo] Referencing RFC3966 can be done in several ways: reusing the entire = telephone-uri definition, the global-number, or only the global-number-digi= ts (which allows visual separators). What the draft is using the number for= (correlation of SDP with a CS call), just referencing the global-number-di= gits part would suffice. However, global-number allows parameters to be add= ed to global-number-digits, which I agree might be useful in some scenarios= - basic interoperability would be achieved by parsing the global-number-di= gits portion. local-number in RFC3966 include things like HEXDIG, "*" and "= #" which I don't think provide much additional help in achieving our goal. -Simo Thanks, Paul From pkyzivat@alum.mit.edu Mon Nov 19 07:12:18 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 DDA2721F8639 for ; Mon, 19 Nov 2012 07:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOzcGALk8iEa for ; Mon, 19 Nov 2012 07:12:18 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id D649C21F8635 for ; Mon, 19 Nov 2012 07:12:17 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id RQ2J1k0071c6gX851TCHCq; Mon, 19 Nov 2012 15:12:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id RTCG1k01A3ZTu2S3jTCH8u; Mon, 19 Nov 2012 15:12:17 +0000 Message-ID: <50AA4C50.20508@alum.mit.edu> Date: Mon, 19 Nov 2012 10:12:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> In-Reply-To: <50A9BFD4.3000601@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 15:12:19 -0000 On 11/19/12 12:12 AM, Harald Alvestrand wrote: > On 11/15/2012 08:55 PM, Adam Roach wrote: >> On 11/15/12 10:57, Paul Kyzivat wrote: >>> The whole notion of codec preference breaks down even more for >>> multiplexed streams. You may very explicitly prefer/require different >>> streams to use different codecs. >>> >>> So I don't think we can rely too much on parsing the existing text >>> for guidance on how to use SDP to represent multiplexed sessions. >>> (Unless of course we use bundle, with a separate m-line for each >>> stream.) AFAIK we are breaking new ground here. >> >> This kind of "we fixed this problem once and get to fix it all over >> again" issue is exactly the kind of thing I was speaking to at the >> microphone in MMUSIC in Atlanta. The further we drift from the >> established semantics of SDP, the less applicable previously developed >> mechanisms become. Bundle and similar approaches that maintain one m= >> line per stream allow us to leverage 14 years of extensions and >> clarifications. If we decide to split from that (rather fundamental, >> IMHO) characteristic of SDP, we are effectively forking the protocol, >> and throwing away years of prior work. > actually my caricature of the history of SDP is 4 years of multicast, > where multiple streams per RTP session was the norm, 10 years of > telephony, with only one stream of each type that mattered in each > direction, and 12 months of trying to get multiple streams working again. :-) :-( > While beating down the resistance of the RTP people against having > different media types in one RTP session, I've been told over and over > again that having multiple media streams of the *same* media type in one > RTP session is just fine and dandy "because that's what we designed RTP > to do", and now we're finally getting explicit about addressing the idea > of whether we tolerate more than one media stream per unit> - where the only control surface unit that's been used for the 10 > years of telephony is the M-line. > > The M-line is problematic because it binds together multiple things: > > - A top level media type > - A set of parameters for media transmission *in all directions* (bound > to payload type) > - Transport information (the "RTP session" data) > > > SDP M-lines are already problematic as soon as you want different > parameters in the two directions. It only goes downhill from there when > one does multiple flows with varying characteristics. > > As I said in Atlanta: SDP M-lines have been walking with one foot on the > "I'm an RTP session" bank of the canal and with the other foot on the > "I'm a media stream description" bank of the canal. > > The canal is growing wider. Fast. The *in all directions* is itself far from clear. - there is a bias towards using the same payload number in both directions but it is allowed to negotiate a different payload number in each direction for the same payload type. - there seems to be an implicit assumption that the same payload type will be used in both directions, but it is still possible to use different payload types for the two directions - you can negotiate asymmetric codec use via sendonly/recvonly sessions, but common usage typically doesn't support two one-way sessions as an alternative to one two-way session. This just further illustrates the schizophrenic nature of the existing SDP support that you are pointing out. Thanks, Paul From adam@nostrum.com Mon Nov 19 07:39: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 3042F21F8683 for ; Mon, 19 Nov 2012 07:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoPsTo6gwDuR for ; Mon, 19 Nov 2012 07:39:02 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 39F4B21F84D0 for ; Mon, 19 Nov 2012 07:39:00 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAJFcbGe045978 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 09:38:41 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50AA527C.6060200@nostrum.com> Date: Mon, 19 Nov 2012 09:38:36 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> In-Reply-To: <50A9BFD4.3000601@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 15:39:03 -0000 On 11/18/12 23:12, Harald Alvestrand wrote: > > The M-line is problematic because it binds together multiple things: > > - A top level media type > - A set of parameters for media transmission *in all directions* > (bound to payload type) > - Transport information (the "RTP session" data) > > > SDP M-lines are already problematic as soon as you want different > parameters in the two directions. It only goes downhill from there > when one does multiple flows with varying characteristics. > > As I said in Atlanta: SDP M-lines have been walking with one foot on > the "I'm an RTP session" bank of the canal and with the other foot on > the "I'm a media stream description" bank of the canal. I agree with your characterization of the situation. I'm a little surprised that it doesn't lead you to the same conclusion as I've reached. There are, at the moment, 176 attributes in the IANA registry that are applicable to m= sections: 3GPP-Adaptation-Support 3GPP-Asset-Information 3GPP-QoE-Metrics 3GPP-SRTP-Config 3gpp-videopostdecbufsize FEC FEC-OTI-extension FEC-declaration SRTPAuthentication SRTPROCTxRate T38FaxFillBitRemoval T38FaxMaxBuffer T38FaxMaxDatagram T38FaxRateManagement T38FaxTranscodingJBIG T38FaxTranscodingMMR T38FaxUdpEC T38FaxVersion T38MaxBitRate T38VendorInfo X-decbyterate X-initpostdecbufperiod X-initpredecbufperiod X-predecbufsize aal2CPS aal2CPSSDUrate aal2sscs3661assured aal2sscs3661unassured aal2sscs3662 aal5sscop aalApp aalType abrParms abrSetup acap accept-types accept-wrapped-types acfg alt alt-default-id anycast atmQOSparms atmTrfcDesc atmmap bcob bearerSigIE bearerType cache candidate capability cbrRate cdsc cfw-id chain channel clkrec cmid codecconfig conf confid connection content-desc cpar cparmax cparmin cpsSDUsize creq crypto csup curr dccp-port dccp-service-code depend des dsel ecan ecn-capable-rtp eecid extmap fec fec-repair-flow fec-source-flow file-date file-disposition file-icon file-range file-selector file-transfer-id fingerprint floorctrl floorid flute-ch flute-tsi fmtp framerate framesize fsel g.3gpp.cat g.3gpp.crs gc h248item ice-mismatch ice-pwd ice-ufrag ike-setup imageattr inactive isup_usi key-mgmt label lang lij max-size maxprate maxptime mbms-flowid mbms-mode mbms-repair mid msrp-cema multicast-rtcp omr-codecs omr-m-att omr-m-bw omr-m-cksum omr-s-att omr-s-bw omr-s-cksum onewaySel orient path pcfg portmapping-req profileDesc prtfl psk-fingerprint ptime qos-mech-recv qos-mech-send qosClass quality rams-updates recvonly remote-candidates repair-window resource rtcp rtcp-fb rtcp-mux rtcp-rsize rtcp-unicast rtcp-xr rtpmap rtpred1 rtpred2 sbc sdplang secondary-realm sendonly sendrecv setup silenceSupp source-filter sqn ssrc ssrc-group stc stkmstream structure tcap uiLayer1_Prot upcc userid visited-realm vsel zrtp-hash Some of these are applicable to the RTP session; others only make sense as applied to a single media stream. If we choose to make each m= section represent one media stream, then these attributes are applicable as-is. We get to take advantage of the work put in place by the 50 to 60 documents that defined the corresponding mechanisms with no changes whatsoever to this existing corpus of work. If we choose to make each m= section represent one RTP session, in which multiple media streams can be placed, then the use of any of those 176 attributes that are to be applied on the stream level becomes ambiguous. If we want to take advantage of them for RTCWEB (or anything else that leverages the work of untangling this mess), then we have to come up with an alternate, non-backwards-compatible syntax for conveying each of those attributes (cf. draft-lennox-mmusic-sdp-source-selection). And that's *just* the issues associated with attributes -- the problem is even worse once you consider the more subtle (and difficult to predict) damage to established mechanisms, like your codec priority conundrum. /a From harald@alvestrand.no Mon Nov 19 08:04: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 F351B21F8616 for ; Mon, 19 Nov 2012 08:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.135 X-Spam-Level: X-Spam-Status: No, score=-110.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LehS5tVeB1DL for ; Mon, 19 Nov 2012 08:04:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8294C21F84DE for ; Mon, 19 Nov 2012 08:04:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D6AD39E197; Mon, 19 Nov 2012 17:04:39 +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 rfo7OcIbHee7; Mon, 19 Nov 2012 17:04:28 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4FB3839E04C; Mon, 19 Nov 2012 17:04:28 +0100 (CET) Message-ID: <50AA588B.9090805@alvestrand.no> Date: Mon, 19 Nov 2012 17:04:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Roach References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> In-Reply-To: <50AA527C.6060200@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 16:04:43 -0000 On 11/19/2012 04:38 PM, Adam Roach wrote: > On 11/18/12 23:12, Harald Alvestrand wrote: >> >> The M-line is problematic because it binds together multiple things: >> >> - A top level media type >> - A set of parameters for media transmission *in all directions* >> (bound to payload type) >> - Transport information (the "RTP session" data) >> >> >> SDP M-lines are already problematic as soon as you want different >> parameters in the two directions. It only goes downhill from there >> when one does multiple flows with varying characteristics. >> >> As I said in Atlanta: SDP M-lines have been walking with one foot on >> the "I'm an RTP session" bank of the canal and with the other foot on >> the "I'm a media stream description" bank of the canal. > > I agree with your characterization of the situation. I'm a little > surprised that it doesn't lead you to the same conclusion as I've > reached. > > There are, at the moment, 176 attributes in the IANA registry that are > applicable to m= sections: > > 3GPP-Adaptation-Support 3GPP-Asset-Information 3GPP-QoE-Metrics > 3GPP-SRTP-Config 3gpp-videopostdecbufsize FEC FEC-OTI-extension > FEC-declaration SRTPAuthentication SRTPROCTxRate T38FaxFillBitRemoval > T38FaxMaxBuffer T38FaxMaxDatagram T38FaxRateManagement > T38FaxTranscodingJBIG T38FaxTranscodingMMR T38FaxUdpEC T38FaxVersion > T38MaxBitRate T38VendorInfo X-decbyterate X-initpostdecbufperiod > X-initpredecbufperiod X-predecbufsize aal2CPS aal2CPSSDUrate > aal2sscs3661assured aal2sscs3661unassured aal2sscs3662 aal5sscop > aalApp aalType abrParms abrSetup acap accept-types accept-wrapped-types > acfg alt alt-default-id anycast atmQOSparms atmTrfcDesc atmmap bcob > bearerSigIE bearerType cache candidate capability cbrRate cdsc > cfw-id chain channel clkrec cmid codecconfig conf confid connection > content-desc cpar cparmax cparmin cpsSDUsize creq crypto csup curr > dccp-port dccp-service-code depend des dsel ecan ecn-capable-rtp > eecid extmap fec fec-repair-flow fec-source-flow file-date > file-disposition file-icon file-range file-selector file-transfer-id > fingerprint floorctrl floorid flute-ch flute-tsi fmtp framerate > framesize fsel g.3gpp.cat g.3gpp.crs gc h248item ice-mismatch ice-pwd > ice-ufrag ike-setup imageattr inactive isup_usi key-mgmt label lang > lij max-size maxprate maxptime mbms-flowid mbms-mode mbms-repair > mid msrp-cema multicast-rtcp omr-codecs omr-m-att omr-m-bw omr-m-cksum > omr-s-att omr-s-bw omr-s-cksum onewaySel orient path pcfg portmapping-req > profileDesc prtfl psk-fingerprint ptime qos-mech-recv qos-mech-send > qosClass quality rams-updates recvonly remote-candidates repair-window > resource rtcp rtcp-fb rtcp-mux rtcp-rsize rtcp-unicast rtcp-xr > rtpmap rtpred1 rtpred2 sbc sdplang secondary-realm sendonly sendrecv > setup silenceSupp source-filter sqn ssrc ssrc-group stc stkmstream > structure tcap uiLayer1_Prot upcc userid visited-realm vsel zrtp-hash > > Some of these are applicable to the RTP session; others only make > sense as applied to a single media stream. And some make absolutely no sense at all in the RTCWEB context. Just for grins, let's take every single attribute defined for ATM bearer connection attributes and just remove them from discussion. Up to 35 attributes down at a single blow. I have at one point in my life dealt with T-series fax (RFC 2159 is long forgotten, I am happy to say). 'Nuff said. And those were just the 2 first ones I looked at. > > If we choose to make each m= section represent one media stream, then > these attributes are applicable as-is. We get to take advantage of the > work put in place by the 50 to 60 documents that defined the > corresponding mechanisms with no changes whatsoever to this existing > corpus of work. Except that, for instance, ice-pwd becomes ambiguous, and has to be dealt with using a bundle mechanism. > > If we choose to make each m= section represent one RTP session, in > which multiple media streams can be placed, then the use of any of > those 176 attributes that are to be applied on the stream level > becomes ambiguous. If we want to take advantage of them for RTCWEB (or > anything else that leverages the work of untangling this mess), then > we have to come up with an alternate, non-backwards-compatible syntax > for conveying each of those attributes (cf. > draft-lennox-mmusic-sdp-source-selection). > > And that's *just* the issues associated with attributes -- the problem > is even worse once you consider the more subtle (and difficult to > predict) damage to established mechanisms, like your codec priority > conundrum. That was an easy one. From adam@nostrum.com Mon Nov 19 08:25:18 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 E29D321F8473 for ; Mon, 19 Nov 2012 08:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljt1lXfhFLCu for ; Mon, 19 Nov 2012 08:25:18 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0D21F8456 for ; Mon, 19 Nov 2012 08:25:17 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAJGOtdR050552 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 10:24:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50AA5D55.6080006@nostrum.com> Date: Mon, 19 Nov 2012 10:24:53 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> In-Reply-To: <50AA588B.9090805@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 16:25:19 -0000 On 11/19/12 10:04, Harald Alvestrand wrote: > On 11/19/2012 04:38 PM, Adam Roach wrote: >> >> >> There are, at the moment, 176 attributes in the IANA registry that >> are applicable to m= sections: >> ... >> Some of these are applicable to the RTP session; others only make >> sense as applied to a single media stream. > And some make absolutely no sense at all in the RTCWEB context. Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see the same solutions applies to CLUE as RTCWEB. I concede that some of these are applicable only to technologies that are dead or dying; however... > I have at one point in my life dealt with T-series fax ...T.38 fax isn't one of them. Sadly. It sure would be nice to discount all of the existing mechanisms, but I suspect that they're not as wholly worthless are you're implying. Perhaps when I have a bit more time, I'll sit down and do a mechanism-by-mechanism evaluation of applicability of each to RTCWEB and CLUE. Until then, I expect it's relatively safe to assume that people haven't been putting values into that registry by performing utterly meaningless work; and, further, that only a fraction of it has been overtaken by technological progress. /a From pkyzivat@alum.mit.edu Mon Nov 19 08:37:33 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7D21F86AA for ; Mon, 19 Nov 2012 08:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc8F9DtG522e for ; Mon, 19 Nov 2012 08:37:32 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD4A21F8687 for ; Mon, 19 Nov 2012 08:37:31 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id RRxD1k0050mv7h055UdXLG; Mon, 19 Nov 2012 16:37:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id RUdX1k00S3ZTu2S3XUdXCY; Mon, 19 Nov 2012 16:37:31 +0000 Message-ID: <50AA604A.7000107@alum.mit.edu> Date: Mon, 19 Nov 2012 11:37:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> In-Reply-To: <50AA5D55.6080006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 16:37:33 -0000 Adam, I'm open to different approaches for addressing multiple RTP streams. So far ISTM there are drawbacks to all the ones I have seen discussed. The m-line per stream approach has problems if you don't know a priori how many, or which, streams you will have need to send over the session. I think there is also a problem with how RTCP works, and how the attributes that affect it apply, in the m-line per session approach. (And there are also problems here if you allow multiple streams per m-line.) Thanks, Paul On 11/19/12 11:24 AM, Adam Roach wrote: > On 11/19/12 10:04, Harald Alvestrand wrote: >> On 11/19/2012 04:38 PM, Adam Roach wrote: >>> >>> >>> There are, at the moment, 176 attributes in the IANA registry that >>> are applicable to m= sections: >>> ... >>> Some of these are applicable to the RTP session; others only make >>> sense as applied to a single media stream. >> And some make absolutely no sense at all in the RTCWEB context. > > Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see the > same solutions applies to CLUE as RTCWEB. I concede that some of these > are applicable only to technologies that are dead or dying; however... > >> I have at one point in my life dealt with T-series fax > > ...T.38 fax isn't one of them. Sadly. > > It sure would be nice to discount all of the existing mechanisms, but I > suspect that they're not as wholly worthless are you're implying. > Perhaps when I have a bit more time, I'll sit down and do a > mechanism-by-mechanism evaluation of applicability of each to RTCWEB and > CLUE. Until then, I expect it's relatively safe to assume that people > haven't been putting values into that registry by performing utterly > meaningless work; and, further, that only a fraction of it has been > overtaken by technological progress. > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Mon Nov 19 08:50: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 2988021F84EB for ; Mon, 19 Nov 2012 08:50:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNcA4AavWyXl for ; Mon, 19 Nov 2012 08:50:47 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 747F821F855E for ; Mon, 19 Nov 2012 08:50:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F3C739E197; Mon, 19 Nov 2012 17:50:45 +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 ixFhbJZceTmM; Mon, 19 Nov 2012 17:50:44 +0100 (CET) Received: from [172.16.33.61] (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7018639E04C; Mon, 19 Nov 2012 17:50:44 +0100 (CET) Message-ID: <50AA6363.7040201@alvestrand.no> Date: Mon, 19 Nov 2012 17:50:43 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Roach References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> In-Reply-To: <50AA5D55.6080006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 16:50:49 -0000 On 11/19/2012 05:24 PM, Adam Roach wrote: > On 11/19/12 10:04, Harald Alvestrand wrote: >> On 11/19/2012 04:38 PM, Adam Roach wrote: >>> >>> >>> There are, at the moment, 176 attributes in the IANA registry that >>> are applicable to m= sections: >>> ... >>> Some of these are applicable to the RTP session; others only make >>> sense as applied to a single media stream. >> And some make absolutely no sense at all in the RTCWEB context. > > Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see > the same solutions applies to CLUE as RTCWEB. I concede that some of > these are applicable only to technologies that are dead or dying; > however... > >> I have at one point in my life dealt with T-series fax > > ...T.38 fax isn't one of them. Sadly. What's your scenario where T.38 fax over RTP is relevant when file transfer over a reliable channel is available between the same 2 devices? > > It sure would be nice to discount all of the existing mechanisms, but > I suspect that they're not as wholly worthless are you're implying. > Perhaps when I have a bit more time, I'll sit down and do a > mechanism-by-mechanism evaluation of applicability of each to RTCWEB > and CLUE. Until then, I expect it's relatively safe to assume that > people haven't been putting values into that registry by performing > utterly meaningless work; and, further, that only a fraction of it has > been overtaken by technological progress. 90% is also a fraction. But I agree it's unlikely to be that high. > > /a From adam@nostrum.com Mon Nov 19 08:57:47 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 212C621F86A8 for ; Mon, 19 Nov 2012 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne57FYc4bAF2 for ; Mon, 19 Nov 2012 08:57:46 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4688921F8683 for ; Mon, 19 Nov 2012 08:57:46 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAJGvOu1053929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Nov 2012 10:57:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50AA64F2.4020607@nostrum.com> Date: Mon, 19 Nov 2012 10:57:22 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> <50AA6363.7040201@alvestrand.no> In-Reply-To: <50AA6363.7040201@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) 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 Nov 2012 16:57:47 -0000 On 11/19/12 10:50, Harald Alvestrand wrote: >> ...T.38 fax isn't one of them. Sadly. > > What's your scenario where T.38 fax over RTP is relevant when file > transfer over a reliable channel is available between the same 2 devices? This is a rat hole that I'm not going to dive too far into, but my understanding is that the tenacity of fax as an underlying technology has to do with a substantial body of U.S. case law that establishes that faxed legal documents are binding, while leaving the issue of transmission using a technology known by any other name unsettled. Is this a mind-numbingly stupid reason for it to hang on? Yeah, maybe. Does that change the facts on the ground? No. Not even a little bit. ObHumor: http://www.theonion.com/articles/report-fax-machines-still-pretty-impressive-if-you,21256/ /a From pkyzivat@alum.mit.edu Mon Nov 19 08:57: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 0CBEF21F86BB for ; Mon, 19 Nov 2012 08:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMzPrnhIIpRz for ; Mon, 19 Nov 2012 08:57:51 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA921F86BA for ; Mon, 19 Nov 2012 08:57:51 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id RQXw1k0071ZXKqc51Uxqpz; Mon, 19 Nov 2012 16:57:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id RUxq1k00B3ZTu2S3hUxq9x; Mon, 19 Nov 2012 16:57:50 +0000 Message-ID: <50AA650D.7080109@alum.mit.edu> Date: Mon, 19 Nov 2012 11:57:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> <50AA6363.7040201@alvestrand.no> In-Reply-To: <50AA6363.7040201@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 16:57:52 -0000 On 11/19/12 11:50 AM, Harald Alvestrand wrote: >>> I have at one point in my life dealt with T-series fax >> >> ...T.38 fax isn't one of them. Sadly. > What's your scenario where T.38 fax over RTP is relevant when file > transfer over a reliable channel is available between the same 2 devices? Sadly, I gather that the legal world hasn't yet caught up with technology. E.g., I think that faxed copies of documents with signatures have more legal validity than do pdf files containing signatures. Stupid, but it can still drive demand for continued support of fax protocols. [I'm not an expert on this - this comment is mostly based on 2nd hand data.] Thanks, Paul From harald@alvestrand.no Tue Nov 20 00:47: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 CD22F21F86E5 for ; Tue, 20 Nov 2012 00:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.228 X-Spam-Level: X-Spam-Status: No, score=-109.228 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfhvfABq-PL4 for ; Tue, 20 Nov 2012 00:47:47 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 301BF21F86EC for ; Tue, 20 Nov 2012 00:47:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E1EF39E16A; Tue, 20 Nov 2012 09:47:44 +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 L9yr2-mxp2nw; Tue, 20 Nov 2012 09:47:42 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9DCCA39E0F3; Tue, 20 Nov 2012 09:47:42 +0100 (CET) Message-ID: <50AB43AD.7000007@alvestrand.no> Date: Tue, 20 Nov 2012 09:47:41 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Roach References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> <50AA6363.7040201@alvestrand.no> <50AA64F2.4020607@nostrum.com> In-Reply-To: <50AA64F2.4020607@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) 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 Nov 2012 08:47:48 -0000 On 11/19/2012 05:57 PM, Adam Roach wrote: > On 11/19/12 10:50, Harald Alvestrand wrote: >>> ...T.38 fax isn't one of them. Sadly. >> >> What's your scenario where T.38 fax over RTP is relevant when file >> transfer over a reliable channel is available between the same 2 >> devices? > > This is a rat hole that I'm not going to dive too far into, but my > understanding is that the tenacity of fax as an underlying technology > has to do with a substantial body of U.S. case law that establishes > that faxed legal documents are binding, while leaving the issue of > transmission using a technology known by any other name unsettled. > > Is this a mind-numbingly stupid reason for it to hang on? Yeah, maybe. > Does that change the facts on the ground? No. Not even a little bit. Sympathy. I've read the original judge's opinion in the English court case that established telex as legally binding - he explicitly said "I have this opinion not because it is technically sound, but because it is necessary to keep commerce flowing". We're still there, and the fax industry keeps chugging along because of it. Still, I don't see the compelling use case for T.38 fax over RTP *into browsers*. > > ObHumor: > http://www.theonion.com/articles/report-fax-machines-still-pretty-impressive-if-you,21256/ > > /a From pkyzivat@alum.mit.edu Tue Nov 20 07:42: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 C750521F8765 for ; Tue, 20 Nov 2012 07:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77hQKgRvg2OA for ; Tue, 20 Nov 2012 07:42:39 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAB121F8753 for ; Tue, 20 Nov 2012 07:42:38 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id Roek1k00J1ZXKqc53rieyx; Tue, 20 Nov 2012 15:42:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id Rrid1k00h3ZTu2S3hridqR; Tue, 20 Nov 2012 15:42:37 +0000 Message-ID: <50ABA4ED.5070103@alum.mit.edu> Date: Tue, 20 Nov 2012 10:42:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "mmusic@ietf.org" , draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 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 Nov 2012 15:42:39 -0000 I am the assigned SDP directorate reviewer for draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06. 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 SDP syntax defined in this draft is trivial and fine. It exercises a defined extension point in RFC3611. That RFC defines an IANA registry for new values using this extension point. This document nominally supplies the information called for when registering. However, the semantics for processing the new syntax is underspecified, and needs to be further elaborated. * New SDP information elements: Section 5 of this draft augments the SDP attribute "rtcp-xr" defined in RFC3611, providing an additional value: "brst-gap-dscrd". * Technical Issues: RFC3611 establishes an IANA registry for new values, and requires that the following information be supplied when registering a new value: - Contact information of the one doing the registration, including at least name, address, and email. - An Augmented Backus-Naur Form (ABNF) [2] definition of the parameter, in accordance with the "format-ext" definition of Section 5.1. - A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer. The first two of the above are properly supplied. But the offer/answer behavior is insufficiently specified. ("When SDP is used in offer-answer context, the SDP Offer/Answer usage defined in [RFC3611] applies.") RFC3611 states: Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions. It then goes on to give different offer/answer procedures for each category of parameter. The reference in *this* draft ("the SDP Offer/Answer usage defined in [RFC3611] applies") is insufficient because there is no indication in this draft whether the new value is a "unilateral" or "collaborative" parameter. The draft needs to be revised to address this issue. I *think* this new parameter is a "unilateral" parameter. If so, it MAY be sufficient to revise section 5.2 as follows: OLD: When SDP is used in offer-answer context, the SDP Offer/Answer usage defined in [RFC3611] applies. NEW: When SDP is used in offer-answer context, the SDP Offer/Answer usage defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters applies. It may be useful to provide an expanded explanation. Regards, Paul Kyzivat From btv1==6713412e283==HKaplan@acmepacket.com Tue Nov 20 10:16: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 BA24921F86E5 for ; Tue, 20 Nov 2012 10:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQdSZyPyB9Ny for ; Tue, 20 Nov 2012 10:16:06 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF821F8690 for ; Tue, 20 Nov 2012 10:16:06 -0800 (PST) X-ASG-Debug-ID: 1353435364-03fc2136a5a6c570001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id nNUqbswRHzgXNkIi (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 13:16:04 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Tue, 20 Nov 2012 13:16:04 -0500 From: Hadriel Kaplan To: "mmusic@ietf.org (E-mail)" Thread-Topic: NEED WG CONSENSUS: media-loopback is all-or-nothing X-ASG-Orig-Subj: NEED WG CONSENSUS: media-loopback is all-or-nothing Thread-Index: AQHNx0sa0Z8XaBiMtU6BXcD6oqpbWQ== Date: Tue, 20 Nov 2012 18:16:03 +0000 Message-ID: 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: <8EC966236C67DD4787072BD2647D9BB5@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1353435364 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.114768 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: Gonzalo Camarillo , "draft-ietf-mmusic-media-loopback@tools.ietf.org" Subject: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 18:16:47 -0000 Howdy, during IESG review of the media-loopback draft, a discussion arose regardin= g the language around indicating media-loopback support per media descripti= on (i.e., per m-line), in sections 3.1 and 3.2. My interpretation/understanding was we were requiring ALL m-lines to indica= te media-loopback; in other words it's an all-or-nothing in both the offer+= answer, and either every media stream is looped back, or none are. However= the text currently doesn't make this clear, and it could be argued either = way, with pro's/con's either way too; so I'd like the WG's consensus on whe= ther it should in fact be an all-or-none approach, or not. Please respond to this email by **Tuesday, December 4th** with a "YES" if t= he draft should mandate ALL media be looped-back, or "NO" if it should allo= w a hybrid approach of some streams being looped while others are not. For reference, the draft is here: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 -hadriel From pkyzivat@alum.mit.edu Tue Nov 20 10:42: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 9E05621F87ED for ; Tue, 20 Nov 2012 10:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsHNGPvZBmT5 for ; Tue, 20 Nov 2012 10:42:46 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id EF35421F87FD for ; Tue, 20 Nov 2012 10:42:45 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id RqyG1k0011vXlb859uikgT; Tue, 20 Nov 2012 18:42:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Ruik1k00Y3ZTu2S3duikc6; Tue, 20 Nov 2012 18:42:44 +0000 Message-ID: <50ABCF23.9020605@alum.mit.edu> Date: Tue, 20 Nov 2012 13:42:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 18:42:46 -0000 NO *Why* should the draft be limited this way if it need not be? Thanks, Paul On 11/20/12 1:16 PM, Hadriel Kaplan wrote: > Howdy, > during IESG review of the media-loopback draft, a discussion arose regarding the language around indicating media-loopback support per media description (i.e., per m-line), in sections 3.1 and 3.2. > > My interpretation/understanding was we were requiring ALL m-lines to indicate media-loopback; in other words it's an all-or-nothing in both the offer+answer, and either every media stream is looped back, or none are. However the text currently doesn't make this clear, and it could be argued either way, with pro's/con's either way too; so I'd like the WG's consensus on whether it should in fact be an all-or-none approach, or not. > > Please respond to this email by **Tuesday, December 4th** with a "YES" if the draft should mandate ALL media be looped-back, or "NO" if it should allow a hybrid approach of some streams being looped while others are not. > > For reference, the draft is here: > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Tue Nov 20 10:56: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 87D3121F87D5 for ; Tue, 20 Nov 2012 10:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.089 X-Spam-Level: X-Spam-Status: No, score=-102.089 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-DqBeH4nHuE for ; Tue, 20 Nov 2012 10:56:42 -0800 (PST) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id A671F21F87D2 for ; Tue, 20 Nov 2012 10:56:42 -0800 (PST) Received: from BLU002-W128 ([65.55.116.74]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 10:56:41 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b6c62602-72f7-46cd-8ebf-7e90bd192d21_" X-Originating-IP: [131.107.0.81] From: Bernard Aboba To: Paul Kyzivat , "mmusic@ietf.org" Date: Tue, 20 Nov 2012 10:56:41 -0800 Importance: Normal In-Reply-To: <50ABCF23.9020605@alum.mit.edu> References: , <50ABCF23.9020605@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2012 18:56:41.0632 (UTC) FILETIME=[C729AA00:01CDC750] Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 18:56:43 -0000 --_b6c62602-72f7-46cd-8ebf-7e90bd192d21_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To Paul's point=2C there may be a scenario in which some m lines would be l= ooped back and others would not. For example=2C what if I want to do a loo= pback test of audio/video but also want to be able to converse via RTT to d= iscuss the results of the test in progress. In that case the audio and vid= eo m lines would be looped back but the text line would not be.=20 > Date: Tue=2C 20 Nov 2012 13:42:43 -0500 > From: pkyzivat@alum.mit.edu > To: mmusic@ietf.org > Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing >=20 > NO >=20 > *Why* should the draft be limited this way if it need not be? >=20 > Thanks=2C > Paul >=20 > On 11/20/12 1:16 PM=2C Hadriel Kaplan wrote: > > Howdy=2C > > during IESG review of the media-loopback draft=2C a discussion arose re= garding the language around indicating media-loopback support per media des= cription (i.e.=2C per m-line)=2C in sections 3.1 and 3.2. > > > > My interpretation/understanding was we were requiring ALL m-lines to in= dicate media-loopback=3B in other words it's an all-or-nothing in both the = offer+answer=2C and either every media stream is looped back=2C or none are= . However the text currently doesn't make this clear=2C and it could be ar= gued either way=2C with pro's/con's either way too=3B so I'd like the WG's = consensus on whether it should in fact be an all-or-none approach=2C or not= . > > > > Please respond to this email by **Tuesday=2C December 4th** with a "YES= " if the draft should mandate ALL media be looped-back=2C or "NO" if it sho= uld allow a hybrid approach of some streams being looped while others are n= ot. > > > > For reference=2C the draft is here: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 > > > > -hadriel > > > > _______________________________________________ > > 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 = --_b6c62602-72f7-46cd-8ebf-7e90bd192d21_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To Paul's point=2C there may be = a scenario in which some m lines would be looped back and others would not.=  =3B For example=2C what if I want to do a loopback test of audio/video= but also want to be able to converse via RTT to discuss the results of the= test in progress. =3B In that case the audio and video m lines would b= e looped back but the text line would not be.

>=3B Date: Tue=2C 20 Nov 2012 13:42:43 -0500
>= =3B From: pkyzivat@alum.mit.edu
>=3B To: mmusic@ietf.org
>=3B Sub= ject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
&= gt=3B
>=3B NO
>=3B
>=3B *Why* should the draft be limited = this way if it need not be?
>=3B
>=3B Thanks=2C
>=3B Paul=
>=3B
>=3B On 11/20/12 1:16 PM=2C Hadriel Kaplan wrote:
>= =3B >=3B Howdy=2C
>=3B >=3B during IESG review of the media-loopba= ck draft=2C a discussion arose regarding the language around indicating med= ia-loopback support per media description (i.e.=2C per m-line)=2C in sectio= ns 3.1 and 3.2.
>=3B >=3B
>=3B >=3B My interpretation/underst= anding was we were requiring ALL m-lines to indicate media-loopback=3B in o= ther words it's an all-or-nothing in both the offer+answer=2C and either ev= ery media stream is looped back=2C or none are. However the text currently= doesn't make this clear=2C and it could be argued either way=2C with pro's= /con's either way too=3B so I'd like the WG's consensus on whether it shoul= d in fact be an all-or-none approach=2C or not.
>=3B >=3B
>=3B = >=3B Please respond to this email by **Tuesday=2C December 4th** with a "= YES" if the draft should mandate ALL media be looped-back=2C or "NO" if it = should allow a hybrid approach of some streams being looped while others ar= e not.
>=3B >=3B
>=3B >=3B For reference=2C the draft is here= :
>=3B >=3B http://tools.ietf.org/html/draft-ietf-mmusic-media-loopb= ack-24
>=3B >=3B
>=3B >=3B -hadriel
>=3B >=3B
>= =3B >=3B _______________________________________________
>=3B >=3B= mmusic mailing list
>=3B >=3B mmusic@ietf.org
>=3B >=3B http= s://www.ietf.org/mailman/listinfo/mmusic
>=3B >=3B
>=3B
>= =3B _______________________________________________
>=3B mmusic mailin= g list
>=3B mmusic@ietf.org
>=3B https://www.ietf.org/mailman/lis= tinfo/mmusic
= --_b6c62602-72f7-46cd-8ebf-7e90bd192d21_-- From bernard_aboba@hotmail.com Tue Nov 20 11:12: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 025FB21F87CB for ; Tue, 20 Nov 2012 11:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5FFnPpjIVhc for ; Tue, 20 Nov 2012 11:12:24 -0800 (PST) Received: from blu0-omc1-s18.blu0.hotmail.com (blu0-omc1-s18.blu0.hotmail.com [65.55.116.29]) by ietfa.amsl.com (Postfix) with ESMTP id E3B1021F87D5 for ; Tue, 20 Nov 2012 11:12:23 -0800 (PST) Received: from BLU002-W219 ([65.55.116.8]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 11:12:23 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f6706a30-d997-4af4-b76d-fb40165dcc99_" X-Originating-IP: [131.107.0.81] From: Bernard Aboba To: Harald Alvestrand , "mmusic@ietf.org" Date: Tue, 20 Nov 2012 11:12:23 -0800 Importance: Normal In-Reply-To: <50A9BFD4.3000601@alvestrand.no> References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no>,<50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com>,<50A9BFD4.3000601@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2012 19:12:23.0371 (UTC) FILETIME=[F87BA1B0:01CDC752] Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 19:12:25 -0000 --_f6706a30-d997-4af4-b76d-fb40165dcc99_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The M-line is problematic because it binds together multiple things: >=20 > - A set of parameters for media transmission *in all directions* (bound t= o payload type) [BA] RFC 3264 Section 5.1 makes it clear that the parameters need not apply= in all directions (though sendrecv is the default):=20 The list of media formats for each media stream conveys two pieces of=0A= information=2C namely the set of formats (codecs and any parameters=0A= associated with the codec=2C in the case of RTP) that the offerer is=0A= capable of sending and/or receiving (depending on the direction=0A= attributes)=2C and=2C in the case of RTP=2C the RTP payload type numbers= =0A= used to identify those formats. If multiple formats are listed=2C it=0A= means that the offerer is capable of making use of any of those=0A= formats during the session. In other words=2C the answerer MAY change= =0A= formats in the middle of the session=2C making use of any of the=0A= formats listed=2C without sending a new offer. For a sendonly stream=2C= =0A= the offer SHOULD indicate those formats the offerer is willing to=0A= send for this stream. For a recvonly stream=2C the offer SHOULD=0A= indicate those formats the offerer is willing to receive for this=0A= stream. For a sendrecv stream=2C the offer SHOULD indicate those=0A= codecs that the offerer is willing to send and receive with. = --_f6706a30-d997-4af4-b76d-fb40165dcc99_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B The M-line is problematic= because it binds together multiple things:
>=3B
>=3B - A s= et of parameters for media transmission *in all directions* (bound to paylo= ad type)

[BA] RFC 3264 Section 5.1 makes it clear that the parameter= s need not apply in all directions (though sendrecv is the default): 
   The list of media formats for each media stream=
 conveys two pieces of=0A=
   information=2C namely the set of formats (codecs and any parameters=0A=
   associated with the codec=2C in the case of RTP) that the offerer is=0A=
   capable of sending and/or receiving (depending on the direction=0A=
   attributes)=2C and=2C in the case of RTP=2C the RTP payload type numbers=
=0A=
   used to identify those formats.  If multiple formats are listed=2C it=0A=
   means that the offerer is capable of making use of any of those=0A=
   formats during the session.  In other words=2C the answerer MAY change=
=0A=
   formats in the middle of the session=2C making use of any of the=0A=
   formats listed=2C without sending a new offer.  For a sendonly stream=2C=
=0A=
   the offer SHOULD indicate those formats the offerer is willing to=0A=
   send for this stream.  For a recvonly stream=2C the offer SHOULD=0A=
   indicate those formats the offerer is willing to receive for this=0A=
   stream.  For a sendrecv stream=2C the offer SHOULD indicate those=0A=
   codecs that the offerer is willing to send and receive with.

= --_f6706a30-d997-4af4-b76d-fb40165dcc99_-- From btv1==6713412e283==HKaplan@acmepacket.com Tue Nov 20 11:51: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 9D37D21F8787 for ; Tue, 20 Nov 2012 11:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnQmFGDW9ess for ; Tue, 20 Nov 2012 11:51:48 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8236521F873D for ; Tue, 20 Nov 2012 11:51:48 -0800 (PST) X-ASG-Debug-ID: 1353441106-03fc20119e82430001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id fK5wxG3N7FymB6H8 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 14:51:46 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Tue, 20 Nov 2012 14:51:33 -0500 From: Hadriel Kaplan To: Bernard Aboba Thread-Topic: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing X-ASG-Orig-Subj: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing Thread-Index: AQHNx1hxvSoC84ovvkqVvo+Zxh0CCw== Date: Tue, 20 Nov 2012 19:51:33 +0000 Message-ID: <535E4BAA-BE0C-47D1-A659-17B4043031EE@acmepacket.com> References: , <50ABCF23.9020605@alum.mit.edu> In-Reply-To: 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: multipart/alternative; boundary="_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_" MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1353441106 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.114774 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 19:51:49 -0000 --_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I take this is a "NO" vote? -hadriel On Nov 20, 2012, at 1:56 PM, Bernard Aboba > wrote: To Paul's point, there may be a scenario in which some m lines would be loo= ped back and others would not. For example, what if I want to do a loopbac= k test of audio/video but also want to be able to converse via RTT to discu= ss the results of the test in progress. In that case the audio and video m= lines would be looped back but the text line would not be. > Date: Tue, 20 Nov 2012 13:42:43 -0500 > From: pkyzivat@alum.mit.edu > To: mmusic@ietf.org > Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing > > NO > > *Why* should the draft be limited this way if it need not be? > > Thanks, > Paul > > On 11/20/12 1:16 PM, Hadriel Kaplan wrote: > > Howdy, > > during IESG review of the media-loopback draft, a discussion arose rega= rding the language around indicating media-loopback support per media descr= iption (i.e., per m-line), in sections 3.1 and 3.2. > > > > My interpretation/understanding was we were requiring ALL m-lines to in= dicate media-loopback; in other words it's an all-or-nothing in both the of= fer+answer, and either every media stream is looped back, or none are. Howe= ver the text currently doesn't make this clear, and it could be argued eith= er way, with pro's/con's either way too; so I'd like the WG's consensus on = whether it should in fact be an all-or-none approach, or not. > > > > Please respond to this email by **Tuesday, December 4th** with a "YES" = if the draft should mandate ALL media be looped-back, or "NO" if it should = allow a hybrid approach of some streams being looped while others are not. > > > > For reference, the draft is here: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 > > > > -hadriel > > > > _______________________________________________ > > 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_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <70EB108B66248C4597D9E928C4B1AB9B@acmepacket.com> Content-Transfer-Encoding: quoted-printable

I take this is a "NO" vote? 

-hadriel


On Nov 20, 2012, at 1:56 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

To Paul's point, there may be a scenario in which some m l= ines would be looped back and others would not.  For example, what if = I want to do a loopback test of audio/video but also want to be able to con= verse via RTT to discuss the results of the test in progress.  In that case the audio and video m lines would= be looped back but the text line would not be. 

> Date: Tue, 20 Nov 2012 13:42:43 -0500
> From: pkyzivat@alum.mit.edu
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-noth= ing
> 
> NO
> 
> *Why* should the draft be limited this way if it need not be?
> 
> Thanks,
> Paul
> 
> On 11/20/12 1:16 PM, Hadriel Kaplan wrote:
> > Howdy,
> > during IESG review of the media-loopback draft, a discussion aros= e regarding the language around indicating media-loopback support per media= description (i.e., per m-line), in sections 3.1 and 3.2.
> >
> > My interpretation/understanding was we were requiring ALL m-lines= to indicate media-loopback; in other words it's an all-or-nothing in both = the offer+answer, and either every media stream is looped back, or none= are. However the text currently doesn't make this clear, and it could be argued either way, with pro's/con's either way= too; so I'd like the WG's consensus on whether it should in fact be an all= -or-none approach, or not.
> >
> > Please respond to this email by **Tuesday, December 4th** with a = "YES" if the draft should mandate ALL media be looped-back, or &q= uot;NO" if it should allow a hybrid approach of some streams being loo= ped while others are not.
> >
> > For reference, the draft is here:
> > http://tools.ie= tf.org/html/draft-ietf-mmusic-media-loopback-24
> >
> > -hadriel
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/list= info/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/= mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

--_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_-- From btv1==6713412e283==HKaplan@acmepacket.com Tue Nov 20 11:54: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 37C5521F87E4 for ; Tue, 20 Nov 2012 11:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBQJtsi+hR9M for ; Tue, 20 Nov 2012 11:54:16 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id AB19721F87E1 for ; Tue, 20 Nov 2012 11:54:16 -0800 (PST) X-ASG-Debug-ID: 1353441255-03fc2136a6a71b90001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id vRr0dFSbzlj0SH3h (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 14:54:15 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Tue, 20 Nov 2012 14:54:15 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing X-ASG-Orig-Subj: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing Thread-Index: AQHNx1jQvSoC84ovvkqVvo+Zxh0CCw== Date: Tue, 20 Nov 2012 19:54:14 +0000 Message-ID: <2217C1EE-793D-498C-B604-8BAF604C2C86@acmepacket.com> References: <50ABCF23.9020605@alum.mit.edu> In-Reply-To: <50ABCF23.9020605@alum.mit.edu> 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: <1F46B966676B2347B1FB9C03E353B3F2@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1353441255 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.114774 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "" Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 19:54:17 -0000 Are you asking for someone to defend/explain the advantages are for limitin= g it, or just giving that as the rationale for your NO vote? (I don't mean this in a negative way - I'm literally not sure if you're ask= ing a question or being rhetorical) -hadriel On Nov 20, 2012, at 1:42 PM, Paul Kyzivat wrote: > NO >=20 > *Why* should the draft be limited this way if it need not be? >=20 > Thanks, > Paul >=20 > On 11/20/12 1:16 PM, Hadriel Kaplan wrote: >> Howdy, >> during IESG review of the media-loopback draft, a discussion arose regar= ding the language around indicating media-loopback support per media descri= ption (i.e., per m-line), in sections 3.1 and 3.2. >>=20 >> My interpretation/understanding was we were requiring ALL m-lines to ind= icate media-loopback; in other words it's an all-or-nothing in both the off= er+answer, and either every media stream is looped back, or none are. Howe= ver the text currently doesn't make this clear, and it could be argued eith= er way, with pro's/con's either way too; so I'd like the WG's consensus on = whether it should in fact be an all-or-none approach, or not. >>=20 >> Please respond to this email by **Tuesday, December 4th** with a "YES" i= f the draft should mandate ALL media be looped-back, or "NO" if it should a= llow a hybrid approach of some streams being looped while others are not. >>=20 >> For reference, the draft is here: >> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >>=20 >> -hadriel >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Tue Nov 20 12:02: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 9D72F21F8837 for ; Tue, 20 Nov 2012 12:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.101 X-Spam-Level: X-Spam-Status: No, score=-102.101 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH8m8xdTReIP for ; Tue, 20 Nov 2012 12:02:25 -0800 (PST) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by ietfa.amsl.com (Postfix) with ESMTP id B88B521F881B for ; Tue, 20 Nov 2012 12:02:24 -0800 (PST) Received: from BLU002-W201 ([65.55.111.72]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 12:02:22 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c3aa5e91-45e2-4f45-b90f-a53d32cdb849_" X-Originating-IP: [131.107.0.126] From: Bernard Aboba To: Hadriel Kaplan Date: Tue, 20 Nov 2012 12:02:22 -0800 Importance: Normal In-Reply-To: <535E4BAA-BE0C-47D1-A659-17B4043031EE@acmepacket.com> References: , , <50ABCF23.9020605@alum.mit.edu>, , <535E4BAA-BE0C-47D1-A659-17B4043031EE@acmepacket.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2012 20:02:22.0602 (UTC) FILETIME=[F429F6A0:01CDC759] Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 20:02:25 -0000 --_c3aa5e91-45e2-4f45-b90f-a53d32cdb849_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "NO". From: HKaplan@acmepacket.com To: bernard_aboba@hotmail.com CC: pkyzivat@alum.mit.edu=3B mmusic@ietf.org Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing Date: Tue=2C 20 Nov 2012 19:51:33 +0000 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= I take this is a "NO" vote? =0A= =0A= =0A= -hadriel=0A= =0A= =0A= =0A= =0A= =0A= On Nov 20=2C 2012=2C at 1:56 PM=2C Bernard Aboba wrote:=0A= =0A= =0A= =0A= To Paul's point=2C there may be a scenario in which some m lines would be l= ooped back and others would not. For example=2C what if I want to do a loo= pback test of audio/video but also want to be able to converse via RTT to d= iscuss the results of=0A= the test in progress. In that case the audio and video m lines would be l= ooped back but the text line would not be.=20 =0A= =0A= =0A= =0A= > Date: Tue=2C 20 Nov 2012 13:42:43 -0500 =0A= > From: pkyzivat@alum.mit.edu =0A= > To: mmusic@ietf.org =0A= > Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing =0A= >=20 =0A= > NO =0A= >=20 =0A= > *Why* should the draft be limited this way if it need not be? =0A= >=20 =0A= > Thanks=2C =0A= > Paul =0A= >=20 =0A= > On 11/20/12 1:16 PM=2C Hadriel Kaplan wrote: =0A= > > Howdy=2C =0A= > > during IESG review of the media-loopback draft=2C a discussion arose re= garding the language around indicating media-loopback support per media des= cription (i.e.=2C per m-line)=2C in sections 3.1 and 3.2. =0A= > > =0A= > > My interpretation/understanding was we were requiring ALL m-lines to in= dicate media-loopback=3B in other words it's an all-or-nothing in both the = offer+answer=2C and either every media stream is looped back=2C or none are= . However the text currently doesn't make=0A= this clear=2C and it could be argued either way=2C with pro's/con's either= way too=3B so I'd like the WG's consensus on whether it should in fact be = an all-or-none approach=2C or not. =0A= > > =0A= > > Please respond to this email by **Tuesday=2C December 4th** with a "YES= " if the draft should mandate ALL media be looped-back=2C or "NO" if it sho= uld allow a hybrid approach of some streams being looped while others are n= ot. =0A= > > =0A= > > For reference=2C the draft is here: =0A= > > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 =0A= > > =0A= > > -hadriel =0A= > > =0A= > > _______________________________________________ =0A= > > mmusic mailing list =0A= > > mmusic@ietf.org =0A= > > https://www.ietf.org/mailman/listinfo/mmusic =0A= > > =0A= >=20 =0A= > _______________________________________________ =0A= > mmusic mailing list =0A= > mmusic@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/mmusic =0A= =0A= =0A= _______________________________________________ =0A= mmusic mailing list =0A= mmusic@ietf.org =0A= https://www.ietf.org/mailman/listinfo/mmusic =0A= =0A= =0A= =0A= = --_c3aa5e91-45e2-4f45-b90f-a53d32cdb849_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
"NO".

From: HKaplan@acmepacket.com
To: bernard_aboba@hotmail.com
= CC: pkyzivat@alum.mit.edu=3B mmusic@ietf.org
Subject: Re: [MMUSIC] NEED = WG CONSENSUS: media-loopback is all-or-nothing
Date: Tue=2C 20 Nov 2012 = 19:51:33 +0000

=0A= =0A= =0A= =0A= =0A= =0A=

=0A=
=0A=
I take this is a "NO" vote? =3B
=0A=

=0A=
=0A=
-hadriel
=0A=

=0A=
=0A=

=0A=
=0A=
=0A=
On Nov 20=2C 2012=2C at 1:56 PM=2C Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B wrote:=0A=
=0A=
=0A=
=0A=
To Paul's point=2C there may be a scenario in which some m= lines would be looped back and others would not. =3B For example=2C wh= at if I want to do a loopback test of audio/video but also want to be able = to converse via RTT to discuss the results of=0A= the test in progress. =3B In that case the audio and video m lines wou= ld be looped back but the text line would not be. =3B
=0A=
=0A=
=0A= =0A= >=3B Date: Tue=2C 20 Nov 2012 13:42:43 -0500
=0A= >=3B From: =3Bpkyzivat@alum.mit.edu
=0A= >=3B To: =3Bmmusic@ietf.org
=0A= >=3B Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-no= thing
=0A= >=3B =3B
=0A= >=3B NO
=0A= >=3B =3B
=0A= >=3B *Why* should the draft be limited this way if it need not be?
=0A= >=3B =3B
=0A= >=3B Thanks=2C
=0A= >=3B Paul
=0A= >=3B =3B
=0A= >=3B On 11/20/12 1:16 PM=2C Hadriel Kaplan wrote:
=0A= >=3B >=3B Howdy=2C
=0A= >=3B >=3B during IESG review of the media-loopback draft=2C a discussio= n arose regarding the language around indicating media-loopback support per= media description (i.e.=2C per m-line)=2C in sections 3.1 and 3.2.
=0A= >=3B >=3B
=0A= >=3B >=3B My interpretation/understanding was we were requiring ALL m-l= ines to indicate media-loopback=3B in other words it's an all-or-nothing in= both the offer+answer=2C and either every media stream is looped back=2C o= r none are. However the text currently doesn't make=0A= this clear=2C and it could be argued either way=2C with pro's/con's either= way too=3B so I'd like the WG's consensus on whether it should in fact be = an all-or-none approach=2C or not.
=0A= >=3B >=3B
=0A= >=3B >=3B Please respond to this email by **Tuesday=2C December 4th** w= ith a "YES" if the draft should mandate ALL media be looped-back=2C or "NO"= if it should allow a hybrid approach of some streams being looped while ot= hers are not.
=0A= >=3B >=3B
=0A= >=3B >=3B For reference=2C the draft is here:
=0A= >=3B >=3B =3Bhttp://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24<= /a>
=0A= >=3B >=3B
=0A= >=3B >=3B -hadriel
=0A= >=3B >=3B
=0A= >=3B >=3B _______________________________________________
=0A= >=3B >=3B mmusic mailing list
=0A= >=3B >=3B =3Bmmusic@ietf.org
=0A= >=3B >=3B =3Bhttps:= //www.ietf.org/mailman/listinfo/mmusic
=0A= >=3B >=3B
=0A= >=3B =3B
=0A= >=3B _______________________________________________
=0A= >=3B mmusic mailing list
=0A= >=3B =3Bmmusic@ietf.org
=0A= >=3B =3Bhttps://www.i= etf.org/mailman/listinfo/mmusic
=0A=
=0A=
=0A= _______________________________________________
=0A= mmusic mailing list
=0A= mmusic@ietf.org
=0A= = https://www.ietf.org/mailman/listinfo/mmusic
=0A=
=0A=
=0A=
=0A=
= --_c3aa5e91-45e2-4f45-b90f-a53d32cdb849_-- From gunnar.hellstrom@omnitor.se Tue Nov 20 12:30: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 055FC21F878F for ; Tue, 20 Nov 2012 12:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXp8Pts6jirP for ; Tue, 20 Nov 2012 12:30:49 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 8894421F8783 for ; Tue, 20 Nov 2012 12:30:47 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 20 Nov 2012 21:30:38 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 092353A11F for ; Tue, 20 Nov 2012 21:30:38 +0100 (CET) Message-ID: <50ABE870.7050406@omnitor.se> Date: Tue, 20 Nov 2012 21:30:40 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <50ABCF23.9020605@alum.mit.edu> In-Reply-To: <50ABCF23.9020605@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 20:30:50 -0000 NO There are unforeseeable effects of requiring all or nothing. What if a new RTP based medium is registered, e.g. m=aroma. Then the logic would require that the media-loopback specification would need to be updated before m=aroma could be used at all. There is also an inconsistency in that 3.1 requires all m-lines in the sdp to include loopback payload type and the draft is valid only for RTP media. There are other media also declared by m-lines, e.g. m=message for MSRP, and many m=application are not RTP-based. A proposal taking care of this problem, but not the one above about new media would be to in 3.1 in the phrase " each individual media description" say "each individual RTP-based media description" /Gunnar On 2012-11-20 19:42, Paul Kyzivat wrote: > NO > > *Why* should the draft be limited this way if it need not be? > > Thanks, > Paul > > On 11/20/12 1:16 PM, Hadriel Kaplan wrote: >> Howdy, >> during IESG review of the media-loopback draft, a discussion arose >> regarding the language around indicating media-loopback support per >> media description (i.e., per m-line), in sections 3.1 and 3.2. >> >> My interpretation/understanding was we were requiring ALL m-lines to >> indicate media-loopback; in other words it's an all-or-nothing in >> both the offer+answer, and either every media stream is looped back, >> or none are. However the text currently doesn't make this clear, and >> it could be argued either way, with pro's/con's either way too; so >> I'd like the WG's consensus on whether it should in fact be an >> all-or-none approach, or not. >> >> Please respond to this email by **Tuesday, December 4th** with a >> "YES" if the draft should mandate ALL media be looped-back, or "NO" >> if it should allow a hybrid approach of some streams being looped >> while others are not. >> >> For reference, the draft is here: >> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >> >> -hadriel >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Tue Nov 20 12:50: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 F138F21F87D5 for ; Tue, 20 Nov 2012 12:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a30ETQzOxuAf for ; Tue, 20 Nov 2012 12:50:45 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 64E1221F87B7 for ; Tue, 20 Nov 2012 12:50:45 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id RonJ1k0020bG4ec59wqk8n; Tue, 20 Nov 2012 20:50:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Rwqk1k0053ZTu2S3PwqkFR; Tue, 20 Nov 2012 20:50:44 +0000 Message-ID: <50ABED23.1000004@alum.mit.edu> Date: Tue, 20 Nov 2012 15:50:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <50ABCF23.9020605@alum.mit.edu> <2217C1EE-793D-498C-B604-8BAF604C2C86@acmepacket.com> In-Reply-To: <2217C1EE-793D-498C-B604-8BAF604C2C86@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 20:50:46 -0000 On 11/20/12 2:54 PM, Hadriel Kaplan wrote: > > Are you asking for someone to defend/explain the advantages are for limiting it, or just giving that as the rationale for your NO vote? > (I don't mean this in a negative way - I'm literally not sure if you're asking a question or being rhetorical) It was primarily a justification for my NO vote. But it is also an invitation for someone who votes yes to convince me of why. Thanks, Paul > -hadriel > > > On Nov 20, 2012, at 1:42 PM, Paul Kyzivat wrote: > >> NO >> >> *Why* should the draft be limited this way if it need not be? >> >> Thanks, >> Paul >> >> On 11/20/12 1:16 PM, Hadriel Kaplan wrote: >>> Howdy, >>> during IESG review of the media-loopback draft, a discussion arose regarding the language around indicating media-loopback support per media description (i.e., per m-line), in sections 3.1 and 3.2. >>> >>> My interpretation/understanding was we were requiring ALL m-lines to indicate media-loopback; in other words it's an all-or-nothing in both the offer+answer, and either every media stream is looped back, or none are. However the text currently doesn't make this clear, and it could be argued either way, with pro's/con's either way too; so I'd like the WG's consensus on whether it should in fact be an all-or-none approach, or not. >>> >>> Please respond to this email by **Tuesday, December 4th** with a "YES" if the draft should mandate ALL media be looped-back, or "NO" if it should allow a hybrid approach of some streams being looped while others are not. >>> >>> For reference, the draft is here: >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >>> >>> -hadriel >>> >>> _______________________________________________ >>> 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 Tue Nov 20 13:31: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 43B3521F872E for ; Tue, 20 Nov 2012 13:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlITQ4c3+ZoM for ; Tue, 20 Nov 2012 13:31:53 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9E021F86B9 for ; Tue, 20 Nov 2012 13:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1693; q=dns/txt; s=iport; t=1353447113; x=1354656713; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n1DtVENhm0y9AGohonlpBVqyviJ1N5EcKS2NKzbuxRA=; b=joJxr+6zIjjaSVRH7DbSZTyM0vxLZnT/woaNKDgMjODX8HyKWBetAEks lnFz7fF89Lfrulx04IN7+PYM4ERpnB6OTmFQDMGkLgiONUkmwp4mHrv3F IKAIYZNA7hg8k1VGfYWp4MVMH6xOMWLGaUxt6aVSP9ZJhfyoqdhc09YqX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL/1q1CtJV2a/2dsb2JhbABEDsJNFnOCHgEBAQQBAQE1NgoBEAsOCgkWDwkDAgECARUwBg0BBQIBAYgJC68CkEGMSQGEYAOIXI0igRyPJYIyW4E9AQgX X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="141563757" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 20 Nov 2012 21:31:53 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAKLVqLf015321; Tue, 20 Nov 2012 21:31:52 GMT Message-ID: <50ABF6C8.7040106@cisco.com> Date: Tue, 20 Nov 2012 16:31:52 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <50ABCF23.9020605@alum.mit.edu> In-Reply-To: <50ABCF23.9020605@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 21:31:54 -0000 One more "NO" vote - I also don't see a reason to mandate such a restriction as it may limit the use cases. -- Flemming On 11/20/12 1:42 PM, Paul Kyzivat wrote: > NO > > *Why* should the draft be limited this way if it need not be? > > Thanks, > Paul > > On 11/20/12 1:16 PM, Hadriel Kaplan wrote: >> Howdy, >> during IESG review of the media-loopback draft, a discussion arose >> regarding the language around indicating media-loopback support per >> media description (i.e., per m-line), in sections 3.1 and 3.2. >> >> My interpretation/understanding was we were requiring ALL m-lines to >> indicate media-loopback; in other words it's an all-or-nothing in >> both the offer+answer, and either every media stream is looped back, >> or none are. However the text currently doesn't make this clear, and >> it could be argued either way, with pro's/con's either way too; so >> I'd like the WG's consensus on whether it should in fact be an >> all-or-none approach, or not. >> >> Please respond to this email by **Tuesday, December 4th** with a >> "YES" if the draft should mandate ALL media be looped-back, or "NO" >> if it should allow a hybrid approach of some streams being looped >> while others are not. >> >> For reference, the draft is here: >> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >> >> -hadriel >> >> _______________________________________________ >> 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 Tue Nov 20 13: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 C4A0921F866C for ; Tue, 20 Nov 2012 13:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLgUy1SzMGIl for ; Tue, 20 Nov 2012 13:39:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2775D21F865B for ; Tue, 20 Nov 2012 13:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1373; q=dns/txt; s=iport; t=1353447579; x=1354657179; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TmyMK9DHMR3HLeKr4PycgV+hZoKR6nwplgnwnCmaA2c=; b=lGaGd8LspbWH7JETLQ2dFRd/7GDk+C2rUbaGJh+gnV0dO+gx50AG8L2I UZr+9WnDGfZAAOnXiwCzyUKnOqUruY+HgJyOEhz5JeZhELmJ7aCxOBMGP 1pxX+QYHYR1/OjfQsiR5qBlex5xS78eqbpDpxv1QnuQc7JVA4bibj7+T6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEL3q1CtJXHB/2dsb2JhbABEvwmDUhZzgh4BAQEEOEABEAsYCRYPCQMCAQIBRQYKAwEHAQGICa8IkEOMNYR1A4hcjSKQQYMN X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144606575" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 20 Nov 2012 21:39:38 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAKLdciT003646; Tue, 20 Nov 2012 21:39:38 GMT Message-ID: <50ABF899.3050009@cisco.com> Date: Tue, 20 Nov 2012 16:39:37 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> <50AA6363.7040201@alvestrand.no> <50AA64F2.4020607@nostrum.com> <50AB43AD.7000007@alvestrand.no> In-Reply-To: <50AB43AD.7000007@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) 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 Nov 2012 21:39:39 -0000 On 11/20/12 3:47 AM, Harald Alvestrand wrote: > On 11/19/2012 05:57 PM, Adam Roach wrote: >> On 11/19/12 10:50, Harald Alvestrand wrote: >>>> ...T.38 fax isn't one of them. Sadly. >>> >>> What's your scenario where T.38 fax over RTP is relevant when file >>> transfer over a reliable channel is available between the same 2 >>> devices? >> >> This is a rat hole that I'm not going to dive too far into, but my >> understanding is that the tenacity of fax as an underlying technology >> has to do with a substantial body of U.S. case law that establishes >> that faxed legal documents are binding, while leaving the issue of >> transmission using a technology known by any other name unsettled. >> >> Is this a mind-numbingly stupid reason for it to hang on? Yeah, >> maybe. Does that change the facts on the ground? No. Not even a >> little bit. > Sympathy. I've read the original judge's opinion in the English court > case that established telex as legally binding - he explicitly said "I > have this opinion not because it is technically sound, but because it > is necessary to keep commerce flowing". We're still there, and the fax > industry keeps chugging along because of it. > > Still, I don't see the compelling use case for T.38 fax over RTP *into > browsers*. Why not if that's the only client I have ? -- Flemming From fandreas@cisco.com Tue Nov 20 13:49: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 5DA7621F87EC for ; Tue, 20 Nov 2012 13:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNJd69EnrPpJ for ; Tue, 20 Nov 2012 13:49:47 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8570421F87EA for ; Tue, 20 Nov 2012 13:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3972; q=dns/txt; s=iport; t=1353448187; x=1354657787; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7EayNcbzP+YuCggP/sFpgDMe9PJKXv+AVgLmgLToO9o=; b=YS0bn/KUpU/JtGvAX08OMKSUdBEcPzLWfsixbJiSmyuD2904r22lwdJW OFznpeJxvDoYaTbvnCQvCv1HTPpfwVw9WhlpMTeLbyAWFKi8OlovevyMI nqybVIW5rF4HaC/u9kWZ0CNwYZju+LyHz2xFeo8rTyi+qm/RRlsdJvV3Q 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALr3q1CrRDoJ/2dsb2JhbAAuFALCWxZzgh4BAQEEOEEQCxgJCgMYDwJGBgoDAQcBAYgIrwmQQ4w4gUcLgyADiFyNIpBBgw0 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="61420065" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 20 Nov 2012 21:49:46 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAKLnj2D006362; Tue, 20 Nov 2012 21:49:46 GMT Message-ID: <50ABFAF9.60609@cisco.com> Date: Tue, 20 Nov 2012 16:49:45 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Roach References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> In-Reply-To: <50AA527C.6060200@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 21:49:48 -0000 On 11/19/12 10:38 AM, Adam Roach wrote: > On 11/18/12 23:12, Harald Alvestrand wrote: >> >> The M-line is problematic because it binds together multiple things: >> >> - A top level media type >> - A set of parameters for media transmission *in all directions* >> (bound to payload type) >> - Transport information (the "RTP session" data) >> >> >> SDP M-lines are already problematic as soon as you want different >> parameters in the two directions. It only goes downhill from there >> when one does multiple flows with varying characteristics. >> >> As I said in Atlanta: SDP M-lines have been walking with one foot on >> the "I'm an RTP session" bank of the canal and with the other foot on >> the "I'm a media stream description" bank of the canal. > > I agree with your characterization of the situation. I'm a little > surprised that it doesn't lead you to the same conclusion as I've > reached. > > There are, at the moment, 176 attributes in the IANA registry that are > applicable to m= sections: > > 3GPP-Adaptation-Support 3GPP-Asset-Information 3GPP-QoE-Metrics > 3GPP-SRTP-Config 3gpp-videopostdecbufsize FEC FEC-OTI-extension > FEC-declaration SRTPAuthentication SRTPROCTxRate T38FaxFillBitRemoval > T38FaxMaxBuffer T38FaxMaxDatagram T38FaxRateManagement > T38FaxTranscodingJBIG T38FaxTranscodingMMR T38FaxUdpEC T38FaxVersion > T38MaxBitRate T38VendorInfo X-decbyterate X-initpostdecbufperiod > X-initpredecbufperiod X-predecbufsize aal2CPS aal2CPSSDUrate > aal2sscs3661assured aal2sscs3661unassured aal2sscs3662 aal5sscop > aalApp aalType abrParms abrSetup acap accept-types accept-wrapped-types > acfg alt alt-default-id anycast atmQOSparms atmTrfcDesc atmmap bcob > bearerSigIE bearerType cache candidate capability cbrRate cdsc > cfw-id chain channel clkrec cmid codecconfig conf confid connection > content-desc cpar cparmax cparmin cpsSDUsize creq crypto csup curr > dccp-port dccp-service-code depend des dsel ecan ecn-capable-rtp > eecid extmap fec fec-repair-flow fec-source-flow file-date > file-disposition file-icon file-range file-selector file-transfer-id > fingerprint floorctrl floorid flute-ch flute-tsi fmtp framerate > framesize fsel g.3gpp.cat g.3gpp.crs gc h248item ice-mismatch ice-pwd > ice-ufrag ike-setup imageattr inactive isup_usi key-mgmt label lang > lij max-size maxprate maxptime mbms-flowid mbms-mode mbms-repair > mid msrp-cema multicast-rtcp omr-codecs omr-m-att omr-m-bw omr-m-cksum > omr-s-att omr-s-bw omr-s-cksum onewaySel orient path pcfg portmapping-req > profileDesc prtfl psk-fingerprint ptime qos-mech-recv qos-mech-send > qosClass quality rams-updates recvonly remote-candidates repair-window > resource rtcp rtcp-fb rtcp-mux rtcp-rsize rtcp-unicast rtcp-xr > rtpmap rtpred1 rtpred2 sbc sdplang secondary-realm sendonly sendrecv > setup silenceSupp source-filter sqn ssrc ssrc-group stc stkmstream > structure tcap uiLayer1_Prot upcc userid visited-realm vsel zrtp-hash > > Some of these are applicable to the RTP session; others only make > sense as applied to a single media stream. > > If we choose to make each m= section represent one media stream, then > these attributes are applicable as-is. Unfortunately not; some of them are, some of them are not (typically because they are attributes related to the "stream" part more than the "media format" part). SDES and ICE are examples that require some form of selection. There was an off-line discussion between a few folks in Atlanta about taking a look at every single SDP attribute defined today (and the other SDP parameters) and determine for each if it would work "as-is" in a bundle scenario or whether it would require some sort of special treatment and what that would be (e.g "aggregation" or "pick-one"). I'm not sure that work has been started yet, but it's probably a good way of making progress on this part of the discussion. Thanks -- Flemming From fandreas@cisco.com Tue Nov 20 13:55: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 069AA21F8675 for ; Tue, 20 Nov 2012 13:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wljG9CZjzdRj for ; Tue, 20 Nov 2012 13:55:54 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 148B121F865B for ; Tue, 20 Nov 2012 13:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14878; q=dns/txt; s=iport; t=1353448554; x=1354658154; h=message-id:date:from:mime-version:to:subject; bh=0aOBe6UtI+BhWn6OyMaccxTRSk+r7hFDMD8/bUoOmzo=; b=ijebNClKgohxBhFkZe4Ad7DqkQ6EWk30AQVrcDgtuJmTsJV7urO7OHko X5SvaZFt1YaGVRThc3bFupid53KKlOhf2fdKUEAH+G5AQYnZWrKb/TPcD 0xfmn4Dqsb6qbV1QlmsCGtWf0PPt3WKEoZP3RdZc+zgUIebmeS4clVgH5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFABr8q1CtJXG+/2dsb2JhbABEi3+2XBZzgkJbPRYYAwIBAgFLAQwIAQEFEodyC658kEOMNYR1A4hcjSKBHI8lgw0 X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="141571520" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 20 Nov 2012 21:55:53 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAKLtqSF003671; Tue, 20 Nov 2012 21:55:53 GMT Message-ID: <50ABFC68.8040001@cisco.com> Date: Tue, 20 Nov 2012 16:55:52 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic , draft-ietf-mmusic-rtsp-nat@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060209080304050108030605" Subject: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-14 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 Nov 2012 21:55:55 -0000 This is a multi-part message in MIME format. --------------060209080304050108030605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-rtsp-nat-14 as Proposed Standard. Please review and provide any comments you may have on the document by December 5, 2012. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks Flemming Draft Info: This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : Jeff Goldberg Magnus Westerlund Thomas Zeng Filename : draft-ietf-mmusic-rtsp-nat-14.txt Pages : 31 Date : 2012-11-15 Abstract: This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------060209080304050108030605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for

    draft-ietf-mmusic-rtsp-nat-14

as Proposed Standard. Please review and provide any comments you may have on the document by December 5, 2012. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.


Thanks

       Flemming


Draft Info:

 
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)
	Author(s)       : Jeff Goldberg
                          Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-14.txt
	Pages           : 31
	Date            : 2012-11-15

Abstract:
   This document defines a solution for Network Address Translation
   (NAT) traversal for datagram based media streams setup and controlled
   with Real-time Streaming Protocol version 2 (RTSP 2.0).  It uses
   Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
   signalling channel, defining the necessary extra RTSP extensions and
   procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-14


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------060209080304050108030605-- From adam@nostrum.com Tue Nov 20 13: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 5C92521F8675 for ; Tue, 20 Nov 2012 13:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xma0NU-lyqm for ; Tue, 20 Nov 2012 13:56:25 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C813721F865B for ; Tue, 20 Nov 2012 13:56:24 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAKLu8Sc025439 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 15:56:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50ABFC78.90101@nostrum.com> Date: Tue, 20 Nov 2012 15:56:08 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com> <50AA6363.7040201@alvestrand.no> <50AA64F2.4020607@nostrum.com> <50AB43AD.7000007@alvestrand.no> In-Reply-To: <50AB43AD.7000007@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs)) 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 Nov 2012 21:56:25 -0000 On 11/20/12 02:47, Harald Alvestrand wrote: > On 11/19/2012 05:57 PM, Adam Roach wrote: >> On 11/19/12 10:50, Harald Alvestrand wrote: >>>> ...T.38 fax isn't one of them. Sadly. >>> >>> What's your scenario where T.38 fax over RTP is relevant when file >>> transfer over a reliable channel is available between the same 2 >>> devices? >> >> This is a rat hole that I'm not going to dive too far into, but my >> understanding is that the tenacity of fax as an underlying technology >> has to do with a substantial body of U.S. case law that establishes >> that faxed legal documents are binding, while leaving the issue of >> transmission using a technology known by any other name unsettled. >> >> Is this a mind-numbingly stupid reason for it to hang on? Yeah, >> maybe. Does that change the facts on the ground? No. Not even a >> little bit. > Sympathy. I've read the original judge's opinion in the English court > case that established telex as legally binding - he explicitly said "I > have this opinion not because it is technically sound, but because it > is necessary to keep commerce flowing". We're still there, and the fax > industry keeps chugging along because of it. > > Still, I don't see the compelling use case for T.38 fax over RTP *into > browsers*. +---------+ +------------+ +---------+ | Web App |---| SIP Server |---| | +---------+ +------------+ | | +-------------+ | | PSTN GW |--| Fax Machine | +---------+ media | | +-------------+ | Browser |--------------------| | +---------+ +---------+ /a From rbarnes@bbn.com Tue Nov 20 14:09: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 7D88F21F874B for ; Tue, 20 Nov 2012 14:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.37 X-Spam-Level: X-Spam-Status: No, score=-106.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Oatc5jcbv9 for ; Tue, 20 Nov 2012 14:09:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BF26121F86B9 for ; Tue, 20 Nov 2012 14:09:40 -0800 (PST) Received: from [128.89.253.219] (port=51241) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Taw0h-0001tZ-9P; Tue, 20 Nov 2012 17:09:39 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <50ABF6C8.7040106@cisco.com> Date: Tue, 20 Nov 2012 17:09:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50ABCF23.9020605@alum.mit.edu> <50ABF6C8.7040106@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1499) Cc: mmusic@ietf.org, Paul Kyzivat Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 22:09:41 -0000 I lean in favor of YES, because it seems to be much simpler and address = the most pressing use cases. (I haven't been involved deeply in the discussion, though; is there = something I'm missing?) On Nov 20, 2012, at 4:31 PM, Flemming Andreasen = wrote: > One more "NO" vote - I also don't see a reason to mandate such a = restriction as it may limit the use cases. >=20 > -- Flemming >=20 > On 11/20/12 1:42 PM, Paul Kyzivat wrote: >> NO >>=20 >> *Why* should the draft be limited this way if it need not be? >>=20 >> Thanks, >> Paul >>=20 >> On 11/20/12 1:16 PM, Hadriel Kaplan wrote: >>> Howdy, >>> during IESG review of the media-loopback draft, a discussion arose = regarding the language around indicating media-loopback support per = media description (i.e., per m-line), in sections 3.1 and 3.2. >>>=20 >>> My interpretation/understanding was we were requiring ALL m-lines to = indicate media-loopback; in other words it's an all-or-nothing in both = the offer+answer, and either every media stream is looped back, or none = are. However the text currently doesn't make this clear, and it could = be argued either way, with pro's/con's either way too; so I'd like the = WG's consensus on whether it should in fact be an all-or-none approach, = or not. >>>=20 >>> Please respond to this email by **Tuesday, December 4th** with a = "YES" if the draft should mandate ALL media be looped-back, or "NO" if = it should allow a hybrid approach of some streams being looped while = others are not. >>>=20 >>> For reference, the draft is here: >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >>>=20 >>> -hadriel >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fandreas@cisco.com Tue Nov 20 15:11: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 2F44021F8793 for ; Tue, 20 Nov 2012 15:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.244 X-Spam-Level: X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtfOh7P7VpX6 for ; Tue, 20 Nov 2012 15:11:34 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C321F8787 for ; Tue, 20 Nov 2012 15:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2478; q=dns/txt; s=iport; t=1353453094; x=1354662694; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dgCVvZgUQVc5lRgZMe/8ArWhRdD36g+sZ3OGSd3S3bg=; b=bqaU0o0g2CSXRKz+1VGQPS1M9n86tTp3mSONqIAviA1JbcROqyhPYGNW qQXZcnXKf8eTkZVbaTpXAjUibCUQaFqCJUtPGLPUvrJaRVlIikY0+05Qn J/F4tihJ883F2G14lzicPDmOMNeVK/rEokb+mVBpdt9BMxwfvW4Wl0dpe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL0MrFCtJXG+/2dsb2JhbABEwlsWc4IeAQEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQEXh3ILrmiQPYw0FAGETQOIXI0igRyPJYMNgT0BCBc X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144590816" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 20 Nov 2012 23:11:33 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAKNBX3H026937; Tue, 20 Nov 2012 23:11:33 GMT Message-ID: <50AC0E24.9010908@cisco.com> Date: Tue, 20 Nov 2012 18:11:32 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Richard L. Barnes" References: <50ABCF23.9020605@alum.mit.edu> <50ABF6C8.7040106@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, Paul Kyzivat Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 23:11:35 -0000 We normally try and provide general solutions rather than focus on specific use cases. Looking at media streams in general, we negotiate and accept/reject them independently (and likewise for preconditions). Why should this be any different ? Thanks -- Flemming On 11/20/12 5:09 PM, Richard L. Barnes wrote: > I lean in favor of YES, because it seems to be much simpler and address the most pressing use cases. > > (I haven't been involved deeply in the discussion, though; is there something I'm missing?) > > > > On Nov 20, 2012, at 4:31 PM, Flemming Andreasen wrote: > >> One more "NO" vote - I also don't see a reason to mandate such a restriction as it may limit the use cases. >> >> -- Flemming >> >> On 11/20/12 1:42 PM, Paul Kyzivat wrote: >>> NO >>> >>> *Why* should the draft be limited this way if it need not be? >>> >>> Thanks, >>> Paul >>> >>> On 11/20/12 1:16 PM, Hadriel Kaplan wrote: >>>> Howdy, >>>> during IESG review of the media-loopback draft, a discussion arose regarding the language around indicating media-loopback support per media description (i.e., per m-line), in sections 3.1 and 3.2. >>>> >>>> My interpretation/understanding was we were requiring ALL m-lines to indicate media-loopback; in other words it's an all-or-nothing in both the offer+answer, and either every media stream is looped back, or none are. However the text currently doesn't make this clear, and it could be argued either way, with pro's/con's either way too; so I'd like the WG's consensus on whether it should in fact be an all-or-none approach, or not. >>>> >>>> Please respond to this email by **Tuesday, December 4th** with a "YES" if the draft should mandate ALL media be looped-back, or "NO" if it should allow a hybrid approach of some streams being looped while others are not. >>>> >>>> For reference, the draft is here: >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >>>> >>>> -hadriel >>>> >>>> _______________________________________________ >>>> 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 bernard_aboba@hotmail.com Tue Nov 20 16:50: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 E09C621F8570 for ; Tue, 20 Nov 2012 16:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.091 X-Spam-Level: X-Spam-Status: No, score=-102.091 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWbrPJuwKyor for ; Tue, 20 Nov 2012 16:50:38 -0800 (PST) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id 105E021F84EB for ; Tue, 20 Nov 2012 16:50:37 -0800 (PST) Received: from BLU002-W217 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 16:50:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_" X-Originating-IP: [131.107.0.114] From: Bernard Aboba To: "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Date: Tue, 20 Nov 2012 16:50:36 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 21 Nov 2012 00:50:37.0007 (UTC) FILETIME=[386EBDF0:01CDC782] Subject: Re: [MMUSIC] RFC 5576 is da answah 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 Nov 2012 00:50:39 -0000 --_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer said: "RFC 5576 is da answah :)=0A= =0A= http://tools.ietf.org/rfc/rfc5576.txt=0A= =0A= Or=2C do you have specific examples/use-cases where it wouldn't work?=0A= " [BA] In the WebRTC context=2C IMHO there are a lot of unanswered questions = in RFC 5576.=20 >From Section 5: Endpoints MUST NOT assume that only the sources mentioned in SDP will be present in an RTP session=3B additional sources=2C with previously unmentioned SSRC IDs=2C can be added at any time=2C and endpoints MUST b= e prepared to receive packets from these sources. (How endpoints handle such packets is not specified here=3B they SHOULD be handled in the same manner as packets from additional sources would be handled had the endpoint not received any a=3Dssrc: attributes at all.) [BA] While the advice above seems generally sensible=2C the meaning of "pre= pared to receive" isn't very clear. Implementations may differ in how they= respond if they don't receive any a=3Dssrc attributes. For example=2C an= implementation might only be able to deal with a single undeclared source = or perhaps not at all. So being "prepared to receive" isn't enough to be a= ble to deal with an RTP translator=2C for example.=20 >From Section 8: When used with the SDP Offer/Answer Model [RFC3264]=2C SDP source- specific attributes describe only the sources that each party is willing to send (whether it is sending RTP data or RTCP report blocks). No mechanism is provided by which an answer can accept or reject individual sources within a media stream=3B if the set of sources in a media stream is unacceptable=2C the answerer's only option is to reject the media stream or the entire multimedia session. [BA] The advice above appears to only apply to an answerer that supports RF= C 5576. If it doesn't support RFC 5576=2C then it will presumably ignore t= he a=3Dssrc lines=2C but may not reject the media stream (by setting the po= rt to zero) or the entire session. In this case=2C it may not be clear to= the Offerer whether in fact it can send all the declared ssrc's or not. C= ontrast this with the CLUE approach in which receiver gets to indicate what= media captures it would like to receive.=20 >From Section 9: Source descriptions are specified in this document such that RTP endpoints that are compliant with the RTP specification [RFC3550] will be able to decode the media streams they describe whether or not they support explicit source descriptions. However=2C some deployed RTP implementations may not actually support multiple media sources in a media stream. Media senders MAY wish to restrict themselves to a single source at a time unless they have some means of concluding that the receivers of the media stream support source multiplexing. [BA] The obvious way for an answerer to indicate support for RFC 5576 woul= d be to include a=3Dssrc lines in the answer. If the Answer doesn't inclu= de a=3Dssrc lines=2C should the Offerer conclude that only one source can b= e sent? The above paragraph indicates this is optional.=20 = --_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christer said:

"RFC 5576 = is da answah :)=0A= =0A= http://t= ools.ietf.org/rfc/rfc5576.txt=0A= =0A= Or=2C do you have specific examples/use-cases where it wouldn't work?=0A= "

[BA] In the WebRTC context=2C IMHO there are a lot of unanswered q= uestions in RFC 5576.

From Section 5:

 =3B =3B Endpo= ints MUST NOT assume that only the sources mentioned in SDP will
 = =3B =3B be present in an RTP session=3B additional sources=2C with prev= iously
 =3B =3B unmentioned SSRC IDs=2C can be added at any time= =2C and endpoints MUST be
 =3B =3B prepared to receive packets f= rom these sources. =3B (How endpoints
 =3B =3B handle such p= ackets is not specified here=3B they SHOULD be handled in
 =3B = =3B the same manner as packets from additional sources would be handled
=  =3B =3B had the endpoint not received any a=3Dssrc: attributes at = all.)

[BA] While the advice above seems generally sensible=2C the me= aning of "prepared to receive" isn't very clear. =3B Implementations ma= y differ in how they respond if they don't receive any a=3Dssrc attributes.=  =3B =3B For example=2C an implementation might only be able to dea= l with a single undeclared source or perhaps not at all. =3B So being "= prepared to receive" isn't enough to be able to deal with an RTP translator= =2C for example.

From Section 8:

 =3B =3B When used = with the SDP Offer/Answer Model [RFC3264]=2C SDP source-
 =3B = =3B specific attributes describe only the sources that each party is
&nb= sp=3B =3B willing to send (whether it is sending RTP data or RTCP repor= t
 =3B =3B blocks). =3B No mechanism is provided by which an= answer can accept or
 =3B =3B reject individual sources within = a media stream=3B if the set of
 =3B =3B sources in a media stre= am is unacceptable=2C the answerer's only option
 =3B =3B is to = reject the media stream or the entire multimedia session.

[BA] The a= dvice above appears to only apply to an answerer that supports RFC 5576.&nb= sp=3B If it doesn't support RFC 5576=2C then it will presumably ignore the = a=3Dssrc lines=2C but may not reject the media stream (by setting the port = to zero) or the entire session. =3B =3B In this case=2C it may not = be clear to the Offerer whether in fact it can send all the declared ssrc's= or not. =3B Contrast this with the CLUE approach in which receiver get= s to indicate what media captures it would like to receive.

From Se= ction 9:

 =3B =3B Source descriptions are specified in this = document such that RTP
 =3B =3B endpoints that are compliant wit= h the RTP specification [RFC3550]
 =3B =3B will be able to decod= e the media streams they describe whether or not
 =3B =3B they s= upport explicit source descriptions. =3B However=2C some deployed
&n= bsp=3B =3B RTP implementations may not actually support multiple media = sources
 =3B =3B in a media stream. =3B Media senders MAY wi= sh to restrict themselves to
 =3B =3B a single source at a time = unless they have some means of concluding
 =3B =3B that the rece= ivers of the media stream support source multiplexing.

[BA] =3B = The obvious way for an answerer to indicate support for RFC 5576 would be t= o include a=3Dssrc lines in the answer. =3B =3B If the Answer doesn= 't include a=3Dssrc lines=2C should the Offerer conclude that only one sour= ce can be sent? =3B =3B The above paragraph indicates this is optio= nal.
= --_1375a7c9-5dab-4edc-b8cc-c38d1fadb17a_-- From mperumal@cisco.com Tue Nov 20 20:31:02 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 1FF1421F8767 for ; Tue, 20 Nov 2012 20:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81SzYv1aiUIt for ; Tue, 20 Nov 2012 20:31:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3D76521F8761 for ; Tue, 20 Nov 2012 20:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1775; q=dns/txt; s=iport; t=1353472261; x=1354681861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hE7NZtACC6vmGMjMVpEgxL+lX/4mA1cYWTteVKqZQYs=; b=EyEds0lylZKCniytbjjrPfoSrts44Ba3j8T18QyTzCPl8DGTKzLdnSJq b+dod27bwVrn0NAtREa6inOqpekdiD+b5dGMKX4Sztye1engTTyhku4A5 APd3GkprEvW5qD8THeiU4GGt2RN2Dml1MluS6tiJdiCsqUKvcSimp7P1+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAClYrFCtJXG9/2dsb2JhbABEwlYWc4IeAQEBBAEBATc0CwwEAgEIDgMEAQELFAkHJwsUCQgCBAENBQiIBQu/GIw0GoNnYQOXGo8lgm+BZBce X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144674249" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 21 Nov 2012 04:31:00 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAL4V03M018314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Nov 2012 04:31:00 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.85]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 22:31:00 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Hadriel Kaplan , "mmusic@ietf.org (E-mail)" Thread-Topic: NEED WG CONSENSUS: media-loopback is all-or-nothing Thread-Index: AQHNx0sa0Z8XaBiMtU6BXcD6oqpbWZfzssoA Date: Wed, 21 Nov 2012 04:30:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Gonzalo Camarillo , "draft-ietf-mmusic-media-loopback@tools.ietf.org" Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 04:31:02 -0000 |Please respond to this email by **Tuesday, December 4th** with a "YES" if = the=20 |draft should mandate ALL media be looped-back, or "NO" if it should allow = a=20 |hybrid approach of some streams being looped while others are not. NO. Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f Hadriel Kaplan |Sent: Tuesday, November 20, 2012 11:46 PM |To: mmusic@ietf.org (E-mail) |Cc: Gonzalo Camarillo; draft-ietf-mmusic-media-loopback@tools.ietf.org |Subject: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing | |Howdy, |during IESG review of the media-loopback draft, a discussion arose regardi= ng the language around |indicating media-loopback support per media description (i.e., per m-line)= , in sections 3.1 and 3.2. | |My interpretation/understanding was we were requiring ALL m-lines to indic= ate media-loopback; in other |words it's an all-or-nothing in both the offer+answer, and either every me= dia stream is looped back, |or none are. However the text currently doesn't make this clear, and it c= ould be argued either way, |with pro's/con's either way too; so I'd like the WG's consensus on whether= it should in fact be an |all-or-none approach, or not. | |Please respond to this email by **Tuesday, December 4th** with a "YES" if = the draft should mandate ALL |media be looped-back, or "NO" if it should allow a hybrid approach of some= streams being looped while |others are not. | |For reference, the draft is here: |http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 | |-hadriel | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From bill.wu@huawei.com Wed Nov 21 00:08: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 8713021F874A; Wed, 21 Nov 2012 00:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqZ7aAi0gFCI; Wed, 21 Nov 2012 00:07:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7547D21F873A; Wed, 21 Nov 2012 00:07:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMZ71220; Wed, 21 Nov 2012 08:07:55 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 08:07:18 +0000 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 08:07:49 +0000 Received: from w53375 (10.138.41.149) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 16:07:42 +0800 Message-ID: From: Qin Wu To: Paul Kyzivat , , References: <50ABA4ED.5070103@alum.mit.edu> Date: Wed, 21 Nov 2012 16:07:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: xrblock@ietf.org Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 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 Nov 2012 08:08:01 -0000 SGksIFBhdWw6DQpUaGFuayBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cywgcGxlYXNlIHNlZSBt eSByZXBseSBpbmxpbmUgYmVsb3cuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgS3l6aXZhdCIgPHBreXppdmF0QGFsdW0ubWl0LmVk dT4NClRvOiA8bW11c2ljQGlldGYub3JnPjsgPGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1 cnN0LWdhcC1kaXNjYXJkQHRvb2xzLmlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIg MjAsIDIwMTIgMTE6NDIgUE0NClN1YmplY3Q6IFtNTVVTSUNdIFNEUCBEaXJlY3RvcmF0ZSByZXZp ZXcgb2YgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItYnVyc3QtZ2FwLWRpc2NhcmQtMDYNCg0K DQo+SSBhbSB0aGUgYXNzaWduZWQgU0RQIGRpcmVjdG9yYXRlIHJldmlld2VyIGZvciANCj4gZHJh ZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItYnVyc3QtZ2FwLWRpc2NhcmQtMDYuIEZvciBiYWNrZ3Jv dW5kIG9uIFNEUCANCj4gZGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgdGhlIEZBUSBhdCANCj4gPGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9zZHAuaHRtbD4uDQo+IA0KPiBQbGVh c2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBi ZWZvcmUgDQo+IHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiAqIFN1 bW1hcnk6DQo+IA0KPiBUaGUgU0RQIHN5bnRheCBkZWZpbmVkIGluIHRoaXMgZHJhZnQgaXMgdHJp dmlhbCBhbmQgZmluZS4NCj4gSXQgZXhlcmNpc2VzIGEgZGVmaW5lZCBleHRlbnNpb24gcG9pbnQg aW4gUkZDMzYxMS4gVGhhdCBSRkMgZGVmaW5lcyBhbiANCj4gSUFOQSByZWdpc3RyeSBmb3IgbmV3 IHZhbHVlcyB1c2luZyB0aGlzIGV4dGVuc2lvbiBwb2ludC4gVGhpcyBkb2N1bWVudCANCj4gbm9t aW5hbGx5IHN1cHBsaWVzIHRoZSBpbmZvcm1hdGlvbiBjYWxsZWQgZm9yIHdoZW4gcmVnaXN0ZXJp bmcuIEhvd2V2ZXIsIA0KPiB0aGUgc2VtYW50aWNzIGZvciBwcm9jZXNzaW5nIHRoZSBuZXcgc3lu dGF4IGlzIHVuZGVyc3BlY2lmaWVkLCBhbmQgbmVlZHMgDQo+IHRvIGJlIGZ1cnRoZXIgZWxhYm9y YXRlZC4NCj4gDQo+ICogTmV3IFNEUCBpbmZvcm1hdGlvbiBlbGVtZW50czoNCj4gDQo+IFNlY3Rp b24gNSBvZiB0aGlzIGRyYWZ0IGF1Z21lbnRzIHRoZSBTRFAgYXR0cmlidXRlICJydGNwLXhyIiBk ZWZpbmVkIGluIA0KPiBSRkMzNjExLCBwcm92aWRpbmcgYW4gYWRkaXRpb25hbCB2YWx1ZTogImJy c3QtZ2FwLWRzY3JkIi4NCj4gDQo+ICogVGVjaG5pY2FsIElzc3VlczoNCj4gDQo+IFJGQzM2MTEg ZXN0YWJsaXNoZXMgYW4gSUFOQSByZWdpc3RyeSBmb3IgbmV3IHZhbHVlcywgYW5kIHJlcXVpcmVz IHRoYXQgDQo+IHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gYmUgc3VwcGxpZWQgd2hlbiByZWdp c3RlcmluZyBhIG5ldyB2YWx1ZToNCj4gDQo+ICAgIC0gIENvbnRhY3QgaW5mb3JtYXRpb24gb2Yg dGhlIG9uZSBkb2luZyB0aGUgcmVnaXN0cmF0aW9uLCBpbmNsdWRpbmcNCj4gICAgICAgYXQgbGVh c3QgbmFtZSwgYWRkcmVzcywgYW5kIGVtYWlsLg0KPiANCj4gICAgLSAgQW4gQXVnbWVudGVkIEJh Y2t1cy1OYXVyIEZvcm0gKEFCTkYpIFsyXSBkZWZpbml0aW9uIG9mIHRoZQ0KPiAgICAgICBwYXJh bWV0ZXIsIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgImZvcm1hdC1leHQiIGRlZmluaXRpb24gb2YN Cj4gICAgICAgU2VjdGlvbiA1LjEuDQo+IA0KPiAgICAtICBBIGRlc2NyaXB0aW9uIG9mIHdoYXQg dGhlIHBhcmFtZXRlciByZXByZXNlbnRzIGFuZCBob3cgaXQgc2hhbGwgYmUNCj4gICAgICAgaW50 ZXJwcmV0ZWQsIGJvdGggbm9ybWFsbHkgYW5kIGluIE9mZmVyL0Fuc3dlci4NCj4gDQo+IFRoZSBm aXJzdCB0d28gb2YgdGhlIGFib3ZlIGFyZSBwcm9wZXJseSBzdXBwbGllZC4gQnV0IHRoZSBvZmZl ci9hbnN3ZXIgDQo+IGJlaGF2aW9yIGlzIGluc3VmZmljaWVudGx5IHNwZWNpZmllZC4gKCJXaGVu IFNEUCBpcyB1c2VkIGluIG9mZmVyLWFuc3dlciANCj4gY29udGV4dCwgdGhlIFNEUCBPZmZlci9B bnN3ZXIgdXNhZ2UgZGVmaW5lZCBpbiBbUkZDMzYxMV0gYXBwbGllcy4iKQ0KPiANCj4gUkZDMzYx MSBzdGF0ZXM6DQo+IA0KPiAgICBFYWNoICJydGNwLXhyIiBwYXJhbWV0ZXIgYmVsb25ncyB0byBv bmUgb2YgdHdvIGNhdGVnb3JpZXMuICBUaGUgZmlyc3QNCj4gICAgY2F0ZWdvcnksIHRoZSB1bmls YXRlcmFsIHBhcmFtZXRlcnMsIGFyZSBmb3IgcmVwb3J0IGJsb2NrcyB0aGF0DQo+ICAgIHNpbXBs eSByZXBvcnQgb24gdGhlIFJUUCBzdHJlYW0gYW5kIHJlbGF0ZWQgbWV0cmljcy4gIFRoZSBzZWNv bmQNCj4gICAgY2F0ZWdvcnksIGNvbGxhYm9yYXRpdmUgcGFyYW1ldGVycywgYXJlIGZvciBYUiBi bG9ja3MgdGhhdCBpbnZvbHZlDQo+ICAgIGFjdGlvbnMgYnkgbW9yZSB0aGFuIG9uZSBwYXJ0eSBp biBvcmRlciB0byBjYXJyeSBvdXQgdGhlaXIgZnVuY3Rpb25zLg0KPiANCj4gSXQgdGhlbiBnb2Vz IG9uIHRvIGdpdmUgZGlmZmVyZW50IG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzIGZvciBlYWNoIA0K PiBjYXRlZ29yeSBvZiBwYXJhbWV0ZXIuIFRoZSByZWZlcmVuY2UgaW4gKnRoaXMqIGRyYWZ0ICgi dGhlIFNEUCANCj4gT2ZmZXIvQW5zd2VyIHVzYWdlIGRlZmluZWQgaW4gW1JGQzM2MTFdIGFwcGxp ZXMiKSBpcyBpbnN1ZmZpY2llbnQgDQo+IGJlY2F1c2UgdGhlcmUgaXMgbm8gaW5kaWNhdGlvbiBp biB0aGlzIGRyYWZ0IHdoZXRoZXIgdGhlIG5ldyB2YWx1ZSBpcyBhIA0KPiAidW5pbGF0ZXJhbCIg b3IgImNvbGxhYm9yYXRpdmUiIHBhcmFtZXRlci4NCj4gDQo+IFRoZSBkcmFmdCBuZWVkcyB0byBi ZSByZXZpc2VkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4gSSAqdGhpbmsqIHRoaXMgbmV3IA0KPiBw YXJhbWV0ZXIgaXMgYSAidW5pbGF0ZXJhbCIgcGFyYW1ldGVyLiBJZiBzbywgaXQgTUFZIGJlIHN1 ZmZpY2llbnQgdG8gDQo+IHJldmlzZSBzZWN0aW9uIDUuMiBhcyBmb2xsb3dzOg0KPiANCj4gT0xE Og0KPiAgICBXaGVuIFNEUCBpcyB1c2VkIGluIG9mZmVyLWFuc3dlciBjb250ZXh0LCB0aGUgU0RQ IE9mZmVyL0Fuc3dlciB1c2FnZQ0KPiAgICBkZWZpbmVkIGluIFtSRkMzNjExXSBhcHBsaWVzLg0K PiANCj4gTkVXOg0KPiAgICBXaGVuIFNEUCBpcyB1c2VkIGluIG9mZmVyLWFuc3dlciBjb250ZXh0 LCB0aGUgU0RQIE9mZmVyL0Fuc3dlciB1c2FnZQ0KPiAgICBkZWZpbmVkIGluIFtSRkMzNjExXSBm b3IgdW5pbGF0ZXJhbCAicnRjcC14ciIgYXR0cmlidXRlIHBhcmFtZXRlcnMNCj4gICAgYXBwbGll cy4NCg0KW1Fpbl06IFRoYW5rIHlvdSBmb3IgZGlnZ2luZyBkZWVwZXIgaW50byBTRFAgb2ZmZXIg YW5zd2VyIHVzYWdlIGZvciBidXJzdCBnYXAgZGlzY2FyZC4NCkkgZnVsbHkgYWdyZWUgd2l0aCB5 b3UgdGhhdCB0aGUgbmV3IHZhbHVlIHdlIGRlZmluZWQgaGVyZSBpcyAidW5pbGF0ZXJhbCIgcGFy YW1ldGVyLiANCkFuZCB5b3VyIHByb3Bvc2VkIGNoYW5nZSBsb29rcyByZWFzb25hYmxlIHRvIG1l LiBUaGFua3MuDQoNCiANCj4gSXQgbWF5IGJlIHVzZWZ1bCB0byBwcm92aWRlIGFuIGV4cGFuZGVk IGV4cGxhbmF0aW9uLg0KDQpbUWluXTogTWF5YmUgd2UgY2FuIGFwcGVuZCBvbmUgbW9yZSBzZW50 ZW5jZSB0byB5b3VyIHByb3Bvc2VkIGNoYW5nZSB0byBzYXk6DQoiDQpGb3IgZGV0YWlsZWQgdXNh Z2UgaW4gT2ZmZXIvQW5zd2VyIGZvciB1bmlsYXRlcmFsIHBhcmFtZXRlciwgcmVmZXIgdG8gc2Vj dGlvbiA1LjIgb2YgUkZDMzYxMS4NCiINCg0KPiBSZWdhcmRzLA0KPiBQYXVsIEt5eml2YXQ= From pkyzivat@alum.mit.edu Wed Nov 21 06:29:13 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 3AE4D21F862C for ; Wed, 21 Nov 2012 06:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7DqY1YaYGZb for ; Wed, 21 Nov 2012 06:29:12 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4721F8616 for ; Wed, 21 Nov 2012 06:29:12 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta02.westchester.pa.mail.comcast.net with comcast id SCGX1k00217dt5G51EVBn3; Wed, 21 Nov 2012 14:29:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id SEVB1k00B3ZTu2S3ZEVBh2; Wed, 21 Nov 2012 14:29:11 +0000 Message-ID: <50ACE536.40601@alum.mit.edu> Date: Wed, 21 Nov 2012 09:29:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50ABA4ED.5070103@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 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 Nov 2012 14:29:13 -0000 Hi Qin, What you propose is fine with me. Thanks, Paul On 11/21/12 3:07 AM, Qin Wu wrote: > Hi, Paul: > Thank for your valuable comments, please see my reply inline below. > > Regards! > -Qin > ----- Original Message ----- > From: "Paul Kyzivat" > To: ; > Sent: Tuesday, November 20, 2012 11:42 PM > Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 > > >> I am the assigned SDP directorate reviewer for >> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06. 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 SDP syntax defined in this draft is trivial and fine. >> It exercises a defined extension point in RFC3611. That RFC defines an >> IANA registry for new values using this extension point. This document >> nominally supplies the information called for when registering. However, >> the semantics for processing the new syntax is underspecified, and needs >> to be further elaborated. >> >> * New SDP information elements: >> >> Section 5 of this draft augments the SDP attribute "rtcp-xr" defined in >> RFC3611, providing an additional value: "brst-gap-dscrd". >> >> * Technical Issues: >> >> RFC3611 establishes an IANA registry for new values, and requires that >> the following information be supplied when registering a new value: >> >> - Contact information of the one doing the registration, including >> at least name, address, and email. >> >> - An Augmented Backus-Naur Form (ABNF) [2] definition of the >> parameter, in accordance with the "format-ext" definition of >> Section 5.1. >> >> - A description of what the parameter represents and how it shall be >> interpreted, both normally and in Offer/Answer. >> >> The first two of the above are properly supplied. But the offer/answer >> behavior is insufficiently specified. ("When SDP is used in offer-answer >> context, the SDP Offer/Answer usage defined in [RFC3611] applies.") >> >> RFC3611 states: >> >> Each "rtcp-xr" parameter belongs to one of two categories. The first >> category, the unilateral parameters, are for report blocks that >> simply report on the RTP stream and related metrics. The second >> category, collaborative parameters, are for XR blocks that involve >> actions by more than one party in order to carry out their functions. >> >> It then goes on to give different offer/answer procedures for each >> category of parameter. The reference in *this* draft ("the SDP >> Offer/Answer usage defined in [RFC3611] applies") is insufficient >> because there is no indication in this draft whether the new value is a >> "unilateral" or "collaborative" parameter. >> >> The draft needs to be revised to address this issue. I *think* this new >> parameter is a "unilateral" parameter. If so, it MAY be sufficient to >> revise section 5.2 as follows: >> >> OLD: >> When SDP is used in offer-answer context, the SDP Offer/Answer usage >> defined in [RFC3611] applies. >> >> NEW: >> When SDP is used in offer-answer context, the SDP Offer/Answer usage >> defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters >> applies. > > [Qin]: Thank you for digging deeper into SDP offer answer usage for burst gap discard. > I fully agree with you that the new value we defined here is "unilateral" parameter. > And your proposed change looks reasonable to me. Thanks. > > >> It may be useful to provide an expanded explanation. > > [Qin]: Maybe we can append one more sentence to your proposed change to say: > " > For detailed usage in Offer/Answer for unilateral parameter, refer to section 5.2 of RFC3611. > " > >> Regards, >> Paul Kyzivat > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From matthew@matthew.at Wed Nov 21 07:39: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 E9EF421F86AB for ; Wed, 21 Nov 2012 07:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6lcqnKXup-R for ; Wed, 21 Nov 2012 07:39:48 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433DA21F86A4 for ; Wed, 21 Nov 2012 07:39:48 -0800 (PST) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id EECDC148038 for ; Wed, 21 Nov 2012 07:39:47 -0800 (PST) Message-ID: <50ACF5C5.2070200@matthew.at> Date: Wed, 21 Nov 2012 07:39:49 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA4C50.20508@alum.mit.edu> In-Reply-To: <50AA4C50.20508@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 15:39:49 -0000 On 11/19/2012 7:12 AM, Paul Kyzivat wrote: > > This just further illustrates the schizophrenic nature of the existing > SDP support that you are pointing out. Explaining why the W3C has chosen to use strings containing SDP as the API for WEBRTC. Matthew Kaufman From partha@parthasarathi.co.in Wed Nov 21 07:47: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 9B3FB21F8738 for ; Wed, 21 Nov 2012 07:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8lRrYqjaPyV for ; Wed, 21 Nov 2012 07:47:50 -0800 (PST) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id E849A21F8734 for ; Wed, 21 Nov 2012 07:47:49 -0800 (PST) Received: from userPC (unknown [122.172.186.155]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 0F482190836E; Wed, 21 Nov 2012 15:47:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1353512869; bh=ozxh1tYQ8IaMdwgcy4SmHSjXxZ7qNJkLg3ooyhvfhKY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=AwG1a5QInXh4c6HBRpa6zOMmkR2EzzsfNU1+Kp2DUbK8em5ezg/C8nd9jWAc5x+Ca tE3unCSdhMhA6sGKSn2t6sxkDzSyghehb8EPI5BfGyoNp8zIo1mI7PrUredHsZP3d0 X5eHMdfzY8xS52VYJk0lyngRaYTFhChvav23oOcU= From: "Parthasarathi R" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Hadriel Kaplan'" , References: In-Reply-To: Date: Wed, 21 Nov 2012 21:17:38 +0530 Message-ID: <002d01cdc7ff$8de38ae0$a9aaa0a0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNx0sa0Z8XaBiMtU6BXcD6oqpbWZfzssoAgAC9RpA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0C020A.50ACF7A5.009D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: 'Gonzalo Camarillo' , draft-ietf-mmusic-media-loopback@tools.ietf.org Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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 Nov 2012 15:47:50 -0000 NO...it is possible that some of the device may prefer to loop back only one of the stream (audio) and not the other streams (like Video). Thanks Partha -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Muthu Arul Mozhi Perumal (mperumal) Sent: Wednesday, November 21, 2012 10:01 AM To: Hadriel Kaplan; mmusic@ietf.org (E-mail) Cc: Gonzalo Camarillo; draft-ietf-mmusic-media-loopback@tools.ietf.org Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing |Please respond to this email by **Tuesday, December 4th** with a "YES" if the |draft should mandate ALL media be looped-back, or "NO" if it should allow a |hybrid approach of some streams being looped while others are not. NO. Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Tuesday, November 20, 2012 11:46 PM |To: mmusic@ietf.org (E-mail) |Cc: Gonzalo Camarillo; draft-ietf-mmusic-media-loopback@tools.ietf.org |Subject: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing | |Howdy, |during IESG review of the media-loopback draft, a discussion arose regarding the language around |indicating media-loopback support per media description (i.e., per m-line), in sections 3.1 and 3.2. | |My interpretation/understanding was we were requiring ALL m-lines to indicate media-loopback; in other |words it's an all-or-nothing in both the offer+answer, and either every media stream is looped back, |or none are. However the text currently doesn't make this clear, and it could be argued either way, |with pro's/con's either way too; so I'd like the WG's consensus on whether it should in fact be an |all-or-none approach, or not. | |Please respond to this email by **Tuesday, December 4th** with a "YES" if the draft should mandate ALL |media be looped-back, or "NO" if it should allow a hybrid approach of some streams being looped while |others are not. | |For reference, the draft is here: |http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 | |-hadriel | |_______________________________________________ |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 jonathan@vidyo.com Wed Nov 21 08:50: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 A379E21F86A2 for ; Wed, 21 Nov 2012 08:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evhzomkE-lTj for ; Wed, 21 Nov 2012 08:50:19 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 643B921F844E for ; Wed, 21 Nov 2012 08:50:19 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B83A37E1D4E; Wed, 21 Nov 2012 11:25:02 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B57FB7E1D42; Wed, 21 Nov 2012 11:25:00 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 21 Nov 2012 11:50:03 -0500 From: Jonathan Lennox To: Bernard Aboba Date: Wed, 21 Nov 2012 11:50:15 -0500 Thread-Topic: [MMUSIC] RFC 5576 is da answah Thread-Index: Ac3ICEfROKZlWYIvSjmK89CBGjjGyQ== Message-ID: <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com> 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: multipart/alternative; boundary="_000_265A48F7933044159BF9CAA29FE12BAEvidyocom_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: [MMUSIC] RFC 5576 is da answah 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 Nov 2012 16:50:20 -0000 --_000_265A48F7933044159BF9CAA29FE12BAEvidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 20, 2012, at 7:50 PM, Bernard Aboba wrote: [BA] In the WebRTC context, IMHO there are a lot of unanswered questions in= RFC 5576. Hi, Bernard -- Yes, RFC 5576 wasn't a complete solution for interactive scenarios; it left= some pieces open that needed additional standardization work. Essentially= , 5576 the declarative part, but not the negotiation part. I followed it up with draft-lennox-mmusic-sdp-source-selection (still alive= , though quiescent) and draft-lennox-mmusic-sdp-max-sources (expired, but m= ore or less the same thing as draft-westerlund-mmusic-max-ssrc) which I thi= nk should cover all the issues you raise. At the time (the IETF Stockholm meeting in 2009) these drafts didn't get mu= ch interest, because the benefits of source multiplexing weren't commonly u= nderstood yet. I'm glad that's now changed. >From Section 5: Endpoints MUST NOT assume that only the sources mentioned in SDP will be present in an RTP session; additional sources, with previously unmentioned SSRC IDs, can be added at any time, and endpoints MUST be prepared to receive packets from these sources. (How endpoints handle such packets is not specified here; they SHOULD be handled in the same manner as packets from additional sources would be handled had the endpoint not received any a=3Dssrc: attributes at all.) [BA] While the advice above seems generally sensible, the meaning of "prepa= red to receive" isn't very clear. Implementations may differ in how they r= espond if they don't receive any a=3Dssrc attributes. For example, an imp= lementation might only be able to deal with a single undeclared source or p= erhaps not at all. So being "prepared to receive" isn't enough to be able = to deal with an RTP translator, for example. Yes, you'd need a way to explain what you're prepared to receive; max-ssrc = could handle this. Generally, if you're speaking to a legacy SIP endpoint, the only safe thing= to assume in the absence of ssrc or max-ssrc attributes is one source per = session; but since this actively contradicts the RTP spec, that couldn't ex= actly be made normative. >From Section 8: When used with the SDP Offer/Answer Model [RFC3264], SDP source- specific attributes describe only the sources that each party is willing to send (whether it is sending RTP data or RTCP report blocks). No mechanism is provided by which an answer can accept or reject individual sources within a media stream; if the set of sources in a media stream is unacceptable, the answerer's only option is to reject the media stream or the entire multimedia session. [BA] The advice above appears to only apply to an answerer that supports RF= C 5576. If it doesn't support RFC 5576, then it will presumably ignore the= a=3Dssrc lines, but may not reject the media stream (by setting the port t= o zero) or the entire session. In this case, it may not be clear to the O= fferer whether in fact it can send all the declared ssrc's or not. Contras= t this with the CLUE approach in which receiver gets to indicate what media= captures it would like to receive. The reason this is phrased as "no mechanism is provided" was to leave open = the possibility of defining such a mechanism in the future, not to preclude= the possibility of there ever being such a mechanism. My source-selection= draft would be one such mechanism; CLUE would be another. >From Section 9: Source descriptions are specified in this document such that RTP endpoints that are compliant with the RTP specification [RFC3550] will be able to decode the media streams they describe whether or not they support explicit source descriptions. However, some deployed RTP implementations may not actually support multiple media sources in a media stream. Media senders MAY wish to restrict themselves to a single source at a time unless they have some means of concluding that the receivers of the media stream support source multiplexing. [BA] The obvious way for an answerer to indicate support for RFC 5576 woul= d be to include a=3Dssrc lines in the answer. If the Answer doesn't inclu= de a=3Dssrc lines, should the Offerer conclude that only one source can be = sent? The above paragraph indicates this is optional. It's perfectly reasonable to support receiving multiple sources, but not ha= ve any sources you're interested in sending at the moment. This problem is= what max-ssrc is for. -- Jonathan Lennox jonathan@vidyo.com --_000_265A48F7933044159BF9CAA29FE12BAEvidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Nov 20, 2012, at 7:50 PM, Bernard Aboba wrote:

=
<= div class=3D"hmmessage">
[BA] In the WebRTC context, IMHO there are a lot of unanswered questions i= n RFC 5576. 
<= /blockquote>

Hi, Bernard --

Yes, RFC 5576 wasn't a complete solution for interactive scenarios; it le= ft some pieces open that needed additional standardization work.  Esse= ntially, 5576 the declarative part, but not the negotiation part.

I followed it up with draft-lennox-mmusic-sdp-source-select= ion (still alive, though quiescent) and draft-lennox-mmusic-sdp-max-so= urces (expired, but more or less the same thing as draft-westerlund-mm= usic-max-ssrc) which I think should cover all the issues you raise.

At the time (the IETF Stockholm meeting in 2009) these dr= afts didn't get much interest, because the benefits of source multiplexing = weren't commonly understood yet.  I'm glad that's now changed.


From Section 5:

   Endpoints MUST NOT assume that only th= e sources mentioned in SDP will
   be present in an RTP sessio= n; additional sources, with previously
   unmentioned SSRC IDs= , can be added at any time, and endpoints MUST be
   prepared = to receive packets from these sources.  (How endpoints
  = handle such packets is not specified here; they SHOULD be handled in
&n= bsp;  the same manner as packets from additional sources would be hand= led
   had the endpoint not received any a=3Dssrc: attributes = at all.)

[BA] While the advice above seems generally sensible, the m= eaning of "prepared to receive" isn't very clear.  Implementations may= differ in how they respond if they don't receive any a=3Dssrc attributes.&= nbsp;  For example, an implementation might only be able to deal with = a single undeclared source or perhaps not at all.  So being "prepared = to receive" isn't enough to be able to deal with an RTP translator, for exa= mple. 

Yes, you'd need a way to explain what = you're prepared to receive; max-ssrc could handle this.

Generally, if you're speaking to a legacy SIP endpoint, the only safe= thing to assume in the absence of ssrc or max-ssrc attributes is one sourc= e per session; but since this actively contradicts the RTP spec, that could= n't exactly be made normative. 


From Section 8:

   = When used with the SDP Offer/Answer Model [RFC3264], SDP source-
 &= nbsp; specific attributes describe only the sources that each party is
&= nbsp;  willing to send (whether it is sending RTP data or RTCP report<= br>   blocks).  No mechanism is provided by which an answer = can accept or
   reject individual sources within a media stre= am; if the set of
   sources in a media stream is unacceptable= , the answerer's only option
   is to reject the media stream = or the entire multimedia session.

[BA] The advice above appears to o= nly apply to an answerer that supports RFC 5576.  If it doesn't suppor= t RFC 5576, then it will presumably ignore the a=3Dssrc lines, but may not = reject the media stream (by setting the port to zero) or the entire session= .   In this case, it may not be clear to the Offerer whether in f= act it can send all the declared ssrc's or not.  Contrast this with th= e CLUE approach in which receiver gets to indicate what media captures it w= ould like to receive. 

The reason this is phr= ased as "no mechanism is provided" was to leave open the possibility of def= ining such a mechanism in the future, not to preclude the possibility of th= ere ever being such a mechanism.  My source-selection draft would be o= ne such mechanism; CLUE would be another.


From Section 9:

 &n= bsp; Source descriptions are specified in this document such that RTP
&n= bsp;  endpoints that are compliant with the RTP specification [RFC3550= ]
   will be able to decode the media streams they describe wh= ether or not
   they support explicit source descriptions.&nbs= p; However, some deployed
   RTP implementations may not actua= lly support multiple media sources
   in a media stream. = Media senders MAY wish to restrict themselves to
   a single = source at a time unless they have some means of concluding
   = that the receivers of the media stream support source multiplexing.

= [BA]  The obvious way for an answerer to indicate support for RFC 5576= would be to include a=3Dssrc lines in the answer.   If the Answe= r doesn't include a=3Dssrc lines, should the Offerer conclude that only one= source can be sent?   The above paragraph indicates this is opti= onal. 

It's perfectly reasonable to support receiv= ing multiple sources, but not have any sources you're interested in sending= at the moment.  This problem is what max-ssrc is for.

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_265A48F7933044159BF9CAA29FE12BAEvidyocom_-- From pkyzivat@alum.mit.edu Wed Nov 21 09:13: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 E479B21F85E8 for ; Wed, 21 Nov 2012 09:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q05K6wnbmP+R for ; Wed, 21 Nov 2012 09:13:49 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 33FD221F85B2 for ; Wed, 21 Nov 2012 09:13:49 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id SCEM1k0081ei1Bg55HDofj; Wed, 21 Nov 2012 17:13:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id SHDo1k0073ZTu2S3kHDo4p; Wed, 21 Nov 2012 17:13:48 +0000 Message-ID: <50AD0BCB.9090508@alum.mit.edu> Date: Wed, 21 Nov 2012 12:13:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com> In-Reply-To: <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] RFC 5576 is da answah 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 Nov 2012 17:13:50 -0000 On 11/21/12 11:50 AM, Jonathan Lennox wrote: >> [BA] While the advice above seems generally sensible, the meaning of >> "prepared to receive" isn't very clear. Implementations may differ in >> how they respond if they don't receive any a=ssrc attributes. For >> example, an implementation might only be able to deal with a single >> undeclared source or perhaps not at all. So being "prepared to >> receive" isn't enough to be able to deal with an RTP translator, for >> example. > > Yes, you'd need a way to explain what you're prepared to receive; > max-ssrc could handle this. It doesn't help me very much to know you are "prepared to receive" a bunch of media streams unless there is also a way to negotiate what they are for. You may be prepared to receive streams for purposes incompatible with the streams I am prepared to transmit. Using a=ssrc it is possible to negotiate things about each stream. For those that aren't negotiated that way, ISTM that there must be some other mechanism for negotiating semantics. This could be SDP signaling that indicated "all otherwise unspecified streams are ...", or the semantics could be conveyed via some other protocol (e.g. CLUE) or by prior agreement. Thanks, Paul From bernard_aboba@hotmail.com Wed Nov 21 19:30:05 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3FD21E8053 for ; Wed, 21 Nov 2012 19:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.798 X-Spam-Level: X-Spam-Status: No, score=-100.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPn+gCnTYaZd for ; Wed, 21 Nov 2012 19:30:04 -0800 (PST) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCDA21E8048 for ; Wed, 21 Nov 2012 19:30:04 -0800 (PST) Received: from BLU002-W15 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Nov 2012 19:30:03 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_3f9c674e-a2dc-4b19-a2be-7ff741481102_" X-Originating-IP: [64.122.121.2] From: Bernard Aboba To: Paul Kyzivat , "mmusic@ietf.org" Date: Wed, 21 Nov 2012 19:30:03 -0800 Importance: Normal In-Reply-To: <50AD0BCB.9090508@alum.mit.edu> References: , <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com>, <50AD0BCB.9090508@alum.mit.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2012 03:30:03.0978 (UTC) FILETIME=[A9346AA0:01CDC861] Subject: Re: [MMUSIC] RFC 5576 is da answah 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 Nov 2012 03:30:05 -0000 --_3f9c674e-a2dc-4b19-a2be-7ff741481102_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul Kyzivat said:=20 > It doesn't help me very much to know you are "prepared to receive" a=20 > bunch of media streams unless there is also a way to negotiate what they= =20 > are for. You may be prepared to receive streams for purposes=20 > incompatible with the streams I am prepared to transmit. >=20 > Using a=3Dssrc it is possible to negotiate things about each stream. For= =20 > those that aren't negotiated that way=2C ISTM that there must be some=20 > other mechanism for negotiating semantics. This could be SDP signaling=20 > that indicated "all otherwise unspecified streams are ..."=2C or the=20 > semantics could be conveyed via some other protocol (e.g. CLUE) or by=20 > prior agreement. [BA] If I read draft-lennox-mmusic-sdp-source-selection correctly=2C it is = possible to describe aspects of what the answerer is "prepared to receive" = but not details of what the Offerer is capable of sending. For example=2C = Section 4=2C includes the following offer/answer: Offer m=3Dvideo 49168 RTP/AVP 96=0A= a=3Drtpmap:96 H264/90000=0A= a=3Dssrc:12345 cname:user1@host1.example.com=0A= a=3Dssrc:67890 cname:user2@host2.example.com=0A= Answer=0A= m=3Dvideo 49170 RTP/AVP 96=0A= a=3Drtpmap:96 H264/90000=0A= a=3Dremote-ssrc:12345 recv:on=0A= a=3Dremote-ssrc:12345 imageattr:* [x=3D720=2Cy=3D576]=0A= a=3Dremote-ssrc:12345 framerate:15=0A= While the above exchange might work for a very basic scenario=2C it doesn't= seem capable of handling more complex cases. In the above Offer/Answer exc= hange=2C the Answerer doesn't know what resolutions or framerates are suppo= rted by the Offerer. For example=2C the Offerer might be capable of encodi= ng 16:9 or 9:16 aspect ratios at 15=2C 30 or 64 frames/second: 16:9: 1280x720=2C 960x540=2C 848x480=2C 640x360=2C 480x270=2C 424x240=2C= 320x180 9:16: 720x1280=2C 540x960=2C 480x848=2C 360x640=2C 270x480=2C = 240x424=2C 180x320 Yet in the above exchange=2C the Answerer asks for 720 by 576=2C leaving th= e Offer to guess what supported resolution is "closest".=20 Also=2C in the Offer=2C there is no indication of what the purpose of ssrc = 67890 is. For example=2C this could be for slides=2C and by rejecting it= =2C the Answerer will not be able to usefully participate in the conference= . So a content: attribute could come in handy. =20 IMHO=2C it became clear to me at IETF 85 that we are indeed straddling a st= eadily widening canyon as Harald has said=2C though I see the two cliffs be= ing CLUE on one side and RFC 5576 on the other. If RFC 5576 is to be "the a= nswah"=2C then MMUSIC needs to fill in the details of how the SDP negotiati= on works. Alternatively=2C if the negotiation is to occur outside SDP (as a= dvocated in CLUE)=2C then we need an explicit statement of where the bounda= ries lie. The middle path (pursuing neither with conviction) doesn't seem = viable to me. = --_3f9c674e-a2dc-4b19-a2be-7ff741481102_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul Kyzivat said: =3B

>=3B It doesn't help me very much to know you are "prepa= red to receive" a
>=3B bunch of media streams unless there is also a = way to negotiate what they
>=3B are for. You may be prepared to recei= ve streams for purposes
>=3B incompatible with the streams I am prepa= red to transmit.
>=3B
>=3B Using a=3Dssrc it is possible to nego= tiate things about each stream. For
>=3B those that aren't negotiated= that way=2C ISTM that there must be some
>=3B other mechanism for ne= gotiating semantics. This could be SDP signaling
>=3B that indicated = "all otherwise unspecified streams are ..."=2C or the
>=3B semantics = could be conveyed via some other protocol (e.g. CLUE) or by
>=3B prio= r agreement.

[BA] =3BIf =3BI read =3Bdraft-lennox-= mmusic-sdp-source-selection correctly=2C it is possible to describe aspects= of what the answerer is "prepared to receive" but not details of what the = Offerer is capable of sending.  =3BFor example=2C Section 4=2C includes= the following offer/answer:

 =3B  =3B  =3B &nb= sp=3BOffer

   m=3Dvi=
deo 49168 RTP/AVP 96=0A=
   a=3Drtpmap:96 H264/90000=0A=
   a=3Dssrc:12345 cname:user1@host1.example.com=0A=
   a=3Dssrc:67890 cname:user2@host2.example.com=0A=

   Answer
=0A= m=3Dvideo 49170 RTP/AVP 96=0A= a=3Drtpmap:96 H264/90000=0A= a=3Dremote-ssrc:12345 recv:on=0A= a=3Dremote-ssrc:12345 imageattr:* [x=3D720=2Cy=3D576]=0A= a=3Dremote-ssrc:12345 framerate:15=0A=


While the above exchange mig= ht work for a very basic scenario=2C it doesn't seem capable of handling mo= re complex cases. In the above Offer/Answer exchange=2C the Answerer doesn'= t know what resolutions or framerates are supported by the Offerer.  = =3BFor example=2C the Offerer might be capable of encoding 16:9 or 9:16 asp= ect ratios at 15=2C 30 or 64 frames/second:

16:9:  =3B1280x720=2C =3B960x540=2C =3B848x480=2C =3B 640x360=2C =3B 480x270=2C =3B424x240=2C=  =3B320x18= 0
 =3B =3B
9:16: 720x1280=2C =3B 540x960=2C =3B480x848=2C =3B 360x640=2C =3B270x480=2C =3B240x424=2C =3B180x320

Yet i= n the above exchange=2C the Answerer asks for 720 by 576=2C leaving the Off= er to guess what supported resolution is "closest". =3B

Also=2C in the Off= er=2C there is no indication of what the purpose of ssrc 67890 is.  =3B= For example=2C this could be for slides=2C and by rejecting it=2C the Answe= rer will not be able to usefully participate in the conference.  =3BSo = a content: attribute could come in handy.  =3B

IMHO=2C = it became clear to me at IETF 85 that we are indeed straddling a steadily w= idening canyon as Harald has said=2C though I see the two cliffs being CLUE= on one side and RFC 5576 on the other. If RFC 5576 is to be "the answah"= =2C then MMUSIC needs to fill in the details of how the SDP negotiation wor= ks. Alternatively=2C if the negotiation is to occur outside SDP (as advocat= ed in CLUE)=2C then we need an explicit statement of where the boundaries l= ie.  =3BThe middle path (pursuing neither with conviction) doesn't seem= viable to me. =3B
= --_3f9c674e-a2dc-4b19-a2be-7ff741481102_-- From christer.holmberg@ericsson.com Thu Nov 22 01:31: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 2509821F8839 for ; Thu, 22 Nov 2012 01:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjftgSNdAFHM for ; Thu, 22 Nov 2012 01:31:35 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BA88321F883A for ; Thu, 22 Nov 2012 01:31:34 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-4d-50adf0f5726e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 15.6D.06323.5F0FDA05; Thu, 22 Nov 2012 10:31:33 +0100 (CET) Received: from ESESSHC020.ericsson.se (153.88.183.78) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 22 Nov 2012 10:31:32 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 10:31:32 +0100 From: Christer Holmberg To: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 5576 is da answah Thread-Index: AQHNx4I7LDBSKk491E6gDy7Y6A3iQpf1l09w Date: Thu, 22 Nov 2012 09:31:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0420E9@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B0420E9ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7XD2sDDK6+k7fYv+Qys8XU5Y9Z HJg8HvecYfNYsuQnUwBTFJdNSmpOZllqkb5dAlfGnlOfmAuanCruN35hbmBcZ9XFyMkhIWAi cfrcBSYIW0ziwr31bCC2kMBJRonZ7VFdjFxA9k5GibXHF7FAJJYwSixcqdvFyMHBJmAh0f1P GyQsIhAiMWfFXrA5wgLaEjO+fmMFKRER0JE4My0XosRI4teMo8wgYRYBVYmtjSkgYV4Bb4lV 046yQwy3kvh2/C0ziM0pYC2xsucvI4jNCHTZ91NrwKYzC4hL3HoyH+piAYkle84zQ9iiEi8f /2OFsBUldp5tZ4aoz5eYf+MKG8QuQYmTM59APaIt0bJ4AvsERrFZSMbOQtIyC0kLRFxHYsHu T2wQtrbEsoWvmWHsMwceMyGLL2BkX8XInpuYmZNebr6JERhlB7f8NtjBuOm+2CFGaQ4WJXFe PdX9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY2RbV/doZK/dKI2NXnub/RWIi+zrnVpxc kruV/fqVbSVVe15l8C//zyQVHjI/d39LfYbW9CXZU1e7GiUIifWmMD68lrIohYn3/IPPfe2F 3VZp7RlM8gGS8y228yeLZ83ea7a0fdJfvwuqpfUTfhdP+jLltGx7xuXEPQxOhw7wx3IVdmpY C99UYinOSDTUYi4qTgQAHit6UIACAAA= Subject: Re: [MMUSIC] RFC 5576 is da answah 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 Nov 2012 09:31:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B0420E9ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From Section 8: > > When used with the SDP Offer/Answer Model [RFC3264], SDP source- > specific attributes describe only the sources that each party is > willing to send (whether it is sending RTP data or RTCP report > blocks). No mechanism is provided by which an answer can accept or > reject individual sources within a media stream; if the set of > sources in a media stream is unacceptable, the answerer's only option > is to reject the media stream or the entire multimedia session. > > [BA] The advice above appears to only apply to an answerer that supports = RFC 5576. If it doesn't support RFC 5576, then it > will presumably ignore the a=3Dssrc lines, but may not reject the media s= tream (by setting the port to zero) or the entire session. > In this case, it may not be clear to the Offerer whether in fact it can s= end all the declared ssrc's or not. Contrast this with the > CLUE approach in which receiver gets to indicate what media captures it w= ould like to receive. In CLUE we have a requirement to be able to communicate with "non-CLUE" and= "single stream" devices, so also there we may have to deal with the case w= here an endpoint doesn't support CLUE and/or RFC 5576. Also keep in mind that, eventhough max-ssrc allows you to specify the numbe= r of streams, it is currently not a mechanism to indicate WHICH streams are= accepted/rejected. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B0420E9ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

>From Section 8:
>
>   When used with the SD= P Offer/Answer Model [RFC3264], SDP source-
>   specific attributes d= escribe only the sources that each party is
>   willing to send (whet= her it is sending RTP data or RTCP report
>   blocks).  No mec= hanism is provided by which an answer can accept or
>   reject individual sou= rces within a media stream; if the set of
>   sources in a media st= ream is unacceptable, the answerer's only option
>   is to reject the medi= a stream or the entire multimedia session.
>
> [BA] The advice above appears to = only apply to an answerer that supports RFC 5576.  If it doesn't suppo= rt RFC 5576, then it

> will presumably ignore the a=3Dssrc lines, but may not reject the media = stream (by setting the port to zero) or the entire session.  

> In this case, it may not be clear to the Offerer whether in fact it can = send all the declared ssrc's or not.  Contrast this with the

> CLUE approach in which receiver gets to indicate what media captures it = would like to receive.

 <= /p>

In CLUE we have a require= ment to be able to communicate with “non-CLUE” and “singl= e stream” devices, so also there we may have to deal with the case wh= ere an endpoint doesn’t support CLUE and/or RFC 5576.

 <= /p>

Also keep in mind that, e= venthough max-ssrc allows you to specify the number of streams, it is curre= ntly not a mechanism to indicate WHICH streams are accepted/rejected.<= /o:p>

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

--_000_7594FB04B1934943A5C02806D1A2204B0420E9ESESSMB209ericsso_-- From harald@alvestrand.no Thu Nov 22 04:27: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 9FB3A21F8958 for ; Thu, 22 Nov 2012 04:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.134 X-Spam-Level: X-Spam-Status: No, score=-110.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbbwE4oipKpF for ; Thu, 22 Nov 2012 04:27:28 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 523A121F8915 for ; Thu, 22 Nov 2012 04:27:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 933A039E1AD; Thu, 22 Nov 2012 13:27:26 +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 BLBmne9wkSkq; Thu, 22 Nov 2012 13:27:25 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8158139E062; Thu, 22 Nov 2012 13:27:25 +0100 (CET) Message-ID: <50AE1A2C.4040201@alvestrand.no> Date: Thu, 22 Nov 2012 13:27:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Bernard Aboba References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no>, <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com>, <50A9BFD4.3000601@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080109050600030509060808" Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 12:27:29 -0000 This is a multi-part message in MIME format. --------------080109050600030509060808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/20/2012 08:12 PM, Bernard Aboba wrote: > > The M-line is problematic because it binds together multiple things: > > > > - A set of parameters for media transmission *in all directions* > (bound to payload type) > > [BA] RFC 3264 Section 5.1 makes it clear that the parameters need not > apply in all directions (though sendrecv is the default): agreed. What I find more problematic / irritating is that with parameters that apply to both directions of a sendrecv stream, there's no way to specify one set that applies A->B and another set that applies B->A. With sendonly / recvonly streams, this is not an issue; with parameters that apply only in one direction (such as crypto keys), it is also not an issue. But for some parameters, it is an issue. > > The list of media formats for each media stream conveys two pieces of > information, namely the set of formats (codecs and any parameters > associated with the codec, in the case of RTP) that the offerer is > capable of sending and/or receiving (depending on the direction > attributes), and, in the case of RTP, the RTP payload type numbers > used to identify those formats. If multiple formats are listed, it > means that the offerer is capable of making use of any of those > formats during the session. In other words, the answerer MAY change > formats in the middle of the session, making use of any of the > formats listed, without sending a new offer. For a sendonly stream, > the offer SHOULD indicate those formats the offerer is willing to > send for this stream. For a recvonly stream, the offer SHOULD > indicate those formats the offerer is willing to receive for this > stream. For a sendrecv stream, the offer SHOULD indicate those > codecs that the offerer is willing to send and receive with. > --------------080109050600030509060808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/20/2012 08:12 PM, Bernard Aboba wrote:
> The M-line is problematic because it binds together multiple things:
>
> - A set of parameters for media transmission *in all directions* (bound to payload type)

[BA] RFC 3264 Section 5.1 makes it clear that the parameters need not apply in all directions (though sendrecv is the default):

agreed. What I find more problematic / irritating is that with parameters that apply to both directions of a sendrecv stream, there's no way to specify one set that applies A->B and another set that applies  B->A.
With sendonly / recvonly streams, this is not an issue; with parameters that apply only in one direction (such as crypto keys), it is also not an issue. But for some parameters, it is an issue.


   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.  If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.  For a sendonly stream,
   the offer SHOULD indicate those formats the offerer is willing to
   send for this stream.  For a recvonly stream, the offer SHOULD
   indicate those formats the offerer is willing to receive for this
   stream.  For a sendrecv stream, the offer SHOULD indicate those
   codecs that the offerer is willing to send and receive with.


--------------080109050600030509060808-- From christer.holmberg@ericsson.com Thu Nov 22 04:35:31 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 AD59E21F8974 for ; Thu, 22 Nov 2012 04:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7MOdSC7kpae for ; Thu, 22 Nov 2012 04:35:30 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 396C321F896F for ; Thu, 22 Nov 2012 04:35:30 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-ae-50ae1c101833 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 93.65.11564.01C1EA05; Thu, 22 Nov 2012 13:35:28 +0100 (CET) Received: from ESESSHC010.ericsson.se (153.88.183.48) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 22 Nov 2012 13:35:27 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 13:35:26 +0100 From: Christer Holmberg To: Harald Alvestrand , Bernard Aboba Thread-Topic: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) Thread-Index: AQHNxhSSFrVLd/9YXUaLOlsJI1Ryp5fzCQOAgAKzgwCAABIuUA== Date: Thu, 22 Nov 2012 12:35:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04227A@ESESSMB209.ericsson.se> References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no>, <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com>, <50A9BFD4.3000601@alvestrand.no> <50AE1A2C.4040201@alvestrand.no> In-Reply-To: <50AE1A2C.4040201@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja6AzLoAg+sr1S32L7nMbHGsr4vN YuryxywOzB5XJlxh9Xjcc4bNY8mSn0wBzFFcNimpOZllqUX6dglcGbc7XjAVXGCvuLHwEVsD YxtbFyMnh4SAicTvT9uZIWwxiQv31gPFuTiEBE4ySkyZtY4dwtnJKDHn3GMoZwmjxJlVs1m6 GDk42AQsJLr/aYN0iwhEStx4epQZJMwsoC5xdXEQSFhYIFyi4U4nM0RJhMS0ZbuZIGwniaOt vewg5SwCqhJrl+iChHkFvCX6VrewQmxqZ5L4+OUl2EhOAV2J+z2cIDWMQHd+P7UGbAyzgLjE rSfzmSDuF5BYsuc81C+iEi8f/2OFsBUldp5tZ4ao15O4MXUKG4StLbFs4WtmiL2CEidnPmEB sYWA4i2LJ7BPYJSYhWTFLCTts5C0z0LSvoCRZRUje25iZk56ueEmRmCUHdzyW3cH46lzIocY pTlYlMR5uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLglGpglOReF/i5ulbJS6OiYrt6W+rM T5k3XNzXXHbri64ofyb8ZYu7mdIzu8cingLs218m7G749jPQvj73hMx6Dv1+qSevr82x4Px9 +8Sh3JeisYwiT14VsG/Ym99WvVP5QUZBFPdNs+tnGF+k84bIV7dObC9mtwn9YfbtnEGKy5KH XjJsR2XFf9YosRRnJBpqMRcVJwIABmloeYACAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs) 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 Nov 2012 12:35:31 -0000 Hi, >> The M-line is problematic because it binds together multiple things: >>=20 >> - A set of parameters for media transmission *in all directions* (bound = to payload type) > >[BA] RFC 3264 Section 5.1 makes it clear that the parameters need not appl= y in all directions (though sendrecv is the default):=20 > >agreed. What I find more problematic / irritating is that with parameters = that apply to both directions of a sendrecv stream, there's no way to speci= fy one set that applies A->B and another set that applies=A0 B->A. >With sendonly / recvonly streams, this is not an issue; with parameters th= at apply only in one direction (such as crypto keys), it is also not an iss= ue. But for some parameters, it is an issue. The root to these problems is that fact that, at one point many earth spins= ago, the community made a decision that with SIP/SDP you only need to indi= cate your receiving capabilities... Regards, Christer From harald@alvestrand.no Thu Nov 22 04:41: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 DC76621F8980 for ; Thu, 22 Nov 2012 04:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.255 X-Spam-Level: X-Spam-Status: No, score=-109.255 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0NySdifxl9v for ; Thu, 22 Nov 2012 04:41:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA83821F891E for ; Thu, 22 Nov 2012 04:41:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5257639E1AD for ; Thu, 22 Nov 2012 13:41:30 +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 7Zaww9dn8LwB for ; Thu, 22 Nov 2012 13:41:26 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7C47A39E062 for ; Thu, 22 Nov 2012 13:41:26 +0100 (CET) Message-ID: <50AE1D75.1070100@alvestrand.no> Date: Thu, 22 Nov 2012 13:41:25 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: , <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com>, <50AD0BCB.9090508@alum.mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060105080103020600080801" Subject: Re: [MMUSIC] RFC 5576 is da answah 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 Nov 2012 12:41:37 -0000 This is a multi-part message in MIME format. --------------060105080103020600080801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/22/2012 04:30 AM, Bernard Aboba wrote: > Paul Kyzivat said: > > > It doesn't help me very much to know you are "prepared to receive" a > > bunch of media streams unless there is also a way to negotiate what > they > > are for. You may be prepared to receive streams for purposes > > incompatible with the streams I am prepared to transmit. > > > > Using a=ssrc it is possible to negotiate things about each stream. For > > those that aren't negotiated that way, ISTM that there must be some > > other mechanism for negotiating semantics. This could be SDP signaling > > that indicated "all otherwise unspecified streams are ...", or the > > semantics could be conveyed via some other protocol (e.g. CLUE) or by > > prior agreement. > > [BA] If I read draft-lennox-mmusic-sdp-source-selection correctly, it > is possible to describe aspects of what the answerer is "prepared to > receive" but not details of what the Offerer is capable of sending. > For example, Section 4, includes the following offer/answer: > > Offer > > m=video 49168 RTP/AVP 96 > a=rtpmap:96 H264/90000 > a=ssrc:12345 cname:user1@host1.example.com > a=ssrc:67890 cname:user2@host2.example.com > > Answer > m=video 49170 RTP/AVP 96 > a=rtpmap:96 H264/90000 > a=remote-ssrc:12345 recv:on > a=remote-ssrc:12345 imageattr:* [x=720,y=576] > a=remote-ssrc:12345 framerate:15 > While the above exchange might work for a very basic scenario, it > doesn't seem capable of handling more complex cases. In the above > Offer/Answer exchange, the Answerer doesn't know what resolutions or > framerates are supported by the Offerer. For example, the Offerer > might be capable of encoding 16:9 or 9:16 aspect ratios at 15, 30 or > 64 frames/second: > > 16:9: 1280x720, 960x540, 848x480, 640x360, 480x270, 424x240, 320x180 > 9:16: 720x1280, 540x960, 480x848, 360x640, 270x480, 240x424, 180x320 > > Yet in the above exchange, the Answerer asks for 720 by 576, leaving > the Offer to guess what supported resolution is "closest". That's a misreading of RRC 6236. The answer asks for *exactly* 720 by 576. The offerer has to either send in that resolution or renegotiate. If a range was acceptable, the answerer should have indicated that ([x=700:800,y=500:600]). > > Also, in the Offer, there is no indication of what the purpose of ssrc > 67890 is. For example, this could be for slides, and by rejecting it, > the Answerer will not be able to usefully participate in the > conference. So a content: attribute could come in handy. > > IMHO, it became clear to me at IETF 85 that we are indeed straddling a > steadily widening canyon as Harald has said, though I see the two > cliffs being CLUE on one side and RFC 5576 on the other. Are you seeing the canyon as being in-SDP signalling vs out-of-SDP signalling? If CLUE goes with multiple streams per m-line, and in-SDP signalling, it needs RFC 5576. If out-of-band signalling needs to refer to SSRCs, we need unique identifiers (SRCNAME or MSID) that out-of-band signalling can use to refer to the flows. Those will likely use RFC 5576 too. > If RFC 5576 is to be "the answah", then MMUSIC needs to fill in the > details of how the SDP negotiation works. Alternatively, if the > negotiation is to occur outside SDP (as advocated in CLUE), then we > need an explicit statement of where the boundaries lie. The middle > path (pursuing neither with conviction) doesn't seem viable to me. Our ability to converge on a boundary definition with conviction seems limited. So since we're presently implementing, it seems that our options are limited to what can be achieved without such convergence. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------060105080103020600080801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/22/2012 04:30 AM, Bernard Aboba wrote:
Paul Kyzivat said: 

> It doesn't help me very much to know you are "prepared to receive" a
> bunch of media streams unless there is also a way to negotiate what they
> are for. You may be prepared to receive streams for purposes
> incompatible with the streams I am prepared to transmit.
>
> Using a=ssrc it is possible to negotiate things about each stream. For
> those that aren't negotiated that way, ISTM that there must be some
> other mechanism for negotiating semantics. This could be SDP signaling
> that indicated "all otherwise unspecified streams are ...", or the
> semantics could be conveyed via some other protocol (e.g. CLUE) or by
> prior agreement.

[BA] If I read draft-lennox-mmusic-sdp-source-selection correctly, it is possible to describe aspects of what the answerer is "prepared to receive" but not details of what the Offerer is capable of sending.  For example, Section 4, includes the following offer/answer:

       Offer

   m=video 49168 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=ssrc:12345 cname:user1@host1.example.com
   a=ssrc:67890 cname:user2@host2.example.com


   Answer
   m=video 49170 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=remote-ssrc:12345 recv:on
   a=remote-ssrc:12345 imageattr:* [x=720,y=576]
   a=remote-ssrc:12345 framerate:15


          

        

        
While
          the above exchange might work for a very basic scenario, it
          doesn't seem capable of handling more complex cases. In the
          above Offer/Answer exchange, the Answerer doesn't know what
          resolutions or framerates are supported by the Offerer.  For
          example, the Offerer might be capable of encoding 16:9 or 9:16
          aspect ratios at 15, 30 or 64 frames/second:

        


        

        

          
16:9:  1280x720, 960x540, 848x480,  640x360,  480x270, 424x240, 320x180 

          
  

          
9:16:
              720x1280,  540x960, 480x848,  360x640, 270x480, 240x424, 180x320

        

        


          

        
Yet in the
            above exchange, the Answerer asks for 720 by 576, leaving
            the Offer to guess what supported resolution is "closest". 

          

      

    

    That's a misreading of RRC 6236. The answer asks for *exactly* 720
    by 576. The offerer has to either send in that resolution or
    renegotiate.

    If a range was acceptable, the answerer should have indicated that
    ([x=700:800,y=500:600]).

    

      

        


          

        
Also, in
            the Offer, there is no indication of what the purpose of
            ssrc 67890 is.  For example, this could be for slides, and
            by rejecting it, the Answerer will not be able to usefully
            participate in the conference.  So a content: attribute
            could come in handy.  

        


          

        
IMHO, it became clear to me at IETF 85 that we are
            indeed straddling a steadily widening canyon as Harald has
            said, though I see the two cliffs being CLUE on one side and
            RFC 5576 on the other.

      

    

    Are you seeing the canyon as being in-SDP signalling vs out-of-SDP
    signalling?

    If CLUE goes with multiple streams per m-line, and in-SDP
    signalling, it needs RFC 5576.

    If out-of-band signalling needs to refer to SSRCs, we need unique
    identifiers (SRCNAME or MSID) that out-of-band signalling can use to
    refer to the flows. Those will likely use RFC 5576 too.

    

    

      

        
 If RFC 5576 is to be "the answah", then MMUSIC needs
            to fill in the details of how the SDP negotiation works.
            Alternatively, if the negotiation is to occur outside SDP
            (as advocated in CLUE), then we need an explicit statement
            of where the boundaries lie.  The middle path (pursuing
            neither with conviction) doesn't seem viable to me. 

          

      

    

    Our ability to converge on a boundary definition with conviction
    seems limited. So since we're presently implementing, it seems that
    our options are limited to what can be achieved without such
    convergence.

    

      
 

      

      

      

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


    

    

  


--------------060105080103020600080801--

From stefan.lk.hakansson@ericsson.com  Thu Nov 22 05:39:18 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 4552721F896E for ; Thu, 22 Nov 2012 05:39:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level: 
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaAQAXGdW6Nk for ; Thu, 22 Nov 2012 05:39:17 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8948021F8966 for ; Thu, 22 Nov 2012 05:39:17 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-23-50ae2b0461bf
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D6.9C.26143.40B2EA05; Thu, 22 Nov 2012 14:39:16 +0100 (CET)
Received: from [150.132.142.225] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 22 Nov 2012 14:39:16 +0100
Message-ID: <50AE2B02.2020900@ericsson.com>
Date: Thu, 22 Nov 2012 14:39:14 +0100
From: Stefan Hakansson LK 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50AE2838.9000807@ericsson.com>
In-Reply-To: <50AE2838.9000807@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvjS6L9roAg20LlCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEfbFrMWHGavePThIXMD42zWLkZODgkBE4nDy2ezQ9hiEhfu rWfrYuTiEBI4ySjx+N4bsCIhgbWMEuvbtEBsXgFtiasLdzCD2CwCqhJ3NywAq2ETsJFY2z2F CcQWFQiTWLPnEBNEvaDEyZlPWEBsEQFhiRlv/7KB2MICSRKrjs1igpivLbFp7TGwOKeAjsS7 lYfAZjIL2EpcmHOdBcKWl9j+dg4zRL2uxLvX91gnMArMQrJiFpKWWUhaFjAyr2Jkz03MzEkv N9rECAyzg1t+q+5gvHNO5BCjNAeLkjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY JW/zux+POfS4cIZqZKh1Rc7XLt3NKt8n3nl7UP6EYl0CmwKzlEAi29970Yk7Tgb6/xOLW+Z+ dNFd3Z7uMJO7PxalXJ/cu6uKZVv/B8fAOY5+Go8UgzJj/P3bRTrY/KwqQrLf7nqnviggP2Ct y3wjY+dop/Nftrm93yQSartb/ppOvqrMFT0lluKMREMt5qLiRACfFYtXAQIAAA==
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 13:39:18 -0000

On 11/20/2012 15:56, Adam Roach wrote:
>
>
>    +---------+   +------------+   +---------+
>    | Web App |---| SIP Server |---|         |
>    +---------+   +------------+   |         | +-------------+
>         |                         | PSTN GW |--| Fax Machine |
>    +---------+      media         |         | +-------------+
>    | Browser |--------------------|         |
>    +---------+                    +---------+

For cases when one client is not a proper fax machine, is not the usual 
thing that is done that the facsimile is converted to/from TIFF, JPEG, 
PDF or similar somewhere between that client and the fax machine? (And 
often sent as a mail attachment)

If so, all tools are already available (e.g. File API if you want to 
store/access on the local file system, XHR or WebSockets - or even the 
rtcweb data channel for transport) to build a client that can handle 
fax. (I am probably missing something)

Stefan


From albrecht.schwarz@alcatel-lucent.com  Thu Nov 22 06:13: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 8A51321F895E for ; Thu, 22 Nov 2012 06:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.098
X-Spam-Level: 
X-Spam-Status: No, score=-9.098 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzJu8RG9y1hN for ; Thu, 22 Nov 2012 06:13:34 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE421F847F for ; Thu, 22 Nov 2012 06:13:34 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAME05qZ007001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 22 Nov 2012 15:00:12 +0100
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 22 Nov 2012 14:59:43 +0100
From: "Schwarz, Albrecht (Albrecht)" 
To: "mmusic@ietf.org" 
Date: Thu, 22 Nov 2012 14:59:42 +0100
Thread-Topic: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
Thread-Index: Ac3Itsv14bj2MiQoQIivv6tR4UFhowAAN0Ng
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9623DF0C4376@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <50AE2838.9000807@ericsson.com> <50AE2B02.2020900@ericsson.com>
In-Reply-To: <50AE2B02.2020900@ericsson.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 14:13:35 -0000

Looks like that your are describing T.37 FoIP behaviour, whereas Adam did p=
oint on T.38 FoIP.

WebRTC should firstly agree
a) whether fax is part of this conversational realtime multimedia service a=
t all,
and if,
b) which transport mode via IP.

To a): support of F.185 (Internet fax) Yes/No
To b):=20
	b.1) T.37 FoIP store-and-forward already sufficient Yes/No
	b.2) T.38 FoIP realtime required Yes/No ((perhaps T.38 over RTP/UDP or UDP=
TL/UDP))
	b.3) or any alternative to T.38 FoIP realtime Yes/No

NOTE: T.38 would specify the behaviour of the=20
1) PSTN gateway (as "T.38 gateway", which is always a PSTN-to-IP gateway) a=
nd
2) Browser (as "T.38 IAD" (Internet aware fax device))
in below illustration.

-Albrecht

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Stefan Hakansson LK
Sent: Donnerstag, 22. November 2012 14:39
To: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prior=
itization of codecs))

On 11/20/2012 15:56, Adam Roach wrote:
>
>
>    +---------+   +------------+   +---------+
>    | Web App |---| SIP Server |---|         |
>    +---------+   +------------+   |         | +-------------+
>         |                         | PSTN GW |--| Fax Machine |
>    +---------+      media         |         | +-------------+
>    | Browser |--------------------|         |
>    +---------+                    +---------+

For cases when one client is not a proper fax machine, is not the usual=20
thing that is done that the facsimile is converted to/from TIFF, JPEG,=20
PDF or similar somewhere between that client and the fax machine? (And=20
often sent as a mail attachment)

If so, all tools are already available (e.g. File API if you want to=20
store/access on the local file system, XHR or WebSockets - or even the=20
rtcweb data channel for transport) to build a client that can handle=20
fax. (I am probably missing something)

Stefan

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

From christer.holmberg@ericsson.com  Thu Nov 22 11:49: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 4661321F8A2B for ; Thu, 22 Nov 2012 11:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.013
X-Spam-Level: 
X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.236,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZyTYE4jaf2z for ; Thu, 22 Nov 2012 11:49:55 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3949E21F867D for ; Thu, 22 Nov 2012 11:49:54 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-fe-50ae81e1cabd
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.81.11564.1E18EA05; Thu, 22 Nov 2012 20:49:53 +0100 (CET)
Received: from ESESSHC015.ericsson.se (153.88.183.63) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 22 Nov 2012 20:49:53 +0100
Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 20:49:52 +0100
From: Christer Holmberg 
To: 'Harald Alvestrand' , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] RFC 5576 is da answah
Thread-Index: AQHNx4I7LDBSKk491E6gDy7Y6A3iQpf0cMeAgAAGk4CAAKwvgIAAmg2AgABnQNA=
Date: Thu, 22 Nov 2012 19:49:51 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B0428C4@ESESSMB209.ericsson.se>
References: , <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com>, <50AD0BCB.9090508@alum.mit.edu>  <50AE1D75.1070100@alvestrand.no>
In-Reply-To: <50AE1D75.1070100@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7DxnUBBo/fG1sc6+tis5i6/DGL A5PHlQlXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJVx/n9hwU/uin+r1rI2MO7i7GLk5JAQMJHY ffsTO4QtJnHh3nq2LkYuDiGBk4wSu58tZoVwdjJKtB95yAThLGGU6G9ZAtTCwcEmYCHR/U8b pFtEIBTI/MsMYgsLaEvM+PqNFaREREBH4sy0XIgSP4mfbd9ZQMIsAqoSB44wgoR5Bbwlnk/e AjX9CaPE9ZtvmUASnAK6Ep9P72ABsRmBjvt+ag1YnFlAXOLWk/lMEEcLSCzZc54ZwhaVePn4 HyuErSix82w7M0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCdh8IaB4y+IJ7BMYxWchWTELSfss JO2zkLQvYGRZxciem5iZk15uuIkRGDkHt/zW3cF46pzIIUZpDhYlcV6upP3+QgLpiSWp2amp BalF8UWlOanFhxiZODilGhitgvXS2ZjqjyUfEbw4P7Cs4ucFZ7nz3eJTvHtFWsu3n/FffnnL Uek5HfquBlcZlwU09PLsW+JzaZpyxcdTFw/eVVXb+zc3nFVE9sKJju2tQv7VwVkJO4+pfuXX /SQY/WtDp+RGn7crDau80hy7FTy2ZsjXJxdLhMg7TpH7O31FV9HXe2LajkosxRmJhlrMRcWJ AOsx96xqAgAA
Subject: Re: [MMUSIC] RFC 5576 is da answah
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 Nov 2012 19:49:56 -0000

Hi,

> Are you seeing the canyon as being in-SDP signalling vs out-of-SDP signal=
ling?
> If CLUE goes with multiple streams per m-line, and in-SDP signalling, it =
needs RFC 5576.
> If out-of-band signalling needs to refer to SSRCs, we need unique identif=
iers (SRCNAME or MSID) that out-of-band=20
> signalling can use to refer to the flows. Those will likely use RFC 5576 =
too.
>
> If RFC 5576 is to be "the answah", then MMUSIC needs to fill in the detai=
ls of how the SDP negotiation works.=20

Agree. The same issues apply for both CLUE and RTCWEB, so it needs to be de=
scribed on a general level.

> Alternatively, if the negotiation is to occur outside SDP (as advocated i=
n CLUE), then we need an explicit statement of where=20
> the boundaries lie.  The middle path (pursuing neither with conviction) d=
oesn't seem viable to me.=20

CLUE has not yet decided what goes in SDP, and what goes into the CLUE chan=
nel.

My suggestion has been that "CLUE application specific data" (e.g. spatial =
relationship information) goes into the CLUE channel, while "transport data=
" (especially data which might be needed by intermediaries etc) goes into S=
DP.=20

Now, there ARE some gray areas, where it can be discussed whether specific =
data is "CLUE app" or "transport". BUT, I would be concerned about CLUE put=
ting data in the CLUE channel as a workaround, simply because it doesn't "f=
it" into SDP - even if the data as such would belong SDP.

Regards,

Christer

=09



From christer.holmberg@ericsson.com  Thu Nov 22 11:59: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 94D0421F8566 for ; Thu, 22 Nov 2012 11:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.872
X-Spam-Level: 
X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zJui2IuQM6k for ; Thu, 22 Nov 2012 11:59:25 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A988E21F89F3 for ; Thu, 22 Nov 2012 11:59:24 -0800 (PST)
X-AuditID: c1b4fb30-b7f936d0000018b3-b1-50ae841b31c2
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EB.AA.06323.B148EA05; Thu, 22 Nov 2012 20:59:23 +0100 (CET)
Received: from ESESSHC015.ericsson.se (153.88.183.63) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 22 Nov 2012 20:59:22 +0100
Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 20:59:22 +0100
From: Christer Holmberg 
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= ,  "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
Thread-Index: AQHNyLbCPmJ2Xb7DRUqt9+xtxs1di5f2RUwg
Date: Thu, 22 Nov 2012 19:59:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B0428EE@ESESSMB209.ericsson.se>
References: <50AE2838.9000807@ericsson.com> <50AE2B02.2020900@ericsson.com>
In-Reply-To: <50AE2B02.2020900@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvja50y7oAg7WHRSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEnfAwumcVRceHqEqYHxJWsXIyeHhICJxKtfj5ghbDGJC/fW s3UxcnEICZxklJi9sZEJwtnJKHH+0hUWCGcJo8SNM2/Zuxg5ONgELCS6/2mDdIsIlEic6Z3D DmILCyRJTHwLMVVEIFli+8XtbBC2kcSPJVeYQGwWAVWJqROOgNm8At4S07/MA+sVArKffz3C CjKeU0BH4ui6epAwI9Bx30+tAStnFhCXuPVkPhPE0QISS/ach3pAVOLl439QjylK7DzbzgxR rydxY+oUNghbW2LZwtfMEGsFJU7OfMICsVZbomXxBPYJjOKzkKyYhaR9FpL2WUjaFzCyrGJk z03MzEkvN9/ECIySg1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU4kOM TBycUg2MC76Z7a9br7v+t0eskvfuiRURNyS2dXx02e+3tLe4zMKn6oVwoV33HNEHTuy7bupU rlz+JonfPKoq55iq+NsOptlLtpw5NVP+i6d7eBlLj19M85o121k25i88xFve67a84WlHrklw xqHj0n4TtgjKVjz49m17HiMru4UxW9CjP+WlEy5GPtiixFKckWioxVxUnAgARHcdlWACAAA=
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 19:59:25 -0000

Hi,=20

>>    +---------+   +------------+   +---------+
>>    | Web App |---| SIP Server |---|         |
>>    +---------+   +------------+   |         | +-------------+
>>         |                         | PSTN GW |--| Fax Machine |
>>    +---------+      media         |         | +-------------+
>>    | Browser |--------------------|         |
>>    +---------+                    +---------+
>
> For cases when one client is not a proper fax machine, is not the usual t=
hing that is done that the=20
> facsimile is converted to/from TIFF, JPEG, PDF or similar somewhere betwe=
en that client and the fax machine? (And often sent as a mail attachment)

I don't think you can make that assumption. Note that I am not talking spec=
ifically about browsers, but IP clients in general.

Now, there is ongoing work (draft-hanes-dispatch-fax-capability) in definin=
g a media feature tag, which clients can use to indicate their fax capabili=
ties. Maybe "picture" should be addded as an option...

Regards,

Christer=

From bernard_aboba@hotmail.com  Thu Nov 22 14:17: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 24D2521F889D for ; Thu, 22 Nov 2012 14:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level: 
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXzxt0ZPCPo3 for ; Thu, 22 Nov 2012 14:17:19 -0800 (PST)
Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1424721F868A for ; Thu, 22 Nov 2012 14:17:19 -0800 (PST)
Received: from BLU002-W56 ([65.55.116.73]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 22 Nov 2012 14:17:18 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_d7f653f9-915f-48fa-8050-547343466fb2_"
X-Originating-IP: [24.16.96.166]
From: Bernard Aboba 
To: Christer Holmberg , "mmusic@ietf.org" 
Date: Thu, 22 Nov 2012 14:17:18 -0800
Importance: Normal
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0428C4@ESESSMB209.ericsson.se>
References: , , <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com>, , <50AD0BCB.9090508@alum.mit.edu>, , <50AE1D75.1070100@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B0428C4@ESESSMB209.ericsson.se>
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Nov 2012 22:17:18.0605 (UTC) FILETIME=[22957BD0:01CDC8FF]
Subject: Re: [MMUSIC] RFC 5576 is da answah
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 Nov 2012 22:17:20 -0000

--_d7f653f9-915f-48fa-8050-547343466fb2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Christer said:

"My suggestion has been that "CLUE application specific data" (e.g. spatial=
 relationship information) goes into the CLUE channel=2C while "transport d=
ata" (especially data which might be needed by intermediaries etc) goes int=
o SDP. "

[BA]  That seems like a reasonable guideline to me.  Looking at draft-ietf-=
clue-framework Section 6.1.1=2C many of the attributes other than the "spat=
ial relationship" ones (such as Point of Capture=2C Line of Capture and Are=
a of Capture) do seem like they can be handled in SDP.  For example=2C  the=
 max-send-ssrc:  and max-recv-ssrc: parameters defined in draft-westerlund-=
mmusic-max-ssrc seem to communicate similar information to Max Capture Enco=
dings=2C and Encoding Group might be taken care of via the a=3Dssrc-group c=
onstruct in RFC 5576.   Height=2C Width and Framerate also can be handled i=
n SDP (though IMHO the negotiation mechanism in draft-lennox-mmusic-sdp-sou=
rce-selection needs work).=20

=0A=
    =0A=
    [Harald]  The answer asks for *exactly* 720=0A=
    by 576. The offerer has to either send in that resolution or=0A=
    renegotiate.
=0A=
    If a range was acceptable=2C the answerer should have indicated that=0A=
    ([x=3D700:800=2Cy=3D500:600]).

[BA] Yes=2C but it seems clumsy for the receiver to indicate its preference=
s without information on what the sender supports.  In draft-lennox-mmusic-=
sdp-source-selection=2C imageattr information only seems to be supported in=
 the answer=2C whereas in RFC 6236=2C the Offer may include both send and r=
eceive information as described in Section 6.1:
a=3Dimageattr:PT send attr-list recv attr-listIncluding both send and recei=
ve information in the Offer seems more likely to enable the negotiation to =
conclude in a single Offer/Answer exchange.
For example=2C the Offer can describe what can be sent by including an a=3D=
max-send-ssrc: line as well as information on the individual a=3Dssrc: line=
s (e.g.=2C  imageattr:=2C framerate:=2C content:).  In addition=2C the Offe=
r can communicate about what can be received via an a=3Dmax-recv-ssrc: line=
 (and perhaps a=3Dremote-ssrc: lines with some imageattr: and framerate: su=
ggestions).  Then the Answer can include a=3Dremote-ssrc lines correspondin=
g to  the sources described in the Offer=2C as well as a=3Dssrc: lines desc=
ribing what the Offer can send (which should be compatible with the receive=
 information in the Offer).  This may allow the negotiation to be concluded=
 in a single Offer/Answer exchange. =20

[Harald]  If CLUE goes with multiple streams per m-line=2C and in-SDP=0A=
    signalling=2C it needs RFC 5576. If out-of-band signalling needs to ref=
er to SSRCs=2C we need unique=0A=
    identifiers (SRCNAME or MSID) that out-of-band signalling can use to=0A=
    refer to the flows. Those will likely use RFC 5576 too.

[BA] Christer has suggested that CLUE out-of-band signalling should only be=
 required to communicate parameters (such as spatial relationships) that ar=
e unique to CLUE.   This seems reasonable to me=2C but today there is consi=
derable overlap in the parameters described in =0A=
draft-ietf-clue-framework and SDP documents such as RFC 5576=2C 6236=2C =0A=
draft-lennox-mmusic-sdp-source-selection and =0A=
draft-westerlund-mmusic-max-ssrc. =20
=0A=
   =20
=0A=
    =0A=
      =0A=
         If RFC 5576 is to be "the answah"=2C then MMUSIC needs=0A=
            to fill in the details of how the SDP negotiation works.=0A=
            Alternatively=2C if the negotiation is to occur outside SDP=0A=
            (as advocated in CLUE)=2C then we need an explicit statement=0A=
            of where the boundaries lie.  The middle path (pursuing=0A=
            neither with conviction) doesn't seem viable to me.=20

=0A=
          =0A=
      =0A=
    =0A=
    [Harald] Our ability to converge on a boundary definition with convicti=
on=0A=
    seems limited. So since we're presently implementing=2C it seems that=
=0A=
    our options are limited to what can be achieved without such=0A=
    convergence.

[BA] We can at least describe how the source negotiation is supposed to wor=
k in the absence of CLUE.  That exercise would help in understand the limit=
s of what can be accomplished in a single O/A exchange. =20
 		 	   		  =

--_d7f653f9-915f-48fa-8050-547343466fb2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Christer said:

"My sugges=
tion has been that "CLUE application specific data" (e.g. spatial relations=
hip information) goes into the CLUE channel=2C while "transport data" (espe=
cially data which might be needed by intermediaries etc) goes into SDP. "

[BA] =3B That seems like a reasonable guideline to me. =
=3B Looking at draft-ietf-clue-framework Section 6.1.1=2C many of the attri=
butes other than the "spatial relationship" ones (such as Point of Capture=
=2C Line of Capture and Area of Capture) do seem like they can be handled i=
n SDP. =3B For example=2C =3B the max-send-ssrc: =3B and max-re=
cv-ssrc: parameters defined in draft-westerlund-mmusic-max-ssrc seem to com=
municate similar information to Max Capture Encodings=2C and Encoding Group=
 might be taken care of via the a=3Dssrc-group construct in RFC 5576. =
=3B =3B Height=2C Width and Framerate also can be handled in SDP (thoug=
h IMHO the negotiation mechanism in draft-lennox-mmusic-sdp-source-selectio=
n needs work). 

=0A=
    =0A=
    [Harald] =3B The answer asks for *exactly* 720=0A=
    by 576. The offerer has to either send in that resolution or=0A=
    renegotiate.
=0A=
    If a range was acceptable=2C the answerer should have indicated that=0A=
    ([x=3D700:800=2Cy=3D500:600]).

[BA] Yes=2C but it seems clumsy f=
or the receiver to indicate its preferences without information on what the=
 sender supports. =3B In draft-lennox-mmusic-sdp-source-selection=2C im=
ageattr information only seems to be supported in the answer=2C whereas in =
RFC 6236=2C the Offer may include both send and receive information as desc=
ribed in Section 6.1:
a=3Dimageattr:PT send attr-list recv attr-lis=
t
Including both send and receive information in the Offer seems more =
likely to enable the negotiation to conclude in a single Offer/Answer excha=
nge.
For example=2C the Offer can describe what can be sent by including=
 an a=3Dmax-send-ssrc: line as well as information on the individual a=3Dss=
rc: lines (e.g.=2C =3B imageattr:=2C framerate:=2C content:). =3B I=
n addition=2C the Offer can communicate about what can be received via an a=
=3Dmax-recv-ssrc: line (and perhaps a=3Dremote-ssrc: lines with some imagea=
ttr: and framerate: suggestions). =3B Then the Answer can include a=3Dr=
emote-ssrc lines corresponding to =3B the sources described in the Offe=
r=2C as well as a=3Dssrc: lines describing what the Offer can send (which s=
hould be compatible with the receive information in the Offer). =3B Thi=
s may allow the negotiation to be concluded in a single Offer/Answer exchan=
ge. =3B 

[Harald] =3B If CLUE goes with multiple streams per=
 m-line=2C and in-SDP=0A=
    signalling=2C it needs RFC 5576. If out-of-band signalling needs to ref=
er to SSRCs=2C we need unique=0A=
    identifiers (SRCNAME or MSID) that out-of-band signalling can use to=0A=
    refer to the flows. Those will likely use RFC 5576 too.

[BA] Chr=
ister has suggested that CLUE out-of-band signalling should only be require=
d to communicate parameters (such as spatial relationships) that are unique=
 to CLUE. =3B =3B This seems reasonable to me=2C but today there is=
 considerable overlap in the parameters described in =0A=
draft-ietf-clue-framework and SDP documents such as RFC 5576=2C 6236=2C =0A=
draft-lennox-mmusic-sdp-source-selection and =0A=
draft-westerlund-mmusic-max-ssrc. =3B 
=0A=
    
=0A=
    
=0A=
      
=0A=
        
 If RFC 5576 is to be "the answah"=2C then MMUSIC need=
s=0A=
            to fill in the details of how the SDP negotiation works.=0A=
            Alternatively=2C if the negotiation is to occur outside SDP=0A=
            (as advocated in CLUE)=2C then we need an explicit statement=0A=
            of where the boundaries lie.  =3BThe middle path (pursuing=
=0A=
            neither with conviction) doesn't seem viable to me. 

=0A=
          
=0A=
      
=0A=
    
=0A=
    [Harald] Our ability to converge on a boundary definition with convicti=
on=0A=
    seems limited. So since we're presently implementing=2C it seems that=
=0A=
    our options are limited to what can be achieved without such=0A=
    convergence.

[BA] We can at least describe how the source negoti=
ation is supposed to work in the absence of CLUE. =3B That exercise wou=
ld help in understand the limits of what can be accomplished in a single O/=
A exchange. =3B 
 		 	   		  

=

--_d7f653f9-915f-48fa-8050-547343466fb2_--

From stefan.lk.hakansson@ericsson.com  Fri Nov 23 03:08:40 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B31121F842A for ; Fri, 23 Nov 2012 03:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.052
X-Spam-Level: 
X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34X0LJmifEPU for ; Fri, 23 Nov 2012 03:08:39 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3789721F8200 for ; Fri, 23 Nov 2012 03:08:39 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-6d-50af59351d22
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2D.5B.26143.5395FA05; Fri, 23 Nov 2012 12:08:37 +0100 (CET)
Received: from [150.132.142.241] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 23 Nov 2012 12:08:36 +0100
Message-ID: <50AF5934.8010307@ericsson.com>
Date: Fri, 23 Nov 2012 12:08:36 +0100
From: Stefan Hakansson LK 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50AF589F.50501@ericsson.com>
In-Reply-To: <50AF589F.50501@ericsson.com>
X-Forwarded-Message-Id: <50AF589F.50501@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvja5p5PoAg+/HFCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN3bV7AX3Bat2N79lrmBcadAFyMHh4SAicSn+7pdjJxAppjE hXvr2boYuTiEBE4ySnz98IwZJCEksJZR4ls/E4jNK6At8WLCe3YQm0VAVWLDliOMIDabgI3E 2u4pYDWiAgESi5ecY4eoF5Q4OfMJC4gtIiAsMePtXzYQW1ggSWLVsVlMEPM1Jeav3Q1Wwymg JXH00x1miINMJX5vvQw2n1nAVuLCnOssELa8xPa3c6Bu05V49/oe6wRGwVlI1s1C0jILScsC RuZVjOy5iZk56eVGmxiBwXdwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUAyPDNgXz2hs3rzsuE1NmY5p+OPl80NuY6W67vz0O/c5VNOmiscb+W9OvJint VODiOfzC8UoKW1tP6R7xsFlWJkc1hL2WrLytdGtpnfeDWQLRGyrerLgy0fmzlUF9mryOyTFh +ekx3pZSE5n/3Ax/5+nzWOm3boXxzkc3hI9XREsmK2VYGt6xUlNiKc5INNRiLipOBABixX6M DAIAAA==
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 11:08:40 -0000

Thanks for the clarifications, and I agree to what rtcweb/webrtc should
decide.

What I was implying in my original mail is that I think T.38 support
should not be added to browsers (at least not as part of the
rtcweb/webrtc effort), and there are at least two reasons:

* It is not in any of the use-cases
* You can support store-and-forward FoIP in browsers already

But this discussion should happen in the rtcweb/webrtc space.

Stefan

On 11/22/2012 02:59 PM, Schwarz, Albrecht (Albrecht) wrote:
> Looks like that your are describing T.37 FoIP behaviour, whereas Adam
> did point on T.38 FoIP.
>
> WebRTC should firstly agree
> a) whether fax is part of this conversational realtime multimedia
> service at all,
> and if,
> b) which transport mode via IP.
>
> To a): support of F.185 (Internet fax) Yes/No
> To b):
>      b.1) T.37 FoIP store-and-forward already sufficient Yes/No
>      b.2) T.38 FoIP realtime required Yes/No ((perhaps T.38 over RTP/UDP
> or UDPTL/UDP))
>      b.3) or any alternative to T.38 FoIP realtime Yes/No
>
> NOTE: T.38 would specify the behaviour of the
> 1) PSTN gateway (as "T.38 gateway", which is always a PSTN-to-IP
> gateway) and
> 2) Browser (as "T.38 IAD" (Internet aware fax device))
> in below illustration.
>
> -Albrecht
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Stefan Hakansson LK
> Sent: Donnerstag, 22. November 2012 14:39
> To: mmusic at ietf.org
> Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
> Prioritization of codecs))
>
> On 11/20/2012 15:56, Adam Roach wrote:
>  >
>  >
>  >    +---------+   +------------+   +---------+
>  >    | Web App |---| SIP Server |---|         |
>  >    +---------+   +------------+   |         | +-------------+
>  >         |                         | PSTN GW |--| Fax Machine |
>  >    +---------+      media         |         | +-------------+
>  >    | Browser |--------------------|         |
>  >    +---------+                    +---------+
>
> For cases when one client is not a proper fax machine, is not the usual
> thing that is done that the facsimile is converted to/from TIFF, JPEG,
> PDF or similar somewhere between that client and the fax machine? (And
> often sent as a mail attachment)
>
> If so, all tools are already available (e.g. File API if you want to
> store/access on the local file system, XHR or WebSockets - or even the
> rtcweb data channel for transport) to build a client that can handle
> fax. (I am probably missing something)
>
> Stefan
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic




From albrecht.schwarz@alcatel-lucent.com  Fri Nov 23 03:11: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 3A5C121F85C2 for ; Fri, 23 Nov 2012 03:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.524
X-Spam-Level: 
X-Spam-Status: No, score=-8.524 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNKuA-qU7xhr for ; Fri, 23 Nov 2012 03:11:37 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7FF21F842A for ; Fri, 23 Nov 2012 03:11:36 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qANBANDO003673 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Nov 2012 12:11:34 +0100
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 23 Nov 2012 12:11:26 +0100
From: "Schwarz, Albrecht (Albrecht)" 
To: Stefan Hakansson LK , "mmusic@ietf.org" 
Date: Fri, 23 Nov 2012 12:11:24 +0100
Thread-Topic: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
Thread-Index: Ac3JauvwfSEsSmOxTHeIKNexvmmvDQAACdGA
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9623DF0C447C@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>
In-Reply-To: <50AF5934.8010307@ericsson.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 11:11:41 -0000

Fully agree!

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Stefan Hakansson LK
Sent: Freitag, 23. November 2012 12:09
To: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prior=
itization of codecs))

Thanks for the clarifications, and I agree to what rtcweb/webrtc should
decide.

What I was implying in my original mail is that I think T.38 support
should not be added to browsers (at least not as part of the
rtcweb/webrtc effort), and there are at least two reasons:

* It is not in any of the use-cases
* You can support store-and-forward FoIP in browsers already

But this discussion should happen in the rtcweb/webrtc space.

Stefan

On 11/22/2012 02:59 PM, Schwarz, Albrecht (Albrecht) wrote:
> Looks like that your are describing T.37 FoIP behaviour, whereas Adam
> did point on T.38 FoIP.
>
> WebRTC should firstly agree
> a) whether fax is part of this conversational realtime multimedia
> service at all,
> and if,
> b) which transport mode via IP.
>
> To a): support of F.185 (Internet fax) Yes/No
> To b):
>      b.1) T.37 FoIP store-and-forward already sufficient Yes/No
>      b.2) T.38 FoIP realtime required Yes/No ((perhaps T.38 over RTP/UDP
> or UDPTL/UDP))
>      b.3) or any alternative to T.38 FoIP realtime Yes/No
>
> NOTE: T.38 would specify the behaviour of the
> 1) PSTN gateway (as "T.38 gateway", which is always a PSTN-to-IP
> gateway) and
> 2) Browser (as "T.38 IAD" (Internet aware fax device))
> in below illustration.
>
> -Albrecht
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Stefan Hakansson LK
> Sent: Donnerstag, 22. November 2012 14:39
> To: mmusic at ietf.org
> Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
> Prioritization of codecs))
>
> On 11/20/2012 15:56, Adam Roach wrote:
>  >
>  >
>  >    +---------+   +------------+   +---------+
>  >    | Web App |---| SIP Server |---|         |
>  >    +---------+   +------------+   |         | +-------------+
>  >         |                         | PSTN GW |--| Fax Machine |
>  >    +---------+      media         |         | +-------------+
>  >    | Browser |--------------------|         |
>  >    +---------+                    +---------+
>
> For cases when one client is not a proper fax machine, is not the usual
> thing that is done that the facsimile is converted to/from TIFF, JPEG,
> PDF or similar somewhere between that client and the fax machine? (And
> often sent as a mail attachment)
>
> If so, all tools are already available (e.g. File API if you want to
> store/access on the local file system, XHR or WebSockets - or even the
> rtcweb data channel for transport) to build a client that can handle
> fax. (I am probably missing something)
>
> Stefan
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



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

From internet-drafts@ietf.org  Fri Nov 23 05:04: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 1766721F856F; Fri, 23 Nov 2012 05:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level: 
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn415e0s1b6Q; Fri, 23 Nov 2012 05:04:34 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AEC21F84C4; Fri, 23 Nov 2012 05:04:34 -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.36
Message-ID: <20121123130434.28783.9314.idtracker@ietfa.amsl.com>
Date: Fri, 23 Nov 2012 05:04:34 -0800
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-06.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, 23 Nov 2012 13:04:39 -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 Wor=
king Group of the IETF.

	Title           : The Evaluation of Different Network Address Translator (=
NAT) Traversal Techniques for Media Controlled by Real-time Streaming Proto=
col (RTSP)
	Author(s)       : Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-06.txt
	Pages           : 41
	Date            : 2012-11-23

Abstract:
   This document describes several Network Address Translator (NAT)
   traversal techniques that were considered to be used for establishing
   the RTP media flows controlled by the Real-time Streaming Protocol
   (RTSP).  Each technique includes a description on how it would be
   used, the security implications of using it and any other deployment
   considerations it has.  There are also discussions on how NAT
   traversal techniques relates to firewalls and how each technique can
   be applied in different use cases.  These findings where used when
   selecting the NAT traversal for RTSP 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From magnus.westerlund@ericsson.com  Fri Nov 23 05:10:02 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 6B33E21F854F for ; Fri, 23 Nov 2012 05:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.18
X-Spam-Level: 
X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEYzH6IG1oX3 for ; Fri, 23 Nov 2012 05:09:58 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8086221F8514 for ; Fri, 23 Nov 2012 05:09:57 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-bf-50af75a47561
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 61.BD.11564.4A57FA05; Fri, 23 Nov 2012 14:09:56 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 23 Nov 2012 14:09:56 +0100
Message-ID: <50AF75A3.9010408@ericsson.com>
Date: Fri, 23 Nov 2012 14:09:55 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "mmusic (E-mail)" 
References: <20121123130434.28783.9314.idtracker@ietfa.amsl.com>
In-Reply-To: <20121123130434.28783.9314.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvje6S0vUBBouOqFlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdcaX7IW7JCoaO6fy9TAeFe4i5GTQ0LAROLo/tuMELaYxIV7 69m6GLk4hAROMkpc3XOdGcJZzihxYcMlsCpeAW2J2/8WsYDYLAKqEq/7N7KD2GwCFhI3fzSy gdiiAr4Ss/b8YoKoF5Q4OfMJWL2IgLpE6+Y+VhBbWMBVouPVWzBbSMBB4uyuL2D1nAKOElev f2ODuEhSYtG0TrBeZgE9iSlXWxghbHmJ5q2zmSF6tSUamjpYJzAKzkKybhaSlllIWhYwMq9i ZM9NzMxJLzfcxAgMwINbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjEGJxdO2XPMqM/KzUE5+x/nlsFjpVlWJL9kuX7nVJBOZt7/hfalx8eW643lz7bcH 5fRNfGdruCza6+mXZvPuk23sN3hlPepPW6dND808E6t7d7rwhpOu0/TUHornT+3R7CnM+nRR Tvjo26qYDzv3RNSp/JD8IdUZdS6r+NYSjV3fD+RedpS0VGIpzkg01GIuKk4EAA9Z2jYOAgAA
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-06.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, 23 Nov 2012 13:10:02 -0000

WG,

This version is the update to address all of Flemming's comments from
the WG last call. If you check the diff:

http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-06

You will notice that this version has gone through a number of
significant changes. Including clearer section structure around
variants. Expanded comparison table and conclusions. Many, many
editorial fixes and quite a lot of corrections and clarifications.

Based on that I would recommend the WG chairs to make a second call on
these changes before requesting publication.

Cheers

Magnus


On 2012-11-23 14:04, 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           : The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
> 	Author(s)       : Magnus Westerlund
>                           Thomas Zeng
> 	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-06.txt
> 	Pages           : 41
> 	Date            : 2012-11-23
> 
> Abstract:
>    This document describes several Network Address Translator (NAT)
>    traversal techniques that were considered to be used for establishing
>    the RTP media flows controlled by the Real-time Streaming Protocol
>    (RTSP).  Each technique includes a description on how it would be
>    used, the security implications of using it and any other deployment
>    considerations it has.  There are also discussions on how NAT
>    traversal techniques relates to firewalls and how each technique can
>    be applied in different use cases.  These findings where used when
>    selecting the NAT traversal for RTSP 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-06
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-06
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> 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
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From partha@parthasarathi.co.in  Fri Nov 23 08:23: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 0E5AB21F8751 for ; Fri, 23 Nov 2012 08:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.97
X-Spam-Level: 
X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-1.005,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_OFF=2.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8qJH4jltJI5 for ; Fri, 23 Nov 2012 08:23:52 -0800 (PST)
Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC9721F867D for ; Fri, 23 Nov 2012 08:23:52 -0800 (PST)
Received: from userPC (unknown [122.179.42.74]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 36825190822B;  Fri, 23 Nov 2012 16:23:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1353687831; bh=jDmftqnvUA1GRkzDTv5Wrv6QduFRQS9KnDwqIujjuCY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nLjaicHgIFfZ+AVKTkbphaH331Sp0QivwoY8AWQEMeC7h0PtDVLP0CnEA+Wp0SNAg exGrUKCTvr0FKIMLW2kf5Fcj7XnolKFM+uN181bbXo/OanGOsPA36R4pPvDRbwq7eD v924LELX1pePfVu96Q0yTK6QYYGrVxOixOmj64jQ=
From: "Parthasarathi R" 
To: "'Stefan Hakansson LK'" , 
References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>
In-Reply-To: <50AF5934.8010307@ericsson.com>
Date: Fri, 23 Nov 2012 21:53:41 +0530
Message-ID: <000601cdc996$ea6c0ec0$bf442c40$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac3JauuYCnD5L7jmTjepkNj0ik196gAKwCXQ
Content-Language: en-us
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A0C020A.50AFA317.00E4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 16:23:53 -0000

Stefan,

I agree with you that usecase does not exists.

I think that T.38 shall be considered as part of PSTN interop as DTMF
usecase is already considered for PSTN interop. In fact, DTMF interop with
PSTN gateway shall be easily achieved using non-media (RTP) mechanism but it
is tough achieve real-time fax interop without media (T.38) support.

Thanks
Partha

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Stefan Hakansson LK
Sent: Friday, November 23, 2012 4:39 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
Prioritization of codecs))

Thanks for the clarifications, and I agree to what rtcweb/webrtc should
decide.

What I was implying in my original mail is that I think T.38 support
should not be added to browsers (at least not as part of the
rtcweb/webrtc effort), and there are at least two reasons:

* It is not in any of the use-cases
* You can support store-and-forward FoIP in browsers already

But this discussion should happen in the rtcweb/webrtc space.

Stefan

On 11/22/2012 02:59 PM, Schwarz, Albrecht (Albrecht) wrote:
> Looks like that your are describing T.37 FoIP behaviour, whereas Adam
> did point on T.38 FoIP.
>
> WebRTC should firstly agree
> a) whether fax is part of this conversational realtime multimedia
> service at all,
> and if,
> b) which transport mode via IP.
>
> To a): support of F.185 (Internet fax) Yes/No
> To b):
>      b.1) T.37 FoIP store-and-forward already sufficient Yes/No
>      b.2) T.38 FoIP realtime required Yes/No ((perhaps T.38 over RTP/UDP
> or UDPTL/UDP))
>      b.3) or any alternative to T.38 FoIP realtime Yes/No
>
> NOTE: T.38 would specify the behaviour of the
> 1) PSTN gateway (as "T.38 gateway", which is always a PSTN-to-IP
> gateway) and
> 2) Browser (as "T.38 IAD" (Internet aware fax device))
> in below illustration.
>
> -Albrecht
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Stefan Hakansson LK
> Sent: Donnerstag, 22. November 2012 14:39
> To: mmusic at ietf.org
> Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
> Prioritization of codecs))
>
> On 11/20/2012 15:56, Adam Roach wrote:
>  >
>  >
>  >    +---------+   +------------+   +---------+
>  >    | Web App |---| SIP Server |---|         |
>  >    +---------+   +------------+   |         | +-------------+
>  >         |                         | PSTN GW |--| Fax Machine |
>  >    +---------+      media         |         | +-------------+
>  >    | Browser |--------------------|         |
>  >    +---------+                    +---------+
>
> For cases when one client is not a proper fax machine, is not the usual
> thing that is done that the facsimile is converted to/from TIFF, JPEG,
> PDF or similar somewhere between that client and the fax machine? (And
> often sent as a mail attachment)
>
> If so, all tools are already available (e.g. File API if you want to
> store/access on the local file system, XHR or WebSockets - or even the
> rtcweb data channel for transport) to build a client that can handle
> fax. (I am probably missing something)
>
> Stefan
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



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


From stefan.lk.hakansson@ericsson.com  Sun Nov 25 10:43: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 D1AF921F8604 for ; Sun, 25 Nov 2012 10:43:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.779
X-Spam-Level: 
X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4-3pq7QFMcx for ; Sun, 25 Nov 2012 10:43:21 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC0321F8602 for ; Sun, 25 Nov 2012 10:43:19 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-fb-50b266c65bd3
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B6.D8.11564.6C662B05; Sun, 25 Nov 2012 19:43:18 +0100 (CET)
Received: from [153.88.53.6] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Sun, 25 Nov 2012 19:43:18 +0100
Message-ID: <50B266C5.90902@ericsson.com>
Date: Sun, 25 Nov 2012 19:43:17 +0100
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Parthasarathi R 
References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com> <000601cdc996$ea6c0ec0$bf442c40$@co.in>
In-Reply-To: <000601cdc996$ea6c0ec0$bf442c40$@co.in>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RvdY2qYAg8NzZC2mLn/MYjH5Ux+r A5PHkiU/mTw+zP/CHsAUxWWTkpqTWZZapG+XwJWx7Md7xoJVShXz71g1MB6V6mLk4JAQMJG4 dte4i5ETyBSTuHBvPVsXIxeHkMBJRonGJb2MEM5KRomz8/eyglTxCmhKHPj5gh3EZhFQlbj4 aAkLiM0mEChx/f8vJhBbVCBK4sfWs+wQ9YISJ2c+AasRETCQ+L3tIdgcZgFhiQvnj4PVCwsk Saw6NgvMFhIolNj+fxlYPSfQcdP+dTBD1NtKXJhznQXClpfY/nYOM0S9rsS71/dYJzAKzkKy bhaSlllIWhYwMq9iZM9NzMxJLzfcxAgMyINbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjHEC+QnKaid2G+3m/iq1U89IP97ujp/X+UepX+bHxxQ7/Tji fn/nBEtfpuq7sVMMtjRz1Yob/E1d/F38V2Z3cLOmt/P6pri1a4v+rfCbfWGKsX/Z+sXXCkpW R09i2n/3ufCfpyWlCetCeOuszea6CrZP5is6c7OpzuJ0mPQc800nObVTZ5+ersRSnJFoqMVc VJwIAHIPSLAWAgAA
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 18:43:22 -0000

Hi Partha,
On 2012-11-23 17:23, Parthasarathi R wrote:
> Stefan,
>
> I agree with you that usecase does not exists.
>
> I think that T.38 shall be considered as part of PSTN interop as DTMF
> usecase is already considered for PSTN interop. In fact, DTMF interop with
> PSTN gateway shall be easily achieved using non-media (RTP) mechanism but it
> is tough achieve real-time fax interop without media (T.38) support.


This is correct AFAIK. And personally I did not really want DTMF as part 
of rtcweb - it is just for legacy interop, and can be solved by other 
means as you point out. But the wg's view was that sending DTMF should 
be supported, and perhaps that makes sense - DTMF is quite often used, 
by a lot of people (I use it almost daily to navigate IVRs).

I don't think this goes for fax, I think fax these days is only used by 
certain (few) organizations and only for certain types of communication.

But if you think differently, please make a proposal on the rtcweb mail 
list!

Thanks,
Stefan

>
> Thanks
> Partha
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
> Stefan Hakansson LK
> Sent: Friday, November 23, 2012 4:39 PM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
> Prioritization of codecs))
>
> Thanks for the clarifications, and I agree to what rtcweb/webrtc should
> decide.
>
> What I was implying in my original mail is that I think T.38 support
> should not be added to browsers (at least not as part of the
> rtcweb/webrtc effort), and there are at least two reasons:
>
> * It is not in any of the use-cases
> * You can support store-and-forward FoIP in browsers already
>
> But this discussion should happen in the rtcweb/webrtc space.
>
> Stefan
>
> On 11/22/2012 02:59 PM, Schwarz, Albrecht (Albrecht) wrote:
>> Looks like that your are describing T.37 FoIP behaviour, whereas Adam
>> did point on T.38 FoIP.
>>
>> WebRTC should firstly agree
>> a) whether fax is part of this conversational realtime multimedia
>> service at all,
>> and if,
>> b) which transport mode via IP.
>>
>> To a): support of F.185 (Internet fax) Yes/No
>> To b):
>>       b.1) T.37 FoIP store-and-forward already sufficient Yes/No
>>       b.2) T.38 FoIP realtime required Yes/No ((perhaps T.38 over RTP/UDP
>> or UDPTL/UDP))
>>       b.3) or any alternative to T.38 FoIP realtime Yes/No
>>
>> NOTE: T.38 would specify the behaviour of the
>> 1) PSTN gateway (as "T.38 gateway", which is always a PSTN-to-IP
>> gateway) and
>> 2) Browser (as "T.38 IAD" (Internet aware fax device))
>> in below illustration.
>>
>> -Albrecht
>>
>> -----Original Message-----
>> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
>> Behalf Of Stefan Hakansson LK
>> Sent: Donnerstag, 22. November 2012 14:39
>> To: mmusic at ietf.org
>> Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
>> Prioritization of codecs))
>>
>> On 11/20/2012 15:56, Adam Roach wrote:
>>   >
>>   >
>>   >    +---------+   +------------+   +---------+
>>   >    | Web App |---| SIP Server |---|         |
>>   >    +---------+   +------------+   |         | +-------------+
>>   >         |                         | PSTN GW |--| Fax Machine |
>>   >    +---------+      media         |         | +-------------+
>>   >    | Browser |--------------------|         |
>>   >    +---------+                    +---------+
>>
>> For cases when one client is not a proper fax machine, is not the usual
>> thing that is done that the facsimile is converted to/from TIFF, JPEG,
>> PDF or similar somewhere between that client and the fax machine? (And
>> often sent as a mail attachment)
>>
>> If so, all tools are already available (e.g. File API if you want to
>> store/access on the local file system, XHR or WebSockets - or even the
>> rtcweb data channel for transport) to build a client that can handle
>> fax. (I am probably missing something)
>>
>> Stefan
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic at ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From bernard_aboba@hotmail.com  Sun Nov 25 11:43: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 22AC921F8661 for ; Sun, 25 Nov 2012 11:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.334
X-Spam-Level: 
X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6mAUvFQHeAB for ; Sun, 25 Nov 2012 11:43:48 -0800 (PST)
Received: from blu0-omc3-s33.blu0.hotmail.com (blu0-omc3-s33.blu0.hotmail.com [65.55.116.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77A0821F8665 for ; Sun, 25 Nov 2012 11:43:48 -0800 (PST)
Received: from BLU002-W10 ([65.55.116.72]) by blu0-omc3-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 25 Nov 2012 11:43:46 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_24ddd0be-f116-4ee7-b6ad-e245ae11c0aa_"
X-Originating-IP: [24.16.96.166]
From: Bernard Aboba 
To: =?iso-8859-1?B?U3RlZmFuIEjla2Fuc3NvbiBMSw==?= 
Date: Sun, 25 Nov 2012 11:43:46 -0800
Importance: Normal
In-Reply-To: <50B266C5.90902@ericsson.com>
References: <50AF589F.50501@ericsson.com> <50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@ericsson.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Nov 2012 19:43:46.0698 (UTC) FILETIME=[2F1946A0:01CDCB45]
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 19:43:49 -0000

--_24ddd0be-f116-4ee7-b6ad-e245ae11c0aa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Stefan said:

> I don't think this goes for fax=2C I think fax these days is only used by=
=20
> certain (few) organizations and only for certain types of communication.
>=20
> But if you think differently=2C please make a proposal on the rtcweb mail=
 list!

[BA]  Given the steep decline in landlines=2C POTS is on the road to becomi=
ng economically non-viable by the end of the decade=2C if not sooner.   Onc=
e POTS shuts down=2C the legal and regulatory requirements which prop up th=
e use of fax will need to be re-thought.  IMHO given the bleak future of fa=
x=2C supporting it in WebRTC is not worth the effort.=20

BTW=2C support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-aud=
io-01 instead of  RFC 4734 (Fax=2C Modem and Text Telephony) which was cite=
d (mistakenly) in -00.  =20

Bernard "Spent several hours debugging T.38 last week" Aboba
 		 	   		  =

--_24ddd0be-f116-4ee7-b6ad-e245ae11c0aa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Stefan said:

>=3B =
I don't think this goes for fax=2C I think fax these days is only used by <=
br>>=3B certain (few) organizations and only for certain types of communi=
cation.
>=3B 
>=3B But if you think differently=2C please make a =
proposal on the rtcweb mail list!

[BA] =3B Given the steep decli=
ne in landlines=2C POTS is on the road to becoming economically non-viable =
by the end of the decade=2C if not sooner.  =3B Once POTS shuts down=2C=
 the legal and regulatory requirements which prop up the use of fax will ne=
ed to be re-thought. =3B IMHO given the bleak future of fax=2C supporti=
ng it in WebRTC is not worth the effort. 

BTW=2C support for RFC 473=
3 (DTMF) is now required in draft-ietf-rtcweb-audio-01 instead of =3B R=
FC 4734 (Fax=2C Modem and Text Telephony) which was cited (mistakenly) in -=
00.  =3B 

Bernard "Spent several hours debugging T.38 last week"=
 Aboba
 		 	   		  

=

--_24ddd0be-f116-4ee7-b6ad-e245ae11c0aa_--

From internet-drafts@ietf.org  Sun Nov 25 23:40: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 4B81E21F86AC; Sun, 25 Nov 2012 23:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRIqyv8Hh8wZ; Sun, 25 Nov 2012 23:40:03 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7D21F8687; Sun, 25 Nov 2012 23:40:03 -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.36
Message-ID: <20121126074003.29289.99493.idtracker@ietfa.amsl.com>
Date: Sun, 25 Nov 2012 23:40:03 -0800
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-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 Nov 2012 07:40: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 Wor=
king Group of the IETF.

	Title           : Offer/Answer Considerations for G.723 Annex A and G.729 =
Annex B
	Author(s)       : Muthu Arul Mozhi Perumal
                          Parthasarathi Ravindran
	Filename        : draft-ietf-mmusic-sdp-g723-g729-00.txt
	Pages           : 8
	Date            : 2012-11-23

Abstract:
   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the SDP offer and
   answer.  This document provides the offer/answer considerations for
   these parameters and updates RFC4856.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From harald@alvestrand.no  Sun Nov 25 23:44: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 88D4921F86AE for ; Sun, 25 Nov 2012 23:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUwrjldSsV1m for ; Sun, 25 Nov 2012 23:44:26 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8933C21F86AC for ; Sun, 25 Nov 2012 23:44:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FDBE39E13F for ; Mon, 26 Nov 2012 08:44:22 +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 RdtgWcQRcOMs for ; Mon, 26 Nov 2012 08:44:21 +0100 (CET)
Received: from [172.30.42.102] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 59F6D39E01E for ; Mon, 26 Nov 2012 08:44:21 +0100 (CET)
Message-ID: <50B31DD5.7070302@alvestrand.no>
Date: Mon, 26 Nov 2012 08:44:21 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: , , <265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com>, , <50AD0BCB.9090508@alum.mit.edu>, , <50AE1D75.1070100@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B0428C4@ESESSMB209.ericsson.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070504080009050803050103"
Subject: Re: [MMUSIC] RFC 5576 is da answah
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 Nov 2012 07:44:26 -0000

This is a multi-part message in MIME format.
--------------070504080009050803050103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/22/2012 11:17 PM, Bernard Aboba wrote:
> Christer said:
>
> "My suggestion has been that "CLUE application specific data" (e.g. 
> spatial relationship information) goes into the CLUE channel, while 
> "transport data" (especially data which might be needed by 
> intermediaries etc) goes into SDP. "
>
> [BA]  That seems like a reasonable guideline to me.  Looking at 
> draft-ietf-clue-framework Section 6.1.1, many of the attributes other 
> than the "spatial relationship" ones (such as Point of Capture, Line 
> of Capture and Area of Capture) do seem like they can be handled in 
> SDP.  For example,  the max-send-ssrc:  and max-recv-ssrc: parameters 
> defined in draft-westerlund-mmusic-max-ssrc seem to communicate 
> similar information to Max Capture Encodings, and Encoding Group might 
> be taken care of via the a=ssrc-group construct in RFC 5576. Height, 
> Width and Framerate also can be handled in SDP (though IMHO the 
> negotiation mechanism in draft-lennox-mmusic-sdp-source-selection 
> needs work).
>
> [Harald]  The answer asks for *exactly* 720 by 576. The offerer has to 
> either send in that resolution or renegotiate.
> If a range was acceptable, the answerer should have indicated that 
> ([x=700:800,y=500:600]).
>
> [BA] Yes, but it seems clumsy for the receiver to indicate its 
> preferences without information on what the sender supports. In 
> draft-lennox-mmusic-sdp-source-selection, imageattr information only 
> seems to be supported in the answer, whereas in RFC 6236, the Offer 
> may include both send and receive information as described in Section 6.1:
> a=imageattr:PT send attr-list recv attr-list
> Including both send and receive information in the Offer seems more 
> likely to enable the negotiation to conclude in a single Offer/Answer 
> exchange.

So are you arguing that draft-lennox should specify "imageattr" with the 
"a=ssrc" construct as well as with the "a=remote-ssrc" construct? I 
could support that.

Sender's generic support can be indicated using 6236, but the sender 
might want to specify it per stream too.


--------------070504080009050803050103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 11/22/2012 11:17 PM, Bernard Aboba
      wrote:

    

    

      
      
Christer said:

        

        "My suggestion has been that "CLUE application specific data"
        (e.g. spatial relationship information) goes into the CLUE
        channel, while "transport data" (especially data which might be
        needed by intermediaries etc) goes into SDP. "

        


          [BA]  That seems like a reasonable guideline to me.  Looking
          at draft-ietf-clue-framework Section 6.1.1, many of the
          attributes other than the "spatial relationship" ones (such as
          Point of Capture, Line of Capture and Area of Capture) do seem
          like they can be handled in SDP.  For example,  the
          max-send-ssrc:  and max-recv-ssrc: parameters defined in
          draft-westerlund-mmusic-max-ssrc seem to communicate similar
          information to Max Capture Encodings, and Encoding Group might
          be taken care of via the a=ssrc-group construct in RFC 5576.  
          Height, Width and Framerate also can be handled in SDP (though
          IMHO the negotiation mechanism in
          draft-lennox-mmusic-sdp-source-selection needs work). 

          

          [Harald]  The answer asks for *exactly* 720 by 576. The
          offerer has to either send in that resolution or renegotiate.

          If a range was acceptable, the answerer should have indicated
          that ([x=700:800,y=500:600]).

          

          [BA] Yes, but it seems clumsy for the receiver to indicate its
          preferences without information on what the sender supports. 
          In draft-lennox-mmusic-sdp-source-selection, imageattr
          information only seems to be supported in the answer, whereas
          in RFC 6236, the Offer may include both send and receive
          information as described in Section 6.1:

          
a=imageattr:PT send attr-list recv attr-list

          Including both send and receive information in the Offer seems
          more likely to enable the negotiation to conclude in a single
          Offer/Answer exchange.

        

      

    

    

    So are you arguing that draft-lennox should specify "imageattr" with
    the "a=ssrc" construct as well as with the "a=remote-ssrc"
    construct? I could support that.

    

    Sender's generic support can be indicated using 6236, but the sender
    might want to specify it per stream too.

    

  


--------------070504080009050803050103--

From bernard_aboba@hotmail.com  Mon Nov 26 00:02: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 6490721F85C2 for ; Mon, 26 Nov 2012 00:02:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.998
X-Spam-Level: 
X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8csO6ZKGDCe for ; Mon, 26 Nov 2012 00:02:51 -0800 (PST)
Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE721F85B4 for ; Mon, 26 Nov 2012 00:02:51 -0800 (PST)
Received: from BLU002-W234 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 26 Nov 2012 00:02:50 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_6f0d5894-eda6-4812-9f23-1250a284bed1_"
X-Originating-IP: [24.16.96.166]
From: Bernard Aboba 
To: Harald Alvestrand , "mmusic@ietf.org" 
Date: Mon, 26 Nov 2012 00:02:50 -0800
Importance: Normal
In-Reply-To: <50B31DD5.7070302@alvestrand.no>
References: , ,,<265A48F7-9330-4415-9BF9-CAA29FE12BAE@vidyo.com>, , , <50AD0BCB.9090508@alum.mit.edu>, , , , <50AE1D75.1070100@alvestrand.no>, , <7594FB04B1934943A5C02806D1A2204B0428C4@ESESSMB209.ericsson.se>, , <50B31DD5.7070302@alvestrand.no>
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Nov 2012 08:02:50.0408 (UTC) FILETIME=[6E027280:01CDCBAC]
Subject: Re: [MMUSIC] RFC 5576 is da answah
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 Nov 2012 08:02:52 -0000

--_6f0d5894-eda6-4812-9f23-1250a284bed1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Harald said:

=0A=
    "So are you arguing that draft-lennox should specify "imageattr" with=
=0A=
    the "a=3Dssrc" construct as well as with the "a=3Dremote-ssrc"=0A=
    construct? I could support that.
=0A=
   =20
=0A=
    Sender's generic support can be indicated using 6236=2C but the sender=
=0A=
    might want to specify it per stream too."

[BA] Yes.  There are situations in which per-stream information would be us=
eful (e.g. if the cameras do not have the same capabilities).  Including a=
=3Dssrc and a=3Dremote-ssrc in both the Offer and the Answer=2C along with =
parameters from RFC 6236=2C it seems to me that it would be possible to neg=
otiate per-stream parameters in a single O/A exchange in many situations. =
=20
 		 	   		  =

--_6f0d5894-eda6-4812-9f23-1250a284bed1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Harald said:

=0A=
    "So are you arguing that draft-lennox should specify "imageattr" with=
=0A=
    the "a=3Dssrc" construct as well as with the "a=3Dremote-ssrc"=0A=
    construct? I could support that.
=0A=
    
=0A=
    Sender's generic support can be indicated using 6236=2C but the sender=
=0A=
    might want to specify it per stream too."

[BA] Yes. =3B Ther=
e are situations in which per-stream information would be useful (e.g. if t=
he cameras do not have the same capabilities). =3B Including a=3Dssrc a=
nd a=3Dremote-ssrc in both the Offer and the Answer=2C along with parameter=
s from RFC 6236=2C it seems to me that it would be possible to negotiate pe=
r-stream parameters in a single O/A exchange in many situations. =3B 
 		 	   		  

=

--_6f0d5894-eda6-4812-9f23-1250a284bed1_--

From keith.drage@alcatel-lucent.com  Mon Nov 26 01:56: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 9F9CD21F85CB for ; Mon, 26 Nov 2012 01:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.948
X-Spam-Level: 
X-Spam-Status: No, score=-109.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w0mk4YHOEad for ; Mon, 26 Nov 2012 01:56:07 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D2D1221F8563 for ; Mon, 26 Nov 2012 01:56:06 -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 qAQ9hpDE026479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Nov 2012 10:56:00 +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; Mon, 26 Nov 2012 10:55:55 +0100
From: "DRAGE, Keith (Keith)" 
To: Bernard Aboba , =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
Date: Mon, 26 Nov 2012 10:55:54 +0100
Thread-Topic: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
Thread-Index: Ac3LRTNgAq5uAGpzTmSHXiV6vqL1AgAdtimg
Message-ID: 
References: <50AF589F.50501@ericsson.com>	<50AF5934.8010307@ericsson.com>, <000601cdc996$ea6c0ec0$bf442c40$@co.in>, <50B266C5.90902@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_EDC0A1AE77C57744B664A310A0B23AE202D30E076BFRMRSSXCHMBSC_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
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 Nov 2012 09:56:07 -0000

--_000_EDC0A1AE77C57744B664A310A0B23AE202D30E076BFRMRSSXCHMBSC_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Be careful to address this issue from a worldwide context rather than a Nor=
th America specific one.

There are still plenty of people raising fax issues from the Asian countrie=
s.

Keith

________________________________
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 Bernard Aboba
Sent: 25 November 2012 19:44
To: Stefan H=E5kansson LK
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prior=
itization of codecs))

Stefan said:
> I don't think this goes for fax, I think fax these days is only used by
> certain (few) organizations and only for certain types of communication.
>
> But if you think differently, please make a proposal on the rtcweb mail l=
ist!

[BA]  Given the steep decline in landlines, POTS is on the road to becoming=
 economically non-viable by the end of the decade, if not sooner.   Once PO=
TS shuts down, the legal and regulatory requirements which prop up the use =
of fax will need to be re-thought.  IMHO given the bleak future of fax, sup=
porting it in WebRTC is not worth the effort.

BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-audio=
-01 instead of  RFC 4734 (Fax, Modem and Text Telephony) which was cited (m=
istakenly) in -00.

Bernard "Spent several hours debugging T.38 last week" Aboba

--_000_EDC0A1AE77C57744B664A310A0B23AE202D30E076BFRMRSSXCHMBSC_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


















Be careful to address this issue from =
a
worldwide context rather than a North America
specific one.



 



There are still plenty of people raisi=
ng fax
issues from the Asian countries.



 



Keith



 


















From:=

mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba

Sent: 25 November 2012 19:44=


To: Stefan H=E5kansson LK
Cc: mmusic@ietf.org

Subject: Re: [MMUSIC] T.38 (=
Re:
M-line philosophy (Re: Wisdom sought: Prioritization of codecs))






 






Stefan said:






> I don't think this goes for fax, I think fax thes=
e
days is only used by 

> certain (few) organizations and only for certain types of communicatio=
n.

> 

> But if you think differently, please make a proposal on the rtcweb mai=
l
list!



[BA]  Given the steep decline in landlines, POTS is on the road to
becoming economically non-viable by the end of the decade, if not sooner.
  Once POTS shuts down, the legal and regulatory requirements which pr=
op
up the use of fax will need to be re-thought.  IMHO given the bleak fu=
ture
of fax, supporting it in WebRTC is not worth the effort. 



BTW, support for RFC 4733 (DTMF) is now required in draft-ietf-rtcweb-audio=
-01
instead of  RFC 4734 (Fax, Modem and Text Telephony) which was cited
(mistakenly) in -00.   



Bernard "Spent several hours debugging T.38 last week" Aboba=



















--_000_EDC0A1AE77C57744B664A310A0B23AE202D30E076BFRMRSSXCHMBSC_--

From internet-drafts@ietf.org  Mon Nov 26 02:26: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 886C821F852D; Mon, 26 Nov 2012 02:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYXQNHd68Pd2; Mon, 26 Nov 2012 02:26:00 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260EF21F8542; Mon, 26 Nov 2012 02:26:00 -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.36
Message-ID: <20121126102600.12367.11572.idtracker@ietfa.amsl.com>
Date: Mon, 26 Nov 2012 02:26:00 -0800
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-14.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 Nov 2012 10:26:00 -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 Wor=
king 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-14.txt
	Pages           : 37
	Date            : 2012-11-26

Abstract:
   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).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-14


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From Simo.Veikkolainen@nokia.com  Mon Nov 26 02: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 3008221F86AF for ; Mon, 26 Nov 2012 02:44:43 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjUvXhDYCRSk for ; Mon, 26 Nov 2012 02:44:42 -0800 (PST)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8F621F8546 for ; Mon, 26 Nov 2012 02:44:37 -0800 (PST)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAQAiYPU007493 for ; Mon, 26 Nov 2012 12:44:35 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 26 Nov 2012 12:44:34 +0200
Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.81]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0318.003; Mon, 26 Nov 2012 10:44:33 +0000
From: 
To: 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-14.txt
Thread-Index: AQHNy8CMlGxATDb9wECfygm1LWCwxpf77U7Q
Date: Mon, 26 Nov 2012 10:44:33 +0000
Message-ID: 
References: <20121126102600.12367.11572.idtracker@ietfa.amsl.com>
In-Reply-To: <20121126102600.12367.11572.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: NgLgUAGhIMVcmkVcu9QCA++pacJLza70eKLlXGeFvL9wKhXSy8cPmB1O7f+1g131u+p7XQQSY5M0SND5LfihhBYrZhjoBg4yTjrAyxi41KFt34p90fRgvTw/rje6DlPthefpgbMQ4+kqJbXHHwDQbHxThpbeGwXYlhODxaWz9hOkHiaW05Tu78tyA85pClrqvIzuqtRMw9/cPV14auGZV0aHAPxyGUxEggZ2hmkRkW6g6i7/udpleQVkQiPp2IBMOq9w0fCsNCm57y2mOuQxfw==
x-originating-ip: [172.21.81.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Nov 2012 10:44:34.0900 (UTC) FILETIME=[06566940:01CDCBC3]
X-Nokia-AV: Clean
Subject: [MMUSIC] FW:  I-D Action: draft-ietf-mmusic-sdp-cs-14.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 Nov 2012 10:44:43 -0000

Hello,

We have submitted a new version of the sdp-cs draft which now includes chan=
ges requested by Flemming for publication of the document:

- Typos corrected
- Clarified that codecs used should be those can be run natively on top of =
a CS bearer
- Allow visual separators in E.164 numbers (refer to 'global-number' in RFC=
 3966)
- Removed the pre-Nov 2008 copyright statement
- Modified the example so that "a=3Dcs-correlation" is a media level attrib=
ute
- Moved RFC3108 to be an informative reference

Regards,
Simo


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 ext internet-drafts@ietf.org
Sent: 26. marraskuuta 2012 12:26
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-14.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 Wor=
king 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-14.txt
	Pages           : 37
	Date            : 2012-11-26

Abstract:
   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).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-14


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From partha@parthasarathi.co.in  Mon Nov 26 09:12: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 EAC7C21F84E6 for ; Mon, 26 Nov 2012 09:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umQPJBLz5nkH for ; Mon, 26 Nov 2012 09:12:08 -0800 (PST)
Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id E731F21F84DE for ; Mon, 26 Nov 2012 09:12:07 -0800 (PST)
Received: from userPC (unknown [122.179.44.19]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 3847B19084E6;  Mon, 26 Nov 2012 17:12:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1353949927; bh=SCJ7T0lEdgThpzBSTVAb63DIEsg7J3XsTS9QJSIrHGE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WT+apUvWCak0olR/XoQ/IwpcnsRU9Ljwg2eQwdjxOTnveogGbRD2VVT2LY4KrLQfN qnseztHeXGzrHOjIWMVr+g9DFHrd0KLG48965D1whoLaeBKS6Fsvf49elJY0drbJr/ nq0xF9HWWXQ7a126pnF4TyFTUlJsfF6CVVs9PyRY=
From: "Parthasarathi R" 
To: 
References: <20121126074003.29289.99493.idtracker@ietfa.amsl.com>
In-Reply-To: <20121126074003.29289.99493.idtracker@ietfa.amsl.com>
Date: Mon, 26 Nov 2012 22:42:01 +0530
Message-ID: <000201cdcbf9$293496e0$7b9dc4a0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac3LqV1eOYig2v1iRcunmjAZMj4nZAATzCVQ
Content-Language: en-us
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A0C0202.50B3A2E7.00DA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-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 Nov 2012 17:12:09 -0000

Hi all,

Offer/Answer Considerations for G.723 Annex A and G.729 Annex B draft is
published with the change in the draft filename as
draft-ietf-mmusic-sdp-g723-g729-00.txt. As per IETF-84 discussion, there is
no open item in this revision of the draft. Could you please review and
provide your valuable experts comments for further progress.

Thanks
Partha & Muthu  

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Monday, November 26, 2012 1:10 PM
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g723-g729-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           : Offer/Answer Considerations for G.723 Annex A and
G.729 Annex B
	Author(s)       : Muthu Arul Mozhi Perumal
                          Parthasarathi Ravindran
	Filename        : draft-ietf-mmusic-sdp-g723-g729-00.txt
	Pages           : 8
	Date            : 2012-11-23

Abstract:
   RFC4856 describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the SDP offer and
   answer.  This document provides the offer/answer considerations for
   these parameters and updates RFC4856.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g723-g729

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g723-g729-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


From fluffy@cisco.com  Mon Nov 26 19:43: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 F2DD721F8892 for ; Mon, 26 Nov 2012 19:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level: 
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdZi1gyyCRxe for ; Mon, 26 Nov 2012 19:43:14 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 38B3521F882D for ; Mon, 26 Nov 2012 19:43:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1353987794; x=1355197394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DSSO4GjI7DCEZ7oUGnvID+e45NrHt2W4sHWDLRn8i1U=; b=BEMNfvC5FvpJYmUjAS0HgpN9Po/MrW1nXuJZFyZ/NLFi2eQ8cGzWuJs5 CZxBSbqegkIcUMr0t9DHHHmCbKPsXrVa4G3vHhg3NlhTkPolrgD3ze9++ Fj+sN0RyOR4FvwKaKXuHqMOHcuNBzL1E7zjLFgVCCVocL7sRlXceCT3ct A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAHg1tFCtJXG9/2dsb2JhbABEwCiBCYIeAQEBAwEBAQE3NAsFCwIBCA4UFBAnCyUCBA4FCId/BgyvfZA5jDcLg1VhA5cdjyiCYg2BaBce
X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146492486"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 27 Nov 2012 03:43:13 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAR3hDOB002466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 03:43:13 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 21:43:13 -0600
From: "Cullen Jennings (fluffy)" 
To: Hadriel Kaplan 
Thread-Topic: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
Thread-Index: AQHNzFFTam+OkTeU5ECaDR0mJjDgBw==
Date: Tue, 27 Nov 2012 03:43:13 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.167]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1808E6E8D5111E4D87537F8D396D5D01@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org \(E-mail\)" , "draft-ietf-mmusic-media-loopback@tools.ietf.org" , Gonzalo Camarillo 
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
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 Nov 2012 03:43:15 -0000

no


On Nov 20, 2012, at 11:16 , Hadriel Kaplan  wrote:

> Howdy,
> during IESG review of the media-loopback draft, a discussion arose regard=
ing the language around indicating media-loopback support per media descrip=
tion (i.e., per m-line), in sections 3.1 and 3.2.
>=20
> My interpretation/understanding was we were requiring ALL m-lines to indi=
cate media-loopback; in other words it's an all-or-nothing in both the offe=
r+answer, and either every media stream is looped back, or none are.  Howev=
er the text currently doesn't make this clear, and it could be argued eithe=
r way, with pro's/con's either way too; so I'd like the WG's consensus on w=
hether it should in fact be an all-or-none approach, or not.
>=20
> Please respond to this email by **Tuesday, December 4th** with a "YES" if=
 the draft should mandate ALL media be looped-back, or "NO" if it should al=
low a hybrid approach of some streams being looped while others are not.
>=20
> For reference, the draft is here:
> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24
>=20
> -hadriel
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From andrew.hutton@siemens-enterprise.com  Tue Nov 27 02:58:19 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 3E2E121F84DB for ; Tue, 27 Nov 2012 02:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAorlf8sw7sm for ; Tue, 27 Nov 2012 02:58:18 -0800 (PST)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7063421F84D9 for ; Tue, 27 Nov 2012 02:58:18 -0800 (PST)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 75E371EB8492; Tue, 27 Nov 2012 11:58:15 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 11:58:15 +0100
From: "Hutton, Andrew" 
To: Hadriel Kaplan , "mmusic@ietf.org (E-mail)" 
Thread-Topic: NEED WG CONSENSUS: media-loopback is all-or-nothing
Thread-Index: AQHNx0sa0Z8XaBiMtU6BXcD6oqpbWZf9jO/g
Date: Tue, 27 Nov 2012 10:58:15 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01370E96@MCHP04MSX.global-ad.net>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Gonzalo Camarillo , "draft-ietf-mmusic-media-loopback@tools.ietf.org" 
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
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 Nov 2012 10:58:19 -0000

NO.=20

I see no reason to mandate that all media is looped back.

Regards
Andy

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: 20 November 2012 18:16
> To: mmusic@ietf.org (E-mail)
> Cc: Gonzalo Camarillo; draft-ietf-mmusic-media-loopback@tools.ietf.org
> Subject: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
>=20
> Howdy,
> during IESG review of the media-loopback draft, a discussion arose
> regarding the language around indicating media-loopback support per
> media description (i.e., per m-line), in sections 3.1 and 3.2.
>=20
> My interpretation/understanding was we were requiring ALL m-lines to
> indicate media-loopback; in other words it's an all-or-nothing in both
> the offer+answer, and either every media stream is looped back, or none
> are.  However the text currently doesn't make this clear, and it could
> be argued either way, with pro's/con's either way too; so I'd like the
> WG's consensus on whether it should in fact be an all-or-none approach,
> or not.
>=20
> Please respond to this email by **Tuesday, December 4th** with a "YES"
> if the draft should mandate ALL media be looped-back, or "NO" if it
> should allow a hybrid approach of some streams being looped while
> others are not.
>=20
> For reference, the draft is here:
> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24
>=20
> -hadriel
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From enrico.marocco@telecomitalia.it  Wed Nov 28 01:00: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 7387F21F84CA for ; Wed, 28 Nov 2012 01:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.119
X-Spam-Level: 
X-Spam-Status: No, score=-101.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+dBNeLmhYc7 for ; Wed, 28 Nov 2012 01:00:51 -0800 (PST)
Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8560321F84EE for ; Wed, 28 Nov 2012 01:00:50 -0800 (PST)
Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 28 Nov 2012 10:00:45 +0100
Received: from MacLab.local (10.229.8.37) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.279.5; Wed, 28 Nov 2012 10:00:45 +0100
Message-ID: <50B5D2BC.6050702@telecomitalia.it>
Date: Wed, 28 Nov 2012 10:00:44 +0100
From: Enrico Marocco 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: 
References: 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030105020503030001040204"
X-TI-Disclaimer: Disclaimer1
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
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 Nov 2012 09:00:51 -0000

--------------ms030105020503030001040204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

No.

I see no compelling reason for introducing such a limitation, but a
bunch of cases where it breaks things badly. In interconnection
scenarios, for instance.

Enrico

On 11/20/12 7:16 PM, Hadriel Kaplan wrote:
> Howdy,
> during IESG review of the media-loopback draft, a discussion arose rega=
rding the language around indicating media-loopback support per media des=
cription (i.e., per m-line), in sections 3.1 and 3.2.
>=20
> My interpretation/understanding was we were requiring ALL m-lines to in=
dicate media-loopback; in other words it's an all-or-nothing in both the =
offer+answer, and either every media stream is looped back, or none are. =
 However the text currently doesn't make this clear, and it could be argu=
ed either way, with pro's/con's either way too; so I'd like the WG's cons=
ensus on whether it should in fact be an all-or-none approach, or not.
>=20
> Please respond to this email by **Tuesday, December 4th** with a "YES" =
if the draft should mandate ALL media be looped-back, or "NO" if it shoul=
d allow a hybrid approach of some streams being looped while others are n=
ot.
>=20
> For reference, the draft is here:
> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24
>=20
> -hadriel
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20



--------------ms030105020503030001040204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz
WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD
DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp
Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/
5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r
rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN
uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0
UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID
ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S
nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh
bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH
AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp
ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g
cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg
Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg
cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp
bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6
Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2
aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0
MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC
AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs
kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6
R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE
GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect
f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB
MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA
oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMjgw
OTAwNDRaMCMGCSqGSIb3DQEJBDEWBBTA/K48i6GqK244C0oBRbcz56HkETBsBgkqhkiG9w0B
CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE
AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T
dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn
BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAOLRtQRa45A7yRsEa5TbfodB/CXVtj2LZzSJln64Y
/toQAGXw5/gQ5sZIkUpXc5NFAFSVgdUFdpNYpJ2qDbGANNr8ZpzkDLCJdd/ANlDSAlKOxYRM
PdrJ6nod7My0Xggc3kug/gPdlRF0VVis97Pn6Rnq8Ek32JrpD/l5wvkDQkrwDXQ1QZNy0t4p
KK6pOhKHRNkDEvY7Jxps/BSpynYlU+gWzWerfQZfnLL0ClnYeEIa91p9QuVhYKrkslGtFLg+
w8Wjy5RTHTGoVftUKMSmyzif29V9paeuYfmLlP528VgkvlSEih14X7BHOt2C1kni+EUozPMo
RcYne1JlVDIxRgAAAAAAAA==
--------------ms030105020503030001040204--

From harald@alvestrand.no  Wed Nov 28 06:50: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 0054B21F887A for ; Wed, 28 Nov 2012 06:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhQdRVTWVnis for ; Wed, 28 Nov 2012 06:50:56 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2A021F859D for ; Wed, 28 Nov 2012 06:50:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DDC039E1C2 for ; Wed, 28 Nov 2012 15:50:54 +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 5kmbCWc-VMSM for ; Wed, 28 Nov 2012 15:50:52 +0100 (CET)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 985E039E056 for ; Wed, 28 Nov 2012 15:50:52 +0100 (CET)
Message-ID: <50B624CC.4010501@alvestrand.no>
Date: Wed, 28 Nov 2012 15:50:52 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mmusic 
Content-Type: multipart/alternative; boundary="------------000407040007040107030804"
Subject: [MMUSIC] M-lines: Wikifying it
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 Nov 2012 14:50:58 -0000

This is a multi-part message in MIME format.
--------------000407040007040107030804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Perhaps we can do some real work rather than just disagreeing on principles.

Perhaps the most contentious issue now is "what should an M-line be".
As far as I can tell, M-lines and their parameters describe 3 things:

- Properties of the transport flow / RTP session (Transport, or T for short)
- Properties that make sense to apply to an individual media stream, and 
may need to be different for different media streams in the same 
combined RTP session (Flow, or F for short)
- Properties that make sense to apply to all streams of a given type 
(Media, or M for short)

The properties that can be represented in M-lines are found in two IANA 
registries, both on
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:

- att-field (both session and media level)
- att-field (media level only)

I make it 179 entries in these categories, combined.

I see the same kind of work being necessary no matter which way we go:

- If we go with M-lines describing a whole RTP session (the MMT 
proposal), each property of the "F" class that we stil need needs to be 
copied onto a property in the "att-field (source level)" registry.

- If we go with M-lines describing groups of media streams, degenerating 
to a single media stream in the case of using "a=inactive" for stream 
muting (the BUNDLE and TOGETHER proposals), each property of the "T" 
class needs to be described as "MUST have consistent values for all the 
combined M-lines", "MUST be taken only from the first M-line in the 
bundle argument", or "must get special treatment".

- In both cases, the "M"-class lines don't need any special treatment. 
They just need to be present in all the M-lines where they're relevant.

I've created a spreadsheet here:

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for 
"necessary" and 0 for "will never matter").

Anyone should be able to write it.
If a few of us do a quick job of markup on it, I think we should be able 
to have a more realistic assessment in a few days.

I've started, but much of this is unknown to me. Can others help?

                       Harald






--------------000407040007040107030804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Perhaps we can do some real work rather than just disagreeing on
    principles.

    

    Perhaps the most contentious issue now is "what should an M-line
    be".

    As far as I can tell, M-lines and their parameters describe 3
    things:

    

    - Properties of the transport flow / RTP session (Transport, or T
    for short)

    - Properties that make sense to apply to an individual media stream,
    and may need to be different for different media streams in the same
    combined RTP session (Flow, or F for short)

    - Properties that make sense to apply to all streams of a given type
    (Media, or M for short)

    

    The properties that can be represented in M-lines are found in two
    IANA registries, both on

    
    http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:

    

    - att-field (both session and media level)

    - att-field (media level only)

    

    I make it 179 entries in these categories, combined.

    

    I see the same kind of work being necessary no matter which way we
    go:

    

    - If we go with M-lines describing a whole RTP session (the MMT
    proposal), each property of the "F" class that we stil need needs to
    be copied onto a property in the "att-field (source level)"
    registry.

    

    - If we go with M-lines describing groups of media streams,
    degenerating to a single media stream in the case of using
    "a=inactive" for stream muting (the BUNDLE and TOGETHER proposals),
    each property of the "T" class needs to be described as "MUST have
    consistent values for all the combined M-lines", "MUST be taken only
    from the first M-line in the bundle argument", or "must get special
    treatment".

    

    - In both cases, the "M"-class lines don't need any special
    treatment. They just need to be present in all the M-lines where
    they're relevant.

    

    I've created a spreadsheet here:

    

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

    

    with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for
    "necessary" and 0 for "will never matter").

    

    Anyone should be able to write it.

    If a few of us do a quick job of markup on it, I think we should be
    able to have a more realistic assessment in a few days.

    

    I've started, but much of this is unknown to me. Can others help?

    

                          Harald

    

    

    

    

    

  


--------------000407040007040107030804--

From jonathan@vidyo.com  Wed Nov 28 08:29: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 8C9CE21F84BC for ; Wed, 28 Nov 2012 08:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRTM46dsf3r9 for ; Wed, 28 Nov 2012 08:29:55 -0800 (PST)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2274921F849A for ; Wed, 28 Nov 2012 08:29:55 -0800 (PST)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id ACF88798279; Wed, 28 Nov 2012 11:04:38 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EAF6B798176; Wed, 28 Nov 2012 11:04:34 -0500 (EST)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Wed, 28 Nov 2012 11:29:32 -0500
From: Jonathan Lennox 
To: Harald Alvestrand , mmusic 
Date: Wed, 28 Nov 2012 11:29:47 -0500
Thread-Topic: [MMUSIC] M-lines: Wikifying it
Thread-Index: Ac3Ng8P3GkOWi5lkRxWEzeqsnUq8/AAAA5Jg
Message-ID: 
References: <50B624CC.4010501@alvestrand.no>
In-Reply-To: <50B624CC.4010501@alvestrand.no>
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_C3759687E4991243A1A0BD44EAC823034DFAC1FAA9BE235maillan_"
MIME-Version: 1.0
Subject: Re: [MMUSIC] M-lines: Wikifying it
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 Nov 2012 16:29:57 -0000

--_000_C3759687E4991243A1A0BD44EAC823034DFAC1FAA9BE235maillan_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Harald -

I think this is a good starting point, though I think things are somewhat m=
ore complicated than you've described.

First of all, for the SHIM approaches, you need to separate Transport param=
eters (e.g. ICE candidates) from Session parameters (e.g., SRTP keying).  T=
his isn't relevant for Bundle/MMT, but as long as we're doing the work it m=
ight as well be done completely.

More significantly, I think, a number of parameters actually fall into mult=
iple categories depending on how they're used.  For example, rtcp-fb is Tra=
nsport (or, if you believe my previous argument, Session) when the rtcp-fb-=
pt field is "*", but it's Media when a specific payload type is given.

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, November 28, 2012 9:51 AM
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

Perhaps we can do some real work rather than just disagreeing on principles=
.

Perhaps the most contentious issue now is "what should an M-line be".
As far as I can tell, M-lines and their parameters describe 3 things:

- Properties of the transport flow / RTP session (Transport, or T for short=
)
- Properties that make sense to apply to an individual media stream, and ma=
y need to be different for different media streams in the same combined RTP=
 session (Flow, or F for short)
- Properties that make sense to apply to all streams of a given type (Media=
, or M for short)

The properties that can be represented in M-lines are found in two IANA reg=
istries, both on
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:

- att-field (both session and media level)
- att-field (media level only)

I make it 179 entries in these categories, combined.

I see the same kind of work being necessary no matter which way we go:

- If we go with M-lines describing a whole RTP session (the MMT proposal), =
each property of the "F" class that we stil need needs to be copied onto a =
property in the "att-field (source level)" registry.

- If we go with M-lines describing groups of media streams, degenerating to=
 a single media stream in the case of using "a=3Dinactive" for stream mutin=
g (the BUNDLE and TOGETHER proposals), each property of the "T" class needs=
 to be described as "MUST have consistent values for all the combined M-lin=
es", "MUST be taken only from the first M-line in the bundle argument", or =
"must get special treatment".

- In both cases, the "M"-class lines don't need any special treatment. They=
 just need to be present in all the M-lines where they're relevant.

I've created a spreadsheet here:

https://docs.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVG=
NV9lUFI3cHlIRFE

with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for "necessar=
y" and 0 for "will never matter").

Anyone should be able to write it.
If a few of us do a quick job of markup on it, I think we should be able to=
 have a more realistic assessment in a few days.

I've started, but much of this is unknown to me. Can others help?

                      Harald





--_000_C3759687E4991243A1A0BD44EAC823034DFAC1FAA9BE235maillan_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Hi, Harald –
=
 
I think this is a g=
ood starting point, though I think things are somewhat more complicated tha=
n you’ve described.
=
 
First of all, for t=
he SHIM approaches, you need to separate Transport parameters (e.g. ICE can=
didates) from Session parameters (e.g., SRTP keying).  This isn’=
t relevant for Bundle/MMT, but as long as we’re doing the work it mig=
ht as well be done completely.
 
More significa=
ntly, I think, a number of parameters actually fall into multiple categorie=
s depending on how they’re used.  For example, rtcp-fb is Transp=
ort (or, if you believe my previous argument, Session) when the rtcp-fb-pt =
field is “*”, but it’s Media when a specific payload type=
 is given.
 
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent:=
 Wednesday, November 28, 2012 9:51 AM
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it
 
Perhaps we can do some real work rather than just disagreeing on=
 principles.

Perhaps the most contentious issue now is "what sh=
ould an M-line be".
As far as I can tell, M-lines and their paramet=
ers describe 3 things:

- Properties of the transport flow / RTP sess=
ion (Transport, or T for short)
- Properties that make sense to apply to=
 an individual media stream, and may need to be different for different med=
ia streams in the same combined RTP session (Flow, or F for short)
- Pro=
perties that make sense to apply to all streams of a given type (Media, or =
M for short)

The properties that can be represented in M-lines are f=
ound in two IANA registries, both on
http://www.iana.org/assignments/=
sdp-parameters/sdp-parameters.xml:

- att-field (both session and=
 media level)
- att-field (media level only)

I make it 179 entrie=
s in these categories, combined.

I see the same kind of work being n=
ecessary no matter which way we go:

- If we go with M-lines describi=
ng a whole RTP session (the MMT proposal), each property of the "F&quo=
t; class that we stil need needs to be copied onto a property in the "=
att-field (source level)" registry.

- If we go with M-lines des=
cribing groups of media streams, degenerating to a single media stream in t=
he case of using "a=3Dinactive" for stream muting (the BUNDLE and=
 TOGETHER proposals), each property of the "T" class needs to be =
described as "MUST have consistent values for all the combined M-lines=
", "MUST be taken only from the first M-line in the bundle argume=
nt", or "must get special treatment".

- In both cases=
, the "M"-class lines don't need any special treatment. They just=
 need to be present in all the M-lines where they're relevant.

I've =
created a spreadsheet here:

https://docs=
.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlI=
RFE

with 2 extra columns: "Class" (M, F or T) and &quo=
t;Importance" (1 for "necessary" and 0 for "will never =
matter").

Anyone should be able to write it.
If a few of us =
do a quick job of markup on it, I think we should be able to have a more re=
alistic assessment in a few days.

I've started, but much of this is =
unknown to me. Can others help?

      =
            &nb=
sp;   Harald




=

--_000_C3759687E4991243A1A0BD44EAC823034DFAC1FAA9BE235maillan_--

From pkyzivat@alum.mit.edu  Wed Nov 28 12:13: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 E731621F8857 for ; Wed, 28 Nov 2012 12:13:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.087
X-Spam-Level: 
X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYGT-t8V4usp for ; Wed, 28 Nov 2012 12:13:06 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id EC28421F886E for ; Wed, 28 Nov 2012 12:13:05 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id V1Wf1k0041uE5Es548D4t0; Wed, 28 Nov 2012 20:13:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id V8D41k00P3ZTu2S3c8D4Q2; Wed, 28 Nov 2012 20:13:04 +0000
Message-ID: <50B6704F.2000108@alum.mit.edu>
Date: Wed, 28 Nov 2012 15:13:03 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50B624CC.4010501@alvestrand.no>
In-Reply-To: <50B624CC.4010501@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354133584; bh=ayUv8jw8DdTF8+VD9nOdeWTHwziiCVeaF7Z1BgB18pM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SlIEpI4FR48puygTGGTd9uUfxIhaOsycprKEJupTlzkVaI1EvIesRb6/9sIFAI5xd S8zxCIcPyJe514iyKCa8SuC09SaMuh8KXU8HAeY0pFikP1+KCNQyxADyZM2pL5GRB4 RIrGG8nnbwm7qBdUQ2nRo8xTF9KI0owbtfIg5bmesRL7iQq1Xy8kUjsZQsodJKGYw2 YWHHeTMBCLxV/nTeF1FfPzZMGdJvGvAHTVHOq4VeHAYYQiDF6fXVyUHzTDZiOwUOdf +EI50qKD1ruRfqQbnCu4/mLZD/q/6eEYqF0BokXA2Gs0uk/syYeX/KDxx6QxlInVaD 7VuGEwF73aDzw==
Subject: Re: [MMUSIC] M-lines: Wikifying it
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 Nov 2012 20:13:13 -0000

Inline

On 11/28/12 9:50 AM, Harald Alvestrand wrote:
> Perhaps we can do some real work rather than just disagreeing on principles.
>
> Perhaps the most contentious issue now is "what should an M-line be".
> As far as I can tell, M-lines and their parameters describe 3 things:
>
> - Properties of the transport flow / RTP session (Transport, or T for short)
> - Properties that make sense to apply to an individual media stream, and
> may need to be different for different media streams in the same
> combined RTP session (Flow, or F for short)
> - Properties that make sense to apply to all streams of a given type
> (Media, or M for short)
>
> The properties that can be represented in M-lines are found in two IANA
> registries, both on
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:
>
> - att-field (both session and media level)
> - att-field (media level only)
>
> I make it 179 entries in these categories, combined.
>
> I see the same kind of work being necessary no matter which way we go:
>
> - If we go with M-lines describing a whole RTP session (the MMT
> proposal), each property of the "F" class that we stil need needs to be
> copied onto a property in the "att-field (source level)" registry.
>
> - If we go with M-lines describing groups of media streams, degenerating
> to a single media stream in the case of using "a=inactive" for stream
> muting (the BUNDLE and TOGETHER proposals), each property of the "T"
> class needs to be described as "MUST have consistent values for all the
> combined M-lines", "MUST be taken only from the first M-line in the
> bundle argument", or "must get special treatment".
>
> - In both cases, the "M"-class lines don't need any special treatment.
> They just need to be present in all the M-lines where they're relevant.
>
> I've created a spreadsheet here:
>
> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE
>
> with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for
> "necessary" and 0 for "will never matter").
>
> Anyone should be able to write it.
> If a few of us do a quick job of markup on it, I think we should be able
> to have a more realistic assessment in a few days.
>
> I've started, but much of this is unknown to me. Can others help?

Don't forget the media formats listed in the m-line itself. The meaning 
of these depends on the  param. The focus of this discussion is 
on those  values that correspond to various flavors of RTP. There 
are a bunch of  values that don't correspond to RTP, and that 
assign different meanings to the format parameters.

AFAIK, of the currently defined proto values only the RTP-related ones 
have the notion of multiple flows within the session. But the sdp 
extensions for SCTP media are currently being defined. That certainly 
has the potential to be considered as multiple flows, and should be 
considered in this discussion.

For RTP transports, the formats are payload type numbers, and these are 
mapped to actual formats (codecs) via a=rtpmap. I see that you have 
proposed that rtpmap be per-media, not transport or flow. I guess this 
means that the same payload type number could mean one thing for all 
audio flows over the transport, and something different for all video 
flows over the same transport. But the payload numbers to be used 
(specified on the m-line) is negotiated in O/A. How would that work for 
audio vs. video? ISTM it would be preferred to negotiate payload numbers 
and types independently per flow.

Regarding the "importance" column in the table: I don't understand how 
you have assigned values. In what frame of reference is importance to be 
assessed?

Regarding a=label: This could be any of T/F/M, depending on application 
use. I think we must assume T, and consider an alternative for F. (And 
for M if we think it is needed.)

(I'm not convinced we need to identify an "M" scope distinct from T and F.)

	Thanks,
	Paul

From harald@alvestrand.no  Wed Nov 28 12:25: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 32EB721F899D for ; Wed, 28 Nov 2012 12:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqf69yfX6Y8y for ; Wed, 28 Nov 2012 12:24:59 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AA12F21F86B9 for ; Wed, 28 Nov 2012 12:24:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F150039E1C2; Wed, 28 Nov 2012 21:24:56 +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 fq9fjf+56Rs6; Wed, 28 Nov 2012 21:24:54 +0100 (CET)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B4A5239E056; Wed, 28 Nov 2012 21:24:54 +0100 (CET)
Message-ID: <50B67316.9030200@alvestrand.no>
Date: Wed, 28 Nov 2012 21:24:54 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jonathan Lennox 
References: <50B624CC.4010501@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060501040009080601000304"
Cc: mmusic 
Subject: Re: [MMUSIC] M-lines: Wikifying it
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 Nov 2012 20:25:01 -0000

This is a multi-part message in MIME format.
--------------060501040009080601000304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/28/2012 05:29 PM, Jonathan Lennox wrote:
>
> Hi, Harald --
>
> I think this is a good starting point, though I think things are 
> somewhat more complicated than you've described.
>
> First of all, for the SHIM approaches, you need to separate Transport 
> parameters (e.g. ICE candidates) from Session parameters (e.g., SRTP 
> keying).  This isn't relevant for Bundle/MMT, but as long as we're 
> doing the work it might as well be done completely.
>
Yes, if we do SHIM, they're different. Good point! Will you update the 
header for that?
(I tend to forget SHIM)
>
> More significantly, I think, a number of parameters actually fall into 
> multiple categories depending on how they're used.  For example, 
> rtcp-fb is Transport (or, if you believe my previous argument, 
> Session) when the rtcp-fb-pt field is "*", but it's Media when a 
> specific payload type is given.
>
That means we'll have to make 2 lines for it. I suspect it's not the 
only one.

> *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *Sent:* Wednesday, November 28, 2012 9:51 AM
> *To:* mmusic
> *Subject:* [MMUSIC] M-lines: Wikifying it
>
> Perhaps we can do some real work rather than just disagreeing on 
> principles.
>
> Perhaps the most contentious issue now is "what should an M-line be".
> As far as I can tell, M-lines and their parameters describe 3 things:
>
> - Properties of the transport flow / RTP session (Transport, or T for 
> short)
> - Properties that make sense to apply to an individual media stream, 
> and may need to be different for different media streams in the same 
> combined RTP session (Flow, or F for short)
> - Properties that make sense to apply to all streams of a given type 
> (Media, or M for short)
>
> The properties that can be represented in M-lines are found in two 
> IANA registries, both on
> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:
>
> - att-field (both session and media level)
> - att-field (media level only)
>
> I make it 179 entries in these categories, combined.
>
> I see the same kind of work being necessary no matter which way we go:
>
> - If we go with M-lines describing a whole RTP session (the MMT 
> proposal), each property of the "F" class that we stil need needs to 
> be copied onto a property in the "att-field (source level)" registry.
>
> - If we go with M-lines describing groups of media streams, 
> degenerating to a single media stream in the case of using 
> "a=inactive" for stream muting (the BUNDLE and TOGETHER proposals), 
> each property of the "T" class needs to be described as "MUST have 
> consistent values for all the combined M-lines", "MUST be taken only 
> from the first M-line in the bundle argument", or "must get special 
> treatment".
>
> - In both cases, the "M"-class lines don't need any special treatment. 
> They just need to be present in all the M-lines where they're relevant.
>
> I've created a spreadsheet here:
>
> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE
>
> with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for 
> "necessary" and 0 for "will never matter").
>
> Anyone should be able to write it.
> If a few of us do a quick job of markup on it, I think we should be 
> able to have a more realistic assessment in a few days.
>
> I've started, but much of this is unknown to me. Can others help?
>
>                       Harald
>
>
>
>


--------------060501040009080601000304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 11/28/2012 05:29 PM, Jonathan Lennox
      wrote:

    

    

      
      
      
      

        
Hi,
            Harald –

        
 

        
I
            think this is a good starting point, though I think things
            are somewhat more complicated than you’ve described.

        
 

        
First
            of all, for the SHIM approaches, you need to separate
            Transport parameters (e.g. ICE candidates) from Session
            parameters (e.g., SRTP keying).  This isn’t relevant for
            Bundle/MMT, but as long as we’re doing the work it might as
            well be done completely.

      

    

    Yes, if we do SHIM, they're different. Good point! Will you update
    the header for that?

    (I tend to forget SHIM)

    

      

        

        
 

        
More
            significantly, I think, a number of parameters actually fall
            into multiple categories depending on how they’re used.  For
            example, rtcp-fb is Transport (or, if you believe my
            previous argument, Session) when the rtcp-fb-pt field is
            “*”, but it’s Media when a specific payload type is given.

      

    

    That means we'll have to make 2 lines for it. I suspect it's not the
    only one.

    

    

      

        

        
 

        

          

            
From:
                Harald Alvestrand [mailto:harald@alvestrand.no] 

                Sent: Wednesday, November 28, 2012 9:51 AM

                To: mmusic

                Subject: [MMUSIC] M-lines: Wikifying it

          

        

        
 

        
Perhaps we can
          do some real work rather than just disagreeing on principles.

          

          Perhaps the most contentious issue now is "what should an
          M-line be".

          As far as I can tell, M-lines and their parameters describe 3
          things:

          

          - Properties of the transport flow / RTP session (Transport,
          or T for short)

          - Properties that make sense to apply to an individual media
          stream, and may need to be different for different media
          streams in the same combined RTP session (Flow, or F for
          short)

          - Properties that make sense to apply to all streams of a
          given type (Media, or M for short)

          

          The properties that can be represented in M-lines are found in
          two IANA registries, both on

          http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:

          

          - att-field (both session and media level)

          - att-field (media level only)

          

          I make it 179 entries in these categories, combined.

          

          I see the same kind of work being necessary no matter which
          way we go:

          

          - If we go with M-lines describing a whole RTP session (the
          MMT proposal), each property of the "F" class that we stil
          need needs to be copied onto a property in the "att-field
          (source level)" registry.

          

          - If we go with M-lines describing groups of media streams,
          degenerating to a single media stream in the case of using
          "a=inactive" for stream muting (the BUNDLE and TOGETHER
          proposals), each property of the "T" class needs to be
          described as "MUST have consistent values for all the combined
          M-lines", "MUST be taken only from the first M-line in the
          bundle argument", or "must get special treatment".

          

          - In both cases, the "M"-class lines don't need any special
          treatment. They just need to be present in all the M-lines
          where they're relevant.

          

          I've created a spreadsheet here:

          

          https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

          

          with 2 extra columns: "Class" (M, F or T) and "Importance" (1
          for "necessary" and 0 for "will never matter").

          

          Anyone should be able to write it.

          If a few of us do a quick job of markup on it, I think we
          should be able to have a more realistic assessment in a few
          days.

          

          I've started, but much of this is unknown to me. Can others
          help?

          

                                Harald

          

          

          

          

          

      

    

    

  


--------------060501040009080601000304--

From bill.wu@huawei.com  Wed Nov 28 16:54: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 75B3221F8946 for ; Wed, 28 Nov 2012 16:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.546
X-Spam-Level: 
X-Spam-Status: No, score=-4.546 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCsSqWKN20FS for ; Wed, 28 Nov 2012 16:54:46 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9411E809B for ; Wed, 28 Nov 2012 16:54:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANH72719; Thu, 29 Nov 2012 00:54:41 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 00:54:15 +0000
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 00:54:25 +0000
Received: from w53375 (10.138.41.149) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 08:54:23 +0800
Message-ID: 
From: Qin Wu 
To: Hadriel Kaplan 
References:  
Date: Thu, 29 Nov 2012 08:54:22 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: mmusic@ietf.org, draft-ietf-mmusic-media-loopback@tools.ietf.org, Gonzalo Camarillo 
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
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, 29 Nov 2012 00:54:46 -0000

Tm8sDQpJIHNlZSBpdCB3aWxsIGJlIG1vcmUgZmxleGlibGUgdG8gYWxsb3cgc29tZSBiZWluZyBs
b29wZWQgYmFjayB3aGlsZSBzb21lIG5vdC4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdp
bmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIiA8Zmx1
ZmZ5QGNpc2NvLmNvbT4NClRvOiAiSGFkcmllbCBLYXBsYW4iIDxIS2FwbGFuQGFjbWVwYWNrZXQu
Y29tPg0KQ2M6IDxtbXVzaWNAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1tbXVzaWMtbWVkaWEtbG9v
cGJhY2tAdG9vbHMuaWV0Zi5vcmc+OyAiR29uemFsbyBDYW1hcmlsbG8iIDxnb256YWxvLmNhbWFy
aWxsb0Blcmljc3Nvbi5jb20+DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMiAxMTo0
MyBBTQ0KU3ViamVjdDogUmU6IFtNTVVTSUNdIE5FRUQgV0cgQ09OU0VOU1VTOiBtZWRpYS1sb29w
YmFjayBpcyBhbGwtb3Itbm90aGluZw0KDQoNCj4gDQo+IG5vDQo+IA0KPiANCj4gT24gTm92IDIw
LCAyMDEyLCBhdCAxMToxNiAsIEhhZHJpZWwgS2FwbGFuIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29t
PiB3cm90ZToNCj4gDQo+PiBIb3dkeSwNCj4+IGR1cmluZyBJRVNHIHJldmlldyBvZiB0aGUgbWVk
aWEtbG9vcGJhY2sgZHJhZnQsIGEgZGlzY3Vzc2lvbiBhcm9zZSByZWdhcmRpbmcgdGhlIGxhbmd1
YWdlIGFyb3VuZCBpbmRpY2F0aW5nIG1lZGlhLWxvb3BiYWNrIHN1cHBvcnQgcGVyIG1lZGlhIGRl
c2NyaXB0aW9uIChpLmUuLCBwZXIgbS1saW5lKSwgaW4gc2VjdGlvbnMgMy4xIGFuZCAzLjIuDQo+
PiANCj4+IE15IGludGVycHJldGF0aW9uL3VuZGVyc3RhbmRpbmcgd2FzIHdlIHdlcmUgcmVxdWly
aW5nIEFMTCBtLWxpbmVzIHRvIGluZGljYXRlIG1lZGlhLWxvb3BiYWNrOyBpbiBvdGhlciB3b3Jk
cyBpdCdzIGFuIGFsbC1vci1ub3RoaW5nIGluIGJvdGggdGhlIG9mZmVyK2Fuc3dlciwgYW5kIGVp
dGhlciBldmVyeSBtZWRpYSBzdHJlYW0gaXMgbG9vcGVkIGJhY2ssIG9yIG5vbmUgYXJlLiAgSG93
ZXZlciB0aGUgdGV4dCBjdXJyZW50bHkgZG9lc24ndCBtYWtlIHRoaXMgY2xlYXIsIGFuZCBpdCBj
b3VsZCBiZSBhcmd1ZWQgZWl0aGVyIHdheSwgd2l0aCBwcm8ncy9jb24ncyBlaXRoZXIgd2F5IHRv
bzsgc28gSSdkIGxpa2UgdGhlIFdHJ3MgY29uc2Vuc3VzIG9uIHdoZXRoZXIgaXQgc2hvdWxkIGlu
IGZhY3QgYmUgYW4gYWxsLW9yLW5vbmUgYXBwcm9hY2gsIG9yIG5vdC4NCj4+IA0KPj4gUGxlYXNl
IHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBieSAqKlR1ZXNkYXksIERlY2VtYmVyIDR0aCoqIHdpdGgg
YSAiWUVTIiBpZiB0aGUgZHJhZnQgc2hvdWxkIG1hbmRhdGUgQUxMIG1lZGlhIGJlIGxvb3BlZC1i
YWNrLCBvciAiTk8iIGlmIGl0IHNob3VsZCBhbGxvdyBhIGh5YnJpZCBhcHByb2FjaCBvZiBzb21l
IHN0cmVhbXMgYmVpbmcgbG9vcGVkIHdoaWxlIG90aGVycyBhcmUgbm90Lg0KPj4gDQo+PiBGb3Ig
cmVmZXJlbmNlLCB0aGUgZHJhZnQgaXMgaGVyZToNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtbW11c2ljLW1lZGlhLWxvb3BiYWNrLTI0DQo+PiANCj4+IC1oYWRyaWVs
DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+IA0KPiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0
DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL21tdXNpYw==


From nikosietf@gmail.com  Thu Nov 29 06:09: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 6A4C021F89DE for ; Thu, 29 Nov 2012 06:09:08 -0800 (PST)
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=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zxzKjHatdrW for ; Thu, 29 Nov 2012 06:09:07 -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 CC61321F89DC for ; Thu, 29 Nov 2012 06:09:06 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id r3so4794888wey.31 for ; Thu, 29 Nov 2012 06:09:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=1uKlTocuIX+4IfK+w3phA1bpnwNX0erLXTrsUu0wq/0=; b=kDlgw+zy2lmmkgnATVtHQjAZVjSqdF/PTBrSiljOJfsYNL2EZ09wGrRHsLgQC6UFmO qFfZkA8x8LJkZGSi5Wz04UZhgPDYUTMatXw9BhSEYb8Ow/+qEvx0mowys/z7GWk98h74 3dN97LnHZtOOubPvZooS/MN1BFEnWXqw0roGJp4rjZyKGsE5+eItByxCq/YbJpMyTdbf D3VYD0+rlxEUaCEyDfodN/7XVqbV3/pOgLFKWYjepViakK7duYvEBfgi/V0xGyKKcxFe hPi0PFukuMnq2S/zF9g0iXNUvJfJ7bD7WojWoeAyvGaLsXPnmQ8wvEiEQrIhkqd/o84w q4vg==
Received: by 10.216.226.10 with SMTP id a10mr9450380weq.35.1354198145961; Thu, 29 Nov 2012 06:09:05 -0800 (PST)
Received: from oteglobePC ([62.75.1.42]) by mx.google.com with ESMTPS id g2sm2568328wiy.0.2012.11.29.06.09.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 06:09:04 -0800 (PST)
From: "Nikos Leontsinis" 
To: "'Qin Wu'" , "'Hadriel Kaplan'" 
References:   
In-Reply-To: 
Date: Thu, 29 Nov 2012 16:09:05 +0200
Message-ID: <004e01cdce3b$195f4a00$4c1dde00$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGmyTljJD8TQy67c5LTgwtkknPsqgKIjY67AosXBx2YJkZx4A==
Content-Language: el
Cc: mmusic@ietf.org, draft-ietf-mmusic-media-loopback@tools.ietf.org, 'Gonzalo Camarillo' 
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing
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, 29 Nov 2012 14:09:08 -0000

No for scalability reasons

/nikos

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Qin Wu
Sent: Thursday, November 29, 2012 2:54 AM
To: Hadriel Kaplan
Cc: mmusic@ietf.org; draft-ietf-mmusic-media-loopback@tools.ietf.org;
Gonzalo Camarillo
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing

No,
I see it will be more flexible to allow some being looped back while some
not.

Regards!
-Qin
----- Original Message ----- 
From: "Cullen Jennings (fluffy)" 
To: "Hadriel Kaplan" 
Cc: ; ;
"Gonzalo Camarillo" 
Sent: Tuesday, November 27, 2012 11:43 AM
Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing


> 
> no
> 
> 
> On Nov 20, 2012, at 11:16 , Hadriel Kaplan  wrote:
> 
>> Howdy,
>> during IESG review of the media-loopback draft, a discussion arose
regarding the language around indicating media-loopback support per media
description (i.e., per m-line), in sections 3.1 and 3.2.
>> 
>> My interpretation/understanding was we were requiring ALL m-lines to
indicate media-loopback; in other words it's an all-or-nothing in both the
offer+answer, and either every media stream is looped back, or none are.
However the text currently doesn't make this clear, and it could be argued
either way, with pro's/con's either way too; so I'd like the WG's consensus
on whether it should in fact be an all-or-none approach, or not.
>> 
>> Please respond to this email by **Tuesday, December 4th** with a "YES" if
the draft should mandate ALL media be looped-back, or "NO" if it should
allow a hybrid approach of some streams being looped while others are not.
>> 
>> For reference, the draft is here:
>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24
>> 
>> -hadriel
>> 
>> _______________________________________________
>> 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