From harald@alvestrand.no Fri Nov 1 02:00:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9A121E80C5 for ; Fri, 1 Nov 2013 02:00:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCXAxoh-Qfga for ; Fri, 1 Nov 2013 02:00:33 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4023811E82E7 for ; Fri, 1 Nov 2013 02:00:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD3E439E516 for ; Fri, 1 Nov 2013 10:00:25 +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 gNvtKo5zXDUY for ; Fri, 1 Nov 2013 10:00:23 +0100 (CET) Received: from [172.16.6.227] (unknown [195.70.5.235]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B699F39E0C8 for ; Fri, 1 Nov 2013 10:00:23 +0100 (CET) Message-ID: <52736DA6.4010102@alvestrand.no> Date: Fri, 01 Nov 2013 10:00:22 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5270B191.9030603@alvestrand.no> <527119EA.2030005@alum.mit.edu> In-Reply-To: <527119EA.2030005@alum.mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updated MSID 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, 01 Nov 2013 09:00:37 -0000 On 10/30/2013 03:38 PM, Paul Kyzivat wrote: > A few comments about this version. Actually the comments aren't > specific to this revision, but they relate to things I didn't notice > earlier. > > Msid-Semantic syntax: > > attribute =/ msid-semantic-attr > msid-semantic-attr = "msid-semantic:" token (" " identifier)* > token = > > The usage of "*" is backward. (Following regex syntax rather than abnf > syntax). This ought to be: > > attribute =/ msid-semantic-attr > msid-semantic-attr = "msid-semantic:" token *(" " identifier) > token = Thanks! > > Just following that: > > The semantic field may hold values from the IANA registries > "Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the > "group" SDP Attribute". > > I have a couple of issues with this: > > Section 5 defines a new registry "Semantics for the msid-semantic SDP > attribute", and defines a new semantic "WMS" in it. The text above > doesn't even reference this registry. Yep, that section needs to be re-thought. The SSRC-group registry is now irrelevant, since we don't do things on SSRC any more. > > Because the two mentioned registries are independent, AFAIK there is > no guarantee that they couldn't someday contain different definitions > for the same "semantic" name. Then, if that name were used with msid > the proper definition to use would be ambiguous. (I realize this is > implausible, but nothing prevents it.) IMO the *right* answer would be > to merge all these grouping semantics into a single table. But that is > a hassle right now. Perhaps it would be sufficient to say that only > semantics that are uniquely defined across all of these tables may be > used with msid. E.g., > > The semantic field may hold any value that is uniquely defined > in one and only one of the IANA registries "Semantics for the > msid-semantic SDP attribute", "Semantics for the "ssrc-group" > SDP Attribute" and "Semantics for the "group" SDP Attribute". That would work - it should then ask IANA to update the instructions for those registries to disallow the registration of new values with conflicts between them. This effectively turns them into one registry... > > Thanks, > Paul > > On 10/30/13 3:13 AM, Harald Alvestrand wrote: >> Roni and Flemming pointed out that I hadn't managed to submit the fixes >> I made to -msid after the reviews of -01 before the deadline, and had >> even managed to forget to send it to the list. >> >> I had missed a number of occurences where "SSRC" needed to be changed to >> "m-line" in the text (with some more adjustments to language around >> that). >> >> Here it is. I'll submit it on Monday, when the I-D repository reopens. >> >> >> >> _______________________________________________ >> 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 -- Surveillance is pervasive. Go Dark. From magnus.westerlund@ericsson.com Fri Nov 1 06:34:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B3611E8357 for ; Fri, 1 Nov 2013 06:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.443 X-Spam-Level: X-Spam-Status: No, score=-105.443 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEUQlAuibr+J for ; Fri, 1 Nov 2013 06:34:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB111E831D for ; Fri, 1 Nov 2013 06:28:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-02-5273ac70498a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 26.FD.23787.07CA3725; Fri, 1 Nov 2013 14:28:16 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Fri, 1 Nov 2013 14:28:15 +0100 Message-ID: <5273ACB5.2020201@ericsson.com> Date: Fri, 1 Nov 2013 14:29:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Harald Alvestrand , mmusic References: <5270B191.9030603@alvestrand.no> In-Reply-To: <5270B191.9030603@alvestrand.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RrdgTXGQwZSrYhbH+rrYLKYuf8zi wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGV0zVrGWDBftaLv6C62BsYvsl2MnBwSAiYS J6eeY4GwxSQu3FvP1sXIxSEkcIhR4uqF7ywQzjJGidNTvzGBVPEKaEusWPmJGcRmEVCRuHN5 KiuIzSZgIXHzRyMbiC0qECxxY9khNoh6QYmTM5+AbRARcJM4Nm89WFxYQEPi6dP5YDOFBHQk vr39yAhicwroSqzpXAlUwwF0kbhET2MQSJhZQE9iytUWRghbXqJ562xmiFZtiYamDtYJjIKz kGybhaRlFpKWBYzMqxjZcxMzc9LLDTcxAkPy4JbfujsYT50TOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGHM29KW6dfSsO+rLWeP37vtjLO8Cj0TkgK/fgReGNq5MM Glij26a4NbWJnUj7O23LrM8ODZM0dpoGfc0XiLh+9OmLVAeZFS9n3Jky9VsHQ8/VyOwverOe HUtkFq5RuhisUr943pZ957gTC4Msb0xw8bfYsjZsy5zI6OSXBdfqHlr/dhR8maCkxFKckWio xVxUnAgANWws0BcCAAA= Subject: Re: [MMUSIC] Updated MSID 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, 01 Nov 2013 13:34:27 -0000 Hi, I have reviewed this document, and have some feedback. First of all I trying to understand any commonalities and differences among the other proposals for relation signaling: Application Token draft-even-mmusic-application-token-01 And our SRCNAME https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/ that relates to our Simulcast proposal https://datatracker.ietf.org/doc/draft-westerlund-avtcore-rtp-simulcast/ I hope to have time to discuss this with people during the IETF meeting. It is something we need to sort out. Now comments directly related to the draft: 1. Section 2: I don't think MSID should really be a media level attribute. It is primarily a source level attribute. The discussion about its usage is all around binding it to media streams, i.e. Packet Streams (SSRC)s. There might be points of binding it to Media Descriptions, which under unified plan would mean Media Sources, but outside of unified it then binds to a RTP session or similar. Thus one needs to consider if the media level application means that all SSRCs or other media streams that originates from the context described by that Media Description have the same MSID values apply. Thus, I would suggest changing MSID to source level attribute, and then add the meaning of applying it as media level when such done. 2. Section 3: "In order to fully reproduce the semantics of the SDP and SSRC grouping frameworks, a session-level attribute is defined for signaling the semantics associated with an msid grouping." I think this is a poor motivation. I think there are good reasons for having a semantics identifier for the grouping identifier so that one can have groupings for different purposes. Thus I think one rather should explain the benefits of enabling such different semantics. 3. Section 4: I don't know if this is the right place for it or where it should go. But applying MSID to WebRTC one runs into the question of how one needs to deal with none source packet streams, i.e. Packet Streams that do not carry the primary source encoding. Such streams that are redundancy streams, like RTP retransmission streams, FEC streams, as well as if one would use scalable encoding and have packet streams that are dependent. How should these be marked using MSID? As being part of the related MediaStreamTrack? OR should we use something that isn't dependent on the WMS semantics, SRCNAME, APPID or other? 4. Section 4.1 o No msid-semantic:WMS attribute is present. The SDP session is assumed to be a backwards-compatible session. All incoming media, on all m-lines that are part of the SDP session, are assumed to belong to independent media streams, each with one track. The identifier of this media stream and of the media stream track is a randomly generated string; the label of this media stream will be set to "Non-WMS stream". NOTE IN DRAFT: Previous versions of this memo suggested adding all incoming SSRCs to a single MediaStream. This is problematic because we do not know if the SSRCs are synchronized or not before we learn the CNAME of the SSRCs, which only happens when an RTCP packet arrives. How to identify a non-WMS stream is still open for discussion - including whether it's necessary to do so. Using the stream label seems like an easy thing to do for debuggability - it's not signalled, and is intended for human consumption anyway. Can you clarify how synchronized playback of multiple different media streams, that on RTP level shares CNAME can be achieved in the context of WebRTC. If that is not an issue with separate MediaStreams then I am fine with this. If the main way of achieving synchronized playback is to put the MediaStreamTracks in the same MediaStream then we have an issue. I see a point in that each endpoitn (CNAME) should have its SSRCs with source packet streams result in MediaStreamTracks in the same MediaStream. But, as you write that either introduces delay into adding a MediaStreamTrack until RTCP info has been received or otherwise a lot of change events as one makes one assumption and then have to correct it as more data comes in. 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 pkyzivat@alum.mit.edu Fri Nov 1 15:25:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D7511E8153 for ; Fri, 1 Nov 2013 15:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHyd1mYMMHvr for ; Fri, 1 Nov 2013 15:25:42 -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 7643A11E8137 for ; Fri, 1 Nov 2013 15:25:42 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id kGiJ1m00316LCl059NRisX; Fri, 01 Nov 2013 22:25:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id kNRh1m00m3ZTu2S3SNRhvr; Fri, 01 Nov 2013 22:25:42 +0000 Message-ID: <52742A65.4020600@alum.mit.edu> Date: Fri, 01 Nov 2013 15:25:41 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4F9341@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F9341@ESESSMB209.ericsson.se> 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=1383344742; bh=bWMW3jIIJ9caolby0rpAgPspEHQ4PDuVnZNLRdQouTA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CWfZO4y4kiHWTkva0Ag+uZGO5gXR61uH3L/KfS/eC2VjQt9pMA9BaA63Gnhjg0MHt SWD+TEb64mW6LdyUSjWRJ7wp5n0SyWZGLoEkBLah9Am2QE5meEBchJMfsTVu2r43Lg 1D1O94nm7kv8upv5nDrEmBqjEL+gnkgSADXQhE9LHjffvQj8y1ukLTu13dvNEzxm5f MBYXyg4RWhWzMdMsoOCww9R0h7EtEWV3LCGLRcKvWgB8B0wrUt90KLCBfcsGz4ZohX tS5tKb8vRGsQS4k+jvIBoB6E1yJBoo7zjl8wFkFu399UpycaJbKA2+w6jmEuUlar83 IVH2waKIsjpYA== Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:25:48 -0000 Following up on some items... On 10/28/13 6:45 AM, Christer Holmberg wrote: >> Section 6.4.3 says: >> >> When an Offerer receives an Answer, in which an offered BUNDLE group >> is accepted, if the Offerer in the associated Offer assigned an >> address (unique or shared), that does not represent the BUNDLE >> address selected for the Offerer, to an "m=" line within the BUNDLE >> group, the Offerer MUST send a subsequent Offer, in which it assigns >> the BUNDLE address selected for the Offerer to each "m=" line within >> the BUNDLE group. This procedure is referred to as Bundle Address >> Synchronization (BAS), and the Offer is referred to as a BAS Offer. >> >> I tried to parse it below. To do so, I had to move "that does not represent the BUNDLE address selected for the Offerer,". >> >> When an Offerer receives an Answer, >> in which an offered BUNDLE group is accepted, >> if the Offerer in the associated Offer assigned an address >> (unique or shared), to an "m=" line within the BUNDLE group, >> that does not represent the BUNDLE address selected for the >> Offerer, >> >> the Offerer MUST send a subsequent Offer, in which it assigns >> the BUNDLE address selected for the Offerer to each "m=" line within >> the BUNDLE group. This procedure is referred to as Bundle Address >> Synchronization (BAS), and the Offer is referred to as a BAS Offer. >> >> Even so, it still doesn't quite make sense to me. The problem is with "selected for the Offerer". IIUC it would state that as "selected by the Answerer". >> >> And in any case I'm not sure if I then have the intended interpretation. >> >> I *think* the condition you are trying to describe is: >> >> - offer included bundle group >> - answer accepted bundle group >> - M is the first mid in the bundle group in the answer >> - A is the media address of the m-line in the offer that >> has mid M >> - some m-line in offered bundle group that was accepted in the answer >> doesn't have media address A >> >> If that is what you are trying to say, then we just have to figure out how to say it intelligibly. I think trying to string it out into a sentence is not going to work, and so you need to break it down something like I did above. > > What I am trying to say is: in the Offer, unless the BUNDLE address (determined by the Answerer) was assigned to each m= line in the BUNDLE group, a new Offer must be sent. *That* I can understand! But IMO it is not what you need to say here. It is over simplified. It doesn't cover the case where some of the m-lines have been rejected in the answer. Also, it doesn't really say what "BUNDLE address (determined by the Answerer)" means. (In reality, a bundle has two addresses - one in the offer and one in the answer. The thing that will eventually be in common between the offer and the answer, that determines those addresses, is the mid value.) > Maybe the following text is easier to understand: > > "When an Offerer receives an Answer, in which an offered BUNDLE group is accepted, > unless, in the Offer, the BUNDLE address (determined by the Answerer [ref-to-section-6.5.1]) > was assigned to each "m=" line within the BUNDLE group, the Offerer MUST send a > subsequent Offer, in which it assigns the BUNDLE address to each "m=" line within > the BUNDLE group. This procedure is referred to as Bundle Address Synchronization > (BAS), and the Offer is referred to as a BAS Offer. > > Perhaps it can be even further simplified, but hopefully it is at least easier to understand now :) It has too many complex clauses. It needs to be simplified. As I suggested previously, I think trying to say it in one sentence is too much to attempt in the English language. So I suggest something of the form: "When the Offerer receives an Answer it checks if the answer meets all of the following conditions: - something - something else - ... If so, the Offerer MUST send a subsequent Offer, in which it assigns the BUNDLE address to each "m=" line within the BUNDLE group. This procedure is referred to as Bundle Address Synchronization (BAS), and the Offer is referred to as a BAS Offer. > ---------------------------- > >> Section 6.5.1 >> >> This section is titled "Offerer Bundle Address Selection", and starts out: >> >> When an Answerer generates an Answer that contains a BUNDLE group, >> the Answer MUST select the Offerer's BUNDLE address. >> >> As I noted earlier, I find this terminology confusing about who is doing what. I think it would be clearer to say this as follows: >> >> 6.5.1. Answerer Selection of Offerer's Bundle Address >> >> When an Answerer generates an Answer that contains a BUNDLE group, >> the Answer MUST select the m-line that will determine the BUNDLE >> address for offerer and answerer. The first mid value in the SDP >> group:BUNDLE attribute mid list of the Offer represents the m-line >> which the Offerer wishes the Answer to select. (Section 6.4.2.) >> >> The Answerer SHOULD select the the first mid value from the offer, >> unless the Answerer in the associated Answer will reject the >> "m=" line associated with that mid value, or remove the "m=" line >> from the BUNDLE group. In such case the Answerer MUST select >> the first unrejected mid value that remains in the SDP group:BUNDLE >> attribute mid list of the Offer. > > Looks good. Maybe we should not use the word "Selection" in the subject, though, if we are going to use "determine" terminology. OK > ---------------------------- > >> Section 6.5.4: >> >> What should be done if rejecting the m-line causes the bundle group to be empty? > > I've been thinking about that myself. > > Either the Answer doesn't contain the SDP group:BUNDLE attribute, or it contains an SDP group:BUNDLE attribute with an empty value list (we would need to double check whether the group attribute ABNF allows that). It not only allows it, it requires that it be used this way. (See 5888 section 9.2.) > I think it would be a little strange to include an empty attribute, though. The only advantage is that it could be used to indicate support of the BUNDLE mechanism. But, if we need to be able to do that even if there is no BUNDLE group we should probably define something else. I don't think we need another mechanism. This one seems to suit the purpose well. Thanks, Paul From harald@alvestrand.no Sat Nov 2 15:10:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4F721E811F for ; Sat, 2 Nov 2013 15:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.955 X-Spam-Level: X-Spam-Status: No, score=-109.955 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYulYxKR-KsG for ; Sat, 2 Nov 2013 15:10:50 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E192F21E8119 for ; Sat, 2 Nov 2013 15:10:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0620039E0C8; Sat, 2 Nov 2013 23:10:23 +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 jEwhutOXGBqv; Sat, 2 Nov 2013 23:10:22 +0100 (CET) Received: from [192.168.235.121] (unknown [69.164.171.170]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8160E39E070; Sat, 2 Nov 2013 23:10:17 +0100 (CET) Message-ID: <52753706.4060805@alvestrand.no> Date: Sat, 02 Nov 2013 18:31:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Magnus Westerlund , mmusic References: <5270B191.9030603@alvestrand.no> <5273ACB5.2020201@ericsson.com> In-Reply-To: <5273ACB5.2020201@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updated MSID 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, 02 Nov 2013 22:10:56 -0000 Thanks for the review! Not addressing the whole thing, but just one: On 11/01/2013 02:29 PM, Magnus Westerlund wrote: > 3. Section 4: > > I don't know if this is the right place for it or where it should go. > But applying MSID to WebRTC one runs into the question of how one needs > to deal with none source packet streams, i.e. Packet Streams that do not > carry the primary source encoding. Such streams that are redundancy > streams, like RTP retransmission streams, FEC streams, as well as if one > would use scalable encoding and have packet streams that are dependent. > > How should these be marked using MSID? As being part of the related > MediaStreamTrack? OR should we use something that isn't dependent on the > WMS semantics, SRCNAME, APPID or other? If I ignore your advice to move msid back from being a media-level attribute to being a stream-level attribute, Unified Plan makes that simple: All packet streams that form part of a MediaStreamTrack are signalled as part of the same m-line, so the MSID applies to all of them. Marking for simulcast is entirely independent of MSID; MSID just identifies the MediaStreamTrack and MediaStream, it does not help in parsing the components of a MediaStreamTrack. The one case where this gets into trouble is a FEC stream that applies to multiple SSRCs; this is the same case (and the same issue) as the one where you might want to use the same a=ssrc attribute in multiple m-lines. Either we can define how that is done, or we can define that this is impossible in Unified Plan. Some issues may not be worth solving. -- Surveillance is pervasive. Go Dark. From harald@alvestrand.no Sat Nov 2 15:11:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974FF11E824B for ; Sat, 2 Nov 2013 15:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.255 X-Spam-Level: X-Spam-Status: No, score=-110.255 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiK2ZzGGWYWC for ; Sat, 2 Nov 2013 15:11:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B321E8122 for ; Sat, 2 Nov 2013 15:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D43139E070; Sat, 2 Nov 2013 23:11:19 +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 K0ju2TUSDrXh; Sat, 2 Nov 2013 23:11:18 +0100 (CET) Received: from [192.168.235.121] (unknown [69.164.171.170]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AF9A939E0C8; Sat, 2 Nov 2013 23:11:02 +0100 (CET) Message-ID: <5275394F.1040901@alvestrand.no> Date: Sat, 02 Nov 2013 18:41:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Magnus Westerlund , mmusic References: <5270B191.9030603@alvestrand.no> <5273ACB5.2020201@ericsson.com> In-Reply-To: <5273ACB5.2020201@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Updated MSID 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, 02 Nov 2013 22:11:28 -0000 On 11/01/2013 02:29 PM, Magnus Westerlund wrote: > Can you clarify how synchronized playback of multiple different media > streams, that on RTP level shares CNAME can be achieved in the context > of WebRTC. In the context of the WebRTC API spec, there exist no guarantees about synchronization between different MediaStreams. The UA is free to play them out synchronized or unsynchronized; of course synchronized playback is also in accordance with the specification. > If that is not an issue with separate MediaStreams then I am > fine with this. If the main way of achieving synchronized playback is to > put the MediaStreamTracks in the same MediaStream then we have an issue. > I see a point in that each endpoitn (CNAME) should have its SSRCs with > source packet streams result in MediaStreamTracks in the same > MediaStream. But, as you write that either introduces delay into adding > a MediaStreamTrack until RTCP info has been received or otherwise a lot > of change events as one makes one assumption and then have to correct it > as more data comes in. I think I see what you mean now; this is an issue with compatibility with non-WMS systems that rely on CNAME for signalling that synchronization should occur. I see two solutions for compatibility: - Add all tracks with the same CNAME to the same MediaStream. Do not signal the addstream or addtrack events until the CNAME is known. This delays playout start, but is compatible with preexisting usage. - Generate separate MediaStreams as in the current spec, but put in a note that if these are played out locally, they SHOULD be synchronized. In the latter case, Javascript will have no way of telling that the tracks are in fact synchronized, but they will play out correctly. -- Surveillance is pervasive. Go Dark. From suhasietf@gmail.com Sat Nov 2 23:08:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6811E810A for ; Sat, 2 Nov 2013 23:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOHZZnmRLOzp for ; Sat, 2 Nov 2013 23:08:57 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC2311E8178 for ; Sat, 2 Nov 2013 23:08:53 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so933161wgh.3 for ; Sat, 02 Nov 2013 23:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+d6MpittXP0D91lJKvd3OY2gCrEDmeL7+OD2bT1Zvf8=; b=QpEqy2JH+fORTqAAYrERq10i0b6hcTyDdWmgsEt1b96aTj3gz11soctX85EPiVztLO af9mO1mi+e//0CjsPtf4Wz7NHNJhRzj+BKmKb4i9ZZvUP6a61ykY5V+RNlNMV8G9PoO2 p4uSZMuJJjRqY7y0tEl27oKuxDkzxGPjMDYW1gE3HnCbAr8IdEi7yhA9S9jXPGwynLTM au9Fg7eyodbmskgoPCmQVPrtgpTwAwHYketGS+ie3vhFrAgRJk5Z9fSNauhELJprWj+A J5gyPL6/C6rL2MUFSHAaBo5bkPdM7CrxDqyYiFNGBYYLgMRQZ6qPAdPyhGCSAW+7Md22 7JJg== MIME-Version: 1.0 X-Received: by 10.194.175.202 with SMTP id cc10mr14924wjc.48.1383458932468; Sat, 02 Nov 2013 23:08:52 -0700 (PDT) Received: by 10.194.178.231 with HTTP; Sat, 2 Nov 2013 23:08:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Nov 2013 23:08:52 -0700 Message-ID: From: Suhas Nandakumar To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e013d0f483b30a504ea3fa243 Cc: Cullen Jennings , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ?? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 06:08:58 -0000 --089e013d0f483b30a504ea3fa243 Content-Type: text/plain; charset=ISO-8859-1 Hello Harald Thanks for the inputs. I had a clarifying question on one of your points (inline) Cheers Suhas On Tue, Oct 22, 2013 at 12:55 AM, Harald Alvestrand wrote: > 0: No, using PT 98 for both audio and video should absolutely not be > allowed. Reuse of a PT for different codecs MUST NOT be done. I thought > that was pretty clear in BUNDLE already; if it's not 100% crystal clear, it > needs to be made clear. > > 1: Either the SDP should be rejected outright or the response to this SDP > needs to disallow bundling those two lines. This belongs in the BUNDLE > spec, and I thought it was pretty clear already. > > 2: If the question is about the "a=rtcp-fb" field, I think it should be > classified as NORMAL. If it is about "a=rtcp-fb:98", it makes more sense to > call it IDENTICAL. > If the PT types are not allowed to be repeated across BUNDLED m=lines, would we have a need for the category to be IDENTICAL even in the case of a=rtcpfb:98 ?? > > > > On Tue, Oct 22, 2013 at 8:36 AM, Suhas Nandakumar wrote: > >> Hello All >> >> Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05 >> defines one category of OPEN ISSUE that was raised while analyzing >> multiplexing behavior of RFC4855, RFC5583 attributes for example. >> >> As an example, let's consider the SDP Example (copied from the draft) >> >> >> // PTs are shared and have different feedback types >> a=group:BUNDLE audio video >> m=audio 3456 RTP/AVP 98 >> a=mid:audio >> a=rtpmap:98 iLBC/8000 >> a=rtcp-fb ack // Positive ACK >> m=video 3456 RTP/AVP 98 >> a=mid:video >> a=rtpmap:98 VP8/90000 >> a-rtcp-fb:98 nack rpsi // Nack ACK >> >> >> In the above case, PT 98 is repeated between the audio and video media >> lines. Audio media line has rtcp-fb ack and video media line has rtcp-fb >> nack. >> >> Since RTCP reporting happens per RTP Session, we can see the following >> high level questions : >> >> 0. Should this be allowed ? >> >> 1. What should be the expected behavior in this scenario ? >> >> 2. What category assignment makes sense in here - IDENTICAL or NORMAL ?? >> >> >> Cheers >> Suhas >> >> >> > --089e013d0f483b30a504ea3fa243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Harald

=A0Thanks for the inputs. = I had a clarifying question on one of your points (inline)

Cheers
Suhas


On Tue, Oct 22, 2013 at 12:55 AM, Harald Alvestrand <<= a href=3D"mailto:hta@google.com" target=3D"_blank">hta@google.com> wrote:
0: No, using PT 98 for both audio and video should absolut= ely not be allowed. Reuse of a PT for different codecs MUST NOT be done. I = thought that was pretty clear in BUNDLE already; if it's not 100% cryst= al clear, it needs to be made clear.

1: Either the SDP should be rejected outright or the respons= e to this SDP needs to disallow bundling those two lines. This belongs in t= he BUNDLE spec, and I thought it was pretty clear already.

2: If the question is about the "a=3Drtcp-fb" field, I= think it should be classified as NORMAL. If it is about "a=3Drtcp-fb:= 98", it makes more sense to call it IDENTICAL.

=A0If the PT types are not allowed to be repeated acros= s BUNDLED m=3Dlines, would we have a need for the category to be IDENTICAL = even in the case of a=3Drtcpfb:98 ??

=A0
=A0


On Tue, Oct 22, 2013 at 8:36 AM, Suhas N= andakumar <suhasietf@gmail.com> wrote:
Hello All

=A0 =A0Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05 d= efines one category of OPEN ISSUE that was raised while analyzing multiplex= ing behavior of RFC4855, RFC5583 attributes for example.

As an example, let's consider the =A0SDP Example (c= opied from the draft)

// PTs are shared and have different feedback types
   a=3Dgroup:BUNDLE audio video
   m=3Daudio 3456 RTP/AVP 98
   a=3Dmid:audio
   a=3Drtpmap:98 iLBC/8000
   a=3Drtcp-fb ack                  // Positive ACK
   m=3Dvideo 3456 RTP/AVP 98
   a=3Dmid:video
   a=3Drtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK

In the above case, PT 98 is repeated b= etween the audio and video media lines. Audio media line has rtcp-fb ack an= d video=A0media line has rtcp-fb nack.= =A0

Since RTCP reporting happens per RTP Session, we can see the followin= g high level questions :=A0

0. Should this be allowed ?=A0

1. What should be the expected behavior in this scena= rio ?

2. What category assignment makes sense in here - IDENTICAL or = NORMAL ??


Cheers
Suh= as




--089e013d0f483b30a504ea3fa243-- From hta@google.com Sun Nov 3 02:00:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F811E8138 for ; Sun, 3 Nov 2013 02:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCFgX5Fjr8DX for ; Sun, 3 Nov 2013 02:00:24 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B114511E81CA for ; Sun, 3 Nov 2013 02:00:20 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p6so698746vbe.4 for ; Sun, 03 Nov 2013 02:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0UCXdU929iYq88WqcRm2/nwi6f5NaOuLWqi2nmXNdv4=; b=fG8TzoImoJtuFtYCewltao0Ge/wDTaVBnyAIWcJDmA4kUJ9HQdNOZ4lfOZ9jLBvY2Q cmQziieh8Tl1Gmg3DZTTLWXC/F5YojRF8bQbe/PsRWBtD8U3rvNSbrYGx4Uz5iwwkqjs oVwGyZcqmHuUSb/DXgQMUOwUYGLAV1wPoV702Xhb6Ti1pviymvHdl1GOPeD3+HYiS3BW 9hi54WmIywhOB608gFjbXooeYDTXVe68Nd6I791F4WD3FKFIvNOYoZtQ4MpZkK6hodth 80L8Cw8KOnIeZIojG8xC9U8hUSnzgs6pyTwQ+EkJMrvIERKlwtggL0VoVVlPhIAf/4uo d8Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0UCXdU929iYq88WqcRm2/nwi6f5NaOuLWqi2nmXNdv4=; b=gpbylVcXk5ZVLvP2jjmlCUxmQwypD1E7bIlmy5xm+I4NAdexvrXZIKeo3um48QBa/V IOBESS3Sb0aN3xP6Pv6QUMmZfGoHS7kkQ4UA+lFRuEmBn/6FBCJcQWngA5kOfhmWpxdS 918ceT4xg2jdLY6+68rA2DTV0fDDpqS7TDoKcEt1cqqoOqD0hPxwRZw493qH4IMhsoLB c/oo9mY3Eqo4Zv23DSlbMaWgDf4O6Gm+un884ETbY5sVkmfo/Z+xn+uScP8Xcp9mHGX+ mBP3MKgQo6MbFtYQy0eVlYl9aGYyZpC9KYjzUDWRQUwwJLZ9iUQiFNbEbMCBpT1SxCxn mzaA== X-Gm-Message-State: ALoCoQmIVVj+adHoB2DJFMCneyxRdary0PYYZrwQ4i9gEzXoWaHT+b6l76Fx6s7RFUvwC0QDq20vMuV7Tjoc2+Vi3O527nARdmCS1y11csw9zMN5wcfwtJakv0+BQOpR8yDDrPx2GY2wcglnMPNkeWL1fSdDvAm0XRLfGfAOom8lR4/5uMrgKDYLn92QyUEp4sIB4qkqLdBn X-Received: by 10.58.44.72 with SMTP id c8mr36181vem.37.1383472810342; Sun, 03 Nov 2013 02:00:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.176.8 with HTTP; Sun, 3 Nov 2013 01:59:49 -0800 (PST) In-Reply-To: References: From: Harald Alvestrand Date: Sun, 3 Nov 2013 10:59:49 +0100 Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=089e013cc1fc6ae26704ea42ddca Cc: Cullen Jennings , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE/SDP : ISSUE#1: Should BUNDLE allow/disallow PT sharing ?? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 10:00:25 -0000 --089e013cc1fc6ae26704ea42ddca Content-Type: text/plain; charset=UTF-8 In the case of multiple m=video lines (for instance), as required by UnifiedPlan, signalling separate PTs for every M-line is not going to work with many video streams. So the consensus seems to be that we should allow PT to be identical across m-lines as long as the codec configuration is identical. It may make sense to have NACK on one media stream and not NACK on another media stream, even though in the implementation, the binding is happening via the m-line + PT combo, not just the PT. So NORMAL should be the right disposition for a=rtcp-fb:98, in my opinion. On Sun, Nov 3, 2013 at 7:08 AM, Suhas Nandakumar wrote: > Hello Harald > > Thanks for the inputs. I had a clarifying question on one of your points > (inline) > > Cheers > Suhas > > > On Tue, Oct 22, 2013 at 12:55 AM, Harald Alvestrand wrote: > >> 0: No, using PT 98 for both audio and video should absolutely not be >> allowed. Reuse of a PT for different codecs MUST NOT be done. I thought >> that was pretty clear in BUNDLE already; if it's not 100% crystal clear, it >> needs to be made clear. >> >> 1: Either the SDP should be rejected outright or the response to this SDP >> needs to disallow bundling those two lines. This belongs in the BUNDLE >> spec, and I thought it was pretty clear already. >> >> 2: If the question is about the "a=rtcp-fb" field, I think it should be >> classified as NORMAL. If it is about "a=rtcp-fb:98", it makes more sense to >> call it IDENTICAL. >> > > If the PT types are not allowed to be repeated across BUNDLED m=lines, > would we have a need for the category to be IDENTICAL even in the case of > a=rtcpfb:98 ?? > > > >> >> > >> >> On Tue, Oct 22, 2013 at 8:36 AM, Suhas Nandakumar wrote: >> >>> Hello All >>> >>> Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attributes-05 >>> defines one category of OPEN ISSUE that was raised while analyzing >>> multiplexing behavior of RFC4855, RFC5583 attributes for example. >>> >>> As an example, let's consider the SDP Example (copied from the draft) >>> >>> >>> >>> // PTs are shared and have different feedback types >>> a=group:BUNDLE audio video >>> m=audio 3456 RTP/AVP 98 >>> a=mid:audio >>> a=rtpmap:98 iLBC/8000 >>> a=rtcp-fb ack // Positive ACK >>> m=video 3456 RTP/AVP 98 >>> a=mid:video >>> a=rtpmap:98 VP8/90000 >>> a-rtcp-fb:98 nack rpsi // Nack ACK >>> >>> >>> In the above case, PT 98 is repeated between the audio and video media >>> lines. Audio media line has rtcp-fb ack and video media line has >>> rtcp-fb nack. >>> >>> Since RTCP reporting happens per RTP Session, we can see the following >>> high level questions : >>> >>> 0. Should this be allowed ? >>> >>> 1. What should be the expected behavior in this scenario ? >>> >>> 2. What category assignment makes sense in here - IDENTICAL or NORMAL ?? >>> >>> >>> Cheers >>> Suhas >>> >>> >>> >> > --089e013cc1fc6ae26704ea42ddca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the case of multiple m=3Dvideo lines (for instance), as= required by UnifiedPlan, signalling separate PTs for every M-line is not g= oing to work with many video streams. So the consensus seems to be that we = should allow PT to be identical across m-lines as long as the codec configu= ration is identical.

It may make sense to have NACK on one media stream and not N= ACK on another media stream, even though in the implementation, the binding= is happening via the m-line + PT combo, not just the PT. So NORMAL should = be the right disposition for a=3Drtcp-fb:98, in my opinion.


On Sun,= Nov 3, 2013 at 7:08 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
Hello Harald

=
=C2=A0Thanks for the inputs. I had a clarifying question on one of you= r points (inline)

Cheers
Suhas
=

On Tue, Oct 22, 2013 at 12:55 AM, Harald Alvestrand <<= a href=3D"mailto:hta@google.com" target=3D"_blank">hta@google.com> wrote:
0: No, using PT 98 for both audio and video should absolut= ely not be allowed. Reuse of a PT for different codecs MUST NOT be done. I = thought that was pretty clear in BUNDLE already; if it's not 100% cryst= al clear, it needs to be made clear.

1: Either the SDP should be rejected outright or the respons= e to this SDP needs to disallow bundling those two lines. This belongs in t= he BUNDLE spec, and I thought it was pretty clear already.

2: If the question is about the "a=3Drtcp-fb" field, I= think it should be classified as NORMAL. If it is about "a=3Drtcp-fb:= 98", it makes more sense to call it IDENTICAL.

=C2=A0If the PT types are not allowed to be repea= ted across BUNDLED m=3Dlines, would we have a need for the category to be I= DENTICAL even in the case of a=3Drtcpfb:98 ??
<= br>
=C2=A0
=C2=A0


On Tue, Oct 22, 2013 at 8:36 AM, Suhas N= andakumar <suhasietf@gmail.com> wrote:
Hello All

=C2=A0 =C2=A0Section 5.2 in the draft-nandakumar-mmusic-sdp-mux-attribute= s-05 defines one category of OPEN ISSUE that was raised while analyzing mul= tiplexing behavior of RFC4855, RFC5583 attributes for example.

As an example, let's consider the =C2=A0SDP Example= (copied from the draft)


// PTs are shared and have different feedback types
   a=3Dgroup:BUNDLE audio video
   m=3Daudio 3456 RTP/AVP 98
   a=3Dmid:audio
   a=3Drtpmap:98 iLBC/8000
   a=3Drtcp-fb ack                  // Positive ACK
   m=3Dvideo 3456 RTP/AVP 98
   a=3Dmid:video
   a=3Drtpmap:98 VP8/90000
   a-rtcp-fb:98 nack rpsi        // Nack ACK

In the above case, PT 98 is repeated b= etween the audio and video media lines. Audio media line has rtcp-fb ack an= d video=C2=A0media line has rtcp-fb na= ck.=C2=A0

Since RTCP reporting happens per RTP Session, we can see the followin= g high level questions :=C2=A0
0. Should this be allowed ?=C2=A0=

1. What should be the expected behavior in this sc= enario ?

2. What category assignment makes sense in here - IDENTICAL or = NORMAL ??


Cheers
Suh= as





--089e013cc1fc6ae26704ea42ddca-- From partha@parthasarathi.co.in Sun Nov 3 02:14:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FB711E81CC for ; Sun, 3 Nov 2013 02:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X8dluOI5bE1 for ; Sun, 3 Nov 2013 02:14:00 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9F11E8104 for ; Sun, 3 Nov 2013 02:14:00 -0800 (PST) Received: from userPC (unknown [122.179.43.26]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id E52B7638F15; Sun, 3 Nov 2013 10:13:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1383473640; bh=pRUwtleBr+6SM4L1dSuNQSVI5xMHAJbNBN239awL6sg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=g47l/itDHHWEYfypH6xamGRBfvqsw6tD+uxGQuh4vvsP4MAWVQAm0CTgWdzphTR1E tZcFKQr/N2zQKzDt9K72A9toAhyq+R7TAlv/ER43ZL96t5kGbDC0sBOolc7NIASvRj V9NTt8KzWoY2xB9P1Y/hZPvqKrhZMuz9I7KzlgBk= From: "Parthasarathi R" To: "'Paul Kyzivat'" , References: <00a401cece8b$7b00f780$7102e680$@co.in> <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se>, <5266C0A7.5040305@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EBBEA@ESESSMB209.ericsson.se> <5266DAB0.7020001@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EC9F2@ESESSMB209.ericsson.se> <5267CA43.8020304@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4EDE3A@ESESSMB209.ericsson.se> <5267E052.6020401@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F0FED@ESESSMB209.ericsson.se> <52692E69.8020109@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C4F223D@ESESSMB209.ericsson.se> <369B690E-2456-48AD-923E-93B88A620817@vidyo.com> <526945F3.1060205@alum.mit.edu> In-Reply-To: <526945F3.1060205@alum.mit.edu> Date: Sun, 3 Nov 2013 15:43:55 +0530 Message-ID: <000b01ced87d$69b8e680$3d2ab380$@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: Ac7Q1A9h/fBu3p/qQh2jvsz0bpUguAHpI1cA Content-Language: en-us X-CTCH-RefID: str=0001.0A020206.527621E8.0032, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-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, 03 Nov 2013 10:14:05 -0000 Hi Paul & all, It is possible to follow RFC 6337 offer/answer guidelines in case UPDATE method (Sec 6.4 of draft-partha-rtcweb-jsep-sip-01) is used for Trickle ICE instead of INFO. The concern with Trickle ICE handling w.r.t RFC 3264 O/A is that the SDP feature interaction like BUNDLE leads to more glare handling during every session creation as UPDATE is exchanged in both directions. IMO, RFC 3264 O/A shall be updated to handle the media address change only SDP which reduces the glare situation but handle the original glare situation. The SDP "a" attribute like "media-address-change-only" or "ice-candidate-change" shall help to achieve this functionality. The attribute will be backward-compatible as "a" attribute will be ignored in case the other end-point does not support. Also, the attribute shall be used within partial offer/answer as well. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, October 24, 2013 9:38 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on > draft-ivov-mmusic-trickle-ice-sip-01 > > I'm far from an expert on ICE, so maybe this is covered and I just > don't > know it... > > ISTM there is a need for some real clarity about the relationship > between ICE state and SDP O/A state, and if/when pieces of state move > or > are synchronized between them. This isn't clear even for SDP O/A on its > own, but with ICE, and now with trickle ICE, and with Partial O/A it is > becoming even more of a problem. > > RFC 6337 started to clarify SDP O/A itself, but it didn't deal with the > sorts of issues that are coming up in this discussion. > > Thanks, > Paul > > On 10/24/13 11:36 AM, Jonathan Lennox wrote: > > > > On Oct 24, 2013, at 10:34 AM, Christer Holmberg > > > wrote: > > > >> Hi, > >> > >>>> We have to remember, though, that a trickled candidate is not a > new > >>>> candidate "type". The candidate types you trickle are the same > types > >>>> you send in Offer/Answer - tickle is simply an alternative > candidate > >>>> transport mechanism. > >>> > >>> Yes, that's right. I am not sure why you are saying it though. > >> > >> Because when you say: > >> > >> "we treat trickle candidates in the same way as peer-reflexive > candidates" > >> > >> ...it sounds like a trickle candidate is a new type of candidate > (similar to peer-reflexive candidate), which is not true. > >> > >> > >> You should say: > >> > >> "We treat candidates that were provided using the trickle ICE > mechanism in the same way as peer-reflexive candidates" > > > > There's a problem with this. > > > > RFC 5245 says: > > > > However, the peer reflexive candidate is not paired with other > remote > > candidates. This is not necessary; a valid pair will be > generated > > from it momentarily based on the procedures in Section 7.1.3.2.2. > If > > an agent wishes to pair the peer reflexive candidate with other > > remote candidates besides the one in the valid pair that will be > > generated, the agent MAY generate an updated offer which includes > the > > peer reflexive candidate. > > > > In other words, peer-reflexive candidates aren't automatically paired > with all remote candidates; they're only paired with the remote > candidate you were checking when you discovered them, unless you send > them in an updated offer. > > > > Candidates provided over Trickle don't have a remote candidate to be > automatically paired with, so "treating them like peer-reflexive > candidates" doesn't make much sense. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@ericsson.com Sun Nov 3 06:16:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B0611E8208 for ; Sun, 3 Nov 2013 06:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W2ccIqu1EGW for ; Sun, 3 Nov 2013 06:16:50 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A337B21E808A for ; Sun, 3 Nov 2013 06:16:46 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-df-52765accebf8 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1A.20.27941.CCA56725; Sun, 3 Nov 2013 15:16:44 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.37]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sun, 3 Nov 2013 15:16:43 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: mmusic Thread-Topic: Old draft versions in the agenda for MMUSIC at IETF 88 Thread-Index: AQHO2J9SvjoiXsBK0U+0jUidKzpWEg== Date: Sun, 3 Nov 2013 14:16:43 +0000 Message-ID: <861759C7815040489720E3CC184F51DD1C4A0788@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51BC7EA5D3A4EA4795AF77C7B01C3716@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje6ZqLIgg/2rpC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCUbuQrWMVd0XT7K1sB4l6mLkYNDQsBEYssl/i5GTiBTTOLC vfVsILaQwBFGib3Pc7sYuYDsRYwSC1/OYQVJsAnYS0xe85ERxBYRkJHYu2kzM4gtDBQ/NL2T FSLuInGu/QWUrSfR8ugYG8guFgEViU3beUHCvAK+EgvnrmEHsRmB9n4/tYYJxGYWEJe49WQ+ E8Q9AhJL9pxnhrBFJV4+/scKYStJrNh+iRGiXk/ixtQpbBC2tcSGJx2sELa2xLKFr5khdglK nJz5hGUCo8gsJCtmIWmfhaR9FpL2WUjaFzCyrmLkKE4tTspNNzLYxAgM+YNbflvsYLz81+YQ ozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGM+urdkgwL6MebYk878sccas 39fuJ3VIr0+a32o/w6KN5UnGgveyn2497w+cEZbJccQtoz9k+dfH4rV/g5VPf3qy/9BSj40S 815tusuY4p7Gtiopp/lYT/YnHqnNP53OSc4tqPM/ur8gr2/CtpvBdv83hjHfUvhQ5FPnv3O5 ijRDIOuB6S6bvJVYijMSDbWYi4oTAYvPDCZHAgAA Subject: [MMUSIC] Old draft versions in the agenda for MMUSIC at IETF 88 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 14:16:56 -0000 Hi all, We just noticed that some of the links in the agenda didn't point to the la= test versions of the drafts. Now the agenda has been updated but in case yo= u read the version mentioned in the draft of one of the following drafts, y= ou may want to check out the latest version too: draft-roach-mmusic-pof-pan-01 draft-thomson-mmusic-ice-webrtc-01 draft-nandakumar-mmusic-sdp-mux-attributes-05 Cheers, Ari= From harald@alvestrand.no Sun Nov 3 10:22:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F255E11E82CD for ; Sun, 3 Nov 2013 10:22:10 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZG3sGlrV7Ds for ; Sun, 3 Nov 2013 10:22:05 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A704011E82CC for ; Sun, 3 Nov 2013 10:22:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A8ED39E176 for ; Sun, 3 Nov 2013 19:22:04 +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 DbhIQhFLPjNY for ; Sun, 3 Nov 2013 19:22:03 +0100 (CET) Received: from [172.19.244.5] (unknown [216.239.45.130]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2610439E091 for ; Sun, 3 Nov 2013 19:22:02 +0100 (CET) Message-ID: <52769448.7080606@alvestrand.no> Date: Sun, 03 Nov 2013 19:22:00 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mmusic X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 18:22:11 -0000 On reviewing the appid document and some of the mail on it.. some questions. I understand that an appid can serve multiple purposes; FEC binding and loudest-speaker selection being two examples. Some of these give information that is completely outside the context of RTP / SDP, so they have to be application specified. Others are within the RTP/SDP ecosystem. Thus: - Can one SSRC have mulitple appids? This seems necessary for those multiple functions to work at the same time without treading on each other, but isn't stated explicitly in the draft. - What's the uniqueness criterion for appids? It would seem logical to have them unique at the source, but at least in one case (recv-appid), it is given by the destination. Are we depending on statistical uniqueness, or is the uniqueness governed by some other mechanism? I'll send off these 2 questions now, in order to make the thread be focused.... -- Surveillance is pervasive. Go Dark. From ron.even.tlv@gmail.com Sun Nov 3 13:53:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3529E21F9F21 for ; Sun, 3 Nov 2013 13:53:19 -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.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0ADoxZbHD-z for ; Sun, 3 Nov 2013 13:53:18 -0800 (PST) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5A721E80DC for ; Sun, 3 Nov 2013 13:53:15 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id na10so2644913bkb.0 for ; Sun, 03 Nov 2013 13:53:09 -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:thread-index :content-language; bh=Du1n5ODq2X5U3ZhIltM0sYK8yvAzAsm9b7LAa+itlOY=; b=OCICy2ACNeXTYzZWwh7g+CEnhjxs0scgXvAAnG+PU1UqJMDhq1jl9vwTWfmqENqU6j VZPSI8DUAjsDG1MHY6o4kmFBzDbowfsGC+8aEtwWJOTT4EC16s44+fAbesPnUoN/PiyJ maN9DM0vsf1qr5x5Cf1e6yWcXcBCwqfA0viA2qCGn8TF6Yw+x31kR7CqtXVAwrayYMa4 j9qcuDWuUKExGL7u3PFouZzGTGIP00uWN+ExXZJ1LHWQwFikZNUZB7h0v4TMc8jYM22W 5TBbhzSGN5ud/8MpYx9Yutn75QS3i2/TigwzeVuFLWhkmPVpHbyFt2YjKwDnrU3I5b1X 3wJA== X-Received: by 10.205.10.200 with SMTP id pb8mr7591732bkb.16.1383515589570; Sun, 03 Nov 2013 13:53:09 -0800 (PST) Received: from RoniE ([2001:67c:370:160:7c8c:2661:ea9b:6b8b]) by mx.google.com with ESMTPSA id pu8sm12635233bkb.9.2013.11.03.13.53.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Nov 2013 13:53:08 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , "'mmusic'" References: <52769448.7080606@alvestrand.no> In-Reply-To: <52769448.7080606@alvestrand.no> Date: Sun, 3 Nov 2013 23:49:51 +0200 Message-ID: <017001ced8de$a268f590$e73ae0b0$@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: AQEJHLPXYj78WEr4Hhkvk0KFWNmBA5ufbmWg Content-Language: en-us Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 21:53:19 -0000 Hi Harald, The current draft is still not mature enough and the presentation will have some information which is not there and some of the text in the 00 version that is not in the 01 version may come back. An SSRC can have multiple appIds example is in a three camera system one appID for active speaker which is now the left camera having a different appID The uniqueness of appID should be per media packet stream. Roni > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Harald Alvestrand > Sent: 03 November, 2013 8:22 PM > To: mmusic > Subject: [MMUSIC] Some more APPID questions > > On reviewing the appid document and some of the mail on it.. some questions. > > I understand that an appid can serve multiple purposes; FEC binding and > loudest-speaker selection being two examples. > > Some of these give information that is completely outside the context of RTP / > SDP, so they have to be application specified. Others are within the RTP/SDP > ecosystem. > Thus: > > - Can one SSRC have mulitple appids? > This seems necessary for those multiple functions to work at the same time > without treading on each other, but isn't stated explicitly in the draft. > > - What's the uniqueness criterion for appids? > It would seem logical to have them unique at the source, but at least in one > case (recv-appid), it is given by the destination. Are we depending on statistical > uniqueness, or is the uniqueness governed by some other mechanism? > > I'll send off these 2 questions now, in order to make the thread be focused.... > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Sun Nov 3 14:04:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853BE11E8107 for ; Sun, 3 Nov 2013 14:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFJmwgESTUmL for ; Sun, 3 Nov 2013 14:04:57 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD821F9C6B for ; Sun, 3 Nov 2013 14:04:56 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id w61so1436256wes.10 for ; Sun, 03 Nov 2013 14:04:56 -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=vWM6ILes9o8bdwrCtZzcao0cFWeWUcTW6gPDTA0t4VI=; b=pJOOX2qv33C73konRpGCy0en7FlV206Cyg3lGrtNog2LaTk8iB4DNpiqCz0nJUtvFf K1EcWrS9EMjonkisNTh16QJ5BTfxocz8MvWM1MET8Q+x+pl1efxowGcyupBlGdGVF3bZ ya/mdgUaEPp5Pmx8mtX1+Or1nq/YnR4BPPPHgwS43GhVLTQ0x4ZYTOXJ0/Ta/zhf5ll5 9G6+k/MKOzWJbLnatd68pfZLDdlqTQpKXFlQKh0837I6uY+9oJE9ZzW0wM6+JUVRf9+1 fzqsYy+16Rsj2ImNwtuUFpy/CVm2wBebp1o3rYze4tYObZngGLflsXS7ApbvGOfHoA2+ NjfA== MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr1299538wjc.42.1383516296065; Sun, 03 Nov 2013 14:04:56 -0800 (PST) Received: by 10.227.202.194 with HTTP; Sun, 3 Nov 2013 14:04:56 -0800 (PST) In-Reply-To: <017001ced8de$a268f590$e73ae0b0$@gmail.com> References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> Date: Sun, 3 Nov 2013 14:04:56 -0800 Message-ID: From: Martin Thomson To: Roni Even Content-Type: text/plain; charset=UTF-8 Cc: mmusic Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 22:04:57 -0000 On 3 November 2013 13:49, Roni Even wrote: > The uniqueness of appID should be per media packet stream. You mean "packet stream"? http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-03#section-2.1.10 Because I don't think that that is particularly useful. From harald@alvestrand.no Sun Nov 3 14:30:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC4621E8123 for ; Sun, 3 Nov 2013 14:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCt4XIxUrk98 for ; Sun, 3 Nov 2013 14:30:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D405321F9DCE for ; Sun, 3 Nov 2013 14:30:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05D3D39E176; Sun, 3 Nov 2013 23:30: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 cRIv-fwnHI0e; Sun, 3 Nov 2013 23:30:38 +0100 (CET) Received: from [31.133.162.5] (dhcp-a205.meeting.ietf.org [31.133.162.5]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CAEEA39E091; Sun, 3 Nov 2013 23:30:37 +0100 (CET) Message-ID: <5276CE8B.8050809@alvestrand.no> Date: Sun, 03 Nov 2013 23:30:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Roni Even , 'mmusic' References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> In-Reply-To: <017001ced8de$a268f590$e73ae0b0$@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 22:30:48 -0000 On 11/03/2013 10:49 PM, Roni Even wrote: > Hi Harald, > The current draft is still not mature enough and the presentation will have > some information which is not there and some of the text in the 00 version > that is not in the 01 version may come back. > > An SSRC can have multiple appIds example is in a three camera system one > appID for active speaker which is now the left camera having a different > appID > > The uniqueness of appID should be per media packet stream. > so if you have ssrc A: appid 45 ssrc B: appid 27 this means exactly the same thing as ssrc A: appid 45 ssrc B: appid 45 ? This seems to create issues when you have a single appid that is moving around between SSRCs. From ron.even.tlv@gmail.com Sun Nov 3 14:36:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F321E80ED for ; Sun, 3 Nov 2013 14:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKbpDdhb7m3l for ; Sun, 3 Nov 2013 14:36:00 -0800 (PST) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8604921E8107 for ; Sun, 3 Nov 2013 14:35:50 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz11so2095587bkb.16 for ; Sun, 03 Nov 2013 14:35:49 -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:thread-index :content-language; bh=RMulAfFuHjBwJlL7TNf1CW9WkkCPqqRCxIf7lsdz79U=; b=IVmRqr/3l1XaXKBcrqg4vZADUdZdKbP8ZhHDsMoR+ZQ3ekHex1XdnAxkVjDNeZtpML u/FMMijhhy9a7w4+7TTt1O1XFXoDFLk3aOVWJGDp8i+OG7j84Et4xIepVfRbTXSOwoZW EkEOhoFuLCb3O1d+uK16tUrSgaaE0SZlTLnuI7kzGv4TR7orIYcw/b6R3EPkMVoXglst ngA1EZTVzV/iGCDAwLsv8QUhRipmQW/+kwNOchllRpqpYfWXcM4GG+MlR48ylluveUgD T4EJSSjbEp6s2hNH1uzMlqzCTWOKpZxG96Q4kRL3MXpzpEzaCa4QkBAZmzK1tUO6/m7b H9+Q== X-Received: by 10.204.169.80 with SMTP id x16mr39917bky.52.1383518149572; Sun, 03 Nov 2013 14:35:49 -0800 (PST) Received: from RoniE ([2001:67c:370:160:7c8c:2661:ea9b:6b8b]) by mx.google.com with ESMTPSA id l9sm12700987bkg.0.2013.11.03.14.35.47 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Nov 2013 14:35:48 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , "'mmusic'" References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> <5276CE8B.8050809@alvestrand.no> In-Reply-To: <5276CE8B.8050809@alvestrand.no> Date: Mon, 4 Nov 2013 00:32:32 +0200 Message-ID: <017701ced8e4$985e40e0$c91ac2a0$@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: AQEJHLPXYj78WEr4Hhkvk0KFWNmBAwIZtPtxAkM5Q+ebfKfr4A== Content-Language: en-us Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 22:36:01 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: 04 November, 2013 12:31 AM > To: Roni Even; 'mmusic' > Subject: Re: [MMUSIC] Some more APPID questions > > On 11/03/2013 10:49 PM, Roni Even wrote: > > Hi Harald, > > The current draft is still not mature enough and the presentation will > > have some information which is not there and some of the text in the > > 00 version that is not in the 01 version may come back. > > > > An SSRC can have multiple appIds example is in a three camera system > > one appID for active speaker which is now the left camera having a > > different appID > > > > The uniqueness of appID should be per media packet stream. > > > so if you have > > ssrc A: appid 45 > ssrc B: appid 27 > > this means exactly the same thing as > > ssrc A: appid 45 > ssrc B: appid 45 [Roni Even] This is not allowed, the appId is unique per media stream or what you call SSRC > > ? > > This seems to create issues when you have a single appid that is moving around > between SSRCs. From ron.even.tlv@gmail.com Sun Nov 3 14:38:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7187521F9B57 for ; Sun, 3 Nov 2013 14:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqLQ5TfBAPZD for ; Sun, 3 Nov 2013 14:38:43 -0800 (PST) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8138D21F995A for ; Sun, 3 Nov 2013 14:38:30 -0800 (PST) Received: by mail-bk0-f53.google.com with SMTP id w11so2115578bkz.12 for ; Sun, 03 Nov 2013 14:38:28 -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:thread-index :content-language; bh=aCX/AqQCvL5mb8AMY/jsZxYKKDqSpIulYCZkmObSSpQ=; b=ZvSMSCFpmksHVnQlrzkW9ru8dSO4jQ1YNa07bVh6sNyxYXC/OSCvlAOHWNUv4J5stp 6moiBjd3F/NlqK7EY1ToJ4vrL6WSfCKuE17qZrKxIRSMfCm+GkguJNUQyZtAVkLgQsN3 sc+5nuuh0aE8Cr1EIhnOkvtCY0ROVsqraVQQVDz3j8rFxkeMM+v2NYaJwRDO6FyIQi/u ro53JeCE6xdoDb8HUoakT4ktW0TA4ZFpRFqT9HTuyJBo/UR0IXHUy9GiguJiruzPXTsB kgx1Y24QxS3Tz3E3Z083la9Y49AZJo7YpHdgmF3AHewlQHuqKrNmCxo0tgHs4UuXNUPY i3KA== X-Received: by 10.204.230.17 with SMTP id jk17mr4811244bkb.6.1383518308214; Sun, 03 Nov 2013 14:38:28 -0800 (PST) Received: from RoniE ([2001:67c:370:160:7c8c:2661:ea9b:6b8b]) by mx.google.com with ESMTPSA id a4sm12719383bko.11.2013.11.03.14.38.26 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Nov 2013 14:38:27 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , "'mmusic'" References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> <5276CE8B.8050809@alvestrand.no> In-Reply-To: <5276CE8B.8050809@alvestrand.no> Date: Mon, 4 Nov 2013 00:35:11 +0200 Message-ID: <017801ced8e4$f6e021b0$e4a06510$@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: AQEJHLPXYj78WEr4Hhkvk0KFWNmBAwIZtPtxAkM5Q+ebfKhwwA== Content-Language: en-us Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 22:38:45 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: 04 November, 2013 12:31 AM > To: Roni Even; 'mmusic' > Subject: Re: [MMUSIC] Some more APPID questions > > On 11/03/2013 10:49 PM, Roni Even wrote: > > Hi Harald, > > The current draft is still not mature enough and the presentation will > > have some information which is not there and some of the text in the > > 00 version that is not in the 01 version may come back. > > > > An SSRC can have multiple appIds example is in a three camera system > > one appID for active speaker which is now the left camera having a > > different appID > > > > The uniqueness of appID should be per media packet stream. > > > so if you have > > ssrc A: appid 45 > ssrc B: appid 27 > > this means exactly the same thing as > > ssrc A: appid 45 > ssrc B: appid 45 > > ? > > This seems to create issues when you have a single appid that is moving around > between SSRCs. [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP header extension, example is appID 45 that can be first SSRC A and then SSRC B if appId represent the active speaker. From ari.keranen@ericsson.com Sun Nov 3 15:09:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B2F21E80FF for ; Sun, 3 Nov 2013 15:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.878 X-Spam-Level: X-Spam-Status: No, score=-3.878 tagged_above=-999 required=5 tests=[AWL=-1.579, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEU7dAi3YB6U for ; Sun, 3 Nov 2013 15:09:47 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 35F2611E824A for ; Sun, 3 Nov 2013 15:09:39 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-31-5276d7b0a801 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 29.3E.27941.0B7D6725; Mon, 4 Nov 2013 00:09:37 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 00:09:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7E882110475 for ; Mon, 4 Nov 2013 01:09:36 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6A67B4EBB4 for ; Mon, 4 Nov 2013 01:09:35 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C1C6A4EB9E for ; Mon, 4 Nov 2013 01:09:34 +0200 (EET) Message-ID: <5276D7B0.8050703@ericsson.com> Date: Sun, 3 Nov 2013 15:09:36 -0800 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <50D1FE75.9060709@nomadiclab.com> In-Reply-To: <50D1FE75.9060709@nomadiclab.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvje7G62VBBkcNLKYuf8ziwOixZMlP pgDGKC6blNSczLLUIn27BK6MA9MvsRfcEqjYPmk2UwPjR54uRg4OCQETiad3nbsYOYFMMYkL 99azgdhCAkcYJW7tte5i5AKy1zNKPJy+gBXCucQocX/JfUYI5zCjxLSlm1nhnN27L7CC9PMK aEucWf6TCcRmEVCRePP/EAuIzSZgL3FzwnV2EFtUIFni2YXrzBD1ghInZz4BqxERUJf4urcH LC4sYC7xaOMaqJt0Jdq3/gCLcwroSfxaehAszixgK3FhznUWCFteYvvbOcwQ/6hJXD23iRmi V1Xi6r9XjBMYRWYhWTcLSfssJO0LGJlXMXIUpxYn5aYbGWxiBIbywS2/LXYwXv5rc4hRmoNF SZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mko4sj5xPZGeHLzU4aDCj4ZFT6FZj a5snd4pP+E0Q33TG98++DW+O7NVkMZyXvsLk45M/3rISlgvZPn1NKp2QvExf0H7no40XE1b9 7u77IKj59j5n4+37U/OuS9lIrNV69l91fqdzqlWejt5v5/fhjT0zLzzPLt8r6s/4Yfr02cnp UcbZuyfUK7EUZyQaajEXFScCAB9Sj2EzAgAA Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:09:52 -0000 Folks, This aggressive nomination bug is still an open issue for ICE. If time permits, I'm hoping to discuss this tomorrow. As a solution, I'm leaning towards the updated offer, but would like to hear your opinions on this. Cheers, Ari On 12/19/12 9:50 AM, Ari Keranen wrote: > Hi all, > > Going through the ICE spec reminded me of one old problem with > aggressive nomination that I discussed with Philip Matthews back when > ICE was published: > > Two endpoints L and R. L is the offerer and controlling end. There are > two possible paths, and just one component. > > Since L is using aggressive nomination, it sets the USE-CANDIDATE flag > in each Binding request. However, the Binding response for the first > path does not make it back to L. When the second check succeeds, L > immediately stops ICE processing and uses the second path. However, R > thinks the first path is being used. > > Initially, L will use path 2 for data, while R will use path 1. > Eventually, both paths will fail, because L is only sending keep-alives > on path 2, while R is only sending them on path 1. > > L R > <--------- Bind req --------------------- ] > ---------- Bind resp -------------------> ] Path 1 > ---------- Bind req, USE-CAND ----------> ] > X <-- Bind resp -------------------- ] > > <--------- Bind req --------------------- ] > ---------- Bind resp -------------------> ] Path 2 > ---------- Bind req, USE-CAND ----------> ] > <--------- Bind resp -------------------- ] > > --- > > > Any good ideas how to fix this? Should the controlling agent just keep > retransmitting even after successful nomination (for how long)? > > The updated offer (if we make that MUST in all cases) will help to > detect the problem though and this could also be added to the list of > "reasons for not using aggressive nomination unless you really have to". > > > Cheers, > Ari > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Sun Nov 3 15:18:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3405921E8107 for ; Sun, 3 Nov 2013 15:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRK7+07Gj9fq for ; Sun, 3 Nov 2013 15:18:32 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 81FF611E8243 for ; Sun, 3 Nov 2013 15:18:32 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id cb5so1270571wib.4 for ; Sun, 03 Nov 2013 15:18:31 -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=tIbRQ4BtkYGfr6GLNUHT/EwoAvPgOEFVg6bd7mwa+us=; b=RagLLjlcjfIH3sWjn7T02aE/ruK3rk94VThk9PArMtMJ5AU+yJrViEJn01g0/XAl04 Mxj971UZP42JZc4OEIxO7KUP5w/lI+zUuqfP18QAHU3BLIHSVXuLtCha7bp9tFv0LQ7b AqR1Y6HUNvYTgT0E1DO0DzU48qncnpGWTJADx+mfRMMDzUgJ1i7PUuYxaYy81kJdqe4o PUDMDJAHVabZortvZ2Le3WNkaQ7KrTi1D6ix8MAuyatfWUE5qaAjyesTT+9iTv5kEtZl DzE3RZYufpZxZUMdH9iQPRf/p/zJV/yszjBT8l3wcThNu45KLZ429woUxodzphqbCNTz 7Oig== MIME-Version: 1.0 X-Received: by 10.181.13.204 with SMTP id fa12mr9936636wid.22.1383520711586; Sun, 03 Nov 2013 15:18:31 -0800 (PST) Received: by 10.227.202.194 with HTTP; Sun, 3 Nov 2013 15:18:31 -0800 (PST) In-Reply-To: <50D1FE75.9060709@nomadiclab.com> References: <50D1FE75.9060709@nomadiclab.com> Date: Sun, 3 Nov 2013 15:18:31 -0800 Message-ID: From: Martin Thomson To: Ari Keranen Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:18:33 -0000 On 19 December 2012 09:50, Ari Keranen wrote: > Any good ideas how to fix this? Should the controlling agent just keep > retransmitting even after successful nomination (for how long)? This specific problem came up when we were writing the CU-RTC-Web demo. It turns out that you can tell if a nomination is genuine by the fact that application data arrives. In this case, R notices that path 2 is both nominated AND live, then it switches to that path. From ari.keranen@ericsson.com Sun Nov 3 15:21:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2257511E824F for ; Sun, 3 Nov 2013 15:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVSM31qWdoNu for ; Sun, 3 Nov 2013 15:21:20 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1F421F9703 for ; Sun, 3 Nov 2013 15:21:19 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-af-5276da6e183d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.88.03802.E6AD6725; Mon, 4 Nov 2013 00:21:18 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 00:21:18 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D8584110475; Mon, 4 Nov 2013 01:21:17 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CF8D44EBB4; Mon, 4 Nov 2013 01:21:16 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 901CA4EB9E; Mon, 4 Nov 2013 01:21:15 +0200 (EET) Message-ID: <5276DA6D.9040904@ericsson.com> Date: Sun, 3 Nov 2013 15:21:17 -0800 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson , Philipp Hancke References: <520B299F.9060409@goodadvice.pages.de> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW7erbIggwlXRC3evp7KbHHtzD9G i6nLH7M4MHvsnHWX3eP2xC0sHkuW/GQKYI7isklJzcksSy3St0vgyrh57SZjwTbWijM7jrM2 MK5m6WJk55AQMJFYnNDFyAlkiUlcuLeerYuRi0NI4BAjkLODBcJZzygxd8JlKGcPo0T7hS6o srWMEgsbP7GA9IM5tz8YgNi8AtoSu9b0MoHYLAIqEp0L14PZbAL2EjcnXGcHsUUFkiWeXbjO DFEvKHFy5hOwOSIC0RJzfy4HqufgYBZQl7i6OAgkLCyQLnF2dzcjxN4PjBJXW5eA9XIKBErs fLeNFcRmFrCVuDDnOguELS+x/e0cZojf1CSuntvEDHGnqsTVf68YJzCKzkKyehaS9llI2hcw Mq9iZM9NzMxJLzfaxAiMhINbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGOtXnLPK5lcITlWTaVzbq/dk/oSO6+//v15zyu98wcvGN3HTCxZfDjGIe9yQ qtueWFZ6JkmJy2Bv/4U7V/3mJwVlVp5+k9v4Sbos8lt1/TavkNfevMYclw6bLj8c5p3R6Rc0 r+5X/4wXF+bM/dWTv6OuY3O00O5T1Q/vL5w45SvDAp3XtbPeqSmxFGckGmoxFxUnAgDiBcDI UgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:21:34 -0000 On 8/16/13 9:13 AM, Martin Thomson wrote: > On 16 August 2013 00:48, Philipp Hancke wrote: >> It's probably a good idea to mention this explicitly in 5245bis or >> draft-ietf-mmusic-ice-sip-sdp though. > > Mention, or just fix. > > I'm guessing that this has never really been tested in practice, so > fixing is probably quite feasible. Apparently a simple fix would be to make offered ice-ufrag max length in ICE-bis 255 (instead of 256). This would even be nicely backward-compatible since the other (legacy) endpoint can still offer 256 chars long ufrag and we would not end up exceeding the max length for STUN username. Cheers, Ari From ari.keranen@ericsson.com Sun Nov 3 15:23:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1111E8251 for ; Sun, 3 Nov 2013 15:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-jR4r06cO8J for ; Sun, 3 Nov 2013 15:23:40 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 867E811E8105 for ; Sun, 3 Nov 2013 15:23:39 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-e0-5276dafa5463 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 36.5D.27924.AFAD6725; Mon, 4 Nov 2013 00:23:38 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 00:23:37 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F1AA5110475; Mon, 4 Nov 2013 01:23:37 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E967F4EBB4; Mon, 4 Nov 2013 01:23:36 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 039714EB9E; Mon, 4 Nov 2013 01:23:35 +0200 (EET) Message-ID: <5276DAFA.2000301@ericsson.com> Date: Sun, 3 Nov 2013 15:23:38 -0800 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson References: <50D1FE75.9060709@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje6vW2VBBmvWyVpcO/OP0WLq8scs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG+kv3WQrmslY8WNTI3MA4maWLkZNDQsBE 4ur7BlYIW0ziwr31bF2MXBxCAocYJW7PXcEO4axnlHh/7TkzhLOHUeJa+3UWCGcto8Ta9d/Y 4Zz73/cDDePg4BXQlthxvxRkLouAisTbf2fAdrAJ2EqsfnUTbLeoQLLEswvXmUFsXgFBiZMz n4DFRQR0JRadfcAOMoZZQF3i6uIgkLCwgLnEo41r2EBsIYEiiW/354OVcwoESvRu+AA2hlnA QmLxm4PsELa8xPa3c5ghXlOTuHpuEzNEr6rE1X+vGCcwis5CsnkWkvZZSNoXMDKvYmTPTczM SS8338QIDPuDW34b7GDcdF/sEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODil GhhXlT76xrz9iGbU9Z+bzr7+K7bcKz/9+VqtXYX3S+emdc8K/Zqd/pbTY1EPF4NWsFBXgVnY o8lbzlovelrSriWSKup30d381rNKyTkGOUte1v7Sm9Ovu9D07r3Qs3UpKYclL0f+Yt2xxWy7 77rzm9l6dC3EU66djQv07L954o1jpW3uJC9voxlKLMUZiYZazEXFiQCay+SzSQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:23:46 -0000 On 11/3/13 3:18 PM, Martin Thomson wrote: > On 19 December 2012 09:50, Ari Keranen wrote: >> Any good ideas how to fix this? Should the controlling agent just keep >> retransmitting even after successful nomination (for how long)? > > This specific problem came up when we were writing the CU-RTC-Web > demo. It turns out that you can tell if a nomination is genuine by > the fact that application data arrives. In this case, R notices that > path 2 is both nominated AND live, then it switches to that path. Good point. How about if there's no application data to send before the NAT bindings time out? Cheers, Ari From martin.thomson@gmail.com Sun Nov 3 15:26:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EF611E824E for ; Sun, 3 Nov 2013 15:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJG52yGDNJX4 for ; Sun, 3 Nov 2013 15:26:02 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0420C21E8126 for ; Sun, 3 Nov 2013 15:25:54 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id f4so3072248wiw.16 for ; Sun, 03 Nov 2013 15:25:54 -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:content-transfer-encoding; bh=AI/HPzPDursnWLRbPSTHnS/rGjpkjfr88bW1EfQRVek=; b=bn3ZyBEzzHsQ3rZZCaF6THCf2lqWKJwv9+E4mUQ/0X8XtQ7kMIu6Vs3KoxkqtmSfkR CGTmZWwiziSwzbpjfPhpnwkyeZce1QecHVZOURmon3MfeEy/2EKNj3ITAiSh0Bu+pJJg f79WMrXFVD27HmsZ58JCOrMsHLs/fyVtSTUs2KRW/MfB3vHNsxmqBunv6yCsk5APtMWi /ehfxWUV07Wp2arlCevd317o4Xrbcbo96B9d1T28dAO252lvbv6md5NkmxmO0PSO2Tl/ 2lppZcXO8zFQ3PtV1bltfYI87k+poWfWsyG1SPdaFSXipwqU7zgYTbHgRBrEGEy6yIOt L4aQ== MIME-Version: 1.0 X-Received: by 10.194.78.51 with SMTP id y19mr164019wjw.62.1383521154058; Sun, 03 Nov 2013 15:25:54 -0800 (PST) Received: by 10.227.202.194 with HTTP; Sun, 3 Nov 2013 15:25:54 -0800 (PST) In-Reply-To: <5276DAFA.2000301@ericsson.com> References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> Date: Sun, 3 Nov 2013 15:25:54 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:26:04 -0000 On 3 November 2013 15:23, Ari Ker=C3=A4nen wrote= : > Good point. How about if there's no application data to send before the N= AT > bindings time out? Why did you want to use ICE then? :) From ari.keranen@ericsson.com Sun Nov 3 15:28:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1C121E8133 for ; Sun, 3 Nov 2013 15:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.838 X-Spam-Level: X-Spam-Status: No, score=-3.838 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jofA1zrK-Evj for ; Sun, 3 Nov 2013 15:28:08 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACBD11E8252 for ; Sun, 3 Nov 2013 15:28:05 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-12-5276dc00e598 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E5.AE.27941.00CD6725; Mon, 4 Nov 2013 00:28:01 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 00:28:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8CD8E110475; Mon, 4 Nov 2013 01:28:00 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 787C54EBB4; Mon, 4 Nov 2013 01:27:59 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EFF294EB9E; Mon, 4 Nov 2013 01:27:57 +0200 (EET) Message-ID: <5276DC00.9030007@ericsson.com> Date: Sun, 3 Nov 2013 15:28:00 -0800 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Martin Thomson References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvjS7jnbIggzPb+C2unfnHaDF1+WMW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj2Wq5gm9MFcemPWZuYFzC1MXIySEhYCKx dup2RghbTOLCvfVsXYxcHEICRxglDvdeYYJw1jNK9N+7wgLh7GGU2LqvEyqzllHi7517bHDO hZnTwIbxCmhLvJt5gwXEZhFQkbi66w3YQjYBW4nVr26CxUUFkiWeXbjODFEvKHFy5hOwuIiA rsSisw/Yuxg5OJgF1CWuLg4CCQsLmEs82rgGatd1oF3r1rCC1HAKBEpcP6UEUsMsYCGx+M1B dghbXqJ562xmiN/UJK6e2wRmCwmoSlz994pxAqPoLCSbZyFpn4WkfQEj8ypGjuLU4qTcdCOD TYzAwD+45bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXFF bfOXaWWXXKLe5C21eFZuevBpU4I+35lz53lkinj7pZ44WmoWH4984PCPbYt1dcbHUP6dR+aY nH/t+ySxe2P2sQe7TM70hbNHrDBgNKl8un8z0/ngmM0n/6X8ncmrOYtZ73vi/PiH3/8bdgXX zV58R/NG/SPtQH+nHwumno6Y5ingeeik01olluKMREMt5qLiRAAnbe16SgIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:28:14 -0000 On 11/3/13 3:25 PM, Martin Thomson wrote: > On 3 November 2013 15:23, Ari Keränen wrote: >> Good point. How about if there's no application data to send before the NAT >> bindings time out? > > Why did you want to use ICE then? :) Preemptive ICE in order to minimize setup delay? A corner-case of a corner-case? :) Cheers, Ari From emcho@sip-communicator.org Sun Nov 3 15:34:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0721E80A1 for ; Sun, 3 Nov 2013 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxlk77kDl8e3 for ; Sun, 3 Nov 2013 15:34:12 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id BB66F11E8252 for ; Sun, 3 Nov 2013 15:34:12 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kq14so6171994pab.7 for ; Sun, 03 Nov 2013 15:34:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=rOHa2dxVq3MJcqkzcgrZnMS45SnUeuzgLJ4ur6Y617c=; b=JWoja0lzOatn2RLlT/YSKbG8lTAAlx2TVuaWsGLakuGGdA8QMfJhE5NHSH0S7e9hNE CKmE7PO6gu7ycOQjLGXszJBUQrbzob8X10857JnGLi0E2wyiU88APhG6K1kymR5trB+K esbx/eUNG/o6lWBR08GG5DBOYoYT8ytHABjmQIculObgGIT0ynbosEKV3452RsjpHF1m 7ZKgw5C49BMZwD9C0+Q11ZBHlFA9fsah0yKvIOKZoV4viLQ5+tV5iRnxpGojqRTGdgSl 9jGAgciQ+XchI5TEe+z/4mCNKdoc0Q9FFp9ajlyEFOUS9JRsbLgggBK8YBOp/JR8zyyY At2Q== X-Gm-Message-State: ALoCoQmzCQwo56xiDD6gVS1VNN2zYIVJUmw3YyIkPYtVczctai35Q3mxU2UBvFWwBmTolYHtFSrU X-Received: by 10.66.52.19 with SMTP id p19mr3851822pao.123.1383521652335; Sun, 03 Nov 2013 15:34:12 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [2607:f8b0:400e:c01::232]) by mx.google.com with ESMTPSA id o1sm24311377pbe.37.2013.11.03.15.34.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:34:11 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id uo5so6467080pbc.9 for ; Sun, 03 Nov 2013 15:34:11 -0800 (PST) X-Received: by 10.66.142.107 with SMTP id rv11mr15119944pab.17.1383521651806; Sun, 03 Nov 2013 15:34:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Sun, 3 Nov 2013 15:33:50 -0800 (PST) In-Reply-To: <5276DC00.9030007@ericsson.com> References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> <5276DC00.9030007@ericsson.com> From: Emil Ivov Date: Mon, 4 Nov 2013 00:33:50 +0100 Message-ID: To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:34:17 -0000 Unless you maintain them, your candidates will timeout even with regular IC= E. If you do maintain them then you have data. Or am I missing something? Emil On Mon, Nov 4, 2013 at 12:28 AM, Ari Ker=E4nen w= rote: > On 11/3/13 3:25 PM, Martin Thomson wrote: >> >> On 3 November 2013 15:23, Ari Ker=E4nen wrote= : >>> >>> Good point. How about if there's no application data to send before the >>> NAT >>> bindings time out? >> >> >> Why did you want to use ICE then? :) > > > Preemptive ICE in order to minimize setup delay? A corner-case of a > corner-case? :) > > > Cheers, > Ari > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Sun Nov 3 15:38:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D280E11E8252 for ; Sun, 3 Nov 2013 15:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x5cG3Yw-DJQ for ; Sun, 3 Nov 2013 15:38:49 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A1D2421E8118 for ; Sun, 3 Nov 2013 15:38:40 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id ey11so3078917wid.1 for ; Sun, 03 Nov 2013 15:38:33 -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=DZZyipxCkwPhG+Xi7QroCEpNLWCXFEkGa9tvgSuk3BE=; b=usGUSpKjGY7s7HSPfw2qrVuGM0xKUpetcrfuAAvHIEjHxxF6LQ0Qq6LP/f6bI+lYoq Izepifnd8qzmkJHp4EWkgV9WxPCASe8PN60NgS7zHMK5NKXsIyhw9ZpQC62w38/RQpz7 O7LKc/+D6AoKmoZ1E44n2IkjsoD5etkPlWoWlr6qMPW24A/XkIC/RiPdRRuyzft9NDbt 8BXMq2WriXXdrJaAf4BSZhsYAf0YJlQ0HmHkX/mzpGEcVYFJQMCcKEqj1W+Pm5x5AMOh KqMVd7himBZwey94lgZEnilO6hDIw5Yn/EGP3eHmoLwnu3mJaSDuz+3d7jxFSX7yHyRK 5PKw== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr10196323wic.64.1383521913043; Sun, 03 Nov 2013 15:38:33 -0800 (PST) Received: by 10.227.202.194 with HTTP; Sun, 3 Nov 2013 15:38:32 -0800 (PST) In-Reply-To: References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> <5276DC00.9030007@ericsson.com> Date: Sun, 3 Nov 2013 15:38:32 -0800 Message-ID: From: Martin Thomson To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:38:54 -0000 On 3 November 2013 15:33, Emil Ivov wrote: > If you do maintain them then you have data. Well, DTLS heartbeats aren't really data. From emcho@sip-communicator.org Sun Nov 3 15:40:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E7721E8118 for ; Sun, 3 Nov 2013 15:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCggq94yKt7Z for ; Sun, 3 Nov 2013 15:40:45 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAEC21E80DC for ; Sun, 3 Nov 2013 15:40:42 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so6295302pad.13 for ; Sun, 03 Nov 2013 15:40:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RcNW3CLNGqzI7lITtXIwN5SLEzoWMLKrFAy6uTds2xY=; b=V/Sp++GApoEwYsch88wj6PY+gCoDZiP9CEZuqObT4hYRGoiSCk6sKs/Hs0SCJt1+Zk Bn+mc9YEon/mMwbc6DNDrnpX/UNv55dKOyk7aLDxzJUQBG96s5A81Mu/psphW0iGCl/P MMjBwqt1GxV33DwzFet4e4AtsO/lr0U7V9YHmugOuMkqHwnXRoZCyoYWTdEu9Be76xTH 0/dumfJPC+5P3V/HoAHABw6yMQj0bEAH5ZaQySqiA0/tIYh0iPqyfHGHxxC+BfoqFjTY phe3rxtCANRWOjgBTCdWlk0X4j+BLkF5VnSpSGRuaHDnVhGdQev+vBTNsH1ts7ZQdEeh tRQw== X-Gm-Message-State: ALoCoQl2X/es7RzUefi0xcQFTscB4/yJptFHXw9YtDMQuhVurhsBkBX7shU0O5OAaytAYqB9zus2 X-Received: by 10.66.218.226 with SMTP id pj2mr14856756pac.62.1383522041875; Sun, 03 Nov 2013 15:40:41 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [2607:f8b0:400e:c01::22f]) by mx.google.com with ESMTPSA id ye1sm28685646pab.19.2013.11.03.15.40.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:40:41 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rq13so2326529pbb.20 for ; Sun, 03 Nov 2013 15:40:41 -0800 (PST) X-Received: by 10.66.182.36 with SMTP id eb4mr3777184pac.125.1383522041382; Sun, 03 Nov 2013 15:40:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.191.163 with HTTP; Sun, 3 Nov 2013 15:40:21 -0800 (PST) In-Reply-To: References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> <5276DC00.9030007@ericsson.com> From: Emil Ivov Date: Mon, 4 Nov 2013 00:40:21 +0100 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2013 23:40:51 -0000 On Mon, Nov 4, 2013 at 12:38 AM, Martin Thomson wrote: > On 3 November 2013 15:33, Emil Ivov wrote: >> If you do maintain them then you have data. > > Well, DTLS heartbeats aren't really data. Not sure what you mean. From harald@alvestrand.no Sun Nov 3 16:25:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6988721E80C3 for ; Sun, 3 Nov 2013 16:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNm+DysCrqtS for ; Sun, 3 Nov 2013 16:25:03 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 634E211E8256 for ; Sun, 3 Nov 2013 16:25:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C843739E176; Mon, 4 Nov 2013 01:25:02 +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 QJNg1ad0k71N; Mon, 4 Nov 2013 01:25:02 +0100 (CET) Received: from [31.133.162.5] (dhcp-a205.meeting.ietf.org [31.133.162.5]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9196639E091; Mon, 4 Nov 2013 01:25:01 +0100 (CET) Message-ID: <5276E95B.5040909@alvestrand.no> Date: Mon, 04 Nov 2013 01:24:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Roni Even , 'mmusic' References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> <5276CE8B.8050809@alvestrand.no> <017801ced8e4$f6e021b0$e4a06510$@gmail.com> In-Reply-To: <017801ced8e4$f6e021b0$e4a06510$@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 00:25:09 -0000 On 11/03/2013 11:35 PM, Roni Even wrote: > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: 04 November, 2013 12:31 AM >> To: Roni Even; 'mmusic' >> Subject: Re: [MMUSIC] Some more APPID questions >> >> On 11/03/2013 10:49 PM, Roni Even wrote: >>> Hi Harald, >>> The current draft is still not mature enough and the presentation will >>> have some information which is not there and some of the text in the >>> 00 version that is not in the 01 version may come back. >>> >>> An SSRC can have multiple appIds example is in a three camera system >>> one appID for active speaker which is now the left camera having a >>> different appID >>> >>> The uniqueness of appID should be per media packet stream. >>> >> so if you have >> >> ssrc A: appid 45 >> ssrc B: appid 27 >> >> this means exactly the same thing as >> >> ssrc A: appid 45 >> ssrc B: appid 45 >> >> ? >> >> This seems to create issues when you have a single appid that is moving > around >> between SSRCs. > [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP header > extension, example is appID 45 that can be first SSRC A and then SSRC B if > appId represent the active speaker. > But if uniqueness of appids is per SSRC, then SSRC B might already be using appid 45 for something else. If we're using an appid for some property that can jump around between SSRCs, the uniqueness of that appid must be guaranteed over the whole context it's jumping around inside, I think. I'm worried if I can't figure out what that context is. -- Surveillance is pervasive. Go Dark. From ari.keranen@ericsson.com Sun Nov 3 19:38:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A8411E8152 for ; Sun, 3 Nov 2013 19:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2-x4q6CTAfc for ; Sun, 3 Nov 2013 19:38:26 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 97FC511E828D for ; Sun, 3 Nov 2013 19:38:21 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-e4-527716abbc50 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CD.65.27924.BA617725; Mon, 4 Nov 2013 04:38:20 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 04:38:19 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3708C1103E4; Mon, 4 Nov 2013 05:38:19 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E10244EB9E; Mon, 4 Nov 2013 05:38:17 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F3EC14EB9A; Mon, 4 Nov 2013 05:38:16 +0200 (EET) Message-ID: <527716A9.9090308@ericsson.com> Date: Sun, 3 Nov 2013 19:38:17 -0800 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Emil Ivov References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> <5276DC00.9030007@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje4asfIgg/ZTvBZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyjjcc5yt4DpLRecR0QbGa8xdjJwcEgImEj8u P4OyxSQu3FvP1sXIxSEkcIhRomfTHSYIZz2jxPSJKxghnD2MEm933mKBcNYySqzfcpMdpB/M aXyj0MXIwcEroC1x6pEhSJhFQEXi0umrTCA2m4C9xM0J18HKRQWSJZ5duA62mldAUOLkzCcs ILaIgLxEd9siJpAxzALqElcXB4GEhQXMJR5tXAN13R4miZ6O72D1nAKBEvP/HASbySxgK3Fh znUWCFteYvvbOVCvqUlcPbeJGeJMVYmr/14xTmAUnYVk9Swk7bOQtC9gZF7FyJ6bmJmTXm6+ iREY8ge3/DbYwbjpvtghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM4M 0NRZfkmGIcCel93iYUd3LPv8Xxw5rxfdW9R28TjbTr37eY9lXU4nRL/2C9dX5Iw/OOdMxXWb Y22X7tz7alOubLwh0fK1/Fyu6VnHbv8NO3F1TdGfqw0yi1cq+D28cHPlbMnLt2Ufr7ldcnM9 11fJvdeuHTGYfHS/Z8Avn6kPpkS822Q8p1pfiaU4I9FQi7moOBEAXXKZlEcCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 03:38:38 -0000 Hi Emil, On 11/3/13 3:33 PM, Emil Ivov wrote: > Unless you maintain them, your candidates will timeout even with regular ICE. > > If you do maintain them then you have data. If you don't have "real" data to send, by RFC5245 you would send keepalive traffic (STUN Binding Indications, RTP No-Ops, etc.). So in this case you should consider receiving any of them on a not-selected candidate pair as a sign to change using that candidate pair, right? I see at least some security issues here, but actually those apply also to non-secure application layer data. Cheers, Ari From fippo@goodadvice.pages.de Sun Nov 3 21:44:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68A11E82D7 for ; Sun, 3 Nov 2013 21:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e5TUcuq8R4g for ; Sun, 3 Nov 2013 21:44:28 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 55E6611E819A for ; Sun, 3 Nov 2013 21:44:28 -0800 (PST) Received: from [192.168.2.101] (p549730E0.dip0.t-ipconnect.de [84.151.48.224]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id rA45iNex000405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 06:44:25 +0100 Message-ID: <52773432.20100@goodadvice.pages.de> Date: Mon, 04 Nov 2013 06:44:18 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= References: <520B299F.9060409@goodadvice.pages.de> <5276DA6D.9040904@ericsson.com> In-Reply-To: <5276DA6D.9040904@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 05:44:34 -0000 > Apparently a simple fix would be to make offered ice-ufrag max length in > ICE-bis 255 (instead of 256). > > This would even be nicely backward-compatible since the other (legacy) > endpoint can still offer 256 chars long ufrag and we would not end up > exceeding the max length for STUN username. And on the other side, if an ice-bis endpoint receives a ice-ufrag of length 256 from a "legacy" endpoint, it can still restrict it's reply to 255 chars. This might be easier to describe as "accept 256 chars, but do not send more than 255 chars". That seems better than trying to figure out what should happen when we end up with 513 bytes, thanks. philipp From ari.keranen@ericsson.com Sun Nov 3 21:47:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1ED11E82E0 for ; Sun, 3 Nov 2013 21:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.62 X-Spam-Level: X-Spam-Status: No, score=-5.62 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqZct9i6m6Em for ; Sun, 3 Nov 2013 21:47:39 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 60C0211E82D7 for ; Sun, 3 Nov 2013 21:47:39 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-7c-527734f6b662 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 78.82.23787.6F437725; Mon, 4 Nov 2013 06:47:34 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 06:47:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 472BC110475; Mon, 4 Nov 2013 07:47:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 480CD4EB9E; Mon, 4 Nov 2013 07:47:32 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D6A604EB9A; Mon, 4 Nov 2013 07:47:30 +0200 (EET) Message-ID: <527734F3.4090901@ericsson.com> Date: Sun, 3 Nov 2013 21:47:31 -0800 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Philipp Hancke References: <520B299F.9060409@goodadvice.pages.de> <5276DA6D.9040904@ericsson.com> <52773432.20100@goodadvice.pages.de> In-Reply-To: <52773432.20100@goodadvice.pages.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje43k/Igg3lPDCzevp7KbHHtzD9G i6nLH7M4MHvsnHWX3eP2xC0sHkuW/GQKYI7isklJzcksSy3St0vgyph0fBtzQRdrxcPbB5kb GP8zdzFyckgImEj8mPGIDcIWk7hwbz2YLSRwiFHi1B3rLkYuIHs9o8SWbW9YIZw9jBJvPrWy QzhrGSX+P+phgXM+TFzC1MXIwcEroC0xa2U0yCgWARWJbb/bWUBsNgF7iZsTrrOD2KICyRLP LlwHO4NXQFDi5MwnYDUiAnoSG3etZQMZwywQInHhSChIWFggXeLs7m5GiOu2Mkmc/ZsLYnMK GEp8ObSbFcRmFrCVuDDnOguELS+x/e0cqC/VJK6e28QM0asqcfXfK8YJjKKzkGyehaR9FpL2 BYzMqxjZcxMzc9LLDTcxAiPh4JbfujsYT50TOcQozcGiJM774a1zkJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGvJL0W3v820V+nzu2Y4YGc4GVnu+qBT0Lv4Tfcf3VrXbVguP+9P+pOr4n 52TcWHNGdEnHrDi9m4VX3E7Mf6Wjmb94EYPgN/9dBsYnY3jm/OSeKrviyPYZLbyJF54ZrVDP cd069xOzFZP+LWU5h1YLdu8cDptPLhOYolLW7f+cev60Y53f9gAbJZbijERDLeai4kQA6lQ4 WFICAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 05:47:51 -0000 On 11/3/13 9:44 PM, Philipp Hancke wrote: >> Apparently a simple fix would be to make offered ice-ufrag max length in >> ICE-bis 255 (instead of 256). >> >> This would even be nicely backward-compatible since the other (legacy) >> endpoint can still offer 256 chars long ufrag and we would not end up >> exceeding the max length for STUN username. > > And on the other side, if an ice-bis endpoint receives a ice-ufrag of > length 256 from a "legacy" endpoint, it can still restrict it's reply to > 255 chars. > This might be easier to describe as "accept 256 chars, but do not send > more than 255 chars". Exactly. Cheers, Ari From ari.keranen@ericsson.com Sun Nov 3 22:40:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7736B11E82E7 for ; Sun, 3 Nov 2013 22:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ep4nA0VoiDH for ; Sun, 3 Nov 2013 22:39:54 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5208811E82D7 for ; Sun, 3 Nov 2013 22:39:46 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-d4-5277412adbac Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 21.65.23787.A2147725; Mon, 4 Nov 2013 07:39:38 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Mon, 4 Nov 2013 07:39:38 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 60BCE1103E4; Mon, 4 Nov 2013 08:39:38 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E38104EB9E; Mon, 4 Nov 2013 08:39:36 +0200 (EET) Received: from dhcp-91d2.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 95A2C4EB9A; Mon, 4 Nov 2013 08:39:31 +0200 (EET) Message-ID: <52774122.70502@ericsson.com> Date: Sun, 3 Nov 2013 22:39:30 -0800 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "mmusic@ietf.org" References: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvja6WY3mQwckT1hZTlz9msTixexuj A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWx9/hV5oIXLBX3Fp9ibGB8ydzFyMkhIWAi cfHvblYIW0ziwr31bF2MXBxCAocYJZq+d0M56xkl/h1vY4Zw9jBKHD57nR3CWcsosbz3Mwuc s/LcR3aQYbwCmhJtp7+zgdgsAioS+15vBYuzCdhL3JxwHcwWFUiWeHbhOjNEvaDEyZlPWEBs EYFYia8vZoEdJQxU833vM0YQW0jAR2LT7H9AvRwcnAK+Es82aoCEmQVsJS7Muc4CYctLbH87 B+o3NYmr5zYxQ7SqSlz994pxAqPILCTbZiFpn4WkfQEj8ypG9tzEzJz0csNNjMAAP7jlt+4O xlPnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsV5XacNNj6K1X+3b 3I+8usI3b3md6E4fwbzu/W++S7Yll3z+wTdbbZ36pN8SoROaRL4UulydtPZ4i/eXvIdu/zOf rrltJvfH9vlFJ9P87Ofi26KnB11TKrDfs41L+1bICV5G/iJ1K7nKRZrBB171FJfd+zlLquTi Bq/muxtyntzzeuJ8z00kUYmlOCPRUIu5qDgRAD8wyhE+AgAA Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-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: Mon, 04 Nov 2013 06:40:06 -0000 Hi, I think the algorithm starts to make sense, but how do you envision to choose the "N" and should there be a negotiation mechanism that ensures that both endpoints choose the same N? Cheers, Ari (as individual) On 8/25/13 11:42 PM, Tirumaleswar Reddy (tireddy) wrote: > Updated the Happy Eyeballs Extension for ICE Algorithm in section 4 > of the draft based on the comments received from the WG to update the > candidate priority such that some server-reflexive candidates have > higher priority than some IPv6 host candidates. > > Comments and Suggestions are welcome. > > -Authors. > From ron.even.tlv@gmail.com Mon Nov 4 00:05:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BFC11E80F2 for ; Mon, 4 Nov 2013 00:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcm2Ojzv+NyH for ; Mon, 4 Nov 2013 00:05:20 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8441E11E8109 for ; Mon, 4 Nov 2013 00:05:20 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id my12so912358bkb.10 for ; Mon, 04 Nov 2013 00:05:19 -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:thread-index :content-language; bh=EwgLs5L1np9odX65PjpFVy0Sf0z5VUcuJC1jypkFxCk=; b=Ioj/e/4n4PJ3BTR895mLiiPN/pX6hQNmxvIr6pDUeL2aY7tkj3BZmXj31zp4Y4ZHLc avNA1y54ycCw5qWCDhA3lgo69hNAoHOXPg5wK2v0coZz2C2mKTHORbrgX7yM6FgRBxFD oaM2PxcXfOGV8xxL5Rrqxf6CH4qduVtU/TwEsrak9lXzh6+tb8HU9FJzgTlwtreQXLAY enH5gSM66SlPpHXnKwwaaG+zsySCJYRaoZOT+LJdML18otmU3ebio1twGT1yRxsLTTtH 6r+MRzzsp83SO+0tHJJhKE1Iy1n4VJihzQ+O0UYJRc3FPsJ122Qy3VGO9U8bGJPWK1wd L++A== X-Received: by 10.205.64.16 with SMTP id xg16mr306766bkb.42.1383552319439; Mon, 04 Nov 2013 00:05:19 -0800 (PST) Received: from RoniE ([2001:67c:370:144:345d:3cd8:6b09:4b9c]) by mx.google.com with ESMTPSA id zl3sm13744062bkb.4.2013.11.04.00.05.17 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Nov 2013 00:05:18 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , "'mmusic'" References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> <5276CE8B.8050809@alvestrand.no> <017801ced8e4$f6e021b0$e4a06510$@gmail.com> <5276E95B.5040909@alvestrand.no> In-Reply-To: <5276E95B.5040909@alvestrand.no> Date: Mon, 4 Nov 2013 10:02:01 +0200 Message-ID: <023401ced934$26bab4a0$74301de0$@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: AQEJHLPXYj78WEr4Hhkvk0KFWNmBAwIZtPtxAkM5Q+cA47rwcgISIw/3m2WXMPA= Content-Language: en-us Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 08:05:21 -0000 Harald, If you map appID:45 to SSRC B also in RTP header and afterwards have appID:45 map to SSRC A it means that you replaced SSRC B with SSRC A for appId 45. The example is if appId 45 is the active speaker and it starts from left camera with SSRC B and changes to right camera with SSRC A. What is allowed is to have appID 45 and appID 27 both map to SSRC A. example is appID 45 is active speaker and appID 27 is left camera and left camera is the current active speaker. Roni > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: 04 November, 2013 2:25 AM > To: Roni Even; 'mmusic' > Subject: Re: [MMUSIC] Some more APPID questions > > On 11/03/2013 11:35 PM, Roni Even wrote: > > > >> -----Original Message----- > >> From: Harald Alvestrand [mailto:harald@alvestrand.no] > >> Sent: 04 November, 2013 12:31 AM > >> To: Roni Even; 'mmusic' > >> Subject: Re: [MMUSIC] Some more APPID questions > >> > >> On 11/03/2013 10:49 PM, Roni Even wrote: > >>> Hi Harald, > >>> The current draft is still not mature enough and the presentation > >>> will have some information which is not there and some of the text > >>> in the > >>> 00 version that is not in the 01 version may come back. > >>> > >>> An SSRC can have multiple appIds example is in a three camera system > >>> one appID for active speaker which is now the left camera having a > >>> different appID > >>> > >>> The uniqueness of appID should be per media packet stream. > >>> > >> so if you have > >> > >> ssrc A: appid 45 > >> ssrc B: appid 27 > >> > >> this means exactly the same thing as > >> > >> ssrc A: appid 45 > >> ssrc B: appid 45 > >> > >> ? > >> > >> This seems to create issues when you have a single appid that is > >> moving > > around > >> between SSRCs. > > [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP > > header extension, example is appID 45 that can be first SSRC A and > > then SSRC B if appId represent the active speaker. > > > > But if uniqueness of appids is per SSRC, then SSRC B might already be using > appid 45 for something else. > > If we're using an appid for some property that can jump around between > SSRCs, the uniqueness of that appid must be guaranteed over the whole context > it's jumping around inside, I think. I'm worried if I can't figure out what that > context is. > > -- > Surveillance is pervasive. Go Dark. From ron.even.tlv@gmail.com Mon Nov 4 00:21:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34F21F9C3A for ; Mon, 4 Nov 2013 00:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo9WXikigKaB for ; Mon, 4 Nov 2013 00:21:07 -0800 (PST) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4EA21F9CB5 for ; Mon, 4 Nov 2013 00:21:06 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id d7so1948506bkh.6 for ; Mon, 04 Nov 2013 00:21:05 -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:thread-index :content-language; bh=+hhgWTg1FSv5JwCpieeDv0GdYNJjK1qArYN+vIolwrA=; b=LOBb05ALglUmkYxCc3jUjQd6utzPVrES0vN4vVMm2J8jmQD2ibm8jr9r9+GyQvtrSy REEOf+2SUANm6HiHmaK7mG8p4w/aENpu/IJKJNMcM/3oXoEG+fuRQDok690lFRTaHQ3X JSSy4El0CbL8gmjHEPxc1FCxZLy1sqqjdURGsSgZ1iHUTwDJqUs15BXjTDc5zsHFJN2U DrhUeEHeen14o1chCCDc+nm+WsCQ8IVi0K5gLcZMLNcUV3Ivng3+2lxGPLk/1wb5Pz0M 3CceH0OSnPoKHFrP8fjiqowZVq0dKu97KZyaaxtAQMU9nsSQT4h0WqW2VpCXnKAkpvl+ JgOA== X-Received: by 10.204.169.80 with SMTP id x16mr73597bky.52.1383553265577; Mon, 04 Nov 2013 00:21:05 -0800 (PST) Received: from RoniE ([2001:67c:370:144:345d:3cd8:6b09:4b9c]) by mx.google.com with ESMTPSA id kk2sm13802493bkb.10.2013.11.04.00.21.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Nov 2013 00:21:05 -0800 (PST) From: "Roni Even" To: "'Martin Thomson'" References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> In-Reply-To: Date: Mon, 4 Nov 2013 10:17:48 +0200 Message-ID: <023501ced936$5b0b6d60$11224820$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJHLPXYj78WEr4Hhkvk0KFWNmBAwIZtPtxAjFsohubfdmucA== Content-Language: en-us Cc: 'mmusic' Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 08:21:07 -0000 Yes, packet stream. They keep changing the names. Roni > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: 04 November, 2013 12:05 AM > To: Roni Even > Cc: Harald Alvestrand; mmusic > Subject: Re: [MMUSIC] Some more APPID questions > > On 3 November 2013 13:49, Roni Even wrote: > > The uniqueness of appID should be per media packet stream. > > You mean "packet stream"? > > http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy- > 03#section-2.1.10 > > Because I don't think that that is particularly useful. From harald@alvestrand.no Mon Nov 4 03:54:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E6711E8133 for ; Mon, 4 Nov 2013 03:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIzJJbCUtwjM for ; Mon, 4 Nov 2013 03:54:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 705CD11E8101 for ; Mon, 4 Nov 2013 03:54:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B73039E1D5; Mon, 4 Nov 2013 12:54:43 +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 hf-uGRSVrNna; Mon, 4 Nov 2013 12:54:42 +0100 (CET) Received: from [31.133.162.5] (dhcp-a205.meeting.ietf.org [31.133.162.5]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6F34B39E1BA; Mon, 4 Nov 2013 12:54:41 +0100 (CET) Message-ID: <52778AFE.9020009@alvestrand.no> Date: Mon, 04 Nov 2013 12:54:38 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Roni Even , 'mmusic' References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> <5276CE8B.8050809@alvestrand.no> <017801ced8e4$f6e021b0$e4a06510$@gmail.com> <5276E95B.5040909@alvestrand.no> <023401ced934$26bab4a0$74301de0$@gmail.com> In-Reply-To: <023401ced934$26bab4a0$74301de0$@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 11:54:52 -0000 On 11/04/2013 09:02 AM, Roni Even wrote: > Harald, > > If you map appID:45 to SSRC B also in RTP header and afterwards have > appID:45 map to SSRC A it means that you replaced SSRC B with SSRC A for > appId 45. The example is if appId 45 is the active speaker and it starts > from left camera with SSRC B and changes to right camera with SSRC A. > > What is allowed is to have appID 45 and appID 27 both map to SSRC A. example > is appID 45 is active speaker and appID 27 is left camera and left camera is > the current active speaker. Roni, we are not communicating; I may not have expressed myself clearly. my question was "what's the scope of uniqueness for appIDs?" That is - within what context can I assume that two appIDs are different if they serve different purposes or identify different things - and what control point inside that context guarantees the uniqueness? I can imagine much confusion resulting from collision of appIDs, and want to know how I can be sure it won't happen. > > Roni > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: 04 November, 2013 2:25 AM >> To: Roni Even; 'mmusic' >> Subject: Re: [MMUSIC] Some more APPID questions >> >> On 11/03/2013 11:35 PM, Roni Even wrote: >>>> -----Original Message----- >>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>> Sent: 04 November, 2013 12:31 AM >>>> To: Roni Even; 'mmusic' >>>> Subject: Re: [MMUSIC] Some more APPID questions >>>> >>>> On 11/03/2013 10:49 PM, Roni Even wrote: >>>>> Hi Harald, >>>>> The current draft is still not mature enough and the presentation >>>>> will have some information which is not there and some of the text >>>>> in the >>>>> 00 version that is not in the 01 version may come back. >>>>> >>>>> An SSRC can have multiple appIds example is in a three camera system >>>>> one appID for active speaker which is now the left camera having a >>>>> different appID >>>>> >>>>> The uniqueness of appID should be per media packet stream. >>>>> >>>> so if you have >>>> >>>> ssrc A: appid 45 >>>> ssrc B: appid 27 >>>> >>>> this means exactly the same thing as >>>> >>>> ssrc A: appid 45 >>>> ssrc B: appid 45 >>>> >>>> ? >>>> >>>> This seems to create issues when you have a single appid that is >>>> moving >>> around >>>> between SSRCs. >>> [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP >>> header extension, example is appID 45 that can be first SSRC A and >>> then SSRC B if appId represent the active speaker. >>> >> But if uniqueness of appids is per SSRC, then SSRC B might already be > using >> appid 45 for something else. >> >> If we're using an appid for some property that can jump around between >> SSRCs, the uniqueness of that appid must be guaranteed over the whole > context >> it's jumping around inside, I think. I'm worried if I can't figure out > what that >> context is. >> >> -- >> Surveillance is pervasive. Go Dark. -- Surveillance is pervasive. Go Dark. From tireddy@cisco.com Mon Nov 4 06:01:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D633E11E81A7 for ; Mon, 4 Nov 2013 06:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDqgfbokmVcD for ; Mon, 4 Nov 2013 06:01:14 -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 3549E11E8264 for ; Mon, 4 Nov 2013 06:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1383573656; x=1384783256; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kmnepBSks2Gv3yQd0YNypzCyzvMWCVGYihDCPQsQgzA=; b=Qzp2hk40nwA3+fvT9xVsFhfkNTymheJoxxMfYRiDIWxWyGpT8eggLPoW 6gHysGRz9cyuKhWlOCoYlGS92Nddh9Qvxk6wICzrM/HqUOOyLFMSCjIyy v19qY6/sqgQ/EF6JEvVzU34LtZIzVMm+IlI/kJ1Fd3aNhvEThpNFX1ZAK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAESnd1KtJV2a/2dsb2JhbABZgweBC789gScWdIIlAQEBAwF3DgQCAQgRBAEBAQodBzIUCAEIAgQBEgiHcwa+KY8nOAaDGoEOA4kIoQuBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208";a="280387595" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2013 14:00:55 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4E0tLP007661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 14:00:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 08:00:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt Thread-Index: AQHOobGUnhOktz0LA0udxKThEjYwSZmmH+qggG9SggD//8VSIA== Date: Mon, 4 Nov 2013 14:00:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2425B748@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> <52774122.70502@ericsson.com> In-Reply-To: <52774122.70502@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-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: Mon, 04 Nov 2013 14:01:20 -0000 > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Monday, November 04, 2013 12:10 PM > To: Tirumaleswar Reddy (tireddy); mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic= -ice- > happy-eyeballs-02.txt >=20 > Hi, >=20 > I think the algorithm starts to make sense, but how do you envision to > choose the "N" and should there be a negotiation mechanism that ensures > that both endpoints choose the same N ? I don't think there is any need to negotiate about "N" because it's only lo= cal prioritization of candidates. ICE agent can use Happy Eyeballs Extensio= n for ICE algorithm independent of whether remote agent supports it or not.= =20 -Tiru. >=20 >=20 > Cheers, > Ari (as individual) >=20 > On 8/25/13 11:42 PM, Tirumaleswar Reddy (tireddy) wrote: > > Updated the Happy Eyeballs Extension for ICE Algorithm in section 4 > > of the draft based on the comments received from the WG to update the > > candidate priority such that some server-reflexive candidates have > > higher priority than some IPv6 host candidates. > > > > Comments and Suggestions are welcome. > > > > -Authors. > > From palmarti@cisco.com Mon Nov 4 06:52:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E29511E81F2 for ; Mon, 4 Nov 2013 06:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4vDQAQuu5qx for ; Mon, 4 Nov 2013 06:52:49 -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 B795B11E81FA for ; Mon, 4 Nov 2013 06:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1166; q=dns/txt; s=iport; t=1383576769; x=1384786369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8AFoLzHG5q5+oP95RnZmVzmlIWmFzAh6tjzD60zSfTk=; b=cZOJeEo3Uv8cflCczFHmvbhjUZji+XsY8lk9gVU1MM1xieaHZ6YB1te/ firVjVpZL6lFjwJwJ8HQ5RGTywc9EX9ZBCzKizV+7ZjEM/faiPGuRCfS0 7IJPe1cu/Whu1t6zNPFZFEtjumPmmynZs5/eDs7c3Djb6XrJy/uJ/lD6W U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADm0d1KtJV2c/2dsb2JhbABZgwc4U75yS4EoFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBYd7Bg2+LwSPJTMHgyCBDgOJCI8CkgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208";a="280416424" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 04 Nov 2013 14:52:47 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA4EqlsS011127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 14:52:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 08:52:47 -0600 From: "Pal Martinsen (palmarti)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] ICE aggressive nomination problem Thread-Index: AQHN3hFkukITmaAu2EWbze2Hkw+88ZoWfneAgAABbgCAAACiAIAAAJYAgAABoQCAAERNgIAAvG+A Date: Mon, 4 Nov 2013 14:52:46 +0000 Message-ID: References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> <5276DC00.9030007@ericsson.com> <527716A9.9090308@ericsson.com> In-Reply-To: <527716A9.9090308@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.214.203] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <424D16007A737D4FB832B54AE0A44CFD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 14:52:54 -0000 On 04 Nov 2013, at 04:38 am, Ari Ker=E4nen wrote= : > Hi Emil, >=20 > On 11/3/13 3:33 PM, Emil Ivov wrote: >> Unless you maintain them, your candidates will timeout even with regular= ICE. >>=20 >> If you do maintain them then you have data. >=20 > If you don't have "real" data to send, by RFC5245 you would send=20 > keepalive traffic (STUN Binding Indications, RTP No-Ops, etc.). So in=20 > this case you should consider receiving any of them on a not-selected=20 > candidate pair as a sign to change using that candidate pair, right? >=20 The simple use case here is presentation sharing. If you just plan to recei= ve a presentation you will never send any data. (Other than keepalives) Other protocols such as BFCP also sends very little data, but there are som= e initial HELOs there. .-. P=E5l-Erik > I see at least some security issues here, but actually those apply also=20 > to non-secure application layer data. >=20 >=20 > Cheers, > Ari >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From palmarti@cisco.com Mon Nov 4 06:52:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6982811E81FA for ; Mon, 4 Nov 2013 06:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quz7-6V4NFwX for ; Mon, 4 Nov 2013 06:52:49 -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 AB90D11E81F8 for ; Mon, 4 Nov 2013 06:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1166; q=dns/txt; s=iport; t=1383576768; x=1384786368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8AFoLzHG5q5+oP95RnZmVzmlIWmFzAh6tjzD60zSfTk=; b=CSNxvzEhON6xXRUkcFYBre0nehdpvYvb71IR/d5hidAZFFXyx+0WvZe+ NGVJU4nn//Yb/jF6LCxjJsB0r0Lz8evF1C/Bf3opI5Q/hG4iSZhKykqtn YeXcm23SG228hN5jbJ1mk/kl81cH+H4sgVcFZwAgjwdfYhkZiS+A8/aeJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAO6zd1KtJV2Z/2dsb2JhbABZgwc4U75yS4EoFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBYd7Bg2+MwSPJTMHgyCBDgOJCI8CkgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208";a="280401812" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 04 Nov 2013 14:52:48 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA4EqlYf025393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 14:52:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 08:52:47 -0600 From: "Pal Martinsen (palmarti)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] ICE aggressive nomination problem Thread-Index: AQHN3hFkukITmaAu2EWbze2Hkw+88ZoWfneAgAABbgCAAACiAIAAAJYAgAABoQCAAERNgIAAvG+A Date: Mon, 4 Nov 2013 14:52:46 +0000 Message-ID: <5A15970D-AAF4-4DF4-8286-6C27892171BE@cisco.com> References: <50D1FE75.9060709@nomadiclab.com> <5276DAFA.2000301@ericsson.com> <5276DC00.9030007@ericsson.com> <527716A9.9090308@ericsson.com> In-Reply-To: <527716A9.9090308@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.214.203] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <34B7C9DDBED6504CAC9DB47654F02B3C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE aggressive nomination problem X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 14:52:54 -0000 On 04 Nov 2013, at 04:38 am, Ari Ker=E4nen wrote= : > Hi Emil, >=20 > On 11/3/13 3:33 PM, Emil Ivov wrote: >> Unless you maintain them, your candidates will timeout even with regular= ICE. >>=20 >> If you do maintain them then you have data. >=20 > If you don't have "real" data to send, by RFC5245 you would send=20 > keepalive traffic (STUN Binding Indications, RTP No-Ops, etc.). So in=20 > this case you should consider receiving any of them on a not-selected=20 > candidate pair as a sign to change using that candidate pair, right? >=20 The simple use case here is presentation sharing. If you just plan to recei= ve a presentation you will never send any data. (Other than keepalives) Other protocols such as BFCP also sends very little data, but there are som= e initial HELOs there. .-. P=E5l-Erik > I see at least some security issues here, but actually those apply also=20 > to non-secure application layer data. >=20 >=20 > Cheers, > Ari >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@ericsson.com Mon Nov 4 07:55:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B115821E817E for ; Mon, 4 Nov 2013 07:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.493 X-Spam-Level: X-Spam-Status: No, score=-5.493 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVEnb4csQrZZ for ; Mon, 4 Nov 2013 07:55:42 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEDB21E8184 for ; Mon, 4 Nov 2013 07:55:29 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-b9-5277c36a022b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 40.E8.27924.A63C7725; Mon, 4 Nov 2013 16:55:22 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.37]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Mon, 4 Nov 2013 16:55:21 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt Thread-Index: Ac7ZKKIa6GJ7VIkmRteG/mt4PNjpFQANUMMAAAP/Q4A= Date: Mon, 4 Nov 2013 15:55:21 +0000 Message-ID: <861759C7815040489720E3CC184F51DD1C4A517B@ESESSMB205.ericsson.se> References: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> <52774122.70502@ericsson.com> <913383AAA69FF945B8F946018B75898A2425B748@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2425B748@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <93E4FB138524B046910027FCA1EBD332@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+JvjW7W4fIgg327JSymLn/MYnFi9zZG ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjwulVbAU/OSr+N+9jamBcwd7FyMkhIWAi sWXJb0YIW0ziwr31bF2MXBxCAocYJS52vGKFcBYxSkw/NYMNpIpNwF5i8pqPYB0iAmYSe5e1 A9kcHMwC6hJXFweBhIUFUiWuH1rADFGSJvF+6k2ociuJZUumgS1mEVCRmDnlJ1icV8BXYu+e rcwQu9YzSsw5f4cVJMEJlJi2ai7YIEag676fWsMEYjMLiEvcejKfCeJqAYkle84zQ9iiEi8f /2OFsJUkGpc8YYWo15O4MXUKG4RtLXG5ZzULhK0tsWzha2aIIwQlTs58wjKBUXwWkhWzkLTP QtI+C0n7LCTtCxhZVzGy5yZm5qSXm29iBEbVwS2/DXYwbrovdohRmoNFSZz3w1vnICGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MbmHrHlsuEWPcseqb3ul930s5HuXm6MZ8YpdntJhgX6LS cGfqAS6e+vm3JixUdeHde+jJYs6uYr402S98Szt3KYoc0InZ0D/vsg6j9zELye3tKwVV4o0e rJm25FlBVUJPx4+dL/LfKeqHiy9VPRu6+H/LGc3kcOOSqIxlJzY7zWZnevN4fXaOEktxRqKh FnNRcSIA8DfddngCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-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: Mon, 04 Nov 2013 15:55:47 -0000 On Nov 4, 2013, at 6:00 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] >> Sent: Monday, November 04, 2013 12:10 PM >> To: Tirumaleswar Reddy (tireddy); mmusic@ietf.org >> Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusi= c-ice- >> happy-eyeballs-02.txt >>=20 >> Hi, >>=20 >> I think the algorithm starts to make sense, but how do you envision to >> choose the "N" and should there be a negotiation mechanism that ensures >> that both endpoints choose the same N ? >=20 > I don't think there is any need to negotiate about "N" because it's only = local prioritization of candidates. ICE agent can use Happy Eyeballs Extens= ion for ICE algorithm independent of whether remote agent supports it or no= t.=20 Have you done an exercise (or better, implementation?) on how the candidate= pairs would then look like? Since ICE uses MAX/MIN sorting of the pairs (s= ee http://tools.ietf.org/html/rfc5245#appendix-B.5) simply having high prio= rity on the other side may not give the results you want. Cheers, Ari= From jonathan@vidyo.com Mon Nov 4 07:57:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDE821E81A5 for ; Mon, 4 Nov 2013 07:57:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE7ozncomipN for ; Mon, 4 Nov 2013 07:57:34 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id C462721E8174 for ; Mon, 4 Nov 2013 07:57:17 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/4/2013 10:57:07 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-152/SG:2 11/4/2013 10:56:44 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.724805 p=-0.906526 Source Normal X-Signature-Violations: 0-0-0-9615-c X-Note-419: 31.2004 ms. Fail:0 Chk:1349 of 1349 total X-Note: SCH-CT/SI:0-1349/SG:1 11/4/2013 10:56:53 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 45147001; Mon, 04 Nov 2013 10:57:07 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0146.000; Mon, 4 Nov 2013 09:57:06 -0600 From: Jonathan Lennox To: Harald Alvestrand Thread-Topic: [MMUSIC] Some more APPID questions Thread-Index: AQHO2W8J9WTQm0i/H0SODxhsmcJI+JoVnrkA Date: Mon, 4 Nov 2013 15:57:05 +0000 Message-ID: <7BF287D7-BF89-4F9C-BA50-61562713C2CD@vidyo.com> References: <52769448.7080606@alvestrand.no> <017001ced8de$a268f590$e73ae0b0$@gmail.com> <5276CE8B.8050809@alvestrand.no> <017801ced8e4$f6e021b0$e4a06510$@gmail.com> <5276E95B.5040909@alvestrand.no> <023401ced934$26bab4a0$74301de0$@gmail.com> <52778AFE.9020009@alvestrand.no> In-Reply-To: <52778AFE.9020009@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.140.141] Content-Type: text/plain; charset="us-ascii" Content-ID: <71C408753CFD7E438BACFB043CAC8B01@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Some more APPID questions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:57:45 -0000 AppIDs need to be unique with an RTP session in order to work for the use c= ases we've identified so far. There may be use cases that would like to define them to be unique more bro= adly -- presumably within a multimedia session, across several RTP sessions= -- and enforcing that wouldn't break anything about the mechanism, I think= , if it turns out to be useful. It's the responsibility of the signaling mechanism that negotiates the AppI= D values to ensure uniqueness. The current draft is a little vague on how = you do this in SDP, because we haven't quite figured out how much AppID val= ues should be receiver-selected vs. sender-selected. (Sender-selected make= s more sense conceptually, but doesn't solve the Bundle early-media race co= ndition with an offered recvonly stream.) On Nov 4, 2013, at 3:54 AM, Harald Alvestrand wrote: > On 11/04/2013 09:02 AM, Roni Even wrote: >> Harald, >>=20 >> If you map appID:45 to SSRC B also in RTP header and afterwards have >> appID:45 map to SSRC A it means that you replaced SSRC B with SSRC A for >> appId 45. The example is if appId 45 is the active speaker and it starts >> from left camera with SSRC B and changes to right camera with SSRC A. >>=20 >> What is allowed is to have appID 45 and appID 27 both map to SSRC A. exa= mple >> is appID 45 is active speaker and appID 27 is left camera and left camer= a is >> the current active speaker. >=20 > Roni, >=20 > we are not communicating; I may not have expressed myself clearly. >=20 > my question was "what's the scope of uniqueness for appIDs?" >=20 > That is - within what context can I assume that two appIDs are different > if they serve different purposes or identify different things - and what > control point inside that context guarantees the uniqueness? >=20 > I can imagine much confusion resulting from collision of appIDs, and > want to know how I can be sure it won't happen. >=20 >=20 >>=20 >> Roni >>=20 >>> -----Original Message----- >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>> Sent: 04 November, 2013 2:25 AM >>> To: Roni Even; 'mmusic' >>> Subject: Re: [MMUSIC] Some more APPID questions >>>=20 >>> On 11/03/2013 11:35 PM, Roni Even wrote: >>>>> -----Original Message----- >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>> Sent: 04 November, 2013 12:31 AM >>>>> To: Roni Even; 'mmusic' >>>>> Subject: Re: [MMUSIC] Some more APPID questions >>>>>=20 >>>>> On 11/03/2013 10:49 PM, Roni Even wrote: >>>>>> Hi Harald, >>>>>> The current draft is still not mature enough and the presentation >>>>>> will have some information which is not there and some of the text >>>>>> in the >>>>>> 00 version that is not in the 01 version may come back. >>>>>>=20 >>>>>> An SSRC can have multiple appIds example is in a three camera system >>>>>> one appID for active speaker which is now the left camera having a >>>>>> different appID >>>>>>=20 >>>>>> The uniqueness of appID should be per media packet stream. >>>>>>=20 >>>>> so if you have >>>>>=20 >>>>> ssrc A: appid 45 >>>>> ssrc B: appid 27 >>>>>=20 >>>>> this means exactly the same thing as >>>>>=20 >>>>> ssrc A: appid 45 >>>>> ssrc B: appid 45 >>>>>=20 >>>>> ? >>>>>=20 >>>>> This seems to create issues when you have a single appid that is >>>>> moving >>>> around >>>>> between SSRCs. >>>> [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP >>>> header extension, example is appID 45 that can be first SSRC A and >>>> then SSRC B if appId represent the active speaker. >>>>=20 >>> But if uniqueness of appids is per SSRC, then SSRC B might already be >> using >>> appid 45 for something else. >>>=20 >>> If we're using an appid for some property that can jump around between >>> SSRCs, the uniqueness of that appid must be guaranteed over the whole >> context >>> it's jumping around inside, I think. I'm worried if I can't figure out >> what that >>> context is. >>>=20 >>> -- >>> Surveillance is pervasive. Go Dark. >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 From partha@parthasarathi.co.in Mon Nov 4 09:22:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBE821E8153 for ; Mon, 4 Nov 2013 09:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu+ZlSC7GFig for ; Mon, 4 Nov 2013 09:22:14 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0E77B11E8235 for ; Mon, 4 Nov 2013 09:15:36 -0800 (PST) Received: from userPC (unknown [122.179.36.6]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 7D5BF868BE7; Mon, 4 Nov 2013 17:15:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1383585333; bh=WkjxN3lk7hw73Tc8Pk27gwp2YS/5O1W5vJ2E9R2dJ+M=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=US5PylRuQ5bUj6GEc7horPTh6B1Imo1Gwoxtm5Zs486a7OrybcdHJO2gpF1T72Voq 0LMF1razxTDEWSRTFVTGak/lF+8e4y+PM7gU8rG28aJBzWlntSbiUYhgV3zkL8yLyI C73Q7ZTiDQfXuQZXv7R51IqK9FTmQjXnj44zzlgk= From: "Parthasarathi R" To: "'SM'" , References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> In-Reply-To: <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> Date: Mon, 4 Nov 2013 22:45:26 +0530 Message-ID: <00a101ced981$77414d60$65c3e820$@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: Ac7WCf0ecmMN+0M+TSWjaJaWZaJOMwDdDmjw Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.5277D635.0194, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:22:20 -0000 Sm, Please read inline. Thanks Partha/Muthu > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of SM > Sent: Thursday, October 31, 2013 9:07 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Last Call: 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) > to Proposed Standard > > At 06:17 30-10-2013, The IESG wrote: > >The IESG has received a request from the Multiparty Multimedia Session > >Control WG (mmusic) to consider the following document: > >- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B' > > as Proposed Standard > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send substantive comments to the > >ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments may > be > > I read this draft quickly. According to the 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 Session > Description > protocol(SDP) offer and answer. This document provides the offer/ > answer considerations for these parameters and updates RFC4856." > > RFC 4856 is about media type registration of payload formats. Agreed The > IESG approval mentioned that the document "specify the procedure to > register RTP payload formats as audio, video or other media subtype > names". The RFC does not specify the AnnexA parameter for G723. Agreed. RFC4856 describes AnnexA parameter for G723. I > took a quick look at the RFCs being referenced. They are about media > type registrations. It is doubtful whether they even qualify for > Proposed Standard. RFC4856 is published as proposed standard in IETF > > The premise on which the work in this draft is built is lacking. The premise on which the work in this draft is already well described in the abstract itself The > draft mentions > G723 Annex A without providing any reference to the > specification. G723 annexa SDP attribute is defined in RFC 4856. In my opinion the draft needs more work for it to be > a Proposed Standard. Could you please list the work which has to be done for this draft It doesn't look like there has been any > discussion about whether there are IPR issues affecting > implementations. > The authors are not aware of any IPR related to this issue. This has been communicated to MMUSIC WG Chairs > Regards, > -sm > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Mon Nov 4 10:33:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE49521E8191 for ; Mon, 4 Nov 2013 10:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTgesu1MDfCX for ; Mon, 4 Nov 2013 10:33:33 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 378D021E8190 for ; Mon, 4 Nov 2013 10:33:33 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex4so987053wid.15 for ; Mon, 04 Nov 2013 10:33:32 -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=nMZNMrJe3jRGjDt5p/U3Z+gCnM2oLZwEpu9mSihPN3I=; b=fTqiqz0zTtQKrrYxHHtbe25YVb70yPNvSPvR+cdeNWDPAV8X1gyiJ1ORceM2SgnHVl wcOXyFVh4Ql4Qd2+0zpcawj2bvEHtCqmAAdqfZyMC6b10b/yFcCc0rIOZmN6QR9RZAyp 5IUF8SdPC9eAew3J6uVoUKduuSKgGNN560WJPbckM6k+ULrmwmZsB8vj9eBtLweyfAwW WLm5n0H3m7noQI73I//a+DARgiyOB4aTWnLGeEgAjCpNOcGD3qZxDdtVl6E1PAxELGBk L+vkadbuvumB3X+38ICmJoXjw5RTioyQqwqMVC3BjTvtbhDvHkGxIrhKR4YtIFz25165 rP/Q== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr13680851wij.30.1383590012466; Mon, 04 Nov 2013 10:33:32 -0800 (PST) Received: by 10.227.202.194 with HTTP; Mon, 4 Nov 2013 10:33:32 -0800 (PST) Date: Mon, 4 Nov 2013 10:33:32 -0800 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] Default 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: Mon, 04 Nov 2013 18:33:34 -0000 The text is currently a little vague in RFC 5245 on what you select here: is it the candidate most likely to succeed? or is it the candidate most like to be selected? From emcho@sip-communicator.org Mon Nov 4 11:11:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C51E11E821C for ; Mon, 4 Nov 2013 11:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr8-ct9MgmvI for ; Mon, 4 Nov 2013 11:11:37 -0800 (PST) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBE221E81C4 for ; Mon, 4 Nov 2013 11:11:32 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id x10so7016411pdj.40 for ; Mon, 04 Nov 2013 11:11:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/TJVAps+q7o2HMRgfWeUj/U4J25ySNnenJbutziahFc=; b=RLg7+gY7eiDw30e6Y/VRyqKz02B2gqRUiKxGVmdM12uCC+aH0cdlWsKlkcO2BzK8k+ /E8RI7QYM+muOCjVuig8YRKWwuRzV8pRloACAo9tO2QHpY2VbQnVZFrrWNvQXGHcskAz 6IEOH76yu/kJNI0MK66jfWnhbjQ/m4cXpZMNC7x6MNBJP7B5PMIuNc1KcWR9EeNg9gdu 6YNoEoKvcNhAQgh+yRrCMKo55w1h1a6vIBxDMLgQ9tlwy4Qs91RYNRqdujTw+QtgSUZT eRiuL0QD3PXV+Dgw+hmbks/kGIyfQPZt9zf5JwOVy92zLEAk9BorLJtMqZzhJIsryE37 lhTA== X-Gm-Message-State: ALoCoQn7sw9xdMzbqh7JGKpEQPtWOybgDcsvqnlGAesN2pz51GvK0rHLpQe5SpDlH39gNCpA7Osm X-Received: by 10.66.182.199 with SMTP id eg7mr4409164pac.135.1383592291850; Mon, 04 Nov 2013 11:11:31 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [2607:f8b0:400e:c01::230]) by mx.google.com with ESMTPSA id pl1sm29725092pbb.20.2013.11.04.11.11.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 11:11:30 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id mc17so7496193pbc.21 for ; Mon, 04 Nov 2013 11:11:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.25.82 with SMTP id a18mr2618806pag.171.1383592290876; Mon, 04 Nov 2013 11:11:30 -0800 (PST) Received: by 10.66.191.163 with HTTP; Mon, 4 Nov 2013 11:11:30 -0800 (PST) Received: by 10.66.191.163 with HTTP; Mon, 4 Nov 2013 11:11:30 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Nov 2013 20:11:30 +0100 Message-ID: From: Emil Ivov To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec52992530324c204ea5eaf7b Cc: mmusic Subject: Re: [MMUSIC] Default 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: Mon, 04 Nov 2013 19:11:41 -0000 --bcaec52992530324c204ea5eaf7b Content-Type: text/plain; charset=ISO-8859-1 Relayed candidates are currently RECOMMENDED, which sounds reasonable. Still, if those are not available, 5245 recommends server reflexive. This may be problematic in cases where servers that perform latching only do it for addresses they consider "private". --sent from my mobile On 4 Nov 2013 19:34, "Martin Thomson" wrote: > The text is currently a little vague in RFC 5245 on what you select here: > > is it the candidate most likely to succeed? > > or > > is it the candidate most like to be selected? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --bcaec52992530324c204ea5eaf7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Relayed candidates are currently RECOMMENDED, which sounds r= easonable.

Still, if those are not available, 5245 recommends server re= flexive. This may be problematic in cases where servers that perform latchi= ng only do it for addresses they consider "private".

--sent from my mobile

On 4 Nov 2013 19:34, "Martin Thomson" = <martin.thomson@gmail.com> wrote:
The text is currently a little vague in RFC 5245 on what you select here:
is it the candidate most likely to succeed?

or

is it the candidate most like to be selected?
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--bcaec52992530324c204ea5eaf7b-- From suhasietf@gmail.com Mon Nov 4 13:14:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508BF21E8103 for ; Mon, 4 Nov 2013 13:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1pMbhWuo54K for ; Mon, 4 Nov 2013 13:14:56 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id A500B21E80AA for ; Mon, 4 Nov 2013 13:14:55 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn9so1190445wib.17 for ; Mon, 04 Nov 2013 13:14:54 -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=xXGluPRObFMlR6HSoqnP14jamX9lGu8jEVvlGpaUt1g=; b=gprEkBstQ8Uc+uqoulWO7cAWL7qzFHkWNn/AelT8IXF0SLFDGlUYOhxdIVMYTkbeht vdhG/JcNSlPcGSxDSi6xZ9gwAuSOqG1Wz23FehJVdWt1jb9lCU5p9n91UifAE7HMXGVI udXHmye03oNUDOcDmZ4mTpl0C9/cfm82shKW+69RspxbP+jHhayfyWsYCeXllgyNzydA t2jg1vU6bw0MHQz1RCFTLL//97vVsFV10RugWFKQXgJ8jy00ev0YJJsVPirQkzxDm6aA fpkfzHdHCeIKX0tamZMzLZtDA16bHib/1+4DIn+PUmcTr50JDQ+bcr8EjgSLvM62oA3p XFFg== MIME-Version: 1.0 X-Received: by 10.194.78.141 with SMTP id b13mr6856764wjx.32.1383599694921; Mon, 04 Nov 2013 13:14:54 -0800 (PST) Received: by 10.194.178.231 with HTTP; Mon, 4 Nov 2013 13:14:54 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Nov 2013 13:14:54 -0800 Message-ID: From: Suhas Nandakumar To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bfcfc8253c4a504ea60684e Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Default 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: Mon, 04 Nov 2013 21:14:57 -0000 --047d7bfcfc8253c4a504ea60684e Content-Type: text/plain; charset=ISO-8859-1 I interpreted it to be the one "most likely to used" when the ICE completes thus forming the default destination for media reception.. On Mon, Nov 4, 2013 at 10:33 AM, Martin Thomson wrote: > The text is currently a little vague in RFC 5245 on what you select here: > > is it the candidate most likely to succeed? > > or > > is it the candidate most like to be selected? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bfcfc8253c4a504ea60684e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I interpreted it to be the one "most likely to used&q= uot; when the ICE completes thus forming the default destination for media = reception..


<= br>
On Mon, Nov 4, 2013 at 10:33 AM, Martin Thom= son <martin.thomson@gmail.com> wrote:
The text is currently a little vague in RFC 5245 on what you select here:
is it the candidate most likely to succeed?

or

is it the candidate most like to be selected?
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

--047d7bfcfc8253c4a504ea60684e-- From ari.keranen@ericsson.com Tue Nov 5 09:49:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D05611E81BD for ; Tue, 5 Nov 2013 09:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.641 X-Spam-Level: X-Spam-Status: No, score=-5.641 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYrDJpXctBvG for ; Tue, 5 Nov 2013 09:48:55 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0AF11E81A3 for ; Tue, 5 Nov 2013 09:48:34 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-1b-52792f71f632 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.5F.27924.17F29725; Tue, 5 Nov 2013 18:48:33 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Tue, 5 Nov 2013 18:48:31 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DF14D110298; Tue, 5 Nov 2013 19:48:31 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C497E51DAA; Tue, 5 Nov 2013 19:48:30 +0200 (EET) Received: from dhcp-a737.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 87F6251D0E; Tue, 5 Nov 2013 19:48:29 +0200 (EET) Message-ID: <52792F6E.9070302@ericsson.com> Date: Tue, 5 Nov 2013 09:48:30 -0800 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Suhas Nandakumar , Martin Thomson , Emil Ivov References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvjW6hfmWQwbZL/BZrdk5gsbh25h+j xdTlj1ksds7tYHZg8dg56y67x5IlP5k8/r8JDGCO4rJJSc3JLEst0rdL4Mo42X+WqWAPV8XD Le+YGxibOLoYOTkkBEwkXs95zA5hi0lcuLeerYuRi0NI4BCjxLIX59ghnPWMEquuNoBVCQns YZQ4cD0bIrGWUWL6kenMcM7U49tZQap4BbQlnp+dDGazCKhIbNjyAMxmE7CXuDnhOtgkUYFk iWcXrjND1AtKnJz5hKWLkYNDRKBEYtnHYBCTWUBd4uriIJAKYQEdiU8fW6FWTWWUWLPjPBNI glMgUGL6te1gI5kFbCUuzLnOAmHLS2x/O4cZ4jU1iavnNjFDPKAqcfXfK8YJjKKzkGyehaR9 FpL2BYzMqxjZcxMzc9LLzTcxAmPi4JbfBjsYN90XO8QozcGiJM774a1zkJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQbG2E0n3hfPPM8vutFS9kl1lcq0zbpJR3gtul6eyKsOZXprf0nJqEVr QrLPGj42OetzT6W2zBW51eB9es/aPPO3IcmPTauSP0ma1h2eelav5MXJzJy8HdpB9smLnGQE 1myIsZC60JceX2jKkxV5gmcZ67LsFoGcIx98clpvLauasMVPiYfJ/JkSS3FGoqEWc1FxIgC/ OtCjVwIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE Default 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, 05 Nov 2013 17:49:02 -0000 Hi, The ICE default candidate should be such that there's a good chance for it to work even without ICE. Hence relayed candidates are suggested, as Emil pointed out. But apparently Martin was very much correct about the fact that this should be clarified. The current text says: > It is RECOMMENDED that default candidates be chosen based on the > likelihood of those candidates to work with the peer that is being > contacted. It is RECOMMENDED that the default candidates are the > relayed candidates (if relayed candidates are available), server > reflexive candidates (if server reflexive candidates are available), > and finally host candidates. Perhaps the first sentence should be extended with " [...] even if ICE is not used"? Cheers, Ari On 11/4/13 1:14 PM, Suhas Nandakumar wrote: > I interpreted it to be the one "most likely to used" when the ICE > completes thus forming the default destination for media reception.. > > > > > On Mon, Nov 4, 2013 at 10:33 AM, Martin Thomson > > wrote: > > The text is currently a little vague in RFC 5245 on what you select > here: > > is it the candidate most likely to succeed? > > or > > is it the candidate most like to be selected? From internet-drafts@ietf.org Tue Nov 5 14:05:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAB621F9EAF; Tue, 5 Nov 2013 14:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUi1A+ZF1dx7; Tue, 5 Nov 2013 14:05:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FC621F9E43; Tue, 5 Nov 2013 14:05:25 -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.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131105220525.29536.93101.idtracker@ietfa.amsl.com> Date: Tue, 05 Nov 2013 14:05:25 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:05:27 -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 : Cross Session Stream Identification in the Session Descr= iption Protocol Author(s) : Harald Alvestrand Filename : draft-ietf-mmusic-msid-02.txt Pages : 15 Date : 2013-11-05 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "m-line" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-msid-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-msid-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From harald@alvestrand.no Tue Nov 5 15:09:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A77811E8179 for ; Tue, 5 Nov 2013 15:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ8-j2OA7mg5 for ; Tue, 5 Nov 2013 15:09:15 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8711E812A for ; Tue, 5 Nov 2013 15:09:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C38E39E199 for ; Wed, 6 Nov 2013 00:09:13 +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 ja+7bWF3m5Z2 for ; Wed, 6 Nov 2013 00:09:12 +0100 (CET) Received: from [IPv6:2001:67c:370:176:2dfc:8adb:553b:335e] (unknown [IPv6:2001:67c:370:176:2dfc:8adb:553b:335e]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9079F39E0E1 for ; Wed, 6 Nov 2013 00:09:11 +0100 (CET) Message-ID: <52797A94.8010706@alvestrand.no> Date: Wed, 06 Nov 2013 00:09:08 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mmusic References: <20131105220526.29536.55211.idtracker@ietfa.amsl.com> In-Reply-To: <20131105220526.29536.55211.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <20131105220526.29536.55211.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060501010403060705040706" Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-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: Tue, 05 Nov 2013 23:09:20 -0000 This is a multi-part message in MIME format. --------------060501010403060705040706 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit As promised, I have updated the msid draft with the fixes mentioned on Monday. I have also included some additional clarifications that came in on the mailing list. One question: Should I move the Appendix B material on ssrc-marking back into the main body, so that the tool is available for non-WebRTC semantics, where UnifiedPlan is not being applied? Harald -------- Original Message -------- Subject: New Version Notification for draft-ietf-mmusic-msid-02.txt Date: Tue, 05 Nov 2013 14:05:26 -0800 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-ietf-mmusic-msid-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-ietf-mmusic-msid Revision: 02 Title: Cross Session Stream Identification in the Session Description Protocol Creation date: 2013-11-05 Group: mmusic Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid Htmlized: http://tools.ietf.org/html/draft-ietf-mmusic-msid-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-02 Abstract: This document specifies a grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "m-line" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------060501010403060705040706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit As promised, I have updated the msid draft with the fixes mentioned on Monday.
I have also included some additional clarifications that came in on the mailing list.

One question: Should I move the Appendix B material on ssrc-marking back into the main body, so that the tool is available for non-WebRTC semantics, where UnifiedPlan is not being applied?

           Harald


-------- Original Message --------
Subject: New Version Notification for draft-ietf-mmusic-msid-02.txt
Date: Tue, 05 Nov 2013 14:05:26 -0800
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-ietf-mmusic-msid-02.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-ietf-mmusic-msid
Revision:	 02
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2013-11-05
Group:		 mmusic
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-02.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-ietf-mmusic-msid-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-02

Abstract:
   This document specifies a grouping mechanism for RTP media streams
   that can be used to specify relations between media streams.

   This mechanism is used to signal the association between the SDP
   concept of "m-line" and the WebRTC concept of "MediaStream" /
   "MediaStreamTrack" using SDP signaling.

   This document is a work item of the MMUSIC WG, whose discussion list
   is mmusic@ietf.org.


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------060501010403060705040706-- From tireddy@cisco.com Wed Nov 6 01:56:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4C21F9BC1 for ; Wed, 6 Nov 2013 01:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-r1HOJXsrUy for ; Wed, 6 Nov 2013 01:56:42 -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 B3CC621F9B25 for ; Wed, 6 Nov 2013 01:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2289; q=dns/txt; s=iport; t=1383731802; x=1384941402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qp/rF4anrBcvI3qtPPda0uSNcZcrTc+0/fmPbiK7FTw=; b=SZnD9czK5/U0P8Agh5WhmgRUJxQoyY/OSFKly+Rtvo2qD/9j9DFVGuEr iXS5gL2lnLbcJ10mhir5bVmjt8vKx5UfdXu1wnPtIH09l6b2xMSg42AvT 15QYXhG2X7OQ0hcoKKEND3sPQ7oITzD2zJmwY3Fqqh14gqUZpHGEewrMw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABURelKtJV2d/2dsb2JhbABagwc4U788gSQWdIIlAQEBAwF3AgwEAgEIEQQBAQEKHQcyFAgBCAIEDgUIh3MGDb5bjygxBwaDGoEQA4kIkDOQW4FogT6CKg X-IronPort-AV: E=Sophos;i="4.93,645,1378857600"; d="scan'208";a="281323094" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 06 Nov 2013 09:56:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA69ufeZ026272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 09:56:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 03:56:41 -0600 From: "Tirumaleswar Reddy (tireddy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt Thread-Index: AQHOobGUnhOktz0LA0udxKThEjYwSZmmH+qggG9SggD//8VSIIAA1fuAgAJa84A= Date: Wed, 6 Nov 2013 09:56:41 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2425E39D@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> <52774122.70502@ericsson.com> <913383AAA69FF945B8F946018B75898A2425B748@xmb-rcd-x10.cisco.com> <861759C7815040489720E3CC184F51DD1C4A517B@ESESSMB205.ericsson.se> In-Reply-To: <861759C7815040489720E3CC184F51DD1C4A517B@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.25] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-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: Wed, 06 Nov 2013 09:56:47 -0000 > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Monday, November 04, 2013 9:25 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic= -ice- > happy-eyeballs-02.txt >=20 >=20 > On Nov 4, 2013, at 6:00 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 > >> -----Original Message----- > >> From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > >> Sent: Monday, November 04, 2013 12:10 PM > >> To: Tirumaleswar Reddy (tireddy); mmusic@ietf.org > >> Subject: Re: [MMUSIC] FW: New Version Notification for draft-reddy-mmu= sic- > ice- > >> happy-eyeballs-02.txt > >> > >> Hi, > >> > >> I think the algorithm starts to make sense, but how do you envision to > >> choose the "N" and should there be a negotiation mechanism that ensure= s > >> that both endpoints choose the same N ? > > > > I don't think there is any need to negotiate about "N" because it's onl= y > local prioritization of candidates. ICE agent can use Happy Eyeballs Exte= nsion > for ICE algorithm independent of whether remote agent supports it or not. >=20 > Have you done an exercise (or better, implementation?) on how the candida= te > pairs would then look like? Since ICE uses MAX/MIN sorting of the pairs (= see > http://tools.ietf.org/html/rfc5245#appendix-B.5) simply having high prior= ity > on the other side may not give the results you want. MAX/MIN logic used for calculating candidate-pair priority ensures that for= a particular agent, a lower-priority candidate is never used until all hig= her-priority candidates have been tried. So even if the remote peer does no= t support Happy Eyeballs Extension algorithm, the ICE agent would start ICE= connectivity checks based on the local prioritization and if IPv4 ICE conn= ectivity is received by the remote peer then it would cause Triggered Check= s for IPv4 candidate-pair. Hence IPv4 candidate-pair will be tested earlier= even if remote peer does not Happy Eyeballs Extension algorithm. So effect= ively even if just one of the end points supports the algorithm, connectivi= ty checks are optimized and should see better results.=20 -Tiru. >=20 >=20 > Cheers, > Ari From ari.keranen@ericsson.com Wed Nov 6 17:11:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E01B11E81DB for ; Wed, 6 Nov 2013 17:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.759 X-Spam-Level: X-Spam-Status: No, score=-3.759 tagged_above=-999 required=5 tests=[AWL=-1.460, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwQqgZo8uPcf for ; Wed, 6 Nov 2013 17:11:39 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B57CB11E81C7 for ; Wed, 6 Nov 2013 17:11:33 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-bb-527ae8c44857 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 90.0C.27941.4C8EA725; Thu, 7 Nov 2013 02:11:32 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.37]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 7 Nov 2013 02:11:32 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt Thread-Index: AQHO21ZLuwyXYav/vU2s+N7Y50EgMA== Date: Thu, 7 Nov 2013 01:11:31 +0000 Message-ID: <861759C7815040489720E3CC184F51DD1C4AD532@ESESSMB205.ericsson.se> References: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> <52774122.70502@ericsson.com> <913383AAA69FF945B8F946018B75898A2425B748@xmb-rcd-x10.cisco.com> <861759C7815040489720E3CC184F51DD1C4A517B@ESESSMB205.ericsson.se> <913383AAA69FF945B8F946018B75898A2425E39D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2425E39D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <32BD0F8B563B544C8980827FDA3644D9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvje6RF1VBBs9+aFlMXf6YxeLE7m2M DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGymWbmQq+8la0rH7C3sC4lLuLkYNDQsBE 4tJG+S5GTiBTTOLCvfVsXYxcHEICRxglmubuYYVwFjFKTF26jwmkik3AXmLymo+MILaIgJnE 3mXtjCCDmAXUJa4uDgIJCwskSqxq38gGUZIksWrCJKhyPYmW23NZQWwWARWJ/v6NYHFeAV+J h+cXskPs2sYk8er3KbAEJ1Bix7+jzCA2I9B130+tAbuBWUBc4taT+UwQVwtILNlznhnCFpV4 +fgfK4StJLHo9meoej2JG1OnsEHY1hJ7d/+HsrUlli18zQxxhKDEyZlPWCYwis9CsmIWkvZZ SNpnIWmfhaR9ASPrKkaO4tTipNx0I4NNjMCoOrjlt8UOxst/bQ4xSnOwKInzfnzrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0bBaa3FIteLX8+fU3zBNCpbZbbj542/vkp8TjkfO0GbR Of5du0pU42fnfNaE0ztnLLGeefTzEo+ZEhNWNE955rXz+sbK63dfT29l3plStXhqs2p28KwK pb71D4/fWmBVefnOvhxv3vKfl4V7Ppx53tbFdPqLB8+sjSwS698cCCxj/fYoQevAzW9KLMUZ iYZazEXFiQAWqWloeAIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-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: Thu, 07 Nov 2013 01:11:46 -0000 Hi Tiru, On Nov 6, 2013, at 1:56 AM, Tirumaleswar Reddy (tireddy) wrote: >> Have you done an exercise (or better, implementation?) on how the candid= ate >> pairs would then look like? Since ICE uses MAX/MIN sorting of the pairs = (see >> http://tools.ietf.org/html/rfc5245#appendix-B.5) simply having high prio= rity >> on the other side may not give the results you want. >=20 > MAX/MIN logic used for calculating candidate-pair priority ensures that f= or a particular agent, a lower-priority candidate is never used until all h= igher-priority candidates have been tried. So even if the remote peer does = not support Happy Eyeballs Extension algorithm, the ICE agent would start I= CE connectivity checks based on the local prioritization and if IPv4 ICE co= nnectivity is received by the remote peer then it would cause Triggered Che= cks for IPv4 candidate-pair. Hence IPv4 candidate-pair will be tested earli= er even if remote peer does not Happy Eyeballs Extension algorithm. So effe= ctively even if just one of the end points supports the algorithm, connecti= vity checks are optimized and should see better results.=20 I'm afraid that still wouldn't work like that. As you said, "a lower-priori= ty candidate is never used until all higher-priority candidates have been t= ried". You would not start checks based on a local high priority for an IPv= 4 candidate since a *pair* with that candidate would not have high priority= (due to the "2^32*MIN(G,D)" part of the formula -- it's the smaller priori= ty of the candidates that counts). That said, I remember getting this wrong in my own implementation the first= time so as I said you may want to do this exercise with real numbers and s= ee where you end up. Cheers, Ari= From richard.ejzak@alcatel-lucent.com Wed Nov 6 20:55:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089BB11E81E0; Wed, 6 Nov 2013 20:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J92P-u1JYzDj; Wed, 6 Nov 2013 20:54:53 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1DA11E80F5; Wed, 6 Nov 2013 20:54:53 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA74sq2H015960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2013 22:54:52 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id rA74spE9011819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 23:54:52 -0500 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.164]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 6 Nov 2013 23:54:51 -0500 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" , "dispatch@ietf.org" Thread-Topic: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols Thread-Index: Ac7bdXupbQe+B6NTR72irSdJAzOx2g== Date: Thu, 7 Nov 2013 04:54:51 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_03FBA798AC24E3498B74F47FD082A92F3D87235BUS70UWXCHMBA04z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 04:55:00 -0000 --_000_03FBA798AC24E3498B74F47FD082A92F3D87235BUS70UWXCHMBA04z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please excuse this one-time cross-posting but I understand that this issue = and the following drafts now move from dispatch to MMUSIC. Please respond = only on the MMUSIC list. draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt draft-ejzak-dispatch-msrp-data-channel-00.txt At the mike, Hadriel Kaplan proposed an alternative approach to the one I p= resented in dispatch yesterday (and in the first draft above), and I hope t= o get consensus on the list regarding which approach I should document goin= g forward. Hadriel's proposal is to represent each data channel to be negotiated with = SDP with its own m line and use BUNDLE to link them together onto a single = SCTP association. This is in contrast to the proposal in the draft that ke= eps all the information about data channels within a single m line. I think Hadriel's proposal has some significant disadvantages: 1) BUNDLE would need to be extended to add this new form of muxing, ju= st to put Humpty Dumpty back together again. 2) This approach requires WebRTC browsers to deal with tracking multip= le m lines representing a single SCTP association; else the application has= to implement the BUNDLE extensions for data channels. 3) It makes the gateway scenario simpler at the cost of complicating t= he direct e2e scenario. 4) It unnecessarily adds additional requirements on an important rtcwe= b dependency (BUNDLE) to support this work. There are some advantages to Hadriel's scheme (simplifies gateway scenarios= , more closely resembles current SDP usage of sub-protocol attributes), but= the disadvantages seem more significant to me. Comments, please? Richard --_000_03FBA798AC24E3498B74F47FD082A92F3D87235BUS70UWXCHMBA04z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please excuse this one-time cross-posting but I unde= rstand that this issue and the following drafts now move from dispatch to M= MUSIC.  Please respond only on the MMUSIC list.

 

draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.t= xt

draft-ejzak-dispatch-msrp-data-channel-00.txt

At the mike, Hadriel Kaplan proposed an alternative = approach to the one I presented in dispatch yesterday (and in the first dra= ft above), and I hope to get consensus on the list regarding which approach= I should document going forward.

 

Hadriel’s proposal is to represent each data c= hannel to be negotiated with SDP with its own m line and use BUNDLE to link= them together onto a single SCTP association.  This is in contrast to= the proposal in the draft that keeps all the information about data channels within a single m line.

 

I think Hadriel’s proposal has some significan= t disadvantages:

1)      BUNDLE would need to be extended to add this new fo= rm of muxing, just to put Humpty Dumpty back together again.

2)      This approach requires WebRTC browsers to deal with= tracking multiple m lines representing a single SCTP association; else the= application has to implement the BUNDLE extensions for data channels.=

3)      It makes the gateway scenario simpler at the cost o= f complicating the direct e2e scenario.

4)      It unnecessarily adds additional requirements on an= important rtcweb dependency (BUNDLE) to support this work.

 

There are some advantages to Hadriel’s scheme = (simplifies gateway scenarios, more closely resembles current SDP usage of = sub-protocol attributes), but the disadvantages seem more significant to me= .

 

Comments, please?

 

Richard

 

 

--_000_03FBA798AC24E3498B74F47FD082A92F3D87235BUS70UWXCHMBA04z_-- From pkyzivat@alum.mit.edu Wed Nov 6 21:47:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC1D21F9C7A for ; Wed, 6 Nov 2013 21:47:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8iZ1G+7Or9k for ; Wed, 6 Nov 2013 21:47:50 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7E21F99F7 for ; Wed, 6 Nov 2013 21:47:14 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id mVmS1m0011ZXKqc5CVmxZv; Thu, 07 Nov 2013 05:46:57 +0000 Received: from dhcp-9448.meeting.ietf.org ([31.133.148.72]) by omta21.westchester.pa.mail.comcast.net with comcast id mVkp1m0011ZxU2f3hVkrTv; Thu, 07 Nov 2013 05:44:55 +0000 Message-ID: <527B28D1.9090006@alum.mit.edu> Date: Wed, 06 Nov 2013 21:44:49 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383803217; bh=xBUOjBeZcfmmOunzE8HZuB+k73hrtZf7G84EB64HkOU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aPtb3etR3D6VxcakG/LEdFSGp6zpBfNS19qcRWiC97g2IeGx1SY2B65Oz12HXEtYQ 4M0/HePAw/GUJBSIWnWvirCHug4nVWL9IscExsdE6s3/1osGS7s75/8J25j22WvbaN rEUGA5W89pDLfnURkmpu83b02ChoQN99tjDU1VzhSi77TyVtfMWIJxUNh8+eE0L813 i2rYIgfvEfxgdhmncdddvDuXyrZacfnfH7MGQJCq/C20CyOqs3DiRQ+m2+Y3SqATDu Xa/77GScjmU12/dEVj5QYHMCVRfv9bpmXVzPg15czUfWuxH/FJcbgALYraMJj7d1cl Xf5vFcWuI8vIQ== Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 05:47:55 -0000 On 11/6/13 8:54 PM, Ejzak, Richard P (Richard) wrote: > Please excuse this one-time cross-posting but I understand that this > issue and the following drafts now move from dispatch to MMUSIC. Please > respond only on the MMUSIC list. > > draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt > > draft-ejzak-dispatch-msrp-data-channel-00.txt > > At the mike, Hadriel Kaplan proposed an alternative approach to the one > I presented in dispatch yesterday (and in the first draft above), and I > hope to get consensus on the list regarding which approach I should > document going forward. > > Hadriel’s proposal is to represent each data channel to be negotiated > with SDP with its own m line and use BUNDLE to link them together onto a > single SCTP association. This is in contrast to the proposal in the > draft that keeps all the information about data channels within a single > m line. If SDP had a richer syntax (e.g., a recursive structure like XML), then I think this would be a good idea. But given the syntax bounds we must live within I don't think it flies. We are already stretching things a lot to get Bundle to work in the current form. And we haven't yet extended Bundle to include the data channel SCTP m-line. (That is a desire of RTCWEB.) If we attempted to also bundle data channels, then we would end up with the following (not using SDP syntax): Bundle( rtp m-line rtp m-line ... Bundle( sctp m-line channel m-line channel m-line ... ) ) I really don't want to even think about how to do that in SDP. Also, if we really thought this was the right thing to do, then it would probably be right to have separate m-lines for each SCTP port multiplexed on the same UDP port. That would give yet another level of nesting! Thanks, Paul > I think Hadriel’s proposal has some significant disadvantages: > > 1)BUNDLE would need to be extended to add this new form of muxing, just > to put Humpty Dumpty back together again. > > 2)This approach requires WebRTC browsers to deal with tracking multiple > m lines representing a single SCTP association; else the application has > to implement the BUNDLE extensions for data channels. > > 3)It makes the gateway scenario simpler at the cost of complicating the > direct e2e scenario. > > 4)It unnecessarily adds additional requirements on an important rtcweb > dependency (BUNDLE) to support this work. > > There are some advantages to Hadriel’s scheme (simplifies gateway > scenarios, more closely resembles current SDP usage of sub-protocol > attributes), but the disadvantages seem more significant to me. > > Comments, please? > > Richard > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Wed Nov 6 22:40:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3111E8180 for ; Wed, 6 Nov 2013 22:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uut8B86SiOR for ; Wed, 6 Nov 2013 22:40:06 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D921E11E810B for ; Wed, 6 Nov 2013 22:40:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41DD139E05D for ; Thu, 7 Nov 2013 07:40:02 +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 jKIDcF4OxE9t for ; Thu, 7 Nov 2013 07:40:01 +0100 (CET) Received: from [31.133.161.198] (dhcp-a1c6.meeting.ietf.org [31.133.161.198]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B776839E03A for ; Thu, 7 Nov 2013 07:40:00 +0100 (CET) Message-ID: <527B35BE.2070004@alvestrand.no> Date: Thu, 07 Nov 2013 07:39:58 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> <527B28D1.9090006@alum.mit.edu> In-Reply-To: <527B28D1.9090006@alum.mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 06:40:13 -0000 On 11/07/2013 06:44 AM, Paul Kyzivat wrote: > On 11/6/13 8:54 PM, Ejzak, Richard P (Richard) wrote: >> Please excuse this one-time cross-posting but I understand that this >> issue and the following drafts now move from dispatch to MMUSIC. Please >> respond only on the MMUSIC list. >> >> draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt >> >> draft-ejzak-dispatch-msrp-data-channel-00.txt >> >> At the mike, Hadriel Kaplan proposed an alternative approach to the one >> I presented in dispatch yesterday (and in the first draft above), and I >> hope to get consensus on the list regarding which approach I should >> document going forward. >> >> Hadriel’s proposal is to represent each data channel to be negotiated >> with SDP with its own m line and use BUNDLE to link them together onto a >> single SCTP association. This is in contrast to the proposal in the >> draft that keeps all the information about data channels within a single >> m line. > > If SDP had a richer syntax (e.g., a recursive structure like XML), > then I think this would be a good idea. > > But given the syntax bounds we must live within I don't think it flies. > We are already stretching things a lot to get Bundle to work in the > current form. And we haven't yet extended Bundle to include the data > channel SCTP m-line. (That is a desire of RTCWEB.) > > If we attempted to also bundle data channels, then we would end up > with the following (not using SDP syntax): > > Bundle( > rtp m-line > rtp m-line > ... > Bundle( > sctp m-line > channel m-line > channel m-line > ... > ) > ) > > I really don't want to even think about how to do that in SDP. > > Also, if we really thought this was the right thing to do, then it > would probably be right to have separate m-lines for each SCTP port > multiplexed on the same UDP port. That would give yet another level of > nesting! > > Thanks, > Paul I agree with Paul here. For normal (as I think of it) WebRTC usage, we want one m-line to describe the SCTP association, and the channels are completely invisible. Richard's proposal makes the channels visible, but otherwise retains the syntax of the WebRTC usage. Having an alternate SDP description of an SCTP association would add parsing complexity, reduce interoperability and generally be a pain in the posterior. Let's just not go there. From martin.thomson@gmail.com Thu Nov 7 10:06:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671EA21E81F8 for ; Thu, 7 Nov 2013 10:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF3TOpXJkcfT for ; Thu, 7 Nov 2013 10:06:53 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9217121E81C1 for ; Thu, 7 Nov 2013 10:05:45 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so894605wes.4 for ; Thu, 07 Nov 2013 10:05:44 -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=Jh/fFHxIrRbSby5XZdHr77uliODQUn/yCD0vItWyN+I=; b=Ujof+m8NOrQFmNgDi1Mc5VoHNKT2F1tILUTVw7ZOefJqTzkyf+vwmV0yoQC45+l4+x MAbHZybNJiXWau1cOzG4wgc7uC5qITofpYEQOqXpgv6xhQa++Ysjes6vZMZhAlX5qqW5 tSaMFp1pv8tU7KLZ4YbItjwY3piVBEjk8+zuzfbBueIVfjKvntoxlzpEEcWSMN3EAWek DK+leZiLE0sM9xKgkfy3P5aG4cFuojvpFOpQvJk7D6pPbMCvBV9QSp84kOIcf9Bj3V4i qitp4l6ayBiSFKato4Ygk2bLMAF3iD8afqjHHoMhvPNWhAxo+M+Ld+iVZwhBJpGo9ooJ AYBw== MIME-Version: 1.0 X-Received: by 10.180.37.114 with SMTP id x18mr3783572wij.64.1383847544663; Thu, 07 Nov 2013 10:05:44 -0800 (PST) Received: by 10.227.202.194 with HTTP; Thu, 7 Nov 2013 10:05:44 -0800 (PST) Date: Thu, 7 Nov 2013 10:05:44 -0800 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [MMUSIC] A possible way to replace 5888 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:06:53 -0000 A backwards-compatible offer would need to rely on ordering. a=groupid:g1 a=group:FOO a b c a=groupid:g2 a=group:FOO b c m=blah ... a=mid:a a=add-group:FOO g1 m=blah ... a=mid:b a=add-group:FOO g1 a=add-group:FOO g2 m=blah ... a=mid:c a=add-group:FOO g1 a=add-group:FOO g2 From hadriel.kaplan@oracle.com Thu Nov 7 10:17:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A846E21E81EE; Thu, 7 Nov 2013 10:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjbiNOt3CbtO; Thu, 7 Nov 2013 10:16:49 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0285B21E824A; Thu, 7 Nov 2013 10:14:47 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA7IEMRx020515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 18:14:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7IEMHS013295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 18:14:22 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7IELhi013272; Thu, 7 Nov 2013 18:14:21 GMT Received: from dhcp-a434.meeting.ietf.org (/31.133.164.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Nov 2013 10:14:21 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Hadriel Kaplan In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Thu, 7 Nov 2013 13:14:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2F68552E-F18B-4A54-BD52-732EEDB02B52@oracle.com> References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> To: "Ejzak, Richard P (Richard)" X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "dispatch@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:17:06 -0000 I had assumed the proposal was to make this draft-thing usable in SIP or = other protocols, not just WebRTC. True? If not true, and this is only = for WebRTC, then yeah do whatever and please ignore this email. Technically SCTP is a transport, not a media type. By having multiple = sctp-based application/media types in the same m-line, it's semantically = equivalent to putting audio+video in the same m-line. Even your example = SDP in the draft shows this, since MSRP is a "message" media type while = one of the others is a "application" one. To put this more concretely, pretend that we had standardized not only = MSRP, BFCP, and T.38 fax to run over SCTP, but also video and audio too. = Maybe not real-time video, but rather TV-style streaming of video or = whatever. So now you'd have SDP with one m-line for "SCTP" with audio, = video, message, and application types within it. I'm ok if the group consensus is to do it anyway, but my point at the = mic was to make this more obvious to people - that by doing this, SDP = semantics are not being consistent. I realize that consistency no = longer matters at the altar of WebRTC expediency, but just thought it = should be pointed out... if for no other reason than to have this stored = in the email archives. -hadriel On Nov 6, 2013, at 11:54 PM, "Ejzak, Richard P (Richard)" = wrote: > Please excuse this one-time cross-posting but I understand that this = issue and the following drafts now move from dispatch to MMUSIC. Please = respond only on the MMUSIC list. > =20 > draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt > draft-ejzak-dispatch-msrp-data-channel-00.txt >=20 > At the mike, Hadriel Kaplan proposed an alternative approach to the = one I presented in dispatch yesterday (and in the first draft above), = and I hope to get consensus on the list regarding which approach I = should document going forward. > =20 > Hadriel=92s proposal is to represent each data channel to be = negotiated with SDP with its own m line and use BUNDLE to link them = together onto a single SCTP association. This is in contrast to the = proposal in the draft that keeps all the information about data channels = within a single m line. > =20 > I think Hadriel=92s proposal has some significant disadvantages: > 1) BUNDLE would need to be extended to add this new form of = muxing, just to put Humpty Dumpty back together again. > 2) This approach requires WebRTC browsers to deal with tracking = multiple m lines representing a single SCTP association; else the = application has to implement the BUNDLE extensions for data channels. > 3) It makes the gateway scenario simpler at the cost of = complicating the direct e2e scenario. > 4) It unnecessarily adds additional requirements on an important = rtcweb dependency (BUNDLE) to support this work. > =20 > There are some advantages to Hadriel=92s scheme (simplifies gateway = scenarios, more closely resembles current SDP usage of sub-protocol = attributes), but the disadvantages seem more significant to me. > =20 > Comments, please? > =20 > Richard > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From martin.thomson@gmail.com Thu Nov 7 10:17:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15DE21E81F7 for ; Thu, 7 Nov 2013 10:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reWlR8KNWQBH for ; Thu, 7 Nov 2013 10:17:57 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 125A421E81FE for ; Thu, 7 Nov 2013 10:15:47 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id ey11so1053663wid.13 for ; Thu, 07 Nov 2013 10:15:46 -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=HbrrKQ+AzUPTElsJjB+BZxSJxtKv+83kRLoudRwspro=; b=TxGzCNmSq6+Lx7GS7B9xyol/OleBA8hXCqhJyoDNKfky+bOtoYOH/LpThHcYIXwSIv 9kgD5Dwbq4nBe0C7ubBNTUJX5/igPGFeTRzDGO+J7nmad3mR48I89iPdj81VWq16K+7B wnf0CzglXU9wQ/EEvPNgxI9dA405dUHKp+sJSPiQryY4G6d2Wj5v92FBmdS3qtEGij2a dPHenTuS9KkQbarERhgXN+lC0N3PLFwnnvUEz55pQNpSQw6fLhK6PI0/bY8ygrpISs0E XEQ0VPZQFE11dxS6Mdrh1xTdGaZQfO9j8YAycqoJevQL3o9B6cCXpy6zlAp9J/fbdlA3 Ovsg== MIME-Version: 1.0 X-Received: by 10.194.109.68 with SMTP id hq4mr8697567wjb.12.1383848146032; Thu, 07 Nov 2013 10:15:46 -0800 (PST) Received: by 10.227.202.194 with HTTP; Thu, 7 Nov 2013 10:15:45 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 10:15:45 -0800 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [MMUSIC] A possible way to replace 5888 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:17:57 -0000 On 7 November 2013 10:05, Martin Thomson wrote: > A backwards-compatible offer would need to rely on ordering. > > a=groupid:g1 > a=group:FOO a b c > a=groupid:g2 > a=group:FOO b c > m=blah ... > a=mid:a > a=add-group:FOO g1 > m=blah ... > a=mid:b > a=add-group:FOO g1 > a=add-group:FOO g2 > m=blah ... > a=mid:c > a=add-group:FOO g1 > a=add-group:FOO g2 And, to address the other issue that was raised, if you want to create a new group in a partial offer, you can simply send something like this: m=blah ... a=add-group:FOO newgroup m=blah ... a=add-group:FOO newgroup From hadriel.kaplan@oracle.com Thu Nov 7 10:34:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0CC11E81DA for ; Thu, 7 Nov 2013 10:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmJpwDuTb2De for ; Thu, 7 Nov 2013 10:34:04 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2B621E8140 for ; Thu, 7 Nov 2013 10:34:03 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA7IXuYH013821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 18:33:57 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7IXtIK011744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 18:33:56 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA7IXtEo011735; Thu, 7 Nov 2013 18:33:55 GMT Received: from dhcp-a434.meeting.ietf.org (/31.133.164.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 07 Nov 2013 10:33:55 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Hadriel Kaplan In-Reply-To: <527B35BE.2070004@alvestrand.no> Date: Thu, 7 Nov 2013 13:33:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72B28FB4-EB19-4289-9F72-D8C5745D9E89@oracle.com> References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> <527B28D1.9090006@alum.mit.edu> <527B35BE.2070004@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:34:10 -0000 On Nov 7, 2013, at 1:39 AM, Harald Alvestrand = wrote: > For normal (as I think of it) WebRTC usage, we want one m-line to > describe the SCTP association, and the channels are completely = invisible. Sure for WebRTC, of course that's true - because they're all one media = type: application. Only the application above (the one in JS) knows = what's in the specific SCTP channels, right? My comment at the mic = about this was for non-WebRTC cases, such as if we were to standardize = MSRP, BFCP, fax, etc. on SCTP. (or at least that's what I thought = Richard's proposal was for, but I could be misunderstanding it) -hadriel From mary.ietf.barnes@gmail.com Thu Nov 7 10:39:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4379B21E814E for ; Thu, 7 Nov 2013 10:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP1qXdMuB-AI for ; Thu, 7 Nov 2013 10:39:50 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 80FC121E8147 for ; Thu, 7 Nov 2013 10:38:53 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so954591wgg.16 for ; Thu, 07 Nov 2013 10:38: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=F2Uj/Ugcw7JtpphqKZwTVph/LHtCJ6RfmAVJefx3+TU=; b=0/JduOazMkksEC5fBnZQp8sb3ET9gGUxXcRR0v+VJ6gfzGkmEgt3gI3HduoSZF4lig R9XgVS0W38hi24+uwxSp9TTygK++qskog03vxk4K1A4zHdTtI8lzlVis20/whlOrRLfO WX8bdf35L5sGhGP+mhiDzPZ30uuaoQ5N9iCXMnElSFNG04fMqFuqOCj7fHGpd2u1AZNN 5vF1Et9k3PzYJtwNic9oOLLHvsehYasBrfFKV9vLYsjmlWtGbRgI33WB2w918//AS4fT nOQCN0/O6Zc0h7km+QWAxLDRhfVypu3yChZBhG6K7Tk0zlDREiyX16igTPR0eCg8ZCJg U3LQ== MIME-Version: 1.0 X-Received: by 10.194.200.100 with SMTP id jr4mr8452315wjc.37.1383849529557; Thu, 07 Nov 2013 10:38:49 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 7 Nov 2013 10:38:49 -0800 (PST) In-Reply-To: <72B28FB4-EB19-4289-9F72-D8C5745D9E89@oracle.com> References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> <527B28D1.9090006@alum.mit.edu> <527B35BE.2070004@alvestrand.no> <72B28FB4-EB19-4289-9F72-D8C5745D9E89@oracle.com> Date: Thu, 7 Nov 2013 12:38:49 -0600 Message-ID: From: Mary Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7bb03e1ea1cb3e04ea9a93b1 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:39:51 -0000 --047d7bb03e1ea1cb3e04ea9a93b1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Nov 7, 2013 at 12:33 PM, Hadriel Kaplan wrote: > > On Nov 7, 2013, at 1:39 AM, Harald Alvestrand > wrote: > > > For normal (as I think of it) WebRTC usage, we want one m-line to > > describe the SCTP association, and the channels are completely invisibl= e. > > Sure for WebRTC, of course that's true - because they're all one media > type: application. Only the application above (the one in JS) knows what= 's > in the specific SCTP channels, right? My comment at the mic about this w= as > for non-WebRTC cases, such as if we were to standardize MSRP, BFCP, fax, > etc. on SCTP. (or at least that's what I thought Richard's proposal was > for, but I could be misunderstanding it) > > [MB] The intent is for this to support non-WebRTC cases. CLUE is another example that could use this mechanism. This is the proposed deliverables: =96 Define generic SDP procedures to enable external negotiation of DataChannel transport for sub-protocol sessions, and to enable negotiation of sub-protocol specific options. =96 Describe how to use the generic SDP procedures negotiate DataChannel transport for specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol. I think part of the confusion is that the drafts were originally very WebRTC centric. [/MB] > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bb03e1ea1cb3e04ea9a93b1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 7, 2013 at 12:33 PM= , Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:<= br>

On Nov 7, 2013, at 1:39 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> For normal (as I think of it) WebRTC usage, we want one m-line to
> describe the SCTP association, and the channels are completely invisib= le.

Sure for WebRTC, of course that's true - because they're all = one media type: application. =A0Only the application above (the one in JS) = knows what's in the specific SCTP channels, right? =A0My comment at the= mic about this was for non-WebRTC cases, such as if we were to standardize= MSRP, BFCP, fax, etc. on SCTP. (or at least that's what I thought Rich= ard's proposal was for, but I could be misunderstanding it)

[MB] The intent is for this to support non-WebRTC cases. =A0CLUE is= another example that could use this mechanism. =A0 =A0
This is the proposed deliverables:

=A0=96 Define generic SDP p= rocedures to enable external negotiation of DataChannel transport for sub-p= rotocol sessions, and to enable=A0negotiation of sub-protocol specific opti= ons.

=96 Describe h= ow to use the generic SDP procedures negotiate DataChannel transport for sp= ecific protocols, potentially including

MSRP, BFCP, T.= 140, T.38 and the CLUE control protocol.


I think part of the confusion is that the drafts were originally ver= y WebRTC centric. =A0
[/MB]=A0
-hadriel

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

--047d7bb03e1ea1cb3e04ea9a93b1-- From pkyzivat@alum.mit.edu Thu Nov 7 11:03:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75D21E8144 for ; Thu, 7 Nov 2013 11:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUJXfYYHn6tU for ; Thu, 7 Nov 2013 11:03:33 -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 77E0821E8140 for ; Thu, 7 Nov 2013 11:02:34 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id mcV61m0060Fqzac5Fj2aaJ; Thu, 07 Nov 2013 19:02:34 +0000 Received: from dhcp-a6d1.meeting.ietf.org ([31.133.166.209]) by omta08.westchester.pa.mail.comcast.net with comcast id mj0R1m00k4XQ1zz3Uj0U2p; Thu, 07 Nov 2013 19:00:32 +0000 Message-ID: <527BE349.5080809@alum.mit.edu> Date: Thu, 07 Nov 2013 11:00:25 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> <2F68552E-F18B-4A54-BD52-732EEDB02B52@oracle.com> In-Reply-To: <2F68552E-F18B-4A54-BD52-732EEDB02B52@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383850954; bh=eEGDMZIWkrAcKX1Rz1y3aS3POIONhGhI9VgTWhnYWjs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oeedM1HHXw2a5sWtCH4+fuuAIchaugUIVz7xQFzRIYGxxspbDuMK7kQ7x1wlVK6os Zc4ufBZH5B1TUPY12UivCuL2+bbwUEqAdqNafuGCjhNlYIy9xf4bw2wnnyJxWaGp/f gQdtgChzvS6FDWCg6RL26e5U63c5twJ1yr33M/1BpJZvJrbfNWjVrcPHrjHuZcLYIB 55v8v1//1wa/2biG6Zz8Kzuk6KzXP72DEH76lkPXqFXRtFwWodEh08tPel48lTJfX/ 9si4TXp3t4n7vaWO/P6P6FWKer+6kzUq2zkzHm3x98dN5nzYVikbT6Wq4qaPvZJu6O 0K1R19kdAPQXw== Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:03:38 -0000 Hadriel, Did you see my reply to Richard? In principle I agree with you, but in practice I don't think it is feasible to go that way. The audio/video/application thing merely reflects a case where SDP got it wrong in the first place. Technically codecs are identified by a mime-type/subtype, but the type is put in the type field of the m-line, and the subtype is put either into the format field of the m-line or into an attribute. When doing it over in a new context we can simply represent it as type/subtype. Thanks, Paul On 11/7/13 10:14 AM, Hadriel Kaplan wrote: > > I had assumed the proposal was to make this draft-thing usable in SIP or other protocols, not just WebRTC. True? If not true, and this is only for WebRTC, then yeah do whatever and please ignore this email. > > Technically SCTP is a transport, not a media type. By having multiple sctp-based application/media types in the same m-line, it's semantically equivalent to putting audio+video in the same m-line. Even your example SDP in the draft shows this, since MSRP is a "message" media type while one of the others is a "application" one. > > To put this more concretely, pretend that we had standardized not only MSRP, BFCP, and T.38 fax to run over SCTP, but also video and audio too. Maybe not real-time video, but rather TV-style streaming of video or whatever. So now you'd have SDP with one m-line for "SCTP" with audio, video, message, and application types within it. > > I'm ok if the group consensus is to do it anyway, but my point at the mic was to make this more obvious to people - that by doing this, SDP semantics are not being consistent. I realize that consistency no longer matters at the altar of WebRTC expediency, but just thought it should be pointed out... if for no other reason than to have this stored in the email archives. > > -hadriel > > > On Nov 6, 2013, at 11:54 PM, "Ejzak, Richard P (Richard)" wrote: > >> Please excuse this one-time cross-posting but I understand that this issue and the following drafts now move from dispatch to MMUSIC. Please respond only on the MMUSIC list. >> >> draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt >> draft-ejzak-dispatch-msrp-data-channel-00.txt >> >> At the mike, Hadriel Kaplan proposed an alternative approach to the one I presented in dispatch yesterday (and in the first draft above), and I hope to get consensus on the list regarding which approach I should document going forward. >> >> Hadriel’s proposal is to represent each data channel to be negotiated with SDP with its own m line and use BUNDLE to link them together onto a single SCTP association. This is in contrast to the proposal in the draft that keeps all the information about data channels within a single m line. >> >> I think Hadriel’s proposal has some significant disadvantages: >> 1) BUNDLE would need to be extended to add this new form of muxing, just to put Humpty Dumpty back together again. >> 2) This approach requires WebRTC browsers to deal with tracking multiple m lines representing a single SCTP association; else the application has to implement the BUNDLE extensions for data channels. >> 3) It makes the gateway scenario simpler at the cost of complicating the direct e2e scenario. >> 4) It unnecessarily adds additional requirements on an important rtcweb dependency (BUNDLE) to support this work. >> >> There are some advantages to Hadriel’s scheme (simplifies gateway scenarios, more closely resembles current SDP usage of sub-protocol attributes), but the disadvantages seem more significant to me. >> >> Comments, please? >> >> Richard >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From tireddy@cisco.com Tue Nov 12 03:46:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2FD11E8127 for ; Tue, 12 Nov 2013 03:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LohG6u5oM6qO for ; Tue, 12 Nov 2013 03:46:24 -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 D61CA11E8125 for ; Tue, 12 Nov 2013 03:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2381; q=dns/txt; s=iport; t=1384256784; x=1385466384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3ZGJ2dEmQsokj9T4VRuGICtv+YoKM9PwyUajlTt23jE=; b=QlZ1DruSSt4Xl9Tbb6BuvPJ/sEYSqq12kYHaq/D/vRLF6OcBRMyLHuEq 6jRtNCDnqHdxcN1L8OZKiW0oKSRMfGxK6K5boCrJu2Zq1pAo/MSF1aPhS 5qOFo/t1+PzlN2cwRhf4QOlMSwTIQViSA1GhHBtnRb1UmcL3xk7PJuCzD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAIcUglKtJXG+/2dsb2JhbABZgwc4U78dgSsWdIIlAQEBAwF3AgwEAgEIEQQBAQEKHQcyFAkIAgQOBQiHcwYNvimPLjEHBoMagREDiQqQNJBbgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,684,1378857600"; d="scan'208";a="283632343" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 12 Nov 2013 11:46:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rACBkNvS013650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 11:46:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 05:46:23 -0600 From: "Tirumaleswar Reddy (tireddy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt Thread-Index: AQHO21ZNmnu1pvCt30GbtcSj/PClypochX8Q Date: Tue, 12 Nov 2013 11:46:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24261FC6@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> <52774122.70502@ericsson.com> <913383AAA69FF945B8F946018B75898A2425B748@xmb-rcd-x10.cisco.com> <861759C7815040489720E3CC184F51DD1C4A517B@ESESSMB205.ericsson.se> <913383AAA69FF945B8F946018B75898A2425E39D@xmb-rcd-x10.cisco.com> <861759C7815040489720E3CC184F51DD1C4AD532@ESESSMB205.ericsson.se> In-Reply-To: <861759C7815040489720E3CC184F51DD1C4AD532@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-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: Tue, 12 Nov 2013 11:46:29 -0000 Hi Ari, Please see inline=20 > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Thursday, November 07, 2013 6:42 AM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice= - > happy-eyeballs-02.txt >=20 > Hi Tiru, >=20 > On Nov 6, 2013, at 1:56 AM, Tirumaleswar Reddy (tireddy) wrote: > >> Have you done an exercise (or better, implementation?) on how the cand= idate > >> pairs would then look like? Since ICE uses MAX/MIN sorting of the pair= s > (see > >> http://tools.ietf.org/html/rfc5245#appendix-B.5) simply having high > priority > >> on the other side may not give the results you want. > > > > MAX/MIN logic used for calculating candidate-pair priority ensures that= for > a particular agent, a lower-priority candidate is never used until all hi= gher- > priority candidates have been tried. So even if the remote peer does not > support Happy Eyeballs Extension algorithm, the ICE agent would start ICE > connectivity checks based on the local prioritization and if IPv4 ICE > connectivity is received by the remote peer then it would cause Triggered > Checks for IPv4 candidate-pair. Hence IPv4 candidate-pair will be tested > earlier even if remote peer does not Happy Eyeballs Extension algorithm. = So > effectively even if just one of the end points supports the algorithm, > connectivity checks are optimized and should see better results. >=20 > I'm afraid that still wouldn't work like that. As you said, "a lower-prio= rity > candidate is never used until all higher-priority candidates have been tr= ied". > You would not start checks based on a local high priority for an IPv4 > candidate since a *pair* with that candidate would not have high priority= (due > to the "2^32*MIN(G,D)" part of the formula -- it's the smaller priority o= f the > candidates that counts). You are right, there is no benefit if only one endpoint supports Happy Eyeb= alls Extension algorithm. we will update the draft to high-light this point= . Thanks and Regards, -Tiru. >=20 > That said, I remember getting this wrong in my own implementation the fir= st > time so as I said you may want to do this exercise with real numbers and = see > where you end up. >=20 >=20 > Cheers, > Ari From christer.holmberg@ericsson.com Tue Nov 12 15:08:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E595221E8095 for ; Tue, 12 Nov 2013 15:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.265 X-Spam-Level: X-Spam-Status: No, score=-5.265 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivSGJcoXWNJv for ; Tue, 12 Nov 2013 15:08:07 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 241B511E8102 for ; Tue, 12 Nov 2013 15:08:06 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-b8-5282b4d5e604 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 42.30.23787.5D4B2825; Wed, 13 Nov 2013 00:08:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 00:08:05 +0100 From: Christer Holmberg To: Christian Groves , "mmusic@ietf.org" Thread-Topic: BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05] Thread-Index: Ac7f+yFiio3q0Su+TKa2xyLMPK+t7Q== Date: Tue, 12 Nov 2013 23:08:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvre61LU1BBuvuclh8ed/IYjF1+WMW ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvj3943rAUfhCreTb/C1MC4kr+LkZNDQsBE YtHhqcwQtpjEhXvr2boYuTiEBA4xSiz49ZwJJCEksIRRYsMGnS5GDg42AQuJ7n/aIGERgWiJ SQub2UBsYYEqia3n5jNDxOsl1vxZyAJh60lc/r8bbAyLgKrEoXd/wOp5BXwlGh4eA6tnBNr7 /dQasBpmAXGJDwevQ90jILFkz3koW1Ti5eN/rBC2ksSK7ZcYIer1JG5MncIGYWtLLFv4mhli vqDEyZlPWCYwCs9CMnYWkpZZSFpmIWlZwMiyipE9NzEzJ73ccBMjMLAPbvmtu4Px1DmRQ4zS HCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC035r0oWitAcuBu8l6axMauaZ8 6D1rlMM2yyWe+VPFl6gCFZmlqwz0Y60+2D3MT/peusffxy5nVtleIcu35hetn+Q8K3jtrDpx zy/Ty6VPUud86LhdejGlSXu5ajd7WsnFHUV/74X6P3hYxHqhV4szLHTbarvQ+dGXVk/ln8rr bdnHpPLkyWolluKMREMt5qLiRADXSRYdOgIAAA== Subject: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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: Tue, 12 Nov 2013 23:08:18 -0000 Hi, Based on the comments from Christian, I suggest the following new text for = BUNDLE: ----------------------------- 6.2.2. Connection Data (c=3D) The "c=3D" line nettype value [RFC4566] associated with each "m=3D" line within a BUNDLE group MUST be 'IN'. The "c=3D" line addrtype value [RFC4566] associated with each "m=3D" lin= e within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST be associated with each "m=3D" line within a BUNDLE group. NOTE: Extensions to this specification can specify usage of the BUNDLE mechanism for other nettype and addrtype values than the ones listed above. ----------------------------- Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Christian Groves L=E4hetetty: 15. lokakuuta 2013 3:05 Vastaanottaja: mmusic@ietf.org Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiat= ion-05 Hello Christer, The SDP grouping mechanism can be applied to different nettype/addrtypes. T= he BUNDLE draft appears to define behaviour related only to the nettype=3DI= N and addrtypes=3DIPv4/IPv6. i.e. section 2 defines BUNDLE terminology base= d on IP. Is there an intention that the BUNDLE mechanism is only used for the above = net and addrtypes? If so should it be mentioned somewhere in the applicabil= ity statement? Regards, Christian On 14/10/2013 10:37 PM, Christer Holmberg wrote: > > Hi, > > I've submitted a new version of the BUNDLE draft. > > I have implemented the modified text for the Offerer and Answerer=20 > procedures, as presented on the list in September. > > The procedures now also mention the usage of the SDP 'bundle-only'=20 > attribute. However, the attribute definition itself has yet not been=20 > added to the draft, as we still haven't solved the issue regarding=20 > usage of port zero. > > In addition, there are some reference corrections, and the FQDN values=20 > in the examples are now according to RFC 2606. > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Tue Nov 12 15:39:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE11D21E8095 for ; Tue, 12 Nov 2013 15:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.743 X-Spam-Level: X-Spam-Status: No, score=-3.743 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxKroXkTwk99 for ; Tue, 12 Nov 2013 15:39:25 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF921E8089 for ; Tue, 12 Nov 2013 15:39:25 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-7d-5282bc2bb509 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 58.46.27941.B2CB2825; Wed, 13 Nov 2013 00:39:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 00:39:23 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? Thread-Index: Ac7f//9tV1L0gQ17QYeeQ7SNfEjBjA== Date: Tue, 12 Nov 2013 23:39:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra72nqYgg33bTSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBtPOlkLZrJW7Pm9nKWBsY2li5GTQ0LAROLEjCOsELaYxIV7 69m6GLk4hASOMEp0/j8N5SxhlJh5fwV7FyMHB5uAhUT3P22QBhEBdYmve3uYQcLCAokSP14r Q4TTJF5cvccOYetJPL87gRHEZhFQldi0uhMszivgK/Fr5zpmEJsRaO/3U2uYQGxmAXGJDwev M0PcIyCxZM95KFtU4uXjf1B3Kkms2H6JEaJeR2LB7k9sELa2xLKFr5kh5gtKnJz5hGUCo/As JGNnIWmZhaRlFpKWBYwsqxg5ilOLk3LTjQw2MQLD+OCW3xY7GC//tTnEKM3BoiTO+/Gtc5CQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGRvO+ys/Pk/mL+pWUfUVc86r+vGQN4Jz7ZC/rLH+n 5ZcjCy+kcAULNuzgMW1QNXm9Y0Ogcb7O4gsf5wcpX7+n9b34eul/0cCXQQcz13hr3Vo7KSCC y/vyjVtTZh2ImXi0NfHElLW/Gz8x/jvX5f1nhva0yAkve37dLOw5Oe/2D5W52ov33vX5E6TE UpyRaKjFXFScCADfjZxfMQIAAA== Subject: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 12 Nov 2013 23:39:31 -0000 Hi, In Vancouver we decided that an Offerer MUST NOT assign a shared address (w= ith a non-zero port) to multiple m- lines until the Answerer, within the se= ssion, has indicated support of BUNDLE. I suggest the following piece of text to implement the decision in the BUN= DLE spec: "The Offerer MUST NOT assign a shared address with a non-zero port value to multiple "m=3D" lines until it has, within the given session, received an SDP Answer indicating that the Answerer supports the BUNDLE mechanism." Note that there will be specific text regarding the usage of port zero for = 'bundle-only' m- lines. Regards, Christer From Christian.Groves@nteczone.com Tue Nov 12 18:40:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FB621E80C6 for ; Tue, 12 Nov 2013 18:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq1D-aapvP6T for ; Tue, 12 Nov 2013 18:40:47 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCA921E80AD for ; Tue, 12 Nov 2013 18:40:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksVAFHmglJ20SI6PGdsb2JhbAANTYM/vy9LgTIDAQEBATiCWgEBAQMBAQEBCSYBBRsbChELGAkWBAQHCQMCAQIBFRwDEQYBDAYCAQGHdxOrVpNGBI9mhDEDrAWBUg Received: from ppp118-209-34-58.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.34.58]) by ipmail06.adl2.internode.on.net with ESMTP; 13 Nov 2013 13:10:20 +1030 Message-ID: <5282E68E.3000505@nteczone.com> Date: Wed, 13 Nov 2013 13:40:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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: Wed, 13 Nov 2013 02:40:48 -0000 Hello Christer, It looks OK to me. Regards, Christian On 13/11/2013 10:08 AM, Christer Holmberg wrote: > Hi, > > Based on the comments from Christian, I suggest the following new text for BUNDLE: > > ----------------------------- > > 6.2.2. Connection Data (c=) > > The "c=" line nettype value [RFC4566] associated with each "m=" line > within a BUNDLE group MUST be 'IN'. > > The "c=" line addrtype value [RFC4566] associated with each "m=" line > within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST be > associated with each "m=" line within a BUNDLE group. > > NOTE: Extensions to this specification can specify usage of the > BUNDLE mechanism for other nettype and addrtype values than the ones > listed above. > > ----------------------------- > > Regards, > > Christer > > > > > -----Alkuperäinen viesti----- > Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Christian Groves > Lähetetty: 15. lokakuuta 2013 3:05 > Vastaanottaja: mmusic@ietf.org > Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 > > Hello Christer, > > The SDP grouping mechanism can be applied to different nettype/addrtypes. The BUNDLE draft appears to define behaviour related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section 2 defines BUNDLE terminology based on IP. > > Is there an intention that the BUNDLE mechanism is only used for the above net and addrtypes? If so should it be mentioned somewhere in the applicability statement? > > Regards, Christian > > On 14/10/2013 10:37 PM, Christer Holmberg wrote: >> Hi, >> >> I've submitted a new version of the BUNDLE draft. >> >> I have implemented the modified text for the Offerer and Answerer >> procedures, as presented on the list in September. >> >> The procedures now also mention the usage of the SDP 'bundle-only' >> attribute. However, the attribute definition itself has yet not been >> added to the draft, as we still haven't solved the issue regarding >> usage of port zero. >> >> In addition, there are some reference corrections, and the FQDN values >> in the examples are now according to RFC 2606. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From suhasietf@gmail.com Tue Nov 12 23:20:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CDD21E8088 for ; Tue, 12 Nov 2013 23:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2SQQRqhOt5V for ; Tue, 12 Nov 2013 23:20:08 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F02C621E8082 for ; Tue, 12 Nov 2013 23:20:07 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id ey11so4835100wid.6 for ; Tue, 12 Nov 2013 23:20:07 -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=8eHVibj4vKUpzd1JlHDQMtUz9SaD6oP3HMFDeCIzxDo=; b=qevw+OhZjG4r58thw4KscyWKjvWDg/f3KbSh665p0FLBMnkLpNIc+MSZDarDhL7+R0 xeNCuM4hHaIKQ3wNhd6jL7m7pGeSgLSJCvW91OAu92U0A4GT40ZuHESs4r4eUT3UpR5x Xg4WgEy2sX7f9Ce+IQnaVTvRFXmNj9wGKkUgk/t+tLCid9HPLtVSf5OCefFDtQj3b/mh XUkeVNZIzJpgxHAKqtnqIQ+F/IbOwq4E0J8MipV9FnZnJs6HAl7V5MLQRkhCD9aTLuFg 5fp4Ff9YyxGG5xoHD4VFopI0uLH3RBo0cF3E1gkT4hJw83QvPAOhTqUxsGCXT+UK40W+ MDCQ== MIME-Version: 1.0 X-Received: by 10.195.13.45 with SMTP id ev13mr29877451wjd.20.1384327207173; Tue, 12 Nov 2013 23:20:07 -0800 (PST) Received: by 10.194.178.231 with HTTP; Tue, 12 Nov 2013 23:20:07 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> Date: Tue, 12 Nov 2013 23:20:07 -0800 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bfced1e6fc1fe04eb09cbc8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 07:20:09 -0000 --047d7bfced1e6fc1fe04eb09cbc8 Content-Type: text/plain; charset=ISO-8859-1 Hi Christer Looks good to me. Except, I am assuming "shared address" is defined in the spec somewhere. I might have missed it as well. Cheers Suhas On Tue, Nov 12, 2013 at 3:39 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > In Vancouver we decided that an Offerer MUST NOT assign a shared address > (with a non-zero port) to multiple m- lines until the Answerer, within the > session, has indicated support of BUNDLE. > > I suggest the following piece of text to implement the decision in the > BUNDLE spec: > > "The Offerer MUST NOT assign a shared address with a non-zero port > value to multiple "m=" lines until it has, within the given > session, > received an SDP Answer indicating that the Answerer supports the > BUNDLE mechanism." > > Note that there will be specific text regarding the usage of port zero for > 'bundle-only' m- lines. > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bfced1e6fc1fe04eb09cbc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer

Looks good to me. Exc= ept, I am assuming "shared address" is defined in the spec somewh= ere. I might have missed it as well.

Cheers
Su= has


On Tue,= Nov 12, 2013 at 3:39 PM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

In Vancouver we decided that an Offerer MUST NOT assign a shared address (w= ith a non-zero port) to multiple m- lines until the Answerer, within the se= ssion, has indicated support of BUNDLE.

I suggest the following piece of text to implement =A0the decision in the B= UNDLE spec:

=A0 =A0 =A0 =A0 "The Offerer MUST NOT assign a shared address with a n= on-zero port
=A0 =A0 =A0 =A0 value to multiple "m=3D" lines until it has, with= in the given session,
=A0 =A0 =A0 =A0 received an SDP Answer indicating that the Answerer support= s the
=A0 =A0 =A0 =A0 BUNDLE mechanism."

Note that there will be specific text regarding the usage of port zero for = 'bundle-only' m- lines.

Regards,

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

--047d7bfced1e6fc1fe04eb09cbc8-- From christer.holmberg@ericsson.com Wed Nov 13 08:25:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606C21E80F4 for ; Wed, 13 Nov 2013 08:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.734 X-Spam-Level: X-Spam-Status: No, score=-3.734 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZjFopWy5Nfs for ; Wed, 13 Nov 2013 08:25:40 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCAB11E814C for ; Wed, 13 Nov 2013 08:25:39 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-21-5283a7fff51d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 92.45.27941.FF7A3825; Wed, 13 Nov 2013 17:25:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 17:25:34 +0100 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? Thread-Index: Ac7f//9tV1L0gQ17QYeeQ7SNfEjBjAAOGZSAABUezTA= Date: Wed, 13 Nov 2013 16:25:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C518686@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C518686ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvre7/5c1BBp8eqFlMXf6YxWLn3A5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj2s1PzAXHrCqmLj/P3MA437iLkZNDQsBE Yvn7KewQtpjEhXvr2boYuTiEBI4wSsyYOpkdwlnCKNH7eipLFyMHB5uAhUT3P22QBhEBLYnV i+cygYSZBdQlri4OAgkLC+RJPPt0hBkkLCKQL3GwJxui2kpi98aFYKtYBFQlXk54wQRi8wr4 Skzqu8EKsWkKo8Tf+xtZQRKcAoESE3rWgDUwAt32/dQasAZmAXGJDwevM0PcLCCxZM95KFtU 4uXjf6wQtpLE2sPbWSDq8yX2TLrCArFMUOLkzCcsExhFZyEZNQtJ2SwkZRBxPYkbU6ewQdja EssWvoaq15WY8e8QC7L4Akb2VYwcxanFSbnpRgabGIExdXDLb4sdjJf/2hxilOZgURLn/fjW OUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD484w/4TdE667/tjE215onD9N6/Gq3IbFjbc+ KdSucXunmmr3+6zDiuwp+RfNc8/MZ/RnefPIYvrHAG8G/yU8/UckTvhOjdbrbT130NzmUzvf AZ+yrbynvrj+uqw8Z4Wu4sxdy2bu+r1BnOtu0ZLISI9rn92mNiR1C+s9qIqx2BzwvmXGnsfh 95RYijMSDbWYi4oTAXe15FN3AgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 16:25:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C518686ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Suhas, I will add an explicit definition of "shared address" to the next version o= f the draft. Regards, Christer L=E4hett=E4j=E4: Suhas Nandakumar [mailto:suhasietf@gmail.com] L=E4hetetty: 13. marraskuuta 2013 9:20 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers= during session establishment? Hi Christer Looks good to me. Except, I am assuming "shared address" is defined in the = spec somewhere. I might have missed it as well. Cheers Suhas On Tue, Nov 12, 2013 at 3:39 PM, Christer Holmberg > wrote: Hi, In Vancouver we decided that an Offerer MUST NOT assign a shared address (w= ith a non-zero port) to multiple m- lines until the Answerer, within the se= ssion, has indicated support of BUNDLE. I suggest the following piece of text to implement the decision in the BUN= DLE spec: "The Offerer MUST NOT assign a shared address with a non-zero port value to multiple "m=3D" lines until it has, within the given sessi= on, received an SDP Answer indicating that the Answerer supports the BUNDLE mechanism." Note that there will be specific text regarding the usage of port zero for = 'bundle-only' m- lines. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C518686ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Suhas,

 <= /p>

I will add= an explicit definition of ”shared address” to the next version= of the draft.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: Suhas Nandakumar [mailto:suhasietf@gmail.com]
L=E4hetetty: 13. marraskuuta 2013 9:20
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org
Aihe: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/= Answers during session establishment?

 

Hi Christer

 

Looks good to me. Except, I am assuming "shared= address" is defined in the spec somewhere. I might have missed it as = well.

 

Cheers

Suhas

 

On Tue, Nov 12, 2013 at 3:39 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

In Vancouver we decided that an Offerer MUST NOT assign a shared address (w= ith a non-zero port) to multiple m- lines until the Answerer, within the se= ssion, has indicated support of BUNDLE.

I suggest the following piece of text to implement  the decision in th= e BUNDLE spec:

        "The Offerer MUST NOT assign a shared addr= ess with a non-zero port
        value to multiple "m=3D" lines until = it has, within the given session,
        received an SDP Answer indicating that the Answ= erer supports the
        BUNDLE mechanism."

Note that there will be specific text regarding the usage of port zero for = 'bundle-only' m- lines.

Regards,

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

 

--_000_7594FB04B1934943A5C02806D1A2204B1C518686ESESSMB209erics_-- From pkyzivat@alum.mit.edu Wed Nov 13 10:02:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A5D11E8159 for ; Wed, 13 Nov 2013 10:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVI6CNwAOb0T for ; Wed, 13 Nov 2013 10:02:14 -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 15D8F11E80EA for ; Wed, 13 Nov 2013 10:02:13 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id p5pn1m0010xGWP85462DqA; Wed, 13 Nov 2013 18:02:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id p62C1m00V3ZTu2S3Y62CiN; Wed, 13 Nov 2013 18:02:13 +0000 Message-ID: <5283BEA3.4040805@alum.mit.edu> Date: Wed, 13 Nov 2013 10:02:11 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> 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=1384365733; bh=wHPv8FDcLX9+8KMipzWLM8UKIFRDvcxNHnJ96SbGZbI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DCgX+MpSTbY6LIdD0C/h1BIStghAAZchBsH10CuBWikmm6FrrwQ+RCNzwRU4m4mUX wBpAfkMdet2d98vG2dWOMjB06nIkux47Yw3aeD4cRSTDSrCRGq6wSVCiVD27LO1HSB rrE7g8Gnw8fJtFkVgqlm82ps0WfHeXJhoOyaW7Buwp73yRgoSKWsWVaUOKmfkf6Wk5 YTX5B//eRfTj9JUXc38/BBB03T5sIVS9cOvI5IfVWGMUf3oiMBOZmSzm4eH63Zyo1v FffbV6xLIeg4LfSVaIOdWguxHI+I9B/DupXlrI3YPGtZJcale85ggnBMjkzRRRtkFa hiKExGEyVKs7w== Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 18:02:19 -0000 Christer, This works for me except for one thing: the word "session", which I fear is sufficiently ambiguous to present trouble. I suggest using "multi-media session". (We can't use "SIP session" or "SIP dialog" because this might be used without SIP.) Thanks, Paul On 11/12/13 3:39 PM, Christer Holmberg wrote: > Hi, > > In Vancouver we decided that an Offerer MUST NOT assign a shared address (with a non-zero port) to multiple m- lines until the Answerer, within the session, has indicated support of BUNDLE. > > I suggest the following piece of text to implement the decision in the BUNDLE spec: > > "The Offerer MUST NOT assign a shared address with a non-zero port > value to multiple "m=" lines until it has, within the given session, > received an SDP Answer indicating that the Answerer supports the > BUNDLE mechanism." > > Note that there will be specific text regarding the usage of port zero for 'bundle-only' m- lines. > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Nov 13 10:42:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE52A11E815C for ; Wed, 13 Nov 2013 10:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll-4TCESYOEc for ; Wed, 13 Nov 2013 10:42:38 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2674911E8104 for ; Wed, 13 Nov 2013 10:42:37 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-2c-5283c81c230d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.3A.23787.C18C3825; Wed, 13 Nov 2013 19:42:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 19:42:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? Thread-Index: Ac7f//9tV1L0gQ17QYeeQ7SNfEjBjAAkhhmAAANs0jA= Date: Wed, 13 Nov 2013 18:42:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> In-Reply-To: <5283BEA3.4040805@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvra7sieYgg5tHeSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjxundrAXruStmN7E1MHZzdjFyckgImEjM afnKBmGLSVy4tx7I5uIQEjjEKNE56SsrSEJIYAmjxPkfkV2MHBxsAhYS3f+0QcIiAr4Szx7f BusVFsiTePbpCDNIiYhAvsTBnmyIEiuJo7MPMoPYLAKqEk0rj4CV8wK1Tj5/kxlier7E34MH WEBsTgEdibebV4FtZQQ65/upNUwgNrOAuMSHg9eZIc4UkFiy5zyULSrx8vE/VghbSWLR7c9Q 9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm64 iREYBQe3/NbdwXjqnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEo5 i99gX7Q0JU3ihXZG4rUvixjZzXrXc3TlLZvZkXOOfd4Znt9Z93geLnvxzlHueeLU3v2R/5gU j63bo/9XxX61ZrubFKNA6a+Vu9551RkF+ew6fbFNf9IhwfL9WxP9W1ddPRdze9JpnxdsUuel Gpav1Gs9c0SJN/3fxi3/XF85ZTzNuTl7WYISS3FGoqEWc1FxIgDNGGV0UAIAAA== Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 18:42:43 -0000 Hi Paul, > This works for me except for one thing: the word "session", which I fear = is sufficiently ambiguous to present trouble. > > I suggest using "multi-media session". (We can't use "SIP session" or "SI= P dialog" because this might be used without SIP.) I agree regarding not being able to use SIP terminology. I guess "multi-media session" is one option. What about "SDP session"? Regards, Christer On 11/12/13 3:39 PM, Christer Holmberg wrote: > Hi, > > In Vancouver we decided that an Offerer MUST NOT assign a shared address = (with a non-zero port) to multiple m- lines until the Answerer, within the = session, has indicated support of BUNDLE. > > I suggest the following piece of text to implement the decision in the B= UNDLE spec: > > "The Offerer MUST NOT assign a shared address with a non-zero port > value to multiple "m=3D" lines until it has, within the given sessio= n, > received an SDP Answer indicating that the Answerer supports the > BUNDLE mechanism." > > Note that there will be specific text regarding the usage of port zero fo= r 'bundle-only' m- lines. > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Wed Nov 13 11:14:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D540C11E810D for ; Wed, 13 Nov 2013 11:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.258 X-Spam-Level: X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDEF48tvwFze for ; Wed, 13 Nov 2013 11:14:14 -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 2078711E8119 for ; Wed, 13 Nov 2013 11:14:13 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id p0QK1m0081swQuc537EC2J; Wed, 13 Nov 2013 19:14:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id p7EB1m00i3ZTu2S3b7ECME; Wed, 13 Nov 2013 19:14:12 +0000 Message-ID: <5283CF83.2090902@alum.mit.edu> Date: Wed, 13 Nov 2013 11:14:11 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> 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=1384370052; bh=d0IcTnO580Q0dWwBj+5elSVy0FBmxbk7ecz3S8N9qqY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZQzJJuptIuB+CBqC9LY5U2FjO+vBM/C595U7+kachZ/3NChkDddRSfX8JkAqJRLj3 H78q/nl0C9eMGAM1wR7BMYxwkimxvph72q8/S4ahdoY9wzBNVNbeZ3/7ori1XxH0O8 dHd0FVgkFyFPvJlzLFOOcSF0fM1SM3XxxZa1f/yQ5zvkxzVoVBahv4mWDLRxgKlQMT Teptg61JU+ORmmcF202+uyhb8CeUX/fMjh6bk+o5yQ0UGq36ZiuSbUiIHcb8D7HXy4 M1b9LGHp+/0EnX/ePjGM4eUPO7wimmGKvwPkcj1kuDSzqWbKQM7h+Ua0tpCqYvUvOO CTAplplqWCOEQ== Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 19:14:19 -0000 On 11/13/13 10:42 AM, Christer Holmberg wrote: > Hi Paul, > >> This works for me except for one thing: the word "session", which I fear is sufficiently ambiguous to present trouble. >> >> I suggest using "multi-media session". (We can't use "SIP session" or "SIP dialog" because this might be used without SIP.) > > I agree regarding not being able to use SIP terminology. > > I guess "multi-media session" is one option. What about "SDP session"? I thought about that. I'm not in love with multi-media session. When I look at 4566 I find a definition of "session" as multi-media session. I think "SDP session" gets the point across, though I have not seen "SDP session" used anywhere else. Thanks, Paul > Regards, > > Christer > > > On 11/12/13 3:39 PM, Christer Holmberg wrote: >> Hi, >> >> In Vancouver we decided that an Offerer MUST NOT assign a shared address (with a non-zero port) to multiple m- lines until the Answerer, within the session, has indicated support of BUNDLE. >> >> I suggest the following piece of text to implement the decision in the BUNDLE spec: >> >> "The Offerer MUST NOT assign a shared address with a non-zero port >> value to multiple "m=" lines until it has, within the given session, >> received an SDP Answer indicating that the Answerer supports the >> BUNDLE mechanism." >> >> Note that there will be specific text regarding the usage of port zero for 'bundle-only' m- lines. >> >> Regards, >> >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Nov 13 11:32:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330D121E811A for ; Wed, 13 Nov 2013 11:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbUcvJNR67TJ for ; Wed, 13 Nov 2013 11:32:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4322B21E80A8 for ; Wed, 13 Nov 2013 11:32:13 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-95-5283d3bc4f01 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 95.3F.03802.CB3D3825; Wed, 13 Nov 2013 20:32:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 20:32:11 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: VS: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? Thread-Index: Ac7f//9tV1L0gQ17QYeeQ7SNfEjBjAAkhhmAAANs0jD///i3gP//6mnA Date: Wed, 13 Nov 2013 19:32:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C51883A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> <5283CF83.2090902@alum.mit.edu> In-Reply-To: <5283CF83.2090902@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre6ey81BBld+8llMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGg8/KBYv5Kk532jQwruPuYuTkkBAwkVh8 ZA0LhC0mceHeerYuRi4OIYFDjBJHJ25lhHCWMEq8nXmHvYuRg4NNwEKi+582SIOIgK/Es8e3 2UBsYYEiiS3TfzJCxIslLp36wQRhu0nsWnAfrIZFQFVi2+dtYDYvUO/RU3Ohll1llFi94T87 SIJTQEdi0rb/rCA2I9BF30+tARvELCAu8eHgdWaISwUkluw5D2WLSrx8/I8VwlaSWLH9EiNE vY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtt YgRGwsEtv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNui fj1qOF9bkcYqyqsovNxxndW/NdPUG01d5zxXfiVxJ3Llnf5NMwx83rxl+umfYPf2o+HfkFOH C+8yVfw0tCl7+jqvIOLUmS3cv9+nMaX2rlV6m1s4gSfHMn7jFSOhJ2e2h2nEWGy0WiB0vuDY 1t4PGye+X6ZRkW19pcKx/O7l12cS680UepVYijMSDbWYi4oTAQDISfpSAgAA Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 19:32:20 -0000 Hi, >>> This works for me except for one thing: the word "session", which I fea= r is sufficiently ambiguous to present trouble. >>> >>> I suggest using "multi-media session". (We can't use "SIP session" or=20 >>> "SIP dialog" because this might be used without SIP.) >> >> I agree regarding not being able to use SIP terminology. >> >> I guess "multi-media session" is one option. What about "SDP session"? > > I thought about that. I'm not in love with multi-media session. > > When I look at 4566 I find a definition of "session" as multi-media sessi= on. I think "SDP session" gets the point across, though I have not seen "SD= P session" used anywhere else. We could even say "SDP session (e.g. a SIP dialog)" Regards, Christer > On 11/12/13 3:39 PM, Christer Holmberg wrote: >> Hi, >> >> In Vancouver we decided that an Offerer MUST NOT assign a shared address= (with a non-zero port) to multiple m- lines until the Answerer, within the= session, has indicated support of BUNDLE. >> >> I suggest the following piece of text to implement the decision in the = BUNDLE spec: >> >> "The Offerer MUST NOT assign a shared address with a non-zero port >> value to multiple "m=3D" lines until it has, within the given sess= ion, >> received an SDP Answer indicating that the Answerer supports the >> BUNDLE mechanism." >> >> Note that there will be specific text regarding the usage of port zero f= or 'bundle-only' m- lines. >> >> Regards, >> >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From suhasietf@gmail.com Wed Nov 13 14:43:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DF921E8091 for ; Wed, 13 Nov 2013 14:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NewYdXmEpNEg for ; Wed, 13 Nov 2013 14:43:16 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F421E808A for ; Wed, 13 Nov 2013 14:43:15 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id ey11so6047395wid.6 for ; Wed, 13 Nov 2013 14:43:15 -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=QQ6slDDVPIh158lozK8PwKcu5yGzohFpK18hAjosJxc=; b=C4JImwlIFTDyiAGNKAYQMPg96HSsvUdEqRDTKqIGv7JfkbVN0ivIZszIy2k+zYsQKX LKw5QbVpFK097q3XamjAKxglcV0sfS41MmpBAetGCmAw19AGqlU16BObH3Klx59u6WAq eRBPMiqyqv7P7SnJBeNdKJrSmDa4TfUimL4EEgXurtuOwWqH0+bQ4m/9b+iZ3F4U6HbK 1SFP4Lmaufv8tLKfMYP3EoA/ic+zQH+VRuvSMtGARDZbQ7wTwCu8ongoDWV3LvzhxWdI Dz+/4YaSDFjBGASGy8tEu6KV4YS4upG+AvXVMGi5pTi/cmciZAs6SQZuXq5p62fF0jFi 6hcw== MIME-Version: 1.0 X-Received: by 10.180.185.101 with SMTP id fb5mr22482029wic.11.1384382595227; Wed, 13 Nov 2013 14:43:15 -0800 (PST) Received: by 10.194.178.231 with HTTP; Wed, 13 Nov 2013 14:43:15 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C51883A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> <5283CF83.2090902@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C51883A@ESESSMB209.ericsson.se> Date: Wed, 13 Nov 2013 14:43:15 -0800 Message-ID: From: Suhas Nandakumar To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2448ed2663504eb16b0cd Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 22:43:19 -0000 --001a11c2448ed2663504eb16b0cd Content-Type: text/plain; charset=ISO-8859-1 Hi Christer If it helps, I might point you to the Taxonomy document to see if there is a terminology from that document that better fits the purpose for naming here http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-00 Cheers Suhas On Wed, Nov 13, 2013 at 11:32 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> This works for me except for one thing: the word "session", which I > fear is sufficiently ambiguous to present trouble. > >>> > >>> I suggest using "multi-media session". (We can't use "SIP session" or > >>> "SIP dialog" because this might be used without SIP.) > >> > >> I agree regarding not being able to use SIP terminology. > >> > >> I guess "multi-media session" is one option. What about "SDP session"? > > > > I thought about that. I'm not in love with multi-media session. > > > > When I look at 4566 I find a definition of "session" as multi-media > session. I think "SDP session" gets the point across, though I have not > seen "SDP session" used anywhere else. > > We could even say "SDP session (e.g. a SIP dialog)" > > Regards, > > Christer > > > > On 11/12/13 3:39 PM, Christer Holmberg wrote: > >> Hi, > >> > >> In Vancouver we decided that an Offerer MUST NOT assign a shared > address (with a non-zero port) to multiple m- lines until the Answerer, > within the session, has indicated support of BUNDLE. > >> > >> I suggest the following piece of text to implement the decision in the > BUNDLE spec: > >> > >> "The Offerer MUST NOT assign a shared address with a non-zero port > >> value to multiple "m=" lines until it has, within the > given session, > >> received an SDP Answer indicating that the Answerer > supports the > >> BUNDLE mechanism." > >> > >> Note that there will be specific text regarding the usage of port zero > for 'bundle-only' m- lines. > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c2448ed2663504eb16b0cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christer

=A0 If it helps, I might po= int you to the Taxonomy document to see if there is a terminology from that= document that better fits the purpose for naming here

=

Cheers
Suhas


On Wed, Nov 13, 2013 at 11:32 AM, Christ= er Holmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

>>> This works for me except for one thing: the word "session= ", which I fear is sufficiently ambiguous to present trouble.
>>>
>>> I suggest using "multi-media session". (We can't= use "SIP session" or
>>> "SIP dialog" because this might be used without SIP.= )
>>
>> I agree regarding not being able to use SIP terminology.
>>
>> I guess "multi-media session" is one option. What about = "SDP session"?
>
> I thought about that. I'm not in love with multi-media session. >
> When I look at 4566 I find a definition of "session" as mult= i-media session. I think "SDP session" gets the point across, tho= ugh I have not seen "SDP session" used anywhere else.

We could even say "SDP session (e.g. a SIP dialog)"

Regards,

Christer


> On 11/12/13 3:39 PM, Christer Holmberg wrote:
>> Hi,
>>
>> In Vancouver we decided that an Offerer MUST NOT assign a shared a= ddress (with a non-zero port) to multiple m- lines until the Answerer, with= in the session, has indicated support of BUNDLE.
>>
>> I suggest the following piece of text to implement =A0the decision= in the BUNDLE spec:
>>
>> =A0 =A0 =A0"The Offerer MUST NOT assign a shared address with= a non-zero port
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0value to multiple "m=3D" line= s until it has, within the given session,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0received an SDP Answer indicating that = the Answerer supports the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0BUNDLE mechanism."
>>
>> Note that there will be specific text regarding the usage of port = zero for 'bundle-only' m- lines.
>>
>> Regards,
>>
>> Christer
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

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

--001a11c2448ed2663504eb16b0cd-- From christer.holmberg@ericsson.com Wed Nov 13 15:29:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB92621E80ED for ; Wed, 13 Nov 2013 15:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHUFm7PBwJCw for ; Wed, 13 Nov 2013 15:28:56 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 208EF21E80B9 for ; Wed, 13 Nov 2013 15:28:55 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-81-52840b35b46a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.FA.15980.53B04825; Thu, 14 Nov 2013 00:28:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 00:28:53 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE DECISION Q8: SDP 'bundle-only' attribute Thread-Index: Ac7gCRpceAmIueuZSE+3AnYuzIwR9g== Date: Wed, 13 Nov 2013 23:28:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C518B4A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvra4Zd0uQwf2rahZ7/i5it5i6/DGL A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJUx5fUB9oKL8hWTVt1kaWDcLNHFyMEhIWAi 8e9tQBcjJ5ApJnHh3nq2LkYuDiGBQ4wS1y9MY4ZwljBK7O/bzgrSwCZgIdH9TxukQURAXeLr 3h5mEJtZQFPi35O37CC2MFDJzU2L2CFqbCUuv29ig7D1JE6+OMoKYrMIqEocmdgGZvMK+Ep8 fPqNEcRmBDri+6k1TBAzxSU+HLzODHGcgMSSPeehbFGJl4//sULYShKNS56wQtTrSCzY/YkN wtaWWLbwNTPEfEGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq5+SZGYMAf3PLb YAfjpvtihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAo0Hp3pdGrjUZV nD8aLKvK5+zWU4pcFuypEb+I+WTJlOqdKX17pJ6zLDr70cV5ab9RMsO8CxtWmem1VDmqvW+f HX+Bb9IR7g8Rfp5T60pvin7WrC3M/Np58NlRn+1zpIQssgM3CClX3FvAF726zCfKqDLr8aOq oAAGxxOrWtv56m8cn9vyvV+JpTgj0VCLuag4EQBL+lSORgIAAA== Subject: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 23:29:03 -0000 Hi, Based on the decision in Vancouver to define the usage of port zero in 'bun= dle-only' m- lines, I've updated the new text I proposed some time ago. One question that was raised in Vancouver is whether we will have to update= RFC 3264, so I've added a new OPEN ISSUE (13) for that. ----------------------------------------------- 7. SDP 'bundle-only' Attribute 7.1. General This section defines a new SDP media-level attribute [RFC4566], 'bundle-only'. The attribute is used, in an SDP Offer, to indicate that an "m=3D" line, to which the attribute has been assigned, within a BUNDLE group is only to be accepted if the Answerer in the SDP Answer keeps the "m=3D" line within the BUNDLE group. 7.2. SDP Offer/Answer Procedures 7.2.1. SDP Offer Procedures When an Offerer sends an SDP Offer, which contains a BUNDLE group, it can assign an SDP 'bundle-only' attribute to an "m=3D" lines within with the BUNDLE group, in order to request that the Answerer only accepts the "m=3D" line if is kept within the BUNDLE group. The Offerer can assign a 'bundle-only' attribute to any number of "m=3D" lines within a BUNDLE group. The Offerer MUST NOT assign a 'bundle-only' attribute to an "m=3D" line that is not within a BUNDLE group. If the Offerer, for the given SDP session, has not received an SDP Answer indicating that the Answerer supports the BUNDLE mechanism, the Offerer MUST in the SDP Offer assign a zero port value to any "m=3D" line to which it assigns a 'bundle-only' attribute. This will ensure that the Answerer, if it does not support the BUNDLE mechanism, will reject such "m=3D" line. As described in Section 6.4.3, once the Offerer has received an SDP Answer, indicating that the Answerer supports the BUNDLE mechanism, the Offerer can assign a shared address to an "m=3D" line within a BUNDLE group. This also applies to "m=3D" lines to which the Offerer has assigned a 'bundle-only' attribute. If the Offerer, in a subsequent SDP Offer, wants to ensure that an "m=3D" line is rejected unless it is kept within the BUNDLE group, it MUST assign a 'bundle-only' attribute to such "m=3D" line. Otherwise the Offerer MUST NOT assign a 'bundle-attribute' to such "m=3D" line. If the Offerer, in a subsequent SDP Offer, wants to move an "m=3D" line out of a BUNDLE group Section 6.4.5, it MUST NOT assign a 'bundle- only' attribute to such "m=3D" line. If the Offerer, in a subsequent SDP Offer, wants to disable an "m=3D" line in a BUNDLE group Section 6.4.6, it MUST NOT assign a 'bundle- only' attribute to such "m=3D" line. 7.2.2. SDP Answer Procedures When the Answerer determines the BUNDLE address for the Offerer Section 6.5.1, it also takes any "m=3D" line to which the Offerer has assigned a 'bundle-only' attribute into consideration. If the Offerer has assigned a 'bundle-only' attribute, and a zero port value, to an "m=3D" line, and if the Answerer accepts the "m=3D" line, it follows the procedures in section Section 6.5.1. If the Offerer has assigned a 'bundle-only' attribute, and a non-zero port value, to an "m=3D" line, it is an indication that the Offerer wants to disable the "m=3D" line Section 6.4.6. The Answerer MUST in the SDP Answer assign a zero port value to such "m=3D" line Section 6.5.4. If the Answerer chooses to not keep an "m=3D" line, to which the Offerer has assigned a 'bundle-only' attribute, within a BUNDLE group, the Answerer MUST reject the "m=3D" line Section 6.5.4. An Answerer MUST NOT assign a 'bundle-only' attribute to an "m=3D" lines in an SDP Answer. OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Answer to a zero port value in an SDP Offer. As we now allow a non-zero value in the SDP Answer, do we need to update 3264 procedures? ----------------------------------------------- From pkyzivat@alum.mit.edu Wed Nov 13 16:19:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F4B21E816D for ; Wed, 13 Nov 2013 16:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDwjg1jXnrYf for ; Wed, 13 Nov 2013 16:19:52 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE3221E8185 for ; Wed, 13 Nov 2013 16:19:51 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id p8fu1m0031ZXKqc57CKqyf; Thu, 14 Nov 2013 00:19:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id pCKp1m00Y3ZTu2S3hCKpNx; Thu, 14 Nov 2013 00:19:50 +0000 Message-ID: <52841724.5000002@alum.mit.edu> Date: Wed, 13 Nov 2013 16:19:48 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Suhas Nandakumar , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> <5283CF83.2090902@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C51883A@ESESSMB209.ericsson.se> In-Reply-To: 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=1384388390; bh=9uDiylVeDHQY3PZBiQm6JcORzQMflA6Hwtl7TYuu/08=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YcWU1UcI7s8CMbhAzaR5BfUyGSdYnzX+ZC0YnYaTmMhDF+jxw0VLUJdDSkwdL6Tn1 Ny/LSEsyXUBLPSrblRyDmbUDKEQARVVQ730NlDCOkfyoxLhVYd4rlp5XvrZHHd8kOn YcmI7ydL6c6UwM/YYSYMvO8ahmEoRAFRCgHVvL/kJf4eGEAFKfBwfrYQDSZXV6PctN cVSPJv+VKUG0pW9uX0n3Otdf8q/uIvAvi//u5SvE/yAl4AfBol8yiX4YqYlaH17I0p MEln3XWeFWP9AEqeAc5Ub8SmKsm5j5sxTSC2uOnf2b5wumH4Zy9gMTNC4c7bIN8OS1 ZnLPoBt5coH7Q== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 00:19:57 -0000 On 11/13/13 2:43 PM, Suhas Nandakumar wrote: > Hi Christer > > If it helps, I might point you to the Taxonomy document to see if > there is a terminology from that document that better fits the purpose > for naming here > > http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-00 I don't think the taxonomy is particularly helpful here. (Maybe it should be.) The concept we are after is at the extreme upper boundary of what the taxonomy considers. It has a definition of multimedia session, and also mentions definitions from 4566 and 3550. They are all quite similar, but not identical. Our use here is, I think, roughly a subset of the 4566 definition, where there are only two participants. But it might not actually be so. It is unclear in those definitions whether the participants are the senders and receivers of signaling, or the senders and receivers of media. Often, but not always, they are the same. For the purposes of this draft we want to be talking about the senders and receivers of the SDP offers and answers. It may be necessary to create a definition for the purpose. Thanks, Paul > Cheers > Suhas > > > On Wed, Nov 13, 2013 at 11:32 AM, Christer Holmberg > > > wrote: > > Hi, > > >>> This works for me except for one thing: the word "session", > which I fear is sufficiently ambiguous to present trouble. > >>> > >>> I suggest using "multi-media session". (We can't use "SIP > session" or > >>> "SIP dialog" because this might be used without SIP.) > >> > >> I agree regarding not being able to use SIP terminology. > >> > >> I guess "multi-media session" is one option. What about "SDP > session"? > > > > I thought about that. I'm not in love with multi-media session. > > > > When I look at 4566 I find a definition of "session" as > multi-media session. I think "SDP session" gets the point across, > though I have not seen "SDP session" used anywhere else. > > We could even say "SDP session (e.g. a SIP dialog)" > > Regards, > > Christer > > > > On 11/12/13 3:39 PM, Christer Holmberg wrote: > >> Hi, > >> > >> In Vancouver we decided that an Offerer MUST NOT assign a shared > address (with a non-zero port) to multiple m- lines until the > Answerer, within the session, has indicated support of BUNDLE. > >> > >> I suggest the following piece of text to implement the decision > in the BUNDLE spec: > >> > >> "The Offerer MUST NOT assign a shared address with a > non-zero port > >> value to multiple "m=" lines until it has, within > the given session, > >> received an SDP Answer indicating that the Answerer > supports the > >> BUNDLE mechanism." > >> > >> Note that there will be specific text regarding the usage of > port zero for 'bundle-only' m- lines. > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > From christer.holmberg@ericsson.com Wed Nov 13 17:21:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3A821E80BF for ; Wed, 13 Nov 2013 17:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnNUBWfyv1Lt for ; Wed, 13 Nov 2013 17:21:33 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5FD911E8102 for ; Wed, 13 Nov 2013 17:21:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-3a-5284259a98d4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 12.9B.23787.A9524825; Thu, 14 Nov 2013 02:21:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 02:21:30 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHO4NZi9flj5ss1UEu1a/Ao76gxKJoj7Uow Date: Thu, 14 Nov 2013 01:21:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C518E13@ESESSMB209.ericsson.se> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C518E13ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvre5s1ZYgg48VFn9afzFabF2faDF1 +WMWB2aP1md7WT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRd34pY8HJM0wVc7v+MTcwvlnE1MXI ySEhYCLRcaKRGcIWk7hwbz1bFyMXh5DAIUaJxl9rmCCcJYwS/Vf+sncxcnCwCVhIdP/TBmkQ EfCQuL/gGBuIzSyQJjGhcz3YUGEBb4mlnX1MEDU+Eht6DzKBtIoIGEm0fOcCCbMIqEqsXj2T FcTmFfCVaDpziRFi1SpWiQvTJ4AlOAWiJf5taGMBsRmBjvt+ag0TxC5xiQ8Hr0MdLSCxZM95 KFtU4uXjf6wQtpLEotufoerzJT5uXQK1TFDi5MwnLBMYRWchGTULSdksJGUQcT2JG1OnsEHY 2hLLFr6GqteVmPHvEAuy+AJG9lWM7LmJmTnp5YabGIHRdXDLb90djKfOiRxilOZgURLn/fDW OUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo3BMe9L9xUVafOUnntzbUfjuYsGKu60fOr0O 1hfG7VltZHMtl09is8LdLXrJnbsKq2ZlfTf9yiU3V9fE7wpXk6vkLb7AxdH7t5+tkjqvsS4q IeJHzfHvrqtuVT9ZM+FR7MbW9VGHyqIjzvsLHu17rXvCVVHm28ei5DtPvcRnT5JMEG2beOrt VSWW4oxEQy3mouJEACB1rqB8AgAA Cc: "mmusic@ietf.org" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:21:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C518E13ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Albrecht, If I understand your proposal correctly, the change would be to relax the r= ule for assigning the SDP setup attribute value in the SDP Offer. Instead o= f mandating actpass, we would also allow active and passive. Right? Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 14. marraskuuta 2013 3:11 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Aihe: AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, guess it's time to come back on this topic since the WG adopted the draft. In brief ("don't want to repeat again the thread"): a) problem statement: existing SDP O/A rules define a tighly coupled mode b= etween the establishment direction of the SIP session and the establishment= direction of the DTLS session, but there's not any reasoning for such tigh= tly coupled behaviour. b) change proposal: Revise in clause 3.1 following list item o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer MUST assign the SDP setup attribute with setup:actpass value, and MUST be prepared to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). by o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer MUST assign the SDP setup attribute with a setup:actpass, set= up:active or setup:passive value, and, in case of setup:actpass or setup:passive, MUST be prepar= ed to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value, in case of setup:actpass or se= tup:passive. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). We would limit ourselves with the existing, restrictive SDP O/A rule. And w= ithout any justification for such a constraint. Any comments? Regards, Albrecht ________________________________ Von: Christer Holmberg [christer.holmberg@ericsson.com] Gesendet: Montag, 7. Oktober 2013 13:11 An: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, At this point, the community is making a decision about whether to start wo= rking on this. Once that is done, we will start looking into, and discuss, individual tech= nical issues etc, and your input will be highly appreciated. Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 7. lokakuuta 2013 13:56 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, I may not commit to submit a problem statement in the next couple of weeks,= just due to time reasons. At least a note (or editor's note) should be added to draft mmusic-udptl-dt= ls in order to indicate the issue and that a solution proposal is still pen= ding. Thanks, Albrecht From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 24. September 2013 16:01 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't think putting a note somewhere in the fax draft is going to solve a= nything. As you indicate, the issue exists in multiple documents, so it's a generic = issues. So, my suggestion is that you put together a short draft which describes th= e problem, and how you want to change it, and then we can have a more gener= ic discussion about it. The WG can then decide whether we shall fix somethi= ng, and if so, in which specs. Regards, Christer ________________________________ From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] Sent: Tuesday, 24 September 2013 4:22 PM To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the "copy & paste" action (across at least three "RFCs") seems to be the ro= ot cause of the issue :-( SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific. We got here (wrt DTLS) three (different!) applications: 1) Key exchange (RFC 5763) 2) Conference control (rfc4582bis) 3) Document transmission (udptl-dtls) All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology. Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility. The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules. What we got so far: SDP O/A rules in three application specific "RFCs" (RFC= 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( There might be two options to correct that copy & paste issue in "udptl-dtl= s" in my opinion: a) expand the SDP O/A rules for more flexibility or b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763) What do you think? Best regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Montag, 23. September 2013 11:54 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say: "The endpoint that is the offerer MUST use the setup attribute value of set= up:actpass" ...which we also copied into the udptl-dtls draft. Now, if you want to change that, and allow the Offerer to "force" the direc= tion, I think you should start a separate thread about that. Because, it is= not specific to fax, in my opinion. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 23. syyskuuta 2013 12:31 To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the decision about "DTLS session establishment direction" is ALWAYS up to t= he SDP ANSWERER (according present 3.1). In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active" and "set= up:passive" (besides codepoint "setup:actpass") in my understanding. I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at: a) T - T b) T -GW The existing udptl-dtls & RFC 5763 text seems to focus on model (a) only: S= DP O/A between two peering, terminal located SIP UAs (there is NOT any SIP = B2BUA). But I could imagine that the SIP/SDP profiles for "T" and "GW" are not nece= ssarily the same in case of model (b): "T" as SDP Offerer may not allowed t= o decide the DTLS session establishment direction, but "GW" as SDP offerer = may need to enforce the DTLS session establishment direction (either way). Regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 19. September 2013 10:02 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server. Section 3.1 states: .... The offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the = SDP setup attribute with the setup:active value. Whichever party is active = MUST initiate a DTLS handshake by sending a ClientHello over each flow (hos= t/port quartet). The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC. BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 18. syyskuuta 2013 18:28 To: Christer Holmberg Cc: mmusic@ietf.org Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of a) T - T b) T -GW c) GW-GW I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints. Christer, I thought that the two directions of 1) SIP session establishment and 2) DTLS session establishment should be NOT tightly coupled (as currently supposed to be in clause 3.1)? The ietf draft should offer the flexibility in decoupling both establishmen= t directions. E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ... In my opinion: the IETF should allow the flexibility, other SDOs could still profile/limit this capability. Best regards, Albrecht PS We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP. --_000_7594FB04B1934943A5C02806D1A2204B1C518E13ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Albrech= t,

 = ;

If I under= stand your proposal correctly, the change would be to relax the rule for as= signing the SDP setup attribute value in the SDP Offer. Instead of mandating actpass, we would also allow active and passive.

 = ;

Right?

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com= ]
L=E4hetetty: 14. marraskuuta 2013 3:11
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Aihe: AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 

Hello Christer,
guess it's time to come back on this topic since the WG adopted the draft.<= br>
In brief ("don't want to repeat again the thread"):
a) problem statement: existing SDP O/A rules define a tighly coupled mode b= etween the establishment direction of the SIP session and the establishment= direction of the DTLS session, but there's not any reasoning for such tigh= tly coupled behaviour.

b) change proposal:
Revise in clause 3.1 following list item

   o  The endpoint MUST use the SDP setup att= ribute [RFC4145].  The

      offerer MUST assign the SDP s= etup attribute with setup:actpass

      value, and MUST be prepared t= o receive a DTLS client_hello message

      before it receives the SDP an= swer.  The answerer MUST assign the=

      SDP setup attribute with eith= er setup:active value or

      setup:passive value.  Th= e answerer SHOULD assign the SDP setup

      attribute with the setup:acti= ve value.  Whichever party is active

      MUST initiate a DTLS handshak= e by sending a ClientHello over each

      flow (host/port quartet).


by

   o  The endpoi= nt MUST use the SDP setup attribute [RFC4145].  The

      = offerer MUST assign the SDP setup attribute with a setup:actpass, setup:act= ive or setup:passive

      = value, and, in case of setup:actpass or setup:passive, MUST be prepared to = receive a DTLS client_hello message=

      = before it receives the SDP answer.  The answerer MUST assign the

      = SDP setup attribute with either setup:active value or

      = setup:passive value.  The answerer SHOULD assign the SDP setup<= span style=3D"color:black">

      = attribute with the setup:active value, in case of setup:actpass or setup:pa= ssive.  Whichever party is active

      = MUST initiate a DTLS handshake by sending a ClientHello over each

      = flow (host/port quartet).


We would limit ourselves with the existing, restrictive SDP O/A rule. And w= ithout any justification for such a constraint.

Any comments?

Regards,
Albrecht


Von: Christer Holmberg [christer.h= olmberg@ericsson.com]
Gesendet: Montag, 7. Oktober 2013 13:11
An: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS,= BRUNO (BRUNO)
Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hi Albrech= t,

 

At this po= int, the community is making a decision about whether to start working on t= his.

 

Once that = is done, we will start looking into, and discuss, individual technical issu= es etc, and your input will be highly appreciated.

 

Regards,

 

Christer

 

L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent= .com]
L=E4hetetty: 7. lokakuuta 2013 13:56
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org; LANDA= IS, BRUNO (BRUNO)
Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 =

Hello Chri= ster,

I may not = commit to submit a problem statement in the next couple of weeks, just due = to time reasons.

At least a= note (or editor’s note) should be added to draft mmusic-udptl-dtls i= n order to indicate the issue and that a solution proposal is still pending.

 

Thanks,

Albrecht

 

 

From: Christer Holmberg [mailto:christer.h= olmberg@ericsson.com]
Sent: Dienstag, 24. September 2013 16:01
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf= .org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

 

Hi Albrecht,

 

I don't think putting a note some= where in the fax draft is going to solve anything.

 

As you indicate, the issue exists= in multiple documents, so it's a generic issues.

 

So, my suggestion is that you put= together a short draft which describes the problem, and how you want to ch= ange it, and then we can have a more generic discussion about it. The WG can then decide whether we shall fix something, and if so= , in which specs.

 

Regards,

 

Christer

 

 

From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com]
Sent: Tuesday, 24 September 2013 4:22 PM
To: Christer Holmberg
Cc: mmusic@ietf= .org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hello Christe= r,

the "copy & paste" action (across at least three "RFCs&q= uot;) seems to be the root cause of the issue :-(

SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific.
We got here (wrt DTLS) three (different!) applications:
1) Key exchange (RFC 5763)
2) Conference control (rfc4582bis)
3) Document transmission (udptl-dtls)

All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs&= quot; (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 := -(

There might be two options to correct that copy & paste issue in "= udptl-dtls" in my opinion:
a) expand the SDP O/A rules for more flexibility
or
b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763)

What do you think?
Best regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say:

"The endpoint that is the offerer MUST use the setup attribute value o= f setup:actpass"

...which we also copied into the udptl-dtls draft.

Now, if you want to change that, and allow the Offerer to "force"= the direction, I think you should start a separate thread about that. Beca= use, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hello Christer,

the decision about "DTLS session establishment direction" is ALWA= YS up to the SDP ANSWERER (according present 3.1).

In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active"= ; and "setup:passive" (besides codepoint "setup:actpass"= ;) in my understanding.

I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at:
a) T - T
b) T -GW

The existing udptl-dtls & RFC 5763 text seems to focus on model (a) onl= y: SDP O/A between two peering, terminal located SIP UAs (there is NOT any = SIP B2BUA).
But I could imagine that the SIP/SDP profiles for "T" and "G= W" are not necessarily the same in case of model (b): "T" as= SDP Offerer may not allowed to decide the DTLS session establishment direc= tion, but "GW" as SDP offerer may need to enforce the DTLS sessio= n establishment direction (either way).

Regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:a= ctive value. Whichever party is active MUST initiate a DTLS handshake by se= nding a ClientHello over each flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination.

Regards,

Christer





-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?<= br> The ietf draft should offer the flexibility in decoupling both establishmen= t directions.

E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP.

--_000_7594FB04B1934943A5C02806D1A2204B1C518E13ESESSMB209erics_-- From albrecht.schwarz@alcatel-lucent.com Wed Nov 13 17:11:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45D821E8098 for ; Wed, 13 Nov 2013 17:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dqgvl-O3ly5 for ; Wed, 13 Nov 2013 17:11:02 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 058E421F9EE0 for ; Wed, 13 Nov 2013 17:11:01 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAE1AurZ022326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 19:10:57 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAE1AtpQ005409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 02:10:55 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 14 Nov 2013 02:10:55 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: Ac60g62jSxVm2TCNSGW1wolV+AvE6AAhc/7wAMub3fD///RlAP/+GRRQgAO+MAD/66WaMIAomS8AgDsvrfg= Date: Thu, 14 Nov 2013 01:10:54 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC107E9DFR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Wed, 13 Nov 2013 17:21:52 -0800 Cc: "mmusic@ietf.org" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:11:09 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC107E9DFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Christer, guess it's time to come back on this topic since the WG adopted the draft. In brief ("don't want to repeat again the thread"): a) problem statement: existing SDP O/A rules define a tighly coupled mode b= etween the establishment direction of the SIP session and the establishment= direction of the DTLS session, but there's not any reasoning for such tigh= tly coupled behaviour. b) change proposal: Revise in clause 3.1 following list item o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer MUST assign the SDP setup attribute with setup:actpass value, and MUST be prepared to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). by o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer MUST assign the SDP setup attribute with a setup:actpass, set= up:active or setup:passive value, and, in case of setup:actpass or setup:passive, MUST be prepar= ed to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value, in case of setup:actpass or se= tup:passive. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). We would limit ourselves with the existing, restrictive SDP O/A rule. And w= ithout any justification for such a constraint. Any comments? Regards, Albrecht ________________________________ Von: Christer Holmberg [christer.holmberg@ericsson.com] Gesendet: Montag, 7. Oktober 2013 13:11 An: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, At this point, the community is making a decision about whether to start wo= rking on this. Once that is done, we will start looking into, and discuss, individual tech= nical issues etc, and your input will be highly appreciated. Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 7. lokakuuta 2013 13:56 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, I may not commit to submit a problem statement in the next couple of weeks,= just due to time reasons. At least a note (or editor=92s note) should be added to draft mmusic-udptl-= dtls in order to indicate the issue and that a solution proposal is still p= ending. Thanks, Albrecht From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 24. September 2013 16:01 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't think putting a note somewhere in the fax draft is going to solve a= nything. As you indicate, the issue exists in multiple documents, so it's a generic = issues. So, my suggestion is that you put together a short draft which describes th= e problem, and how you want to change it, and then we can have a more gener= ic discussion about it. The WG can then decide whether we shall fix somethi= ng, and if so, in which specs. Regards, Christer ________________________________ From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] Sent: Tuesday, 24 September 2013 4:22 PM To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the "copy & paste" action (across at least three "RFCs") seems to be the ro= ot cause of the issue :-( SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific. We got here (wrt DTLS) three (different!) applications: 1) Key exchange (RFC 5763) 2) Conference control (rfc4582bis) 3) Document transmission (udptl-dtls) All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology. Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility. The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules. What we got so far: SDP O/A rules in three application specific "RFCs" (RFC= 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( There might be two options to correct that copy & paste issue in "udptl-dtl= s" in my opinion: a) expand the SDP O/A rules for more flexibility or b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763) What do you think? Best regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Montag, 23. September 2013 11:54 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say: "The endpoint that is the offerer MUST use the setup attribute value of set= up:actpass" ...which we also copied into the udptl-dtls draft. Now, if you want to change that, and allow the Offerer to "force" the direc= tion, I think you should start a separate thread about that. Because, it is= not specific to fax, in my opinion. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 23. syyskuuta 2013 12:31 To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the decision about "DTLS session establishment direction" is ALWAYS up to t= he SDP ANSWERER (according present 3.1). In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active" and "set= up:passive" (besides codepoint "setup:actpass") in my understanding. I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at: a) T - T b) T -GW The existing udptl-dtls & RFC 5763 text seems to focus on model (a) only: S= DP O/A between two peering, terminal located SIP UAs (there is NOT any SIP = B2BUA). But I could imagine that the SIP/SDP profiles for "T" and "GW" are not nece= ssarily the same in case of model (b): "T" as SDP Offerer may not allowed t= o decide the DTLS session establishment direction, but "GW" as SDP offerer = may need to enforce the DTLS session establishment direction (either way). Regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 19. September 2013 10:02 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server. Section 3.1 states: .... The offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the = SDP setup attribute with the setup:active value. Whichever party is active = MUST initiate a DTLS handshake by sending a ClientHello over each flow (hos= t/port quartet). The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC. BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 18. syyskuuta 2013 18:28 To: Christer Holmberg Cc: mmusic@ietf.org Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of a) T - T b) T -GW c) GW-GW I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints. Christer, I thought that the two directions of 1) SIP session establishment and 2) DTLS session establishment should be NOT tightly coupled (as currently supposed to be in clause 3.1)? The ietf draft should offer the flexibility in decoupling both establishmen= t directions. E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ... In my opinion: the IETF should allow the flexibility, other SDOs could still profile/limit this capability. Best regards, Albrecht PS We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP. --_000_786615F3A85DF44AA2A76164A71FE1AC107E9DFR711WXCHMBA03zeu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Christer,
guess it's time to come back on this topic since the WG adopted the draft.<= br>
In brief ("don't want to repeat again the thread"):
a) problem statement: existing SDP O/A rules define a tighly coupled mode b= etween the establishment direction of the SIP session and the establishment= direction of the DTLS session, but there's not any reasoning for such tigh= tly coupled behaviour.

b) change proposal:
Revise in clause 3.1 following list item

   o  The endpoint MUST us= e the SDP setup attribute [RFC4145].  The

      offerer MUST assign the SDP setup attribute with setup:actpass

      value, and MUST be prepared to receive a DTLS client_hello message

      before it receives the SDP answer.&= nbsp; The answerer MUST assign the

      SDP setup attribute with either setup:active value or

      setup:passive value.  T= he answerer SHOULD assign the SDP setup

      attribute with the setup:active value.  Whichever party is active

      MUST initiate a DTLS handshake by sending a ClientHello over each

      flow (host/port quartet).


by

   o  The endpoint MUST use the S= DP setup attribute [RFC4145].  The

      offerer MUST assign the SDP setup attribute with a setup:actpass, setup:act= ive or setup:passive

      value, and, in case of setup:actpass or setup:passive, MUST be prepared to = receive a DTLS client_hello message

      before it receives the SDP answer.  <= /span>The answerer MUST assign the

      SDP setup attribute with either setup:active value or

      setup:passive value.  The answ= erer SHOULD assign the SDP setup

      attribute with the setup:active value, in case of setup:actpass or setup:pa= ssive.  Whichever party is active

      MUST initiate a DTLS handshake by sending a ClientHello over each

      flow (host/port quartet).


We would limit ourselves with the existing, restrictive SDP O/A rule. And w= ithout any justification for such a constraint.

Any comments?

Regards,
Albrecht



Von: Christer Holmberg [christer.holmberg= @ericsson.com]
Gesendet: Montag, 7. Oktober 2013 13:11
An: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hi Albre= cht,

 

At this = point, the community is making a decision about whether to start working on= this.

 

Once tha= t is done, we will start looking into, and discuss, individual technical is= sues etc, and your input will be highly appreciated.

 

Regards,=

 

Christer=

 

L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om]
L=E4hetetty: 7. lokakuuta 2013 13:56
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 

Hello Ch= rister,

I may no= t commit to submit a problem statement in the next couple of weeks, just du= e to time reasons.

At least= a note (or editor=92s note) should be added to draft mmusic-udptl-dtls in = order to indicate the issue and that a solution proposal is still pending.

 

Thanks,<= /span>

Albrecht=

 

 

 

Hi Albrecht,

 

I don't think putting a note so= mewhere in the fax draft is going to solve anything.

 

As you indicate, the issue exis= ts in multiple documents, so it's a generic issues.

 

So, my suggestion is that you p= ut together a short draft which describes the problem, and how you want to = change it, and then we can have a more generic discussion about it. The WG can then decide whether we shall fix something, and if so= , in which specs.

 

Regards,

 

Christer

 

 

From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com]
Sent: Tuesday, 24 September 2013 4:22 PM
To: Christer Holmberg
Cc: mmusic@ietf= .org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hello Chris= ter,

the "copy & paste" action (across at least three "RFCs&q= uot;) seems to be the root cause of the issue :-(

SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific.
We got here (wrt DTLS) three (different!) applications:
1) Key exchange (RFC 5763)
2) Conference control (rfc4582bis)
3) Document transmission (udptl-dtls)

All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs&= quot; (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 := -(

There might be two options to correct that copy & paste issue in "= udptl-dtls" in my opinion:
a) expand the SDP O/A rules for more flexibility
or
b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763)

What do you think?
Best regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say:

"The endpoint that is the offerer MUST use the setup attribute value o= f setup:actpass"

...which we also copied into the udptl-dtls draft.

Now, if you want to change that, and allow the Offerer to "force"= the direction, I think you should start a separate thread about that. Beca= use, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hello Christer,

the decision about "DTLS session establishment direction" is ALWA= YS up to the SDP ANSWERER (according present 3.1).

In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active"= ; and "setup:passive" (besides codepoint "setup:actpass"= ;) in my understanding.

I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at:
a) T - T
b) T -GW

The existing udptl-dtls & RFC 5763 text seems to focus on model (a) onl= y: SDP O/A between two peering, terminal located SIP UAs (there is NOT any = SIP B2BUA).
But I could imagine that the SIP/SDP profiles for "T" and "G= W" are not necessarily the same in case of model (b): "T" as= SDP Offerer may not allowed to decide the DTLS session establishment direc= tion, but "GW" as SDP offerer may need to enforce the DTLS sessio= n establishment direction (either way).

Regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:a= ctive value. Whichever party is active MUST initiate a DTLS handshake by se= nding a ClientHello over each flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination.

Regards,

Christer





-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?<= br> The ietf draft should offer the flexibility in decoupling both establishmen= t directions.

E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP.

--_000_786615F3A85DF44AA2A76164A71FE1AC107E9DFR711WXCHMBA03zeu_-- From albrecht.schwarz@alcatel-lucent.com Wed Nov 13 17:31:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467621E80BF for ; Wed, 13 Nov 2013 17:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37qbYUEhBhur for ; Wed, 13 Nov 2013 17:31:23 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5B121E8098 for ; Wed, 13 Nov 2013 17:31:23 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAE1VEqH013685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 19:31:15 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAE1VDCI002354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 02:31:13 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 14 Nov 2013 02:31:13 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg Thread-Topic: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: Ac60g62jSxVm2TCNSGW1wolV+AvE6AAhc/7wAMub3fD///RlAP/+GRRQgAO+MAD/66WaMIAomS8AgDsvrfj///T0AAACay/4 Date: Thu, 14 Nov 2013 01:31:13 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC107EFE@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C518E13@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C518E13@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC107EFEFR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mmusic@ietf.org" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:31:30 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC107EFEFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Right. ________________________________ Von: Christer Holmberg [christer.holmberg@ericsson.com] Gesendet: Donnerstag, 14. November 2013 02:21 An: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, If I understand your proposal correctly, the change would be to relax the r= ule for assigning the SDP setup attribute value in the SDP Offer. Instead o= f mandating actpass, we would also allow active and passive. Right? Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 14. marraskuuta 2013 3:11 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Aihe: AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, guess it's time to come back on this topic since the WG adopted the draft. In brief ("don't want to repeat again the thread"): a) problem statement: existing SDP O/A rules define a tighly coupled mode b= etween the establishment direction of the SIP session and the establishment= direction of the DTLS session, but there's not any reasoning for such tigh= tly coupled behaviour. b) change proposal: Revise in clause 3.1 following list item o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer MUST assign the SDP setup attribute with setup:actpass value, and MUST be prepared to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). by o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer MUST assign the SDP setup attribute with a setup:actpass, set= up:active or setup:passive value, and, in case of setup:actpass or setup:passive, MUST be prepar= ed to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value, in case of setup:actpass or se= tup:passive. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet). We would limit ourselves with the existing, restrictive SDP O/A rule. And w= ithout any justification for such a constraint. Any comments? Regards, Albrecht ________________________________ Von: Christer Holmberg [christer.holmberg@ericsson.com] Gesendet: Montag, 7. Oktober 2013 13:11 An: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, At this point, the community is making a decision about whether to start wo= rking on this. Once that is done, we will start looking into, and discuss, individual tech= nical issues etc, and your input will be highly appreciated. Regards, Christer L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alca= tel-lucent.com] L=E4hetetty: 7. lokakuuta 2013 13:56 Vastaanottaja: Christer Holmberg Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, I may not commit to submit a problem statement in the next couple of weeks,= just due to time reasons. At least a note (or editor=92s note) should be added to draft mmusic-udptl-= dtls in order to indicate the issue and that a solution proposal is still p= ending. Thanks, Albrecht From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 24. September 2013 16:01 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't think putting a note somewhere in the fax draft is going to solve a= nything. As you indicate, the issue exists in multiple documents, so it's a generic = issues. So, my suggestion is that you put together a short draft which describes th= e problem, and how you want to change it, and then we can have a more gener= ic discussion about it. The WG can then decide whether we shall fix somethi= ng, and if so, in which specs. Regards, Christer ________________________________ From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] Sent: Tuesday, 24 September 2013 4:22 PM To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the "copy & paste" action (across at least three "RFCs") seems to be the ro= ot cause of the issue :-( SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific. We got here (wrt DTLS) three (different!) applications: 1) Key exchange (RFC 5763) 2) Conference control (rfc4582bis) 3) Document transmission (udptl-dtls) All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology. Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility. The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules. What we got so far: SDP O/A rules in three application specific "RFCs" (RFC= 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( There might be two options to correct that copy & paste issue in "udptl-dtl= s" in my opinion: a) expand the SDP O/A rules for more flexibility or b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763) What do you think? Best regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Montag, 23. September 2013 11:54 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say: "The endpoint that is the offerer MUST use the setup attribute value of set= up:actpass" ...which we also copied into the udptl-dtls draft. Now, if you want to change that, and allow the Offerer to "force" the direc= tion, I think you should start a separate thread about that. Because, it is= not specific to fax, in my opinion. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 23. syyskuuta 2013 12:31 To: Christer Holmberg Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hello Christer, the decision about "DTLS session establishment direction" is ALWAYS up to t= he SDP ANSWERER (according present 3.1). In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active" and "set= up:passive" (besides codepoint "setup:actpass") in my understanding. I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at: a) T - T b) T -GW The existing udptl-dtls & RFC 5763 text seems to focus on model (a) only: S= DP O/A between two peering, terminal located SIP UAs (there is NOT any SIP = B2BUA). But I could imagine that the SIP/SDP profiles for "T" and "GW" are not nece= ssarily the same in case of model (b): "T" as SDP Offerer may not allowed t= o decide the DTLS session establishment direction, but "GW" as SDP offerer = may need to enforce the DTLS session establishment direction (either way). Regards, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 19. September 2013 10:02 To: Schwarz, Albrecht (Albrecht) Cc: mmusic@ietf.org Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session Hi Albrecht, The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server. Section 3.1 states: .... The offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the = SDP setup attribute with the setup:active value. Whichever party is active = MUST initiate a DTLS handshake by sending a ClientHello over each flow (hos= t/port quartet). The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC. BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com] Sent: 18. syyskuuta 2013 18:28 To: Christer Holmberg Cc: mmusic@ietf.org Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of a) T - T b) T -GW c) GW-GW I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints. Christer, I thought that the two directions of 1) SIP session establishment and 2) DTLS session establishment should be NOT tightly coupled (as currently supposed to be in clause 3.1)? The ietf draft should offer the flexibility in decoupling both establishmen= t directions. E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ... In my opinion: the IETF should allow the flexibility, other SDOs could still profile/limit this capability. Best regards, Albrecht PS We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP. --_000_786615F3A85DF44AA2A76164A71FE1AC107EFEFR711WXCHMBA03zeu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Right.

Von: Christer Holmberg [christer.holmberg= @ericsson.com]
Gesendet: Donnerstag, 14. November 2013 02:21
An: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hi Albre= cht,

 

If I und= erstand your proposal correctly, the change would be to relax the rule for = assigning the SDP setup attribute value in the SDP Offer. Instead of mandating actpass, we would also allow active and passive.

 

Right?

 

Regards,=

 

Christer=

 

L=E4hett=E4j=E4: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.c= om]
L=E4hetetty: 14. marraskuuta 2013 3:11
Vastaanottaja: Christer Holmberg
Kopio: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Aihe: AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 

Hello Christer,
guess it's time to come back on this topic since the WG adopted the draft.<= br>
In brief ("don't want to repeat again the thread"):
a) problem statement: existing SDP O/A rules define a tighly coupled mode b= etween the establishment direction of the SIP session and the establishment= direction of the DTLS session, but there's not any reasoning for such tigh= tly coupled behaviour.

b) change proposal:
Revise in clause 3.1 following list item

   o  The endpoint MUST use the SDP setup at= tribute [RFC4145].  The

      offerer MUST assign the SDP = setup attribute with setup:actpass

      value, and MUST be prepared = to receive a DTLS client_hello message

      before it receives the SDP a= nswer.  The answerer MUST assign the

      SDP setup attribute with eit= her setup:active value or

      setup:passive value.  T= he answerer SHOULD assign the SDP setup<= /span>

      attribute with the setup:act= ive value.  Whichever party is active

      MUST initiate a DTLS handsha= ke by sending a ClientHello over each

      flow (host/port quartet).


by

   o  The endpo= int MUST use the SDP setup attribute [RFC4145].  The

     = offerer MUST assign the SDP setup attribute with a setup:actpass, setup:ac= tive or setup:passive

     = value, and, in case of setup:actpass or setup:passive, MUST be prepared to= receive a DTLS client_hello message

     = before it receives the SDP answer.  The answerer MUST assign the

     = SDP setup attribute with either setup:active value or

     = setup:passive value.  The answerer SHOULD assign the SDP setup=

     = attribute with the setup:active value, in case of setup:actpass or setup:p= assive.  Whichever party is active<= /span>

     = MUST initiate a DTLS handshake by sending a ClientHello over each

     = flow (host/port quartet).


We would limit ourselves with the existing, restrictive SDP O/A rule. And w= ithout any justification for such a constraint.

Any comments?

Regards,
Albrecht

Hi Albre= cht,

 

At this = point, the community is making a decision about whether to start working on= this.

 

Once tha= t is done, we will start looking into, and discuss, individual technical is= sues etc, and your input will be highly appreciated.

 

Regards,=

 

Christer=

 

L=E4hett=E4j=E4:= Schwarz, Albrecht (Albrecht) [mailto:albrecht.= schwarz@alcatel-lucent.com]
L=E4hetetty: 7. lokakuuta 2013 13:56
Vastaanottaja: Christer Holmberg
Kopio: mmusic@i= etf.org; LANDAIS, BRUNO (BRUNO)
Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS ses= sion

 

Hello Ch= rister,

I may no= t commit to submit a problem statement in the next couple of weeks, just du= e to time reasons.

At least= a note (or editor=92s note) should be added to draft mmusic-udptl-dtls in = order to indicate the issue and that a solution proposal is still pending.

 

Thanks,<= /span>

Albrecht=

 

 

From: Christer Holmberg [mailto:christ= er.holmberg@ericsson.com]
Sent: Dienstag, 24. September 2013 16:01
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf= .org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

 

Hi Albrecht,

 

I don't think putting a note so= mewhere in the fax draft is going to solve anything.

 

As you indicate, the issue exis= ts in multiple documents, so it's a generic issues.

 

So, my suggestion is that you p= ut together a short draft which describes the problem, and how you want to = change it, and then we can have a more generic discussion about it. The WG can then decide whether we shall fix something, and if so= , in which specs.

 

Regards,

 

Christer

 

 

From: Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com]
Sent: Tuesday, 24 September 2013 4:22 PM
To: Christer Holmberg
Cc: mmusic@ietf= .org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS = session

Hello Chris= ter,

the "copy & paste" action (across at least three "RFCs&q= uot;) seems to be the root cause of the issue :-(

SIP session establishment and L4 security session (DTLS, TLS) establishment= directions should be principally decoupled because application specific.
We got here (wrt DTLS) three (different!) applications:
1) Key exchange (RFC 5763)
2) Conference control (rfc4582bis)
3) Document transmission (udptl-dtls)

All three applications are different in terms of number/type of supported n= etwork models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS ses= sion establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the r= equired SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs&= quot; (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 := -(

There might be two options to correct that copy & paste issue in "= udptl-dtls" in my opinion:
a) expand the SDP O/A rules for more flexibility
or
b) add a WARNING / NOTE about the inherent limitations (due to the assumpti= on of a network and communication environment according RFC 5763)

What do you think?
Best regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

I don't know what model people were focusing on when writing RFC 5763, but = the RFC does say:

"The endpoint that is the offerer MUST use the setup attribute value o= f setup:actpass"

...which we also copied into the udptl-dtls draft.

Now, if you want to change that, and allow the Offerer to "force"= the direction, I think you should start a separate thread about that. Beca= use, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: mmusic@ietf.org; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hello Christer,

the decision about "DTLS session establishment direction" is ALWA= YS up to the SDP ANSWERER (according present 3.1).

In order to decouple SIP session and DTLS session establishment directions,= then the SDP OFFERER should also to be able to use "setup:active"= ; and "setup:passive" (besides codepoint "setup:actpass"= ;) in my understanding.

I'm not sure whether the reference to RFC 5763 helps because I could imagin= e that the subject comes down to the indicated network scenarios, lets look= again at:
a) T - T
b) T -GW

The existing udptl-dtls & RFC 5763 text seems to focus on model (a) onl= y: SDP O/A between two peering, terminal located SIP UAs (there is NOT any = SIP B2BUA).
But I could imagine that the SIP/SDP profiles for "T" and "G= W" are not necessarily the same in case of model (b): "T" as= SDP Offerer may not allowed to decide the DTLS session establishment direc= tion, but "GW" as SDP offerer may need to enforce the DTLS sessio= n establishment direction (either way).

Regards,
Albrecht


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: mmusic@ietf.org
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session=

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establi= shment are NOT tightly coupled. The draft enables the Answerer to select wh= ether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass value, and M= UST be prepared to receive a DTLS client_hello message before it receives t= he SDP answer. The answerer MUST assign the SDP setup attribute with either= setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:a= ctive value. Whichever party is active MUST initiate a DTLS handshake by se= nding a ClientHello over each flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we = base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP= procedures for DTLS server determination.

Regards,

Christer





-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.co= m]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a gat= eway, leading to three possible scenarios of
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network= -side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?<= br> The ietf draft should offer the flexibility in decoupling both establishmen= t directions.

E.g., there might be the demand to limit DTLS session establishment in T-to= -GW direction (and apply rather the reverse direction) due ClientHello asso= ciated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects c= ould influence TLS session establishment direction. However, I guess that N= AT-T is minor for DTLS/UDP.

--_000_786615F3A85DF44AA2A76164A71FE1AC107EFEFR711WXCHMBA03zeu_-- From pkyzivat@alum.mit.edu Wed Nov 13 18:08:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB98021E80AC for ; Wed, 13 Nov 2013 18:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrUl1fSbendn for ; Wed, 13 Nov 2013 18:08:19 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id DFD8A21E8090 for ; Wed, 13 Nov 2013 18:08:18 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id pCJ61m0011YDfWL56E8Haj; Thu, 14 Nov 2013 02:08:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id pE8G1m00W3ZTu2S3gE8GRL; Thu, 14 Nov 2013 02:08:17 +0000 Message-ID: <52843090.4050509@alum.mit.edu> Date: Wed, 13 Nov 2013 18:08:16 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C518E13@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107EFE@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC107EFE@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384394897; bh=xkAh16efpxbBAD5pFIR8zZ4wesFC5ErcH6fNoigDWaA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nNlP+iKQD0zmdG+Iiqvrwavf7OFC7w7PUTuGFytgTNr9indPWAjHyr1q6XaMgd+Tr ObjyNAMSZcyjlpgAFX7nQuwZ7T3wgHJhz9OljU45SlHH1dOrD3gupl97usGFn5duBn /mkhrx1hX3y5fBFthzNj0Mfr+rGu7qwrVUEwCNFPbj1wIMPOmldbr8/ncJ/1r2CtOM UiYQB0fLTTbsT8wPEftH8vjb14oMJaj3L9jGx5Z7Q6UjcqlVmflJc3bS7FiCk8muMd /dNwcgT8VhLPi1TYl7vR9kiJw+CbcKPhnnvBa/L7EoZ0c4xnadY3r6Ygc7+1GOooYX 5+MlTbijUN6yg== Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 02:08:23 -0000 I believe that the a=setup attribute was first defined by rfc 4145, for TCP. There it governs who listens for an incoming connection. And the main concern was that NATs/FWs might prevent one end or the other from accepting incoming connections. Even so, it didn't have any normative behavior about what should be in the offer. As this same attribute is used in different contexts, the implications of using it may vary. In particular, if it is intended that either end should be able to take either the active or passive role, then the considerations for use may vary. ISTM that actpas SHOULD be used in the offer, except in cases where the offerer has a particular preference for active or passive, and would prefer to have the connection fail than use the other mode. Thanks, Paul On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote: > Right. > > ------------------------------------------------------------------------ > *Von:* Christer Holmberg [christer.holmberg@ericsson.com] > *Gesendet:* Donnerstag, 14. November 2013 02:21 > *An:* Schwarz, Albrecht (Albrecht) > *Cc:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) > *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hi Albrecht, > > If I understand your proposal correctly, the change would be to relax > the rule for assigning the SDP setup attribute value in the SDP Offer. > Instead of mandating actpass, we would also allow active and passive. > > Right? > > Regards, > > Christer > > *Lähettäjä:*Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > *Lähetetty:* 14. marraskuuta 2013 3:11 > *Vastaanottaja:* Christer Holmberg > *Kopio:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) > *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > Hello Christer, > guess it's time to come back on this topic since the WG adopted the draft. > > In brief ("don't want to repeat again the thread"): > a) problem statement: existing SDP O/A rules define a tighly coupled > mode between the establishment direction of the SIP session and the > establishment direction of the DTLS session, but there's not any > reasoning for such tightly coupled behaviour. > > b) change proposal: > Revise in clause 3.1 following list item > > o The endpoint MUST use the SDP setup attribute [RFC4145]. The > > offerer MUST assign the SDP setup attribute with setup:actpass > > value, and MUST be prepared to receive a DTLS client_hello message > > before it receives the SDP answer. The answerer MUST assign the > > SDP setup attribute with either setup:active value or > > setup:passive value. The answerer SHOULD assign the SDP setup > > attribute with the setup:active value. Whichever party is active > > MUST initiate a DTLS handshake by sending a ClientHello over each > > flow (host/port quartet). > > > by > > o The endpoint MUST use the SDP setup attribute [RFC4145]. The > > offerer MUST assign the SDP setup attribute with a setup:actpass, > setup:active or setup:passive > > value, and, in case of setup:actpass or setup:passive, MUST be > prepared to receive a DTLS client_hello message > > before it receives the SDP answer. The answerer MUST assign the > > SDP setup attribute with either setup:active value or > > setup:passive value. The answerer SHOULD assign the SDP setup > > attribute with the setup:active value, in case of setup:actpass > or setup:passive. Whichever party is active > > MUST initiate a DTLS handshake by sending a ClientHello over each > > flow (host/port quartet). > > > We would limit ourselves with the existing, restrictive SDP O/A rule. > And without any justification for such a constraint. > > Any comments? > > Regards, > Albrecht > > > ------------------------------------------------------------------------ > > *Von:*Christer Holmberg [christer.holmberg@ericsson.com] > *Gesendet:* Montag, 7. Oktober 2013 13:11 > *An:* Schwarz, Albrecht (Albrecht) > *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hi Albrecht, > > At this point, the community is making a decision about whether to start > working on this. > > Once that is done, we will start looking into, and discuss, individual > technical issues etc, and your input will be highly appreciated. > > Regards, > > Christer > > *Lähettäjä:*Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > *Lähetetty:* 7. lokakuuta 2013 13:56 > *Vastaanottaja:* Christer Holmberg > *Kopio:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > Hello Christer, > > I may not commit to submit a problem statement in the next couple of > weeks, just due to time reasons. > > At least a note (or editor’s note) should be added to draft > mmusic-udptl-dtls in order to indicate the issue and that a solution > proposal is still pending. > > Thanks, > > Albrecht > > *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent:* Dienstag, 24. September 2013 16:01 > *To:* Schwarz, Albrecht (Albrecht) > *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hi Albrecht, > > I don't think putting a note somewhere in the fax draft is going to > solve anything. > > As you indicate, the issue exists in multiple documents, so it's a > generic issues. > > So, my suggestion is that you put together a short draft which describes > the problem, and how you want to change it, and then we can have a more > generic discussion about it. The WG can then decide whether we shall fix > something, and if so, in which specs. > > Regards, > > Christer > > ------------------------------------------------------------------------ > > *From:*Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] > *Sent:* Tuesday, 24 September 2013 4:22 PM > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hello Christer, > > the "copy & paste" action (across at least three "RFCs") seems to be the > root cause of the issue :-( > > SIP session establishment and L4 security session (DTLS, TLS) > establishment directions should be principally decoupled because > application specific. > > We got here (wrt DTLS) three (different!) applications: > 1) Key exchange (RFC 5763) > 2) Conference control (rfc4582bis) > 3) Document transmission (udptl-dtls) > > All three applications are different in terms of number/type of > supported network models, security models or/and communication topology. > > Consequently, the basic, application independent SDP O/A rules for DTLS > session establishment would need to support that flexibility. > The application specific SIP/SDP profile could then still narrow down > the required SDP O/A rules. > > What we got so far: SDP O/A rules in three application specific "RFCs" > (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( > > There might be two options to correct that copy & paste issue in > "udptl-dtls" in my opinion: > a) expand the SDP O/A rules for more flexibility > or > b) add a WARNING / NOTE about the inherent limitations (due to the > assumption of a network and communication environment according RFC 5763) > > What do you think? > Best regards, > Albrecht > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Montag, 23. September 2013 11:54 > To: Schwarz, Albrecht (Albrecht) > Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > Hi Albrecht, > > I don't know what model people were focusing on when writing RFC 5763, > but the RFC does say: > > "The endpoint that is the offerer MUST use the setup attribute value of > setup:actpass" > > ...which we also copied into the udptl-dtls draft. > > Now, if you want to change that, and allow the Offerer to "force" the > direction, I think you should start a separate thread about that. > Because, it is not specific to fax, in my opinion. > > Regards, > > Christer > > -----Original Message----- > From: Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > Sent: 23. syyskuuta 2013 12:31 > To: Christer Holmberg > Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > Hello Christer, > > the decision about "DTLS session establishment direction" is ALWAYS up > to the SDP ANSWERER (according present 3.1). > > In order to decouple SIP session and DTLS session establishment > directions, then the SDP OFFERER should also to be able to use > "setup:active" and "setup:passive" (besides codepoint "setup:actpass") > in my understanding. > > I'm not sure whether the reference to RFC 5763 helps because I could > imagine that the subject comes down to the indicated network scenarios, > lets look again at: > a) T - T > b) T -GW > > The existing udptl-dtls & RFC 5763 text seems to focus on model (a) > only: SDP O/A between two peering, terminal located SIP UAs (there is > NOT any SIP B2BUA). > But I could imagine that the SIP/SDP profiles for "T" and "GW" are not > necessarily the same in case of model (b): "T" as SDP Offerer may not > allowed to decide the DTLS session establishment direction, but "GW" as > SDP offerer may need to enforce the DTLS session establishment direction > (either way). > > Regards, > Albrecht > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Donnerstag, 19. September 2013 10:02 > To: Schwarz, Albrecht (Albrecht) > Cc: mmusic@ietf.org > Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > Hi Albrecht, > > The direction of the SIP session establishment and the DTLS session > establishment are NOT tightly coupled. The draft enables the Answerer to > select whether it wants to act as DTLS client or DTLS server. > > Section 3.1 states: > > .... The > offerer MUST assign the SDP setup attribute with setup:actpass value, > and MUST be prepared to receive a DTLS client_hello message before it > receives the SDP answer. The answerer MUST assign the SDP setup > attribute with either setup:active value or setup:passive value. The > answerer SHOULD assign the SDP setup attribute with the setup:active > value. Whichever party is active MUST initiate a DTLS handshake by > sending a ClientHello over each flow (host/port quartet). > > The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, > we base the procedure on that RFC. > > BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the > DTLS-SRTP procedures for DTLS server determination. > > Regards, > > Christer > > > > > > -----Original Message----- > From: Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > Sent: 18. syyskuuta 2013 18:28 > To: Christer Holmberg > Cc: mmusic@ietf.org > Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > The T.38 endpoint could be located in a terminal (= T.38 IAF) or in a > gateway, leading to three possible scenarios of > a) T - T > b) T -GW > c) GW-GW > > I'd like to scope on scenario (b) due to its asymmetry of user- and > network-side located T.38 endpoints. > > Christer, > I thought that the two directions of > 1) SIP session establishment and > 2) DTLS session establishment > should be NOT tightly coupled (as currently supposed to be in clause 3.1)? > The ietf draft should offer the flexibility in decoupling both > establishment directions. > > E.g., there might be the demand to limit DTLS session establishment in > T-to-GW direction (and apply rather the reverse direction) due > ClientHello associated security threats, resource requests in terms of > memory, ... > > In my opinion: > the IETF should allow the flexibility, > other SDOs could still profile/limit this capability. > > Best regards, > Albrecht > > PS > We had a similar discussion with TLS, there NAT traversal (NAT-T) > aspects could influence TLS session establishment direction. However, I > guess that NAT-T is minor for DTLS/UDP. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Wed Nov 13 21:52:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E3521E81D2 for ; Wed, 13 Nov 2013 21:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.667 X-Spam-Level: X-Spam-Status: No, score=-4.667 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuVg9fZjUqu1 for ; Wed, 13 Nov 2013 21:52:26 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 488F021E81BD for ; Wed, 13 Nov 2013 21:52:24 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-72-52846516d871 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9B.B0.15980.61564825; Thu, 14 Nov 2013 06:52:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 06:52:22 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHO4NZi9flj5ss1UEu1a/Ao76gxKJoj7Uow///yroCAAApaAIAAT18p Date: Thu, 14 Nov 2013 05:52:21 +0000 Message-ID: <3l87dt3gkmh42oon4n8n22he.1384408337440@email.android.com> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C518E13@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107EFE@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <52843090.4050509@alum.mit.edu> In-Reply-To: <52843090.4050509@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra5YakuQwbYrihZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx4t9mtoJ/GRXzPq9nbGDcG9LFyMkhIWAi sXb9dkYIW0ziwr31bF2MXBxCAocYJe4vOcEO4SxhlHiwuRPI4eBgE7CQ6P6nDdIgIuAr8ezx bTYQW1ggTOLT+UlsEPFwiY5/d6BsN4nDvWeZQGwWAVWJzcv7mUFsXqD4y+efoZY9Y5NYvXEK M8h8TgEdieYvaSA1jEAHfT+1BqyXWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK0SNgcT7c/OZ IWxtiWULX0PtEpQ4OfMJywRGkVlIRs1C0jILScssJC0LGFlWMbLnJmbmpJebb2IEhvzBLb8N djBuui92iFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwp5hmZO3Uv2b+e M/ex/Wqx/68UPe/brlVhc1Y8G6VlKXDhSXJv9eOdn+o3TDPZ7y2/dsadPsm3Xo2LN/xIm9wh 96D4f5yy8VXrb/zmCfyOXHUvznwoeFCoyfLbYVfz7oQKLvvfpmZXptyXPm11nbVAmyVzi9O5 lYl/9afNuDPRYY7KqZji6RFKLMUZiYZazEXFiQD1fC6ZRwIAAA== Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 05:52:31 -0000 Hi, I guess 'SHOULD use actpass' would work. Regards, Christer Sent from my Sony Ericsson Xperia arc S Paul Kyzivat wrote: I believe that the a=3Dsetup attribute was first defined by rfc 4145, for T= CP. There it governs who listens for an incoming connection. And the main concern was that NATs/FWs might prevent one end or the other from accepting incoming connections. Even so, it didn't have any normative behavior about what should be in the offer. As this same attribute is used in different contexts, the implications of using it may vary. In particular, if it is intended that either end should be able to take either the active or passive role, then the considerations for use may vary. ISTM that actpas SHOULD be used in the offer, except in cases where the offerer has a particular preference for active or passive, and would prefer to have the connection fail than use the other mode. Thanks, Paul On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote: > Right. > > ------------------------------------------------------------------------ > *Von:* Christer Holmberg [christer.holmberg@ericsson.com] > *Gesendet:* Donnerstag, 14. November 2013 02:21 > *An:* Schwarz, Albrecht (Albrecht) > *Cc:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) > *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hi Albrecht, > > If I understand your proposal correctly, the change would be to relax > the rule for assigning the SDP setup attribute value in the SDP Offer. > Instead of mandating actpass, we would also allow active and passive. > > Right? > > Regards, > > Christer > > *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > *L=E4hetetty:* 14. marraskuuta 2013 3:11 > *Vastaanottaja:* Christer Holmberg > *Kopio:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) > *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessio= n > > Hello Christer, > guess it's time to come back on this topic since the WG adopted the draft= . > > In brief ("don't want to repeat again the thread"): > a) problem statement: existing SDP O/A rules define a tighly coupled > mode between the establishment direction of the SIP session and the > establishment direction of the DTLS session, but there's not any > reasoning for such tightly coupled behaviour. > > b) change proposal: > Revise in clause 3.1 following list item > > o The endpoint MUST use the SDP setup attribute [RFC4145]. The > > offerer MUST assign the SDP setup attribute with setup:actpass > > value, and MUST be prepared to receive a DTLS client_hello message > > before it receives the SDP answer. The answerer MUST assign the > > SDP setup attribute with either setup:active value or > > setup:passive value. The answerer SHOULD assign the SDP setup > > attribute with the setup:active value. Whichever party is active > > MUST initiate a DTLS handshake by sending a ClientHello over each > > flow (host/port quartet). > > > by > > o The endpoint MUST use the SDP setup attribute [RFC4145]. The > > offerer MUST assign the SDP setup attribute with a setup:actpass, > setup:active or setup:passive > > value, and, in case of setup:actpass or setup:passive, MUST be > prepared to receive a DTLS client_hello message > > before it receives the SDP answer. The answerer MUST assign the > > SDP setup attribute with either setup:active value or > > setup:passive value. The answerer SHOULD assign the SDP setup > > attribute with the setup:active value, in case of setup:actpass > or setup:passive. Whichever party is active > > MUST initiate a DTLS handshake by sending a ClientHello over each > > flow (host/port quartet). > > > We would limit ourselves with the existing, restrictive SDP O/A rule. > And without any justification for such a constraint. > > Any comments? > > Regards, > Albrecht > > > ------------------------------------------------------------------------ > > *Von:*Christer Holmberg [christer.holmberg@ericsson.com] > *Gesendet:* Montag, 7. Oktober 2013 13:11 > *An:* Schwarz, Albrecht (Albrecht) > *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hi Albrecht, > > At this point, the community is making a decision about whether to start > working on this. > > Once that is done, we will start looking into, and discuss, individual > technical issues etc, and your input will be highly appreciated. > > Regards, > > Christer > > *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > *L=E4hetetty:* 7. lokakuuta 2013 13:56 > *Vastaanottaja:* Christer Holmberg > *Kopio:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessio= n > > Hello Christer, > > I may not commit to submit a problem statement in the next couple of > weeks, just due to time reasons. > > At least a note (or editor=92s note) should be added to draft > mmusic-udptl-dtls in order to indicate the issue and that a solution > proposal is still pending. > > Thanks, > > Albrecht > > *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent:* Dienstag, 24. September 2013 16:01 > *To:* Schwarz, Albrecht (Albrecht) > *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hi Albrecht, > > I don't think putting a note somewhere in the fax draft is going to > solve anything. > > As you indicate, the issue exists in multiple documents, so it's a > generic issues. > > So, my suggestion is that you put together a short draft which describes > the problem, and how you want to change it, and then we can have a more > generic discussion about it. The WG can then decide whether we shall fix > something, and if so, in which specs. > > Regards, > > Christer > > ------------------------------------------------------------------------ > > *From:*Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com] > *Sent:* Tuesday, 24 September 2013 4:22 PM > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS > session > > Hello Christer, > > the "copy & paste" action (across at least three "RFCs") seems to be the > root cause of the issue :-( > > SIP session establishment and L4 security session (DTLS, TLS) > establishment directions should be principally decoupled because > application specific. > > We got here (wrt DTLS) three (different!) applications: > 1) Key exchange (RFC 5763) > 2) Conference control (rfc4582bis) > 3) Document transmission (udptl-dtls) > > All three applications are different in terms of number/type of > supported network models, security models or/and communication topology. > > Consequently, the basic, application independent SDP O/A rules for DTLS > session establishment would need to support that flexibility. > The application specific SIP/SDP profile could then still narrow down > the required SDP O/A rules. > > What we got so far: SDP O/A rules in three application specific "RFCs" > (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( > > There might be two options to correct that copy & paste issue in > "udptl-dtls" in my opinion: > a) expand the SDP O/A rules for more flexibility > or > b) add a WARNING / NOTE about the inherent limitations (due to the > assumption of a network and communication environment according RFC 5763) > > What do you think? > Best regards, > Albrecht > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Montag, 23. September 2013 11:54 > To: Schwarz, Albrecht (Albrecht) > Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessi= on > > Hi Albrecht, > > I don't know what model people were focusing on when writing RFC 5763, > but the RFC does say: > > "The endpoint that is the offerer MUST use the setup attribute value of > setup:actpass" > > ...which we also copied into the udptl-dtls draft. > > Now, if you want to change that, and allow the Offerer to "force" the > direction, I think you should start a separate thread about that. > Because, it is not specific to fax, in my opinion. > > Regards, > > Christer > > -----Original Message----- > From: Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > Sent: 23. syyskuuta 2013 12:31 > To: Christer Holmberg > Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) > Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessi= on > > Hello Christer, > > the decision about "DTLS session establishment direction" is ALWAYS up > to the SDP ANSWERER (according present 3.1). > > In order to decouple SIP session and DTLS session establishment > directions, then the SDP OFFERER should also to be able to use > "setup:active" and "setup:passive" (besides codepoint "setup:actpass") > in my understanding. > > I'm not sure whether the reference to RFC 5763 helps because I could > imagine that the subject comes down to the indicated network scenarios, > lets look again at: > a) T - T > b) T -GW > > The existing udptl-dtls & RFC 5763 text seems to focus on model (a) > only: SDP O/A between two peering, terminal located SIP UAs (there is > NOT any SIP B2BUA). > But I could imagine that the SIP/SDP profiles for "T" and "GW" are not > necessarily the same in case of model (b): "T" as SDP Offerer may not > allowed to decide the DTLS session establishment direction, but "GW" as > SDP offerer may need to enforce the DTLS session establishment direction > (either way). > > Regards, > Albrecht > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Donnerstag, 19. September 2013 10:02 > To: Schwarz, Albrecht (Albrecht) > Cc: mmusic@ietf.org > Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessi= on > > Hi Albrecht, > > The direction of the SIP session establishment and the DTLS session > establishment are NOT tightly coupled. The draft enables the Answerer to > select whether it wants to act as DTLS client or DTLS server. > > Section 3.1 states: > > .... The > offerer MUST assign the SDP setup attribute with setup:actpass value, > and MUST be prepared to receive a DTLS client_hello message before it > receives the SDP answer. The answerer MUST assign the SDP setup > attribute with either setup:active value or setup:passive value. The > answerer SHOULD assign the SDP setup attribute with the setup:active > value. Whichever party is active MUST initiate a DTLS handshake by > sending a ClientHello over each flow (host/port quartet). > > The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, > we base the procedure on that RFC. > > BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the > DTLS-SRTP procedures for DTLS server determination. > > Regards, > > Christer > > > > > > -----Original Message----- > From: Schwarz, Albrecht (Albrecht) > [mailto:albrecht.schwarz@alcatel-lucent.com] > Sent: 18. syyskuuta 2013 18:28 > To: Christer Holmberg > Cc: mmusic@ietf.org > Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session > > The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a > gateway, leading to three possible scenarios of > a) T - T > b) T -GW > c) GW-GW > > I'd like to scope on scenario (b) due to its asymmetry of user- and > network-side located T.38 endpoints. > > Christer, > I thought that the two directions of > 1) SIP session establishment and > 2) DTLS session establishment > should be NOT tightly coupled (as currently supposed to be in clause 3.1)= ? > The ietf draft should offer the flexibility in decoupling both > establishment directions. > > E.g., there might be the demand to limit DTLS session establishment in > T-to-GW direction (and apply rather the reverse direction) due > ClientHello associated security threats, resource requests in terms of > memory, ... > > In my opinion: > the IETF should allow the flexibility, > other SDOs could still profile/limit this capability. > > Best regards, > Albrecht > > PS > We had a similar discussion with TLS, there NAT traversal (NAT-T) > aspects could influence TLS session establishment direction. However, I > guess that NAT-T is minor for DTLS/UDP. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@unify.com Thu Nov 14 04:45:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB4F11E8114 for ; Thu, 14 Nov 2013 04:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIgGcxKCl+8c for ; Thu, 14 Nov 2013 04:44:59 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A553D21E8085 for ; Thu, 14 Nov 2013 04:44:58 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id CDBE51EB851C; Thu, 14 Nov 2013 13:44:56 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 13:44:56 +0100 From: "Stach, Thomas" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? Thread-Index: AQHO4KSQhgHe5dqvwUaUS/lMIC1X1pokq51A Date: Thu, 14 Nov 2013 12:44:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> <5283CF83.2090902@alum.mit.edu> In-Reply-To: <5283CF83.2090902@alum.mit.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 12:45:03 -0000 Christer, is there any connection between the subject line and the content of this ma= il threat about putting the shared address into the offer? I'm a bit confus= ed. Separate from this I want to clarify if the 2nd offer/answer exchange as in= dicated in the subject line is just used in SIP environments in order to do= the usual intermediary "appeasement". Would the second offer/answer also be required for the WebRTC case where ju= st have two browser client being connect via the same WebRTC server and no = further intermediaries? Kind Regards Thomas Stach > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Mittwoch, 13. November 2013 20:14 > To: Christer Holmberg; mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 > Offer/Answers during session establishment? >=20 > On 11/13/13 10:42 AM, Christer Holmberg wrote: > > Hi Paul, > > > >> This works for me except for one thing: the word "session", which I > fear is sufficiently ambiguous to present trouble. > >> > >> I suggest using "multi-media session". (We can't use "SIP session" > or "SIP dialog" because this might be used without SIP.) > > > > I agree regarding not being able to use SIP terminology. > > > > I guess "multi-media session" is one option. What about "SDP > session"? >=20 > I thought about that. I'm not in love with multi-media session. >=20 > When I look at 4566 I find a definition of "session" as multi-media > session. I think "SDP session" gets the point across, though I have not > seen "SDP session" used anywhere else. >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > > > On 11/12/13 3:39 PM, Christer Holmberg wrote: > >> Hi, > >> > >> In Vancouver we decided that an Offerer MUST NOT assign a shared > address (with a non-zero port) to multiple m- lines until the Answerer, > within the session, has indicated support of BUNDLE. > >> > >> I suggest the following piece of text to implement the decision in > the BUNDLE spec: > >> > >> "The Offerer MUST NOT assign a shared address with a non-zero > port > >> value to multiple "m=3D" lines until it has, within the given > session, > >> received an SDP Answer indicating that the Answerer > supports the > >> BUNDLE mechanism." > >> > >> Note that there will be specific text regarding the usage of port > zero for 'bundle-only' m- lines. > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Thu Nov 14 04:53:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABBC21E8085 for ; Thu, 14 Nov 2013 04:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCyjKwLXcWhj for ; Thu, 14 Nov 2013 04:52:58 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6B11E80E2 for ; Thu, 14 Nov 2013 04:52:57 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-00-5284c7a59358 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A1.BF.15980.5A7C4825; Thu, 14 Nov 2013 13:52:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 13:52:53 +0100 From: Christer Holmberg To: "Stach, Thomas" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? Thread-Index: AQHO4TdT4OW+qVPI1U6skrTqpbrQ65okrm5p Date: Thu, 14 Nov 2013 12:52:53 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C518151@ESESSMB209.ericsson.se> <5283BEA3.4040805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5187CC@ESESSMB209.ericsson.se> <5283CF83.2090902@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvre6y4y1BBuv2cVlMXf6YxeLkzm3M DkweS5b8ZPLY3vOYJYApissmJTUnsyy1SN8ugSvjzE7fgreSFW8n9DI3MK4R6WLk5JAQMJHY desvE4QtJnHh3nq2LkYuDiGBQ4wSH9ZvZ4FwljBKHNozhbmLkYODTcBCovufNkiDiECwxMnm 0ywgtrBAnsS6k1MZQUpEBPIlDvZkQ5QYSfzc3w8WZhFQlTjZ4AoS5hVwk/j5cyEzxPQZTBK3 Fj1jB0lwCvhLLNt+E8xmBLrn+6k1YLcxC4hL3HoyH+pOAYkle84zQ9iiEi8f/2OFqNGRWLD7 ExuErS2xbOFrZohlghInZz5hmcAoMgvJqFlIWmYhaZmFpGUBI8sqRvbcxMyc9HLzTYzAcD+4 5bfBDsZN98UOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFf4WeooeyK lz6/pv5hO86960fmRcVtSpzbTr+dv2diCt+svp1GRTsiDU8v7bcRyIktSzrvkp3c+2zv6qho nwn3K9pveL/+ZvlEptT+bneyrmeAb+cWE+9znpMU1Q7yfJNYlnOxwpVJt3XOe92KdEflO/Gp hV4vPz5MtxTg1pjnt3HuYQ6JciWW4oxEQy3mouJEAD4piDVFAgAA Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 Offer/Answers during session establishment? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 12:53:03 -0000 Hi Thomas, >From a BUNDLE perspective, the 2nd Offer is always mandated. BUNDLE current= ly does not define different rules for specific environments. Regards, Christer Sent from my Sony Ericsson Xperia arc S "Stach, Thomas" wrote: Christer, is there any connection between the subject line and the content of this ma= il threat about putting the shared address into the offer? I'm a bit confus= ed. Separate from this I want to clarify if the 2nd offer/answer exchange as in= dicated in the subject line is just used in SIP environments in order to do= the usual intermediary "appeasement". Would the second offer/answer also be required for the WebRTC case where ju= st have two browser client being connect via the same WebRTC server and no = further intermediaries? Kind Regards Thomas Stach > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Mittwoch, 13. November 2013 20:14 > To: Christer Holmberg; mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q6: Do we always mandate 2 > Offer/Answers during session establishment? > > On 11/13/13 10:42 AM, Christer Holmberg wrote: > > Hi Paul, > > > >> This works for me except for one thing: the word "session", which I > fear is sufficiently ambiguous to present trouble. > >> > >> I suggest using "multi-media session". (We can't use "SIP session" > or "SIP dialog" because this might be used without SIP.) > > > > I agree regarding not being able to use SIP terminology. > > > > I guess "multi-media session" is one option. What about "SDP > session"? > > I thought about that. I'm not in love with multi-media session. > > When I look at 4566 I find a definition of "session" as multi-media > session. I think "SDP session" gets the point across, though I have not > seen "SDP session" used anywhere else. > > Thanks, > Paul > > > Regards, > > > > Christer > > > > > > On 11/12/13 3:39 PM, Christer Holmberg wrote: > >> Hi, > >> > >> In Vancouver we decided that an Offerer MUST NOT assign a shared > address (with a non-zero port) to multiple m- lines until the Answerer, > within the session, has indicated support of BUNDLE. > >> > >> I suggest the following piece of text to implement the decision in > the BUNDLE spec: > >> > >> "The Offerer MUST NOT assign a shared address with a non-zero > port > >> value to multiple "m=3D" lines until it has, within the giv= en > session, > >> received an SDP Answer indicating that the Answerer > supports the > >> BUNDLE mechanism." > >> > >> Note that there will be specific text regarding the usage of port > zero for 'bundle-only' m- lines. > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From wwwrun@rfc-editor.org Thu Nov 14 06:19:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8123221E80C8; Thu, 14 Nov 2013 06:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdf5HYdm9Ypq; Thu, 14 Nov 2013 06:19:12 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D6BFF21E80C2; Thu, 14 Nov 2013 06:19:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 48A6D75E015; Thu, 14 Nov 2013 06:09:16 -0800 (PST) To: liang@icann.org, miguel.a.garcia@ericsson.com, simo.veikkolainen@nokia.com, bob_gilman@comcast.net From: RFC Errata System Message-Id: <20131114140916.48A6D75E015@rfc-editor.org> Date: Thu, 14 Nov 2013 06:09:16 -0800 (PST) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org, gonzalo.camarillo@ericsson.com, iesg@ietf.org Subject: [MMUSIC] [Errata Held for Document Update] RFC7006 (3738) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 14:19:13 -0000 The following errata report has been held for document update for RFC7006, "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7006&eid=3738 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: pearl liang Date Reported: 2013-09-25 Held by: Gonzalo Camarillo (IESG) Section: 6.1 Original Text ------------- 6.1. New SDP Attributes IANA has registered new attributes in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following registration form: Attribute name: bcap Long form name: Bandwidth Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate session or media-level bandwidths Appropriate values: See RFC 7066, Section 3.1.1 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com Attribute name: ccap Long form name: Connection Data Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate media-level connection data Appropriate values: See RFC 7066, Section 3.1.2 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com Attribute name: icap Long form name: Title Capability Type of attribute: Both media and session level Subject to charset: Yes Purpose: Negotiate human-readable information describing the session or media Appropriate values: See RFC 7066, Section 3.1.3 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com Corrected Text -------------- 6.1. New SDP Attributes IANA has registered new attributes in the "att-field (both session and media level)" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following registration form: Attribute name: bcap Long form name: Bandwidth Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate session or media-level bandwidths Appropriate values: See RFC 7006, Section 3.1.1 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com Attribute name: ccap Long form name: Connection Data Capability Type of attribute: Both media and session level Subject to charset: No Purpose: Negotiate media-level connection data Appropriate values: See RFC 7006, Section 3.1.2 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com Attribute name: icap Long form name: Title Capability Type of attribute: Both media and session level Subject to charset: Yes Purpose: Negotiate human-readable information describing the session or media Appropriate values: See RFC 7006, Section 3.1.3 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com Notes ----- The Appropriate values for the three New SDP Attributes have cited an incorrect RFC. It should be RFC 7006, rather than RFC 7066. -------------------------------------- RFC7006 (draft-ietf-mmusic-sdp-miscellaneous-caps-07) -------------------------------------- Title : Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) Publication Date : September 2013 Author(s) : M. Garcia-Martin, S. Veikkolainen, R. Gilman Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From pkyzivat@alum.mit.edu Thu Nov 14 08:52:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7F21E80C7 for ; Thu, 14 Nov 2013 08:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXXjczSBxZOG for ; Thu, 14 Nov 2013 08:52:13 -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 41BE021E8056 for ; Thu, 14 Nov 2013 08:52:13 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta09.westchester.pa.mail.comcast.net with comcast id pR7m1m00A1GhbT859UsC3E; Thu, 14 Nov 2013 16:52:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id pUsC1m0033ZTu2S3TUsCwC; Thu, 14 Nov 2013 16:52:12 +0000 Message-ID: <5284FFBB.2030407@alum.mit.edu> Date: Thu, 14 Nov 2013 08:52:11 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384447932; bh=hX+unD2IlgVC5S+lOLTjENt0uAsPaX3cmt+tKXxzm6o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MOvnu+4NSISFni5aXs5M0OWXQCi4IN2z9YLiDh06XoFYUdCk0csBcpE1viiGafnJl nk+1Ry+1ti1Zgkgo2/PDU3ZPg1XPIE8Q4i9MZQLBc1M2S3uu7PkAOYm6wPCEi5Urvb LXpA1qxC8Yzjg0H/XnL4ObGD6uNrXt+V/Lrhbau8cqU2Bqz6VThQA0MAo32NoxTnz3 mlPSOPizbKicnLhzrT4P7WWZLuOm5ECfodDeQpB2fkXUY+npHt9aRkaIHc+kXtuqpR V+YnNFDNUweGKxuOyd2MgqNgfer61BtU6Mi+EnZcPoJk9yqJP2eu1jtMSg9B+wM1IY SuxaozJsK3nQg== Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 14 Nov 2013 16:52:18 -0000 I don't understand the point of this. I'm not aware of any general use of a nettype other than IN, or an addrtype other than IP4 or IP6, but I also don't see why the behavior of bundle is dependent upon this. Any other choices that still have a notion of port sufficient to allow SDP O/A rules to apply should also work with bundle. So I see no reason to incorporate such a scope limitation. Thanks, Paul On 11/12/13 3:08 PM, Christer Holmberg wrote: > Hi, > > Based on the comments from Christian, I suggest the following new text for BUNDLE: > > ----------------------------- > > 6.2.2. Connection Data (c=) > > The "c=" line nettype value [RFC4566] associated with each "m=" line > within a BUNDLE group MUST be 'IN'. > > The "c=" line addrtype value [RFC4566] associated with each "m=" line > within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST be > associated with each "m=" line within a BUNDLE group. > > NOTE: Extensions to this specification can specify usage of the > BUNDLE mechanism for other nettype and addrtype values than the ones > listed above. > > ----------------------------- > > Regards, > > Christer > > > > > -----Alkuperäinen viesti----- > Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Christian Groves > Lähetetty: 15. lokakuuta 2013 3:05 > Vastaanottaja: mmusic@ietf.org > Aihe: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05 > > Hello Christer, > > The SDP grouping mechanism can be applied to different nettype/addrtypes. The BUNDLE draft appears to define behaviour related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section 2 defines BUNDLE terminology based on IP. > > Is there an intention that the BUNDLE mechanism is only used for the above net and addrtypes? If so should it be mentioned somewhere in the applicability statement? > > Regards, Christian > > On 14/10/2013 10:37 PM, Christer Holmberg wrote: >> >> Hi, >> >> I've submitted a new version of the BUNDLE draft. >> >> I have implemented the modified text for the Offerer and Answerer >> procedures, as presented on the list in September. >> >> The procedures now also mention the usage of the SDP 'bundle-only' >> attribute. However, the attribute definition itself has yet not been >> added to the draft, as we still haven't solved the issue regarding >> usage of port zero. >> >> In addition, there are some reference corrections, and the FQDN values >> in the examples are now according to RFC 2606. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Thu Nov 14 09:09:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6038121E8109 for ; Thu, 14 Nov 2013 09:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQXhRScwmujA for ; Thu, 14 Nov 2013 09:08:39 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 8824B21E8115 for ; Thu, 14 Nov 2013 09:08:37 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id pQ2K1m0030cZkys57V8cNx; Thu, 14 Nov 2013 17:08:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id pV8c1m00k3ZTu2S3WV8cS1; Thu, 14 Nov 2013 17:08:36 +0000 Message-ID: <52850394.6080602@alum.mit.edu> Date: Thu, 14 Nov 2013 09:08:36 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C518B4A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C518B4A@ESESSMB209.ericsson.se> 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=1384448916; bh=txvkRBPj1CxOWm/st9/aVAsFNvaw84mJg2DCWWqdVRo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bVEcZDZ/LTXeEo+PAh+A9k6Lw91IiSm4xHPQZxo7YFSGh3XasFsOaioEMtlKfKmVh z0NUJ3/p6/kFCWwx5mPDBXMWbc9DXfXzJMTbjiJr6GP20VpghtPzVxJEX8CE1ZEil5 fvkIOROq/k9Z1pWnE0T2V92Ea6frrLj7ZwGVWWUB2tv0dwVQKxbYMuItkuL3EI5hTU AyPn9d4EalECDZA0eBd5D906Qm4yeR1MWiELB4qbctJ6muo1uzXEzyG3UCr9k1s0Up Xrmm2ss2RoSNwlna0gY9Z3LVc5hfhnuJHin6BWZGUvRObUrnaoLkQyyPpWLhwDCrN5 16D1fRT/G+S0g== Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 17:09:00 -0000 On 11/13/13 3:28 PM, Christer Holmberg wrote: > Hi, > > Based on the decision in Vancouver to define the usage of port zero in 'bundle-only' m- lines, I've updated the new text I proposed some time ago. > > One question that was raised in Vancouver is whether we will have to update RFC 3264, so I've added a new OPEN ISSUE (13) for that. ... > OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Answer > to a zero port value in an SDP Offer. As we now allow a non-zero > value in the SDP Answer, do we need to update 3264 procedures? Why is this a question. Section 8.2 of 3264 clearly states this, and we propose to do otherwise. So that means a revision is required. Thanks, Paul From christer.holmberg@ericsson.com Thu Nov 14 09:27:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20F321E8098 for ; Thu, 14 Nov 2013 09:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.57 X-Spam-Level: X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFNMJy4Py46o for ; Thu, 14 Nov 2013 09:26:56 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DD24E21E8056 for ; Thu, 14 Nov 2013 09:26:55 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-9b-528507de538e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 94.2E.15980.ED705825; Thu, 14 Nov 2013 18:26:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 18:26:53 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute Thread-Index: Ac7gCRpceAmIueuZSE+3AnYuzIwR9gBSquYAAAKqqPA= Date: Thu, 14 Nov 2013 17:26:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C51998A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C518B4A@ESESSMB209.ericsson.se> <52850394.6080602@alum.mit.edu> In-Reply-To: <52850394.6080602@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre499tYgg+lnpS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj0VSOgjPsFVtubWRtYHzK2sXIySEhYCLx cdcTZghbTOLCvfVsILaQwCFGia8f7bsYuYDsJYwSjXdfASU4ONgELCS6/2mD1IgI+Eo8e3wb rF5YwFViz5ZrTBBxN4nXmw8wQthWEldn/gGrYRFQlfi3exdYnBeod9usDnaIXfkSZzbPYgGx OQV0JG53zge7jRHonu+n1oDNZBYQl/hw8DrUnQISS/ach7JFJV4+/gf1i5LE2sPbWSDqdSQW 7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRPTcxMye93HwTIzAO Dm75bbCDcdN9sUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg7Mo7doD1 aqBVxjvJ3mm3V03cqW57+eDO4/eCX7X2+4jNCH5XeKbyyqqCz7n9q0w3yBmsMtjy5dKnhVem vtEVy/1x+vvP9Y+bEze4b0tq3yV+fP8slcYpcd7BLPZt/ysur1rvEX001t9BSPFxQujx1J2B 0+SU5UOi+xZ1H2es/Tg1T865gPWYvxJLcUaioRZzUXEiAFH0arVRAgAA Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 17:27:03 -0000 Hi, >> Based on the decision in Vancouver to define the usage of port zero in '= bundle-only' m- lines, I've updated the new text I proposed some time ago. >> >> One question that was raised in Vancouver is whether we will have to upd= ate RFC 3264, so I've added a new OPEN ISSUE (13) for that. >>... >> OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Answe= r >> to a zero port value in an SDP Offer. As we now allow a non-zero >> value in the SDP Answer, do we need to update 3264 procedures? > > Why is this a question. Section 8.2 of 3264 clearly states this, and we p= ropose to do otherwise. So that means a revision is required. It is a question because we decided in Vancouver that we need to figure out= what/how to do. However, I guess the question is not IF, but HOW, we will update 3264. Will= BUNDLE update the affected 3264 sections? Will we produce a 3264bis? Etc e= tc etc. Regards, Christer From pkyzivat@alum.mit.edu Thu Nov 14 09:35:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B4521F9FA4 for ; Thu, 14 Nov 2013 09:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXhH1Z67FKWB for ; Thu, 14 Nov 2013 09:35:26 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 88DB821F9BD5 for ; Thu, 14 Nov 2013 09:35:24 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta13.westchester.pa.mail.comcast.net with comcast id pPzo1m0031ei1Bg5DVbQij; Thu, 14 Nov 2013 17:35:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id pVbP1m00v3ZTu2S3kVbPAv; Thu, 14 Nov 2013 17:35:24 +0000 Message-ID: <528509DB.5000604@alum.mit.edu> Date: Thu, 14 Nov 2013 09:35:23 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C518B4A@ESESSMB209.ericsson.se> <52850394.6080602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C51998A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C51998A@ESESSMB209.ericsson.se> 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=1384450524; bh=IQqjZUiPUEbKOo4D+lpp9oLiNVSzFXrzq0ea8a8qdTk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T6JuDoIXQ4c8V+2d/JVL/uuR7PWdIyG3hssN7tiQZfje5gASHKMBUU1X45BHJMr7G 4RQYRKwqBwrfeE+96k8Q7HC22W3HXBqvuOMQa/8z95+5XzxoiX8vn0zrDp0CgU7L0X GJWcvrsk7aYByOOA78hWIFdwfGAPspsZCy+vxnp2j1ukx3Je5C0dzxXX3P+Uv6aoEY mo94Jyo0M4p7Eto6swlLJYmrtwvDBcZZs3t9o8lAKmPVzBFZ53Kwd7I1E0Ox922hUe Ntzu+IskxF7h7hfpMupWJsXrOCzPQJaBM+4nwxhE8zNgpMBfmcRSAfj3YVHrCqb4tR jLQ46EbzeJfcA== Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 17:35:32 -0000 On 11/14/13 9:26 AM, Christer Holmberg wrote: > Hi, > >>> Based on the decision in Vancouver to define the usage of port zero in 'bundle-only' m- lines, I've updated the new text I proposed some time ago. >>> >>> One question that was raised in Vancouver is whether we will have to update RFC 3264, so I've added a new OPEN ISSUE (13) for that. >>> ... >>> OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Answer >>> to a zero port value in an SDP Offer. As we now allow a non-zero >>> value in the SDP Answer, do we need to update 3264 procedures? >> >> Why is this a question. Section 8.2 of 3264 clearly states this, and we propose to do otherwise. So that means a revision is required. > > It is a question because we decided in Vancouver that we need to figure out what/how to do. > > However, I guess the question is not IF, but HOW, we will update 3264. Will BUNDLE update the affected 3264 sections? Will we produce a 3264bis? Etc etc etc. Right. I doubt we want to do a 3264bis at this time. The most straightforward thing is to simply put an explicit statement in this draft that it is updating 3264 in this way as a narrow exception, and mark the draft as "updates 3264". And then you can ask the chairs of sipcore to review this. :-) Thanks, Paul From christer.holmberg@ericsson.com Thu Nov 14 09:42:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C38421E8098 for ; Thu, 14 Nov 2013 09:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GR0ul0McYx1 for ; Thu, 14 Nov 2013 09:41:54 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDB221F9FAB for ; Thu, 14 Nov 2013 09:41:46 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-3d-52850b59e8fa Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 33.29.23787.95B05825; Thu, 14 Nov 2013 18:41:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 18:41:45 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05] Thread-Index: Ac7f+yFiio3q0Su+TKa2xyLMPK+t7QBVll2AAANRrvA= Date: Thu, 14 Nov 2013 17:41:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> In-Reply-To: <5284FFBB.2030407@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvrW4kd2uQwYOlxhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxpLWXpWCeTMXKY9NYGxgfinUxcnJICJhI 7P+0kxXCFpO4cG89WxcjF4eQwCFGif4ZD1ghnCWMEmvW3mHsYuTgYBOwkOj+pw3SICLgK/Hs 8W2wBmGBdkaJb3d3gDkiAh2MEl2/drNAVFlJXLxylQ3EZhFQlXjR+IIdZBAvUPeGzU4gYSGB fImPSxrByjkFdCTOf1jEDmIzAl30/dQaJhCbWUBc4sPB68wQlwpILNlzHsoWlXj5+B/UB0oS aw9vZ4Go15O4MXUKG4StLbFs4Wuwel4BQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI3tu YmZOernhJkZgNBzc8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwCjve3zGvtq7MxJP2kj+jrJurv6qENVrUnX6zdvTygvj6h64RS2KPbTgQkRjP6/IafYF AZOZNNs482Uepq2/JPUkoT6mN9zzzVezgnMpNp9z8jyXz9y8cvLfvTaN7IUbStVi9jv0xXzJ 6JjTXXn044u6D7dWXdD6bLZ+SV+4NuPEGWcXHjNZJqnEUpyRaKjFXFScCADl63lxVAIAAA== Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 14 Nov 2013 17:42:06 -0000 Hi, >I don't understand the point of this. > >I'm not aware of any general use of a nettype other than IN, RFC 3108 defines an 'ATM' value. draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. > or an addrtype other than IP4 or IP6, but I also don't see why the behavi= or of bundle is dependent upon this. RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. draft-ietf-mmusic-sdp-cs defines an 'E164' value. (Whether the semantics of the two 'E164' values are the same I don't know, = but that's a separate issue). > Any other choices that still have a notion of port sufficient to allow SD= P O/A rules to apply should also work with bundle. I see no reason to require an extension in such cases - especially since th= ey are very unlikely to occur. Regards, Christer > Based on the comments from Christian, I suggest the following new text fo= r BUNDLE: > > ----------------------------- > > 6.2.2. Connection Data (c=3D) > > The "c=3D" line nettype value [RFC4566] associated with each "m=3D" l= ine > within a BUNDLE group MUST be 'IN'. > > The "c=3D" line addrtype value [RFC4566] associated with each "m=3D" = line > within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST be > associated with each "m=3D" line within a BUNDLE group. > > NOTE: Extensions to this specification can specify usage of the > BUNDLE mechanism for other nettype and addrtype values than the ones > listed above. > > ----------------------------- > > Regards, > > Christer > > > > > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]= =20 > Puolesta Christian Groves > L=E4hetetty: 15. lokakuuta 2013 3:05 > Vastaanottaja: mmusic@ietf.org > Aihe: Re: [MMUSIC] Draft new version:=20 > draft-ietf-mmusic-sdp-bundle-negotiation-05 > > Hello Christer, > > The SDP grouping mechanism can be applied to different nettype/addrtypes.= The BUNDLE draft appears to define behaviour related only to the nettype= =3DIN and addrtypes=3DIPv4/IPv6. i.e. section 2 defines BUNDLE terminology = based on IP. > > Is there an intention that the BUNDLE mechanism is only used for the abov= e net and addrtypes? If so should it be mentioned somewhere in the applicab= ility statement? > > Regards, Christian > > On 14/10/2013 10:37 PM, Christer Holmberg wrote: >> >> Hi, >> >> I've submitted a new version of the BUNDLE draft. >> >> I have implemented the modified text for the Offerer and Answerer=20 >> procedures, as presented on the list in September. >> >> The procedures now also mention the usage of the SDP 'bundle-only' >> attribute. However, the attribute definition itself has yet not been=20 >> added to the draft, as we still haven't solved the issue regarding=20 >> usage of port zero. >> >> In addition, there are some reference corrections, and the FQDN=20 >> values in the examples are now according to RFC 2606. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Thu Nov 14 09:46:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585FF21E8098 for ; Thu, 14 Nov 2013 09:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.277 X-Spam-Level: X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEZGrrnvV5FX for ; Thu, 14 Nov 2013 09:46:53 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E217D21E80E7 for ; Thu, 14 Nov 2013 09:46:37 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-ed-52850c65276b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 69.4B.03802.56C05825; Thu, 14 Nov 2013 18:46:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 18:46:13 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05] Thread-Index: Ac7f+yFiio3q0Su+TKa2xyLMPK+t7QBVll2AAANRrvAAAKeycA== Date: Thu, 14 Nov 2013 17:46:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5199E7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+JvrW4qT2uQwc9jGhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx92Y/c8EVhYofVz4xNzBekepi5OSQEDCR 6L+zmgnCFpO4cG89WxcjF4eQwCFGid/ffrNDOEsYJe4e38/YxcjBwSZgIdH9TxskLiLQzChx 7fxyFhBHWKCdUeLb3R1sEJkORomuX7tZQDpEBJwkTp3VBFnBIqAqsenAAUYQm1fAV+Lyis8s EBs2M0qsfLacGSTBKeAn8Wb2TrCbGIFu+n5qDZjNLCAu8eHgdWaIWwUkluw5D2WLSrx8/I8V wlaSWHt4OwtEvZ7EjalT2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYx sucmZuaklxttYgRGxMEtv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjCUi0VwztCeXqfjeXMjGXRy7f9fXTx+nPi/65Hd0QmXNTIOC9efkZhZKb9x0fVET X172k21V928IzqzeJKhXNnm5b3LbzcANRomTlv1N8vRS8Xod2lqo2Zf2zHxp+M902YqWi/zl Nlr9rWs4fuvoFa3708wikh//Yudk6W3v7h5LChPmOOn/XImlOCPRUIu5qDgRAMeJ+6BWAgAA Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 14 Nov 2013 17:46:58 -0000 I see no reason to NOT require an extension in such cases, that is. -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Christer Holmberg L=E4hetetty: 14. marraskuuta 2013 19:42 Vastaanottaja: Paul Kyzivat; mmusic@ietf.org Aihe: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft ne= w version: draft-ietf-mmusic-sdp-bundle-negotiation-05] Hi, >I don't understand the point of this. > >I'm not aware of any general use of a nettype other than IN, RFC 3108 defines an 'ATM' value. draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. > or an addrtype other than IP4 or IP6, but I also don't see why the behavi= or of bundle is dependent upon this. RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. draft-ietf-mmusic-sdp-cs defines an 'E164' value. (Whether the semantics of the two 'E164' values are the same I don't know, = but that's a separate issue). > Any other choices that still have a notion of port sufficient to allow SD= P O/A rules to apply should also work with bundle. I see no reason to require an extension in such cases - especially since th= ey are very unlikely to occur. Regards, Christer > Based on the comments from Christian, I suggest the following new text fo= r BUNDLE: > > ----------------------------- > > 6.2.2. Connection Data (c=3D) > > The "c=3D" line nettype value [RFC4566] associated with each "m=3D" l= ine > within a BUNDLE group MUST be 'IN'. > > The "c=3D" line addrtype value [RFC4566] associated with each "m=3D" = line > within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST be > associated with each "m=3D" line within a BUNDLE group. > > NOTE: Extensions to this specification can specify usage of the > BUNDLE mechanism for other nettype and addrtype values than the ones > listed above. > > ----------------------------- > > Regards, > > Christer > > > > > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]= =20 > Puolesta Christian Groves > L=E4hetetty: 15. lokakuuta 2013 3:05 > Vastaanottaja: mmusic@ietf.org > Aihe: Re: [MMUSIC] Draft new version:=20 > draft-ietf-mmusic-sdp-bundle-negotiation-05 > > Hello Christer, > > The SDP grouping mechanism can be applied to different nettype/addrtypes.= The BUNDLE draft appears to define behaviour related only to the nettype= =3DIN and addrtypes=3DIPv4/IPv6. i.e. section 2 defines BUNDLE terminology = based on IP. > > Is there an intention that the BUNDLE mechanism is only used for the abov= e net and addrtypes? If so should it be mentioned somewhere in the applicab= ility statement? > > Regards, Christian > > On 14/10/2013 10:37 PM, Christer Holmberg wrote: >> >> Hi, >> >> I've submitted a new version of the BUNDLE draft. >> >> I have implemented the modified text for the Offerer and Answerer=20 >> procedures, as presented on the list in September. >> >> The procedures now also mention the usage of the SDP 'bundle-only' >> attribute. However, the attribute definition itself has yet not been=20 >> added to the draft, as we still haven't solved the issue regarding=20 >> usage of port zero. >> >> In addition, there are some reference corrections, and the FQDN=20 >> values in the examples are now according to RFC 2606. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > 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 christer.holmberg@ericsson.com Thu Nov 14 10:28:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29A21E80FE for ; Thu, 14 Nov 2013 10:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.58 X-Spam-Level: X-Spam-Status: No, score=-5.58 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVBven1PDP38 for ; Thu, 14 Nov 2013 10:28:31 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 58BEE11E8176 for ; Thu, 14 Nov 2013 10:28:31 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-b1-5285164e150d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.5B.23787.E4615825; Thu, 14 Nov 2013 19:28:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 19:28:29 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: VS: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khg== Date: Thu, 14 Nov 2013 18:28:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvra6fWGuQwaqXihZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxtvMDS8E3qYrlh74zNTA+FOli5OSQEDCR OL97KxOELSZx4d56ti5GLg4hgUOMEleOLmeGcJYwSmxdeRoow8HBJmAh0f1PG6RBRMBX4tnj 22wgtrBAisSyCZeZIeKpEpNa57FC2HoSU28fArNZBFQl3j/sYgQZwwvU23ogESTMCLT3+6k1 YDcwC4hLfDh4nRniHgGJJXvOQ9miEi8f/2OFsJUkFt3+DFWvJ3Fj6hQ2CFtbYtnC12D1vAKC EidnPmGZwCg8C8nYWUhaZiFpmYWkZQEjyypG9tzEzJz0csNNjMDAPrjlt+4OxlPnRA4xSnOw KInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUT5Jy9CA7c+XLymnl754U8xZz9e+ Uc2wavrBa68zPafmnnx6u9T/TP6JWT7Jf2bff/lAKd/t1o/WJw6ya2/2nf8vp2khFl7Mwv+l e51IQ7l3y7Rlxsz8DCE1Rne9287qNarIsJ+SC/K7MrOgYf3Hp0bNVjl1vyuNjaJn9j6wX8B2 Z/2ccweLlViKMxINtZiLihMBsQwmYDoCAAA= Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 18:28:38 -0000 Hi, I scanned through 3264, in order to find the sections that need to be updat= ed. Below are the sections/sentences that I found, together with suggestions on= how to modify the text. Section 5.1 (Unicast Streams): ------------------------------------- OLD TEXT: "A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream (Section 6)." SUGGESTED NEW TEXT: "By default, a port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream (Section 6). Extensions can define a different semantics for the usage of a port number of zero in the offer." Section 8.2 (Removing a Media Stream): ------------------------------------------------- =20 OLD TEXT: "A stream that is offered with a port of zero MUST be marked with port zero in the answer." SUGGESTED NEW TEXT: "A stream that is offered with a port of zero, in order to be removed, MUS= T be marked with port zero in the answer." Section 8.4 (Putting a Unicast Media Stream on Hold): ----------------------------------------------------------------- OLD TEXT: "Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled." SUGGESTED NEW TEXT: "Of course, when used, the port number MUST NOT be zero, which could specify that the stream has been disabled." Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 L=E4hetetty: 14. marraskuuta 2013 19:35 Vastaanottaja: Christer Holmberg; mmusic@ietf.org Aihe: Re: VS: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute On 11/14/13 9:26 AM, Christer Holmberg wrote: > Hi, > >>> Based on the decision in Vancouver to define the usage of port zero in = 'bundle-only' m- lines, I've updated the new text I proposed some time ago. >>> >>> One question that was raised in Vancouver is whether we will have to up= date RFC 3264, so I've added a new OPEN ISSUE (13) for that. >>> ... >>> OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Ans= wer >>> to a zero port value in an SDP Offer. As we now allow a non-zero >>> value in the SDP Answer, do we need to update 3264 procedures? >> >> Why is this a question. Section 8.2 of 3264 clearly states this, and we = propose to do otherwise. So that means a revision is required. > > It is a question because we decided in Vancouver that we need to figure o= ut what/how to do. > > However, I guess the question is not IF, but HOW, we will update 3264. Wi= ll BUNDLE update the affected 3264 sections? Will we produce a 3264bis? Etc= etc etc. Right. I doubt we want to do a 3264bis at this time. The most straightforward thing is to simply put an explicit statement in th= is draft that it is updating 3264 in this way as a narrow exception, and ma= rk the draft as "updates 3264". And then you can ask the chairs of sipcore to review this. :-) Thanks, Paul From martin.thomson@gmail.com Thu Nov 14 10:35:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C513B11E8132 for ; Thu, 14 Nov 2013 10:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59B6Rq0HJdit for ; Thu, 14 Nov 2013 10:35:24 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 17BA411E80F7 for ; Thu, 14 Nov 2013 10:35:23 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id m15so2411081wgh.6 for ; Thu, 14 Nov 2013 10:35:23 -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=s9pmokgr40M0PvT643LrNWj+x2zA8R946PxRZeVNUeU=; b=UZLaaiwiViRB0igFtPlaaAQ/U3BB+iVxC1Fz77a2t1npoBg5UsxisyReZtvOtMgl7C 52JQHCVMaPM2iv3rNzwYPN3O4q7X2S24neHEyfUCyQQeB2iZ329TMLHfVJZhMDKcPNrV wJ9QYFwU6sBPJuDevYUpSXPA/L4GjDqjbzRFsEK0MM4qagi8emwqf2i4BQ8gxVer8cZI pSn9gXHaIbgkYb5UAE4c/1ki/kqzpSEz13XNzIBmbu8i0mQZUUBIfjouqQgdsp+1WqWW WBqm4zpu7qrSDgq2FufmQApEjG3ioJjGcT/vXp/hSnEeaFegcpB+R+2G4NqPy949SwKC GQTA== MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr3302672wjc.67.1384454121475; Thu, 14 Nov 2013 10:35:21 -0800 (PST) Received: by 10.227.101.73 with HTTP; Thu, 14 Nov 2013 10:35:21 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> Date: Thu, 14 Nov 2013 10:35:21 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 18:35:24 -0000 On 14 November 2013 10:28, Christer Holmberg wrote: > I scanned through 3264, in order to find the sections that need to be updated. A direct replacement doesn't seem necessary. We aren't issuing a new 3264. A more direct explanation of what 3264 permits or prohibits and why this is being changed is probably more important. Maybe it's as simple as saying something like: RFC 3264 states that m-lines with zero ports are negotiated off. This document updates RFC 3264 to permit the use of a zero port on m-lines in combination with the a=bundle-only attribute. From pkyzivat@alum.mit.edu Thu Nov 14 10:57:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404EE11E8163 for ; Thu, 14 Nov 2013 10:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.043 X-Spam-Level: X-Spam-Status: No, score=0.043 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6Z0AfkjpBen for ; Thu, 14 Nov 2013 10:57:38 -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 87F7311E815C for ; Thu, 14 Nov 2013 10:57:36 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id pWiG1m0091uE5Es54Wxan0; Thu, 14 Nov 2013 18:57:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id pWxZ1m00z3ZTu2S3cWxa0S; Thu, 14 Nov 2013 18:57:34 +0000 Message-ID: <52851D1D.1020801@alum.mit.edu> Date: Thu, 14 Nov 2013 10:57:33 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384455454; bh=3cihHMnD8qecpkcc7K/ArJeWXOUfMhz8s+F4mRibJyo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G1wTJCDD2FBFiwQDjWnl0R9Ud+WFByWrYd2h4v7NKvpbgDrMg7ht5mFwDbYdNxW3T p45aS9w36suwndcpE2tflUioiq6U5X1YFh4GYk18FpsQ4Npl2nQkVW959IdHh8ibom bFBLVewyw+BoYi9jkVDCpJE9kOPg/9haqJCohbf5TweqYF90JpmHEIFxsw8Z38o+O2 MWrUxGrYfbFd47vxVvi7gtA2jTk+cHVKhbnACIOQxVuVQPfsMlVDjKN4x2YP2pupri j4aN/wnl/WWq4zUPbLbAAm3yBJOjKEJUFVXRp/dY/uXHYLazYjIEfOY47P/dS+9Tj1 x90UM4dUWhJnw== Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 14 Nov 2013 18:57:43 -0000 On 11/14/13 9:41 AM, Christer Holmberg wrote: > Hi, > >> I don't understand the point of this. >> >> I'm not aware of any general use of a nettype other than IN, > > RFC 3108 defines an 'ATM' value. > > draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. > >> or an addrtype other than IP4 or IP6, but I also don't see why the behavior of bundle is dependent upon this. > > RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. > > draft-ietf-mmusic-sdp-cs defines an 'E164' value. > > (Whether the semantics of the two 'E164' values are the same I don't know, but that's a separate issue). > >> Any other choices that still have a notion of port sufficient to allow SDP O/A rules to apply should also work with bundle. > > I see no reason to require an extension in such cases - especially since they are very unlikely to occur. This is more of a philosophical issue - whether to say as little as possible, and allow the scope to be broad, or say extra to narrow the scope to the specific case that has motivated the work. I favor saying nothing about this, and leaving the scope to include any network and address type. You are preferring to narrow it. I can live with whatever the consensus is. Thanks, Paul > Regards, > > Christer > > >> Based on the comments from Christian, I suggest the following new text for BUNDLE: >> >> ----------------------------- >> >> 6.2.2. Connection Data (c=) >> >> The "c=" line nettype value [RFC4566] associated with each "m=" line >> within a BUNDLE group MUST be 'IN'. >> >> The "c=" line addrtype value [RFC4566] associated with each "m=" line >> within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST be >> associated with each "m=" line within a BUNDLE group. >> >> NOTE: Extensions to this specification can specify usage of the >> BUNDLE mechanism for other nettype and addrtype values than the ones >> listed above. >> >> ----------------------------- >> >> Regards, >> >> Christer >> >> >> >> >> -----Alkuperäinen viesti----- >> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Puolesta Christian Groves >> Lähetetty: 15. lokakuuta 2013 3:05 >> Vastaanottaja: mmusic@ietf.org >> Aihe: Re: [MMUSIC] Draft new version: >> draft-ietf-mmusic-sdp-bundle-negotiation-05 >> >> Hello Christer, >> >> The SDP grouping mechanism can be applied to different nettype/addrtypes. The BUNDLE draft appears to define behaviour related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section 2 defines BUNDLE terminology based on IP. >> >> Is there an intention that the BUNDLE mechanism is only used for the above net and addrtypes? If so should it be mentioned somewhere in the applicability statement? >> >> Regards, Christian >> >> On 14/10/2013 10:37 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> I've submitted a new version of the BUNDLE draft. >>> >>> I have implemented the modified text for the Offerer and Answerer >>> procedures, as presented on the list in September. >>> >>> The procedures now also mention the usage of the SDP 'bundle-only' >>> attribute. However, the attribute definition itself has yet not been >>> added to the draft, as we still haven't solved the issue regarding >>> usage of port zero. >>> >>> In addition, there are some reference corrections, and the FQDN >>> values in the examples are now according to RFC 2606. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Thu Nov 14 11:05:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F1421E80AE for ; Thu, 14 Nov 2013 11:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.585 X-Spam-Level: X-Spam-Status: No, score=-5.585 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seRq9p3QGH1f for ; Thu, 14 Nov 2013 11:05:14 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D3D1B11E815E for ; Thu, 14 Nov 2013 11:05:13 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-ee-52851ee80dba Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E7.23.15980.8EE15825; Thu, 14 Nov 2013 20:05:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 20:05:12 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpolFa4g Date: Thu, 14 Nov 2013 19:05:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C519ADF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre5LudYgg44DjBbXzvxjtJi6/DGL xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZfz/PZW9YB97xeInc9ga GJewdzFyckgImEis2nuaEcIWk7hwbz1bFyMXh5DAIUaJVRNnsEA4SxglLu06xdTFyMHBJmAh 0f1PG6RBREBXYtHZB2CDmAV8JV4u+MIMYgsLxEv8+rGVEaImQeLA1PtsELaRxIsZS1lBbBYB VYm1Ny6A9fIC9d7Z+IsZYtcURonFj2+BNXAKBErM2toDNpQR6Lrvp9YwQSwTl/hw8DozxNUC Ekv2nIeyRSVePv7HCmErSSy6/RnsZmYBTYn1u/QhWhUlpnQ/hNorKHFy5hOWCYxis5BMnYXQ MQtJxywkHQsYWVYxsucmZuakl5tvYgRGzcEtvw12MG66L3aIUZqDRUmc98Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjOrrJ2z+sZAx4u/iWdXLPU0++z/R31GSa6NYm2P/m0V9lrP4 NelpaSLMSefmcVZur7Uq/836LLy8YMfK8oaJmy4+0auMs7r4fWvKto5u75bMjtQtTNHLwuR0 ki5d2fR3pZycqZ3Fk88XTyzqM/tzeJXwXHublckvbLbO5bQN12dnN5+yZY23gxJLcUaioRZz UXEiALUiRMJoAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 19:05:21 -0000 SGkgTWFydGluLA0KDQo+PiBJIHNjYW5uZWQgdGhyb3VnaCAzMjY0LCBpbiBvcmRlciB0byBmaW5k IHRoZSBzZWN0aW9ucyB0aGF0IG5lZWQgdG8gYmUgdXBkYXRlZC4NCj4NCj4gQSBkaXJlY3QgcmVw bGFjZW1lbnQgZG9lc24ndCBzZWVtIG5lY2Vzc2FyeS4gIFdlIGFyZW4ndCBpc3N1aW5nIGEgbmV3 IDMyNjQuICBBIG1vcmUgZGlyZWN0IGV4cGxhbmF0aW9uIG9mIHdoYXQgMzI2NCBwZXJtaXRzIG9y IHByb2hpYml0cyBhbmQgd2h5IHRoaXMgaXMgYmVpbmcgY2hhbmdlZCBpcyBwcm9iYWJseSBtb3Jl IGltcG9ydGFudC4NCj4NCj4gTWF5YmUgaXQncyBhcyBzaW1wbGUgYXMgc2F5aW5nIHNvbWV0aGlu ZyBsaWtlOg0KPg0KPiBSRkMgMzI2NCBzdGF0ZXMgdGhhdCBtLWxpbmVzIHdpdGggemVybyBwb3J0 cyBhcmUgbmVnb3RpYXRlZCBvZmYuICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDMyNjQgdG8g cGVybWl0IHRoZSB1c2Ugb2YgYSB6ZXJvIHBvcnQgb24gbS1saW5lcyBpbiBjb21iaW5hdGlvbiB3 aXRoIHRoZSBhPWJ1bmRsZS1vbmx5IGF0dHJpYnV0ZS4NCg0KVGhhdCBpcyBub3QgaG93IHdlIGhh dmUgdXBkYXRlZCBSRkNzIGluIHRoZSBwYXN0LiBBdCBsZWFzdCBpbiBteSBleHBlcmllbmNlIHdl IGhhdmUgZXhwbGljaXRseSB1cGRhdGVkIHNwZWNpZmljYXRpb24gdGV4dC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg== From martin.thomson@gmail.com Thu Nov 14 12:03:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF37311E810D for ; Thu, 14 Nov 2013 12:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb7yXJKn0sjt for ; Thu, 14 Nov 2013 12:03:49 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 118B321E80F1 for ; Thu, 14 Nov 2013 12:03:47 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so2638128wgh.32 for ; Thu, 14 Nov 2013 12:03:47 -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=1pXw2fUXa9i5V+zr4EnSdJOWtm3mdvhEsf1Q3kKe38k=; b=Pd5FYVAaLvQ3gzVCALBkRB3YM2ABYNEoJItFJl75e1r8UWtr4LH3bQLhhsYeVJjBPd LQqouINQdGjct5IGF77kca7jAIe8eckP1OSHR/DBe33llgaBCzyRpoDGP2rdVfkCmTxA cWlxZwwSnQ6+kAb2sDbZOzt1YXvjL+8zQxKAPkSN7IqEj02Dvptfize8qJygb7odLrNt FiYwgwadXc2hsoiX6+aVryiSfmCZp3Eo7JmZRM0V2i33XnEFGnapTZq2n01GgdLZsEbM DYNAPN2dXoHsK6N7EtSYF1Qcj8IXRqRimhIEONCf3U7wKRDd9MWTf0duZvvl6sZPcTL3 ytEw== MIME-Version: 1.0 X-Received: by 10.180.86.102 with SMTP id o6mr4455661wiz.30.1384459427286; Thu, 14 Nov 2013 12:03:47 -0800 (PST) Received: by 10.227.101.73 with HTTP; Thu, 14 Nov 2013 12:03:47 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C519ADF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C519ADF@ESESSMB209.ericsson.se> Date: Thu, 14 Nov 2013 12:03:47 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 20:03:49 -0000 On 14 November 2013 11:05, Christer Holmberg wrote: > That is not how we have updated RFCs in the past. At least in my experience we have explicitly updated specification text. I must have been doing it wrong then. I didn't notice anyone caring. From christer.holmberg@ericsson.com Thu Nov 14 12:14:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAAD11E8125 for ; Thu, 14 Nov 2013 12:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieq7GoquU3IV for ; Thu, 14 Nov 2013 12:14:54 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC011E8119 for ; Thu, 14 Nov 2013 12:14:52 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-ca-52852f3bf3e4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E2.40.23787.B3F25825; Thu, 14 Nov 2013 21:14:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 21:14:51 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpolFa4g/////4CAABOjMA== Date: Thu, 14 Nov 2013 20:14:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C519CA5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C519ADF@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra61fmuQwb8bhhbXzvxjtJi6/DGL xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZZx93MJY8Iij4uvLw6wN jEc4uhg5OSQETCS+HF/ABmGLSVy4tx7I5uIQEjjEKDFpwVtmCGcJo8SCa51AGQ4ONgELie5/ 2iANIgK6EovOPmAHsZkFfCVeLvjCDGILC8RL/PqxlRGiJkHiwNT7bBC2k8TZqZ1MIDaLgKrE nZeLwHp5gXofPn7KBLFrPpPE2dnTwJo5BQIlvje+AmtmBLru+6k1TBDLxCU+HLzODHG1gMSS PeehbFGJl4//sULYShJrD29nAbmZWUBTYv0ufYhWRYkp3Q+h9gpKnJz5hGUCo9gsJFNnIXTM QtIxC0nHAkaWVYzsuYmZOenlhpsYgVFzcMtv3R2Mp86JHGKU5mBREuf98NY5SEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANjMVvigoleWSURHzVvVAumm/M/CoiRuavqfGu59OpPv8+Lfb4t vPAEY97BOCON5V5zlFZoPeye6+Gwq2XS8m6GxwtuNvx7E/71q6Xr6UJRr2lqbpcLa0Mytk5i 1kiQXD9NY7NEvI/UscCUMv7bzxfNd2XU+hondyjyjkls3It1NVvUxXQee01WYinOSDTUYi4q TgQAJk5Ll2gCAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 20:14:59 -0000 SSB3YXMgdGhpbmtpbmcgb2YgZG9pbmcgc29tZXRoaW5nIHNpbWlsYXIgdG8gc2VjdGlvbiA1IGlu IGRyYWZ0LWlldGYtZWNyaXQtY291bnRyeS1lbWctdXJuLTAxLCB3aGVyZSB0aGUgb2xkIGFuZCBu ZXcgdGV4dCBpcyBzaG93bi4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYt ZWNyaXQtY291bnRyeS1lbWctdXJuLTAxLnR4dA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Ci0tLS0tQWxrdXBlcsOkaW5lbiB2aWVzdGktLS0tLQ0KTMOkaGV0dMOkasOkOiBNYXJ0aW4gVGhv bXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpMw6RoZXRldHR5OiAxNC4g bWFycmFza3V1dGEgMjAxMyAyMjowNA0KVmFzdGFhbm90dGFqYTogQ2hyaXN0ZXIgSG9sbWJlcmcN CktvcGlvOiBQYXVsIEt5eml2YXQ7IG1tdXNpY0BpZXRmLm9yZw0KQWloZTogUmU6IFtNTVVTSUNd IEJVTkRMRSBERUNJU0lPTiBRODogU0RQICdidW5kbGUtb25seScgYXR0cmlidXRlIC0gU3VnZ2Vz dGVkIDMyNjQgdXBkYXRlDQoNCk9uIDE0IE5vdmVtYmVyIDIwMTMgMTE6MDUsIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBUaGF0IGlz IG5vdCBob3cgd2UgaGF2ZSB1cGRhdGVkIFJGQ3MgaW4gdGhlIHBhc3QuIEF0IGxlYXN0IGluIG15 IGV4cGVyaWVuY2Ugd2UgaGF2ZSBleHBsaWNpdGx5IHVwZGF0ZWQgc3BlY2lmaWNhdGlvbiB0ZXh0 Lg0KDQpJIG11c3QgaGF2ZSBiZWVuIGRvaW5nIGl0IHdyb25nIHRoZW4uICBJIGRpZG4ndCBub3Rp Y2UgYW55b25lIGNhcmluZy4NCg== From christer.holmberg@ericsson.com Thu Nov 14 14:45:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBEA11E8122 for ; Thu, 14 Nov 2013 14:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQH5Jd78oOTt for ; Thu, 14 Nov 2013 14:45:48 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 31AD411E811B for ; Thu, 14 Nov 2013 14:45:47 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-52-5285529ad99b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 73.FA.27941.A9255825; Thu, 14 Nov 2013 23:45:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 23:45:46 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: VS: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05] Thread-Index: Ac7f+yFiio3q0Su+TKa2xyLMPK+t7QBVll2AAANRrvAAAQ8wgAAKATkg Date: Thu, 14 Nov 2013 22:45:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C519DE8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> <52851D1D.1020801@alum.mit.edu> In-Reply-To: <52851D1D.1020801@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre7soNYgg7VzGC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStject75oKbihUT5iU0MHZLdzFyckgImEi0 b1nJCmGLSVy4t56ti5GLQ0jgCKPEto7ZLBDOEkaJ3e372bsYOTjYBCwkuv9pgzSICPhKPHt8 G6xBWKCbUaLlwldmEEdEoIdRom3ZdnaIKjeJI8v+M4HYLAKqEmeXfGYEsXmBuhfeb2eF2HCV UeLT0hPMIAlOAR2JT9e6wIoYgW76fmoNWDOzgLjEh4PXmSFuFZBYsuc8lC0q8fLxP6gflCRW bL/ECFGvJ3Fj6hQ2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYwcxanF SbnpRgabGIERcXDLb4sdjJf/2hxilOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY9/MmqjYe2b679JbrqlfyhbMX6diNuN004NJRwqTZVbo6f6412vhWjYv8XR5SW+AGt/U M82Ss+vfNQQ7TDb3Ocxatvrz1CN/Z8W0PBVsuf1WrnVDcMs7hy7H6k/Nt1nnsd/dnFFjtEIy 0kRWnTErwcW0xdwkriNWwPKRJBf313tnWlkjrrxUYinOSDTUYi4qTgQAHnftS1YCAAA= Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 14 Nov 2013 22:45:53 -0000 Hi, >>> I don't understand the point of this. >>> >>> I'm not aware of any general use of a nettype other than IN, >> >> RFC 3108 defines an 'ATM' value. >> >> draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. >> >>> or an addrtype other than IP4 or IP6, but I also don't see why the beha= vior of bundle is dependent upon this. >> >> RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. >> >> draft-ietf-mmusic-sdp-cs defines an 'E164' value. >> >> (Whether the semantics of the two 'E164' values are the same I don't kno= w, but that's a separate issue). >> >>> Any other choices that still have a notion of port sufficient to allow = SDP O/A rules to apply should also work with bundle. >> >> I see no reason to require an extension in such cases - especially since= they are very unlikely to occur. > > This is more of a philosophical issue - whether to say as little as possi= ble, and allow the scope to be broad, or say extra to narrow the scope to t= he specific case that has motivated the work. > > I favor saying nothing about this, and leaving the scope to include any n= etwork and address type. You are preferring to narrow it. I can live with w= hatever the consensus is. Open Issue #14. The clarification/restriction was requested by Christian, and personally I = think it is good. But, as always, community decides :) Regards, Christer >> Based on the comments from Christian, I suggest the following new text f= or BUNDLE: >> >> ----------------------------- >> >> 6.2.2. Connection Data (c=3D) >> >> The "c=3D" line nettype value [RFC4566] associated with each "m=3D"= line >> within a BUNDLE group MUST be 'IN'. >> >> The "c=3D" line addrtype value [RFC4566] associated with each "m=3D= " line >> within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value MUST = be >> associated with each "m=3D" line within a BUNDLE group. >> >> NOTE: Extensions to this specification can specify usage of the >> BUNDLE mechanism for other nettype and addrtype values than the one= s >> listed above. >> >> ----------------------------- >> >> Regards, >> >> Christer >> >> >> >> >> -----Alkuper=E4inen viesti----- >> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org= ]=20 >> Puolesta Christian Groves >> L=E4hetetty: 15. lokakuuta 2013 3:05 >> Vastaanottaja: mmusic@ietf.org >> Aihe: Re: [MMUSIC] Draft new version: >> draft-ietf-mmusic-sdp-bundle-negotiation-05 >> >> Hello Christer, >> >> The SDP grouping mechanism can be applied to different nettype/addrtypes= . The BUNDLE draft appears to define behaviour related only to the nettype= =3DIN and addrtypes=3DIPv4/IPv6. i.e. section 2 defines BUNDLE terminology = based on IP. >> >> Is there an intention that the BUNDLE mechanism is only used for the abo= ve net and addrtypes? If so should it be mentioned somewhere in the applica= bility statement? >> >> Regards, Christian >> >> On 14/10/2013 10:37 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> I've submitted a new version of the BUNDLE draft. >>> >>> I have implemented the modified text for the Offerer and Answerer=20 >>> procedures, as presented on the list in September. >>> >>> The procedures now also mention the usage of the SDP 'bundle-only' >>> attribute. However, the attribute definition itself has yet not been=20 >>> added to the draft, as we still haven't solved the issue regarding=20 >>> usage of port zero. >>> >>> In addition, there are some reference corrections, and the FQDN=20 >>> values in the examples are now according to RFC 2606. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Thu Nov 14 14:56:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5811E8112 for ; Thu, 14 Nov 2013 14:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.759 X-Spam-Level: X-Spam-Status: No, score=-3.759 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4G0JHpAGuHf for ; Thu, 14 Nov 2013 14:56:23 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1911E80E6 for ; Thu, 14 Nov 2013 14:56:22 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-56-528555158797 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 9F.4B.27941.51555825; Thu, 14 Nov 2013 23:56:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 23:56:21 +0100 From: Christer Holmberg To: "mmusic@ietf.org" , Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpolFa4g/////4CAABOjMIAALG7g Date: Thu, 14 Nov 2013 22:56:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C519E14@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C519ADF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C519CA5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C519CA5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvra5oaGuQwYmtKhbXzvxjtJi6/DGL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx9vQqloJ7rhXNSzkbGH84dzFyckgImEg8 ur2aBcIWk7hwbz1bFyMXh5DAEUaJ+fdWMUI4Sxglbq18zd7FyMHBJmAh0f1PG6RBRCBEYvGV n4wgtrBAvMSvH1sZIeIJEgem3meDsN0kji1sAIuzCKhKdPcfA7N5BXwljs6ZxAQx/zGTxNIF C5hAEpwCfhL7F54AK2IEuuj7qTVgcWYBcYkPB68zQ1wqILFkz3koW1Ti5eN/rBC2ksSK7ZcY Qe5kFtCUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nUWQgds5B0zELSsYCRZRUjR3FqcVJu upHBJkZgJBzc8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wOi8calaRUNY7iG9ByUHvz8r1H1QtFiTr7s2dBYHw45P57qjHojz7kyXyvoiEacpqWKRYfbe Rfb/lZoDm+QSFBvSf07fdyDGjn3RRrm8yefuW76pXlysfOaswa9HX68vFitpcCuzPd7xKavl +Y4spcTQlon9b1fOdD6yyU9IlH9SakvxNGWHDiWW4oxEQy3mouJEAJA7MkFSAgAA Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 22:56:28 -0000 SGksDQoNCkJlbG93IGlzIGFuIGV4YW1wbGUgb2YgaG93IHRoZSAzMjY0IHVwZGF0ZSBjb3VsZCBi ZSBpbXBsZW1lbnRlZCBpbiBCVU5ETEUuDQoNCk5vdGUgdGhhdCBJIG9ubHkgaW5jbHVkZSB0aGUg cGFyYWdyYXBocyB0aGF0IGFyZSBtb2RpZmllZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KOC4gIFVwZGF0ZSB0 byBSRkMgMzI2NA0KDQo4LjEuICBHZW5lcmFsDQoNCiAgIFRoaXMgc2VjdGlvbiByZXBsYWNlcyB0 aGUgdGV4dCBvZiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zIG9mIFJGQyAzMjY0Og0KDQogICBvICBT ZWN0aW9uIDUuMSAoVW5pY2FzdCBTdHJlYW1zKS4NCg0KICAgbyAgU2VjdGlvbiA4LjIgKFJlbW92 aW5nIGEgTWVkaWEgU3RyZWFtKS4NCg0KICAgbyAgU2VjdGlvbiA4LjQgKFB1dHRpbmcgYSBVbmlj YXN0IE1lZGlhIFN0cmVhbSBvbiBIb2xkKS4NCg0KOC4yLiAgT3JpZ2luYWwgdGV4dCBvZiBzZWN0 aW9uIDUuMSAoMm5kIHBhcmFncmFwaCkgb2YgUkZDIDMyNjQNCg0KICAgRm9yIHJlY3Zvbmx5IGFu ZCBzZW5kcmVjdiBzdHJlYW1zLCB0aGUgcG9ydCBudW1iZXIgYW5kIGFkZHJlc3MgaW4gdGhlDQog ICBvZmZlciBpbmRpY2F0ZSB3aGVyZSB0aGUgb2ZmZXJlciB3b3VsZCBsaWtlIHRvIHJlY2VpdmUg dGhlIG1lZGlhDQogICBzdHJlYW0uICBGb3Igc2VuZG9ubHkgUlRQIHN0cmVhbXMsIHRoZSBhZGRy ZXNzIGFuZCBwb3J0IG51bWJlcg0KICAgaW5kaXJlY3RseSBpbmRpY2F0ZSB3aGVyZSB0aGUgb2Zm ZXJlciB3YW50cyB0byByZWNlaXZlIFJUQ1AgcmVwb3J0cy4NCiAgIFVubGVzcyB0aGVyZSBpcyBh biBleHBsaWNpdCBpbmRpY2F0aW9uIG90aGVyd2lzZSwgcmVwb3J0cyBhcmUgc2VudCB0bw0KICAg dGhlIHBvcnQgbnVtYmVyIG9uZSBoaWdoZXIgdGhhbiB0aGUgbnVtYmVyIGluZGljYXRlZC4gIFRo ZSBJUCBhZGRyZXNzDQogICBhbmQgcG9ydCBwcmVzZW50IGluIHRoZSBvZmZlciBpbmRpY2F0ZSBu b3RoaW5nIGFib3V0IHRoZSBzb3VyY2UgSVANCiAgIGFkZHJlc3MgYW5kIHNvdXJjZSBwb3J0IG9m IFJUUCBhbmQgUlRDUCBwYWNrZXRzIHRoYXQgd2lsbCBiZSBzZW50IGJ5DQogICB0aGUgb2ZmZXJl ci4gIEEgcG9ydCBudW1iZXIgb2YgemVybyBpbiB0aGUgb2ZmZXIgaW5kaWNhdGVzIHRoYXQgdGhl DQogICBzdHJlYW0gaXMgb2ZmZXJlZCBidXQgTVVTVCBOT1QgYmUgdXNlZC4gIFRoaXMgaGFzIG5v IHVzZWZ1bCBzZW1hbnRpY3MNCiAgIGluIGFuIGluaXRpYWwgb2ZmZXIsIGJ1dCBpcyBhbGxvd2Vk IGZvciByZWFzb25zIG9mIGNvbXBsZXRlbmVzcywNCiAgIHNpbmNlIHRoZSBhbnN3ZXIgY2FuIGNv bnRhaW4gYSB6ZXJvIHBvcnQgaW5kaWNhdGluZyBhIHJlamVjdGVkIHN0cmVhbQ0KICAgKFNlY3Rp b24gNikuICBGdXJ0aGVybW9yZSwgZXhpc3Rpbmcgc3RyZWFtcyBjYW4gYmUgdGVybWluYXRlZCBi eQ0KICAgc2V0dGluZyB0aGUgcG9ydCB0byB6ZXJvIChTZWN0aW9uIDgpLiAgSW4gZ2VuZXJhbCwg YSBwb3J0IG51bWJlciBvZg0KICAgemVybyBpbmRpY2F0ZXMgdGhhdCB0aGUgbWVkaWEgc3RyZWFt IGlzIG5vdCB3YW50ZWQuDQoNCjguMy4gIE5ldyB0ZXh0IHJlcGxhY2luZyBzZWN0aW9uIDUuMSBv ZiBSRkMgMzI2NA0KDQogICBGb3IgcmVjdm9ubHkgYW5kIHNlbmRyZWN2IHN0cmVhbXMsIHRoZSBw b3J0IG51bWJlciBhbmQgYWRkcmVzcyBpbiB0aGUNCiAgIG9mZmVyIGluZGljYXRlIHdoZXJlIHRo ZSBvZmZlcmVyIHdvdWxkIGxpa2UgdG8gcmVjZWl2ZSB0aGUgbWVkaWENCiAgIHN0cmVhbS4gIEZv ciBzZW5kb25seSBSVFAgc3RyZWFtcywgdGhlIGFkZHJlc3MgYW5kIHBvcnQgbnVtYmVyDQogICBp bmRpcmVjdGx5IGluZGljYXRlIHdoZXJlIHRoZSBvZmZlcmVyIHdhbnRzIHRvIHJlY2VpdmUgUlRD UCByZXBvcnRzLg0KICAgVW5sZXNzIHRoZXJlIGlzIGFuIGV4cGxpY2l0IGluZGljYXRpb24gb3Ro ZXJ3aXNlLCByZXBvcnRzIGFyZSBzZW50IHRvDQogICB0aGUgcG9ydCBudW1iZXIgb25lIGhpZ2hl ciB0aGFuIHRoZSBudW1iZXIgaW5kaWNhdGVkLiAgVGhlIElQIGFkZHJlc3MNCiAgIGFuZCBwb3J0 IHByZXNlbnQgaW4gdGhlIG9mZmVyIGluZGljYXRlIG5vdGhpbmcgYWJvdXQgdGhlIHNvdXJjZSBJ UA0KICAgYWRkcmVzcyBhbmQgc291cmNlIHBvcnQgb2YgUlRQIGFuZCBSVENQIHBhY2tldHMgdGhh dCB3aWxsIGJlIHNlbnQgYnkNCiAgIHRoZSBvZmZlcmVyLiAgQSBwb3J0IG51bWJlciBvZiB6ZXJv IGluIHRoZSBvZmZlciBpbmRpY2F0ZXMgdGhhdCB0aGUNCiAgIHN0cmVhbSBpcyBvZmZlcmVkIGJ1 dCBNVVNUIE5PVCBiZSB1c2VkLiAgVGhpcyBoYXMgbm8gdXNlZnVsIHNlbWFudGljcw0KICAgaW4g YW4gaW5pdGlhbCBvZmZlciwgYnV0IGlzIGFsbG93ZWQgZm9yIHJlYXNvbnMgb2YgY29tcGxldGVu ZXNzLA0KICAgc2luY2UgdGhlIGFuc3dlciBjYW4gY29udGFpbiBhIHplcm8gcG9ydCBpbmRpY2F0 aW5nIGEgcmVqZWN0ZWQgc3RyZWFtDQogICAoU2VjdGlvbiA2KS4gIEZ1cnRoZXJtb3JlLCBleGlz dGluZyBzdHJlYW1zIGNhbiBiZSB0ZXJtaW5hdGVkIGJ5DQogICBzZXR0aW5nIHRoZSBwb3J0IHRv IHplcm8gKFNlY3Rpb24gOCkuICBJbiBnZW5lcmFsLCBhIHBvcnQgbnVtYmVyIG9mDQogICB6ZXJv IGluZGljYXRlcyB0aGF0IHRoZSBtZWRpYSBzdHJlYW0gaXMgbm90IHdhbnRlZC4NCg0KOC40LiAg T3JpZ2luYWwgdGV4dCBvZiBzZWN0aW9uIDguMiAoMm5kIHBhcmFncmFwaCkgb2YgUkZDIDMyNjQN Cg0KICAgQSBzdHJlYW0gdGhhdCBpcyBvZmZlcmVkIHdpdGggYSBwb3J0IG9mIHplcm8gTVVTVCBi ZSBtYXJrZWQgd2l0aCBwb3J0DQogICB6ZXJvIGluIHRoZSBhbnN3ZXIuICBMaWtlIHRoZSBvZmZl ciwgdGhlIGFuc3dlciBNQVkgb21pdCBhbGwNCiAgIGF0dHJpYnV0ZXMgcHJlc2VudCBwcmV2aW91 c2x5LCBhbmQgTUFZIGxpc3QganVzdCBhIHNpbmdsZSBtZWRpYQ0KICAgZm9ybWF0IGZyb20gYW1v bmdzdCB0aG9zZSBpbiB0aGUgb2ZmZXIuDQoNCjguNS4gIE5ldyB0ZXh0IHJlcGxhY2luZyBzZWN0 aW9uIDguMiAoMm5kIHBhcmFncmFwaCkgb2YgUkZDIDMyNjQNCg0KICAgQSBzdHJlYW0gdGhhdCBp cyBvZmZlcmVkIHdpdGggYSBwb3J0IG9mIHplcm8sIGluIG9yZGVyIHRvIGJlIHJlbW92ZWQsDQog ICBNVVNUIGJlIG1hcmtlZCB3aXRoIHBvcnQgemVybyBpbiB0aGUgYW5zd2VyLiAgTGlrZSB0aGUg b2ZmZXIsIHRoZQ0KICAgYW5zd2VyIE1BWSBvbWl0IGFsbCBhdHRyaWJ1dGVzIHByZXNlbnQgcHJl dmlvdXNseSwgYW5kIE1BWSBsaXN0IGp1c3QNCiAgIGEgc2luZ2xlIG1lZGlhIGZvcm1hdCBmcm9t IGFtb25nc3QgdGhvc2UgaW4gdGhlIG9mZmVyLg0KDQo4LjYuICBPcmlnaW5hbCB0ZXh0IG9mIHNl Y3Rpb24gOC40ICg2dGggcGFyYWdyYXBoKSBvZiBSRkMgMzI2NA0KDQogICBSRkMgMjU0MyBbMTBd IHNwZWNpZmllZCB0aGF0IHBsYWNpbmcgYSB1c2VyIG9uIGhvbGQgd2FzIGFjY29tcGxpc2hlZA0K ICAgYnkgc2V0dGluZyB0aGUgY29ubmVjdGlvbiBhZGRyZXNzIHRvIDAuMC4wLjAuICBJdHMgdXNh Z2UgZm9yIHB1dHRpbmcNCiAgIGEgY2FsbCBvbiBob2xkIGlzIG5vIGxvbmdlciByZWNvbW1lbmRl ZCwgc2luY2UgaXQgZG9lc24ndCBhbGxvdyBmb3INCiAgIFJUQ1AgdG8gYmUgdXNlZCB3aXRoIGhl bGQgc3RyZWFtcywgZG9lc24ndCB3b3JrIHdpdGggSVB2NiwgYW5kIGJyZWFrcw0KICAgd2l0aCBj b25uZWN0aW9uIG9yaWVudGVkIG1lZGlhLiAgSG93ZXZlciwgaXQgY2FuIGJlIHVzZWZ1bCBpbiBh bg0KICAgaW5pdGlhbCBvZmZlciB3aGVuIHRoZSBvZmZlcmVyIGtub3dzIGl0IHdhbnRzIHRvIHVz ZSBhIHBhcnRpY3VsYXIgc2V0DQogICBvZiBtZWRpYSBzdHJlYW1zIGFuZCBmb3JtYXRzLCBidXQg ZG9lc24ndCBrbm93IHRoZSBhZGRyZXNzZXMgYW5kDQogICBwb3J0cyBhdCB0aGUgdGltZSBvZiB0 aGUgb2ZmZXIuICBPZiBjb3Vyc2UsIHdoZW4gdXNlZCwgdGhlIHBvcnQNCiAgIG51bWJlciBNVVNU IE5PVCBiZSB6ZXJvLCB3aGljaCB3b3VsZCBzcGVjaWZ5IHRoYXQgdGhlIHN0cmVhbSBoYXMgYmVl bg0KICAgZGlzYWJsZWQuICBBbiBhZ2VudCBNVVNUIGJlIGNhcGFibGUgb2YgcmVjZWl2aW5nIFNE UCB3aXRoIGENCiAgIGNvbm5lY3Rpb24gYWRkcmVzcyBvZiAwLjAuMC4wLCBpbiB3aGljaCBjYXNl IGl0IG1lYW5zIHRoYXQgbmVpdGhlcg0KICAgUlRQIG5vciBSVENQIHNob3VsZCBiZSBzZW50IHRv IHRoZSBwZWVyLg0KDQo4LjcuICBOZXcgdGV4dCByZXBsYWNpbmcgc2VjdGlvbiA4LjQgKDZ0aCBw YXJhZ3JhcGgpIG9mIFJGQyAzMjY0DQoNCiAgIFJGQyAyNTQzIFsxMF0gc3BlY2lmaWVkIHRoYXQg cGxhY2luZyBhIHVzZXIgb24gaG9sZCB3YXMgYWNjb21wbGlzaGVkDQogICBieSBzZXR0aW5nIHRo ZSBjb25uZWN0aW9uIGFkZHJlc3MgdG8gMC4wLjAuMC4gIEl0cyB1c2FnZSBmb3IgcHV0dGluZw0K ICAgYSBjYWxsIG9uIGhvbGQgaXMgbm8gbG9uZ2VyIHJlY29tbWVuZGVkLCBzaW5jZSBpdCBkb2Vz bid0IGFsbG93IGZvcg0KICAgUlRDUCB0byBiZSB1c2VkIHdpdGggaGVsZCBzdHJlYW1zLCBkb2Vz bid0IHdvcmsgd2l0aCBJUHY2LCBhbmQgYnJlYWtzDQogICB3aXRoIGNvbm5lY3Rpb24gb3JpZW50 ZWQgbWVkaWEuICBIb3dldmVyLCBpdCBjYW4gYmUgdXNlZnVsIGluIGFuDQogICBpbml0aWFsIG9m ZmVyIHdoZW4gdGhlIG9mZmVyZXIga25vd3MgaXQgd2FudHMgdG8gdXNlIGEgcGFydGljdWxhciBz ZXQNCiAgIG9mIG1lZGlhIHN0cmVhbXMgYW5kIGZvcm1hdHMsIGJ1dCBkb2Vzbid0IGtub3cgdGhl IGFkZHJlc3NlcyBhbmQNCiAgIHBvcnRzIGF0IHRoZSB0aW1lIG9mIHRoZSBvZmZlci4gIE9mIGNv dXJzZSwgd2hlbiB1c2VkLCB0aGUgcG9ydA0KICAgbnVtYmVyIE1VU1QgTk9UIGJlIHplcm8sIHdo aWNoIGNvdWxkIHNwZWNpZnkgdGhhdCB0aGUgc3RyZWFtIGhhcyBiZWVuDQogICBkaXNhYmxlZC4g IEFuIGFnZW50IE1VU1QgYmUgY2FwYWJsZSBvZiByZWNlaXZpbmcgU0RQIHdpdGggYQ0KICAgY29u bmVjdGlvbiBhZGRyZXNzIG9mIDAuMC4wLjAsIGluIHdoaWNoIGNhc2UgaXQgbWVhbnMgdGhhdCBu ZWl0aGVyDQogICBSVFAgbm9yIFJUQ1Agc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHBlZXIuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCi0tLS0tQWxr dXBlcsOkaW5lbiB2aWVzdGktLS0tLQ0KTMOkaGV0dMOkasOkOiBtbXVzaWMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBQdW9sZXN0YSBDaHJpc3RlciBI b2xtYmVyZw0KTMOkaGV0ZXR0eTogMTQuIG1hcnJhc2t1dXRhIDIwMTMgMjI6MTUNClZhc3RhYW5v dHRhamE6IE1hcnRpbiBUaG9tc29uDQpLb3BpbzogbW11c2ljQGlldGYub3JnOyBQYXVsIEt5eml2 YXQNCkFpaGU6IFJlOiBbTU1VU0lDXSBCVU5ETEUgREVDSVNJT04gUTg6IFNEUCAnYnVuZGxlLW9u bHknIGF0dHJpYnV0ZSAtIFN1Z2dlc3RlZCAzMjY0IHVwZGF0ZQ0KDQpJIHdhcyB0aGlua2luZyBv ZiBkb2luZyBzb21ldGhpbmcgc2ltaWxhciB0byBzZWN0aW9uIDUgaW4gZHJhZnQtaWV0Zi1lY3Jp dC1jb3VudHJ5LWVtZy11cm4tMDEsIHdoZXJlIHRoZSBvbGQgYW5kIG5ldyB0ZXh0IGlzIHNob3du Lg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1lY3JpdC1jb3VudHJ5LWVt Zy11cm4tMDEudHh0DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KLS0tLS1BbGt1cGVyw6Rp bmVuIHZpZXN0aS0tLS0tDQpMw6RoZXR0w6Rqw6Q6IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFy dGluLnRob21zb25AZ21haWwuY29tXSANCkzDpGhldGV0dHk6IDE0LiBtYXJyYXNrdXV0YSAyMDEz IDIyOjA0DQpWYXN0YWFub3R0YWphOiBDaHJpc3RlciBIb2xtYmVyZw0KS29waW86IFBhdWwgS3l6 aXZhdDsgbW11c2ljQGlldGYub3JnDQpBaWhlOiBSZTogW01NVVNJQ10gQlVORExFIERFQ0lTSU9O IFE4OiBTRFAgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUgLSBTdWdnZXN0ZWQgMzI2NCB1cGRhdGUN Cg0KT24gMTQgTm92ZW1iZXIgMjAxMyAxMTowNSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IFRoYXQgaXMgbm90IGhvdyB3ZSBoYXZl IHVwZGF0ZWQgUkZDcyBpbiB0aGUgcGFzdC4gQXQgbGVhc3QgaW4gbXkgZXhwZXJpZW5jZSB3ZSBo YXZlIGV4cGxpY2l0bHkgdXBkYXRlZCBzcGVjaWZpY2F0aW9uIHRleHQuDQoNCkkgbXVzdCBoYXZl IGJlZW4gZG9pbmcgaXQgd3JvbmcgdGhlbi4gIEkgZGlkbid0IG5vdGljZSBhbnlvbmUgY2FyaW5n Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNp YyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMNCg== From Christian.Groves@nteczone.com Thu Nov 14 14:58:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756AF21E80B3 for ; Thu, 14 Nov 2013 14:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtvQiGIZiNon for ; Thu, 14 Nov 2013 14:58:13 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 557A821E8064 for ; Thu, 14 Nov 2013 14:58:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoVABBVhVJ20W1tPGdsb2JhbAANTYM/vyZLgTcDAQEBATiCWgEBAQQBAQEJJgEFGxsbCxgJGgQHDwIWHAMREwYCAQGICq0xk0IEj2aEMQOsBoFS Received: from ppp118-209-109-109.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.109.109]) by ipmail04.adl6.internode.on.net with ESMTP; 15 Nov 2013 09:28:12 +1030 Message-ID: <5285557B.60700@nteczone.com> Date: Fri, 15 Nov 2013 09:58:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> <52851D1D.1020801@alum.mit.edu> In-Reply-To: <52851D1D.1020801@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 14 Nov 2013 22:58:14 -0000 Hello Paul, The problem is that BUNDLE is described in terms of how it relates to IN addresses not other address types. If the scope is left general the text and procedures should also be made general to match. I don't think we want to go down that path. Regards, Christian On 15/11/2013 5:57 AM, Paul Kyzivat wrote: > On 11/14/13 9:41 AM, Christer Holmberg wrote: >> Hi, >> >>> I don't understand the point of this. >>> >>> I'm not aware of any general use of a nettype other than IN, >> >> RFC 3108 defines an 'ATM' value. >> >> draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. >> >>> or an addrtype other than IP4 or IP6, but I also don't see why the >>> behavior of bundle is dependent upon this. >> >> RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. >> >> draft-ietf-mmusic-sdp-cs defines an 'E164' value. >> >> (Whether the semantics of the two 'E164' values are the same I don't >> know, but that's a separate issue). >> >>> Any other choices that still have a notion of port sufficient to >>> allow SDP O/A rules to apply should also work with bundle. >> >> I see no reason to require an extension in such cases - especially >> since they are very unlikely to occur. > > This is more of a philosophical issue - whether to say as little as > possible, and allow the scope to be broad, or say extra to narrow the > scope to the specific case that has motivated the work. > > I favor saying nothing about this, and leaving the scope to include > any network and address type. You are preferring to narrow it. I can > live with whatever the consensus is. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> >>> Based on the comments from Christian, I suggest the following new >>> text for BUNDLE: >>> >>> ----------------------------- >>> >>> 6.2.2. Connection Data (c=) >>> >>> The "c=" line nettype value [RFC4566] associated with each "m=" >>> line >>> within a BUNDLE group MUST be 'IN'. >>> >>> The "c=" line addrtype value [RFC4566] associated with each >>> "m=" line >>> within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value >>> MUST be >>> associated with each "m=" line within a BUNDLE group. >>> >>> NOTE: Extensions to this specification can specify usage of the >>> BUNDLE mechanism for other nettype and addrtype values than the >>> ones >>> listed above. >>> >>> ----------------------------- >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> -----Alkuperäinen viesti----- >>> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>> Puolesta Christian Groves >>> Lähetetty: 15. lokakuuta 2013 3:05 >>> Vastaanottaja: mmusic@ietf.org >>> Aihe: Re: [MMUSIC] Draft new version: >>> draft-ietf-mmusic-sdp-bundle-negotiation-05 >>> >>> Hello Christer, >>> >>> The SDP grouping mechanism can be applied to different >>> nettype/addrtypes. The BUNDLE draft appears to define behaviour >>> related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section >>> 2 defines BUNDLE terminology based on IP. >>> >>> Is there an intention that the BUNDLE mechanism is only used for the >>> above net and addrtypes? If so should it be mentioned somewhere in >>> the applicability statement? >>> >>> Regards, Christian >>> >>> On 14/10/2013 10:37 PM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> I've submitted a new version of the BUNDLE draft. >>>> >>>> I have implemented the modified text for the Offerer and Answerer >>>> procedures, as presented on the list in September. >>>> >>>> The procedures now also mention the usage of the SDP 'bundle-only' >>>> attribute. However, the attribute definition itself has yet not been >>>> added to the draft, as we still haven't solved the issue regarding >>>> usage of port zero. >>>> >>>> In addition, there are some reference corrections, and the FQDN >>>> values in the examples are now according to RFC 2606. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> 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 15 07:07:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFFA11E8150 for ; Fri, 15 Nov 2013 07:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEesYaY7H4Dz for ; Fri, 15 Nov 2013 07:07:32 -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 A25C311E81A8 for ; Fri, 15 Nov 2013 07:07:31 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id popr1m0030xGWP854r7SHb; Fri, 15 Nov 2013 15:07:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id pr7S1m00Q3ZTu2S3Yr7S6x; Fri, 15 Nov 2013 15:07:26 +0000 Message-ID: <528638AE.2000106@alum.mit.edu> Date: Fri, 15 Nov 2013 07:07:26 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> <52851D1D.1020801@alum.mit.edu> <5285557B.60700@nteczone.com> In-Reply-To: <5285557B.60700@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384528046; bh=CBVb0OHbb3Yb4wy5FMEKCKEQuLWfOCJf9h0B/F+81Lw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qYtVqTVXqHH9ML4iZTOzgWd2bbjGPJfFFviCAjDSTKh8IpTHvvaDd9y3+RKA5KVQd BRXMVVt8kHGaVeFnBePwk3ZVmzWdMF5uAP+l33s7kojtehDC3wT981BnXa6VCLFibS nehZwCLwxvzWMx5nxJ/GVtn1KO5qgG1rBRpsmf1zCcyZfTbZTvaLr478lLqCBXgnUq wek8yyOKxmpi/F14yUinlNnLR6X2vEB8Dz8e6kFP7ZDppmBj9oUvAa04LfDVKVZFdR 62C99esbJ1N1xM3rALsfCQA5Mxd0YsapGUeK6Wl0qPui2IId+kHML0jyVEpwARbIhe KXV2J+9LtgT0w== Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 15 Nov 2013 15:07:42 -0000 On 11/14/13 2:58 PM, Christian Groves wrote: > Hello Paul, > > The problem is that BUNDLE is described in terms of how it relates to IN > addresses not other address types. If the scope is left general the text > and procedures should also be made general to match. I don't think we > want to go down that path. Hmm. I guess you are referring to the definitions of Unique address and BUNDLE address that reference IP address. And maybe 5-tuple and other places that refer to "address". OK. I agree that it may be easier to restrict the scope than to wordsmith these definitions to be more general. Thanks, Paul > Regards, Christian > > On 15/11/2013 5:57 AM, Paul Kyzivat wrote: >> On 11/14/13 9:41 AM, Christer Holmberg wrote: >>> Hi, >>> >>>> I don't understand the point of this. >>>> >>>> I'm not aware of any general use of a nettype other than IN, >>> >>> RFC 3108 defines an 'ATM' value. >>> >>> draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. >>> >>>> or an addrtype other than IP4 or IP6, but I also don't see why the >>>> behavior of bundle is dependent upon this. >>> >>> RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. >>> >>> draft-ietf-mmusic-sdp-cs defines an 'E164' value. >>> >>> (Whether the semantics of the two 'E164' values are the same I don't >>> know, but that's a separate issue). >>> >>>> Any other choices that still have a notion of port sufficient to >>>> allow SDP O/A rules to apply should also work with bundle. >>> >>> I see no reason to require an extension in such cases - especially >>> since they are very unlikely to occur. >> >> This is more of a philosophical issue - whether to say as little as >> possible, and allow the scope to be broad, or say extra to narrow the >> scope to the specific case that has motivated the work. >> >> I favor saying nothing about this, and leaving the scope to include >> any network and address type. You are preferring to narrow it. I can >> live with whatever the consensus is. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>>> Based on the comments from Christian, I suggest the following new >>>> text for BUNDLE: >>>> >>>> ----------------------------- >>>> >>>> 6.2.2. Connection Data (c=) >>>> >>>> The "c=" line nettype value [RFC4566] associated with each "m=" >>>> line >>>> within a BUNDLE group MUST be 'IN'. >>>> >>>> The "c=" line addrtype value [RFC4566] associated with each >>>> "m=" line >>>> within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value >>>> MUST be >>>> associated with each "m=" line within a BUNDLE group. >>>> >>>> NOTE: Extensions to this specification can specify usage of the >>>> BUNDLE mechanism for other nettype and addrtype values than the >>>> ones >>>> listed above. >>>> >>>> ----------------------------- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> -----Alkuperäinen viesti----- >>>> Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>> Puolesta Christian Groves >>>> Lähetetty: 15. lokakuuta 2013 3:05 >>>> Vastaanottaja: mmusic@ietf.org >>>> Aihe: Re: [MMUSIC] Draft new version: >>>> draft-ietf-mmusic-sdp-bundle-negotiation-05 >>>> >>>> Hello Christer, >>>> >>>> The SDP grouping mechanism can be applied to different >>>> nettype/addrtypes. The BUNDLE draft appears to define behaviour >>>> related only to the nettype=IN and addrtypes=IPv4/IPv6. i.e. section >>>> 2 defines BUNDLE terminology based on IP. >>>> >>>> Is there an intention that the BUNDLE mechanism is only used for the >>>> above net and addrtypes? If so should it be mentioned somewhere in >>>> the applicability statement? >>>> >>>> Regards, Christian >>>> >>>> On 14/10/2013 10:37 PM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've submitted a new version of the BUNDLE draft. >>>>> >>>>> I have implemented the modified text for the Offerer and Answerer >>>>> procedures, as presented on the list in September. >>>>> >>>>> The procedures now also mention the usage of the SDP 'bundle-only' >>>>> attribute. However, the attribute definition itself has yet not been >>>>> added to the draft, as we still haven't solved the issue regarding >>>>> usage of port zero. >>>>> >>>>> In addition, there are some reference corrections, and the FQDN >>>>> values in the examples are now according to RFC 2606. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Fri Nov 15 09:51:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07AC11E81B7 for ; Fri, 15 Nov 2013 09:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg5CTMeL+fOs for ; Fri, 15 Nov 2013 09:51:27 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7310111E8110 for ; Fri, 15 Nov 2013 09:51:26 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-25-52865f1d06a9 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.E5.27941.D1F56825; Fri, 15 Nov 2013 18:51:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Fri, 15 Nov 2013 18:51:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-05] Thread-Index: AQHO4Y0BWif7AysXX0+NT7V1Btk2DpomVOwAgAA+VKA= Date: Fri, 15 Nov 2013 17:51:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C51A80E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C51810A@ESESSMB209.ericsson.se> <5284FFBB.2030407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5199CB@ESESSMB209.ericsson.se> <52851D1D.1020801@alum.mit.edu> <5285557B.60700@nteczone.com> <528638AE.2000106@alum.mit.edu> In-Reply-To: <528638AE.2000106@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvra5sfFuQwdsb6hZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxd+lcxoKDBhVNt24zNzDeVe9i5OSQEDCR uHJkNyuELSZx4d56ti5GLg4hgSOMEgde74RyljBKbLl+FaiKg4NNwEKi+582SIOIgK/Es8e3 wWqEBdoZJb7d3QHmiAh0MEp0/drNAlFlJdF5bSfYChYBVYkJm++yg9i8QN3rzixkh9gwlUni +OwvbCAJTgEdiUPr2plBbEagm76fWsMEYjMLiEt8OHidGeJWAYkle85D2aISLx//g/pBSWLF 9kuMEPV6EjemTmGDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxchRnFqc lJtuZLCJERgTB7f8ttjBePmvzSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwTq/+Z8h09k3E0emej0JDp/8+esSgWeNk6uxQGbcMF73bl5nV75snexjynuGo3hx+mV9z 25zjbVt/Fafo3zU/wiQmfeb+xccbufJtpV/YOhyRfbbwlLPhqeagSVWy7vOUTy+6sPFGno0Y q8tZ7yy+ktTrr02yvpyf5Huv8vjUp45bGCZt1ClJUWIpzkg01GIuKk4EAEb0fBlXAgAA Subject: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-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, 15 Nov 2013 17:51:32 -0000 Hi, Thanks, Paul! So, unless someone else objects, I'll include the suggested text in the nex= t version of BUNDLE. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Paul Kyzivat L=E4hetetty: 15. marraskuuta 2013 17:07 Vastaanottaja: mmusic@ietf.org Aihe: Re: [MMUSIC] BUNDLE TEXT: nettype/addrtype restriction [was: Draft ne= w version: draft-ietf-mmusic-sdp-bundle-negotiation-05] On 11/14/13 2:58 PM, Christian Groves wrote: > Hello Paul, > > The problem is that BUNDLE is described in terms of how it relates to=20 > IN addresses not other address types. If the scope is left general the=20 > text and procedures should also be made general to match. I don't=20 > think we want to go down that path. Hmm. I guess you are referring to the definitions of Unique address and BUN= DLE address that reference IP address. And maybe 5-tuple and other places t= hat refer to "address". OK. I agree that it may be easier to restrict the scope than to wordsmith t= hese definitions to be more general. Thanks, Paul > Regards, Christian > > On 15/11/2013 5:57 AM, Paul Kyzivat wrote: >> On 11/14/13 9:41 AM, Christer Holmberg wrote: >>> Hi, >>> >>>> I don't understand the point of this. >>>> >>>> I'm not aware of any general use of a nettype other than IN, >>> >>> RFC 3108 defines an 'ATM' value. >>> >>> draft-ietf-mmusic-sdp-cs defines a 'PSTN' value. >>> >>>> or an addrtype other than IP4 or IP6, but I also don't see why the=20 >>>> behavior of bundle is dependent upon this. >>> >>> RFC 3109 defines 'NSAP', 'E164' and 'GWID' values. >>> >>> draft-ietf-mmusic-sdp-cs defines an 'E164' value. >>> >>> (Whether the semantics of the two 'E164' values are the same I don't=20 >>> know, but that's a separate issue). >>> >>>> Any other choices that still have a notion of port sufficient to=20 >>>> allow SDP O/A rules to apply should also work with bundle. >>> >>> I see no reason to require an extension in such cases - especially=20 >>> since they are very unlikely to occur. >> >> This is more of a philosophical issue - whether to say as little as=20 >> possible, and allow the scope to be broad, or say extra to narrow the=20 >> scope to the specific case that has motivated the work. >> >> I favor saying nothing about this, and leaving the scope to include=20 >> any network and address type. You are preferring to narrow it. I can=20 >> live with whatever the consensus is. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>>> Based on the comments from Christian, I suggest the following new=20 >>>> text for BUNDLE: >>>> >>>> ----------------------------- >>>> >>>> 6.2.2. Connection Data (c=3D) >>>> >>>> The "c=3D" line nettype value [RFC4566] associated with each "m= =3D" >>>> line >>>> within a BUNDLE group MUST be 'IN'. >>>> >>>> The "c=3D" line addrtype value [RFC4566] associated with each=20 >>>> "m=3D" line >>>> within a BUNDLE group MUST be 'IP4' or 'IP6'. The same value=20 >>>> MUST be >>>> associated with each "m=3D" line within a BUNDLE group. >>>> >>>> NOTE: Extensions to this specification can specify usage of the >>>> BUNDLE mechanism for other nettype and addrtype values than=20 >>>> the ones >>>> listed above. >>>> >>>> ----------------------------- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> -----Alkuper=E4inen viesti----- >>>> L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg]=20 >>>> Puolesta Christian Groves >>>> L=E4hetetty: 15. lokakuuta 2013 3:05 >>>> Vastaanottaja: mmusic@ietf.org >>>> Aihe: Re: [MMUSIC] Draft new version: >>>> draft-ietf-mmusic-sdp-bundle-negotiation-05 >>>> >>>> Hello Christer, >>>> >>>> The SDP grouping mechanism can be applied to different=20 >>>> nettype/addrtypes. The BUNDLE draft appears to define behaviour=20 >>>> related only to the nettype=3DIN and addrtypes=3DIPv4/IPv6. i.e.=20 >>>> section >>>> 2 defines BUNDLE terminology based on IP. >>>> >>>> Is there an intention that the BUNDLE mechanism is only used for=20 >>>> the above net and addrtypes? If so should it be mentioned somewhere=20 >>>> in the applicability statement? >>>> >>>> Regards, Christian >>>> >>>> On 14/10/2013 10:37 PM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've submitted a new version of the BUNDLE draft. >>>>> >>>>> I have implemented the modified text for the Offerer and Answerer=20 >>>>> procedures, as presented on the list in September. >>>>> >>>>> The procedures now also mention the usage of the SDP 'bundle-only' >>>>> attribute. However, the attribute definition itself has yet not=20 >>>>> been added to the draft, as we still haven't solved the issue=20 >>>>> regarding usage of port zero. >>>>> >>>>> In addition, there are some reference corrections, and the FQDN=20 >>>>> values in the examples are now according to RFC 2606. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From simon.perreault@viagenie.ca Fri Nov 15 12:27:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C6711E8128; Fri, 15 Nov 2013 12:27:12 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkVm7tx7-ICS; Fri, 15 Nov 2013 12:27:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDE11E80E0; Fri, 15 Nov 2013 12:27:08 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8A20B403CB; Fri, 15 Nov 2013 15:27:07 -0500 (EST) Message-ID: <5286839B.8050305@viagenie.ca> Date: Fri, 15 Nov 2013 15:27:07 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , pntaw@ietf.org, "behave@ietf.org" , mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tram@ietf.org Subject: [MMUSIC] Turn Revised And Modernized (tram) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tram@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 20:27:12 -0000 All, A few of us have been working on a proposal for a new working group that would focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn Revised And Modernized) and discussion is happening in . Subscribe link: Here is the charter we have been working on. If you would like to comment and/or get involved, please do so on the TRAM mailing list. Simon (and many others!) > Turn Revised And Modernized (tram) > ---------------------------------- > > Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April > 2010. Until recently the protocol had only a rather limited deployment. This > is primarily because its primary use case is as one of the NAT traversal > methods of the Interactive Connectivity Establishment (ICE) framework (RFC > 5245). This inherent dependency on ICE combined with the fact that ICE itself > was slow to achieve widespread adoption because other alternative mechanisms > were historically used by the VoIP industry were the causes of the initial > lack of interest. This situation has changed drastically as ICE, and > consequently TURN, are mandatory to implement in WebRTC, which is a set of > technologies developed at the IETF and W3C aiming to enable Real Time > Communication on the Web. > > Because of the ubiquity of the Web and of the new opportunities created by the > arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by > the recent work updating the ICE framework, as well as standardizing the URIs > used to access a STUN [RFC7064] or TURN [RFC7065] server. > > The goal of the TRAM Working Group is to consolidate the various initiatives > to update TURN and STUN, including the definition of new transport and > authentication mechanisms that make STUN and TURN more suitable for the WebRTC > environment. The Working Group will closely coordinate with the appropriate > Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. > > The current list of deliverable is: > > - DTLS transport for TURN > > Candidate draft: draft-petithuguenin-tram-turn-dtls > > TURN defines three transports: UDP, TCP, and TLS. A straightforward extension > of this set is DTLS, enabling secure datagram-oriented transport. > > - New authentication mechanism for TURN > > Problem analysis: draft-reddy-behave-turn-auth > Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been suggested > > The current authentication mechanism for TURN, which is reused from STUN, has > been designed with a SIP account database in mind. The new RTCWEB usages, > which are mostly based on web applications, do not fit that model. A new > authentication mechanism optimized for such web applications will be created. > > - TURN server auto-discovery mechanism for enterprise and ISPs > > Candidate draft: TBD > > Current TURN server discovery is based on the presence of SRV and/or NAPTR DNS > records. These records are usually under the administrative control of the > application or service provider, not the enterprise or the ISP on whose > network the client is situated. Enterprises or ISPs wishing to provide their > own TURN server, in an attempt to reduce so-called "triangle routing", need a > new auto-discovery mechanism. > > - STUN-bis > > Candidate draft: TBD > > A new revision of RFC 5389 will contain: > > - Various bug fixes > - STUN hash algorithm agility (currently only SHA-1 is allowed) > > - TURN-bis > > Candidate draft: TBD > > A new revision of RFC 5766 will contain: > > - Various bug fixes > - Support for multi-tenant servers > (Servers always send the same REALM attribute. No realm negotiation phase > currently exists.) > > Goals and Milestones: > > [TBD] -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gsalguei@cisco.com Fri Nov 15 14:56:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C652E11E81D2 for ; Fri, 15 Nov 2013 14:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibkQ+JZ2FcsP for ; Fri, 15 Nov 2013 14:56:47 -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 81BBE11E811D for ; Fri, 15 Nov 2013 14:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14647; q=dns/txt; s=iport; t=1384556203; x=1385765803; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yeHpZodFpnA73LKEizTRVEdzfQiOmCrlxIRtCJtT53k=; b=LEdSECh05gpeUl6oSWjgBorLmjLyFmoM4RvwWS1OojmKGPTpMPL/CqUg BfJy7/sxGEUDlovfb2AiaELaZk64Md4GgpodpSZ/rM71Q6/j2cT6VT4R9 /uw8ZWB7VVwRt+6zejnRd23on3c09HzuR0xtzxZrTRcTs/MUsxBygDyqt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFANqlhlKtJV2b/2dsb2JhbABZgwc4U75hS4EqFnSCJQEBAQMBAQEBCVwGCwUHBAIBCBEEAQEBJwcnCxQJCAIEDgUUB4dgBg3BJQSOKIEOMwcGgxqBEQOTbEKDYpINgyiBaUE X-IronPort-AV: E=Sophos;i="4.93,710,1378857600"; d="scan'208";a="285291125" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2013 22:56:42 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAFMugil022773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 22:56:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 16:56:42 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHO4N5p0XpoIfKxQUeqq6//ZRwwFpoknjaAgAKwh4A= Date: Fri, 15 Nov 2013 22:56:41 +0000 Message-ID: <81FDCDD8-6BDD-4D64-8D22-00A750E0289F@cisco.com> References: <786615F3A85DF44AA2A76164A71FE1AC0BA3EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A769E@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0BC423@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4A9A45@ESESSMB209.ericsson.se>, <786615F3A85DF44AA2A76164A71FE1AC0BD395@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4AB001@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC0C68BB@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C4B6352@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107E9D@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <7594FB04B1934943A5C02806D1A2204B1C518E13@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC107EFE@FR711WXCHMBA03.zeu.alcatel-lucent.com>, <52843090.4050509@alum.mit.edu> <3l87dt3gkmh42oon4n8n22he.1384408337440@email.android.com> In-Reply-To: <3l87dt3gkmh42oon4n8n22he.1384408337440@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.78] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41D4D2C00039A441A9066E6ADC42DAC4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 22:56:52 -0000 TBH I didn't see a compelling reason to make the change in the first place.= If it is important to Albrecht, I think this proposal is fine and seems in= nocuous to the proposed solution. Gonzalo On Nov 14, 2013, at 12:52 AM, Christer Holmberg wrote: > Hi, >=20 > I guess 'SHOULD use actpass' would work. >=20 > Regards, >=20 > Christer >=20 > Sent from my Sony Ericsson Xperia arc S >=20 > Paul Kyzivat wrote: >=20 >=20 > I believe that the a=3Dsetup attribute was first defined by rfc 4145, for= TCP. >=20 > There it governs who listens for an incoming connection. And the main > concern was that NATs/FWs might prevent one end or the other from > accepting incoming connections. Even so, it didn't have any normative > behavior about what should be in the offer. >=20 > As this same attribute is used in different contexts, the implications > of using it may vary. In particular, if it is intended that either end > should be able to take either the active or passive role, then the > considerations for use may vary. >=20 > ISTM that actpas SHOULD be used in the offer, except in cases where the > offerer has a particular preference for active or passive, and would > prefer to have the connection fail than use the other mode. >=20 > Thanks, > Paul >=20 > On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote: >> Right. >>=20 >> ------------------------------------------------------------------------ >> *Von:* Christer Holmberg [christer.holmberg@ericsson.com] >> *Gesendet:* Donnerstag, 14. November 2013 02:21 >> *An:* Schwarz, Albrecht (Albrecht) >> *Cc:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >> session >>=20 >> Hi Albrecht, >>=20 >> If I understand your proposal correctly, the change would be to relax >> the rule for assigning the SDP setup attribute value in the SDP Offer. >> Instead of mandating actpass, we would also allow active and passive. >>=20 >> Right? >>=20 >> Regards, >>=20 >> Christer >>=20 >> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> *L=E4hetetty:* 14. marraskuuta 2013 3:11 >> *Vastaanottaja:* Christer Holmberg >> *Kopio:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >> *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessi= on >>=20 >> Hello Christer, >> guess it's time to come back on this topic since the WG adopted the draf= t. >>=20 >> In brief ("don't want to repeat again the thread"): >> a) problem statement: existing SDP O/A rules define a tighly coupled >> mode between the establishment direction of the SIP session and the >> establishment direction of the DTLS session, but there's not any >> reasoning for such tightly coupled behaviour. >>=20 >> b) change proposal: >> Revise in clause 3.1 following list item >>=20 >> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>=20 >> offerer MUST assign the SDP setup attribute with setup:actpass >>=20 >> value, and MUST be prepared to receive a DTLS client_hello message >>=20 >> before it receives the SDP answer. The answerer MUST assign the >>=20 >> SDP setup attribute with either setup:active value or >>=20 >> setup:passive value. The answerer SHOULD assign the SDP setup >>=20 >> attribute with the setup:active value. Whichever party is active >>=20 >> MUST initiate a DTLS handshake by sending a ClientHello over each >>=20 >> flow (host/port quartet). >>=20 >>=20 >> by >>=20 >> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>=20 >> offerer MUST assign the SDP setup attribute with a setup:actpass, >> setup:active or setup:passive >>=20 >> value, and, in case of setup:actpass or setup:passive, MUST be >> prepared to receive a DTLS client_hello message >>=20 >> before it receives the SDP answer. The answerer MUST assign the >>=20 >> SDP setup attribute with either setup:active value or >>=20 >> setup:passive value. The answerer SHOULD assign the SDP setup >>=20 >> attribute with the setup:active value, in case of setup:actpass >> or setup:passive. Whichever party is active >>=20 >> MUST initiate a DTLS handshake by sending a ClientHello over each >>=20 >> flow (host/port quartet). >>=20 >>=20 >> We would limit ourselves with the existing, restrictive SDP O/A rule. >> And without any justification for such a constraint. >>=20 >> Any comments? >>=20 >> Regards, >> Albrecht >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> *Von:*Christer Holmberg [christer.holmberg@ericsson.com] >> *Gesendet:* Montag, 7. Oktober 2013 13:11 >> *An:* Schwarz, Albrecht (Albrecht) >> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >> session >>=20 >> Hi Albrecht, >>=20 >> At this point, the community is making a decision about whether to start >> working on this. >>=20 >> Once that is done, we will start looking into, and discuss, individual >> technical issues etc, and your input will be highly appreciated. >>=20 >> Regards, >>=20 >> Christer >>=20 >> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> *L=E4hetetty:* 7. lokakuuta 2013 13:56 >> *Vastaanottaja:* Christer Holmberg >> *Kopio:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO= ) >> *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sessi= on >>=20 >> Hello Christer, >>=20 >> I may not commit to submit a problem statement in the next couple of >> weeks, just due to time reasons. >>=20 >> At least a note (or editor=92s note) should be added to draft >> mmusic-udptl-dtls in order to indicate the issue and that a solution >> proposal is still pending. >>=20 >> Thanks, >>=20 >> Albrecht >>=20 >> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent:* Dienstag, 24. September 2013 16:01 >> *To:* Schwarz, Albrecht (Albrecht) >> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >> session >>=20 >> Hi Albrecht, >>=20 >> I don't think putting a note somewhere in the fax draft is going to >> solve anything. >>=20 >> As you indicate, the issue exists in multiple documents, so it's a >> generic issues. >>=20 >> So, my suggestion is that you put together a short draft which describes >> the problem, and how you want to change it, and then we can have a more >> generic discussion about it. The WG can then decide whether we shall fix >> something, and if so, in which specs. >>=20 >> Regards, >>=20 >> Christer >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From:*Schwarz, Albrecht (Albrecht) [albrecht.schwarz@alcatel-lucent.com= ] >> *Sent:* Tuesday, 24 September 2013 4:22 PM >> *To:* Christer Holmberg >> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >> session >>=20 >> Hello Christer, >>=20 >> the "copy & paste" action (across at least three "RFCs") seems to be the >> root cause of the issue :-( >>=20 >> SIP session establishment and L4 security session (DTLS, TLS) >> establishment directions should be principally decoupled because >> application specific. >>=20 >> We got here (wrt DTLS) three (different!) applications: >> 1) Key exchange (RFC 5763) >> 2) Conference control (rfc4582bis) >> 3) Document transmission (udptl-dtls) >>=20 >> All three applications are different in terms of number/type of >> supported network models, security models or/and communication topology. >>=20 >> Consequently, the basic, application independent SDP O/A rules for DTLS >> session establishment would need to support that flexibility. >> The application specific SIP/SDP profile could then still narrow down >> the required SDP O/A rules. >>=20 >> What we got so far: SDP O/A rules in three application specific "RFCs" >> (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( >>=20 >> There might be two options to correct that copy & paste issue in >> "udptl-dtls" in my opinion: >> a) expand the SDP O/A rules for more flexibility >> or >> b) add a WARNING / NOTE about the inherent limitations (due to the >> assumption of a network and communication environment according RFC 5763= ) >>=20 >> What do you think? >> Best regards, >> Albrecht >>=20 >>=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Montag, 23. September 2013 11:54 >> To: Schwarz, Albrecht (Albrecht) >> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sess= ion >>=20 >> Hi Albrecht, >>=20 >> I don't know what model people were focusing on when writing RFC 5763, >> but the RFC does say: >>=20 >> "The endpoint that is the offerer MUST use the setup attribute value of >> setup:actpass" >>=20 >> ...which we also copied into the udptl-dtls draft. >>=20 >> Now, if you want to change that, and allow the Offerer to "force" the >> direction, I think you should start a separate thread about that. >> Because, it is not specific to fax, in my opinion. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> Sent: 23. syyskuuta 2013 12:31 >> To: Christer Holmberg >> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sess= ion >>=20 >> Hello Christer, >>=20 >> the decision about "DTLS session establishment direction" is ALWAYS up >> to the SDP ANSWERER (according present 3.1). >>=20 >> In order to decouple SIP session and DTLS session establishment >> directions, then the SDP OFFERER should also to be able to use >> "setup:active" and "setup:passive" (besides codepoint "setup:actpass") >> in my understanding. >>=20 >> I'm not sure whether the reference to RFC 5763 helps because I could >> imagine that the subject comes down to the indicated network scenarios, >> lets look again at: >> a) T - T >> b) T -GW >>=20 >> The existing udptl-dtls & RFC 5763 text seems to focus on model (a) >> only: SDP O/A between two peering, terminal located SIP UAs (there is >> NOT any SIP B2BUA). >> But I could imagine that the SIP/SDP profiles for "T" and "GW" are not >> necessarily the same in case of model (b): "T" as SDP Offerer may not >> allowed to decide the DTLS session establishment direction, but "GW" as >> SDP offerer may need to enforce the DTLS session establishment direction >> (either way). >>=20 >> Regards, >> Albrecht >>=20 >>=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Donnerstag, 19. September 2013 10:02 >> To: Schwarz, Albrecht (Albrecht) >> Cc: mmusic@ietf.org >> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS sess= ion >>=20 >> Hi Albrecht, >>=20 >> The direction of the SIP session establishment and the DTLS session >> establishment are NOT tightly coupled. The draft enables the Answerer to >> select whether it wants to act as DTLS client or DTLS server. >>=20 >> Section 3.1 states: >>=20 >> .... The >> offerer MUST assign the SDP setup attribute with setup:actpass value, >> and MUST be prepared to receive a DTLS client_hello message before it >> receives the SDP answer. The answerer MUST assign the SDP setup >> attribute with either setup:active value or setup:passive value. The >> answerer SHOULD assign the SDP setup attribute with the setup:active >> value. Whichever party is active MUST initiate a DTLS handshake by >> sending a ClientHello over each flow (host/port quartet). >>=20 >> The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, >> we base the procedure on that RFC. >>=20 >> BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the >> DTLS-SRTP procedures for DTLS server determination. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> Sent: 18. syyskuuta 2013 18:28 >> To: Christer Holmberg >> Cc: mmusic@ietf.org >> Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session >>=20 >> The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a >> gateway, leading to three possible scenarios of >> a) T - T >> b) T -GW >> c) GW-GW >>=20 >> I'd like to scope on scenario (b) due to its asymmetry of user- and >> network-side located T.38 endpoints. >>=20 >> Christer, >> I thought that the two directions of >> 1) SIP session establishment and >> 2) DTLS session establishment >> should be NOT tightly coupled (as currently supposed to be in clause 3.1= )? >> The ietf draft should offer the flexibility in decoupling both >> establishment directions. >>=20 >> E.g., there might be the demand to limit DTLS session establishment in >> T-to-GW direction (and apply rather the reverse direction) due >> ClientHello associated security threats, resource requests in terms of >> memory, ... >>=20 >> In my opinion: >> the IETF should allow the flexibility, >> other SDOs could still profile/limit this capability. >>=20 >> Best regards, >> Albrecht >>=20 >> PS >> We had a similar discussion with TLS, there NAT traversal (NAT-T) >> aspects could influence TLS session establishment direction. However, I >> guess that NAT-T is minor for DTLS/UDP. >>=20 >>=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 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@unify.com Mon Nov 18 03:23:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF811E813F for ; Mon, 18 Nov 2013 03:23:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urapOWYPqB9N for ; Mon, 18 Nov 2013 03:23:39 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 53FB011E8107 for ; Mon, 18 Nov 2013 03:23:39 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id A7F5623F0464; Mon, 18 Nov 2013 12:23:37 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 12:23:37 +0100 From: "Stach, Thomas" To: Martin Thomson , Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//8S6A//okgLA= Date: Mon, 18 Nov 2013 11:23:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 11:23:44 -0000 Inline=20 > On 14 November 2013 10:28, Christer Holmberg > wrote: > > I scanned through 3264, in order to find the sections that need to be > updated. >=20 >=20 > A direct replacement doesn't seem necessary. We aren't issuing a new > 3264. A more direct explanation of what 3264 permits or prohibits and > why this is being changed is probably more important. >=20 > Maybe it's as simple as saying something like: >=20 > RFC 3264 states that m-lines with zero ports are negotiated off. This > document updates RFC 3264 to permit the use of a zero port on m-lines > in combination with the a=3Dbundle-only attribute. [TS] I agree with Martin. An answerer compliant with 3264 and not supporting bundle would ignore a=3D= bundle-only and would set the port=3D0 in its answer. I don't see an issue with an offerer compliant with 3264 and not supporting= bundle, since it wouldn't have included a=3Dbundle-only (and wouldn't incl= ude a larger number of m-lines with port=3D0). The answerer supporting bund= le would have to set port=3D0 in the answer to such an offer in order to co= mply with 3264.=20 In my opinion there isn't any change to the procedures in 3264 for an older= implementation, so this isn't an update to 3264.=20 However, explicit text in bundle that describes this behavior would be just= ified. Regards Thomas > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From internet-drafts@ietf.org Mon Nov 18 06:22:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AED411E8198; Mon, 18 Nov 2013 06:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c021OS3Y7T70; Mon, 18 Nov 2013 06:22:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CD211E81DE; Mon, 18 Nov 2013 06:21:51 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131118142151.18268.3166.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 06:21:51 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 14:22:31 -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-17.txt Pages : 31 Date : 2013-11-18 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-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 18 06:22:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB1C11E81E8; Mon, 18 Nov 2013 06:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS0YJnHVZa5a; Mon, 18 Nov 2013 06:22:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6679211E8133; Mon, 18 Nov 2013 06:22:18 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131118142218.18294.34052.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 06:22:18 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 14:22:41 -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-10.txt Pages : 40 Date : 2013-11-18 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-evaluation-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Nov 18 06:24:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD8811E81C5 for ; Mon, 18 Nov 2013 06:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3Rkbr2Tbht0 for ; Mon, 18 Nov 2013 06:24:25 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C8B3B11E8167 for ; Mon, 18 Nov 2013 06:23:58 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-4f-528a22fd8107 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 92.C2.15980.DF22A825; Mon, 18 Nov 2013 15:23:57 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Mon, 18 Nov 2013 15:23:56 +0100 Message-ID: <528A22FD.2070003@ericsson.com> Date: Mon, 18 Nov 2013 15:23:57 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: References: <20131118142151.18268.3166.idtracker@ietfa.amsl.com> In-Reply-To: <20131118142151.18268.3166.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvre5fpa4gg+N9GhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpLNvgXvhSpm7lvA2sD4hK+LkZNDQsBE4sKpoywQtpjEhXvr 2boYuTiEBA4xSrz785kJwlnOKDH7Sh9QhoODV0Bbov2uM4jJIqAq8e5oAUgvm4CFxM0fjWwg tqhAsMT5V4vZQWxeAUGJkzOfgM0XERCVeHRxESuILSzgLLHo6S6weiEBB4nFt1+B2ZwCjhJT tv1mBhkvISAu0dMYBBJmFtCTmHK1hRHClpdo3jqbGaJVW6KhqYN1AqPgLCTbZiFpmYWkZQEj 8ypG9tzEzJz0cvNNjMDAO7jlt8EOxk33xQ4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBkXd1w7RQ7T9pYaohPVMNkgMYe1dPNl+3PqX4e27n4tZj9ScjLXm3v29J4zb9 nGrT/G7mHqt/UdV3RY5GVDoEKL/4afSCb9k3pYbm0hSTg1wl/FvtbhRuFvxq9MH8g/r15F3B Vs5PmFSP6IlOYJtxZYG6/rzMlX/kMtzclvOcy/92ISe34YG5EktxRqKhFnNRcSIA6yxYugoC AAA= Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 14:24:30 -0000 WG, These are just keep-alive submissions. I hope the WG chair is going to do the publication request soon. Cheers Magnus On 2013-11-18 15:21, 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 : 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-17.txt > Pages : 31 > Date : 2013-11-18 > > 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-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-17 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > > -- 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 magnus.westerlund@ericsson.com Mon Nov 18 06:25:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEA011E8186 for ; Mon, 18 Nov 2013 06:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.034 X-Spam-Level: X-Spam-Status: No, score=-104.034 tagged_above=-999 required=5 tests=[AWL=-1.435, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IobMfSK6PGOs for ; Mon, 18 Nov 2013 06:25:16 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6411E8227 for ; Mon, 18 Nov 2013 06:24:44 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-e9-528a232ba5dc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0B.B9.27941.B232A825; Mon, 18 Nov 2013 15:24:43 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Mon, 18 Nov 2013 15:24:43 +0100 Message-ID: <528A232B.3010102@ericsson.com> Date: Mon, 18 Nov 2013 15:24:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mmusic (E-mail)" References: <20131118142218.18294.34052.idtracker@ietfa.amsl.com> In-Reply-To: <20131118142218.18294.34052.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvra62cleQwdcf2hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtl7VQUNYhVPGnoYGxjPC3YxcnJICJhI/N2/ihHCFpO4cG89 WxcjF4eQwBFGiQdHpzFBOMsZJb4dmgNWxSugLdG7fRILiM0ioCrR8fskG4jNJmAhcfNHI5gt KhAscf7VYnaIekGJkzOfgNWLCKhLtG7uY+1i5OAQFnCVOP7EGyQsJOAosXv1YyYQm1PASaJz 8UmwEgkBcYmexiCQMLOAnsSUqy2MELa8RPPW2cwQrdoSDU0drBMYBWchWTYLScssJC0LGJlX MXIUpxYn5aYbGWxiBAbfwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M9wydLkzbv2/JslWTOiW3HfrXcOGrkmKOfe9pXv0+c7vN3fFpM68UlKQlnT6V Lj4pUnvJkv3r7Btn+XyfuXL+WuMw/bkb9z8JeMrcphUi5/WFM05gQ+5OvUWfxa1i5kR3qFd9 rS9KXnwpwuJr4pW/W34k5p+bKjNHt6nLefaj5XdTuz3v6vncVGIpzkg01GIuKk4EAGbABDwM AgAA Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-evaluation-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 14:25:22 -0000 WG, These are just keep-alive submissions. I hope the WG chair is going to do the publication request soon. Cheers Magnus On 2013-11-18 15:22, 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-10.txt > Pages : 40 > Date : 2013-11-18 > > 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-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 parthasarathi.ravindran@nsn.com Mon Nov 18 08:25:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7222611E813B for ; Mon, 18 Nov 2013 08:25:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mry5sASpRdQk for ; Mon, 18 Nov 2013 08:24:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE4511E8191 for ; Mon, 18 Nov 2013 08:23:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAIGNbdw028158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 17:23:37 +0100 Received: from SGSIHTC003.nsn-intra.net ([10.159.225.20]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAIGNF65003534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 17:23:35 +0100 Received: from SGSIHTC005.nsn-intra.net (10.159.225.22) by SGSIHTC003.nsn-intra.net (10.159.225.20) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Nov 2013 00:23:34 +0800 Received: from SGSIMBX006.nsn-intra.net ([169.254.6.215]) by SGSIHTC005.nsn-intra.net ([10.159.225.22]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 00:23:34 +0800 From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" To: "ext Stach, Thomas" , Martin Thomson , Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//e9WAgAXQsgD//yb3IA== Date: Mon, 18 Nov 2013 16:23:34 +0000 Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2432 X-purgate-ID: 151667::1384791818-00005753-96C2F241/0-0/0-0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 16:25:01 -0000 Hi Thomas, An answerer compliant with 3264 and not supporting bundle would igno= re a=3Dbundle-only and would set the port=3D0 in its answer. The above statement clearly shows how RFC 3264 implementation will break wi= th "bundle-only" attribute proposal. RFC 3264 would have properly negotiate= d in case the port is allocated in the initial offer instead of port 0. Thanks Partha -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext Stach, Thomas Sent: Monday, November 18, 2013 4:54 PM To: Martin Thomson; Christer Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Inline=20 > On 14 November 2013 10:28, Christer Holmberg > wrote: > > I scanned through 3264, in order to find the sections that need to be > updated. >=20 >=20 > A direct replacement doesn't seem necessary. We aren't issuing a new > 3264. A more direct explanation of what 3264 permits or prohibits and > why this is being changed is probably more important. >=20 > Maybe it's as simple as saying something like: >=20 > RFC 3264 states that m-lines with zero ports are negotiated off. This > document updates RFC 3264 to permit the use of a zero port on m-lines > in combination with the a=3Dbundle-only attribute. [TS] I agree with Martin. An answerer compliant with 3264 and not supporting bundle would ignore a=3D= bundle-only and would set the port=3D0 in its answer. I don't see an issue with an offerer compliant with 3264 and not supporting= bundle, since it wouldn't have included a=3Dbundle-only (and wouldn't incl= ude a larger number of m-lines with port=3D0). The answerer supporting bund= le would have to set port=3D0 in the answer to such an offer in order to co= mply with 3264.=20 In my opinion there isn't any change to the procedures in 3264 for an older= implementation, so this isn't an update to 3264.=20 However, explicit text in bundle that describes this behavior would be just= ified. Regards Thomas > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@unify.com Mon Nov 18 08:48:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B52211E81CB for ; Mon, 18 Nov 2013 08:48:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC964PbeiXzZ for ; Mon, 18 Nov 2013 08:48:49 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7E15911E8100 for ; Mon, 18 Nov 2013 08:45:31 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 9DD431EB852D; Mon, 18 Nov 2013 17:45:30 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 17:45:30 +0100 From: "Stach, Thomas" To: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//8S6A//okgLCADAABAP//7XIg Date: Mon, 18 Nov 2013 16:45:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> In-Reply-To: <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 16:48:57 -0000 >=20 > Hi Thomas, >=20 > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. >=20 > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal.=20 [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior.=20 My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1=20 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.= =20 The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.=20 I would regard that as an invalid combination.=20 Regards Thomas >=20 > Thanks > Partha >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update >=20 > Inline >=20 > > On 14 November 2013 10:28, Christer Holmberg > > wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. >=20 >=20 > Regards > Thomas >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon Nov 18 09:20:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E437B11E812D for ; Mon, 18 Nov 2013 09:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE5mDqJW4XmT for ; Mon, 18 Nov 2013 09:20:45 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 541B511E819C for ; Mon, 18 Nov 2013 09:19:50 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-77-528a4c35e948 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F6.F0.27941.53C4A825; Mon, 18 Nov 2013 18:19:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Mon, 18 Nov 2013 18:19:49 +0100 From: Christer Holmberg To: "Stach, Thomas" , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpoqzaoAgABTzwCAAAYggIAAGJHtgAABy1w= Date: Mon, 18 Nov 2013 17:19:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, 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_7594FB04B1934943A5C02806D1A2204B1C53EE54ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3VtfMpyvIYOZeVotrZ/4xWkxd/pjF 4lnrciaLFRsOsFqc3LmN2YHV4+/7D0weO2fdZfdYsuQnk8fP9VfZPbb3PGYJYI3isklJzcks Sy3St0vgyni44ihLwe2wiu5n5g2MX927GDk5JARMJLb3fmWEsMUkLtxbz9bFyMUhJHCEUaLv xjF2kISQwGJGicsPS7sYOTjYBCwkuv9pg4RFBNYxSpxdLw9iMwv4Srz/OR2sXFggXmLlmrmM EDUJEgem3meDsP0kDsz+zQRiswioSuzadY4VxOYF6n10ay8TxN5HTBKPp55nBklwCvhLfNi7 EMxmBDru+6k1TBDLxCVuPZnPBHG0gMSSPRD1EgKiEi8f/2OFsBUldp5tZ4aoz5c4uHoHM8Qy QYmTM5+wTGAUnYVk1CwkZbOQlEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEFSNtcT6tqUsyGoW MHKsYuQoTi1Oyk03MtjECIzTg1t+W+xgvPzX5hCjNAeLkjjvx7fOQUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYZxg5FP+aIlXduiVxjclcgbKvX+NfT5DSWaDzTWbFn4vHiyOD+KQ/RORp iST1pd6bZDf1XYm3V/On8iMRil5/jNydNWZyT65ksTHQPH2OS+xm68uoe4YL065LJsoHX57L vvd8YZZN9h5mZ9XpWfMvtO/X7Fw+5dRS27/r1A22PAs6MSFBJfGoEktxRqKhFnNRcSIAKWfi 7qECAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:20:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C53EE54ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The issue is not whether a 3264 implementation will break or not. The issue is more administrative, and how we are allowed to write standards= in IETF. Currently, 3264 says: 1) Port zero in an Offer means that the stream must not be used; and 2) An Offer with port zero must be answered with port zero As far as I know, we can not simply override that by defining an SDP attrib= ute ('bundle-only'). Unless we can move inside the boundaries set by 3264, = we need to update 3264. Please correct me if I'm wrong, though. I guess some chair/AD input would b= e useful here. IN ANY CASE, I really hope we are not going to spend too much time on this = issue - we have more important things to do. Regards, Christer ________________________________ From: Stach, Thomas [thomas.stach@unify.com] Sent: Monday, 18 November 2013 6:45 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update > > Hi Thomas, > > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. > > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal. [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior. My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer. The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me. I would regard that as an invalid combination. Regards Thomas > > Thanks > Partha > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update > > Inline > > > On 14 November 2013 10:28, Christer Holmberg > > wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. > > > Regards > Thomas > > > _______________________________________________ > > 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_7594FB04B1934943A5C02806D1A2204B1C53EE54ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5260E7A68C4B694C9D3E7C6E4991468C@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

The issue is not whether a 3264 implementation will break or not.

 

The issue is more administrative, and how we are allowed to write standa= rds in IETF.

 

Currently, 3264 says:

 

1) Port zero in an Offer means that the stream must not be use= d; and

2) An Offer with port zero must be answered with port zero

 

As far as I know, we can not simply override that by defining an SDP att= ribute ('bundle-only'). Unless we can move inside the boundaries set by 326= 4, we need to update 3264.

 

Please correct me if I'm wrong, though. I guess some chair/AD input woul= d be useful here.

 

IN ANY CASE, I really hope we are not going to spend too much time on th= is issue - we have more important things to do.

 

Regards,

 

Christer

 

 

From: Stach, Thomas [thomas.stach@unify.com]
Sent: Monday, 18 November 2013 6:45 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; C= hrister Holmberg
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

>
> Hi Thomas,
>
> <snip> An answerer compliant with 3264 and not supporting bundle= would
> ignore a=3Dbundle-only and would set the port=3D0 in its answer. </= snip>
>
> The above statement clearly shows how RFC 3264 implementation will
> break with "bundle-only" attribute proposal.
[TS] I'm not sure what 'break' should mean here. If it means "reject t= he m-line by setting port=3D in the answer", that is the intended beha= vior.
My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1
Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.=
The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line.
> RFC 3264 would have
> properly negotiated in case the port is allocated in the initial offer=
> instead of port 0.
[TS] That is not what a=3Dbundle-only wants to achieve.
The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.
I would regard that as an invalid combination.

Regards
Thomas
>
> Thanks
> Partha
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of ext Stach, Thomas
> Sent: Monday, November 18, 2013 4:54 PM
> To: Martin Thomson; Christer Holmberg
> Cc: mmusic@ietf.org; Paul Kyzivat
> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute = -
> Suggested 3264 update
>
> Inline
>
> > On 14 November 2013 10:28, Christer Holmberg
> > <christer.holmberg@ericsson.com> wrote:
> > > I scanned through 3264, in order to find the sections that n= eed to
> be
> > updated.
> >
> >
> > A direct replacement doesn't seem necessary.  We aren't issu= ing a new
> > 3264.  A more direct explanation of what 3264 permits or pro= hibits
> and
> > why this is being changed is probably more important.
> >
> > Maybe it's as simple as saying something like:
> >
> > RFC 3264 states that m-lines with zero ports are negotiated off.<= br> > This
> > document updates RFC 3264 to permit the use of a zero port on m-l= ines
> > in combination with the a=3Dbundle-only attribute.
> [TS]  I agree with Martin.
> An answerer compliant with 3264 and not supporting bundle would ignore=
> a=3Dbundle-only and would set the port=3D0 in its answer.
> I don't see an issue with an offerer compliant with 3264 and not
> supporting bundle, since it wouldn't have included a=3Dbundle-only (an= d
> wouldn't include a larger number of m-lines with port=3D0). The answer= er
> supporting bundle would have to set port=3D0 in the answer to such an<= br> > offer in order to comply with 3264.
> In my opinion there isn't any change to the procedures in 3264 for an<= br> > older implementation, so this isn't an update to 3264.
> However, explicit text in bundle that describes this behavior would be=
> justified.
>
>
> Regards
> Thomas
>
> > _______________________________________________
> > 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_7594FB04B1934943A5C02806D1A2204B1C53EE54ESESSMB209erics_-- From parthasarathi.ravindran@nsn.com Mon Nov 18 09:24:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F415111E81A8 for ; Mon, 18 Nov 2013 09:24:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSjIZTM0ra1B for ; Mon, 18 Nov 2013 09:24:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8B63E11E81CC for ; Mon, 18 Nov 2013 09:23:06 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAIHN1e7011132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 18:23:02 +0100 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAIHMxNn011930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 18:23:01 +0100 Received: from SGSIMBX006.nsn-intra.net ([169.254.6.215]) by SGSIHTC002.nsn-intra.net ([10.159.225.19]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 01:22:58 +0800 From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" To: "ext Stach, Thomas" , Martin Thomson , Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//e9WAgAXQsgD//yb3IIABMviA//9yteA= Date: Mon, 18 Nov 2013 17:22:58 +0000 Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C92251@SGSIMBX006.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4143 X-purgate-ID: 151667::1384795382-00005753-6D884EFC/0-0/0-0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:24:14 -0000 Hi Thomas, AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the initial offer.= This ensures that the backward compatibility with the existing system as w= ell as provides the bundle negotiation if required. Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within "m" li= ne or not. Thanks Partha -----Original Message----- From: ext Stach, Thomas [mailto:thomas.stach@unify.com]=20 Sent: Monday, November 18, 2013 10:15 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update >=20 > Hi Thomas, >=20 > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. >=20 > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal.=20 [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior.=20 My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1=20 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.= =20 The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.=20 I would regard that as an invalid combination.=20 Regards Thomas >=20 > Thanks > Partha >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update >=20 > Inline >=20 > > On 14 November 2013 10:28, Christer Holmberg > > wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. >=20 >=20 > Regards > Thomas >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Mon Nov 18 09:33:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD011E80E9 for ; Mon, 18 Nov 2013 09:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvXHGqudkP-V for ; Mon, 18 Nov 2013 09:33:05 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BB71511E8178 for ; Mon, 18 Nov 2013 09:31:17 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-7f-528a4ee3347e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 26.40.15980.3EE4A825; Mon, 18 Nov 2013 18:31:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Mon, 18 Nov 2013 18:31:15 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs Thread-Index: Ac7kg/s/Ox1+oezCTIqy8+w+xBQcog== Content-Class: urn:content-classes:message Date: Mon, 18 Nov 2013 17:31:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C53FE70@ESESSMB209.ericsson.se> 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_7594FB04B1934943A5C02806D1A2204B1C53FE70ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre5jv64gg/aTKhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvpbG5gL5kpXrN93gbGB8YxYFyMnh4SAicSlZ2dYIGwxiQv3 1rN1MXJxCAkcYpRo7j/ECuEsZpRo2LKXuYuRg4NNwEKi+582SIOIgLrE1709zCC2sICHxLfL Z5gh4r4Sq/p3sIOUiwjoSWxYngESZhbQktgxYR8jiM0ioCpxactWRpASXqDyv3McQcKMQCd8 P7WGCaJcXOLWk/lMEKcJSCzZc54ZwhaVePn4HyuErSix82w7M0R9vsSTRf/AxvMKCEqcnPmE ZQKj8Cwkm2chGTsLScssJC0QcT2JG1OnsEHY2hLLFr5mhrB1JWb8OwRVYy2xYsEiFmQ1Cxg5 VzGy5yZm5qSXm29iBMbOwS2/DXYwbrovdohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MZ3WW3/fYeLVo6b+3DeytO19KaaceOWadt4Vjc6DZH7OTG1g/6c7b9/yYmKTp 1GM3rU8UPf3Tkdh5WX1nyFbzOZM2V/48wvb808XYdKk70WK3drvtWqWy9KpUCleHqF+XRs7/ yarm7z7KLD8u1PY1+c3Uh14GbSfOz2QVUIn/zZzwf0H6/RvRS5VYijMSDbWYi4oTAVNdWNVr AgAA Subject: [MMUSIC] E164 address type in both RFC 3108 and 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, 18 Nov 2013 17:33:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C53FE70ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, RFC 3108 (SDP for ATM) defines an 'E164' address type value. When used, the= associated address value is "up to 15 decimal digits". Example: c=3DATM E164 9738294382 draft-ietf-mmusic-sdp-cs-21 also defines an 'E164' address type value, with= a slightly different syntax for the associated address value: - an international E.164 number (prepended with a '+' sign); or - the value "-", signifying that the address is unknown Now, the sdp-cs draft DOES say: "Please note that the "E164" address type defined in this memo is exclusively defined to be used in conjunction with the "PSTN" networ= k type in accordance with [RFC4566]. Usage of "E164" address type in conjunction with other network types may be defined elsewhere." ...and, in 3108 the network type value is "ATM", so. I just wonder whether it would be useful to, in sdp-cs, give 3108 as an exa= mple of where "E164" is defined for another network type, and with a differ= ent syntax? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C53FE70ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6901C37D01C19C41A41319B022DAB7CD@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

RFC 3108 (SDP for ATM) defines an 'E164' address type value. When used, = the associated address value is "up to 15 decimal digits".

 

Example: c=3DATM E164 9738294382

draft-ietf-mmusic-sdp-cs-21 also defines an 'E164' address type value, w= ith a slightly different syntax for the associated address value:

 

- an international E.164 number (prepended with a '+' sign); or
- the value "-", signifying that the address is unknown

 

Now, the sdp-cs draft DOES say:

 

        "Please note that t= he "E164" address type defined in this memo is
       exclusively defined to be used in= conjunction with the "PSTN" network
       type in accordance with [RFC4566]= .  Usage of "E164" address type in
       conjunction with other network ty= pes may be defined elsewhere."

 

...and, in 3108 the network type value is "ATM", so.

 

I just wonder whether it would be useful to, in sdp-cs, give 3108 as an = example of where "E164" is defined for another network type, and = with a different syntax?

 

Regards,

 

Christer

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C53FE70ESESSMB209erics_-- From christer.holmberg@ericsson.com Mon Nov 18 09:35:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE45A11E81BA for ; Mon, 18 Nov 2013 09:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiesEm+xh+zj for ; Mon, 18 Nov 2013 09:35:07 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0649E11E8178 for ; Mon, 18 Nov 2013 09:34:23 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-6a-528a4f9efd74 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DA.D2.27941.E9F4A825; Mon, 18 Nov 2013 18:34:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 18 Nov 2013 18:34:22 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , "ext Stach, Thomas" , Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpoqzaoAgABTzwCAAAYggIAACnkAgAATZo2AAACN5Q== Date: Mon, 18 Nov 2013 17:34:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C53FE83@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> , <40AFDF4AF1909E4CB42B6D91CE6C419D19C92251@SGSIMBX006.nsn-intra.net> In-Reply-To: <40AFDF4AF1909E4CB42B6D91CE6C419D19C92251@SGSIMBX006.nsn-intra.net> 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_7594FB04B1934943A5C02806D1A2204B1C53FE83ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Vne+f1eQwd7PnBbXzvxjtJi6/DGL xbPW5UwWKzYcYLU4uXMbswOrx9/3H5g8ds66y+6xZMlPJo+f66+ye2zvecwSwBrFZZOSmpNZ llqkb5fAldE2XbXgQ0zFx/+/mBsYj/p2MXJySAiYSHz7cIMNwhaTuHBvPZDNxSEkcIRR4szp xcwQzmJGiXvTHgM5HBxsAhYS3f+0QeIiApsYJT6f+8kM0s0s4Cvx/ud0dhBbWCBeYuWauYwg tohAgsSBqffZIOwwie27prKC2CwCqhIP9nSzgNi8QL2bT/0CqxESWMEsseSgFojNKRAg8fXb bLA5jEDXfT+1hglil7jErSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtRYufZdqjb8iVeTOpng9gl KHFy5hOWCYyis5CMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dgqqxllh46w8zspoF jByrGDmKU4uTctONDDYxAiP14JbfFjsYL/+1OcQozcGiJM778a1zkJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGG0e33rCo/Sp1SX5nY3OxFwuH2TRNAe0sG4m/OtN/ZKTe1JfsDU2Tr9As eNcguu3g9IVHFUKWPDMN00m+b9D++lNWy1T25XWzzj/dX9jJv36ypETsywvbok5pLCy9mqRj /HnZspcS5txdrGWhN9+sy1z8/BT/B8HgIOvOmnszPp74HP1gu2ikEktxRqKhFnNRcSIALfTk UqICAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:35:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C53FE83ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Partha, Please note that the WG agreed in Vancouver to send bundle-only with port z= ero. The question now is whether/how/if we need to update 3264 based on that agr= eement. Regards, Christer ________________________________ From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [parthasarathi.ravindra= n@nsn.com] Sent: Monday, 18 November 2013 7:22 PM To: ext Stach, Thomas; Martin Thomson; Christer Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi Thomas, AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the initial offer.= This ensures that the backward compatibility with the existing system as w= ell as provides the bundle negotiation if required. Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within "m" li= ne or not. Thanks Partha -----Original Message----- From: ext Stach, Thomas [mailto:thomas.stach@unify.com] Sent: Monday, November 18, 2013 10:15 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update > > Hi Thomas, > > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. > > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal. [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior. My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer. The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me. I would regard that as an invalid combination. Regards Thomas > > Thanks > Partha > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update > > Inline > > > On 14 November 2013 10:28, Christer Holmberg > > wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. > > > Regards > Thomas > > > _______________________________________________ > > 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_7594FB04B1934943A5C02806D1A2204B1C53FE83ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <19664E6AAB598C44BDD10720F4EC5C0F@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi Partha,

 

Please note that the WG agreed in Vancouver to send bundle-only wit= h port zero.

 

The question now is whether/how/if we need to update 3264 based on that = agreement.

 

Regards,

 

Christer

 

From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [parthasarat= hi.ravindran@nsn.com]
Sent: Monday, 18 November 2013 7:22 PM
To: ext Stach, Thomas; Martin Thomson; Christer Holmberg
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

Hi Thomas,

AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the init= ial offer. This ensures that the backward compatibility with the existing system as well as provides the bundle nego= tiation if required.

Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within &q= uot;m" line or not.

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update

>
> Hi Thomas,
>
> <snip> An answerer compliant with 3264 and not supporting bundle= would
> ignore a=3Dbundle-only and would set the port=3D0 in its answer. </= snip>
>
> The above statement clearly shows how RFC 3264 implementation will
> break with "bundle-only" attribute proposal.
[TS] I'm not sure what 'break' should mean here. If it means "reject t= he m-line by setting port=3D in the answer", that is the intended beha= vior.
My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1
Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.=
The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line.
> RFC 3264 would have
> properly negotiated in case the port is allocated in the initial offer=
> instead of port 0.
[TS] That is not what a=3Dbundle-only wants to achieve.
The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.
I would regard that as an invalid combination.

Regards
Thomas
>
> Thanks
> Partha
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of ext Stach, Thomas
> Sent: Monday, November 18, 2013 4:54 PM
> To: Martin Thomson; Christer Holmberg
> Cc: mmusic@ietf.org; Paul Kyzivat
> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute = -
> Suggested 3264 update
>
> Inline
>
> > On 14 November 2013 10:28, Christer Holmberg
> > <christer.holmberg@ericsson.com> wrote:
> > > I scanned through 3264, in order to find the sections that n= eed to
> be
> > updated.
> >
> >
> > A direct replacement doesn't seem necessary.  We aren't issu= ing a new
> > 3264.  A more direct explanation of what 3264 permits or pro= hibits
> and
> > why this is being changed is probably more important.
> >
> > Maybe it's as simple as saying something like:
> >
> > RFC 3264 states that m-lines with zero ports are negotiated off.<= br> > This
> > document updates RFC 3264 to permit the use of a zero port on m-l= ines
> > in combination with the a=3Dbundle-only attribute.
> [TS]  I agree with Martin.
> An answerer compliant with 3264 and not supporting bundle would ignore=
> a=3Dbundle-only and would set the port=3D0 in its answer.
> I don't see an issue with an offerer compliant with 3264 and not
> supporting bundle, since it wouldn't have included a=3Dbundle-only (an= d
> wouldn't include a larger number of m-lines with port=3D0). The answer= er
> supporting bundle would have to set port=3D0 in the answer to such an<= br> > offer in order to comply with 3264.
> In my opinion there isn't any change to the procedures in 3264 for an<= br> > older implementation, so this isn't an update to 3264.
> However, explicit text in bundle that describes this behavior would be=
> justified.
>
>
> Regards
> Thomas
>
> > _______________________________________________
> > 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_7594FB04B1934943A5C02806D1A2204B1C53FE83ESESSMB209erics_-- From parthasarathi.ravindran@nsn.com Mon Nov 18 09:35:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0496311E8200 for ; Mon, 18 Nov 2013 09:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zujqsJ82cOJT for ; Mon, 18 Nov 2013 09:35:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D4D4311E8123 for ; Mon, 18 Nov 2013 09:34:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAIHYXJw031194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 18:34:33 +0100 Received: from SGSIHTC001.nsn-intra.net ([10.159.225.18]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAIHYVgS012400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 18:34:32 +0100 Received: from SGSIMBX006.nsn-intra.net ([169.254.6.215]) by SGSIHTC001.nsn-intra.net ([10.159.225.18]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 01:34:30 +0800 From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" To: ext Christer Holmberg , "Stach, Thomas" , Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//e9WAgAXQsgD//yb3IIABMviAgAAJmID//3b40A== Date: Mon, 18 Nov 2013 17:34:29 +0000 Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C92284@SGSIMBX006.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: multipart/alternative; boundary="_000_40AFDF4AF1909E4CB42B6D91CE6C419D19C92284SGSIMBX006nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19848 X-purgate-ID: 151667::1384796074-00005753-22505CB4/0-0/0-0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:35:36 -0000 --_000_40AFDF4AF1909E4CB42B6D91CE6C419D19C92284SGSIMBX006nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, I agree. We discussed the same earlier in length. In fact, I vaguely remember that there is a proposal from Adam to introduce= new RTP profile name to achieve this functionality without impacting RFC 3= 264. Thanks Partha From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, November 18, 2013 10:50 PM To: Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Th= omson Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi, The issue is not whether a 3264 implementation will break or not. The issue is more administrative, and how we are allowed to write standards= in IETF. Currently, 3264 says: 1) Port zero in an Offer means that the stream must not be used; and 2) An Offer with port zero must be answered with port zero As far as I know, we can not simply override that by defining an SDP attrib= ute ('bundle-only'). Unless we can move inside the boundaries set by 3264, = we need to update 3264. Please correct me if I'm wrong, though. I guess some chair/AD input would b= e useful here. IN ANY CASE, I really hope we are not going to spend too much time on this = issue - we have more important things to do. Regards, Christer ________________________________ From: Stach, Thomas [thomas.stach@unify.com] Sent: Monday, 18 November 2013 6:45 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update > > Hi Thomas, > > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. > > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal. [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior. My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer. The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me. I would regard that as an invalid combination. Regards Thomas > > Thanks > Partha > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmu= sic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update > > Inline > > > On 14 November 2013 10:28, Christer Holmberg > > >= wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. > > > Regards > Thomas > > > _______________________________________________ > > 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_40AFDF4AF1909E4CB42B6D91CE6C419D19C92284SGSIMBX006nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 <= /p>

I agree. We discussed the= same earlier in length.

 <= /p>

In fact, I vaguely rememb= er that there is a proposal from Adam to introduce new RTP profile name to = achieve this functionality without impacting RFC 3264.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: ext Chri= ster Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, November 18, 2013 10:50 PM
To: Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Ma= rtin Thomson
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

 

Hi,

 

The issue is not whether a 3264 implementation w= ill break or not.

 

The issue is more administrative, and how we are= allowed to write standards in IETF.

 

Currently, 3264 says:

 

1) Port zero in an Offer means that the stream&n= bsp;must not be used; and

2) An Offer with port zero must be answered with= port zero

 

As far as I know, we can not simply override tha= t by defining an SDP attribute ('bundle-only'). Unless we can move inside t= he boundaries set by 3264, we need to update 3264.

 

Please correct me if I'm wrong, though. I guess = some chair/AD input would be useful here.

 

IN ANY CASE, I really hope we are not going to s= pend too much time on this issue - we have more important things to do.

 

Regards,

 

Christer

 

 

From: Stach, Thomas [thomas.stach@= unify.com]
Sent: Monday, 18 November 2013 6:45 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; C= hrister Holmberg
Cc: mmusic@ietf.org; Paul Kyz= ivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

>
> Hi Thomas,
>
> <snip> An answerer compliant with 3264 and not supporting bundle= would
> ignore a=3Dbundle-only and would set the port=3D0 in its answer. </= snip>
>
> The above statement clearly shows how RFC 3264 implementation will
> break with "bundle-only" attribute proposal.
[TS] I'm not sure what 'break' should mean here. If it means "reject t= he m-line by setting port=3D in the answer", that is the intended beha= vior.
My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1
Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.=
The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line.
> RFC 3264 would have
> properly negotiated in case the port is allocated in the initial offer=
> instead of port 0.
[TS] That is not what a=3Dbundle-only wants to achieve.
The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.
I would regard that as an invalid combination.

Regards
Thomas
>
> Thanks
> Partha
>
> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto= :mmusic-bounces@ietf.org] On
> Behalf Of ext Stach, Thomas
> Sent: Monday, November 18, 2013 4:54 PM
> To: Martin Thomson; Christer Holmberg
> Cc: mmusic@ietf.org; Paul Kyziv= at
> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute = -
> Suggested 3264 update
>
> Inline
>
> > On 14 November 2013 10:28, Christer Holmberg
> > <christer.ho= lmberg@ericsson.com> wrote:
> > > I scanned through 3264, in order to find the sections that n= eed to
> be
> > updated.
> >
> >
> > A direct replacement doesn't seem necessary.  We aren't issu= ing a new
> > 3264.  A more direct explanation of what 3264 permits or pro= hibits
> and
> > why this is being changed is probably more important.
> >
> > Maybe it's as simple as saying something like:
> >
> > RFC 3264 states that m-lines with zero ports are negotiated off.<= br> > This
> > document updates RFC 3264 to permit the use of a zero port on m-l= ines
> > in combination with the a=3Dbundle-only attribute.
> [TS]  I agree with Martin.
> An answerer compliant with 3264 and not supporting bundle would ignore=
> a=3Dbundle-only and would set the port=3D0 in its answer.
> I don't see an issue with an offerer compliant with 3264 and not
> supporting bundle, since it wouldn't have included a=3Dbundle-only (an= d
> wouldn't include a larger number of m-lines with port=3D0). The answer= er
> supporting bundle would have to set port=3D0 in the answer to such an<= br> > offer in order to comply with 3264.
> In my opinion there isn't any change to the procedures in 3264 for an<= br> > older implementation, so this isn't an update to 3264.
> However, explicit text in bundle that describes this behavior would be=
> justified.
>
>
> Regards
> Thomas
>
> > _______________________________________________
> > 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_40AFDF4AF1909E4CB42B6D91CE6C419D19C92284SGSIMBX006nsnin_-- From parthasarathi.ravindran@nsn.com Mon Nov 18 09:47:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA611E8292 for ; Mon, 18 Nov 2013 09:47:25 -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.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRFarT7G8yhs for ; Mon, 18 Nov 2013 09:47:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A938A11E81EB for ; Mon, 18 Nov 2013 09:39:22 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAIHdFbH006388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 18:39:15 +0100 Received: from SGSIHTC003.nsn-intra.net ([10.159.225.20]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAIHdCJA026577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 18:39:13 +0100 Received: from SGSIHTC005.nsn-intra.net (10.159.225.22) by SGSIHTC003.nsn-intra.net (10.159.225.20) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Nov 2013 01:39:11 +0800 Received: from SGSIMBX006.nsn-intra.net ([169.254.6.215]) by SGSIHTC005.nsn-intra.net ([10.159.225.22]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 01:39:11 +0800 From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" To: ext Christer Holmberg , "ext Stach, Thomas" , Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//e9WAgAXQsgD//yb3IIABMviA//9yteCAAJrzAP//eQ+w Date: Mon, 18 Nov 2013 17:39:11 +0000 Message-ID: <40AFDF4AF1909E4CB42B6D91CE6C419D19C923FD@SGSIMBX006.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> , <40AFDF4AF1909E4CB42B6D91CE6C419D19C92251@SGSIMBX006.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C53FE83@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C53FE83@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: multipart/alternative; boundary="_000_40AFDF4AF1909E4CB42B6D91CE6C419D19C923FDSGSIMBX006nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 18716 X-purgate-ID: 151667::1384796355-00005753-A405C453/0-0/0-0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:47:26 -0000 --_000_40AFDF4AF1909E4CB42B6D91CE6C419D19C923FDSGSIMBX006nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for the update. The new RTP profile (like BSAVPF) proposal looks muc= h cleaner solution. Thanks Partha From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, November 18, 2013 11:04 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Stach, Thomas; Marti= n Thomson Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi Partha, Please note that the WG agreed in Vancouver to send bundle-only with port z= ero. The question now is whether/how/if we need to update 3264 based on that agr= eement. Regards, Christer ________________________________ From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [parthasarathi.ravindra= n@nsn.com] Sent: Monday, 18 November 2013 7:22 PM To: ext Stach, Thomas; Martin Thomson; Christer Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi Thomas, AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the initial offer.= This ensures that the backward compatibility with the existing system as w= ell as provides the bundle negotiation if required. Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within "m" li= ne or not. Thanks Partha -----Original Message----- From: ext Stach, Thomas [mailto:thomas.stach@unify.com] Sent: Monday, November 18, 2013 10:15 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update > > Hi Thomas, > > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. > > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal. [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior. My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer. The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me. I would regard that as an invalid combination. Regards Thomas > > Thanks > Partha > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmu= sic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update > > Inline > > > On 14 November 2013 10:28, Christer Holmberg > > >= wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. > > > Regards > Thomas > > > _______________________________________________ > > 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_40AFDF4AF1909E4CB42B6D91CE6C419D19C923FDSGSIMBX006nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 <= /p>

Thanks for the update. Th= e new RTP profile (like BSAVPF) proposal looks much cleaner solution.<= /o:p>

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: ext Chri= ster Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, November 18, 2013 11:04 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Stach, Thomas= ; Martin Thomson
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

 

Hi Partha,

 

Please note that the WG agreed in Vancouver= to send bundle-only with port zero.

 

The question now is whether/how/if we need to up= date 3264 based on that agreement.

 

Regards,

 

Christer

 

From: Ravindran, Parthasarathi (NS= N - IN/Bangalore) [parthasarathi.ravindran@nsn.com]
Sent: Monday, 18 November 2013 7:22 PM
To: ext Stach, Thomas; Martin Thomson; Christer Holmberg
Cc: mmusic@ietf.org; Paul Kyz= ivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

Hi Thomas,

AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the init= ial offer. This ensures that the backward compatibility with the existing system as well as provides the bundle nego= tiation if required.

Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within &q= uot;m" line or not.

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg
Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update

>
> Hi Thomas,
>
> <snip> An answerer compliant with 3264 and not supporting bundle= would
> ignore a=3Dbundle-only and would set the port=3D0 in its answer. </= snip>
>
> The above statement clearly shows how RFC 3264 implementation will
> break with "bundle-only" attribute proposal.
[TS] I'm not sure what 'break' should mean here. If it means "reject t= he m-line by setting port=3D in the answer", that is the intended beha= vior.
My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1
Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.=
The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line.
> RFC 3264 would have
> properly negotiated in case the port is allocated in the initial offer=
> instead of port 0.
[TS] That is not what a=3Dbundle-only wants to achieve.
The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.
I would regard that as an invalid combination.

Regards
Thomas
>
> Thanks
> Partha
>
> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto= :mmusic-bounces@ietf.org] On
> Behalf Of ext Stach, Thomas
> Sent: Monday, November 18, 2013 4:54 PM
> To: Martin Thomson; Christer Holmberg
> Cc: mmusic@ietf.org; Paul Kyziv= at
> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute = -
> Suggested 3264 update
>
> Inline
>
> > On 14 November 2013 10:28, Christer Holmberg
> > <christer.ho= lmberg@ericsson.com> wrote:
> > > I scanned through 3264, in order to find the sections that n= eed to
> be
> > updated.
> >
> >
> > A direct replacement doesn't seem necessary.  We aren't issu= ing a new
> > 3264.  A more direct explanation of what 3264 permits or pro= hibits
> and
> > why this is being changed is probably more important.
> >
> > Maybe it's as simple as saying something like:
> >
> > RFC 3264 states that m-lines with zero ports are negotiated off.<= br> > This
> > document updates RFC 3264 to permit the use of a zero port on m-l= ines
> > in combination with the a=3Dbundle-only attribute.
> [TS]  I agree with Martin.
> An answerer compliant with 3264 and not supporting bundle would ignore=
> a=3Dbundle-only and would set the port=3D0 in its answer.
> I don't see an issue with an offerer compliant with 3264 and not
> supporting bundle, since it wouldn't have included a=3Dbundle-only (an= d
> wouldn't include a larger number of m-lines with port=3D0). The answer= er
> supporting bundle would have to set port=3D0 in the answer to such an<= br> > offer in order to comply with 3264.
> In my opinion there isn't any change to the procedures in 3264 for an<= br> > older implementation, so this isn't an update to 3264.
> However, explicit text in bundle that describes this behavior would be=
> justified.
>
>
> Regards
> Thomas
>
> > _______________________________________________
> > 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_40AFDF4AF1909E4CB42B6D91CE6C419D19C923FDSGSIMBX006nsnin_-- From christer.holmberg@ericsson.com Mon Nov 18 09:52:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20F711E8152 for ; Mon, 18 Nov 2013 09:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=1.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoHnUmsM0ZNW for ; Mon, 18 Nov 2013 09:52:10 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ED87B11E81A4 for ; Mon, 18 Nov 2013 09:46:08 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-b4-528a524749cb Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 68.81.15980.7425A825; Mon, 18 Nov 2013 18:45:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Mon, 18 Nov 2013 18:45:43 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , "ext Stach, Thomas" , Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpoqzaoAgABTzwCAAAYggIAACnkAgAATZo2AAACN5f//8JWAgAASVy2AAABAaA== Date: Mon, 18 Nov 2013 17:45:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C53FEE5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> , <40AFDF4AF1909E4CB42B6D91CE6C419D19C92251@SGSIMBX006.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C53FE83@ESESSMB209.ericsson.se>, <40AFDF4AF1909E4CB42B6D91CE6C419D19C923FD@SGSIMBX006.nsn-intra.net> In-Reply-To: <40AFDF4AF1909E4CB42B6D91CE6C419D19C923FD@SGSIMBX006.nsn-intra.net> 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_7594FB04B1934943A5C02806D1A2204B1C53FEE5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvra57UFeQwbOFqhbXzvxjtJi6/DGL xbPW5UwWKzYcYLU4uXMbswOrx9/3H5g8ds66y+6xZMlPJo+f66+ye2zvecwSwBrFZZOSmpNZ llqkb5fAlTFlxgmWgiNzGStePpzC1sB4po2xi5GDQ0LARKJjGkcXIyeQKSZx4d56ti5GLg4h gUOMEr+ezGGHcBYzSnw+cJYJpIFNwEKi+582SFxEYBNQ/NxPZpBuZgFfifc/p7OD2MIC8RIr 18xlBLFFBBIkDky9zwZhZ0m0d81gBbFZBFQlnj/sZQKxeYF6/+xbxQKxbAOLxIqfs8GaOQUC JJZd/QbWzAh03vdTa5gglolL3HoynwnibAGJJXvOM0PYohIvH/9jhbAVJXaebYc6Ll+i5cF3 FohlghInZz5hmcAoOgvJqFlIymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIaAaDiDbWmLl eylkJQsYOVYxsucmZuakl5tvYgTG6sEtvw12MG66L3aIUZqDRUmc98Nb5yAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjNUTAj/7/0r4u/r/qcurEio+hRjNM1jrfqlfz+jUzKuhPtsEL2ka XHMP5yzWDp4cM0H0/OyZRRKSB2ZaP8uexJZis+PPFo+k5WuC11ptWfhSu1TC7ol7+5Ws/cF1 eq081i6vZdufFDZ5CXw7cN9YP6E1fuuCrujQhj6tb/sNi5xDJ8spLjtpqcRSnJFoqMVcVJwI ADwUniSjAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2013 17:52:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C53FEE5ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And how would that work with non-RTP media? Regards, Christer ________________________________ From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [parthasarathi.ravindra= n@nsn.com] Sent: Monday, 18 November 2013 7:39 PM To: Christer Holmberg; ext Stach, Thomas; Martin Thomson Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi Christer, Thanks for the update. The new RTP profile (like BSAVPF) proposal looks muc= h cleaner solution. Thanks Partha From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, November 18, 2013 11:04 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Stach, Thomas; Marti= n Thomson Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi Partha, Please note that the WG agreed in Vancouver to send bundle-only with port z= ero. The question now is whether/how/if we need to update 3264 based on that agr= eement. Regards, Christer ________________________________ From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [parthasarathi.ravindra= n@nsn.com] Sent: Monday, 18 November 2013 7:22 PM To: ext Stach, Thomas; Martin Thomson; Christer Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update Hi Thomas, AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the initial offer.= This ensures that the backward compatibility with the existing system as w= ell as provides the bundle negotiation if required. Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within "m" li= ne or not. Thanks Partha -----Original Message----- From: ext Stach, Thomas [mailto:thomas.stach@unify.com] Sent: Monday, November 18, 2013 10:15 PM To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg Cc: mmusic@ietf.org; Paul Kyzivat Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update > > Hi Thomas, > > An answerer compliant with 3264 and not supporting bundle would > ignore a=3Dbundle-only and would set the port=3D0 in its answer. > > The above statement clearly shows how RFC 3264 implementation will > break with "bundle-only" attribute proposal. [TS] I'm not sure what 'break' should mean here. If it means "reject the m-= line by setting port=3D in the answer", that is the intended behavior. My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-uni= fied-plan-00#section-3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer. The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line. > RFC 3264 would have > properly negotiated in case the port is allocated in the initial offer > instead of port 0. [TS] That is not what a=3Dbundle-only wants to achieve. The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me. I would regard that as an invalid combination. Regards Thomas > > Thanks > Partha > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmu= sic-bounces@ietf.org] On > Behalf Of ext Stach, Thomas > Sent: Monday, November 18, 2013 4:54 PM > To: Martin Thomson; Christer Holmberg > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update > > Inline > > > On 14 November 2013 10:28, Christer Holmberg > > >= wrote: > > > I scanned through 3264, in order to find the sections that need to > be > > updated. > > > > > > A direct replacement doesn't seem necessary. We aren't issuing a new > > 3264. A more direct explanation of what 3264 permits or prohibits > and > > why this is being changed is probably more important. > > > > Maybe it's as simple as saying something like: > > > > RFC 3264 states that m-lines with zero ports are negotiated off. > This > > document updates RFC 3264 to permit the use of a zero port on m-lines > > in combination with the a=3Dbundle-only attribute. > [TS] I agree with Martin. > An answerer compliant with 3264 and not supporting bundle would ignore > a=3Dbundle-only and would set the port=3D0 in its answer. > I don't see an issue with an offerer compliant with 3264 and not > supporting bundle, since it wouldn't have included a=3Dbundle-only (and > wouldn't include a larger number of m-lines with port=3D0). The answerer > supporting bundle would have to set port=3D0 in the answer to such an > offer in order to comply with 3264. > In my opinion there isn't any change to the procedures in 3264 for an > older implementation, so this isn't an update to 3264. > However, explicit text in bundle that describes this behavior would be > justified. > > > Regards > Thomas > > > _______________________________________________ > > 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_7594FB04B1934943A5C02806D1A2204B1C53FEE5ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6BEEF954835BD546B6E93AD173CD19B4@ericsson.com> Content-Transfer-Encoding: quoted-printable

And how would that work with non-RTP media?

 

Regards,

 

Christer

 

From: Ravindran, Parthasarathi (NSN - IN/= Bangalore) [parthasarathi.ravindran@nsn.com]
Sent: Monday, 18 November 2013 7:39 PM
To: Christer Holmberg; ext Stach, Thomas; Martin Thomson
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

Hi Christer,=

 

Thanks for t= he update. The new RTP profile (like BSAVPF) proposal looks much cleaner so= lution.

 

Thanks

Partha

 

From: ext = Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, November 18, 2013 11:04 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Stach, Thomas= ; Martin Thomson
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

 

Hi Partha,

 

Please note that the WG agreed in Vanco= uver to send bundle-only with port zero.

 

The question now is whether/how/if we need t= o update 3264 based on that agreement.

 

Regards,

 

Christer

 

From: Ravindran, Parthasar= athi (NSN - IN/Bangalore) [parthasarathi.ravindran@nsn.com]
Sent: Monday, 18 November 2013 7:22 PM
To: ext Stach, Thomas; Martin Thomson; Christer Holmberg
Cc: mmusic@ietf= .org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribut= e - Suggested 3264 update

Hi Thomas,

AFAIK, it was agreed that the offer will not have bundle port until otherwi= se, it is known that the remote peer supports BUNDLE. In that scenario, I p= refer to send some actual port with "bundle-only" during the init= ial offer. This ensures that the backward compatibility with the existing system as well as provides the bundle nego= tiation if required.

Also, Could you please confirm as per your understanding of offer m line wi= th port 0 & a=3Dbundle-only whether any ICE candidates exists within &q= uot;m" line or not.

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer= Holmberg
Cc: mmusic@ietf.org; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update

>
> Hi Thomas,
>
> <snip> An answerer compliant with 3264 and not supporting bundle= would
> ignore a=3Dbundle-only and would set the port=3D0 in its answer. </= snip>
>
> The above statement clearly shows how RFC 3264 implementation will
> break with "bundle-only" attribute proposal.
[TS] I'm not sure what 'break' should mean here. If it means "reject t= he m-line by setting port=3D in the answer", that is the intended beha= vior.
My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1
Here, the a=3Dbundle-only attribute is combined with port=3D0 in the offer.=
The port=3D0 in the offer should guarantee that an answerer does not use th= e m-line.
> RFC 3264 would have
> properly negotiated in case the port is allocated in the initial offer=
> instead of port 0.
[TS] That is not what a=3Dbundle-only wants to achieve.
The semantics of using a valid port in the offer together with a=3Dbundle-o= nly are not clear to me.
I would regard that as an invalid combination.

Regards
Thomas
>
> Thanks
> Partha
>
> -----Original Message-----
> From: mmu= sic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of ext Stach, Thomas
> Sent: Monday, November 18, 2013 4:54 PM
> To: Martin Thomson; Christer Holmberg
> Cc: mmusic@ietf.o= rg; Paul Kyzivat
> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute = -
> Suggested 3264 update
>
> Inline
>
> > On 14 November 2013 10:28, Christer Holmberg
> > <christer.holmberg@ericsson.com> wrote:
> > > I scanned through 3264, in order to find the sections that n= eed to
> be
> > updated.
> >
> >
> > A direct replacement doesn't seem necessary.  We aren't issu= ing a new
> > 3264.  A more direct explanation of what 3264 permits or pro= hibits
> and
> > why this is being changed is probably more important.
> >
> > Maybe it's as simple as saying something like:
> >
> > RFC 3264 states that m-lines with zero ports are negotiated off.<= br> > This
> > document updates RFC 3264 to permit the use of a zero port on m-l= ines
> > in combination with the a=3Dbundle-only attribute.
> [TS]  I agree with Martin.
> An answerer compliant with 3264 and not supporting bundle would ignore=
> a=3Dbundle-only and would set the port=3D0 in its answer.
> I don't see an issue with an offerer compliant with 3264 and not
> supporting bundle, since it wouldn't have included a=3Dbundle-only (an= d
> wouldn't include a larger number of m-lines with port=3D0). The answer= er
> supporting bundle would have to set port=3D0 in the answer to such an<= br> > offer in order to comply with 3264.
> In my opinion there isn't any change to the procedures in 3264 for an<= br> > older implementation, so this isn't an update to 3264.
> However, explicit text in bundle that describes this behavior would be=
> justified.
>
>
> Regards
> Thomas
>
> > _______________________________________________
> > 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_7594FB04B1934943A5C02806D1A2204B1C53FEE5ESESSMB209erics_-- From pkyzivat@alum.mit.edu Mon Nov 18 10:28:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC171A1F43 for ; Mon, 18 Nov 2013 10:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.972] autolearn=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3SyAScadaqq for ; Mon, 18 Nov 2013 10:28:41 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 1013B1A1F42 for ; Mon, 18 Nov 2013 10:28:36 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id r5Zw1m0030cZkys5B67nDP; Mon, 18 Nov 2013 18:07:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id r67m1m00x3ZTu2S3W67nwE; Mon, 18 Nov 2013 18:07:47 +0000 Message-ID: <528A5772.3050005@alum.mit.edu> Date: Mon, 18 Nov 2013 10:07:46 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "Stach, Thomas" , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> 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=1384798067; bh=44w+zqRfiBXy9tjucHXoxwLIdY+zf1nZrk5yiXMulyg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sMbbVANE2h/8aHrjWIOH/kOt430zpLf3Wdavqj5PaGI62AOqWYTQicAeTxOmUJV4l WAJ8kLxaD0d8UQdRAeWI/WEOjtZE0yaPikfYLyPXrXUZpuRjiZah4pj318pFOdKib+ CDd0rXbUI2QMHQM4N542KQ393Wi1OEddFxw3nBzbNkMGUqpgS5frCv2dGpeW5DrvUB k2avNZUnQLa/HUPG9ypkNM1dwqmKHrfM2a/yPb1RnastU5tWfBApSUWJ0ZtE8i3DIn LHmmtAY9Zm+I231/y+B9npnBv8/VlE6dlacJwaq/ZBAq4C8SY5+b+2S8hNbFZ67u1H HQOO2MNBAmQ6g== Cc: "mmusic@ietf.org" Subject: [MMUSIC] ***UNCHECKED*** Re: BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2013 18:28:43 -0000 On 11/18/13 9:19 AM, Christer Holmberg wrote: > Hi, > > The issue is not whether a 3264 implementation will break or not. > > The issue is more administrative, and how we are allowed to write > standards in IETF. > > Currently, 3264 says: > > 1) Port zero in an Offer means that the stream must not be used; and > > 2) An Offer with port zero must be answered with port zero > > As far as I know, we can not simply override that by defining an SDP > attribute ('bundle-only'). Unless we can move inside the boundaries set > by 3264, we need to update 3264. > > Please correct me if I'm wrong, though. I guess some chair/AD input > would be useful here. I queried Adam for his opinion so we could have unanimity among chairs, but I haven't heard back from him. I agree with Martin, that we need to formally declare that we are updating 3264, but that we don't have to provide an explicit delta to 3264 to do so. > IN ANY CASE, I really hope we are not going to spend too much time on > this issue - we have more important things to do. Agree. Thanks, Paul > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* Stach, Thomas [thomas.stach@unify.com] > *Sent:* Monday, 18 November 2013 6:45 PM > *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; > Christer Holmberg > *Cc:* mmusic@ietf.org; Paul Kyzivat > *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute > - Suggested 3264 update > >> >> Hi Thomas, >> >> An answerer compliant with 3264 and not supporting bundle would >> ignore a=bundle-only and would set the port=0 in its answer. >> >> The above statement clearly shows how RFC 3264 implementation will >> break with "bundle-only" attribute proposal. > [TS] I'm not sure what 'break' should mean here. If it means "reject the > m-line by setting port= in the answer", that is the intended behavior. > My statement was based on > http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1 > Here, the a=bundle-only attribute is combined with port=0 in the offer. > The port=0 in the offer should guarantee that an answerer does not use > the m-line. >> RFC 3264 would have >> properly negotiated in case the port is allocated in the initial offer >> instead of port 0. > [TS] That is not what a=bundle-only wants to achieve. > The semantics of using a valid port in the offer together with > a=bundle-only are not clear to me. > I would regard that as an invalid combination. > > Regards > Thomas >> >> Thanks >> Partha >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of ext Stach, Thomas >> Sent: Monday, November 18, 2013 4:54 PM >> To: Martin Thomson; Christer Holmberg >> Cc: mmusic@ietf.org; Paul Kyzivat >> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - >> Suggested 3264 update >> >> Inline >> >> > On 14 November 2013 10:28, Christer Holmberg >> > wrote: >> > > I scanned through 3264, in order to find the sections that need to >> be >> > updated. >> > >> > >> > A direct replacement doesn't seem necessary. We aren't issuing a new >> > 3264. A more direct explanation of what 3264 permits or prohibits >> and >> > why this is being changed is probably more important. >> > >> > Maybe it's as simple as saying something like: >> > >> > RFC 3264 states that m-lines with zero ports are negotiated off. >> This >> > document updates RFC 3264 to permit the use of a zero port on m-lines >> > in combination with the a=bundle-only attribute. >> [TS] I agree with Martin. >> An answerer compliant with 3264 and not supporting bundle would ignore >> a=bundle-only and would set the port=0 in its answer. >> I don't see an issue with an offerer compliant with 3264 and not >> supporting bundle, since it wouldn't have included a=bundle-only (and >> wouldn't include a larger number of m-lines with port=0). The answerer >> supporting bundle would have to set port=0 in the answer to such an >> offer in order to comply with 3264. >> In my opinion there isn't any change to the procedures in 3264 for an >> older implementation, so this isn't an update to 3264. >> However, explicit text in bundle that describes this behavior would be >> justified. >> >> >> Regards >> Thomas >> >> > _______________________________________________ >> > 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 Mon Nov 18 10:38:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67FD1A1F4B for ; Mon, 18 Nov 2013 10:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.972] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUpWpNNbotWL for ; Mon, 18 Nov 2013 10:38:47 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id BC46F1A1F48 for ; Mon, 18 Nov 2013 10:38:46 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id r0mv1m00816LCl05D6HwQp; Mon, 18 Nov 2013 18:17:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id r6Hw1m00S3ZTu2S3S6HwUX; Mon, 18 Nov 2013 18:17:56 +0000 Message-ID: <528A59D4.9040504@alum.mit.edu> Date: Mon, 18 Nov 2013 10:17:56 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C53FE70@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C53FE70@ESESSMB209.ericsson.se> 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=1384798676; bh=VSk9oU659fMe1A6/AOHKTDQBS9gPzwYZi/43GCnGN5I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QZ8qEccplxanjxig49f3tt5OdypK8i2fdqD4uY+dXAY+/9Q0uTF1dxABrCrsvGKkF 2WfjcGEsDy5UagfjQWdAELZow2KKFd572F3cTWIDocyiU3IMGMSm3XBg28+S3I1nqg SHTdDXnRx2hH8WYc4wncGIxYBGt9yZpTYgU+ake+tHE4m+41PH9bhFi3qru1nLZOIl W46rcW5H27xjEEMq13fU9K1+r4sdS5j8q0f9hQpIiMAzs5T9hKnp3P5fkpyzNxTK+n WCVkGRLIyI6Uf6axrE6fl70QU/fCwpt9uzZyqIfpxms05EGvJCXvGxN6IVXY9CzDEw PIYZSOZItXs7A== Subject: Re: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2013 18:38:48 -0000 On 11/18/13 9:31 AM, Christer Holmberg wrote: > Hi, > > RFC 3108 (SDP for ATM) defines an 'E164' address type value. When used, > the associated address value is "up to 15 decimal digits". > > Example: c=ATM E164 9738294382 > > draft-ietf-mmusic-sdp-cs-21 also defines an 'E164' address type value, > with a slightly different syntax for the associated address value: > > - an international E.164 number (prepended with a '+' sign); or > - the value "-", signifying that the address is unknown > > Now, the sdp-cs draft DOES say: > > "Please note that the "E164" address type defined in this memo is > exclusively defined to be used in conjunction with the "PSTN" > network > type in accordance with [RFC4566]. Usage of "E164" address type in > conjunction with other network types may be defined elsewhere." > > ...and, in 3108 the network type value is "ATM", so. > > I just wonder whether it would be useful to, in sdp-cs, give 3108 as an > example of where "E164" is defined for another network type, and with a > different syntax? I wouldn't object, but neither do I find it necessary to do this. I wasn't aware of 3108 when it was being standardized. I find its use of "E164" perverted, since it explicitly allows non-E164 values to be used, and doesn't even define how such numbers are to be interpreted. It should have used something other than "E164". But I guess it is too late to "fix" that. Thanks, Paul From Christian.Groves@nteczone.com Mon Nov 18 15:26:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886251AE652 for ; Mon, 18 Nov 2013 15:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.435 X-Spam-Level: *** X-Spam-Status: No, score=3.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfeF0PEXB_vp for ; Mon, 18 Nov 2013 15:26:54 -0800 (PST) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5B81AE6B1 for ; Mon, 18 Nov 2013 15:26:53 -0800 (PST) Received: from ppp118-209-127-154.lns20.mel4.internode.on.net ([118.209.127.154]:52147 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1ViYAy-0005kn-BG for mmusic@ietf.org; Tue, 19 Nov 2013 10:24:16 +1100 Message-ID: <528AA233.1030005@nteczone.com> Date: Tue, 19 Nov 2013 10:26:43 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C53FE70@ESESSMB209.ericsson.se> <528A59D4.9040504@alum.mit.edu> In-Reply-To: <528A59D4.9040504@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2013 23:26:55 -0000 Hello Christer, I think the last sentence: /"Usage of "E164" address type in conjunction with other network types may be defined elsewhere."/ could potentially be confusing. I think this sentence is referring to that the E164 address defined by [SDP-CS] could be used elsewhere. Whereas the RFC3105 usage of E164 is distinct from [SDP-CS]. I think that after our discussion regarding the IANA registration its clear that Address type is dependent on Network Type. So I would be included to remove the above sentence and just indicate that E164 defined by [SDP-CS] is used exclusively for nettype PSTN. You could add a note to the effect: "Note: RFC3105 also defines address type E164. This definition is distinct from the one defined by [SDP-CS] and shall not be used with nettype PSTN." Regards, Christian On 19/11/2013 5:17 AM, Paul Kyzivat wrote: > On 11/18/13 9:31 AM, Christer Holmberg wrote: >> Hi, >> >> RFC 3108 (SDP for ATM) defines an 'E164' address type value. When used, >> the associated address value is "up to 15 decimal digits". >> >> Example: c=ATM E164 9738294382 >> >> draft-ietf-mmusic-sdp-cs-21 also defines an 'E164' address type value, >> with a slightly different syntax for the associated address value: >> >> - an international E.164 number (prepended with a '+' sign); or >> - the value "-", signifying that the address is unknown >> >> Now, the sdp-cs draft DOES say: >> >> "Please note that the "E164" address type defined in this >> memo is >> exclusively defined to be used in conjunction with the "PSTN" >> network >> type in accordance with [RFC4566]. Usage of "E164" address >> type in >> conjunction with other network types may be defined elsewhere." >> >> ...and, in 3108 the network type value is "ATM", so. >> >> I just wonder whether it would be useful to, in sdp-cs, give 3108 as an >> example of where "E164" is defined for another network type, and with a >> different syntax? > > I wouldn't object, but neither do I find it necessary to do this. > > I wasn't aware of 3108 when it was being standardized. I find its use > of "E164" perverted, since it explicitly allows non-E164 values to be > used, and doesn't even define how such numbers are to be interpreted. > > It should have used something other than "E164". But I guess it is too > late to "fix" that. > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Mon Nov 18 23:25:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32B41AC441 for ; Mon, 18 Nov 2013 23:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FbKpibF3Mx6 for ; Mon, 18 Nov 2013 23:25:05 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9715A1AC404 for ; Mon, 18 Nov 2013 23:25:04 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-ad-528b1249b6ea Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 26.B7.23787.9421B825; Tue, 19 Nov 2013 08:24:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 19 Nov 2013 08:24:57 +0100 From: Christer Holmberg To: Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs Thread-Index: AQHO5JDoFWgTp7ouhUKZy3qr7DyTKporkWKAgACWPwA= Date: Tue, 19 Nov 2013 07:24:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C541615@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C53FE70@ESESSMB209.ericsson.se> <528A59D4.9040504@alum.mit.edu> <528AA233.1030005@nteczone.com> In-Reply-To: <528AA233.1030005@nteczone.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+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvra6XUHeQwb3N7BZf3jeyWExd/pjF gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mp4OmkbY8E0iYqXX1YzNjAuF+5i5OSQEDCR uL/gKROELSZx4d56ti5GLg4hgUOMEt1LV7NCOIsZJU7tbWfuYuTgYBOwkOj+pw3SICIQLTFp YTMbiC0sEC5x4l0PG0Q8QmLezz3MELaVxOe/D8DiLAKqErsPrmUCGcMr4Cvx/3QyxPh+Ronf 21aDHcEpoCMxqekrO4jNCHTQ91NrwOLMAuISt57MhzpUQGLJnvPMELaoxMvH/1ghbEWJj6/2 MULU60gs2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMn vdxwEyMwFg5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YLRpWj2DP8xh/U97mxwdk7QFnRGPKtLVe5hP7LgdLxEm/Hiiz4Uedbbibfc2zDZLSBAI3fM9 aKtIQtb3nw6+H+bvemigHz0t88Dsu4FLO74+3M04db2u7eJkQ34taZHP9Wva7I7+1rzJKXie zUXt3Gmd/z98tEIPFv2qNmLfa79E1k1y+8nVDEosxRmJhlrMRcWJAFDMQwVTAgAA Subject: Re: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 07:25:06 -0000 Hi Christian, I think your suggestion looks good. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: 19. marraskuuta 2013 1:27 To: mmusic@ietf.org Subject: Re: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmu= sic-sdp-cs Hello Christer, I think the last sentence: /"Usage of "E164" address type in conjunction wi= th other network types may be defined elsewhere."/ could potentially be con= fusing. I think this sentence is referring to that the E164 address defined= by [SDP-CS] could be used elsewhere. Whereas the RFC3105 usage of E164 is = distinct from [SDP-CS]. I think that after our discussion regarding the IANA registration its clear= that Address type is dependent on Network Type. So I would be included to = remove the above sentence and just indicate that E164 defined by [SDP-CS] i= s used exclusively for nettype PSTN. You could add a note to the effect: "Note: RFC3105 also defines address typ= e E164. This definition is distinct from the one defined by [SDP-CS] and sh= all not be used with nettype PSTN." Regards, Christian On 19/11/2013 5:17 AM, Paul Kyzivat wrote: > On 11/18/13 9:31 AM, Christer Holmberg wrote: >> Hi, >> >> RFC 3108 (SDP for ATM) defines an 'E164' address type value. When=20 >> used, the associated address value is "up to 15 decimal digits". >> >> Example: c=3DATM E164 9738294382 >> >> draft-ietf-mmusic-sdp-cs-21 also defines an 'E164' address type=20 >> value, with a slightly different syntax for the associated address value= : >> >> - an international E.164 number (prepended with a '+' sign); or >> - the value "-", signifying that the address is unknown >> >> Now, the sdp-cs draft DOES say: >> >> "Please note that the "E164" address type defined in this=20 >> memo is >> exclusively defined to be used in conjunction with the "PSTN" >> network >> type in accordance with [RFC4566]. Usage of "E164" address=20 >> type in >> conjunction with other network types may be defined elsewhere." >> >> ...and, in 3108 the network type value is "ATM", so. >> >> I just wonder whether it would be useful to, in sdp-cs, give 3108 as=20 >> an example of where "E164" is defined for another network type, and=20 >> with a different syntax? > > I wouldn't object, but neither do I find it necessary to do this. > > I wasn't aware of 3108 when it was being standardized. I find its use=20 > of "E164" perverted, since it explicitly allows non-E164 values to be=20 > used, and doesn't even define how such numbers are to be interpreted. > > It should have used something other than "E164". But I guess it is too=20 > late to "fix" that. > > 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 christer.holmberg@ericsson.com Tue Nov 19 02:40:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2138B1ADBFF for ; Tue, 19 Nov 2013 02:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoO2-OOBn1Ff for ; Tue, 19 Nov 2013 02:40:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C3E041AD986 for ; Tue, 19 Nov 2013 02:40:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-69-528b4023c5b6 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 73.26.23787.3204B825; Tue, 19 Nov 2013 11:40:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 19 Nov 2013 11:40:35 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: UDPTL-DTLS: Open Issue regarding usage of the SDP connection attribute Thread-Index: Ac7lEyKJHfFouG6mT62OQuu1lxu/kQ== Date: Tue, 19 Nov 2013 10:40:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C541B0A@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C541B0AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvra6yQ3eQwfPDwhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsTmL2wFK+QrNh35zdTAuFO6i5GTQ0LARKJt7ScWCFtM4sK9 9WxdjFwcQgKHGCXmP77IDOEsZpTYtOA9YxcjBwebgIVE9z9tkAYRAXWJr3t7mEFsYYFAiVuN N5kh4mES9/5OYYGw9SQ2XrnACmKzCKhK3P3ewQhi8wr4Styeco4NxGYEWvz91BomEJtZQFzi 1pP5TBAHCUgs2XOeGcIWlXj5+B8rhK0o8fHVPkaI+nyJoy2LmSBmCkqcnPmEZQKj0Cwko2Yh KZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYmTPTczMSS833MQIDPuDW37r7mA8 dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgbk64IJ/crpOxjmLrC 1Z/tiGKjmahY+f7922xPz2Cck9MdXZve8FDM99OblYfX6qg5xwvFFffeNZ9V9XxNOmvfqq8b dr6R+RW+60ZlkOGU29c+lIYwLTq12vOh25Zb+m3Rburav+x7F624fy2f+W1ebtJ7RoM7ch43 pH9tVmTVFCqQ9PpR56vEUpyRaKjFXFScCACV5pklSQIAAA== Subject: [MMUSIC] UDPTL-DTLS: Open Issue regarding usage of the SDP connection attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 10:40:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C541B0AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the open issues (indicated in an Editor's Note) in the UDPTL-DTLS dr= aft is regarding the usage of the SDP connection attribute: "Editor's note: FFS if connection attribute defined in RFC 4145 is needed." The SRTP-DTLS spec forbids the usage of the attribute: "The endpoint MUST NOT use the connection attribute defined in [RFC4145]." ...and I can't think of a reason why we should deviate in the UDPTL-DTLS sp= ec, so my suggestion would be to remove the Editor's Note, and explicitly i= ndicate that the attribute must not be used (same as in RFC 5763). Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C541B0AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the open issues (indicated in an Editor’= ;s Note) in the UDPTL-DTLS draft is regarding the usage of the SDP connecti= on attribute:

 

“Editor's note: F= FS if connection attribute defined in RFC 4145 is needed.”=

 

The SRTP-DTLS spec forbids the usage of the attribut= e:

 

“The endpoint MUS= T NOT use the connection attribute defined in [RFC4145].”<= /p>

 

…and I can’t think of a reason why we sh= ould deviate in the UDPTL-DTLS spec, so my suggestion would be to remove th= e Editor’s Note, and explicitly indicate that the attribute must not = be used (same as in RFC 5763).

 

Comments?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C541B0AESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Nov 19 02:43:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56EA1ADBFF for ; Tue, 19 Nov 2013 02:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxlHSVvZ6zCH for ; Tue, 19 Nov 2013 02:43:33 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D557D1AD8DC for ; Tue, 19 Nov 2013 02:43:32 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-5d-528b40cd3f90 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3C.8D.15980.DC04B825; Tue, 19 Nov 2013 11:43:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 19 Nov 2013 11:43:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "Stach, Thomas" , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpoqzaoAgABTzwCAAAYggIAAGJHtgAABy1z///yhAIABJqxw Date: Tue, 19 Nov 2013 10:43:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> In-Reply-To: <528A5772.3050005@alum.mit.edu> 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+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvre45h+4gg8UXRCz2/F3EbnHtzD9G i6nLH7NYPGtdzmSxYsMBVouTO7cxO7B5/H3/gclj56y77B5Llvxk8pi18wmLx8/1V9k9tvc8 Zglgi+KySUnNySxLLdK3S+DKuPFTuuCyVsXkFy/YGxg3KXUxcnJICJhIPFizkhHCFpO4cG89 WxcjF4eQwCFGie0zL7JCOIsZJR5O+cDUxcjBwSZgIdH9TxskLiLwlVHi0Owv7CBxZgF1iauL g0AGCQvES6xcMxdsqIhAgsSBqffZIOwoiTn3boPFWQRUJU5c2A1m8wr4Spy7O48ZYtcJZomu 5UfZQRKcAjoStz5sArMZga77fmoNE4jNLCAucevJfCaIqwUkluw5zwxhi0q8fPyPFcJWlPj4 ah8jRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMbLnJmbm pJebb2IExtzBLb8NdjBuui92iFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYzasr2h2s9W86fbnNZ4vZW5cs+E53sPTN0QYsk7ZeGBa6ftK471v9xvd+nddkXOAye9XkS9 k+Bf4fZifuSmtpfOBydNzT96Rao9+2Jh/7xX32QSGiZrcH8yExA4OlVKPyj3SbimlehW3qDP S+c/8jty9lyTtNP84/rvv8z7PKk0+5Pvz/sBPq0iSizFGYmGWsxFxYkA8cUdGYcCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 10:43:35 -0000 Hi, So, let's do things in steps: First, does anyone object that we need to, SOMEHOW (we'll discuss the actua= l text etc later), update RFC 3264? Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 18. marraskuuta 2013 20:08 To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Ba= ngalore); Martin Thomson; Adam Roach Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update On 11/18/13 9:19 AM, Christer Holmberg wrote: > Hi, > > The issue is not whether a 3264 implementation will break or not. > > The issue is more administrative, and how we are allowed to write=20 > standards in IETF. > > Currently, 3264 says: > > 1) Port zero in an Offer means that the stream must not be used; and > > 2) An Offer with port zero must be answered with port zero > > As far as I know, we can not simply override that by defining an SDP=20 > attribute ('bundle-only'). Unless we can move inside the boundaries=20 > set by 3264, we need to update 3264. > > Please correct me if I'm wrong, though. I guess some chair/AD input=20 > would be useful here. I queried Adam for his opinion so we could have unanimity among chairs, but= I haven't heard back from him. I agree with Martin, that we need to formally declare that we are updating = 3264, but that we don't have to provide an explicit delta to 3264 to do so. > IN ANY CASE, I really hope we are not going to spend too much time on=20 > this issue - we have more important things to do. Agree. Thanks, Paul > Regards, > > Christer > > ---------------------------------------------------------------------- > -- > *From:* Stach, Thomas [thomas.stach@unify.com] > *Sent:* Monday, 18 November 2013 6:45 PM > *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson;=20 > Christer Holmberg > *Cc:* mmusic@ietf.org; Paul Kyzivat > *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only'=20 > attribute > - Suggested 3264 update > >> >> Hi Thomas, >> >> An answerer compliant with 3264 and not supporting bundle=20 >> would ignore a=3Dbundle-only and would set the port=3D0 in its answer.=20 >> >> >> The above statement clearly shows how RFC 3264 implementation will=20 >> break with "bundle-only" attribute proposal. > [TS] I'm not sure what 'break' should mean here. If it means "reject=20 > the m-line by setting port=3D in the answer", that is the intended behavi= or. > My statement was based on > http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section- > 3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the= =20 > offer. > The port=3D0 in the offer should guarantee that an answerer does not use= =20 > the m-line. >> RFC 3264 would have >> properly negotiated in case the port is allocated in the initial=20 >> offer instead of port 0. > [TS] That is not what a=3Dbundle-only wants to achieve. > The semantics of using a valid port in the offer together with=20 > a=3Dbundle-only are not clear to me. > I would regard that as an invalid combination. > > Regards > Thomas >> >> Thanks >> Partha >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >> Behalf Of ext Stach, Thomas >> Sent: Monday, November 18, 2013 4:54 PM >> To: Martin Thomson; Christer Holmberg >> Cc: mmusic@ietf.org; Paul Kyzivat >> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute=20 >> - Suggested 3264 update >> >> Inline >> >> > On 14 November 2013 10:28, Christer Holmberg=20 >> > wrote: >> > > I scanned through 3264, in order to find the sections that need=20 >> > > to >> be >> > updated. >> > >> > >> > A direct replacement doesn't seem necessary. We aren't issuing a=20 >> > new 3264. A more direct explanation of what 3264 permits or=20 >> > prohibits >> and >> > why this is being changed is probably more important. >> > >> > Maybe it's as simple as saying something like: >> > >> > RFC 3264 states that m-lines with zero ports are negotiated off. >> This >> > document updates RFC 3264 to permit the use of a zero port on=20 >> > m-lines in combination with the a=3Dbundle-only attribute. >> [TS] I agree with Martin. >> An answerer compliant with 3264 and not supporting bundle would=20 >> ignore a=3Dbundle-only and would set the port=3D0 in its answer. >> I don't see an issue with an offerer compliant with 3264 and not=20 >> supporting bundle, since it wouldn't have included a=3Dbundle-only (and= =20 >> wouldn't include a larger number of m-lines with port=3D0). The=20 >> answerer supporting bundle would have to set port=3D0 in the answer to=20 >> such an offer in order to comply with 3264. >> In my opinion there isn't any change to the procedures in 3264 for an=20 >> older implementation, so this isn't an update to 3264. >> However, explicit text in bundle that describes this behavior would=20 >> be justified. >> >> >> Regards >> Thomas >> >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> >https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic From thomas.stach@unify.com Tue Nov 19 03:56:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E8D1ADF27 for ; Tue, 19 Nov 2013 03:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCJ6pIqeIme8 for ; Tue, 19 Nov 2013 03:56:08 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6929B1AD8EA for ; Tue, 19 Nov 2013 03:56:08 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 7DB6E23F0499; Tue, 19 Nov 2013 12:56:01 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 12:56:01 +0100 From: "Stach, Thomas" To: Christer Holmberg , Paul Kyzivat , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//8S6A//okgLCADAABAP//7XIggAAiRYCAAA1mAIABFi+A///p0bA= Date: Tue, 19 Nov 2013 11:56:00 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 11:56:11 -0000 Christer, may I ask what you mean by "NEED to update 3264"?=20 - If you mean to revise 3264 and create a 3264bis, I would object. =20 - If you mean to include "Updates: RFC3264" in the header of the BUNDLE RFC= -to-be, I'm inclined to say "Not necessary", but I don't care enough and wo= uld not object.=20 Disclaimer: I quickly scanned RFC2026 and its successors for criteria when = "Updates: RFCxxxx" is used, but couldn't find any. - If you mean that we need to precisely describe how a bundle-implementatio= n acts on receipt of an offer with port=3D0 and an a=3Dbundle-only attribut= e, I would say "Yes, absolutely" and I also would want to clarify that this= goes beyond what is specified in 3264. I hope this helps, but I can also give a justification in a next step. Regards Thomas >=20 > Hi, >=20 > So, let's do things in steps: >=20 > First, does anyone object that we need to, SOMEHOW (we'll discuss the > actual text etc later), update RFC 3264? >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 18. marraskuuta 2013 20:08 > To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - > IN/Bangalore); Martin Thomson; Adam Roach > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - > Suggested 3264 update >=20 > On 11/18/13 9:19 AM, Christer Holmberg wrote: > > Hi, > > > > The issue is not whether a 3264 implementation will break or not. > > > > The issue is more administrative, and how we are allowed to write > > standards in IETF. > > > > Currently, 3264 says: > > > > 1) Port zero in an Offer means that the stream must not be used; and > > > > 2) An Offer with port zero must be answered with port zero > > > > As far as I know, we can not simply override that by defining an SDP > > attribute ('bundle-only'). Unless we can move inside the boundaries > > set by 3264, we need to update 3264. > > > > Please correct me if I'm wrong, though. I guess some chair/AD input > > would be useful here. >=20 > I queried Adam for his opinion so we could have unanimity among chairs, > but I haven't heard back from him. >=20 > I agree with Martin, that we need to formally declare that we are > updating 3264, but that we don't have to provide an explicit delta to > 3264 to do so. >=20 > > IN ANY CASE, I really hope we are not going to spend too much time on > > this issue - we have more important things to do. >=20 > Agree. >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > --------------------------------------------------------------------- > - > > -- > > *From:* Stach, Thomas [thomas.stach@unify.com] > > *Sent:* Monday, 18 November 2013 6:45 PM > > *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; > > Christer Holmberg > > *Cc:* mmusic@ietf.org; Paul Kyzivat > > *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' > > attribute > > - Suggested 3264 update > > > >> > >> Hi Thomas, > >> > >> An answerer compliant with 3264 and not supporting bundle > >> would ignore a=3Dbundle-only and would set the port=3D0 in its answer. > >> > >> > >> The above statement clearly shows how RFC 3264 implementation will > >> break with "bundle-only" attribute proposal. > > [TS] I'm not sure what 'break' should mean here. If it means "reject > > the m-line by setting port=3D in the answer", that is the intended > behavior. > > My statement was based on > > http://tools.ietf.org/html/draft-roach-mmusic-unified-plan- > 00#section- > > 3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in th= e > > offer. > > The port=3D0 in the offer should guarantee that an answerer does not > use > > the m-line. > >> RFC 3264 would have > >> properly negotiated in case the port is allocated in the initial > >> offer instead of port 0. > > [TS] That is not what a=3Dbundle-only wants to achieve. > > The semantics of using a valid port in the offer together with > > a=3Dbundle-only are not clear to me. > > I would regard that as an invalid combination. > > > > Regards > > Thomas > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of ext Stach, Thomas > >> Sent: Monday, November 18, 2013 4:54 PM > >> To: Martin Thomson; Christer Holmberg > >> Cc: mmusic@ietf.org; Paul Kyzivat > >> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' > attribute > >> - Suggested 3264 update > >> > >> Inline > >> > >> > On 14 November 2013 10:28, Christer Holmberg > >> > wrote: > >> > > I scanned through 3264, in order to find the sections that need > >> > > to > >> be > >> > updated. > >> > > >> > > >> > A direct replacement doesn't seem necessary. We aren't issuing a > >> > new 3264. A more direct explanation of what 3264 permits or > >> > prohibits > >> and > >> > why this is being changed is probably more important. > >> > > >> > Maybe it's as simple as saying something like: > >> > > >> > RFC 3264 states that m-lines with zero ports are negotiated off. > >> This > >> > document updates RFC 3264 to permit the use of a zero port on > >> > m-lines in combination with the a=3Dbundle-only attribute. > >> [TS] I agree with Martin. > >> An answerer compliant with 3264 and not supporting bundle would > >> ignore a=3Dbundle-only and would set the port=3D0 in its answer. > >> I don't see an issue with an offerer compliant with 3264 and not > >> supporting bundle, since it wouldn't have included a=3Dbundle-only > (and > >> wouldn't include a larger number of m-lines with port=3D0). The > >> answerer supporting bundle would have to set port=3D0 in the answer to > >> such an offer in order to comply with 3264. > >> In my opinion there isn't any change to the procedures in 3264 for > an > >> older implementation, so this isn't an update to 3264. > >> However, explicit text in bundle that describes this behavior would > >> be justified. > >> > >> > >> Regards > >> Thomas > >> > >> > _______________________________________________ > >> > mmusic mailing list > >> > mmusic@ietf.org > >> >https://www.ietf.org/mailman/listinfo/mmusic > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >>https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Tue Nov 19 04:04:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FAA1ADF51 for ; Tue, 19 Nov 2013 04:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUFA-Hm0P5mr for ; Tue, 19 Nov 2013 04:04:17 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2C99E1ADF4C for ; Tue, 19 Nov 2013 04:04:16 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-f8-528b53ba265b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DA.E9.27941.AB35B825; Tue, 19 Nov 2013 13:04:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 19 Nov 2013 13:04:10 +0100 From: Christer Holmberg To: "Stach, Thomas" , Paul Kyzivat , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpoqzaoAgABTzwCAAAYggIAAGJHtgAABy1z///yhAIABJqxwgAADygCAABHtoA== Date: Tue, 19 Nov 2013 12:04:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C541E85@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> 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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvre6u4O4ggyn/1Sz2/F3EbnHtzD9G i6nLH7NYPGtdzmSxYsMBVouTO7cxO7B5/H3/gclj56y77B5Llvxk8pi18wmLx8/1V9k9tvc8 Zglgi+KySUnNySxLLdK3S+DKeLprO2PBZJOK803PWBsYezS7GDk5JARMJI7272SGsMUkLtxb z9bFyMUhJHCEUWLpxossIAkhgcWMEnd/aHQxcnCwCVhIdP/TBqkREfjKKPH41xlGkDizgLrE 1cVBIOXCAvESK9fMZQSxRQQSJA5Mvc8GYWdJbH83DWwki4CqxIIF78D28gr4Shzbs4kJYu9F FomurrlgRZwC/hLTjt0AK2IEOu77qTVMIDazgLjErSfzmSCOFpBYsuc81AOiEi8f/2OFsBUl Pr7axwhRryOxYPcnNghbW2LZwtdQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcxanF SbnpRgabGIFRd3DLb4sdjJf/2hxilOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY9fWrizRBPeG/IUm69i+rVVQj82eGRhy4cT875u5XkvXdTE4qHbWv58usXCVwdtu9t9W uad3ZthKznvBGJSu/8mh+uzSP5Oki9x4GF+fXdp7cvrVEBbH7Zf0hdaLzPsTwxJ/rcDuwhyz q+VGu/u0bztJNa/68njnom0Fq7w4+xvuhrfpn54toMRSnJFoqMVcVJwIAJas33WIAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 12:04:20 -0000 Hi, > may I ask what you mean by "NEED to update 3264"?=20 > > - If you mean to revise 3264 and create a 3264bis, I would object. =20 That is not what I meant. > - If you mean to include "Updates: RFC3264" in the header of the BUNDLE R= FC-to-be, I'm inclined to say "Not necessary", but I don't care enough and = would not object.=20 That is what I meant. > - If you mean that we need to precisely describe how a bundle-implementat= ion acts on receipt of an offer with port=3D0 and an a=3Dbundle-only=20 > attribute, I would say "Yes, absolutely" and I also would want to clarify= that this goes beyond what is specified in 3264. That is not what I meant.=20 In the BUNDLE spec we naturally need to describe how bundle-only is used, b= ut this question is only related to the possible update of 3264 :) Regards, Christer >=20 > Hi, >=20 > So, let's do things in steps: >=20 > First, does anyone object that we need to, SOMEHOW (we'll discuss the=20 > actual text etc later), update RFC 3264? >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 18. marraskuuta 2013 20:08 > To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN -=20 > IN/Bangalore); Martin Thomson; Adam Roach > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute=20 > - Suggested 3264 update >=20 > On 11/18/13 9:19 AM, Christer Holmberg wrote: > > Hi, > > > > The issue is not whether a 3264 implementation will break or not. > > > > The issue is more administrative, and how we are allowed to write=20 > > standards in IETF. > > > > Currently, 3264 says: > > > > 1) Port zero in an Offer means that the stream must not be used; and > > > > 2) An Offer with port zero must be answered with port zero > > > > As far as I know, we can not simply override that by defining an SDP=20 > > attribute ('bundle-only'). Unless we can move inside the boundaries=20 > > set by 3264, we need to update 3264. > > > > Please correct me if I'm wrong, though. I guess some chair/AD input=20 > > would be useful here. >=20 > I queried Adam for his opinion so we could have unanimity among=20 > chairs, but I haven't heard back from him. >=20 > I agree with Martin, that we need to formally declare that we are=20 > updating 3264, but that we don't have to provide an explicit delta to > 3264 to do so. >=20 > > IN ANY CASE, I really hope we are not going to spend too much time=20 > > on this issue - we have more important things to do. >=20 > Agree. >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > -------------------------------------------------------------------- > > - > - > > -- > > *From:* Stach, Thomas [thomas.stach@unify.com] > > *Sent:* Monday, 18 November 2013 6:45 PM > > *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson;=20 > > Christer Holmberg > > *Cc:* mmusic@ietf.org; Paul Kyzivat > > *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' > > attribute > > - Suggested 3264 update > > > >> > >> Hi Thomas, > >> > >> An answerer compliant with 3264 and not supporting bundle=20 > >> would ignore a=3Dbundle-only and would set the port=3D0 in its answer. > >> > >> > >> The above statement clearly shows how RFC 3264 implementation will=20 > >> break with "bundle-only" attribute proposal. > > [TS] I'm not sure what 'break' should mean here. If it means "reject=20 > > the m-line by setting port=3D in the answer", that is the intended > behavior. > > My statement was based on > > http://tools.ietf.org/html/draft-roach-mmusic-unified-plan- > 00#section- > > 3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in th= e=20 > > offer. > > The port=3D0 in the offer should guarantee that an answerer does not > use > > the m-line. > >> RFC 3264 would have > >> properly negotiated in case the port is allocated in the initial=20 > >> offer instead of port 0. > > [TS] That is not what a=3Dbundle-only wants to achieve. > > The semantics of using a valid port in the offer together with=20 > > a=3Dbundle-only are not clear to me. > > I would regard that as an invalid combination. > > > > Regards > > Thomas > >> > >> Thanks > >> Partha > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > >> Behalf Of ext Stach, Thomas > >> Sent: Monday, November 18, 2013 4:54 PM > >> To: Martin Thomson; Christer Holmberg > >> Cc: mmusic@ietf.org; Paul Kyzivat > >> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' > attribute > >> - Suggested 3264 update > >> > >> Inline > >> > >> > On 14 November 2013 10:28, Christer Holmberg=20 > >> > wrote: > >> > > I scanned through 3264, in order to find the sections that need=20 > >> > > to > >> be > >> > updated. > >> > > >> > > >> > A direct replacement doesn't seem necessary. We aren't issuing a=20 > >> > new 3264. A more direct explanation of what 3264 permits or=20 > >> > prohibits > >> and > >> > why this is being changed is probably more important. > >> > > >> > Maybe it's as simple as saying something like: > >> > > >> > RFC 3264 states that m-lines with zero ports are negotiated off. > >> This > >> > document updates RFC 3264 to permit the use of a zero port on=20 > >> > m-lines in combination with the a=3Dbundle-only attribute. > >> [TS] I agree with Martin. > >> An answerer compliant with 3264 and not supporting bundle would=20 > >> ignore a=3Dbundle-only and would set the port=3D0 in its answer. > >> I don't see an issue with an offerer compliant with 3264 and not=20 > >> supporting bundle, since it wouldn't have included a=3Dbundle-only > (and > >> wouldn't include a larger number of m-lines with port=3D0). The=20 > >> answerer supporting bundle would have to set port=3D0 in the answer=20 > >> to such an offer in order to comply with 3264. > >> In my opinion there isn't any change to the procedures in 3264 for > an > >> older implementation, so this isn't an update to 3264. > >> However, explicit text in bundle that describes this behavior would=20 > >> be justified. > >> > >> > >> Regards > >> Thomas > >> > >> > _______________________________________________ > >> > 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 19 07:47:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC31AE00C for ; Tue, 19 Nov 2013 07:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocYYafXDlw4Z for ; Tue, 19 Nov 2013 07:47:50 -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 DB9461AE009 for ; Tue, 19 Nov 2013 07:47:49 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id rS5U1m00627AodY55TnjZ2; Tue, 19 Nov 2013 15:47:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id rTnj1m00d3ZTu2S3fTnj80; Tue, 19 Nov 2013 15:47:43 +0000 Message-ID: <528B881F.7080102@alum.mit.edu> Date: Tue, 19 Nov 2013 07:47:43 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "Stach, Thomas" , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> 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=1384876063; bh=pHQ3Aqw/Egd7N72soV0A3wUNIpId/LM/Ywm2g3fAKfI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KvuCiQbu0uDCuElEC+WilD9wRuNzoysTf7347CUVhRnbPalzgCN8fptVn9RHl24Nb RhbrDNb8o7qzG4JH2Eu+6kHjGqFQ5DzFdDbpK2SDQzOlrxx5/3NkK3AUkL+kRnAvaA YXLtgNQC96NRi7tAq4jTScPDh0EOyT2MqV5+IiBPzb1xAhATX8mOsgISXs8jKn42BB 24x9OnKQw7QhgIWB6D/eU2XSGTCbD5a7EmpB6SzobGtgi/mlWIxU4Sc05u+HsAAspV wmc5U6R/ZK5CiV9kwYVQV7KtIfPJ5cCNt0bm1pUiKqbN4ERP9HD8sBLrH02PEMtBol r6rQQUyGOhYTw== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 15:47:52 -0000 On 11/19/13 2:43 AM, Christer Holmberg wrote: > Hi, > > So, let's do things in steps: > > First, does anyone object that we need to, SOMEHOW (we'll discuss the actual text etc later), update RFC 3264? I *don't* object - I *do* think we need to indicate formally that 3264 is being updated. My logic is that is we don't do that, then it will be impossible to claim simultaneous conformance to bundle-only and 3264 - using bundle-only will of necessity require violating 3264. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 18. marraskuuta 2013 20:08 > To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Adam Roach > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update > > On 11/18/13 9:19 AM, Christer Holmberg wrote: >> Hi, >> >> The issue is not whether a 3264 implementation will break or not. >> >> The issue is more administrative, and how we are allowed to write >> standards in IETF. >> >> Currently, 3264 says: >> >> 1) Port zero in an Offer means that the stream must not be used; and >> >> 2) An Offer with port zero must be answered with port zero >> >> As far as I know, we can not simply override that by defining an SDP >> attribute ('bundle-only'). Unless we can move inside the boundaries >> set by 3264, we need to update 3264. >> >> Please correct me if I'm wrong, though. I guess some chair/AD input >> would be useful here. > > I queried Adam for his opinion so we could have unanimity among chairs, but I haven't heard back from him. > > I agree with Martin, that we need to formally declare that we are updating 3264, but that we don't have to provide an explicit delta to > 3264 to do so. > >> IN ANY CASE, I really hope we are not going to spend too much time on >> this issue - we have more important things to do. > > Agree. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> ---------------------------------------------------------------------- >> -- >> *From:* Stach, Thomas [thomas.stach@unify.com] >> *Sent:* Monday, 18 November 2013 6:45 PM >> *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; >> Christer Holmberg >> *Cc:* mmusic@ietf.org; Paul Kyzivat >> *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' >> attribute >> - Suggested 3264 update >> >>> >>> Hi Thomas, >>> >>> An answerer compliant with 3264 and not supporting bundle >>> would ignore a=bundle-only and would set the port=0 in its answer. >>> >>> >>> The above statement clearly shows how RFC 3264 implementation will >>> break with "bundle-only" attribute proposal. >> [TS] I'm not sure what 'break' should mean here. If it means "reject >> the m-line by setting port= in the answer", that is the intended behavior. >> My statement was based on >> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section- >> 3.1 Here, the a=bundle-only attribute is combined with port=0 in the >> offer. >> The port=0 in the offer should guarantee that an answerer does not use >> the m-line. >>> RFC 3264 would have >>> properly negotiated in case the port is allocated in the initial >>> offer instead of port 0. >> [TS] That is not what a=bundle-only wants to achieve. >> The semantics of using a valid port in the offer together with >> a=bundle-only are not clear to me. >> I would regard that as an invalid combination. >> >> Regards >> Thomas >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of ext Stach, Thomas >>> Sent: Monday, November 18, 2013 4:54 PM >>> To: Martin Thomson; Christer Holmberg >>> Cc: mmusic@ietf.org; Paul Kyzivat >>> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute >>> - Suggested 3264 update >>> >>> Inline >>> >>>> On 14 November 2013 10:28, Christer Holmberg >>>> wrote: >>>>> I scanned through 3264, in order to find the sections that need >>>>> to >>> be >>>> updated. >>>> >>>> >>>> A direct replacement doesn't seem necessary. We aren't issuing a >>>> new 3264. A more direct explanation of what 3264 permits or >>>> prohibits >>> and >>>> why this is being changed is probably more important. >>>> >>>> Maybe it's as simple as saying something like: >>>> >>>> RFC 3264 states that m-lines with zero ports are negotiated off. >>> This >>>> document updates RFC 3264 to permit the use of a zero port on >>>> m-lines in combination with the a=bundle-only attribute. >>> [TS] I agree with Martin. >>> An answerer compliant with 3264 and not supporting bundle would >>> ignore a=bundle-only and would set the port=0 in its answer. >>> I don't see an issue with an offerer compliant with 3264 and not >>> supporting bundle, since it wouldn't have included a=bundle-only (and >>> wouldn't include a larger number of m-lines with port=0). The >>> answerer supporting bundle would have to set port=0 in the answer to >>> such an offer in order to comply with 3264. >>> In my opinion there isn't any change to the procedures in 3264 for an >>> older implementation, so this isn't an update to 3264. >>> However, explicit text in bundle that describes this behavior would >>> be justified. >>> >>> >>> Regards >>> Thomas >>> >>>> _______________________________________________ >>>> 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 partha@parthasarathi.co.in Tue Nov 19 10:27:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1381AE014 for ; Tue, 19 Nov 2013 10:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DvgXnOZwF6D for ; Tue, 19 Nov 2013 10:27:47 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1081AE0AA for ; Tue, 19 Nov 2013 10:27:46 -0800 (PST) Received: from userPC (unknown [122.179.55.63]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id EE96914D81D4; Tue, 19 Nov 2013 18:27:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1384885660; bh=vrALuU015vsHajqIXoLUXMnJ9DcUpbqXtZKUX6hcwTw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=h4NIRD5zvh3RV+nK+NnZC32/u/zKcaPUQ5zsm/MSyVuC/6rxhfZPJ+sOFyPBK1MZa Usz90SS+aIBj+ENIhDD0mTVTrPlf7qmSRjxvkYv2T05SDlKoeo8p9nd/upmWZvg1QR IgeQEHozhy6uw593GKHW8LWa7p2T+3ik2NH2T0xU= From: "Parthasarathi R" To: "'SM'" References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> In-Reply-To: <00a101ced981$77414d60$65c3e820$@co.in> Date: Tue, 19 Nov 2013 23:57:32 +0530 Message-ID: <00ab01cee555$05f53560$11dfa020$@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: Ac7WCf0ecmMN+0M+TSWjaJaWZaJOMwDdDmjwAvV1ARA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.528BAD9C.0086, ss=2, re=0.100, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 18:27:49 -0000 Sm, I have clarified all your below queries. Could you please let me know in case you still see any specific issue with the draft. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Parthasarathi R > Sent: Monday, November 04, 2013 10:45 PM > To: 'SM'; mmusic@ietf.org > Subject: Re: [MMUSIC] Last Call: 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) > to Proposed Standard > > Sm, > > Please read inline. > > Thanks > Partha/Muthu > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of SM > > Sent: Thursday, October 31, 2013 9:07 AM > > To: mmusic@ietf.org > > Subject: Re: [MMUSIC] Last Call: > 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex > B) > > to Proposed Standard > > > > At 06:17 30-10-2013, The IESG wrote: > > >The IESG has received a request from the Multiparty Multimedia > Session > > >Control WG (mmusic) to consider the following document: > > >- 'Offer/Answer Considerations for G723 Annex A and G729 Annex B' > > > as Proposed Standard > > > > > >The IESG plans to make a decision in the next few weeks, and > solicits > > >final comments on this action. Please send substantive comments to > the > > >ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments > may > > be > > > > I read this draft quickly. According to the 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 Session > > Description > > protocol(SDP) offer and answer. This document provides the > offer/ > > answer considerations for these parameters and updates RFC4856." > > > > RFC 4856 is about media type registration of payload formats. > Agreed > > The > > IESG approval mentioned that the document "specify the procedure to > > register RTP payload formats as audio, video or other media subtype > > names". The RFC does not specify the AnnexA parameter for G723. > > Agreed. RFC4856 describes AnnexA parameter for G723. > > I > > took a quick look at the RFCs being referenced. They are about media > > type registrations. It is doubtful whether they even qualify for > > Proposed Standard. > RFC4856 is published as proposed standard in IETF > > > > > The premise on which the work in this draft is built is lacking. > The premise on which the work in this draft is already well > described in the abstract itself > > The > > draft mentions > > G723 Annex A without providing any reference to the > > specification. > G723 annexa SDP attribute is defined in RFC 4856. > > In my opinion the draft needs more work for it to be > > a Proposed Standard. > Could you please list the work which has to be done for this > draft > > > It doesn't look like there has been any > > discussion about whether there are IPR issues affecting > > implementations. > > > > The authors are not aware of any IPR related to this issue. > This > has been communicated to MMUSIC WG Chairs > > > Regards, > > -sm > > > > _______________________________________________ > > 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 sm@resistor.net Tue Nov 19 11:27:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A623F1AE1E7 for ; Tue, 19 Nov 2013 11:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzXZ8gXNb-mP for ; Tue, 19 Nov 2013 11:27:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC851AE1EE for ; Tue, 19 Nov 2013 11:27:51 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAJJRdse004435; Tue, 19 Nov 2013 11:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384889264; bh=7l9HOaSVWsGiBbIJQn8xW2e27wQNpAKtiZ+9N2fFEmg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=03QIoLAOsIW6Z0/pJmRfjc36NHIAz25x2Kw+iMc5iyinQmj+fwDBhah4VIKId9EvS uyxdZqAZAS8q7ffasNG5QDNN7Knpc51JLjiqPsGjHSMSWRKfEhozx5/nvSyl9sO4lk gbn2ayPGEie/5l3db62vOvo2uzFldEbB+M1/RKR4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384889264; i=@resistor.net; bh=7l9HOaSVWsGiBbIJQn8xW2e27wQNpAKtiZ+9N2fFEmg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nXr/RvsO1JIarxjM9CP5GALqi7TMMKbz+wIqlxdl8hb6l8vAp6GhnTUbvdVixdKCf BHXX7I2XjD0z3GYtoKgLrgCEydUCCqj8EFCDOtUtSq2XHENxcL+9n5zf3LmNhqHq16 NKZdYL2nTQuA99GxokZDDf2IXlitmxXnzVGE2WLA= Message-Id: <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 19 Nov 2013 11:27:07 -0800 To: Parthasarathi R From: SM In-Reply-To: <00ab01cee555$05f53560$11dfa020$@co.in> References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 19 Nov 2013 11:48:26 -0800 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 19:27:52 -0000 Hi Partha, I forgot to mention that I am not subscribed to the MMUSIC mailing list. At 10:27 19-11-2013, Parthasarathi R wrote: >I have clarified all your below queries. Could you please let me know in >case you still see any specific issue with the draft. In my humble opinion RFC 4856 is more about a media type registration request instead of a technical specification about interoperability. It is mentioned in Section 1 of that RFC that it updates the media type registrations. The fact that RFC 4856 is published as a Proposed Standard does not mean that it is the correct status. There are a lot of oddities in the IETF Stream. I prefer not to ask about those oddities. :-) draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 Annex B. There aren't any references for them. The problem with the draft is that it builds upon RFC 4856 instead of the technical specification where the protocol is specified. Is G723 Annex A and G729 Annex B needed to implement what the draft tries to do? In my opinion, yes. The document shepherd write-up has the following question: "Why is this the proper type of RFC?" The answer provided is: "Proposed Standard. The title page notes the document as Standards Track" That does not answer the question. Regards, -sm From christer.holmberg@ericsson.com Wed Nov 20 02:47:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416601AD8CD for ; Wed, 20 Nov 2013 02:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3fV9QWlm5ZT for ; Wed, 20 Nov 2013 02:47:50 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D38F11AD939 for ; Wed, 20 Nov 2013 02:47:49 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-b6-528c934e61c6 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D6.4F.27941.E439C825; Wed, 20 Nov 2013 11:47:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Wed, 20 Nov 2013 11:47:42 +0100 From: Christer Holmberg To: Paul Kyzivat , "Stach, Thomas" , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: AQHO4WhIQegXxiGZgkiMUWoE7n6oBpoqzaoAgABTzwCAAAYggIAAGJHtgAABy1z///yhAIABJqxwgABEiICAAU1l8A== Date: Wed, 20 Nov 2013 10:47:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5466E8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> <528B881F.7080102@alum.mit.edu> In-Reply-To: <528B881F.7080102@alum.mit.edu> 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+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvra7f5J4gg5MrNS32/F3EbnHtzD9G i6nLH7NYPGtdzmSxYsMBVouTO7cxO7B5/H3/gclj56y77B5Llvxk8pi18wmLx8/1V9k9tvc8 Zglgi+KySUnNySxLLdK3S+DKeLA3seCOWcW6SY/ZGxi36HQxcnJICJhI7OpewAxhi0lcuLee rYuRi0NI4AijxOreLywQzmJGiU/PHjJ2MXJwsAlYSHT/0waJiwh8ZZQ4NPsLO0icWUBd4uri IJBBwgLxEivXzGUEsUUEEiQOTL3PBmFnSWzffwEsziKgKrHv5R2wOK+Ar8TS5/eYIXZtZJG4 MuUgK0iCU0BH4tHfbSwgNiPQdd9PrWECsZkFxCVuPZnPBHG1gMSSPeehPhCVePn4HyuErSjx 8dU+Roh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKE4t TspNNzLYxAiMuoNbflvsYLz81+YQozQHi5I478e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGI3DHWasnHwpLNDs8Pae2qwHfC/k9imz/mtjyi28v9js9SvT/C+NUe8TeHcbWWrNz7L4 wXBu89Hlz9QyeTTz0hhDZxz3UZjCZs932tLy6LWVW652JJb2v9vz/Gje76QJnkdKhbJlpzHe m/5Z8cwVTnkutRO7SoxkD0+P7qv7wiW60snx+s4zOUosxRmJhlrMRcWJAJNR5f+IAgAA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:47:53 -0000 So, maybe something like: "This specification updates the procedures in RFC 3264. It defines the usag= e of a zero port value in an SDP Offer even if the stream is not removed. In addition, it al= lows the Answerer to assign a non-zero port value to a stream in an SDP Answer also in cases = where the stream contained a zero port value in the associated SDP Offer. The updates= above only apply to streams for which an SDP 'bundle-only' attribute has been assigned= in the SDP Offer." Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 19. marraskuuta 2013 17:48 To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Ba= ngalore); Martin Thomson; Adam Roach Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Sug= gested 3264 update On 11/19/13 2:43 AM, Christer Holmberg wrote: > Hi, > > So, let's do things in steps: > > First, does anyone object that we need to, SOMEHOW (we'll discuss the act= ual text etc later), update RFC 3264? I *don't* object - I *do* think we need to indicate formally that 3264 is b= eing updated. My logic is that is we don't do that, then it will be impossible to claim s= imultaneous conformance to bundle-only and 3264 - using bundle-only will of= necessity require violating 3264. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 18. marraskuuta 2013 20:08 > To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN -=20 > IN/Bangalore); Martin Thomson; Adam Roach > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute=20 > - Suggested 3264 update > > On 11/18/13 9:19 AM, Christer Holmberg wrote: >> Hi, >> >> The issue is not whether a 3264 implementation will break or not. >> >> The issue is more administrative, and how we are allowed to write=20 >> standards in IETF. >> >> Currently, 3264 says: >> >> 1) Port zero in an Offer means that the stream must not be used; and >> >> 2) An Offer with port zero must be answered with port zero >> >> As far as I know, we can not simply override that by defining an SDP=20 >> attribute ('bundle-only'). Unless we can move inside the boundaries=20 >> set by 3264, we need to update 3264. >> >> Please correct me if I'm wrong, though. I guess some chair/AD input=20 >> would be useful here. > > I queried Adam for his opinion so we could have unanimity among chairs, b= ut I haven't heard back from him. > > I agree with Martin, that we need to formally declare that we are=20 > updating 3264, but that we don't have to provide an explicit delta to > 3264 to do so. > >> IN ANY CASE, I really hope we are not going to spend too much time on=20 >> this issue - we have more important things to do. > > Agree. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> --------------------------------------------------------------------- >> - >> -- >> *From:* Stach, Thomas [thomas.stach@unify.com] >> *Sent:* Monday, 18 November 2013 6:45 PM >> *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson;=20 >> Christer Holmberg >> *Cc:* mmusic@ietf.org; Paul Kyzivat >> *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' >> attribute >> - Suggested 3264 update >> >>> >>> Hi Thomas, >>> >>> An answerer compliant with 3264 and not supporting bundle=20 >>> would ignore a=3Dbundle-only and would set the port=3D0 in its answer. >>> >>> >>> The above statement clearly shows how RFC 3264 implementation will=20 >>> break with "bundle-only" attribute proposal. >> [TS] I'm not sure what 'break' should mean here. If it means "reject=20 >> the m-line by setting port=3D in the answer", that is the intended behav= ior. >> My statement was based on >> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section >> - >> 3.1 Here, the a=3Dbundle-only attribute is combined with port=3D0 in the= =20 >> offer. >> The port=3D0 in the offer should guarantee that an answerer does not=20 >> use the m-line. >>> RFC 3264 would have >>> properly negotiated in case the port is allocated in the initial=20 >>> offer instead of port 0. >> [TS] That is not what a=3Dbundle-only wants to achieve. >> The semantics of using a valid port in the offer together with=20 >> a=3Dbundle-only are not clear to me. >> I would regard that as an invalid combination. >> >> Regards >> Thomas >>> >>> Thanks >>> Partha >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >>> Behalf Of ext Stach, Thomas >>> Sent: Monday, November 18, 2013 4:54 PM >>> To: Martin Thomson; Christer Holmberg >>> Cc: mmusic@ietf.org; Paul Kyzivat >>> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only'=20 >>> attribute >>> - Suggested 3264 update >>> >>> Inline >>> >>>> On 14 November 2013 10:28, Christer Holmberg=20 >>>> wrote: >>>>> I scanned through 3264, in order to find the sections that need to >>> be >>>> updated. >>>> >>>> >>>> A direct replacement doesn't seem necessary. We aren't issuing a=20 >>>> new 3264. A more direct explanation of what 3264 permits or=20 >>>> prohibits >>> and >>>> why this is being changed is probably more important. >>>> >>>> Maybe it's as simple as saying something like: >>>> >>>> RFC 3264 states that m-lines with zero ports are negotiated off. >>> This >>>> document updates RFC 3264 to permit the use of a zero port on=20 >>>> m-lines in combination with the a=3Dbundle-only attribute. >>> [TS] I agree with Martin. >>> An answerer compliant with 3264 and not supporting bundle would=20 >>> ignore a=3Dbundle-only and would set the port=3D0 in its answer. >>> I don't see an issue with an offerer compliant with 3264 and not=20 >>> supporting bundle, since it wouldn't have included a=3Dbundle-only=20 >>> (and wouldn't include a larger number of m-lines with port=3D0). The=20 >>> answerer supporting bundle would have to set port=3D0 in the answer to= =20 >>> such an offer in order to comply with 3264. >>> In my opinion there isn't any change to the procedures in 3264 for=20 >>> an older implementation, so this isn't an update to 3264. >>> However, explicit text in bundle that describes this behavior would=20 >>> be justified. >>> >>> >>> Regards >>> Thomas >>> >>>> _______________________________________________ >>>> 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 martin.thomson@gmail.com Wed Nov 20 09:27:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01C51AE4E1 for ; Wed, 20 Nov 2013 09:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYnTx-D1Ye8S for ; Wed, 20 Nov 2013 09:27:58 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 10C631AE4DD for ; Wed, 20 Nov 2013 09:27:57 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so9457061wgh.17 for ; Wed, 20 Nov 2013 09:27:51 -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=XSx2SxztVDS1dX8wIBaFfhgAmxduxJZz8VhSlKaTZqk=; b=Bth6ygSCmQdm3beCMS4IICgRvvOOcpVMmOhlX3NWK2je3V5/cBdVbNfGyNTPPn79R8 jVhbzX+qqoTW0x25kvQjXKQ2FRI0wyzZIcbe8ZfpcthgUUxMd0TRjzhCaco5+4E79Lxl k37lKswRGCYIE6KMKNxuplAmyiuBuhyW3PDsRIAuK4rG7dyT+8H59DgvWAfQGiOxokeS y/fgcMGwzno27uJCZLdqkSkUWHUX5OQk62UQwqtNwvto0uL6NqePAny24GfCIDwD0c3O P5fWMHDQw9b2hhgQXWH/dERFwJX23+dGtbL7OLWI+cHAm79ILwTgKkRjJJuJkIa19Ev4 J5iw== MIME-Version: 1.0 X-Received: by 10.180.20.102 with SMTP id m6mr2337780wie.22.1384968471238; Wed, 20 Nov 2013 09:27:51 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 20 Nov 2013 09:27:51 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5466E8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> <528B881F.7080102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5466E8@ESESSMB209.ericsson.se> Date: Wed, 20 Nov 2013 09:27:51 -0800 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:28:00 -0000 On 20 November 2013 02:47, Christer Holmberg wrote: > > "This specification updates the procedures in RFC 3264. It defines the usage of a zero port > value in an SDP Offer even if the stream is not removed. In addition, it allows the Answerer > to assign a non-zero port value to a stream in an SDP Answer also in cases where the > stream contained a zero port value in the associated SDP Offer. The updates above only > apply to streams for which an SDP 'bundle-only' attribute has been assigned in the SDP > Offer." Looks good to me. From thomas.stach@unify.com Wed Nov 20 09:30:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D991AE490 for ; Wed, 20 Nov 2013 09:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MibxteHTxfBw for ; Wed, 20 Nov 2013 09:30:16 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DF7C81AE4B7 for ; Wed, 20 Nov 2013 09:30:15 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id C73F51EB84AA; Wed, 20 Nov 2013 18:30:08 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 18:30:08 +0100 From: "Stach, Thomas" To: Martin Thomson , Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update Thread-Index: Ac7hZ01K7HvLlvO5RfSMmrwvGU4Khv//8S6A//okgLCADAABAP//7XIggAAiRYCAAA1mAIABFi+AgABVBYCAAT6BgIAAb86A///u0lA= Date: Wed, 20 Nov 2013 17:30:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> <528B881F.7080102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5466E8@ESESSMB209.ericsson.se> In-Reply-To: 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:30:17 -0000 V29ya3MgZm9yIG1lDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBN YXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gU2VudDog TWl0dHdvY2gsIDIwLiBOb3ZlbWJlciAyMDEzIDE4OjI4DQo+IFRvOiBDaHJpc3RlciBIb2xtYmVy Zw0KPiBDYzogUGF1bCBLeXppdmF0OyBTdGFjaCwgVGhvbWFzOyBSYXZpbmRyYW4sIFBhcnRoYXNh cmF0aGkgKE5TTiAtDQo+IElOL0JhbmdhbG9yZSk7IEFkYW0gUm9hY2g7IG1tdXNpY0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW01NVVNJQ10gQlVORExFIERFQ0lTSU9OIFE4OiBTRFAgJ2J1bmRs ZS1vbmx5JyBhdHRyaWJ1dGUgLQ0KPiBTdWdnZXN0ZWQgMzI2NCB1cGRhdGUNCj4gDQo+IE9uIDIw IE5vdmVtYmVyIDIwMTMgMDI6NDcsIENocmlzdGVyIEhvbG1iZXJnDQo+IDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiA+DQo+ID4gIlRoaXMgc3BlY2lmaWNhdGlvbiB1 cGRhdGVzIHRoZSBwcm9jZWR1cmVzIGluIFJGQyAzMjY0LiBJdCBkZWZpbmVzDQo+IHRoZSB1c2Fn ZSBvZiBhIHplcm8gcG9ydA0KPiA+IHZhbHVlIGluIGFuIFNEUCBPZmZlciBldmVuIGlmIHRoZSBz dHJlYW0gaXMgbm90IHJlbW92ZWQuIEluIGFkZGl0aW9uLA0KPiBpdCBhbGxvd3MgdGhlIEFuc3dl cmVyDQo+ID4gdG8gYXNzaWduIGEgbm9uLXplcm8gcG9ydCB2YWx1ZSB0byBhIHN0cmVhbSBpbiBh biBTRFAgQW5zd2VyIGFsc28gaW4NCj4gY2FzZXMgd2hlcmUgdGhlDQo+ID4gc3RyZWFtIGNvbnRh aW5lZCBhIHplcm8gcG9ydCB2YWx1ZSBpbiB0aGUgYXNzb2NpYXRlZCBTRFAgT2ZmZXIuIFRoZQ0K PiB1cGRhdGVzIGFib3ZlIG9ubHkNCj4gPiBhcHBseSB0byBzdHJlYW1zIGZvciB3aGljaCBhbiBT RFAgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUgaGFzIGJlZW4NCj4gYXNzaWduZWQgaW4gdGhlIFNE UA0KPiA+IE9mZmVyLiINCj4gDQo+IExvb2tzIGdvb2QgdG8gbWUuDQo= From pkyzivat@alum.mit.edu Wed Nov 20 16:19:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F61AE211 for ; Wed, 20 Nov 2013 16:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4Os8EFYUBBV for ; Wed, 20 Nov 2013 16:19:29 -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 B89441AE1E9 for ; Wed, 20 Nov 2013 16:19:28 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id s0Fr1m0021wpRvQ550KNzW; Thu, 21 Nov 2013 00:19:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id s0KM1m00m3ZTu2S3e0KMAs; Thu, 21 Nov 2013 00:19:22 +0000 Message-ID: <528D5189.6020707@alum.mit.edu> Date: Wed, 20 Nov 2013 16:19:21 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Christer Holmberg , "Stach, Thomas" , "Ravindran, Parthasarathi (NSN - IN/Bangalore)" , Martin Thomson , Adam Roach References: <7594FB04B1934943A5C02806D1A2204B1C519A85@ESESSMB209.ericsson.se> <40AFDF4AF1909E4CB42B6D91CE6C419D19C92174@SGSIMBX006.nsn-intra.net>, <7594FB04B1934943A5C02806D1A2204B1C53EE54@ESESSMB209.ericsson.se> <528A5772.3050005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C541B2E@ESESSMB209.ericsson.se> <528B881F.7080102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5466E8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5466E8@ESESSMB209.ericsson.se> 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=1384993162; bh=E5Ai66VNrfzIkCIY+rnLfaBbTxg1tr+uCIP775f8jWk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VNyfFjoCJzyRTw7Uwja1gS3bPOs6TITojONOdnefrnliYkcb/sow8Y5/ldcmz7JjM vBp7Ui6FrUhu6LZEFhjVsPg6wKK6Vw2ze/FbkZZX9BoRxXqDy7dBEAldy4yoY6Di09 mwc5LWDzIjj1wkQFS8fT5woOT3MM44oc6NgmLCSVBVGM2EU8kCGEeqwYEvRBPANBos xqkkE/Oly1ogdCcDoTRxhNdzxSis8+QKVwLSL5xpVUhsXF/JNCc4UYEL8nOa7r/Muq hGqkizeVueFGgXF7/ER0txFgrTo6nszOouL99HwOaaXAyFWnXHqSH1KbaiV/Vqxsv7 tc5uXPt3Cl3MA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 00:19:31 -0000 WFM On 11/20/13 2:47 AM, Christer Holmberg wrote: > So, maybe something like: > > "This specification updates the procedures in RFC 3264. It defines the usage of a zero port > value in an SDP Offer even if the stream is not removed. In addition, it allows the Answerer > to assign a non-zero port value to a stream in an SDP Answer also in cases where the > stream contained a zero port value in the associated SDP Offer. The updates above only > apply to streams for which an SDP 'bundle-only' attribute has been assigned in the SDP > Offer." > > Regards, > > Christer > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 19. marraskuuta 2013 17:48 > To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Adam Roach > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update > > On 11/19/13 2:43 AM, Christer Holmberg wrote: >> Hi, >> >> So, let's do things in steps: >> >> First, does anyone object that we need to, SOMEHOW (we'll discuss the actual text etc later), update RFC 3264? > > I *don't* object - I *do* think we need to indicate formally that 3264 is being updated. > > My logic is that is we don't do that, then it will be impossible to claim simultaneous conformance to bundle-only and 3264 - using bundle-only will of necessity require violating 3264. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 18. marraskuuta 2013 20:08 >> To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - >> IN/Bangalore); Martin Thomson; Adam Roach >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute >> - Suggested 3264 update >> >> On 11/18/13 9:19 AM, Christer Holmberg wrote: >>> Hi, >>> >>> The issue is not whether a 3264 implementation will break or not. >>> >>> The issue is more administrative, and how we are allowed to write >>> standards in IETF. >>> >>> Currently, 3264 says: >>> >>> 1) Port zero in an Offer means that the stream must not be used; and >>> >>> 2) An Offer with port zero must be answered with port zero >>> >>> As far as I know, we can not simply override that by defining an SDP >>> attribute ('bundle-only'). Unless we can move inside the boundaries >>> set by 3264, we need to update 3264. >>> >>> Please correct me if I'm wrong, though. I guess some chair/AD input >>> would be useful here. >> >> I queried Adam for his opinion so we could have unanimity among chairs, but I haven't heard back from him. >> >> I agree with Martin, that we need to formally declare that we are >> updating 3264, but that we don't have to provide an explicit delta to >> 3264 to do so. >> >>> IN ANY CASE, I really hope we are not going to spend too much time on >>> this issue - we have more important things to do. >> >> Agree. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> *From:* Stach, Thomas [thomas.stach@unify.com] >>> *Sent:* Monday, 18 November 2013 6:45 PM >>> *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; >>> Christer Holmberg >>> *Cc:* mmusic@ietf.org; Paul Kyzivat >>> *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' >>> attribute >>> - Suggested 3264 update >>> >>>> >>>> Hi Thomas, >>>> >>>> An answerer compliant with 3264 and not supporting bundle >>>> would ignore a=bundle-only and would set the port=0 in its answer. >>>> >>>> >>>> The above statement clearly shows how RFC 3264 implementation will >>>> break with "bundle-only" attribute proposal. >>> [TS] I'm not sure what 'break' should mean here. If it means "reject >>> the m-line by setting port= in the answer", that is the intended behavior. >>> My statement was based on >>> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section >>> - >>> 3.1 Here, the a=bundle-only attribute is combined with port=0 in the >>> offer. >>> The port=0 in the offer should guarantee that an answerer does not >>> use the m-line. >>>> RFC 3264 would have >>>> properly negotiated in case the port is allocated in the initial >>>> offer instead of port 0. >>> [TS] That is not what a=bundle-only wants to achieve. >>> The semantics of using a valid port in the offer together with >>> a=bundle-only are not clear to me. >>> I would regard that as an invalid combination. >>> >>> Regards >>> Thomas >>>> >>>> Thanks >>>> Partha >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of ext Stach, Thomas >>>> Sent: Monday, November 18, 2013 4:54 PM >>>> To: Martin Thomson; Christer Holmberg >>>> Cc: mmusic@ietf.org; Paul Kyzivat >>>> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' >>>> attribute >>>> - Suggested 3264 update >>>> >>>> Inline >>>> >>>>> On 14 November 2013 10:28, Christer Holmberg >>>>> wrote: >>>>>> I scanned through 3264, in order to find the sections that need to >>>> be >>>>> updated. >>>>> >>>>> >>>>> A direct replacement doesn't seem necessary. We aren't issuing a >>>>> new 3264. A more direct explanation of what 3264 permits or >>>>> prohibits >>>> and >>>>> why this is being changed is probably more important. >>>>> >>>>> Maybe it's as simple as saying something like: >>>>> >>>>> RFC 3264 states that m-lines with zero ports are negotiated off. >>>> This >>>>> document updates RFC 3264 to permit the use of a zero port on >>>>> m-lines in combination with the a=bundle-only attribute. >>>> [TS] I agree with Martin. >>>> An answerer compliant with 3264 and not supporting bundle would >>>> ignore a=bundle-only and would set the port=0 in its answer. >>>> I don't see an issue with an offerer compliant with 3264 and not >>>> supporting bundle, since it wouldn't have included a=bundle-only >>>> (and wouldn't include a larger number of m-lines with port=0). The >>>> answerer supporting bundle would have to set port=0 in the answer to >>>> such an offer in order to comply with 3264. >>>> In my opinion there isn't any change to the procedures in 3264 for >>>> an older implementation, so this isn't an update to 3264. >>>> However, explicit text in bundle that describes this behavior would >>>> be justified. >>>> >>>> >>>> Regards >>>> Thomas >>>> >>>>> _______________________________________________ >>>>> 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 gsalguei@cisco.com Wed Nov 20 22:52:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF271AE0B2 for ; Wed, 20 Nov 2013 22:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGMYEuarMeoj for ; Wed, 20 Nov 2013 22:52:01 -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 7C8511AE0C4 for ; Wed, 20 Nov 2013 22:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1097; q=dns/txt; s=iport; t=1385016714; x=1386226314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jQ0UeBcMxk0nAqQnyMaViFAq09qNWDPDBLYje1Dho/E=; b=c3QKvhTM6tm7cgW15Hr2qKpbQDjF2Srxs5FbIui0msKUKkbLaWeYcRkW a812YbSFxjVe98FF7pY2+tC3GM3LI4CXuPZyyCSvc0Mr+89L0P/TOOn29 2TMwkbniKRpQpqHzcKu5F/MzEi1UXrW8hg/E8MH+HnN5SCF0+wuUYlBsc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAKCsjVKtJXHA/2dsb2JhbABZgwc4U70gToEfFnSCJQEBAQMBAQEBawsFCwIBCEYnCyUBAQQOBYd7Bg3AZhMEjzgzB4MggRIDmBKSEIFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,742,1378857600"; d="scan'208";a="286344395" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 21 Nov 2013 06:51:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAL6prc6018076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 06:51:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 00:51:53 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [MMUSIC] UDPTL-DTLS: Open Issue regarding usage of the SDP connection attribute Thread-Index: Ac7lEyKJHfFouG6mT62OQuu1lxu/kQBpVCUA Date: Thu, 21 Nov 2013 06:51:52 +0000 Message-ID: <4DAEA4CA-B47B-437B-BEAC-9BE23ADEEA62@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C541B0A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C541B0A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.222] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0365C6CBF0CF4F4E94FD545C98690DB7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] UDPTL-DTLS: Open Issue regarding usage of the SDP connection attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 06:52:03 -0000 On Nov 19, 2013, at 2:40 AM, Christer Holmberg wrote: > Hi, > =20 > One of the open issues (indicated in an Editor=92s Note) in the UDPTL-DTL= S draft is regarding the usage of the SDP connection attribute: > =20 > =93Editor's note: FFS if connection attribute defined in RFC 4145 is need= ed.=94 > =20 > The SRTP-DTLS spec forbids the usage of the attribute: > =20 > =93The endpoint MUST NOT use the connection attribute defined in [RFC4145= ].=94 > =20 > =85and I can=92t think of a reason why we should deviate in the UDPTL-DTL= S spec, so my suggestion would be to remove the Editor=92s Note, and explic= itly indicate that the attribute must not be used (same as in RFC 5763). > =20 > Comments? I agree with the change to MUST NOT. No reason I can think of to deviate f= rom SRTP-DTLS with regards to usage of the connection attribute. Gonzalo > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From internet-drafts@ietf.org Thu Nov 21 00:09:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFB1AE0F2; Thu, 21 Nov 2013 00:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKwZ2JIwKsqk; Thu, 21 Nov 2013 00:09:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F671A8028; Thu, 21 Nov 2013 00:09:33 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121080933.9562.80904.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 00:09:33 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 08:09:34 -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 : UDP Transport Layer (UDPTL) over Datagram Transport Laye= r Security (DTLS) Author(s) : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-01.txt Pages : 19 Date : 2013-11-21 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-udptl-dtls-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Thu Nov 21 00:15:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E343F1AC499 for ; Thu, 21 Nov 2013 00:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E1z6gElRsHP for ; Thu, 21 Nov 2013 00:15:19 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA9D31AC448 for ; Thu, 21 Nov 2013 00:15:18 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-56-528dc10e32ce Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F2.68.03802.E01CD825; Thu, 21 Nov 2013 09:15:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Thu, 21 Nov 2013 09:15:09 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Thread-Index: Ac7mkSk0zo3yfrWATZqATJzetabOTA== Date: Thu, 21 Nov 2013 08:15:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C54A8ACESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrS7fwd4ggyO9IhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrwN89kL9lhVfH8m2sC417iLkZNDQsBE4kT7YXYIW0ziwr31 bF2MXBxCAocYJZ5cesAI4SxmlPh26jVQFQcHm4CFRPc/bZAGEQF1ia97e5hBbGEBG4l7f1rZ IeKOEk9a10LZehJ/Dp4Ds1kEVCUWXH/ICGLzCvhKnN7/EizOCLT4+6k1TCA2s4C4xK0n85kg DhKQWLLnPDOELSrx8vE/VghbUeLjq32MEPX5Eg9/X2aBmCkocXLmE5YJjEKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRPTcxMye93GgTIzDoD275rbqD8c45kUOM 0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgFFZZtuZiwR8tT3+WL1sS2DgO 3dQMVNhRL/PI9YDUDdsk+acz7LnCglkfXbrLc8j3zaI/vnaNWj+k3bfdEG7av83/e5Vj/obA hlM6Pkcnpbee31wnKbPYfb3oIUPuloLWfuPni22vlLvbCG5XvvvkQkaTd/5J7/6C6xnOn+sU z73af/vhhUnxSizFGYmGWsxFxYkAGI0N80gCAAA= Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 08:15:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C54A8ACESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi fax lovers, We've submitted a new version (-01) of draft-ietf-mmusic-udptl-dtls. CHANGES: In addition to some editorial fixes, the changes, based on e-mail discussio= ns, are: - SDP offerer is allowed to assign an a=3Dsetup:active or a=3Dsetu= p:passive value, in addition to the recommended a=3Dsetup:actpass - The example for secure fax replacing audio stream in audio-only = session added - Editor's note on the connection attribute resolved by prohibitin= g usage of the SDP connection attribute OPEN ISSUES: There is still an open issue in section 4.2, which is more editorial than t= echnical. Comments and input is welcome. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C54A8ACESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi fax lovers,

 

We’ve submitted a new version (-01) of draft-i= etf-mmusic-udptl-dtls.

 

CHANGES:

 

In addition to some editorial fixes, the changes, ba= sed on e-mail discussions, are:

 

-     &= nbsp;    SDP offerer is allowed to assign an a=3Dsetup:activ= e or a=3Dsetup:passive value, in addition to the recommended a=3Dsetup:actp= ass

-     &= nbsp;    The example for secure fax replacing audio stream i= n audio-only session added

-     &= nbsp;    Editor's note on the connection attribute resolved = by prohibiting usage of the SDP connection attribute

 

 

OPEN ISSUES:

 

There is still an open issue in section 4.2, which i= s more editorial than technical. Comments and input is welcome.<= /p>

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C54A8ACESESSMB209erics_-- From gonzalo.camarillo@ericsson.com Thu Nov 21 02:24:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D871AD8E3 for ; Thu, 21 Nov 2013 02:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpSMNspQgeFM for ; Thu, 21 Nov 2013 02:24:03 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 218911ACCEA for ; Thu, 21 Nov 2013 02:24:02 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-cb-528ddf205acb Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D7.E7.15980.02FDD825; Thu, 21 Nov 2013 11:23:28 +0100 (CET) Received: from [131.160.36.120] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Thu, 21 Nov 2013 11:23:14 +0100 Message-ID: <528DDF12.6030701@ericsson.com> Date: Thu, 21 Nov 2013 12:23:14 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvra7l/d4gg3NGFlOXP2ZxYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGwhW/mAqOMFesXvmAvYHxJVMXIyeHhICJxL1Vt1kgbDGJC/fW s3UxcnEICRxilLi65QMrhLOGUeL69zmsIFW8AtoSy1fuBetmEVCV2PLkBRuIzSZgIbHl1n2w SaICURLnz0Fs4BUQlDg58wlYXERAVOLRxUVgc4QFDCXeNc4H6uUA2iwu0dMYBBJmFtCTmHK1 hRHClpfY/nYOM4gtBLL2WQvLBEb+WUimzkLSMgtJywJG5lWM7LmJmTnp5eabGIHBdHDLb4Md jJvuix1ilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo1y3lW3009lO3s83 fz904qnHghRd9WmfFqY+OrfuQ8AGP9WpCj9qWTluHdlxK0/SRVt93r69MpHPPyzTmeax5tZW dv3bHXY5NnMCWhMSZOXD5rIy2rSZ7Gxt+n/q/IF/1262f+z/e4ZBd9fGTU8OT8+PcFt68/yJ rIS9/guOzYm/6VPFO1Nv9xwlluKMREMt5qLiRACpoAvc9AEAAA== Subject: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 10:24:04 -0000 Folks, the IESG is reviewing the RTSP 2.0 spec below: http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ Before progressing the draft, I have been asked by the IESG to check with the MMUSIC WG whether or not people still think it is worthwhile publishing this spec. In particular, they would like to know what level of deployment we can expect once the spec is published. Your input is appreciated. Thanks, Gonzalo From abegen@cisco.com Thu Nov 21 02:38:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A3C1ADFBC for ; Thu, 21 Nov 2013 02:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0xTSlwhZzUq for ; Thu, 21 Nov 2013 02:38:29 -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 CD5011ADFB7 for ; Thu, 21 Nov 2013 02:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1610; q=dns/txt; s=iport; t=1385030302; x=1386239902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hAH+1Muxc3OOQ1q7UtWBpD2uqLqpXpwU2RhxrU/9IoA=; b=EcDY5WM29w+cKTYEsfblVtivn0QW5+d7v/JU4F+yaUrXIR6tCc7zQAHX 9OiT/4XxIM/wtRS9uw0I68Sb28I+RbAAwIj1if6KMHExiNkuzBDdjv2EY F+HPuV19T4i2DnOAZM1eel67hFyEkwwxBSHcmVIbIQ4G+AURMqmpZNz9A c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAEvijVKtJV2b/2dsb2JhbABZgmYhOFO8Lk6BHxZ0giUBAQEDAQEBATc0CwULAgEINhAnCyUCBA4Fh3sGAQzAWxePODMHgyCBEgOYEoEwkGCDKIIq X-IronPort-AV: E=Sophos;i="4.93,743,1378857600"; d="scan'208";a="286577909" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 21 Nov 2013 10:38:22 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rALAcMCP003799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 10:38:22 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 04:38:21 -0600 From: "Ali C. Begen (abegen)" To: Gonzalo Camarillo Thread-Topic: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis Thread-Index: AQHO5qPO/tHe3jytkUWT0R0uH9FYH5ov4uWA Date: Thu, 21 Nov 2013 10:38:21 +0000 Message-ID: <0C52DDFC-9792-48BB-89AF-09FB022F5159@cisco.com> References: <528DDF12.6030701@ericsson.com> In-Reply-To: <528DDF12.6030701@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <398C46BC59CB3349ADED55958189C51E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 10:38:30 -0000 I am feeling terrible to say this as obviously much effort has gone into th= is document. But to me, this spec is simply too late to have any chance to get deployed.= Today there are lots of massive RTSP based streaming systems, yet they are= obsolete and present lots of scalability and management issues. They also = have lots of interop issues as not every vendor actually implemented RTSP i= n the same way. Providers are not very eager to ditch these systems right a way. The ones t= hat pull the trigger are mostly ditching RTSP altogether and moving towards= http/cdn based streaming. Chances are quite slim for them to switch from R= TSP 1.0 to RTSP 2.0. Needless to say, RTSP is a difficult protocol to both = implement and deploy/manage. Whether this should this draft from moving forward, that is a separate disc= ussion, I think. On Nov 21, 2013, at 12:23 PM, Gonzalo Camarillo wrote: > Folks, >=20 > the IESG is reviewing the RTSP 2.0 spec below: >=20 > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ >=20 > Before progressing the draft, I have been asked by the IESG to check > with the MMUSIC WG whether or not people still think it is worthwhile > publishing this spec. In particular, they would like to know what level > of deployment we can expect once the spec is published. >=20 > Your input is appreciated. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Thu Nov 21 02:55:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006E91ADFBC for ; Thu, 21 Nov 2013 02:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyJ2N0Q61YvO for ; Thu, 21 Nov 2013 02:55:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 918DB1AD958 for ; Thu, 21 Nov 2013 02:55:12 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-0b-528de689277d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BC.D1.03802.986ED825; Thu, 21 Nov 2013 11:55:05 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Thu, 21 Nov 2013 11:55:04 +0100 Message-ID: <528DE688.6010402@ericsson.com> Date: Thu, 21 Nov 2013 11:55:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Gonzalo Camarillo , References: <528DDF12.6030701@ericsson.com> In-Reply-To: <528DDF12.6030701@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+JvrW7ns94gg8szBSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK7uxywFDZIVv/etZmtgnCPSxcjJISFgInF00hpGCFtM4sK9 9WxdjFwcQgKHGCWOvlzNCuEsZ5TYO2syK0gVr4C2xJu5U5hAbBYBVYn1x54zg9hsAhYSN380 soHYogLBEld71zFD1AtKnJz5hAXEFhHwlHi59yfYNmEBO4mZH0+AzRQCmjm3ZwpYPaeAjsTe s1PZuxg5gC4Sl+hpDAIJMwsYSBxZNIcVwpaXaN46mxmmtaGpg3UCo+AsJNtmIWmZhaRlASPz Kkb23MTMnPRyo02MwPA7uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNa fIiRiYNTqoHRuL37R5r1s3Ne70urFXStj01++8D/a0GMwV19G7nzt43D139LcxbeNccwNy3v 726u/8+iwjzfr+0p1jnMdsN02anjM672l12XshKdEiC7UesYZ0GwydbZJjmlzl8tg6bxycXr L7dvfcFzOeTFgmkZXed8Ga/ZZHknBDqtZly49+Pi+Wk+6jFKLMUZiYZazEXFiQD7LgMHDQIA AA== Subject: Re: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 10:55:15 -0000 On 2013-11-21 11:23, Gonzalo Camarillo wrote: > Folks, > > the IESG is reviewing the RTSP 2.0 spec below: > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > Before progressing the draft, I have been asked by the IESG to check > with the MMUSIC WG whether or not people still think it is worthwhile > publishing this spec. In particular, they would like to know what level > of deployment we can expect once the spec is published. > Hi, I know that 3GPP in TS 26.234 (12.1.0) do reference a feature in RTSP 2.0: Section N.2 “RTP over TCP” (RFC4571): The RTP packets are tunnelled over separate TCP connections. A major difference compared to the “RTSP/RTP Interleaving” mode (RFC 2326) is, that the client opens one or more separate TCP connections to the server for the RTP transport. This mechanism is described in the RTSP 2.0 draft (draft-ietf-mmusic-rfc2326bis-18.txt). Thus, I expect this reference to be updated when RTSP 2.0 gets implemented. I would also note that PSS (in section 5.5.2 of 26.234) have back fitted several of RTSP 2.0 specification features into their RTSP 1.0 usage. These include: - Supported header - Pipelining They also have their own versions of time-shift handling and asynchronous notifications. I have also received this email from Scott Taylor (scott.taylor@immersaview.com) > Thank you for your work putting together the RTSP 2.0 spec. It's > exactly what I needed to address the shortcomings of RTSP 1.0 in my > current project. I'm the lead developer on a software product that > performs live streaming, synchronized recording and playback of > simulation environments. I think this points to that RTSP has other uses than just normal audio/video and that there exist other cases where one needs control of playout and transmission of inter time related information or streams. I think there are several arguments why RTSP 2.0 should be published even if there is no response to question for implementing RTSP 2.0. 1. That the future consumers of RTSP 2.0 specification may not even know they needed it at this point 2. That leaving in place without warning a broken specification like RTSP 1.0 is bad considering that we have a specification that has less issues. So why not publish it? If IESG are worried about the effect of obsoleting RTSP 1.0, then lets discuss that issue. Not stopping publication of RTSP 2.0. 3. There are features in use out on the network in RTSP 1.0 that are primarily specified in RTSP 2.0. The fact that we in IETF couldn't keep the version number hasn't stopped industry forums to use the specified extensions and deploy them within RTSP 1.0. 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 internet-drafts@ietf.org Thu Nov 21 11:31:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507671AE202; Thu, 21 Nov 2013 11:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EGnV-3Lah5s; Thu, 21 Nov 2013 11:31:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E50781AE174; Thu, 21 Nov 2013 11:31:57 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121193157.12090.83051.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 11:31:57 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-duplication-grouping-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:31:59 -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 : Duplication Grouping Semantics in the Session Descriptio= n Protocol Author(s) : Ali Begen Yiqun Cai Heidi Ou Filename : draft-ietf-mmusic-duplication-grouping-04.txt Pages : 9 Date : 2013-11-21 Abstract: Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-duplication-grouping-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Christian.Groves@nteczone.com Thu Nov 21 14:58:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DBB1AE3E9 for ; Thu, 21 Nov 2013 14:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.435 X-Spam-Level: *** X-Spam-Status: No, score=3.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE3ZSfqLarzh for ; Thu, 21 Nov 2013 14:58:18 -0800 (PST) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446EA1AE3E8 for ; Thu, 21 Nov 2013 14:58:18 -0800 (PST) Received: from ppp118-209-100-27.lns20.mel4.internode.on.net ([118.209.100.27]:54577 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VjdC5-00035p-N3 for mmusic@ietf.org; Fri, 22 Nov 2013 09:57:53 +1100 Message-ID: <528E8FFF.3030405@nteczone.com> Date: Fri, 22 Nov 2013 09:58:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <528DDF12.6030701@ericsson.com> In-Reply-To: <528DDF12.6030701@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 22:58:19 -0000 Hello I would support publishing this spec. Draft ITU-T H.248.66 makes reference to the RTSP2.0 work. It has been held up for a couple of years waiting for the RTSP2.0 draft to be published. It would be good to put this to bed. Regards, Christian On 21/11/2013 9:23 PM, Gonzalo Camarillo wrote: > Folks, > > the IESG is reviewing the RTSP 2.0 spec below: > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > Before progressing the draft, I have been asked by the IESG to check > with the MMUSIC WG whether or not people still think it is worthwhile > publishing this spec. In particular, they would like to know what level > of deployment we can expect once the spec is published. > > Your input is appreciated. > > Thanks, > > Gonzalo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From oscar.ohlsson@ericsson.com Fri Nov 22 01:18:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80C1AE337 for ; Fri, 22 Nov 2013 01:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZLzBq4_ueUq for ; Fri, 22 Nov 2013 01:18:44 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 660811AE32A for ; Fri, 22 Nov 2013 01:18:40 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-ed-528f216854a9 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 91.84.27941.8612F825; Fri, 22 Nov 2013 10:18:32 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.247]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 22 Nov 2013 10:18:31 +0100 From: Oscar Ohlsson To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Thread-Index: Ac7mkSk0zo3yfrWATZqATJzetabOTAAyKbLg Date: Fri, 22 Nov 2013 09:18:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW6GYn+QwYe7RhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpx3DcwFu4UqOmZ8ZWlgfMLXxcjJISFgInHj5FQmCFtM4sK9 9WwgtpDAEUaJV33mXYxcQPYSRonuf4vAitgEDCRu3T/JAmKLCMRKfF33HiwuLOAgMfP0QiaI uKPEk9a17BC2kcTp5u9g9SwCqhLPLx1hBLF5BXwlLvTdZYJY5itx4tE8MJtTwE+ie0UXWC+j gKzE/e/3wHqZBcQlbj2ZD3WogMSSPeeZIWxRiZeP/7F2MXIA2YoSy/vlIMp1JBbs/sQGYWtL LFv4mhliraDEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyipGjOLU4KTfdyGATIzDsD275bbGD 8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgPLJuq0yKzOOsg1mc BxsnvtVofvLTKUsgu3SH3GauNfaRKhcXREwOytNgWd6ZmGC+vpZRl/fBXutzK3b0zv/G161d 7ayhwH6vUNq4zEGDR/LYRHPL5bs0tvJGf7m0O5A1ZeP1uKt9bDdn5q8z0d9hvptziey7MFur M61b71xgkJvuorT9s0CVEktxRqKhFnNRcSIAEwAz5kkCAAA= Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:18:45 -0000 Hi, I have a comment on the usage of the fingerprint attribute in draft-ietf-mm= usic-udptl-dtls-01. In future versions of 3GPP TS 33.328 we would like to u= se UDPTL-DTLS in combination with MIKEY-TICKET. In that case there is no e= xchange of certificate fingerprints; instead the offerer and answerer negot= iates a secret key over SDP and then runs a DTLS-PSK handshake. The problem= is that draft-ietf-mmusic-udptl-dtls-01 currently forbids other types of k= ey management protocols: o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. o If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects. I would suggest that you make the requirements related to certificate finge= rprints conditional, e.g. by adding a statement similar to this: In case DTLS is used with a pre-shared key ciphersuite (RFC 4279) the re= quirements related to certificate verification=20 and inclusion of certificate fingerprints do not apply. How the pre-shar= ed key is made available to the endpoints=20 is out of scope of this specification.=20 Regards, Oscar Ohlsson From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: den 21 november 2013 09:15 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 Hi fax lovers, We've submitted a new version (-01) of draft-ietf-mmusic-udptl-dtls. CHANGES: In addition to some editorial fixes, the changes, based on e-mail discussio= ns, are: - SDP offerer is allowed to assign an a=3Dsetup:active or a=3Dsetup:passive= value, in addition to the recommended a=3Dsetup:actpass=20 - The example for secure fax replacing audio stream in audio-only session a= dded=20 - Editor's note on the connection attribute resolved by prohibiting usage o= f the SDP connection attribute=20 OPEN ISSUES: There is still an open issue in section 4.2, which is more editorial than t= echnical. Comments and input is welcome. Regards, Christer From Simo.Veikkolainen@nokia.com Fri Nov 22 04:34:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847C1ADBF7 for ; Fri, 22 Nov 2013 04:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoHl4gWu2gYv for ; Fri, 22 Nov 2013 04:34:50 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id CF6A21AD9B8 for ; Fri, 22 Nov 2013 04:34:49 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.24]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rAMCRJPR021494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 22 Nov 2013 14:27:20 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.50]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.03.0136.001; Fri, 22 Nov 2013 12:27:19 +0000 From: To: , Thread-Topic: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs Thread-Index: Ac7kg/s/Ox1+oezCTIqy8+w+xBQcogABoWsAALy6IgA= Date: Fri, 22 Nov 2013 12:27:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C53FE70@ESESSMB209.ericsson.se> <528A59D4.9040504@alum.mit.edu> In-Reply-To: <528A59D4.9040504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.80.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmusic-sdp-cs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 12:34:52 -0000 Hi, I'm not actively following the list, but Christer kindly pinged me off-list= . For some reason I could not find Christian Groves' email (http://www.ietf= .org/mail-archive/web/mmusic/current/msg12771.html) in my inbox where he w= rites: --- I think the last sentence: /"Usage of "E164" address type in conjunction wi= th other network types may be defined elsewhere."/ could potentially be con= fusing. I think this sentence is referring to that the E164 address defined= by [SDP-CS] could be used elsewhere. Whereas the RFC3105 usage of E164 is = distinct from [SDP-CS]. I think that after our discussion regarding the IANA registration its clear= that Address type is dependent on Network Type. So I would be included to = remove the above sentence and just indicate that E164 defined by [SDP-CS] i= s used exclusively for nettype PSTN. You could add a note to the effect: "Note: RFC3105 also defines address typ= e E164. This definition is distinct from the one defined by [SDP-CS] and sh= all not be used with nettype PSTN." --- =20 The proposed text sounds good to me as well; we can add it in the next vers= ion. Simo PS. The RFC number in question is RFC3108, not RFC3105. -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: 18 November, 2013 20:18 To: mmusic@ietf.org Subject: Re: [MMUSIC] E164 address type in both RFC 3108 and draft-ietf-mmu= sic-sdp-cs On 11/18/13 9:31 AM, Christer Holmberg wrote: > Hi, > > RFC 3108 (SDP for ATM) defines an 'E164' address type value. When used, > the associated address value is "up to 15 decimal digits". > > Example: c=3DATM E164 9738294382 > > draft-ietf-mmusic-sdp-cs-21 also defines an 'E164' address type value, > with a slightly different syntax for the associated address value: > > - an international E.164 number (prepended with a '+' sign); or > - the value "-", signifying that the address is unknown > > Now, the sdp-cs draft DOES say: > > "Please note that the "E164" address type defined in this memo i= s > exclusively defined to be used in conjunction with the "PSTN" > network > type in accordance with [RFC4566]. Usage of "E164" address type = in > conjunction with other network types may be defined elsewhere." > > ...and, in 3108 the network type value is "ATM", so. > > I just wonder whether it would be useful to, in sdp-cs, give 3108 as an > example of where "E164" is defined for another network type, and with a > different syntax? I wouldn't object, but neither do I find it necessary to do this. I wasn't aware of 3108 when it was being standardized. I find its use of=20 "E164" perverted, since it explicitly allows non-E164 values to be used,=20 and doesn't even define how such numbers are to be interpreted. It should have used something other than "E164". But I guess it is too=20 late to "fix" that. Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From eckelcu@cisco.com Fri Nov 22 10:54:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621CF1AE19B for ; Fri, 22 Nov 2013 10:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.226 X-Spam-Level: X-Spam-Status: No, score=-8.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeV-R0FexGp8 for ; Fri, 22 Nov 2013 10:54:48 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8A11AE0DC for ; Fri, 22 Nov 2013 10:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15591; q=dns/txt; s=iport; t=1385146480; x=1386356080; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+M8NcPzgf+EZIod+6egnq8K4YeCfQ28WMu0NvJx9Ol8=; b=UfItQr54VZ6pIhYGVF8E/rlWkLez4cGkSX3QnWqBn4o0iP63hYSUrj/I nD/xMMg8odT8KI4FWpscviUCG2/XFeCoo3nWLTRMwQwCzA6PXi75fU2yK lLdFEA0xVwzT0NsBEKafyLxw1k1DrM5/gTugxhOrpIXHjXmEcEUoMrbdm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FABmoj1KtJXHB/2dsb2JhbABZgwc4U7tHToEiFnSCJQEBAQQBAQEJXAYLDAYBCBEEAQEBJy4LFAkIAgQBDQUJCweHZQENwRgXjjAGAQEcMwIFBoQsA4kKimVCg2OSEoMogWkIFyI X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="scan'208";a="1573344" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-3.cisco.com with ESMTP; 22 Nov 2013 18:54:39 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAMIseZS009380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 18:54:40 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 12:54:40 -0600 From: "Charles Eckel (eckelcu)" To: "Gonzalo Salgueiro (gsalguei)" , Christer Holmberg Thread-Topic: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHO4N5p9ObMK+oa+UC3S7P1Fu4dKZoknjaAgAKwh4CACjaVAA== Date: Fri, 22 Nov 2013 18:54:39 +0000 Message-ID: In-Reply-To: <81FDCDD8-6BDD-4D64-8D22-00A750E0289F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [171.68.20.21] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:54:51 -0000 Within the BFCPBIS working group, we debated this same point. In the end, we decided it was best to align with RFC 5763. Here is the thread for your reference: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00167.html Cheers, Charles On 11/15/13 2:56 PM, "Gonzalo Salgueiro (gsalguei)" wrote: >TBH I didn't see a compelling reason to make the change in the first >place. If it is important to Albrecht, I think this proposal is fine and >seems innocuous to the proposed solution. > >Gonzalo > > >On Nov 14, 2013, at 12:52 AM, Christer Holmberg > wrote: > >> Hi, >>=20 >> I guess 'SHOULD use actpass' would work. >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Sony Ericsson Xperia arc S >>=20 >> Paul Kyzivat wrote: >>=20 >>=20 >> I believe that the a=3Dsetup attribute was first defined by rfc 4145, fo= r >>TCP. >>=20 >> There it governs who listens for an incoming connection. And the main >> concern was that NATs/FWs might prevent one end or the other from >> accepting incoming connections. Even so, it didn't have any normative >> behavior about what should be in the offer. >>=20 >> As this same attribute is used in different contexts, the implications >> of using it may vary. In particular, if it is intended that either end >> should be able to take either the active or passive role, then the >> considerations for use may vary. >>=20 >> ISTM that actpas SHOULD be used in the offer, except in cases where the >> offerer has a particular preference for active or passive, and would >> prefer to have the connection fail than use the other mode. >>=20 >> Thanks, >> Paul >>=20 >> On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote: >>> Right. >>>=20 >>>=20 >>>------------------------------------------------------------------------ >>> *Von:* Christer Holmberg [christer.holmberg@ericsson.com] >>> *Gesendet:* Donnerstag, 14. November 2013 02:21 >>> *An:* Schwarz, Albrecht (Albrecht) >>> *Cc:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>>=20 >>> Hi Albrecht, >>>=20 >>> If I understand your proposal correctly, the change would be to relax >>> the rule for assigning the SDP setup attribute value in the SDP Offer. >>> Instead of mandating actpass, we would also allow active and passive. >>>=20 >>> Right? >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> *L=E4hetetty:* 14. marraskuuta 2013 3:11 >>> *Vastaanottaja:* Christer Holmberg >>> *Kopio:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >>> *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>>=20 >>> Hello Christer, >>> guess it's time to come back on this topic since the WG adopted the >>>draft. >>>=20 >>> In brief ("don't want to repeat again the thread"): >>> a) problem statement: existing SDP O/A rules define a tighly coupled >>> mode between the establishment direction of the SIP session and the >>> establishment direction of the DTLS session, but there's not any >>> reasoning for such tightly coupled behaviour. >>>=20 >>> b) change proposal: >>> Revise in clause 3.1 following list item >>>=20 >>> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>>=20 >>> offerer MUST assign the SDP setup attribute with setup:actpass >>>=20 >>> value, and MUST be prepared to receive a DTLS client_hello >>>message >>>=20 >>> before it receives the SDP answer. The answerer MUST assign the >>>=20 >>> SDP setup attribute with either setup:active value or >>>=20 >>> setup:passive value. The answerer SHOULD assign the SDP setup >>>=20 >>> attribute with the setup:active value. Whichever party is active >>>=20 >>> MUST initiate a DTLS handshake by sending a ClientHello over each >>>=20 >>> flow (host/port quartet). >>>=20 >>>=20 >>> by >>>=20 >>> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>>=20 >>> offerer MUST assign the SDP setup attribute with a setup:actpass, >>> setup:active or setup:passive >>>=20 >>> value, and, in case of setup:actpass or setup:passive, MUST be >>> prepared to receive a DTLS client_hello message >>>=20 >>> before it receives the SDP answer. The answerer MUST assign the >>>=20 >>> SDP setup attribute with either setup:active value or >>>=20 >>> setup:passive value. The answerer SHOULD assign the SDP setup >>>=20 >>> attribute with the setup:active value, in case of setup:actpass >>> or setup:passive. Whichever party is active >>>=20 >>> MUST initiate a DTLS handshake by sending a ClientHello over each >>>=20 >>> flow (host/port quartet). >>>=20 >>>=20 >>> We would limit ourselves with the existing, restrictive SDP O/A rule. >>> And without any justification for such a constraint. >>>=20 >>> Any comments? >>>=20 >>> Regards, >>> Albrecht >>>=20 >>>=20 >>>=20 >>>------------------------------------------------------------------------ >>>=20 >>> *Von:*Christer Holmberg [christer.holmberg@ericsson.com] >>> *Gesendet:* Montag, 7. Oktober 2013 13:11 >>> *An:* Schwarz, Albrecht (Albrecht) >>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>>=20 >>> Hi Albrecht, >>>=20 >>> At this point, the community is making a decision about whether to >>>start >>> working on this. >>>=20 >>> Once that is done, we will start looking into, and discuss, individual >>> technical issues etc, and your input will be highly appreciated. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> *L=E4hetetty:* 7. lokakuuta 2013 13:56 >>> *Vastaanottaja:* Christer Holmberg >>> *Kopio:* mmusic@ietf.org ; LANDAIS, BRUNO >>>(BRUNO) >>> *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>>=20 >>> Hello Christer, >>>=20 >>> I may not commit to submit a problem statement in the next couple of >>> weeks, just due to time reasons. >>>=20 >>> At least a note (or editor=B9s note) should be added to draft >>> mmusic-udptl-dtls in order to indicate the issue and that a solution >>> proposal is still pending. >>>=20 >>> Thanks, >>>=20 >>> Albrecht >>>=20 >>> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> *Sent:* Dienstag, 24. September 2013 16:01 >>> *To:* Schwarz, Albrecht (Albrecht) >>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>>=20 >>> Hi Albrecht, >>>=20 >>> I don't think putting a note somewhere in the fax draft is going to >>> solve anything. >>>=20 >>> As you indicate, the issue exists in multiple documents, so it's a >>> generic issues. >>>=20 >>> So, my suggestion is that you put together a short draft which >>>describes >>> the problem, and how you want to change it, and then we can have a more >>> generic discussion about it. The WG can then decide whether we shall >>>fix >>> something, and if so, in which specs. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>------------------------------------------------------------------------ >>>=20 >>> *From:*Schwarz, Albrecht (Albrecht) >>>[albrecht.schwarz@alcatel-lucent.com] >>> *Sent:* Tuesday, 24 September 2013 4:22 PM >>> *To:* Christer Holmberg >>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>>=20 >>> Hello Christer, >>>=20 >>> the "copy & paste" action (across at least three "RFCs") seems to be >>>the >>> root cause of the issue :-( >>>=20 >>> SIP session establishment and L4 security session (DTLS, TLS) >>> establishment directions should be principally decoupled because >>> application specific. >>>=20 >>> We got here (wrt DTLS) three (different!) applications: >>> 1) Key exchange (RFC 5763) >>> 2) Conference control (rfc4582bis) >>> 3) Document transmission (udptl-dtls) >>>=20 >>> All three applications are different in terms of number/type of >>> supported network models, security models or/and communication >>>topology. >>>=20 >>> Consequently, the basic, application independent SDP O/A rules for DTLS >>> session establishment would need to support that flexibility. >>> The application specific SIP/SDP profile could then still narrow down >>> the required SDP O/A rules. >>>=20 >>> What we got so far: SDP O/A rules in three application specific "RFCs" >>> (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( >>>=20 >>> There might be two options to correct that copy & paste issue in >>> "udptl-dtls" in my opinion: >>> a) expand the SDP O/A rules for more flexibility >>> or >>> b) add a WARNING / NOTE about the inherent limitations (due to the >>> assumption of a network and communication environment according RFC >>>5763) >>>=20 >>> What do you think? >>> Best regards, >>> Albrecht >>>=20 >>>=20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Montag, 23. September 2013 11:54 >>> To: Schwarz, Albrecht (Albrecht) >>> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>>=20 >>> Hi Albrecht, >>>=20 >>> I don't know what model people were focusing on when writing RFC 5763, >>> but the RFC does say: >>>=20 >>> "The endpoint that is the offerer MUST use the setup attribute value of >>> setup:actpass" >>>=20 >>> ...which we also copied into the udptl-dtls draft. >>>=20 >>> Now, if you want to change that, and allow the Offerer to "force" the >>> direction, I think you should start a separate thread about that. >>> Because, it is not specific to fax, in my opinion. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> Sent: 23. syyskuuta 2013 12:31 >>> To: Christer Holmberg >>> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>>=20 >>> Hello Christer, >>>=20 >>> the decision about "DTLS session establishment direction" is ALWAYS up >>> to the SDP ANSWERER (according present 3.1). >>>=20 >>> In order to decouple SIP session and DTLS session establishment >>> directions, then the SDP OFFERER should also to be able to use >>> "setup:active" and "setup:passive" (besides codepoint "setup:actpass") >>> in my understanding. >>>=20 >>> I'm not sure whether the reference to RFC 5763 helps because I could >>> imagine that the subject comes down to the indicated network scenarios, >>> lets look again at: >>> a) T - T >>> b) T -GW >>>=20 >>> The existing udptl-dtls & RFC 5763 text seems to focus on model (a) >>> only: SDP O/A between two peering, terminal located SIP UAs (there is >>> NOT any SIP B2BUA). >>> But I could imagine that the SIP/SDP profiles for "T" and "GW" are not >>> necessarily the same in case of model (b): "T" as SDP Offerer may not >>> allowed to decide the DTLS session establishment direction, but "GW" as >>> SDP offerer may need to enforce the DTLS session establishment >>>direction >>> (either way). >>>=20 >>> Regards, >>> Albrecht >>>=20 >>>=20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Donnerstag, 19. September 2013 10:02 >>> To: Schwarz, Albrecht (Albrecht) >>> Cc: mmusic@ietf.org >>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>>=20 >>> Hi Albrecht, >>>=20 >>> The direction of the SIP session establishment and the DTLS session >>> establishment are NOT tightly coupled. The draft enables the Answerer >>>to >>> select whether it wants to act as DTLS client or DTLS server. >>>=20 >>> Section 3.1 states: >>>=20 >>> .... The >>> offerer MUST assign the SDP setup attribute with setup:actpass value, >>> and MUST be prepared to receive a DTLS client_hello message before it >>> receives the SDP answer. The answerer MUST assign the SDP setup >>> attribute with either setup:active value or setup:passive value. The >>> answerer SHOULD assign the SDP setup attribute with the setup:active >>> value. Whichever party is active MUST initiate a DTLS handshake by >>> sending a ClientHello over each flow (host/port quartet). >>>=20 >>> The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, >>> we base the procedure on that RFC. >>>=20 >>> BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the >>> DTLS-SRTP procedures for DTLS server determination. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> Sent: 18. syyskuuta 2013 18:28 >>> To: Christer Holmberg >>> Cc: mmusic@ietf.org >>> Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session >>>=20 >>> The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a >>> gateway, leading to three possible scenarios of >>> a) T - T >>> b) T -GW >>> c) GW-GW >>>=20 >>> I'd like to scope on scenario (b) due to its asymmetry of user- and >>> network-side located T.38 endpoints. >>>=20 >>> Christer, >>> I thought that the two directions of >>> 1) SIP session establishment and >>> 2) DTLS session establishment >>> should be NOT tightly coupled (as currently supposed to be in clause >>>3.1)? >>> The ietf draft should offer the flexibility in decoupling both >>> establishment directions. >>>=20 >>> E.g., there might be the demand to limit DTLS session establishment in >>> T-to-GW direction (and apply rather the reverse direction) due >>> ClientHello associated security threats, resource requests in terms of >>> memory, ... >>>=20 >>> In my opinion: >>> the IETF should allow the flexibility, >>> other SDOs could still profile/limit this capability. >>>=20 >>> Best regards, >>> Albrecht >>>=20 >>> PS >>> We had a similar discussion with TLS, there NAT traversal (NAT-T) >>> aspects could influence TLS session establishment direction. However, I >>> guess that NAT-T is minor for DTLS/UDP. >>>=20 >>>=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 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Sat Nov 23 04:39:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0601AE2CD for ; Sat, 23 Nov 2013 04:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQrd47GHJ_On for ; Sat, 23 Nov 2013 04:39:41 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62D8C1AD628 for ; Sat, 23 Nov 2013 04:39:40 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-5d-5290a2030775 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 43.FF.23787.302A0925; Sat, 23 Nov 2013 13:39:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Sat, 23 Nov 2013 13:39:31 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHO4NZi9flj5ss1UEu1a/Ao76gxKJoj7Uow///yroCAAApaAIAAT18pgAKfw4CACryzgIABOkjS Date: Sat, 23 Nov 2013 12:39:31 +0000 Message-ID: References: <81FDCDD8-6BDD-4D64-8D22-00A750E0289F@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrS7zoglBBnOem1lsmvWFzWLuFD+L qcsfs1is2HCA1YHF4+/7D0weU35vZPVYsuQnUwBzFJdNSmpOZllqkb5dAlfGuZMLWAuaqyvm T0puYNyW0sXIySEhYCLx7tELNghbTOLCvfVANheHkMAhRomL+46wQjiLGSXWHL3C0sXIwcEm YCHR/U8bpEFEIENiRtdpVhCbWcBX4v3P6ewgtrBAmMSn85PYIGrCJTr+3YGyoyS27rsNNoZF QFXibqsAiMkr4CbR1KcDUiEkEC/x7fNTZhCbU0BfYsncxWDTGYFO+35qDRPEJnGJW0/mM0Gc LCCxZM95ZghbVOLl439Q1+hJ3Jg6hQ3C1pZYtvA1WA2vgKDEyZlPWCYwis5CMmoWkpZZSFpm IWlZwMiyipE9NzEzJ73ccBMjMEIObvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamBse+kuvGDVsruMT4V7Au5Nly7u+f2Ux/t0ozZX7N6UU3rizc5n47rX VpxdsFzxAsPPEzMuvfogWbJbL+T60tdzby1gYO6/F9A6OWZDjJLozdsc6/muPC7+/XBtXR1j /ASt6KtXGVS9b5a8t9WwWWizTvxgzALz39n3Ds5arpiq4m1Y8SLtyNa/SizFGYmGWsxFxYkA OKxZel4CAAA= Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 12:39:45 -0000 Hi Charles, In the thread you refer to, I don't think you considered the alternative we= are discussing now :) The discussion was more about whether the setup attribute shall be used to = determine the TLS role to begin with, and the outcome was that the attribut= e IS used. We are NOT changing that for UDPTL-DTLS, we are simply relaxing = the MUST-indicate-actpass-in-the-offer rule. Regards, Christer Sent from my Sony Ericsson Xperia arc S "Charles Eckel (eckelcu)" wrote: Within the BFCPBIS working group, we debated this same point. In the end, we decided it was best to align with RFC 5763. Here is the thread for your reference: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00167.html Cheers, Charles On 11/15/13 2:56 PM, "Gonzalo Salgueiro (gsalguei)" wrote: >TBH I didn't see a compelling reason to make the change in the first >place. If it is important to Albrecht, I think this proposal is fine and >seems innocuous to the proposed solution. > >Gonzalo > > >On Nov 14, 2013, at 12:52 AM, Christer Holmberg > wrote: > >> Hi, >> >> I guess 'SHOULD use actpass' would work. >> >> Regards, >> >> Christer >> >> Sent from my Sony Ericsson Xperia arc S >> >> Paul Kyzivat wrote: >> >> >> I believe that the a=3Dsetup attribute was first defined by rfc 4145, fo= r >>TCP. >> >> There it governs who listens for an incoming connection. And the main >> concern was that NATs/FWs might prevent one end or the other from >> accepting incoming connections. Even so, it didn't have any normative >> behavior about what should be in the offer. >> >> As this same attribute is used in different contexts, the implications >> of using it may vary. In particular, if it is intended that either end >> should be able to take either the active or passive role, then the >> considerations for use may vary. >> >> ISTM that actpas SHOULD be used in the offer, except in cases where the >> offerer has a particular preference for active or passive, and would >> prefer to have the connection fail than use the other mode. >> >> Thanks, >> Paul >> >> On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote: >>> Right. >>> >>> >>>------------------------------------------------------------------------ >>> *Von:* Christer Holmberg [christer.holmberg@ericsson.com] >>> *Gesendet:* Donnerstag, 14. November 2013 02:21 >>> *An:* Schwarz, Albrecht (Albrecht) >>> *Cc:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>> >>> Hi Albrecht, >>> >>> If I understand your proposal correctly, the change would be to relax >>> the rule for assigning the SDP setup attribute value in the SDP Offer. >>> Instead of mandating actpass, we would also allow active and passive. >>> >>> Right? >>> >>> Regards, >>> >>> Christer >>> >>> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> *L=E4hetetty:* 14. marraskuuta 2013 3:11 >>> *Vastaanottaja:* Christer Holmberg >>> *Kopio:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >>> *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>> >>> Hello Christer, >>> guess it's time to come back on this topic since the WG adopted the >>>draft. >>> >>> In brief ("don't want to repeat again the thread"): >>> a) problem statement: existing SDP O/A rules define a tighly coupled >>> mode between the establishment direction of the SIP session and the >>> establishment direction of the DTLS session, but there's not any >>> reasoning for such tightly coupled behaviour. >>> >>> b) change proposal: >>> Revise in clause 3.1 following list item >>> >>> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>> >>> offerer MUST assign the SDP setup attribute with setup:actpass >>> >>> value, and MUST be prepared to receive a DTLS client_hello >>>message >>> >>> before it receives the SDP answer. The answerer MUST assign the >>> >>> SDP setup attribute with either setup:active value or >>> >>> setup:passive value. The answerer SHOULD assign the SDP setup >>> >>> attribute with the setup:active value. Whichever party is active >>> >>> MUST initiate a DTLS handshake by sending a ClientHello over each >>> >>> flow (host/port quartet). >>> >>> >>> by >>> >>> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>> >>> offerer MUST assign the SDP setup attribute with a setup:actpass, >>> setup:active or setup:passive >>> >>> value, and, in case of setup:actpass or setup:passive, MUST be >>> prepared to receive a DTLS client_hello message >>> >>> before it receives the SDP answer. The answerer MUST assign the >>> >>> SDP setup attribute with either setup:active value or >>> >>> setup:passive value. The answerer SHOULD assign the SDP setup >>> >>> attribute with the setup:active value, in case of setup:actpass >>> or setup:passive. Whichever party is active >>> >>> MUST initiate a DTLS handshake by sending a ClientHello over each >>> >>> flow (host/port quartet). >>> >>> >>> We would limit ourselves with the existing, restrictive SDP O/A rule. >>> And without any justification for such a constraint. >>> >>> Any comments? >>> >>> Regards, >>> Albrecht >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>> *Von:*Christer Holmberg [christer.holmberg@ericsson.com] >>> *Gesendet:* Montag, 7. Oktober 2013 13:11 >>> *An:* Schwarz, Albrecht (Albrecht) >>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>> >>> Hi Albrecht, >>> >>> At this point, the community is making a decision about whether to >>>start >>> working on this. >>> >>> Once that is done, we will start looking into, and discuss, individual >>> technical issues etc, and your input will be highly appreciated. >>> >>> Regards, >>> >>> Christer >>> >>> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> *L=E4hetetty:* 7. lokakuuta 2013 13:56 >>> *Vastaanottaja:* Christer Holmberg >>> *Kopio:* mmusic@ietf.org ; LANDAIS, BRUNO >>>(BRUNO) >>> *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>> >>> Hello Christer, >>> >>> I may not commit to submit a problem statement in the next couple of >>> weeks, just due to time reasons. >>> >>> At least a note (or editor=B9s note) should be added to draft >>> mmusic-udptl-dtls in order to indicate the issue and that a solution >>> proposal is still pending. >>> >>> Thanks, >>> >>> Albrecht >>> >>> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> *Sent:* Dienstag, 24. September 2013 16:01 >>> *To:* Schwarz, Albrecht (Albrecht) >>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>> >>> Hi Albrecht, >>> >>> I don't think putting a note somewhere in the fax draft is going to >>> solve anything. >>> >>> As you indicate, the issue exists in multiple documents, so it's a >>> generic issues. >>> >>> So, my suggestion is that you put together a short draft which >>>describes >>> the problem, and how you want to change it, and then we can have a more >>> generic discussion about it. The WG can then decide whether we shall >>>fix >>> something, and if so, in which specs. >>> >>> Regards, >>> >>> Christer >>> >>> >>>------------------------------------------------------------------------ >>> >>> *From:*Schwarz, Albrecht (Albrecht) >>>[albrecht.schwarz@alcatel-lucent.com] >>> *Sent:* Tuesday, 24 September 2013 4:22 PM >>> *To:* Christer Holmberg >>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>> session >>> >>> Hello Christer, >>> >>> the "copy & paste" action (across at least three "RFCs") seems to be >>>the >>> root cause of the issue :-( >>> >>> SIP session establishment and L4 security session (DTLS, TLS) >>> establishment directions should be principally decoupled because >>> application specific. >>> >>> We got here (wrt DTLS) three (different!) applications: >>> 1) Key exchange (RFC 5763) >>> 2) Conference control (rfc4582bis) >>> 3) Document transmission (udptl-dtls) >>> >>> All three applications are different in terms of number/type of >>> supported network models, security models or/and communication >>>topology. >>> >>> Consequently, the basic, application independent SDP O/A rules for DTLS >>> session establishment would need to support that flexibility. >>> The application specific SIP/SDP profile could then still narrow down >>> the required SDP O/A rules. >>> >>> What we got so far: SDP O/A rules in three application specific "RFCs" >>> (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-( >>> >>> There might be two options to correct that copy & paste issue in >>> "udptl-dtls" in my opinion: >>> a) expand the SDP O/A rules for more flexibility >>> or >>> b) add a WARNING / NOTE about the inherent limitations (due to the >>> assumption of a network and communication environment according RFC >>>5763) >>> >>> What do you think? >>> Best regards, >>> Albrecht >>> >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Montag, 23. September 2013 11:54 >>> To: Schwarz, Albrecht (Albrecht) >>> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>> >>> Hi Albrecht, >>> >>> I don't know what model people were focusing on when writing RFC 5763, >>> but the RFC does say: >>> >>> "The endpoint that is the offerer MUST use the setup attribute value of >>> setup:actpass" >>> >>> ...which we also copied into the udptl-dtls draft. >>> >>> Now, if you want to change that, and allow the Offerer to "force" the >>> direction, I think you should start a separate thread about that. >>> Because, it is not specific to fax, in my opinion. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> Sent: 23. syyskuuta 2013 12:31 >>> To: Christer Holmberg >>> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>> >>> Hello Christer, >>> >>> the decision about "DTLS session establishment direction" is ALWAYS up >>> to the SDP ANSWERER (according present 3.1). >>> >>> In order to decouple SIP session and DTLS session establishment >>> directions, then the SDP OFFERER should also to be able to use >>> "setup:active" and "setup:passive" (besides codepoint "setup:actpass") >>> in my understanding. >>> >>> I'm not sure whether the reference to RFC 5763 helps because I could >>> imagine that the subject comes down to the indicated network scenarios, >>> lets look again at: >>> a) T - T >>> b) T -GW >>> >>> The existing udptl-dtls & RFC 5763 text seems to focus on model (a) >>> only: SDP O/A between two peering, terminal located SIP UAs (there is >>> NOT any SIP B2BUA). >>> But I could imagine that the SIP/SDP profiles for "T" and "GW" are not >>> necessarily the same in case of model (b): "T" as SDP Offerer may not >>> allowed to decide the DTLS session establishment direction, but "GW" as >>> SDP offerer may need to enforce the DTLS session establishment >>>direction >>> (either way). >>> >>> Regards, >>> Albrecht >>> >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Donnerstag, 19. September 2013 10:02 >>> To: Schwarz, Albrecht (Albrecht) >>> Cc: mmusic@ietf.org >>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>session >>> >>> Hi Albrecht, >>> >>> The direction of the SIP session establishment and the DTLS session >>> establishment are NOT tightly coupled. The draft enables the Answerer >>>to >>> select whether it wants to act as DTLS client or DTLS server. >>> >>> Section 3.1 states: >>> >>> .... The >>> offerer MUST assign the SDP setup attribute with setup:actpass value, >>> and MUST be prepared to receive a DTLS client_hello message before it >>> receives the SDP answer. The answerer MUST assign the SDP setup >>> attribute with either setup:active value or setup:passive value. The >>> answerer SHOULD assign the SDP setup attribute with the setup:active >>> value. Whichever party is active MUST initiate a DTLS handshake by >>> sending a ClientHello over each flow (host/port quartet). >>> >>> The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, >>> we base the procedure on that RFC. >>> >>> BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the >>> DTLS-SRTP procedures for DTLS server determination. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> Sent: 18. syyskuuta 2013 18:28 >>> To: Christer Holmberg >>> Cc: mmusic@ietf.org >>> Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session >>> >>> The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in a >>> gateway, leading to three possible scenarios of >>> a) T - T >>> b) T -GW >>> c) GW-GW >>> >>> I'd like to scope on scenario (b) due to its asymmetry of user- and >>> network-side located T.38 endpoints. >>> >>> Christer, >>> I thought that the two directions of >>> 1) SIP session establishment and >>> 2) DTLS session establishment >>> should be NOT tightly coupled (as currently supposed to be in clause >>>3.1)? >>> The ietf draft should offer the flexibility in decoupling both >>> establishment directions. >>> >>> E.g., there might be the demand to limit DTLS session establishment in >>> T-to-GW direction (and apply rather the reverse direction) due >>> ClientHello associated security threats, resource requests in terms of >>> memory, ... >>> >>> In my opinion: >>> the IETF should allow the flexibility, >>> other SDOs could still profile/limit this capability. >>> >>> Best regards, >>> Albrecht >>> >>> PS >>> We had a similar discussion with TLS, there NAT traversal (NAT-T) >>> aspects could influence TLS session establishment direction. However, I >>> guess that NAT-T is minor for DTLS/UDP. >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From salvatore.loreto@ericsson.com Sat Nov 23 06:52:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04EF1ADEBA for ; Sat, 23 Nov 2013 06:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6I20QkaOlfR for ; Sat, 23 Nov 2013 06:51:58 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A86CF1ADBD4 for ; Sat, 23 Nov 2013 06:51:57 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-63-5290c1051d67 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E7.2F.03802.501C0925; Sat, 23 Nov 2013 15:51:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.229]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Sat, 23 Nov 2013 15:51:48 +0100 From: Salvatore Loreto To: Peter Thatcher Thread-Topic: Should we put the SCTP max message size in the SDP? Thread-Index: AQHO59KSo690P/9Zfkuq+OuUX9gyppoxyn6AgAAG3gCAAARKgIAAARSAgAD/7wA= Date: Sat, 23 Nov 2013 14:51:48 +0000 Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> 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.150] Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A336B5EESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Vpf14IQgg+/nFCy2ThWyuNi0hNFi 6vLHLBbXlr9mtej9uITRgdVjwaZSjyVLfjJ5bGjZweRxdN5+1gCWKC6blNSczLLUIn27BK6M w8/mMxbc9624v20OcwPjKe8uRk4OCQETibZdO5ggbDGJC/fWs3UxcnEICRxilFjUfQrKWcIo MWPNJRaQKjYBM4nnD7cwg9giApoSkyc3s4LYzAIbGSXuzK7sYuTgEBZwkOhdKwVR4ijx5dEz JgjbT2LDj0dMICUsAqoS//dUgoR5BbwlXkw7wgSx6gGTxI8Db9lBEpwCgRIvTy8HW8sIdNz3 U2uYIFaJS9x6Mh/qaAGJJXvOM0PYohIvH/9jhbCVJFZsv8QIUZ8vsXXOAhaIZYISJ2c+YZnA KDoLyahZSMpmISmbBXQqM9CX63fpQ5QoSkzpfsgOYWtItM6ZC2VbS1x++5wdWc0CRo5VjOy5 iZk56eVGmxiBcXlwy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUAyNzQJ9gVrbbPqXk+Zu7np+Sa3/Ezm3dXbtusu/amvrzP5cfvCaRdu78bN8NkyrfXph/ 4KXiTBZBPsPJ62ZtXbNsvn/tDNvHaSa2GmmXNOa0xvqXbZzapHJm3wtFydwkL5+Pmrly35Ui 9+3kYotQLBTK0usM9VK8K9uSWrSfk3PNjJ59M1e9kldiKc5INNRiLipOBADAI9tVmQIAAA== Cc: Michael Tuexen , "public-webrtc@w3.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 14:52:01 -0000 --_000_2B9B48179856DC4FA00C93C79EB7E64A336B5EESESSMB109ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQooYWRkaW5nIG1tdXNpYyBtYWlsaW5nIGxpc3QsIHNvcnJ5IGZvciBjcm9zcyBwb3N0aW5nIGJ1 dCBpZiB3ZSB3YW50IHRvIHByb2dyZXNzIHRoZSBkcmFmdA0Kd2l0aGluIElFVEYgd2UgaGF2ZSB0 byBkaXNjdXNzIGl0IGluIHRoZSBtbXVzaWMgbWFpbGluZyBsaXN0KQ0KDQp0aGUgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAtMDUNCnN0aWxsIGFs bG93IHRvIHNwZWNpZnkgdGhlIG51bWJlciBvZiBzdHJlYW1zLCBldmVuIGlmIGl0IGlzIG9wdGlv bmFsDQoNCmlmIHdlIHdhbnQgdG8gYWRkIGFsc28gbWF4LW1lc3NhZ2Utc2l6ZSBhdHRyaWJ1dGUs IGFsc28gYXMgb24gb3B0aW9uYWwgb25lDQp3aGF0IGFib3V0IHNvbWV0aGluZyBsaWtlIHRoaXM/ DQoNCmE9c2N0cG1hcDo1MDAwIHdlYnJ0Yy1kYXRhY2hhbm5lbCBbc3RyZWFtc10gW21heC1tZXNz YWdlLXNpemVdDQoNCi9TYWx2YXRvcmUNCg0KDQpPbiBOb3YgMjMsIDIwMTMsIGF0IDE6MzUgQU0s IFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdv b2dsZS5jb20+Pg0KIHdyb3RlOg0KDQoNCg0KDQpPbiBGcmksIE5vdiAyMiwgMjAxMyBhdCAzOjMx IFBNLCBNaWNoYWVsIFR1ZXhlbiA8TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGU8bWFp bHRvOk1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlPj4gd3JvdGU6DQpPbiBOb3YgMjMs IDIwMTMsIGF0IDEyOjE2IEFNLCBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb208 bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPj4gd3JvdGU6DQoNCj4gWWVzLCB3ZSBhZ3JlZWQg dG8gZm9yZWdvIHB1dHRpbmcgc3RyZWFtcyBpbiB0aGUgU0RQLiAgSSdtIHN1cmUgSSBnb3QgdGhl IHN5bnRheCBvZiB0aGUgU0RQIHdyb25nLiAgWW91cnMgbG9va3MgYmV0dGVyLg0KYW5kIHRoZSBz ZW1hbnRpYyBpczogSSdtIHdpbGxpbmcgdG8gYWNjZXB0IFNDVFAgdXNlciBtZXNzYWdlcyBvZiBh dCBsZWFzdCAxMDAwMDAwIGJ5dGVzLCByaWdodD8NCg0KDQrigItDb3JyZWN0LuKAiw0KDQoNCkl0 IG1ha2VzIHNlbnNlIHRvIHB1dCBpdCBpbnRvIHRoZSBTRFAuLi4NCg0KQmVzdCByZWdhcmRzDQpN aWNoYWVsDQo+DQo+DQo+IE9uIEZyaSwgTm92IDIyLCAyMDEzIGF0IDI6NTEgUE0sIEp1c3RpbiBV YmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3Jv dGU6DQo+IEkgbGlrZSB0aGUgaWRlYSwgYnV0IEknbSBub3Qgc3VyZSB0aGUgc3ludGF4IGluIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLTA0IGNh biBleHByZXNzIHRoaXMuDQo+DQo+IFRoZSBjdXJyZW50IGE9c2N0cG1hcCBpcw0KPg0KPiBhPXNj dHBtYXA6NTAwMCB3ZWJydGMtZGF0YWNoYW5uZWwgW3N0cmVhbXNdDQo+DQo+IGFsdGhvdWdoIElJ UkMgd2UgYWdyZWVkIHRvIGZvcmVnbyB0aGUgd2hvbGUgc3RyZWFtcyBuZWdvdGlhdGlvbiB0aGlu Zy4NCj4NCj4gU28gd2Ugd291bGQgbmVlZCBzb21ldGhpbmcgbGlrZSBhPWZtdHA6NTAwMCBtYXgt bWVzc2FnZS1zaXplPTEwMDAwMDAuDQo+DQo+DQo+IE9uIEZyaSwgTm92IDIyLCAyMDEzIGF0IDI6 MjggUE0sIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRj aGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCj4gVGhpcyBpcyBwcm9iYWJseSBnb2luZyB0byBzb3Vu ZCBzdHJhbmdlIGNvbWluZyBmcm9tIG1lLCBidXQgSSB0aGluayBpdCBtaWdodCBiZSBhIGJldHRl ciBpZGVhIHRvIHB1dCB0aGUgU0NUUCBtYXggbWVzc2FnZSBzaXplIGluIHRoZSBTRFAuDQo+DQo+ IEknbSBzdGlsbCBPSyB3aXRoIGhhdmluZyBhbiBpbi1iYW5kIG1lc3NhZ2UgKGFzIHdlIGRpc2N1 c3NlZCBkdXJpbmcgVFBBQykgdG8gc3dhcCB0aGUgU0NUUCBtYXggbWVzc2FnZSBiZXR3ZWVuIGVu ZHBvaW50cywgYnV0IEkgd2FzIHRoaW5raW5nIGFib3V0IGl0IGEgbGl0dGxlIG1vcmUgYW5kIHJl YWxpemVkIHRoYXQgaXQgZG9lcyBpbnZvbHZlIHNvbWUgZXh0cmEgZWRnZSBjYXNlcyBhbmQgYSBi aXQgb2YgcG9zc2libGUgbGF0ZW5jeS4gIEl0IHdvdWxkIGJlIG5pY2UgaWYgd2UgY291bGQgZG8g YSBoYW5kc2hha2UgZWFybGllciBvbi4uLi4gYW5kIHRoZW4gSSByZWFsaXplZCB3ZSBjYW4gYmVj YXVzZSB3ZSBjYW4ganVzdCBwdXQgaXQgaW4gdGhlIFNEUCB3aGVyZSB3ZSBhbHJlYWR5IGRvIGEg aGFuZHNoYWtlIHdlbGwgYWhlYWQgb2YgdGltZS4NCj4NCj4gU29tZXRoaW5nIGxpa2U6DQo+DQo+ IGE9c2N0cG1hcDo1MDAwIG1heC1tZXNzYWdlLXNpemUgMTAwMDAwMA0KPg0KPg0KPiBPYnZpb3Vz bHkgSSdtIG5vdCBhIGJpZyBmYW4gb2Ygc3R1ZmZpbmcgbG90cyBvZiBzdHVmZiBpbnRvIFNEUCwg YnV0IEkgdGhpbmsgdGhpcyBpcyB2ZXJ5IG1pbmltYWwgYW5kIGlzIGEgbW9yZSBzaW1wbGUgc29s dXRpb24uDQo+DQo+DQo+DQo+DQo+IFdoYXQgZG8geW91IHRoaW5rPw0KPg0KPg0KDQoNCg0K --_000_2B9B48179856DC4FA00C93C79EB7E64A336B5EESESSMB109ericsso_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PihhZGRp bmcgbW11c2ljIG1haWxpbmcgbGlzdCwgc29ycnkgZm9yIGNyb3NzIHBvc3RpbmcgYnV0IGlmIHdl IHdhbnQgdG8gcHJvZ3Jlc3MgdGhlIGRyYWZ0PC9kaXY+DQo8ZGl2PndpdGhpbiBJRVRGIHdlIGhh dmUgdG8gZGlzY3VzcyBpdCBpbiB0aGUgbW11c2ljIG1haWxpbmcgbGlzdCk8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQp0aGUmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcC0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAtMDU8L2E+DQo8ZGl2PnN0aWxsIGFsbG93IHRv IHNwZWNpZnkgdGhlIG51bWJlciBvZiBzdHJlYW1zLCBldmVuIGlmIGl0IGlzIG9wdGlvbmFsPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5pZiB3ZSB3YW50IHRvIGFkZCBhbHNvIG1heC1t ZXNzYWdlLXNpemUgYXR0cmlidXRlLCBhbHNvIGFzIG9uIG9wdGlvbmFsIG9uZTwvZGl2Pg0KPGRp dj53aGF0IGFib3V0IHNvbWV0aGluZyBsaWtlIHRoaXM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+YT1zY3RwbWFwOjUwMDAgd2VicnRjLWRhdGFjaGFubmVsIFtzdHJlYW1z XSBbbWF4LW1lc3NhZ2Utc2l6ZV08L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+L1NhbHZhdG9yZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+T24gTm92IDIzLCAyMDEzLCBhdCAxOjM1IEFNLCBQZXRlciBU aGF0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIj5wdGhhdGNo ZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZuYnNwO3dyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0i Zm9udC1mYW1pbHk6dmVyZGFuYSxzYW5zLXNlcmlmIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJp LCBOb3YgMjIsIDIwMTMgYXQgMzozMSBQTSwgTWljaGFlbCBUdWV4ZW4gPHNwYW4gZGlyPSJsdHIi Pg0KJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZSIg dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlPC9hPiZndDs8 L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPGRpdiBjbGFzcz0iaW0iPk9uIE5vdiAyMywgMjAxMywgYXQgMTI6MTYgQU0sIFBl dGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iPnB0 aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBZZXMsIHdl IGFncmVlZCB0byBmb3JlZ28gcHV0dGluZyBzdHJlYW1zIGluIHRoZSBTRFAuICZuYnNwO0knbSBz dXJlIEkgZ290IHRoZSBzeW50YXggb2YgdGhlIFNEUCB3cm9uZy4gJm5ic3A7WW91cnMgbG9va3Mg YmV0dGVyLjxicj4NCjwvZGl2Pg0KYW5kIHRoZSBzZW1hbnRpYyBpczogSSdtIHdpbGxpbmcgdG8g YWNjZXB0IFNDVFAgdXNlciBtZXNzYWdlcyBvZiBhdCBsZWFzdCAxMDAwMDAwIGJ5dGVzLCByaWdo dD88YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLHNhbnMt c2VyaWYiPuKAi0NvcnJlY3Qu4oCLPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkl0IG1h a2VzIHNlbnNlIHRvIHB1dCBpdCBpbnRvIHRoZSBTRFAuLi48YnI+DQo8YnI+DQpCZXN0IHJlZ2Fy ZHM8YnI+DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+TWljaGFl bDxicj4NCjwvZm9udD48L3NwYW4+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPg0KPGRpdiBjbGFzcz0i aDUiPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBGcmksIE5vdiAyMiwgMjAxMyBhdCAyOjUx IFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29t Ij5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEkgbGlrZSB0aGUg aWRlYSwgYnV0IEknbSBub3Qgc3VyZSB0aGUgc3ludGF4IGluIDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLTA0IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zY3Rw LXNkcC0wNDwvYT4gY2FuIGV4cHJlc3MgdGhpcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgY3Vy cmVudCBhPXNjdHBtYXAgaXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBhPXNjdHBtYXA6NTAwMCB3ZWJy dGMtZGF0YWNoYW5uZWwgW3N0cmVhbXNdPGJyPg0KJmd0Ozxicj4NCiZndDsgYWx0aG91Z2ggSUlS QyB3ZSBhZ3JlZWQgdG8gZm9yZWdvIHRoZSB3aG9sZSBzdHJlYW1zIG5lZ290aWF0aW9uIHRoaW5n Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFNvIHdlIHdvdWxkIG5lZWQgc29tZXRoaW5nIGxpa2UgYT1m bXRwOjUwMDAgbWF4LW1lc3NhZ2Utc2l6ZT0xMDAwMDAwLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBPbiBGcmksIE5vdiAyMiwgMjAxMyBhdCAyOjI4IFBNLCBQZXRlciBUaGF0Y2hlciAm bHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIj5wdGhhdGNoZXJAZ29vZ2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgVGhpcyBpcyBwcm9iYWJseSBnb2luZyB0byBz b3VuZCBzdHJhbmdlIGNvbWluZyBmcm9tIG1lLCBidXQgSSB0aGluayBpdCBtaWdodCBiZSBhIGJl dHRlciBpZGVhIHRvIHB1dCB0aGUgU0NUUCBtYXggbWVzc2FnZSBzaXplIGluIHRoZSBTRFAuPGJy Pg0KJmd0Ozxicj4NCiZndDsgSSdtIHN0aWxsIE9LIHdpdGggaGF2aW5nIGFuIGluLWJhbmQgbWVz c2FnZSAoYXMgd2UgZGlzY3Vzc2VkIGR1cmluZyBUUEFDKSB0byBzd2FwIHRoZSBTQ1RQIG1heCBt ZXNzYWdlIGJldHdlZW4gZW5kcG9pbnRzLCBidXQgSSB3YXMgdGhpbmtpbmcgYWJvdXQgaXQgYSBs aXR0bGUgbW9yZSBhbmQgcmVhbGl6ZWQgdGhhdCBpdCBkb2VzIGludm9sdmUgc29tZSBleHRyYSBl ZGdlIGNhc2VzIGFuZCBhIGJpdCBvZiBwb3NzaWJsZSBsYXRlbmN5LiAmbmJzcDtJdA0KIHdvdWxk IGJlIG5pY2UgaWYgd2UgY291bGQgZG8gYSBoYW5kc2hha2UgZWFybGllciBvbi4uLi4gYW5kIHRo ZW4gSSByZWFsaXplZCB3ZSBjYW4gYmVjYXVzZSB3ZSBjYW4ganVzdCBwdXQgaXQgaW4gdGhlIFNE UCB3aGVyZSB3ZSBhbHJlYWR5IGRvIGEgaGFuZHNoYWtlIHdlbGwgYWhlYWQgb2YgdGltZS48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBTb21ldGhpbmcgbGlrZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBhPXNj dHBtYXA6NTAwMCBtYXgtbWVzc2FnZS1zaXplIDEwMDAwMDA8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgT2J2aW91c2x5IEknbSBub3QgYSBiaWcgZmFuIG9mIHN0dWZmaW5nIGxvdHMgb2Yg c3R1ZmYgaW50byBTRFAsIGJ1dCBJIHRoaW5rIHRoaXMgaXMgdmVyeSBtaW5pbWFsIGFuZCBpcyBh IG1vcmUgc2ltcGxlIHNvbHV0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IFdoYXQgZG8geW91IHRoaW5rPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_2B9B48179856DC4FA00C93C79EB7E64A336B5EESESSMB109ericsso_-- From ekr@rtfm.com Sat Nov 23 13:33:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03EA1AE023 for ; Sat, 23 Nov 2013 13:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B08NA4gTcQJ for ; Sat, 23 Nov 2013 13:33:40 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id DCA291ADFD4 for ; Sat, 23 Nov 2013 13:33:39 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so1368071wgh.21 for ; Sat, 23 Nov 2013 13:33:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zUt38ltNjt8LNFZl8qu9XuhZ1H1JODO+LTl8DkFOfNQ=; b=buhPmJQOyg726SXt/igVBw/+1bt+75MHGzexgb9hMGKQAotf8BJSEpanGBtnodhqFr NAG1ja1c/5ZVIGo9lZHEEF+kJQWifYW5G0k40yrp2YezhKm1WjW0EbhOl2GalvlFkukt e88202pF0M1ErAK0dOjfFCM+8yRlfV7QSOFFGLx64FgCEjdTtQKpk2MzV8FkiRI6Ank+ 5SJsl3DCWZ583RjOk3YjMhErXC5Q6Fm+oa7b0voVzV72AE7nj7MHcpK8qd24KMgWT2gb gmaFqolJUSz+vOW6p9S7Mb9ORoGXOuPTEBCGXkyC5ldHkOntt58M75wu+LYCEi9M/ki8 VZIg== X-Gm-Message-State: ALoCoQk7tT8ZQtkAhrqkeIq+I17BhMTJqCnA8754BGLHONSNt0u1GA1QuE8/EvkfuJRw6VzAaP25 X-Received: by 10.180.12.179 with SMTP id z19mr7860821wib.24.1385242411680; Sat, 23 Nov 2013 13:33:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sat, 23 Nov 2013 13:32:51 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> From: Eric Rescorla Date: Sat, 23 Nov 2013 13:32:51 -0800 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=001a11c3533ae059d304ebdee17d Cc: "mmusic@ietf.org" , "public-webrtc@w3.org" , Peter Thatcher Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 21:33:42 -0000 --001a11c3533ae059d304ebdee17d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 23, 2013 at 7:19 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On Nov 23, 2013, at 3:51 PM, Salvatore Loreto < > salvatore.loreto@ericsson.com> wrote: > > > > > (adding mmusic mailing list, sorry for cross posting but if we want to > progress the draft > > within IETF we have to discuss it in the mmusic mailing list) > > > > the http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 > > still allow to specify the number of streams, even if it is optional > > > > if we want to add also max-message-size attribute, also as on optional > one > > what about something like this? > > > > a=sctpmap:5000 webrtc-datachannel [streams] [max-message-size] > ... and what is the semantic if max-message-size is not provided? The > endpoint > is willing to accept arbitrary large messages? > > I also suggest to rename max-message-size to supported-message-size. > The semantics is that the end-point is willing to accept messages up to > supported-message-size. It does not make a statement about messages larger > than the limit. Calling it max-message-size suggests to me, that messages > larger than the limit can't be handled... 1. I'm cool with the idea of negotiating this in the SDP. 2. I actually think it would be better to have a max message size, since otherwise we're back in the indeterminate behavior case. 3. The semantics should be that each side just gets to inform the other side of their value, not that it's negotiated. -Ekr --001a11c3533ae059d304ebdee17d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Nov 23, 2013 at 7:19 AM, Michael Tuexen &= lt;Mi= chael.Tuexen@lurchi.franken.de> wrote:
On Nov 23, 2013, at 3:51 P= M, Salvatore Loreto <sa= lvatore.loreto@ericsson.com> wrote:

>
> (adding mmusic mailing list, sorry for cross posting but if we want to= progress the draft
> within IETF we have to discuss it in the mmusic mailing list)
>
> the http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-= 05
> still allow to specify the number of streams, even if it is optional >
> if we want to add also max-message-size attribute, also as on optional= one
> what about something like this?
>
> a=3Dsctpmap:5000 webrtc-datachannel [streams] [max-message-size]
... and what is the semantic if max-message-size is not provided? The= endpoint
is willing to accept arbitrary large messages?

I also suggest to rename max-message-size to supported-message-size.
The semantics is that the end-point is willing to accept messages up to
supported-message-size. It does not make a statement about messages larger<= br> than the limit. Calling it max-message-size suggests to me, that messages larger than the limit can't be handled...

1. I'm cool with the idea of negotiating this in the SDP.
= 2. I actually think it would be better to have a max message size, since
otherwise we're back in the indeterminate behavior case.
3. The semantics should be that each side just gets to inform the ot= her
side of their value, not that it's negotiated.

-Ekr


--001a11c3533ae059d304ebdee17d-- From martin.thomson@gmail.com Sat Nov 23 14:54:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F281AE242 for ; Sat, 23 Nov 2013 14:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBizKe87J7wd for ; Sat, 23 Nov 2013 14:54:26 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 29D8B1AE2E9 for ; Sat, 23 Nov 2013 14:54:25 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so4044617wib.13 for ; Sat, 23 Nov 2013 14:54:18 -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=iBbduinSXByVQhNg6g5VBH0RJCgEtTbZqNb39L/KG0Y=; b=ycEH9AQQ+Pobsu7c946F+xUAt7/xyAUize2EZcMY/UR5gUnStrvibcWwHbCLawmgGi JLXCMXK7o+7KPTeXcK28AL53dsqkG2P3z5FBm2vYYnDelK1/6rSk+TD+o0cWeswLD4FA SG34P4qBz2IVRQlhCCYZBLKLqPoYA5J049KmFmoohR69OoxMZxEWbLxboTzo3sXsCQ5j QG2PMS0M2ed3kGg7ExKjw9wL6MpJ/cLSPIl7SQ1vwLyeg8+vj1bPBRFJBKKTX/F+wLIb kkq3GgPdZ/W6PqCzAGET3Q+wmC7Eow40oVKTJgvyIE/vw4dPYYzIWS1aYzZnC7LDfrT1 91tg== MIME-Version: 1.0 X-Received: by 10.180.206.18 with SMTP id lk18mr8000108wic.64.1385247258080; Sat, 23 Nov 2013 14:54:18 -0800 (PST) Received: by 10.227.134.195 with HTTP; Sat, 23 Nov 2013 14:54:18 -0800 (PST) In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> Date: Sat, 23 Nov 2013 14:54:18 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: Michael Tuexen , Peter Thatcher , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 22:54:27 -0000 On 23 November 2013 13:32, Eric Rescorla wrote: > 3. The semantics should be that each side just gets to inform the other > side of their value, not that it's negotiated. This is especially important. "negotiation" here makes zero sense. From Michael.Tuexen@lurchi.franken.de Sat Nov 23 07:19:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9655B1ADF58 for ; Sat, 23 Nov 2013 07:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb4ZzhFUxpu4 for ; Sat, 23 Nov 2013 07:19:27 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C332E1AD7C5 for ; Sat, 23 Nov 2013 07:19:26 -0800 (PST) Received: from [192.168.1.134] (p5481BEE3.dip0.t-ipconnect.de [84.129.190.227]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 21F581C0C0692; Sat, 23 Nov 2013 16:19:17 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> Date: Sat, 23 Nov 2013 16:19:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> To: Salvatore Loreto X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Sat, 23 Nov 2013 18:53:40 -0800 Cc: "mmusic@ietf.org" , "public-webrtc@w3.org" , Peter Thatcher Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 15:19:29 -0000 On Nov 23, 2013, at 3:51 PM, Salvatore Loreto = wrote: >=20 > (adding mmusic mailing list, sorry for cross posting but if we want to = progress the draft > within IETF we have to discuss it in the mmusic mailing list) >=20 > the http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 > still allow to specify the number of streams, even if it is optional >=20 > if we want to add also max-message-size attribute, also as on optional = one > what about something like this? >=20 > a=3Dsctpmap:5000 webrtc-datachannel [streams] [max-message-size] ... and what is the semantic if max-message-size is not provided? The = endpoint is willing to accept arbitrary large messages? I also suggest to rename max-message-size to supported-message-size. The semantics is that the end-point is willing to accept messages up to supported-message-size. It does not make a statement about messages = larger than the limit. Calling it max-message-size suggests to me, that = messages larger than the limit can't be handled... Best regards Michael >=20 > /Salvatore >=20 >=20 > On Nov 23, 2013, at 1:35 AM, Peter Thatcher > wrote: >=20 >>=20 >>=20 >>=20 >> On Fri, Nov 22, 2013 at 3:31 PM, Michael Tuexen = wrote: >> On Nov 23, 2013, at 12:16 AM, Peter Thatcher = wrote: >>=20 >> > Yes, we agreed to forego putting streams in the SDP. I'm sure I = got the syntax of the SDP wrong. Yours looks better. >> and the semantic is: I'm willing to accept SCTP user messages of at = least 1000000 bytes, right? >>=20 >>=20 >> =E2=80=8BCorrect.=E2=80=8B >>=20 >> =20 >> It makes sense to put it into the SDP... >>=20 >> Best regards >> Michael >> > >> > >> > On Fri, Nov 22, 2013 at 2:51 PM, Justin Uberti = wrote: >> > I like the idea, but I'm not sure the syntax in = http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-04 can express = this. >> > >> > The current a=3Dsctpmap is >> > >> > a=3Dsctpmap:5000 webrtc-datachannel [streams] >> > >> > although IIRC we agreed to forego the whole streams negotiation = thing. >> > >> > So we would need something like a=3Dfmtp:5000 = max-message-size=3D1000000. >> > >> > >> > On Fri, Nov 22, 2013 at 2:28 PM, Peter Thatcher = wrote: >> > This is probably going to sound strange coming from me, but I think = it might be a better idea to put the SCTP max message size in the SDP. >> > >> > I'm still OK with having an in-band message (as we discussed during = TPAC) to swap the SCTP max message between endpoints, but I was thinking = about it a little more and realized that it does involve some extra edge = cases and a bit of possible latency. It would be nice if we could do a = handshake earlier on.... and then I realized we can because we can just = put it in the SDP where we already do a handshake well ahead of time. >> > >> > Something like: >> > >> > a=3Dsctpmap:5000 max-message-size 1000000 >> > >> > >> > Obviously I'm not a big fan of stuffing lots of stuff into SDP, but = I think this is very minimal and is a more simple solution. >> > >> > >> > >> > >> > What do you think? >> > >> > >>=20 >>=20 >=20 From Michael.Tuexen@lurchi.franken.de Sat Nov 23 14:53:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F851AE256 for ; Sat, 23 Nov 2013 14:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJHo8wzUGIP3 for ; Sat, 23 Nov 2013 14:53:12 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id BAECC1AE242 for ; Sat, 23 Nov 2013 14:53:11 -0800 (PST) Received: from [192.168.1.134] (p5481BEE3.dip0.t-ipconnect.de [84.129.190.227]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9526B1C0C0692; Sat, 23 Nov 2013 23:53:01 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Sat, 23 Nov 2013 23:53:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Sat, 23 Nov 2013 18:53:40 -0800 Cc: "mmusic@ietf.org" , "public-webrtc@w3.org" , Peter Thatcher Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 22:53:14 -0000 On Nov 23, 2013, at 10:32 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Sat, Nov 23, 2013 at 7:19 AM, Michael Tuexen = wrote: > On Nov 23, 2013, at 3:51 PM, Salvatore Loreto = wrote: >=20 > > > > (adding mmusic mailing list, sorry for cross posting but if we want = to progress the draft > > within IETF we have to discuss it in the mmusic mailing list) > > > > the http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 > > still allow to specify the number of streams, even if it is optional > > > > if we want to add also max-message-size attribute, also as on = optional one > > what about something like this? > > > > a=3Dsctpmap:5000 webrtc-datachannel [streams] [max-message-size] > ... and what is the semantic if max-message-size is not provided? The = endpoint > is willing to accept arbitrary large messages? >=20 > I also suggest to rename max-message-size to supported-message-size. > The semantics is that the end-point is willing to accept messages up = to > supported-message-size. It does not make a statement about messages = larger > than the limit. Calling it max-message-size suggests to me, that = messages > larger than the limit can't be handled... >=20 > 1. I'm cool with the idea of negotiating this in the SDP. > 2. I actually think it would be better to have a max message size, = since > otherwise we're back in the indeterminate behavior case. The semantic Peter suggested was: You can handle messages up to the limit provided in the SDP. What = happens with larger messages is unspecified. For this semantic I suggest the name supported-message-size. If, which is not suggested by Peter as far as I understand, the semantic = is You can handle messages up to the limit provided in the SDP. If you send a larger message, I can't handle it. For this semantic max-message-size would be appropriate. No matter which semantic you choose, as a peer I would not send a = message larger than the limit since in the first case I don't know if it can be handled, in the second case I'm sure. > 3. The semantics should be that each side just gets to inform the = other > side of their value, not that it's negotiated. Sure. Best regards Michael >=20 > -Ekr >=20 >=20 From ekr@rtfm.com Sun Nov 24 08:16:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF041ADFD5 for ; Sun, 24 Nov 2013 08:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abZN4RlhC8TH for ; Sun, 24 Nov 2013 08:16:19 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 115521ADF97 for ; Sun, 24 Nov 2013 08:16:18 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so2958254wes.12 for ; Sun, 24 Nov 2013 08:16:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DX624ZwGWy7alDTgrent+rKs5IFGBAv3UcVEtcZSysY=; b=RAOHK7N16XWigO5Wnf+yxWrbAdFXFxx+L5uUfqR/hLTO+NR+sKFCeS2F7rQ1J+pJ47 DN+lCeKlvsJZzbB16Zo8Az5wksZ8j1Sv37P8Rr+H1OrniCxrnbbjrUxUnFw5sWUpmtEV DItbH158GbnBcUJw2iqB2NUjJvA/ANeLrql1JkuZcVHtqUQqllTtOvMrnmZ5iq9hCPiD JOy+w1t6an4L01zKCzg0n7MM6jRV8CPNJAO0HkNaghANuZbnQB07gRGaltnxp7gkdM9u Ur2Wu3G5bCU9pwLWF6Z2U84WdhnCSvZDbecBTkmBndEpjHzBAcyn+h+pRsa1xRJ9pfWL jy2w== X-Gm-Message-State: ALoCoQk38wVHAoIOzYLgr6cTG3BF3u/5d3R1cRvS09xuRGmIbBOLkw+s8NU0ov5M+BvtxQsEBwP4 X-Received: by 10.180.205.233 with SMTP id lj9mr10319443wic.24.1385309770569; Sun, 24 Nov 2013 08:16:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sun, 24 Nov 2013 08:15:30 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> From: Eric Rescorla Date: Sun, 24 Nov 2013 08:15:30 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c26128c76f7f04ebee9022 Cc: Michael Tuexen , Peter Thatcher , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 16:16:21 -0000 --001a11c26128c76f7f04ebee9022 Content-Type: text/plain; charset=ISO-8859-1 For concreteness, here's what I suggest. - An SDP attribute which indicates the maximum message size that the endpoint is willing to accept. The other side should assume that any larger message will be rejected, though there is no requirement that it do so (just as there is no requirement to behave in any particular way if an unadvertised RTP PT is received). - If the attribute is not present, the assumption is that there is some sensible (small) default that matches the behavior of existing browsers. 64k? - An attribute value of '0' means I will do my best with whatever you send me, subject to memory capacity, etc. - Proposed name: 'max-message-size' -Ekr On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson wrote: > On 23 November 2013 13:32, Eric Rescorla wrote: > > 3. The semantics should be that each side just gets to inform the other > > side of their value, not that it's negotiated. > > This is especially important. "negotiation" here makes zero sense. > --001a11c26128c76f7f04ebee9022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For concreteness, here's what I suggest.

- An SDP attribute which indicates the maximum message size that
=A0 the endpoint is willing to accept. The other side should assume t= hat
=A0 any larger message will be rejected, though there is no requiremen= t
=A0 that it do so (just as there is no requirement to behave in= any
=A0 particular way if an unadvertised RTP PT is received).

- If the attribute is not present, the assumption is th= at there is some
=A0 sensible (small) default that matches the be= havior of existing
=A0 browsers. 64k?

- = An attribute value of '0' means I will do my best with whatever you=
=A0 send me, subject to memory capacity, etc.

- Proposed name: 'max-message-size'

-Ekr<= /div>



On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com> wrote:
> 3. The semantics should be that each side just gets to inform the othe= r
> side of their value, not that it's negotiated.

This is especially important. =A0"negotiation" here makes z= ero sense.

--001a11c26128c76f7f04ebee9022-- From ekr@rtfm.com Sun Nov 24 08:42:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214B51AE2FD for ; Sun, 24 Nov 2013 08:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWtuO7q7u7D2 for ; Sun, 24 Nov 2013 08:42:00 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 466C21AE122 for ; Sun, 24 Nov 2013 08:42:00 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hm4so2602695wib.6 for ; Sun, 24 Nov 2013 08:41:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MivGWqxWKpxWJlNJfP8cTHpLnTuMI2xpcDXcIvM6HnA=; b=dK3ErbuXiHWgqi3YT4H3C/7WwBtvmGHRkjkH79uXz9O8EfdWsGDeWwxHUuBVMYYJmy DWp6KOuNDsetUfpwojrur9wvixuv76bjzZ2NiF3xX4RLLtR2UvU7XD7rmYRYN4fHC8hp cSFelV/e8vXjXPlwN5KrW652CoLbPCdgYp4iOM2umP3EuwijEeB6GV57zI3hi1kW0m+Z vqidsFL3e7gr5JNiRSOTZ0pm7O8g8Ajdg5rpl1q6KGvHaUISKLCnz+jVCsTNVuIsxiqs KRx0WYA0hQVqFev/Nq2iCMT3u1J84iAKKBDBCcfKcydHIMAn/BP43OhDyRJ3sAUMeeAx J0dQ== X-Gm-Message-State: ALoCoQkx9Fmv9d+HSsHzcwffEewsyxIufibrhFhCn3o/I7zCchzXrmp5E9eKtvfQK1Z4YeV62njP X-Received: by 10.194.1.139 with SMTP id 11mr2039323wjm.33.1385311311602; Sun, 24 Nov 2013 08:41:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sun, 24 Nov 2013 08:41:11 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> From: Eric Rescorla Date: Sun, 24 Nov 2013 08:41:11 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b3a8c30a1c11304ebeeec28 Cc: Michael Tuexen , Peter Thatcher , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 16:42:02 -0000 --047d7b3a8c30a1c11304ebeeec28 Content-Type: text/plain; charset=ISO-8859-1 And in case it's not obvious, there probably also needs to be a way to interrogate the PC to find the current remote value so that the application can chunk if it wants. -Ekr On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla wrote: > For concreteness, here's what I suggest. > > - An SDP attribute which indicates the maximum message size that > the endpoint is willing to accept. The other side should assume that > any larger message will be rejected, though there is no requirement > that it do so (just as there is no requirement to behave in any > particular way if an unadvertised RTP PT is received). > > - If the attribute is not present, the assumption is that there is some > sensible (small) default that matches the behavior of existing > browsers. 64k? > > - An attribute value of '0' means I will do my best with whatever you > send me, subject to memory capacity, etc. > > - Proposed name: 'max-message-size' > > -Ekr > > > > On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson wrote: > >> On 23 November 2013 13:32, Eric Rescorla wrote: >> > 3. The semantics should be that each side just gets to inform the other >> > side of their value, not that it's negotiated. >> >> This is especially important. "negotiation" here makes zero sense. >> > > --047d7b3a8c30a1c11304ebeeec28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And in case it's not obvious, there probably also need= s to be a way to
interrogate the PC to find the current remote valu= e so that the
application can chunk if it wants.

-Ekr



On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla <ekr@rtfm= .com> wrote:
For concreteness, here'= s what I suggest.

- An SDP attribute which indicates the= maximum message size that
=A0 the endpoint is willing to accept. The other side should assume th= at
=A0 any larger message will be rejected, though there is no requiremen= t
=A0 that it do so (just as there is no requirement to behave in= any
=A0 particular way if an unadvertised RTP PT is received).

- If the attribute is not present, the assumption is th= at there is some
=A0 sensible (small) default that matches the be= havior of existing
=A0 browsers. 64k?

- = An attribute value of '0' means I will do my best with whatever you=
=A0 send me, subject to memory capacity, etc.

- Proposed name: 'max-message-size'

-Ekr<= /div>



On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com> wrote:
> 3. The semantics should be that each side just gets to inform the othe= r
> side of their value, not that it's negotiated.

This is especially important. =A0"negotiation" here makes z= ero sense.


--047d7b3a8c30a1c11304ebeeec28-- From Michael.Tuexen@lurchi.franken.de Sun Nov 24 08:47:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1C1AE3DB for ; Sun, 24 Nov 2013 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iT_7Jr6PMOJX for ; Sun, 24 Nov 2013 08:47:15 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D806F1AE3D8 for ; Sun, 24 Nov 2013 08:47:14 -0800 (PST) Received: from [192.168.1.134] (p5481B8BE.dip0.t-ipconnect.de [84.129.184.190]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 02D2B1C0C0692; Sun, 24 Nov 2013 17:47:04 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Sun, 24 Nov 2013 17:47:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1510) Cc: Peter Thatcher , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 16:47:17 -0000 On Nov 24, 2013, at 5:15 PM, Eric Rescorla wrote: > For concreteness, here's what I suggest. >=20 > - An SDP attribute which indicates the maximum message size that > the endpoint is willing to accept. The other side should assume that > any larger message will be rejected, though there is no requirement > that it do so (just as there is no requirement to behave in any > particular way if an unadvertised RTP PT is received). >=20 > - If the attribute is not present, the assumption is that there is = some > sensible (small) default that matches the behavior of existing > browsers. 64k? >=20 > - An attribute value of '0' means I will do my best with whatever you > send me, subject to memory capacity, etc. >=20 > - Proposed name: 'max-message-size' I agree with the semantic, but I think 'supported-message-size' = describes better what you describe above. It is not the maximum, since it is not = specified what happens with larger messages. Don't get me wrong: I like you = semantic, just find the name a bit misleading. Why not remove your second point? If the sender wants to limit the size, it will signal it in SDP, if it has no limit, it doesn't signal it. Best regards Michael >=20 > -Ekr >=20 >=20 >=20 > On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson = wrote: > On 23 November 2013 13:32, Eric Rescorla wrote: > > 3. The semantics should be that each side just gets to inform the = other > > side of their value, not that it's negotiated. >=20 > This is especially important. "negotiation" here makes zero sense. >=20 From ekr@rtfm.com Sun Nov 24 08:52:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E521AE2FD for ; Sun, 24 Nov 2013 08:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQkqTd3-H60p for ; Sun, 24 Nov 2013 08:52:24 -0800 (PST) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5481AE3D4 for ; Sun, 24 Nov 2013 08:52:24 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u56so2897381wes.23 for ; Sun, 24 Nov 2013 08:52:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xECu1fPY74Af/dkS88I4Fz1PKt/2DMnwhW3UMPbuYIA=; b=UeJ39vHILtFRNjSybfbBzR0Ec/yvW5b2TmPGTxr6VRsyUFAWFTwJETHwc6e/3vlCMp 1xdley2+bT8PtSd2tD0TadeVpRmHYNev8OIh2MMX4nhXoJcRy7tCpEPEl7JPmWm1dsMR qRHnF1lEDezN/bMnB+wvZhLg4hQPwk0vUAmkUSSYBevv44cXMABJUoz7U6jUBwo/1QZa d3sBnEgn1dEirZ8yQCWIZecRbFEUsubDFQOEaBmZ5nf+MPqchKBS+Kn6Tr3J9S0PgLrU 0xasYvkjHY4XkTZtnQDXkBQQ1LtAWSJAZzi1VADLWE7cCCehLBNI084TtvGxJky1ercg ZYSw== X-Gm-Message-State: ALoCoQm+3OYa3qDpcE5MuMVkWLUGU3G1jv/F1hMfb+faGiROzBU3XYuxDlviE+rNqvkwaLMemN4B X-Received: by 10.180.211.71 with SMTP id na7mr10528829wic.5.1385311935863; Sun, 24 Nov 2013 08:52:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Sun, 24 Nov 2013 08:51:35 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> From: Eric Rescorla Date: Sun, 24 Nov 2013 08:51:35 -0800 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=001a11c347e0d7350004ebef11e7 Cc: Peter Thatcher , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 16:52:28 -0000 --001a11c347e0d7350004ebef11e7 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 24, 2013 at 8:47 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On Nov 24, 2013, at 5:15 PM, Eric Rescorla wrote: > > > For concreteness, here's what I suggest. > > > > - An SDP attribute which indicates the maximum message size that > > the endpoint is willing to accept. The other side should assume that > > any larger message will be rejected, though there is no requirement > > that it do so (just as there is no requirement to behave in any > > particular way if an unadvertised RTP PT is received). > > > > - If the attribute is not present, the assumption is that there is some > > sensible (small) default that matches the behavior of existing > > browsers. 64k? > > > > - An attribute value of '0' means I will do my best with whatever you > > send me, subject to memory capacity, etc. > > > > - Proposed name: 'max-message-size' > I agree with the semantic, but I think 'supported-message-size' describes > better what you describe above. It is not the maximum, since it is not > specified > what happens with larger messages. Don't get me wrong: I like you semantic, > just find the name a bit misleading. > I would be fine with your proposed name. Why not remove your second point? If the sender wants to limit the size, > it will signal it in SDP, if it has no limit, it doesn't signal it. > Ordinarily I would agree with you, but there are extant implementations which don't signal so I'm thinking of minimizing failures with them. -Ekr Best regards > Michael > > > > -Ekr > > > > > > > > On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson < > martin.thomson@gmail.com> wrote: > > On 23 November 2013 13:32, Eric Rescorla wrote: > > > 3. The semantics should be that each side just gets to inform the other > > > side of their value, not that it's negotiated. > > > > This is especially important. "negotiation" here makes zero sense. > > > > --001a11c347e0d7350004ebef11e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Nov 24, 2013 at 8:47 AM, Michael Tuexen &= lt;Mi= chael.Tuexen@lurchi.franken.de> wrote:
On Nov 24, 2013, at 5:15 P= M, Eric Rescorla <ekr@rtfm.com> w= rote:

> For concreteness, here's what I suggest.
>
> - An SDP attribute which indicates the maximum message size that
> =A0 the endpoint is willing to accept. The other side should assume th= at
> =A0 any larger message will be rejected, though there is no requiremen= t
> =A0 that it do so (just as there is no requirement to behave in any > =A0 particular way if an unadvertised RTP PT is received).
>
> - If the attribute is not present, the assumption is that there is som= e
> =A0 sensible (small) default that matches the behavior of existing
> =A0 browsers. 64k?
>
> - An attribute value of '0' means I will do my best with whate= ver you
> =A0 send me, subject to memory capacity, etc.
>
> - Proposed name: 'max-message-size'
I agree with the semantic, but I think 'supported-message-size= 9; describes
better what you describe above. It is not the maximum, since it is not spec= ified
what happens with larger messages. Don't get me wrong: I like you seman= tic,
just find the name a bit misleading.

I = would be fine with your proposed name.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Why not remove your second point? If the sender wants to limit the size, it will signal it in SDP, if it has no limit, it doesn't signal it.
=

Ordinarily I would agree with you, but the= re are extant implementations
which don't signal so I'm t= hinking of minimizing failures with them.

-Ekr

Best regards
Michael
>
> -Ekr
>
>
>
> On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com> wrote:
> > 3. The semantics should be that each side just gets to inform the= other
> > side of their value, not that it's negotiated.
>
> This is especially important. =A0"negotiation" here makes ze= ro sense.
>


--001a11c347e0d7350004ebef11e7-- From partha@parthasarathi.co.in Sun Nov 24 12:19:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF411AE1E9 for ; Sun, 24 Nov 2013 12:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAEBZN6JqPWq for ; Sun, 24 Nov 2013 12:19:55 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9821AE18C for ; Sun, 24 Nov 2013 12:19:55 -0800 (PST) Received: from userPC (unknown [122.179.42.105]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id A9DEF19083BA; Sun, 24 Nov 2013 20:19:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385324387; bh=x8zYyJFveOpDh02YZVmlcKYntlTF87HV7iHxNkKykno=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=G3QcH4EJ8ZBWJS78P5yBMS3PNKUkYkwm72ohgBMvZF11ZkVyHOChWMOucYdaZv2N2 h+siH0QNtThi5QMlc1uJLh3Qb8lysPqv9vNklaADxTdErM5XfUYNu9RvLMWeCVhp6p JV2b7zQuaS445NGQu3yIsf311j2D1D9NVuq0m1kY= From: "Parthasarathi R" To: "'SM'" References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> In-Reply-To: <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> Date: Mon, 25 Nov 2013 01:49:39 +0530 Message-ID: <003301cee952$852cd120$8f867360$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7lXW/BZ87V0ZmXQ6CrxW1s2CzoOgD7jBdQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.52925F63.0065, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.100 X-CTCH-Rules: SUBJECT_NEEDS_ENCODING, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: 'Flemming Andreasen' , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 20:19:57 -0000 Hi SM, Thanks for the clarification that the draft solution is fine for you. The issue/clarification required is w.r.t the type of RFC and the reference to the original codec (ITU) specification. Please note that the original publication of the draft was done as "BCP" (http://tools.ietf.org/html/draft-muthu-mmusic-offer-answer-g723-g729-00). It was discussed in length during IETF-84 and the draft was submitted as "standards track" as per WG decision ( http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html). Including Flemming & Ari in this mail thread explicitly. As far as the reference is considered, this draft aims at offer/answer mechanism for SDP attributes which are described as part of RFC 4856 and the corresponding codec ITU specification is supposed to be referenced in RFC 4856 only. I could not understand the logic why this specification has to mention ITU codec specification. Apart from this, we (The authors) consider that RFC 4856 is in the correct RFC type. If you think that RFC 4856 status is wrong, Let us discuss in the separate mail thread. Thanks Partha > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, November 20, 2013 12:57 AM > To: Parthasarathi R > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Last Call: 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) > to Proposed Standard > > Hi Partha, > > I forgot to mention that I am not subscribed to the MMUSIC mailing > list. > > At 10:27 19-11-2013, Parthasarathi R wrote: > >I have clarified all your below queries. Could you please let me know > in > >case you still see any specific issue with the draft. > > In my humble opinion RFC 4856 is more about a media type registration > request instead of a technical specification about > interoperability. It is mentioned in Section 1 of that RFC that it > updates the media type registrations. The fact that RFC 4856 is > published as a Proposed Standard does not mean that it is the correct > status. There are a lot of oddities in the IETF Stream. I prefer > not to ask about those oddities. :-) > > draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 > Annex B. There aren't any references for them. The problem with the > draft is that it builds upon RFC 4856 instead of the technical > specification where the protocol is specified. Is G723 Annex A and > G729 Annex B needed to implement what the draft tries to do? In my > opinion, yes. > > The document shepherd write-up has the following question: > > "Why is this the proper type of RFC?" > > The answer provided is: > > "Proposed Standard. The title page notes the document as Standards > Track" > > That does not answer the question. > > Regards, > -sm From pkyzivat@alum.mit.edu Sun Nov 24 12:55:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995BD1AE172 for ; Sun, 24 Nov 2013 12:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjvAcpp1sT2z for ; Sun, 24 Nov 2013 12:55:23 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id C521D1AE02D for ; Sun, 24 Nov 2013 12:55:22 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id tYgU1m0040QuhwU5DYvEAu; Sun, 24 Nov 2013 20:55:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id tYvE1m0043ZTu2S3NYvEJJ; Sun, 24 Nov 2013 20:55:14 +0000 Message-ID: <529267B2.8030008@alum.mit.edu> Date: Sun, 24 Nov 2013 12:55:14 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> In-Reply-To: <003301cee952$852cd120$8f867360$@co.in> 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=1385326514; bh=vZx4fTRA9riIFA5yal8Ezgt8dNo6dzIprkk6LvlPIlA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b7qK30m31LM4DYjAb9DaFCeoCZNaZ59THc2uELTm9mkxKawRfDmP6z42dynCbfWb8 EG+RNjE1m/o/h40n/cT9gaLZ5yMqcBQc4+rWlF3W7Gr2ZPOyzEX+WtoXTIBY2pMWvc BiUNh5Qf2ymEj6z/2m7HAqQqSLYZ+cz5HKiE7AEXGN1BZ8No2ixpu7Rv+ZeuvJHfNd hcQpsyleE6OI1FLGS0wtPuK9M0E8sHfU/rln1uOb0tG/Tg76qmtJ+TEkvaitq8G1Q+ jr28cCJXP6hoKIi100uy9hOJ8Q3b6DSKl8ihANSOBRHvWZpN+iC9UlwCYQfBOy07/r 0sSlUcTPZkAGg== Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 20:55:24 -0000 Note that "standards track" is what is used for *drafts* that are intended to become standards. IIUC, this is changed to Proposed Standard when the draft is published as an RFC. Thanks, Paul On 11/24/13 12:19 PM, Parthasarathi R wrote: > Hi SM, > > Thanks for the clarification that the draft solution is fine for you. The > issue/clarification required is w.r.t the type of RFC and the reference to > the original codec (ITU) specification. > > Please note that the original publication of the draft was done as "BCP" > (http://tools.ietf.org/html/draft-muthu-mmusic-offer-answer-g723-g729-00). > It was discussed in length during IETF-84 and the draft was submitted as > "standards track" as per WG decision ( > http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html). > Including Flemming & Ari in this mail thread explicitly. > > As far as the reference is considered, this draft aims at offer/answer > mechanism for SDP attributes which are described as part of RFC 4856 and the > corresponding codec ITU specification is supposed to be referenced in RFC > 4856 only. I could not understand the logic why this specification has to > mention ITU codec specification. > > Apart from this, we (The authors) consider that RFC 4856 is in the correct > RFC type. If you think that RFC 4856 status is wrong, Let us discuss in the > separate mail thread. > > Thanks > Partha > >> -----Original Message----- >> From: SM [mailto:sm@resistor.net] >> Sent: Wednesday, November 20, 2013 12:57 AM >> To: Parthasarathi R >> Cc: mmusic@ietf.org >> Subject: RE: [MMUSIC] Last Call: > 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) >> to Proposed Standard >> >> Hi Partha, >> >> I forgot to mention that I am not subscribed to the MMUSIC mailing >> list. >> >> At 10:27 19-11-2013, Parthasarathi R wrote: >>> I have clarified all your below queries. Could you please let me know >> in >>> case you still see any specific issue with the draft. >> >> In my humble opinion RFC 4856 is more about a media type registration >> request instead of a technical specification about >> interoperability. It is mentioned in Section 1 of that RFC that it >> updates the media type registrations. The fact that RFC 4856 is >> published as a Proposed Standard does not mean that it is the correct >> status. There are a lot of oddities in the IETF Stream. I prefer >> not to ask about those oddities. :-) >> >> draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 >> Annex B. There aren't any references for them. The problem with the >> draft is that it builds upon RFC 4856 instead of the technical >> specification where the protocol is specified. Is G723 Annex A and >> G729 Annex B needed to implement what the draft tries to do? In my >> opinion, yes. >> >> The document shepherd write-up has the following question: >> >> "Why is this the proper type of RFC?" >> >> The answer provided is: >> >> "Proposed Standard. The title page notes the document as Standards >> Track" >> >> That does not answer the question. >> >> Regards, >> -sm > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From Michael.Tuexen@lurchi.franken.de Sun Nov 24 13:48:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E241AE36C for ; Sun, 24 Nov 2013 13:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A3r7f9YmBjE for ; Sun, 24 Nov 2013 13:48:56 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CAC501AE10B for ; Sun, 24 Nov 2013 13:48:55 -0800 (PST) Received: from [192.168.1.134] (p5481B8BE.dip0.t-ipconnect.de [84.129.184.190]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BFF971C0C0693; Sun, 24 Nov 2013 22:48:45 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Sun, 24 Nov 2013 22:48:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1510) Cc: Peter Thatcher , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2013 21:48:58 -0000 On Nov 24, 2013, at 5:51 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Sun, Nov 24, 2013 at 8:47 AM, Michael Tuexen = wrote: > On Nov 24, 2013, at 5:15 PM, Eric Rescorla wrote: >=20 > > For concreteness, here's what I suggest. > > > > - An SDP attribute which indicates the maximum message size that > > the endpoint is willing to accept. The other side should assume = that > > any larger message will be rejected, though there is no = requirement > > that it do so (just as there is no requirement to behave in any > > particular way if an unadvertised RTP PT is received). > > > > - If the attribute is not present, the assumption is that there is = some > > sensible (small) default that matches the behavior of existing > > browsers. 64k? > > > > - An attribute value of '0' means I will do my best with whatever = you > > send me, subject to memory capacity, etc. > > > > - Proposed name: 'max-message-size' > I agree with the semantic, but I think 'supported-message-size' = describes > better what you describe above. It is not the maximum, since it is not = specified > what happens with larger messages. Don't get me wrong: I like you = semantic, > just find the name a bit misleading. >=20 > I would be fine with your proposed name. OK. >=20 >=20 > Why not remove your second point? If the sender wants to limit the = size, > it will signal it in SDP, if it has no limit, it doesn't signal it. >=20 > Ordinarily I would agree with you, but there are extant = implementations > which don't signal so I'm thinking of minimizing failures with them. Obviously, currently no implementation currently uses this. I just want future implementation to provide a limit and to implement application level reassembly for valid message size and protection against too large = messages. Maybe we can use appropriate wording to try to enforce that. Than I'm = happy. Best regards Michael >=20 > -Ekr >=20 > Best regards > Michael > > > > -Ekr > > > > > > > > On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson = wrote: > > On 23 November 2013 13:32, Eric Rescorla wrote: > > > 3. The semantics should be that each side just gets to inform the = other > > > side of their value, not that it's negotiated. > > > > This is especially important. "negotiation" here makes zero sense. > > >=20 >=20 From iesg-secretary@ietf.org Mon Nov 25 09:40:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC31ADF80; Mon, 25 Nov 2013 09:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOzA4yPaPwgx; Mon, 25 Nov 2013 09:40:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C511ADFD0; Mon, 25 Nov 2013 09:40:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131125174009.14077.62820.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2013 09:40:09 -0800 Cc: mmusic chair , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Duplication Grouping Semantics in the Session Description Protocol' to Proposed Standard (draft-ietf-mmusic-duplication-grouping-04.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:40:13 -0000 The IESG has approved the following document: - 'Duplication Grouping Semantics in the Session Description Protocol' (draft-ietf-mmusic-duplication-grouping-04.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ Technical Summary Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework [RFC5888]. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. Working Group Summary There is WG consensus behind this draft. All issues raised during and before WGLC have been addressed. Document Quality The document has received multiple reviews from working group participants and the document shepherd. There is currently at least one vendor implementing this mechanism and various other vendors have expressed interest for this technique. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Ari Keranen is the Document Shepherd, and the Responsible Area Director is Gonzalo Camarillo. From pthatcher@google.com Mon Nov 25 08:13:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E281ADF88 for ; Mon, 25 Nov 2013 08:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTHf_GnKpPQA for ; Mon, 25 Nov 2013 08:13:55 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E95EF1ADF59 for ; Mon, 25 Nov 2013 08:13:54 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so5806005pde.0 for ; Mon, 25 Nov 2013 08:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uk/EgQN11C+P7Tyvt0UzaOTK/6RqjtTHR95fVq8WNQg=; b=TSq0mzFcbB2IJ4RRUN9dourZ3JSeejkSrIfZbGrV1LnZyeqmi0FrPkUWtlvR9Bzaue y5Mlz87xgZeL2DmEe5tV0MAR4/Su6YyMRncL34XWGvKELUcwNxOK9ZV1ur9XRy3ISziP WCC6gh3NR3uKzzhwIlBaeoBs8O2yPNIri0HR/86mXLEl+SfIQxsfYiV/nReOPeoAO4fz o9wcdvZQViMjHa1nCktXokqAJHG3D/05siZhC74KVb9/vjVwowjrr45mUaWgTFhKcufm 9xNrIP9YyJMcgvLbPnU5d+umEWBUjaNPAOg9lsQgldxeO9awXlh1AQ6Gmr3y/2yA7PJ5 XK6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uk/EgQN11C+P7Tyvt0UzaOTK/6RqjtTHR95fVq8WNQg=; b=ZIjHbcEHnyp567/WbIeiDzA9rod4IemDNuohzL76f31Q8VRI38vP02Gaa1M/4b9mgE Kblc/KUT11pqYE6Ty7UWWpOXtE3kMoVX9m+7NE7nAuPJU8NdJupWLlXAc1H+9qa10sdY Nbc0BcSEOmkWLw35LDn57cui5tR4cXjFKYyUPzg8eg+eDTneiypAEvvqz3tBNQTUr8Kf FX8BWVUpujUyPKCzMG/XDnT3GYN8vtjsgrnWV4wLznaqdXvBIBeg0NxuD625H7uTjtdh QT3Cl8p2XZBQW1vQ+lab5KiHG8RtG5c7A7QG2renssppNy2RWt563gVmdKi6G/NnZWAB ms+Q== X-Gm-Message-State: ALoCoQltnc27XApeI/xwD/k005cVN+6/1SoCIKewXiJkv57Z5I8R1Yl/YzxoIHqrr7fwJ6eAeSQaj3+48A4+JXb4j0QxKXJpthEJECgj1Co6RonYCNTGXEjYvFUzAlw30fDu9DkSv9zxipZbE2yLo29BCWOShVcIYCeP+Kd+RASvx8Nwcq9hWxXYLBIv32nLXokMRLk+RNXU X-Received: by 10.68.180.2 with SMTP id dk2mr7198795pbc.94.1385396035221; Mon, 25 Nov 2013 08:13:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.163.234 with HTTP; Mon, 25 Nov 2013 08:13:14 -0800 (PST) In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> From: Peter Thatcher Date: Mon, 25 Nov 2013 08:13:14 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b5d5f4a8d984304ec02a649 X-Mailman-Approved-At: Mon, 25 Nov 2013 10:34:42 -0800 Cc: Michael Tuexen , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 16:13:56 -0000 --047d7b5d5f4a8d984304ec02a649 Content-Type: text/plain; charset=UTF-8 Your proposal all sounds good to me. I don't feel strongly one way or the other about "max-" vs. "supported-". On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla wrote: > For concreteness, here's what I suggest. > > - An SDP attribute which indicates the maximum message size that > the endpoint is willing to accept. The other side should assume that > any larger message will be rejected, though there is no requirement > that it do so (just as there is no requirement to behave in any > particular way if an unadvertised RTP PT is received). > > - If the attribute is not present, the assumption is that there is some > sensible (small) default that matches the behavior of existing > browsers. 64k? > > - An attribute value of '0' means I will do my best with whatever you > send me, subject to memory capacity, etc. > > - Proposed name: 'max-message-size' > > -Ekr > > > > On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson wrote: > >> On 23 November 2013 13:32, Eric Rescorla wrote: >> > 3. The semantics should be that each side just gets to inform the other >> > side of their value, not that it's negotiated. >> >> This is especially important. "negotiation" here makes zero sense. >> > > --047d7b5d5f4a8d984304ec02a649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Your proposal all sounds good to me. =C2=A0I don't feel str= ongly one way or the other about "max-" vs. "supported-"= ;.


On Sun,= Nov 24, 2013 at 8:15 AM, Eric Rescorla <ekr@rtfm.com> wrote:
=
For concreteness, here's what I suggest.

- An SDP attribute which indicates the maximum message size that
=C2=A0 the endpoint is willing to accept. The other side should assum= e that
=C2=A0 any larger message will be rejected, though there is no require= ment
=C2=A0 that it do so (just as there is no requirement to beh= ave in any
=C2=A0 particular way if an unadvertised RTP PT is rec= eived).

- If the attribute is not present, the assumption is th= at there is some
=C2=A0 sensible (small) default that matches the= behavior of existing
=C2=A0 browsers. 64k?

<= div>- An attribute value of '0' means I will do my best with whatev= er you
=C2=A0 send me, subject to memory capacity, etc.

<= div>- Proposed name: 'max-message-size'

-E= kr



On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com> wrote:
> 3. The semantics should be that each side just gets to inform the othe= r
> side of their value, not that it's negotiated.

This is especially important. =C2=A0"negotiation" here make= s zero sense.


--047d7b5d5f4a8d984304ec02a649-- From eckelcu@cisco.com Mon Nov 25 13:00:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08EF1AE00C for ; Mon, 25 Nov 2013 13:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.702 X-Spam-Level: X-Spam-Status: No, score=-12.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psiKb7tTZgj9 for ; Mon, 25 Nov 2013 13:00:55 -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 3F4761ADFFA for ; Mon, 25 Nov 2013 13:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17091; q=dns/txt; s=iport; t=1385413255; x=1386622855; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=EDO3xaTjOje27fPQrUtdUCVvwBJn4pkm6xv9Ht2FyFg=; b=KWpONFliT5BLHkE3gY36Y5i8XhTn/nooxChZxNe+8TPkTVYsWx0U63Vk 6IoJ9ypVjHtA2wRwxyMj0jAl9pMQLjtvSBUVzuOBBBXNpoNUxZnURs9nm SnlBt4X1LeA4WMmrlKgYECxL/73wikTroFRe6kovTMLOi0w+1V4W45HgA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFABC6k1KtJV2b/2dsb2JhbABZgwc4U7tcToEsFnSCJQEBAQQBAQEJXAYLDAYBCBEEAQEBJy4LFAkIAgQBDQUJCweHZQENvkoXjjAGAQEcMwIFBoQtA5NvQoNjkhKDKIFpCBci X-IronPort-AV: E=Sophos;i="4.93,769,1378857600"; d="scan'208";a="287447026" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 25 Nov 2013 21:00:54 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAPL0sKO023601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 21:00:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 15:00:54 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session Thread-Index: AQHO4N5p9ObMK+oa+UC3S7P1Fu4dKZoknjaAgAKwh4CACjaVAIABr6KAgAMqoQA= Date: Mon, 25 Nov 2013 21:00:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [171.68.20.22] Content-Type: text/plain; charset="windows-1254" Content-ID: <1C5C62C44605F6438CA2EB53BBF5F63C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 21:00:59 -0000 Hi Christer, Yes, I understand and agree with that. As mentioned in the BFCPBIS thread, indicating "actpass" in the offer is important for B2BUAs that rely on this in order to be able to match up the two sides of a call. For example, such a B2BUA would send an INVITE without an offer and expect to receive back an offer with the capabilities of the remote endpoint. If that endpoint sends back "actpass" in its offer, the B2BUA is free to answer with either "active" or "passive" in order to match this up with the associated call on the other side of the B2BUA. This way the B2BUA can participate in the SIP/SDP signaling yet not be in the path of the the BFCP over DTLS channel. Cheers, Charles On 11/23/13 4:39 AM, "Christer Holmberg" wrote: >Hi Charles, > >In the thread you refer to, I don't think you considered the alternative >we are discussing now :) > >The discussion was more about whether the setup attribute shall be used >to determine the TLS role to begin with, and the outcome was that the >attribute IS used. We are NOT changing that for UDPTL-DTLS, we are simply >relaxing the MUST-indicate-actpass-in-the-offer rule. > >Regards, > >Christer > >Sent from my Sony Ericsson Xperia arc S > >"Charles Eckel (eckelcu)" wrote: > > >Within the BFCPBIS working group, we debated this same point. In the end, >we decided it was best to align with RFC 5763. Here is the thread for your >reference: >http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00167.html > >Cheers, >Charles > > >On 11/15/13 2:56 PM, "Gonzalo Salgueiro (gsalguei)" >wrote: > >>TBH I didn't see a compelling reason to make the change in the first >>place. If it is important to Albrecht, I think this proposal is fine and >>seems innocuous to the proposed solution. >> >>Gonzalo >> >> >>On Nov 14, 2013, at 12:52 AM, Christer Holmberg >> wrote: >> >>> Hi, >>> >>> I guess 'SHOULD use actpass' would work. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Sony Ericsson Xperia arc S >>> >>> Paul Kyzivat wrote: >>> >>> >>> I believe that the a=3Dsetup attribute was first defined by rfc 4145, f= or >>>TCP. >>> >>> There it governs who listens for an incoming connection. And the main >>> concern was that NATs/FWs might prevent one end or the other from >>> accepting incoming connections. Even so, it didn't have any normative >>> behavior about what should be in the offer. >>> >>> As this same attribute is used in different contexts, the implications >>> of using it may vary. In particular, if it is intended that either end >>> should be able to take either the active or passive role, then the >>> considerations for use may vary. >>> >>> ISTM that actpas SHOULD be used in the offer, except in cases where the >>> offerer has a particular preference for active or passive, and would >>> prefer to have the connection fail than use the other mode. >>> >>> Thanks, >>> Paul >>> >>> On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote: >>>> Right. >>>> >>>> >>>>----------------------------------------------------------------------- >>>>- >>>> *Von:* Christer Holmberg [christer.holmberg@ericsson.com] >>>> *Gesendet:* Donnerstag, 14. November 2013 02:21 >>>> *An:* Schwarz, Albrecht (Albrecht) >>>> *Cc:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >>>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>> session >>>> >>>> Hi Albrecht, >>>> >>>> If I understand your proposal correctly, the change would be to relax >>>> the rule for assigning the SDP setup attribute value in the SDP Offer. >>>> Instead of mandating actpass, we would also allow active and passive. >>>> >>>> Right? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >>>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>>> *L=E4hetetty:* 14. marraskuuta 2013 3:11 >>>> *Vastaanottaja:* Christer Holmberg >>>> *Kopio:* mmusic@ietf.org; LANDAIS, BRUNO (BRUNO) >>>> *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>>session >>>> >>>> Hello Christer, >>>> guess it's time to come back on this topic since the WG adopted the >>>>draft. >>>> >>>> In brief ("don't want to repeat again the thread"): >>>> a) problem statement: existing SDP O/A rules define a tighly coupled >>>> mode between the establishment direction of the SIP session and the >>>> establishment direction of the DTLS session, but there's not any >>>> reasoning for such tightly coupled behaviour. >>>> >>>> b) change proposal: >>>> Revise in clause 3.1 following list item >>>> >>>> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>>> >>>> offerer MUST assign the SDP setup attribute with setup:actpass >>>> >>>> value, and MUST be prepared to receive a DTLS client_hello >>>>message >>>> >>>> before it receives the SDP answer. The answerer MUST assign the >>>> >>>> SDP setup attribute with either setup:active value or >>>> >>>> setup:passive value. The answerer SHOULD assign the SDP setup >>>> >>>> attribute with the setup:active value. Whichever party is >>>>active >>>> >>>> MUST initiate a DTLS handshake by sending a ClientHello over >>>>each >>>> >>>> flow (host/port quartet). >>>> >>>> >>>> by >>>> >>>> o The endpoint MUST use the SDP setup attribute [RFC4145]. The >>>> >>>> offerer MUST assign the SDP setup attribute with a >>>>setup:actpass, >>>> setup:active or setup:passive >>>> >>>> value, and, in case of setup:actpass or setup:passive, MUST be >>>> prepared to receive a DTLS client_hello message >>>> >>>> before it receives the SDP answer. The answerer MUST assign the >>>> >>>> SDP setup attribute with either setup:active value or >>>> >>>> setup:passive value. The answerer SHOULD assign the SDP setup >>>> >>>> attribute with the setup:active value, in case of setup:actpass >>>> or setup:passive. Whichever party is active >>>> >>>> MUST initiate a DTLS handshake by sending a ClientHello over >>>>each >>>> >>>> flow (host/port quartet). >>>> >>>> >>>> We would limit ourselves with the existing, restrictive SDP O/A rule. >>>> And without any justification for such a constraint. >>>> >>>> Any comments? >>>> >>>> Regards, >>>> Albrecht >>>> >>>> >>>> >>>>----------------------------------------------------------------------- >>>>- >>>> >>>> *Von:*Christer Holmberg [christer.holmberg@ericsson.com] >>>> *Gesendet:* Montag, 7. Oktober 2013 13:11 >>>> *An:* Schwarz, Albrecht (Albrecht) >>>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>>> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>> session >>>> >>>> Hi Albrecht, >>>> >>>> At this point, the community is making a decision about whether to >>>>start >>>> working on this. >>>> >>>> Once that is done, we will start looking into, and discuss, individual >>>> technical issues etc, and your input will be highly appreciated. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> *L=E4hett=E4j=E4:*Schwarz, Albrecht (Albrecht) >>>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>>> *L=E4hetetty:* 7. lokakuuta 2013 13:56 >>>> *Vastaanottaja:* Christer Holmberg >>>> *Kopio:* mmusic@ietf.org ; LANDAIS, BRUNO >>>>(BRUNO) >>>> *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>>session >>>> >>>> Hello Christer, >>>> >>>> I may not commit to submit a problem statement in the next couple of >>>> weeks, just due to time reasons. >>>> >>>> At least a note (or editor=B9s note) should be added to draft >>>> mmusic-udptl-dtls in order to indicate the issue and that a solution >>>> proposal is still pending. >>>> >>>> Thanks, >>>> >>>> Albrecht >>>> >>>> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> *Sent:* Dienstag, 24. September 2013 16:01 >>>> *To:* Schwarz, Albrecht (Albrecht) >>>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>> session >>>> >>>> Hi Albrecht, >>>> >>>> I don't think putting a note somewhere in the fax draft is going to >>>> solve anything. >>>> >>>> As you indicate, the issue exists in multiple documents, so it's a >>>> generic issues. >>>> >>>> So, my suggestion is that you put together a short draft which >>>>describes >>>> the problem, and how you want to change it, and then we can have a >>>>more >>>> generic discussion about it. The WG can then decide whether we shall >>>>fix >>>> something, and if so, in which specs. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>>----------------------------------------------------------------------- >>>>- >>>> >>>> *From:*Schwarz, Albrecht (Albrecht) >>>>[albrecht.schwarz@alcatel-lucent.com] >>>> *Sent:* Tuesday, 24 September 2013 4:22 PM >>>> *To:* Christer Holmberg >>>> *Cc:* mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>>> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>> session >>>> >>>> Hello Christer, >>>> >>>> the "copy & paste" action (across at least three "RFCs") seems to be >>>>the >>>> root cause of the issue :-( >>>> >>>> SIP session establishment and L4 security session (DTLS, TLS) >>>> establishment directions should be principally decoupled because >>>> application specific. >>>> >>>> We got here (wrt DTLS) three (different!) applications: >>>> 1) Key exchange (RFC 5763) >>>> 2) Conference control (rfc4582bis) >>>> 3) Document transmission (udptl-dtls) >>>> >>>> All three applications are different in terms of number/type of >>>> supported network models, security models or/and communication >>>>topology. >>>> >>>> Consequently, the basic, application independent SDP O/A rules for >>>>DTLS >>>> session establishment would need to support that flexibility. >>>> The application specific SIP/SDP profile could then still narrow down >>>> the required SDP O/A rules. >>>> >>>> What we got so far: SDP O/A rules in three application specific "RFCs" >>>> (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 >>>>:-( >>>> >>>> There might be two options to correct that copy & paste issue in >>>> "udptl-dtls" in my opinion: >>>> a) expand the SDP O/A rules for more flexibility >>>> or >>>> b) add a WARNING / NOTE about the inherent limitations (due to the >>>> assumption of a network and communication environment according RFC >>>>5763) >>>> >>>> What do you think? >>>> Best regards, >>>> Albrecht >>>> >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Montag, 23. September 2013 11:54 >>>> To: Schwarz, Albrecht (Albrecht) >>>> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>>session >>>> >>>> Hi Albrecht, >>>> >>>> I don't know what model people were focusing on when writing RFC 5763, >>>> but the RFC does say: >>>> >>>> "The endpoint that is the offerer MUST use the setup attribute value >>>>of >>>> setup:actpass" >>>> >>>> ...which we also copied into the udptl-dtls draft. >>>> >>>> Now, if you want to change that, and allow the Offerer to "force" the >>>> direction, I think you should start a separate thread about that. >>>> Because, it is not specific to fax, in my opinion. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: Schwarz, Albrecht (Albrecht) >>>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>>> Sent: 23. syyskuuta 2013 12:31 >>>> To: Christer Holmberg >>>> Cc: mmusic@ietf.org ; LANDAIS, BRUNO (BRUNO) >>>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>>session >>>> >>>> Hello Christer, >>>> >>>> the decision about "DTLS session establishment direction" is ALWAYS up >>>> to the SDP ANSWERER (according present 3.1). >>>> >>>> In order to decouple SIP session and DTLS session establishment >>>> directions, then the SDP OFFERER should also to be able to use >>>> "setup:active" and "setup:passive" (besides codepoint "setup:actpass") >>>> in my understanding. >>>> >>>> I'm not sure whether the reference to RFC 5763 helps because I could >>>> imagine that the subject comes down to the indicated network >>>>scenarios, >>>> lets look again at: >>>> a) T - T >>>> b) T -GW >>>> >>>> The existing udptl-dtls & RFC 5763 text seems to focus on model (a) >>>> only: SDP O/A between two peering, terminal located SIP UAs (there is >>>> NOT any SIP B2BUA). >>>> But I could imagine that the SIP/SDP profiles for "T" and "GW" are not >>>> necessarily the same in case of model (b): "T" as SDP Offerer may not >>>> allowed to decide the DTLS session establishment direction, but "GW" >>>>as >>>> SDP offerer may need to enforce the DTLS session establishment >>>>direction >>>> (either way). >>>> >>>> Regards, >>>> Albrecht >>>> >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Donnerstag, 19. September 2013 10:02 >>>> To: Schwarz, Albrecht (Albrecht) >>>> Cc: mmusic@ietf.org >>>> Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>>session >>>> >>>> Hi Albrecht, >>>> >>>> The direction of the SIP session establishment and the DTLS session >>>> establishment are NOT tightly coupled. The draft enables the Answerer >>>>to >>>> select whether it wants to act as DTLS client or DTLS server. >>>> >>>> Section 3.1 states: >>>> >>>> .... The >>>> offerer MUST assign the SDP setup attribute with setup:actpass value, >>>> and MUST be prepared to receive a DTLS client_hello message before it >>>> receives the SDP answer. The answerer MUST assign the SDP setup >>>> attribute with either setup:active value or setup:passive value. The >>>> answerer SHOULD assign the SDP setup attribute with the setup:active >>>> value. Whichever party is active MUST initiate a DTLS handshake by >>>> sending a ClientHello over each flow (host/port quartet). >>>> >>>> The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In >>>>fact, >>>> we base the procedure on that RFC. >>>> >>>> BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the >>>> DTLS-SRTP procedures for DTLS server determination. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Schwarz, Albrecht (Albrecht) >>>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>>> Sent: 18. syyskuuta 2013 18:28 >>>> To: Christer Holmberg >>>> Cc: mmusic@ietf.org >>>> Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS >>>>session >>>> >>>> The T.38 endpoint could be located in a terminal (=3D T.38 IAF) or in = a >>>> gateway, leading to three possible scenarios of >>>> a) T - T >>>> b) T -GW >>>> c) GW-GW >>>> >>>> I'd like to scope on scenario (b) due to its asymmetry of user- and >>>> network-side located T.38 endpoints. >>>> >>>> Christer, >>>> I thought that the two directions of >>>> 1) SIP session establishment and >>>> 2) DTLS session establishment >>>> should be NOT tightly coupled (as currently supposed to be in clause >>>>3.1)? >>>> The ietf draft should offer the flexibility in decoupling both >>>> establishment directions. >>>> >>>> E.g., there might be the demand to limit DTLS session establishment in >>>> T-to-GW direction (and apply rather the reverse direction) due >>>> ClientHello associated security threats, resource requests in terms of >>>> memory, ... >>>> >>>> In my opinion: >>>> the IETF should allow the flexibility, >>>> other SDOs could still profile/limit this capability. >>>> >>>> Best regards, >>>> Albrecht >>>> >>>> PS >>>> We had a similar discussion with TLS, there NAT traversal (NAT-T) >>>> aspects could influence TLS session establishment direction. However, >>>>I >>>> guess that NAT-T is minor for DTLS/UDP. >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic > From fandreas@cisco.com Mon Nov 25 15:14:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207A01AE07C for ; Mon, 25 Nov 2013 15:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV-kqPtUXvkM for ; Mon, 25 Nov 2013 15:14:02 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 4E90D1AE089 for ; Mon, 25 Nov 2013 15:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2831; q=dns/txt; s=iport; t=1385421242; x=1386630842; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=LMxWzIDCgMeE1/OFwCNw8XCh3ieDyoDP1WCobI0v2mY=; b=c7UUqz9WxUDjEOvTpkJqZWUaAm5RQ0D3sZCMRsjDxXPVg51SKH1lb5Iv OhsB+Pj101Id8BiQHoiHdRh/Qvsdrj8O69x2Y7Nl1eINB21/pI5tIvZoX PO6q1nNkk80UiM8UIx55uRaVXrCZ8NfhVOh34R9nAsB7aGLMIC1QIcdAI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8LAM3Yk1KtJV2d/2dsb2JhbABZgwc4qAQDlClOgSYWdIIlAQEBAwEBAQE1NgoGCwsYCRYPCQMCAQIBFTAGAQwGAgEBh3cGDb5MF48OhDMDiUKOUoEwkGKDRh4 X-IronPort-AV: E=Sophos;i="4.93,770,1378857600"; d="scan'208";a="2183930" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 25 Nov 2013 23:14:02 +0000 Received: from bxb-fandreas-88110.cisco.com (bxb-fandreas-88110.cisco.com [10.98.149.203]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAPNE1dv020858; Mon, 25 Nov 2013 23:14:01 GMT Message-ID: <5293D9B9.4000502@cisco.com> Date: Mon, 25 Nov 2013 18:14:01 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gonzalo Camarillo , mmusic@ietf.org References: <528DDF12.6030701@ericsson.com> In-Reply-To: <528DDF12.6030701@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 23:14:04 -0000 On 11/21/13 5:23 AM, Gonzalo Camarillo wrote: > Folks, > > the IESG is reviewing the RTSP 2.0 spec below: > > http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > > Before progressing the draft, I have been asked by the IESG to check > with the MMUSIC WG whether or not people still think it is worthwhile > publishing this spec. In short: Yes. RTSP 2.0 provides a number of clarificiations, error fixes and updates to RTSP 1.0, which at this point is over 15 years old (see Appendix I for a list of those changes), and while RTSP 2.0 is not backwards compatible with RTSP 1.0 (in some cases due to underspecification of RTSP 1.0), many of the clarifications may prove helpful to implementers of RTSP 1.0, even if they don't migrate. RTSP 2.0 also includes new functionality such as IPv6 and a companion document to assist with NAT traversal, which are just 2 examples of features needed in today's environment. On a non-technical note, the WG agreed to do this work and the work has essentially completed at this point, with a significant amount of effort by the authors, incl. updates to address several in-depth reviews more recently. We usually do not apply a subjective value-judgement to whether a document should be published this late in the game (unless it's potentially harmful), and again, in lieu of the maturity level and effort that has been put into this document, it would not be reasonable to start doing that here. > In particular, they would like to know what level > of deployment we can expect once the spec is published. Clearly RTSP does not have the traction it used to have with HTTP adaptive bit-rate seemingly being all the rage these days. However, a couple of points to consider here: 1) If it doesn't get published, it won't get deployed. 2) Some of the clarifications/updates provided by the RTSP 2.0 spec are of use to RTSP 1.0 implementations as well and hence may prove helpful with resolving existing bugs (I've personally experienced this with other protocols) 3) While the people on this list may or may not indicate their plans around deployment, RTSP is a fairly well-known protocol with a large body of potential implementers beyond those subscribed to this mailing list. My personal experience with other protocols shows that more people look at these things than you may think (outside the WG). I don't see any downside to publishing the spec, but based on the above, there are several good reasons to publishing it and hence I'm in favor of doing so. Thanks -- Flemming > Your input is appreciated. > > Thanks, > > Gonzalo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From juberti@google.com Mon Nov 25 16:13:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2A1AE0F8 for ; Mon, 25 Nov 2013 16:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AdZ8IsqTCln for ; Mon, 25 Nov 2013 16:13:08 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E40C61AE0F5 for ; Mon, 25 Nov 2013 16:13:07 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id c14so3487412vea.14 for ; Mon, 25 Nov 2013 16:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c4aQ+K5H8mh+wfzoKO/QimuLUatp5ItDK6O9rl/jnBI=; b=om4E3JC3Y9hGDWtqCFtifIPv021SdBJ3BegckkU5gMZBtXESBkCPsX99EL3gtNdpR1 WGrNKZsvAPQvd7ZF0oxPmy+aKbJrkOdhygiQJDAaOS0ay5gOr18kw5F7AqR5XoIBskM8 2e/qtVYa1SkHIFbvr48hXJUuWWk///VRskbHY+7iegzOM3R4/F8fqBlEQgskl0omksiZ KXyEqfMtq2iMGYhiL1YhWmQBcW+/2fGV/3JN2H4daRYuqXqRJJPC6NRwchiPRtTqZQMn wMZLuO/1zPa9Z9x+rwh5c+jsQNOAVmOn7YEz0SWo0R3R/Ij6v9oj3nGRjrxY3gW/h5SZ tCaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=c4aQ+K5H8mh+wfzoKO/QimuLUatp5ItDK6O9rl/jnBI=; b=R+8EK8h9sGeMtOY5Yn4svOWJZ3l2xiWzLknP6CvbxKHplPdeHeVPCloD+Mf/lsSyml PLKwatAWZGXphpx+t70H8hJ2hmetbGTHO7yP5I+IH+mxesdTKi1eAgfl15PaZiXF8UVp /W2JcOYMdv8RV+mzUYzlO7h5MuU60YoGu1z/aMuw12ZiKJvQqDhh3NguaCSm3h+fzVlJ YWMdciW7CNMcNBtng9KC7DhPUeii4OvEeHjcxuvT+oRdsy9BCxu8kn8xS/a318whp6vu o0M6cHR1LIqpAPB0axqbsSVlHjqbextz+GTsUhk4LH6Z0VKK9lapFhewkc6yBi8jI3Si gBtg== X-Gm-Message-State: ALoCoQnzJeGuoKuF63GnHyq585gJ8jOu5pVrm8UvR4keO+YLXJPB6VQZmbonZYCs5YW7fPUSj7+nFNdIj9L1ma48zSvBW18QigMVm7BrPPy+GBvCk3yNlokRe/O406QdlGVk+rCL7BWM+41+R9keiMLk00jbus9xmOR/SyyOg89Nu+oWi5vN5ObkaHHC/SjhyJxo+Tq7Rvny X-Received: by 10.58.107.4 with SMTP id gy4mr413603veb.39.1385424787682; Mon, 25 Nov 2013 16:13:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.110.101 with HTTP; Mon, 25 Nov 2013 16:12:47 -0800 (PST) In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> From: Justin Uberti Date: Mon, 25 Nov 2013 16:12:47 -0800 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=089e0122f348555b6904ec0958fa Cc: Michael Tuexen , "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 00:13:09 -0000 --089e0122f348555b6904ec0958fa Content-Type: text/plain; charset=UTF-8 I agree with Eric's suggestions, including '0' as a special case. Regarding naming, I kind of prefer "max-", as there is ample precedent for this, e.g. maxptime, maxplaybackrate in http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03. In fact, for optimal consistency I would argue for |maxmsgsize|. Regarding how the parameter is specified, I beg you not to use positional arguments, and use fmtp named arguments instead, e.g. a=sctpmap:5000 webrtc-datachannel a=fmtp:5000 maxmsgsize=65536 On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher wrote: > Your proposal all sounds good to me. I don't feel strongly one way or the > other about "max-" vs. "supported-". > > > On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla wrote: > >> For concreteness, here's what I suggest. >> >> - An SDP attribute which indicates the maximum message size that >> the endpoint is willing to accept. The other side should assume that >> any larger message will be rejected, though there is no requirement >> that it do so (just as there is no requirement to behave in any >> particular way if an unadvertised RTP PT is received). >> >> - If the attribute is not present, the assumption is that there is some >> sensible (small) default that matches the behavior of existing >> browsers. 64k? >> >> - An attribute value of '0' means I will do my best with whatever you >> send me, subject to memory capacity, etc. >> >> - Proposed name: 'max-message-size' >> >> -Ekr >> >> >> >> On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson > > wrote: >> >>> On 23 November 2013 13:32, Eric Rescorla wrote: >>> > 3. The semantics should be that each side just gets to inform the other >>> > side of their value, not that it's negotiated. >>> >>> This is especially important. "negotiation" here makes zero sense. >>> >> >> > --089e0122f348555b6904ec0958fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Eric's suggestions, including '0= ' as a special case.

Regarding naming, I kind of pr= efer "max-", as there is ample precedent for this, e.g. maxptime,= maxplaybackrate in http://tools.ietf.org/html/draft-spittka-payload-rtp-opus= -03. In fact, for optimal consistency I would argue for |maxmsgsize|.
Regarding how the parameter is specified, I beg you not to u= se positional arguments, and use fmtp named arguments instead, e.g.
a=3Dsctpmap:5= 000 webrtc-datachannel
a=3D= fmtp:5000 maxmsgsize=3D65536


On Mon, Nov 25, 2013 at 8:13 AM, Pete= r Thatcher <pthatcher@google.com> wrote:
Your proposal all sounds good to= me. =C2=A0I don't feel strongly one way or the other about "max-&= quot; vs. "supported-".


On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
For concreteness, here's what I suggest.

- An SDP attribute which indicates the maximum message size that
=C2=A0 the endpoint is willing to accept. The other side should assum= e that
=C2=A0 any larger message will be rejected, though there is no require= ment
=C2=A0 that it do so (just as there is no requirement to beh= ave in any
=C2=A0 particular way if an unadvertised RTP PT is rec= eived).

- If the attribute is not present, the assumption is th= at there is some
=C2=A0 sensible (small) default that matches the= behavior of existing
=C2=A0 browsers. 64k?

<= div>- An attribute value of '0' means I will do my best with whatev= er you
=C2=A0 send me, subject to memory capacity, etc.

<= div>- Proposed name: 'max-message-size'

-E= kr



On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com> wrote:
> 3. The semantics should be that each side just gets to inform the othe= r
> side of their value, not that it's negotiated.

This is especially important. =C2=A0"negotiation" here make= s zero sense.



--089e0122f348555b6904ec0958fa-- From martin.thomson@gmail.com Mon Nov 25 16:15:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F471AE0F8 for ; Mon, 25 Nov 2013 16:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-vY1yrJMCJ8 for ; Mon, 25 Nov 2013 16:15:48 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 182C31AE0FD for ; Mon, 25 Nov 2013 16:15:47 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id a1so2767840wgh.23 for ; Mon, 25 Nov 2013 16:15:47 -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=xom94U2bkESWuHnf/oecOiyiMkIHiw4Vqwi8FJO2b0w=; b=wnhtGpxUqOhpoSzM0Bulwcf0t1vRDVcGfNKyMRpIr3tMOSAF5VwWwViLhgYbUlP7ex 91JeBd8R3aims/Xl89iiNKG1la4vP/lGU5ExvJ8jKhz9ZTevsVg37E4QJIhqUrriLMo2 iwMhzafmAFOSJsepbkGZcz5vUt3D9ar2VKTK8UVenWczYvd9bsxSbft7ryVDoL1TmGSL +G8MoT1C+LDejfEeu7v1dwohTkeNcZpwOdT+FwQmZleYFsn/fzhrzYovBOxdQ9rKh+Ed 7eqkg0J5RXQM4wNQKgfv71MSJ10P5EF5wumec8xOft00R/jWb7e+lWd3AmMJfiXwJ+NB ZDKQ== MIME-Version: 1.0 X-Received: by 10.180.206.18 with SMTP id lk18mr15845724wic.64.1385424947573; Mon, 25 Nov 2013 16:15:47 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 25 Nov 2013 16:15:47 -0800 (PST) In-Reply-To: References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> Date: Mon, 25 Nov 2013 16:15:47 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: Michael Tuexen , "public-webrtc@w3.org" , Peter Thatcher , "mmusic@ietf.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 00:15:50 -0000 On 25 November 2013 16:12, Justin Uberti wrote: > I agree with Eric's suggestions, including '0' as a special case. > > Regarding naming, I kind of prefer "max-", as there is ample precedent for > this, e.g. maxptime, maxplaybackrate in > http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03. In fact, for > optimal consistency I would argue for |maxmsgsize|. > > Regarding how the parameter is specified, I beg you not to use positional > arguments, and use fmtp named arguments instead, e.g. > a=sctpmap:5000 webrtc-datachannel > a=fmtp:5000 maxmsgsize=65536 I like it. From salvatore.loreto@ericsson.com Wed Nov 27 04:40:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D271AE244 for ; Wed, 27 Nov 2013 04:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCPM4UtWRPTV for ; Wed, 27 Nov 2013 04:40:25 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47C1AE1B8 for ; Wed, 27 Nov 2013 04:40:24 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-55-5295e8374aa6 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F2.A5.23787.738E5925; Wed, 27 Nov 2013 13:40:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.229]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Wed, 27 Nov 2013 13:40:23 +0100 From: Salvatore Loreto To: Justin Uberti Thread-Topic: [MMUSIC] Should we put the SCTP max message size in the SDP? Thread-Index: AQHO59KSo690P/9Zfkuq+OuUX9gypg== Date: Wed, 27 Nov 2013 12:40:22 +0000 Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A340A63@ESESSMB109.ericsson.se> References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> <529463FF.2020107@alvestrand.no> 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.149] Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A340A63ESESSMB109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Vtf8xdQgg5ZHChbH+rrYLLZOFbKY uvwxi0XvxyWMDiweVyZcYfVYsKnUY8mSn0weR+ftZw1gieKySUnNySxLLdK3S+DKmNReUrA5 oOJY0z6WBsbzTl2MHBwSAiYSS9rUuhg5gUwxiQv31rN1MXJxCAkcYpT4sOMxK4SzhFHi8K1f LCBVbAJmEs8fbmEGsUUE1CQeztoFVsQs0MQocfv+D7AiYQFPiSNnv7NAFHlJrJrwEcrWk5g0 5Rg7yGYWAVWJk5stQcK8At4S01+9ZIRYtopd4sOrK2ALOAUCJT59/scKYjMCnff91BomEJtZ QFzi1pP5TBBnC0gs2XOeGcIWlXj5GKJeQkBJYu3h7Swgu5gF8iU2t6hC7BKUODnzCcsERtFZ SCbNQqiahaQKokRHYsHuT2wQtrbEsoWvmWHsMwceM0HY1hJTL71jRFazgJFjFSN7bmJmTnq5 4SZGYCwe3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCY a2uf9CxHcYWri6TRvTcXjNOPdOzI33P91tI9R2dbLufXKZ31xvgly7uD9erbldbe8c1ZpLl8 sXiMkb5w5TNW/5gDeUY17OLX3dv4V/6apBQ7v+JH07+sG7fuzexexpEU2bUr9ux/s1rLfo8v B87Z7iri+KK76lC3s5mL37kJAoZzrgTZTK1SYinOSDTUYi4qTgQAwaHf9JMCAAA= Cc: "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 12:40:29 -0000 --_000_2B9B48179856DC4FA00C93C79EB7E64A340A63ESESSMB109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable my reading of RFC4566 is that a=3Dfmtp is defined only for specifying forma= t parameter for a=3Drtpmap: if we want to use the same a=3Dfmtp for the a=3Dsctpmap it is necessary to = update the draft-ietf-mmusic-sctp-sdp-05 to specify this usage. /Sal On Nov 26, 2013, at 7:02 PM, Justin Uberti > wrote: RFC 4566 doesn't seem to prohibit it, but there could be other precedent th= at I am missing. a=3Dfmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format. It is a media-level attribute, and it is not dependent on charset. On Tue, Nov 26, 2013 at 1:03 AM, Harald Alvestrand > wrote: On 11/26/2013 01:12 AM, Justin Uberti wrote: I agree with Eric's suggestions, including '0' as a special case. Regarding naming, I kind of prefer "max-", as there is ample precedent for = this, e.g. maxptime, maxplaybackrate in http://tools.ietf.org/html/draft-sp= ittka-payload-rtp-opus-03. In fact, for optimal consistency I would argue f= or |maxmsgsize|. Regarding how the parameter is specified, I beg you not to use positional a= rguments, and use fmtp named arguments instead, e.g. a=3Dsctpmap:5000 webrtc-datachannel a=3Dfmtp:5000 maxmsgsize=3D65536 Does a=3Dfmtp bind to arbitrary identifiers? I thought it only bound to pay= load types... On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher > wrote: Your proposal all sounds good to me. I don't feel strongly one way or the = other about "max-" vs. "supported-". On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla > wrote: For concreteness, here's what I suggest. - An SDP attribute which indicates the maximum message size that the endpoint is willing to accept. The other side should assume that any larger message will be rejected, though there is no requirement that it do so (just as there is no requirement to behave in any particular way if an unadvertised RTP PT is received). - If the attribute is not present, the assumption is that there is some sensible (small) default that matches the behavior of existing browsers. 64k? - An attribute value of '0' means I will do my best with whatever you send me, subject to memory capacity, etc. - Proposed name: 'max-message-size' -Ekr On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson > wrote: On 23 November 2013 13:32, Eric Rescorla = > wrote: > 3. The semantics should be that each side just gets to inform the other > side of their value, not that it's negotiated. This is especially important. "negotiation" here makes zero sense. --_000_2B9B48179856DC4FA00C93C79EB7E64A340A63ESESSMB109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <5CFD2A3116A3A64A95EDC92FF4390B61@ericsson.com> Content-Transfer-Encoding: quoted-printable my reading of RFC4566 is that a=3Dfmtp is defined only for specifying forma= t parameter for a=3Drtpmap:

if we want to use the same a=3Dfmtp for the a=3Dsctpmap it is necessar= y to update the draft-ietf-mmusic-sctp-sdp-05
to specify this usage.

/Sal

On Nov 26, 2013, at 7:02 PM, Justin Uberti <juberti@google.com> wrote:

RFC 4566 doesn't seem to prohibit it, but there could be o= ther precedent that I am missing. 

  a=3Dfmtp:<format> <format specific parameters>

         This attribute allows parameters that are specific to a
         particular format to be conveyed in a way that SDP does not
         have to understand them.  The format must be one of the formats
         specified for the media.  Format-specific parameters may be any
         set of parameters required to be conveyed by SDP and given

         unchanged to the media tool that will use this format.  At mo=
st
         one instance of this attribute is allowed for each format.

         It is a media-level attribute, and it is not dependent on
         charset.


On Tue, Nov 26, 2013 at 1:03 AM, Harald Alvestra= nd <harald@alvest= rand.no> wrote:
On 11/26/2013 01:12 AM, Justin Uberti wrote:
I agree with Eric's suggestions, including '0' as a special case.

Regarding naming, I kind of prefer "max-", as there is ample prec= edent for this, e.g. maxptime, maxplaybackrate in http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03. In fact, = for optimal consistency I would argue for |maxmsgsize|.

Regarding how the parameter is specified, I beg you not to use positio= nal arguments, and use fmtp named arguments instead, e.g.
a=3Dsctpmap:5000= webrtc-datachannel
a=3Dfmtp:5= 000 maxmsgsize=3D65536

Does a=3Dfmtp bind to arbitrary identifiers? I thought it only bound to pay= load types...




On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher = <pthatcher@goo= gle.com> wrote:
Your = proposal all sounds good to me.  I don't feel strongly one way or the = other about "max-" vs. "supported-".


On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:
For concreteness, here's what I suggest.

- An SDP attribute which indicates the maximum message size that
  the endpoint is willing to accept. The other side should assume= that
  any larger message will be rejected, though there is no require= ment
  that it do so (just as there is no requirement to behave in any=
  particular way if an unadvertised RTP PT is received).

- If the attribute is not present, the assumption is that there is som= e
  sensible (small) default that matches the behavior of existing<= /div>
  browsers. 64k?

- An attribute value of '0' means I will do my best with whatever you<= /div>
  send me, subject to memory capacity, etc.

- Proposed name: 'max-message-size'

-Ekr



On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com> wrote:
> 3. The semantics should be that each side just gets to inform the othe= r
> side of their value, not that it's negotiated.

This is especially important.  "negotiation" here makes zero= sense.






--_000_2B9B48179856DC4FA00C93C79EB7E64A340A63ESESSMB109ericsso_-- From christer.holmberg@ericsson.com Wed Nov 27 05:13:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377961AD8E3 for ; Wed, 27 Nov 2013 05:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evE9gvnHfBjD for ; Wed, 27 Nov 2013 05:12:58 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DBA141AD943 for ; Wed, 27 Nov 2013 05:12:57 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-9e-5295efd8cb9a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E4.EF.27941.8DFE5925; Wed, 27 Nov 2013 14:12:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 27 Nov 2013 14:12:56 +0100 From: Christer Holmberg To: Salvatore Loreto , Justin Uberti Thread-Topic: [MMUSIC] Should we put the SCTP max message size in the SDP? Thread-Index: AQHO59KSSlyXpZYGlU+7orXwTr/y0poxyn6AgAAG3gCAAARKgIAAARSAgAD/7wCAAAetAIAAaGCAgAAWwgCAASLpAIABkbIAgACF/ICAAJRrgIAAhZgAgAFJMQCAABeY0A== Date: Wed, 27 Nov 2013 13:12:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C55DF11@ESESSMB209.ericsson.se> References: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de> <2B9B48179856DC4FA00C93C79EB7E64A336B5E@ESESSMB109.ericsson.se> <9AD2E7ED-EBB7-4FC7-8A04-56D038FFD937@lurchi.franken.de> <529463FF.2020107@alvestrand.no> <2B9B48179856DC4FA00C93C79EB7E64A340A63@ESESSMB109.ericsson.se> In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A340A63@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre6N91ODDH6fsbI41tfFZrF1qpDF 1OWPWSx6Py5hdGDxuDLhCqvHgk2lHkuW/GTyODpvP2sASxSXTUpqTmZZapG+XQJXxqpNO5kL NkpUHG6xamBsFe5i5OSQEDCROP74OhOELSZx4d56ti5GLg4hgSOMEj//PIByFjNKfLq9hLWL kYODTcBCovufNkiDiECUxO6vEDXMAk2MErfv/2ABSQgLeEr8a3nBDlHkJbFqwkcWkCIRgUmM Ev+3PQcrYhFQleiZPZUVxOYV8JVYcmslC8S2N+wSt7YtYwRJcAr4SEyeOZcZxGYEuu/7qTVg tzILiEvcejIf6m4BiSV7zjND2KISLx//Y4WwFSWuTl8OVa8ncWPqFDYIW1ti2cLXzBCLBSVO znzCMoFRbBaSsbOQtMxC0jILScsCRpZVjBzFqcVJuelGBpsYgdF0cMtvix2Ml//aHGKU5mBR Euf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjxKNWsa31f2/f3LGleZv+DIblu/jz dRuTb14MFbR/wlL3VmfN9Tld1nE788IeMa7pFH3kdfhfVddEw4TbagzyVzxyJn9eefT9s6/P CrbzTow+kVvy5sb+zWtmrPi6bfHxP/pnxFwMBS+zahc98GR9f20fz95iLYVb08+FTpl6u3Tx Lf0NNg2qfUosxRmJhlrMRcWJALMdSrx0AgAA Cc: "mmusic@ietf.org" , "public-webrtc@w3.org" Subject: Re: [MMUSIC] Should we put the SCTP max message size in the SDP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:13:00 -0000 Hi, >my reading of RFC4566 is that a=3Dfmtp is defined only for specifying form= at parameter for=A0a=3Drtpmap:=20 That is my understanding also. Regards, Christer On Nov 26, 2013, at 7:02 PM, Justin Uberti wrote: RFC 4566 doesn't seem to prohibit it, but there could be other precedent th= at I am missing.=20 a=3Dfmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format. It is a media-level attribute, and it is not dependent on charset. On Tue, Nov 26, 2013 at 1:03 AM, Harald Alvestrand w= rote: On 11/26/2013 01:12 AM, Justin Uberti wrote: I agree with Eric's suggestions, including '0' as a special case. Regarding naming, I kind of prefer "max-", as there is ample precedent for = this, e.g. maxptime, maxplaybackrate in http://tools.ietf.org/html/draft-sp= ittka-payload-rtp-opus-03. In fact, for optimal consistency I would argue f= or |maxmsgsize|.=20 Regarding how the parameter is specified, I beg you not to use positional a= rguments, and use fmtp named arguments instead, e.g. a=3Dsctpmap:5000 webrtc-datachannel a=3Dfmtp:5000 maxmsgsize=3D65536 Does a=3Dfmtp bind to arbitrary identifiers? I thought it only bound to pay= load types...=20 On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher wrot= e: Your proposal all sounds good to me. =A0I don't feel strongly one way or th= e other about "max-" vs. "supported-". On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla wrote: For concreteness, here's what I suggest.=20 - An SDP attribute which indicates the maximum message size that =A0 the endpoint is willing to accept. The other side should assume that =A0 any larger message will be rejected, though there is no requirement =A0 that it do so (just as there is no requirement to behave in any =A0 particular way if an unadvertised RTP PT is received). - If the attribute is not present, the assumption is that there is some =A0 sensible (small) default that matches the behavior of existing =A0 browsers. 64k? - An attribute value of '0' means I will do my best with whatever you =A0 send me, subject to memory capacity, etc. - Proposed name: 'max-message-size' -Ekr On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson = wrote: On 23 November 2013 13:32, Eric Rescorla wrote: > 3. The semantics should be that each side just gets to inform the other > side of their value, not that it's negotiated. This is especially important. =A0"negotiation" here makes zero sense. From bernard_aboba@hotmail.com Thu Nov 28 12:03:15 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34B11ADFCF for ; Thu, 28 Nov 2013 12:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roxzgFVupQ0y for ; Thu, 28 Nov 2013 12:03:13 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD41ADD02 for ; Thu, 28 Nov 2013 12:03:13 -0800 (PST) Received: from BLU169-W114 ([65.55.111.71]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Nov 2013 12:03:12 -0800 X-TMN: [6zf13GrxrjYNJm7WUkXeYVjitEfjOeXS] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_321ae4fb-b47f-4a64-b95b-10a447b40c17_" From: Bernard Aboba To: "mmusic@ietf.org" Date: Thu, 28 Nov 2013 12:03:12 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 28 Nov 2013 20:03:12.0772 (UTC) FILETIME=[DE260C40:01CEEC74] Subject: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 20:03:15 -0000 --_321ae4fb-b47f-4a64-b95b-10a447b40c17_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 88=2C a number of participants (including myself) expressed the vi= ew that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below= =2C I will attempt to explain how simulcast might be negotiated in a simpli= fied Offer/Answer exchange based on the principles of Unified Plan.=20 =20 Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU)=2C while receiving one among a = set of potential streams from the SFU=2C with the SFU being able to switch = between the streams that it is sending to the endpoint without signaling. = RFC 3264 describes how to handle each of these situations.=20 =20 With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=20 =20 If the offerer wishes to only send media on a stream to its peer=2C it MUST= mark the stream as sendonly with the "a=3Dsendonly" attribute. We refer = to a stream as being marked with a certain direction if a direction attribu= te was present as either a media stream attribute or a session attribute. F= or sendonly RTP streams=2C the payload type numbers indicate the value of t= he payload type field in RTP packet the offerer is planning to send for tha= t codec... In all cases=2C the formats in the "m=3D" line MUST be listed i= n order of preference=2C with the first format listed being preferred. In = this case=2C preferred means that the recipient of the offer SHOULD use the= format with the highest preference that is acceptable to it. If multiple m= edia streams of different types are present=2C it means that the offerer wi= shes to use those streams at the same time. A typical case is an audio and= a video stream as part of a videoconference. =20 If multiple media streams of the same type are present in an offer=2C it m= eans that the offerer wishes to send (and/or receive) multiple streams of t= hat type at the same time... Each stream MAY use different encodings.=20 =20 With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=20 =20 If the offerer wishes to only receive media from its peer=2C it MUST mark = the stream as recvonly... If multiple formats are listed=2C it means that t= he offerer is capable of making use of any of those formats during the sess= ion. In other words=2C the answerer MAY change formats in the middle of th= e session=2C making use of any of the formats listed=2C without sending a n= ew offer. For a sendonly stream=2C the offer SHOULD indicate those formats= the offerer is willing to send for this stream. For a recvonly stream=2C = the offer SHOULD indicate those formats the offerer is willing to receive = for this stream.... =20 For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to receive = for that codec. =20 =20 Based on the above: =20 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . The offer would also include a single m=3Dline (with a=3Drecvonly) descr= ibing the streams that the endpoint is prepared to receive=2C each with the= ir own payload type.=20 =20 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition=2C the answer would include a single m=3Dline (with= a=3Dsendonly) indicating the streams from among those proposed by the endp= oint that the SFU is prepared to send. The SFU can then switch between tho= se streams without having to signal the endpoint.=20 =20 Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send=2C an Answerer can indicate how m= any streams it is prepared to receive (might only be one if simulcast isn't= supported). Similarly=2C an Answerer can select those simulcast streams = it is prepared to send (might only be one if simulcast isn't supported).=20 =20 Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio):=20 =20 v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640=2Cy=3D360]=20 m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320=2Cy=3D180] m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]=20 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320=2Cy=3D180] =20 =20 Example Answer:=20 =20 v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]=20 m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320=2Cy=3D180] m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640=2Cy=3D360]=20 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D320=2Cy=3D180]=20 =20 = --_321ae4fb-b47f-4a64-b95b-10a447b40c17_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 88=2C a number of = =3B participants (including myself) expressed the view that draft-westerlun= d-avtcore-rtp-simulcast was too complicated. =3B =3BBelow=2C I will= attempt to explain how simulcast might be =3Bnegotiated in a simplifie= d Offer/Answer exchange =3Bbased on the principles of Unified Plan.  =3B
Typically in simulcast we have an endpoint sending multiple st= reams =3Bin parallel =3Bto the Selective Forwarding Unit (SFU)=2C w= hile receiving one among a set of potential streams from the SFU=2C with th= e SFU being able to switch between the streams that it is sending to the en= dpoint =3Bwithout signaling. =3B RFC 3264 describes how to handle e= ach of these situations.
 =3B
With respect to sending multiple s= treams in parallel=2C RFC 3264 Section 5.1 states the following:
 = =3B
If the offere= r wishes to only send media on a stream to its peer=2C it =3BMUST mark = the stream as sendonly with the "a=3Dsendonly" attribute. =3B We = =3B refer to a stream as being marked with a certain direction if a =3B= direction attribute was present as either a media stream attribute or a ses= sion attribute. =3BFor sendonly RTP streams=2C the payload type numbers= indicate the value of the payload type field in RTP packet =3Bthe offe= rer is planning to send for that codec... =3B In all cases=2C the forma= ts in the "m=3D" line MUST be listed in order of =3Bpreference=2C with = the first format listed being preferred. =3B In this =3Bcase=2C pre= ferred means that the recipient of the offer SHOULD use the format with the= highest preference that is acceptable to it. If multiple media streams of = different types are present=2C it means that the offerer wishes to use thos= e streams at the same time. =3B A =3Btypical case is an audio and a= video stream as part of a videoconference.
 =3B
If multiple medi= a streams of the same type are present in an offer=2C =3B it means that= the offerer wishes to send (and/or receive) multiple streams of that type = at the same time... =3B Each stream MAY use =3Bdifferent encodings.=
 =3B
With respect to receiving one among a set of = potential streams=2C here is what RFC 3264 Section 5.1 says:
 =3B
If the offerer wi= shes to only receive media from its peer=2C it MUST mark the stream as recv= only... If multiple formats are listed=2C it means that the offerer is capa= ble =3Bof making use of any of those formats during the session. = =3B In other =3Bwords=2C the answerer MAY change formats in the middle = of the session=2C making use of any of the formats listed=2C without sendin= g a new offer. =3B =3BFor a sendonly stream=2C the offer SHOULD ind= icate those formats the =3Bofferer is willing to send for this stream.&= nbsp=3B For a recvonly stream=2C =3B the offer SHOULD indicate those fo= rmats the offerer is willing to receive for this stream....
 =3B&nbs= p=3B
For recvonly RTP streams=2C the payload type numbers indicate the = value of the payload type field in RTP packets the offerer is expecting to&= nbsp=3B receive for that codec. =3B
 =3B
Based = on the above:
 =3B
1. An offer from an endpoint to an SFU would i= nclude an m=3Dline for each potential simulcast stream to be sent=2C each i= ncluding an a=3Dsendonly line. =3B The offer would also include a singl= e m=3Dline (with a=3Drecvonly) describing the streams that the endpoint is = prepared to receive=2C each with their own payload type.
 =3B
2.= An answer from an SFU to an endpoint would accept or reject each of the si= mulcast streams that the endpoint is proposing to send (with an a=3Drecvonl= y line). =3B In addition=2C the answer would include a single m=3Dline = (with a=3Dsendonly) indicating the streams from among those proposed by the= endpoint that the SFU is prepared to send. =3B The SFU can then switch= between those streams without having to signal the endpoint.
 =3B<= BR>Since it is possible for the =3BAnswerer to accept/reject each of th= e proposed streams the Offerer is proposing to send=2C an =3BAnswerer c= an indicate how many streams it is prepared to receive (might only be one i= f simulcast isn't supported). =3B =3B Similarly=2C an Answerer can = select those simulcast streams it is prepared to send (might only be one if= simulcast isn't supported).
 =3B
Example Offer (leaving out BUN= DLE=2C rtp/rtcp multiplexing=2C and audio):
 =3B
 =3B = =3B v=3D0
 =3B =3B o=3Dalice 2362969037 2362969040 IN IP4 192.0.= 2.156
 =3B =3B s=3DSimulcast Enabled Unified Plan Client
&nbs= p=3B =3B t=3D0 0
 =3B =3B c=3DIN IP4 192.0.2.156
 =3B=  =3B b=3DAS:665
 =3B =3B m=3Dvideo 49300 RTP/AVP 97
 = =3B =3B a=3Dsendonly
 =3B =3B b=3DAS:520
 =3B =3B= a=3Drtpmap:97 H264/90000
 =3B =3B a=3Dfmtp:97 profile-level-id= =3D42c01e
 =3B =3B a=3Dimageattr:97 send [x=3D640=2Cy=3D360]  =3B =3B m=3Dvideo 49302 RTP/AVP 98
 =3B =3B a=3Dsendon= ly
 =3B =3B a=3Drtpmap:98 H264/90000
 =3B =3B a=3Dfmt= p:98 profile-level-id=3D42c01e
 =3B =3B a=3Dimageattr:98 send [x= =3D320=2Cy=3D180]
 =3B =3B m=3Dvideo 49304 RTP/AVP 100 99
&nb= sp=3B =3B a=3Drecvonly
 =3B =3B a=3Drtpmap:100 H264/90000 =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
 =3B = =3B a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]
 =3B =3B a=3Drtp= map:99 H264/90000
 =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e=
 =3B =3B a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]
 =3B<= BR> =3B
Example Answer:
 =3B
 =3B =3B v=3D0
&n= bsp=3B =3B o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
 =3B=  =3B s=3DAnswer to Simulcast Enabled Unified Plan Client
 =3B&nb= sp=3B t=3D0 0
 =3B =3B c=3DIN IP4 192.0.2.43
 =3B =3B= b=3DAS:665
 =3B =3B m=3Dvideo 48000 RTP/AVP 97
 =3B = =3B a=3Drecvonly
 =3B =3B b=3DAS:520
 =3B =3B a=3Drtp= map:97 H264/90000
 =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e=
 =3B =3B a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]
 =3B=  =3B m=3Dvideo 48002 RTP/AVP 98
 =3B =3B a=3Drecvonly
&nb= sp=3B =3B a=3Drtpmap:98 H264/90000
 =3B =3B a=3Dfmtp:98 prof= ile-level-id=3D42c01e
 =3B =3B a=3Dimageattr:98 recv [x=3D320=2C= y=3D180]
 =3B =3B m=3Dvideo 48004 RTP/AVP 100 99
 =3B&nbs= p=3B a=3Dsendonly
 =3B =3B a=3Drtpmap:100 H264/90000
 =3B=  =3B a=3Dfmtp:100 profile-level-id=3D42c01e
 =3B =3B a=3Dima= geattr:100 send [x=3D640=2Cy=3D360]
 =3B =3B a=3Drtpmap:99 H264= /90000
 =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
 = =3B =3B a=3Dimageattr:100 send [x=3D320=2Cy=3D180]
 =3B
=
= --_321ae4fb-b47f-4a64-b95b-10a447b40c17_-- From sm@resistor.net Fri Nov 29 00:50:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678411AE140 for ; Fri, 29 Nov 2013 00:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jux0bvMKau94 for ; Fri, 29 Nov 2013 00:50:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFB61A1F48 for ; Fri, 29 Nov 2013 00:50:36 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAT8oBUg013477; Fri, 29 Nov 2013 00:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385715029; bh=G/8j3P+oEoSbO0EgmoUc+GBLMbj57zGvZIqg7Fry7i8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QN0gMWA68rKqCtRjhd5j/1h9tjpiARb7DIsmgnsQpvpYxLoAFc1R/oXL4K92OoBrY ex7AtruSVvwhT/tU4w08QFjSsS+jmNRX7sd18oTdHRSZAV/nfmrD8FhLxl/fTnC7XT /4i7pVDohmkV1x8SqBnzCIK6xi0UUgPCcyFHPVa0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385715029; i=@resistor.net; bh=G/8j3P+oEoSbO0EgmoUc+GBLMbj57zGvZIqg7Fry7i8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uFAhK5XunsQaGoQgatM0n1sSC2ZV3FKcJK8EqJaonwBYvA3pPlLugTV887GwMBr/2 p5I0K/0cqlJVwMDu5CbRL4DmqsWAUIBu0hkP9RF+7Mg43yIwek3NHzNDcgkfYbpKHi TRZ9nW4qMPbaZ1dvp+DhrUmVV5SMhE6Z3V2JEbC0= Message-Id: <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Nov 2013 00:21:59 -0800 To: Parthasarathi R From: SM In-Reply-To: <003301cee952$852cd120$8f867360$@co.in> References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Flemming Andreasen , Ari =?iso-8859-1?Q?Ker=E4nen?= , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Nov 2013 08:50:37 -0000 Hi Partha, At 12:19 24-11-2013, Parthasarathi R wrote: >Thanks for the clarification that the draft solution is fine for you. The >issue/clarification required is w.r.t the type of RFC and the reference to >the original codec (ITU) specification. > >Please note that the original publication of the draft was done as "BCP" >(http://tools.ietf.org/html/draft-muthu-mmusic-offer-answer-g723-g729-00). >It was discussed in length during IETF-84 and the draft was submitted as >"standards track" as per WG decision ( >http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html). >Including Flemming & Ari in this mail thread explicitly. The minutes of the IETF 84 does not show a lengthy discussion. The message about the WG decision from the WG Chairs says "I support this". >Apart from this, we (The authors) consider that RFC 4856 is in the correct >RFC type. If you think that RFC 4856 status is wrong, Let us discuss in the >separate mail thread. I reordered the above paragraph as it is related to the comment I made above. It is mentioned about that the authors believe that RFC 4856 is the correct type. There isn't any explanation about why the authors think so. I do not see any response to my previous comment ( http://www.ietf.org/mail-archive/web/mmusic/current/msg12778.html ). >As far as the reference is considered, this draft aims at offer/answer >mechanism for SDP attributes which are described as part of RFC 4856 and the >corresponding codec ITU specification is supposed to be referenced in RFC >4856 only. I could not understand the logic why this specification has to >mention ITU codec specification. In my opinion, reading the corresponding codec specification is required to understand what the draft proposes. Regards, -sm From partha@parthasarathi.co.in Fri Nov 29 10:16:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A517A1AE2A2 for ; Fri, 29 Nov 2013 10:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vjyTGMfuvIX for ; Fri, 29 Nov 2013 10:16:05 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD51AE29C for ; Fri, 29 Nov 2013 10:16:04 -0800 (PST) Received: from userPC (unknown [122.179.47.2]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id DC4778689A7; Fri, 29 Nov 2013 18:15:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385748963; bh=6rjrhnLkHnmQErbh6PccNE975vEgez7yur04rQBqiFs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=noVW6ibHCDy7Zt/tSH3GMJbEuA3FeclzNQwoJ9qR3GgHwBmYpaxsP0l1S+Y7W1hwI ppFau8wVJJIy5C4TavGFQE7f3n2mjCBIJmAMiR5FuYWC5S3plYt8vTtUdU7eUvIRF8 Lnots15PJere+v2OmIcM3d7bW0aj1Ue2F19xlGLU= From: "Parthasarathi R" To: "'SM'" , "'Stephen Casner'" , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , "'Flemming Andreasen'" References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> In-Reply-To: <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> Date: Fri, 29 Nov 2013 23:45:46 +0530 Message-ID: <016b01ceed2f$0be29e90$23a7dbb0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7lXW/BZ87V0ZmXQ6CrxW1s2CzoOgHzBhuA Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.5298D9E3.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Cc: mmusic@ietf.org Subject: [MMUSIC] RFC 4856 is in the correct RFC category - Errata query? [was RE: Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Nov 2013 18:16:06 -0000 Hi Casner/Ari/Flemming, As part of draft-ietf-mmusic-sdp-g723-g729-04 draft last call comments, the following comments from sm are relevant to RFC 4856 category 1) The fact that RFC 4856 is > published as a Proposed Standard does not mean that it is the correct > status. There are a lot of oddities in the IETF Stream. I prefer > not to ask about those oddities. :-) The authors of draft-ietf-mmusic-sdp-g723-g729-04 (Muthu & Myself) are of the opinion that RFC 4856 is in the correct category as it describes about codec like G.723 and G.729. 2) draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 > Annex B. There aren't any references for them. draft-ietf-mmusic-sdp-g723-g729-04 updates RFC 4856 w.r.t offer/answer(O/A) mechanism of G723 Annex A and G729 Annex B. RFC 4856 does not have reference for G723 Annex A and G729 Annex B. IMO if the codec reference has to be mentioned, it has to be mentioned in RFC 4856 and not required in draft-ietf-mmusic-sdp-g723-g729-04 as it updates only O/A of RFC 4856. Thanks Partha > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, November 20, 2013 12:57 AM > To: Parthasarathi R > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Last Call: 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) > to Proposed Standard > > Hi Partha, > > I forgot to mention that I am not subscribed to the MMUSIC mailing > list. > > At 10:27 19-11-2013, Parthasarathi R wrote: > >I have clarified all your below queries. Could you please let me know > in > >case you still see any specific issue with the draft. > > In my humble opinion RFC 4856 is more about a media type registration > request instead of a technical specification about > interoperability. It is mentioned in Section 1 of that RFC that it > updates the media type registrations. The fact that RFC 4856 is > published as a Proposed Standard does not mean that it is the correct > status. There are a lot of oddities in the IETF Stream. I prefer > not to ask about those oddities. :-) > > draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 > Annex B. There aren't any references for them. The problem with the > draft is that it builds upon RFC 4856 instead of the technical > specification where the protocol is specified. Is G723 Annex A and > G729 Annex B needed to implement what the draft tries to do? In my > opinion, yes. > > The document shepherd write-up has the following question: > > "Why is this the proper type of RFC?" > > The answer provided is: > > "Proposed Standard. The title page notes the document as Standards > Track" > > That does not answer the question. > > Regards, > -sm From partha@parthasarathi.co.in Fri Nov 29 10:34:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ED81ADEB4 for ; Fri, 29 Nov 2013 10:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6tlQFxxVdEF for ; Fri, 29 Nov 2013 10:34:50 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.154]) by ietfa.amsl.com (Postfix) with ESMTP id EBEB01ACCE6 for ; Fri, 29 Nov 2013 10:34:49 -0800 (PST) Received: from userPC (unknown [122.179.47.2]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 54F5C868FC7; Fri, 29 Nov 2013 18:34:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385750088; bh=Cu261Jzr/erVuLcSNuFvBMDMrIMAk41ZTn20fySoIsc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kxlk55bIOYVG3kwYHBYLzOlR81R9y+aUqO+t+91QCNa3dk2FA1wpbZ12YNYLGAWox PZc8EdCRdVLSJJF+3HC0k4PmXjMBtKOgImdVmmDL7W16Ct7ZrE9cZNeJkd7FDSysD8 tWPGn3hAtIBx/mxv3wGQoFUX2jPe1pcup7HxOCUk= From: "Parthasarathi R" To: "'SM'" , "'Flemming Andreasen'" , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> In-Reply-To: <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> Date: Sat, 30 Nov 2013 00:04:34 +0530 Message-ID: <016d01ceed31$aa7a1130$ff6e3390$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7s4BUIxiUP9L78Sw2lVOD9/ZGa+AAT93Gg Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.5298DE48.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Nov 2013 18:34:52 -0000 Sm, The minutes of the IETF 84 does not show a lengthy discussion. = The > message about the WG decision from the WG Chairs says "I support = this". The draft-ietf-mmusic-sdp-g723-g729-04.txt related minutes of IETF84 is given below for your reference: "draft-muthu-mmusic-offer-answer-g723-g729-00.txt - Parthasarathi = Ravindran Hadriel had clarifying questions on the proposed solution. Christer asked why this isn=92t addressed by change to the document that defined this payload (RFC 4856), to include the o/a considerations. IOW = do a bis of that document. Cullen said this should either be an update or a = bis to the original doc =96 it should not be a BCP. Jonathan agreed with doing a bis. Roni said that when discussed in = PAYLOAD WG (with many of same people) they suggested bringing it to MMUSIC and = doing as BCP. Robert said BCP is almost certainly wrong.=20 Chairs noted that nobody disagrees there is an issue. Chairs will = discuss with PAYLOAD WG chairs and ADs about what the proper process should be = for resolving and documenting it." The related link is http://www.ietf.org/proceedings/84/minutes/minutes-84-mmusic. The draft = is submitted as "Standards track" as per WG chairs & AD instructions after = the meeting and the relevant link is http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html.=20 Your other comments are related to RFC 4856 and I have initiated in the = mail thread to discuss those comments separately. Thanks Partha > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Friday, November 29, 2013 1:52 PM > To: Parthasarathi R > Cc: mmusic@ietf.org; Flemming Andreasen; Ari Ker=E4nen > Subject: RE: [MMUSIC] Last Call: 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex = B) > to Proposed Standard >=20 > Hi Partha, > At 12:19 24-11-2013, Parthasarathi R wrote: > >Thanks for the clarification that the draft solution is fine for you. > The > >issue/clarification required is w.r.t the type of RFC and the > reference to > >the original codec (ITU) specification. > > > >Please note that the original publication of the draft was done as > "BCP" > = >(http://tools.ietf.org/html/draft-muthu-mmusic-offer-answer-g723-g729- > 00). > >It was discussed in length during IETF-84 and the draft was submitted > as > >"standards track" as per WG decision ( > >http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html). > >Including Flemming & Ari in this mail thread explicitly. >=20 > The minutes of the IETF 84 does not show a lengthy discussion. The > message about the WG decision from the WG Chairs says "I support = this". >=20 > >Apart from this, we (The authors) consider that RFC 4856 is in the > correct > >RFC type. If you think that RFC 4856 status is wrong, Let us discuss > in the > >separate mail thread. >=20 > I reordered the above paragraph as it is related to the comment I > made above. It is mentioned about that the authors believe that RFC > 4856 is the correct type. There isn't any explanation about why the > authors think so. I do not see any response to my previous comment ( > http://www.ietf.org/mail-archive/web/mmusic/current/msg12778.html ). >=20 > >As far as the reference is considered, this draft aims at = offer/answer > >mechanism for SDP attributes which are described as part of RFC 4856 > and the > >corresponding codec ITU specification is supposed to be referenced in > RFC > >4856 only. I could not understand the logic why this specification = has > to > >mention ITU codec specification. >=20 > In my opinion, reading the corresponding codec specification is > required to understand what the draft proposes. >=20 > Regards, > -sm From christer.holmberg@ericsson.com Sat Nov 30 00:40:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A321AE3BE for ; Sat, 30 Nov 2013 00:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.361 X-Spam-Level: ** X-Spam-Status: No, score=2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaJh2dhoWztY for ; Sat, 30 Nov 2013 00:40:05 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC891AE364 for ; Sat, 30 Nov 2013 00:40:04 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-1f-5299a462c3e8 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E5.52.22496.264A9925; Sat, 30 Nov 2013 09:40:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Sat, 30 Nov 2013 09:40:01 +0100 From: Christer Holmberg To: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Thread-Index: AQHO7HThG+X2tMt6m0yojy1/V4PWfZo9dplH Date: Sat, 30 Nov 2013 08:40:00 +0000 Message-ID: <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_867vuen3mevy8h0fwtss4hta1385800798144emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvrW7SkplBBv03hCz2L7nMbDF1+WMW ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJWx7dJStoKrBRXn9+xlamDcGtvFyMkhIWAi sb/tOxOELSZx4d56ti5GLg4hgROMEptn/2KEcBYzSlz+8Y+li5GDg03AQqL7nzZIg4hAiMSc FXvBmoUFPCRezD/DBBH3lHi5s4UVwjaSaNv9lBHEZhFQlVi09QhYnFfATWJt/w9mEFtIwEri +613bCA2p4C1xO/vD8DqGYEO+n5qDdhMZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sEDU5EovP Q9zAKyAocXLmE5YJjMKzkLTPQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xIIsvYGRf xShZnFpcnJtuZKCXm55bopdalJlcXJyfp1ecuokRGEcHt/w22sF4co/9IUZpDhYlcd7rrDVB QgLpiSWp2ampBalF8UWlOanFhxiZODilGhglnGRNlD8/ua/hsXArY+e0499O1XxQSCzL9Ui6 Fa91Z/s2CacrO3fX+b61n3ZQV7o6wO6WqYPIvyNC2+4qS+2sWrVM6MSBpc+O37S4EtS1ouq2 zH6mR1xK+1s1Z2dr3ThwJOOQjvCH5fGSR7w6Ge9P8D/YsdNEwnGJ8kTv7Nrd4s4Ja3OTgq4o sRRnJBpqMRcVJwIALz+9unECAAA= Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 30 Nov 2013 08:40:07 -0000 --_000_867vuen3mevy8h0fwtss4hta1385800798144emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernard, In your example, how does the answerer know that the offered m- lines are f= or simulcast? As far as O/A is concerned, it could just be a number of comp= letely separate (different content etc) uni-directional streams. Regards, Christer Sent from my Sony Ericsson Xperia arc S Bernard Aboba wrote: At IETF 88, a number of participants (including myself) expressed the view= that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below, I= will attempt to explain how simulcast might be negotiated in a simplified = Offer/Answer exchange based on the principles of Unified Plan. Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU), while receiving one among a se= t of potential streams from the SFU, with the SFU being able to switch betw= een the streams that it is sending to the endpoint without signaling. RFC = 3264 describes how to handle each of these situations. With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following: If the offerer wishes to only send media on a stream to its peer, it MUST m= ark the stream as sendonly with the "a=3Dsendonly" attribute. We refer to= a stream as being marked with a certain direction if a direction attribute= was present as either a media stream attribute or a session attribute. For= sendonly RTP streams, the payload type numbers indicate the value of the p= ayload type field in RTP packet the offerer is planning to send for that co= dec... In all cases, the formats in the "m=3D" line MUST be listed in orde= r of preference, with the first format listed being preferred. In this cas= e, preferred means that the recipient of the offer SHOULD use the format wi= th the highest preference that is acceptable to it. If multiple media strea= ms of different types are present, it means that the offerer wishes to use = those streams at the same time. A typical case is an audio and a video str= eam as part of a videoconference. If multiple media streams of the same type are present in an offer, it mea= ns that the offerer wishes to send (and/or receive) multiple streams of tha= t type at the same time... Each stream MAY use different encodings. With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says: If the offerer wishes to only receive media from its peer, it MUST mark the= stream as recvonly... If multiple formats are listed, it means that the of= ferer 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 sessi= on, 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 SHOU= LD indicate those formats the offerer is willing to receive for this stream= .... For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to receive fo= r that codec. Based on the above: 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line. = The offer would also include a single m=3Dline (with a=3Drecvonly) describ= ing the streams that the endpoint is prepared to receive, each with their o= wn payload type. 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition, the answer would include a single m=3Dline (with a= =3Dsendonly) indicating the streams from among those proposed by the endpoi= nt that the SFU is prepared to send. The SFU can then switch between those= streams without having to signal the endpoint. Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send, an Answerer can indicate how man= y streams it is prepared to receive (might only be one if simulcast isn't s= upported). Similarly, an Answerer can select those simulcast streams it i= s prepared to send (might only be one if simulcast isn't supported). Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640,y=3D360] m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320,y=3D180] m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320,y=3D180] Example Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640,y=3D360] m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320,y=3D180] m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D320,y=3D180] --_000_867vuen3mevy8h0fwtss4hta1385800798144emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Hi Bernard,=0A=
=0A=
In your example, how does the answerer know that the offered m- lines are f=
or simulcast? As far as O/A is concerned, it could just be a number of comp=
letely separate (different content etc) uni-directional streams.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Bernard Aboba <bernard_aboba@hotmail.com> wrote:=0A=
=0A=
At IETF 88, a number of  participants (including myse= lf) expressed the view that draft-westerlund-avtcore-rtp-simulcast was too = complicated.  Below, I will attempt to explain how simulcast migh= t be negotiated in a simplified Offer/Answer exchange based on the principles of Unified Plan.
 
Typically in simulcast we have an endpoint sending multiple streams in= parallel to the Selective Forwarding Unit (SFU), while receiving one = among a set of potential streams from the SFU, with the SFU being able to s= witch between the streams that it is sending to the endpoint without signaling.  RFC 3264 describes how to ha= ndle each of these situations.
 
With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following:
 
If the offerer wishes to= only send media on a stream to its peer, it MUST mark the stream as s= endonly with the "a=3Dsendonly" attribute.  We  refer t= o a stream as being marked with a certain direction if a direction attribute was present as either a media stream attribute or a session attr= ibute. For sendonly RTP streams, the payload type numbers indicate the= value of the payload type field in RTP packet the offerer is planning= to send for that codec...  In all cases, the formats in the "m=3D" line MUST be listed in order of p= reference, with the first format listed being preferred.  In this = ;case, preferred means that the recipient of the offer SHOULD use the forma= t with the highest preference that is acceptable to it. If multiple media streams of different types are present, it means that the o= fferer wishes to use those streams at the same time.  A typical c= ase is an audio and a video stream as part of a videoconference.
 
If multiple media streams of the same type are present in an offer,  i= t means that the offerer wishes to send (and/or receive) multiple streams o= f that type at the same time...  Each stream MAY use different en= codings.
 
With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says:
 
If the offerer wishes to= only receive media from its peer, it MUST mark the stream as recvonly... I= f 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, withou= t sending a new offer.  For a sendonly stream, the offer SHOULD i= ndicate those formats the offerer is willing to send for this stream.  For a recvonly stream,  the offer SHOULD indic= ate those formats the offerer is willing to receive for this stream....
  
For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to  recei= ve for that codec. 
 
Based on the above:
 
1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line.&= nbsp; The offer would also include a single m=3Dline (with a=3Drecvonly) de= scribing the streams that the endpoint is prepared to receive, each with their own payload type.
 
2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line).  In addition, the answer would include a single m=3Dline (w= ith a=3Dsendonly) indicating the streams from among those proposed by the endpoint that the SFU is prepared to send.&nbs= p; The SFU can then switch between those streams without having to signal t= he endpoint.
 
Since it is possible for the Answerer to accept/reject each of the pro= posed streams the Offerer is proposing to send, an Answerer can indica= te how many streams it is prepared to receive (might only be one if simulca= st isn't supported).   Similarly, an Answerer can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).
 
Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio):
 
   v=3D0
   o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
   s=3DSimulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.156
   b=3DAS:665
   m=3Dvideo 49300 RTP/AVP 97
   a=3Dsendonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 send [x=3D640,y=3D360]
   m=3Dvideo 49302 RTP/AVP 98
   a=3Dsendonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 send [x=3D320,y=3D180]
   m=3Dvideo 49304 RTP/AVP 100 99
   a=3Drecvonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 recv [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:99 recv [x=3D320,y=3D180]
 
 
Example Answer:
 
   v=3D0
   o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
   s=3DAnswer to Simulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.43
   b=3DAS:665
   m=3Dvideo 48000 RTP/AVP 97
   a=3Drecvonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 recv [x=3D640,y=3D360]
   m=3Dvideo 48002 RTP/AVP 98
   a=3Drecvonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 recv [x=3D320,y=3D180]
   m=3Dvideo 48004 RTP/AVP 100 99
   a=3Dsendonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D320,y=3D180]
 
--_000_867vuen3mevy8h0fwtss4hta1385800798144emailandroidcom_-- From bernard_aboba@hotmail.com Sat Nov 30 11:30:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB481AE1BF for ; Sat, 30 Nov 2013 11:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKcO8nAT0Rj1 for ; Sat, 30 Nov 2013 11:30:33 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1438E1AE1BC for ; Sat, 30 Nov 2013 11:30:33 -0800 (PST) Received: from BLU169-W119 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Nov 2013 11:30:31 -0800 X-TMN: [zZr/UotrZ0IVGDpGaVgF1C0DmuUttLlJ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_458fb067-642a-4ab4-a551-5d1a1751e310_" From: Bernard Aboba To: Christer Holmberg , "mmusic@ietf.org" Date: Sat, 30 Nov 2013 11:30:31 -0800 Importance: Normal In-Reply-To: <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> References: , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2013 19:30:31.0609 (UTC) FILETIME=[A207D290:01CEEE02] Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 30 Nov 2013 19:30:35 -0000 --_458fb067-642a-4ab4-a551-5d1a1751e310_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer asked:"In your example=2C how does the answerer know that the offe= red m- lines are for simulcast? As far as O/A is concerned=2C it could just= be a number of completely separate (different content etc) uni-directional= streams."[BA] The most obvious way would be grouping. Looking at RFC 5888= /5583=2C it doesn't appear that either FID or DDP grouping would apply to s= imulcast. So perhaps a new group type would be needed. =0A= =0A= Bernard Aboba wrote:=0A= =0A= =0A= =0A= At IETF 88=2C a number of participants (including myself) expressed the vi= ew that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below= =2C I will attempt to explain how simulcast might be negotiated in a simpli= fied Offer/Answer exchange based=0A= on the principles of Unified Plan.=20 =0A= =20 =0A= Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU)=2C while receiving one among a = set of potential streams from the SFU=2C with the SFU being able to switch = between the streams that it is sending=0A= to the endpoint without signaling. RFC 3264 describes how to handle each = of these situations.=0A= =0A= =20 =0A= With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=0A= =0A= =20 =0A= If the offerer wishes to only send media on a stream to its peer=2C it MUST= mark the stream as sendonly with the "a=3Dsendonly" attribute. We refer = to a stream as being marked with a certain direction if a direction=0A= attribute was present as either a media stream attribute or a session attr= ibute. For sendonly RTP streams=2C the payload type numbers indicate the va= lue of the payload type field in RTP packet the offerer is planning to send= for that codec... In all cases=2C=0A= the formats in the "m=3D" line MUST be listed in order of preference=2C wi= th the first format listed being preferred. In this case=2C preferred mean= s that the recipient of the offer SHOULD use the format with the highest pr= eference that is acceptable to it. If=0A= multiple media streams of different types are present=2C it means that the= offerer wishes to use those streams at the same time. A typical case is a= n audio and a video stream as part of a videoconference. =0A= =20 =0A= If multiple media streams of the same type are present in an offer=2C it m= eans that the offerer wishes to send (and/or receive) multiple streams of t= hat type at the same time... Each stream MAY use different encodings.=0A= =0A= =0A= =20 =0A= With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=0A= =0A= =20 =0A= If the offerer wishes to only receive media from its peer=2C it MUST mark t= he stream as recvonly... If multiple formats are listed=2C it means that th= e offerer is capable of making use of any of those formats during=0A= the session. In other words=2C the answerer MAY change formats in the mid= dle of the session=2C making use of any of the formats listed=2C without se= nding a new offer. For a sendonly stream=2C the offer SHOULD indicate thos= e formats the offerer is willing to send=0A= for this stream. For a recvonly stream=2C the offer SHOULD indicate thos= e formats the offerer is willing to receive for this stream.... =0A= =20 =0A= For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to receive = for that codec. =0A= =0A= =0A= =20 =0A= Based on the above: =0A= =20 =0A= 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . The offer would also include a single m=3Dline (with a=3Drecvonly) descr= ibing the streams that the endpoint is prepared=0A= to receive=2C each with their own payload type.=20 =0A= =20 =0A= 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition=2C the answer would include a single m=3Dline (with= a=3Dsendonly) indicating the streams from=0A= among those proposed by the endpoint that the SFU is prepared to send. Th= e SFU can then switch between those streams without having to signal the en= dpoint.=0A= =0A= =20 =0A= Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send=2C an Answerer can indicate how m= any streams it is prepared to receive (might only be one if simulcast isn't= supported). Similarly=2C an Answerer=0A= can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).=0A= =0A= =20 =0A= Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio):=20 =0A= =20 =0A= v=3D0 =0A= o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 =0A= s=3DSimulcast Enabled Unified Plan Client =0A= t=3D0 0 =0A= c=3DIN IP4 192.0.2.156 =0A= b=3DAS:665 =0A= m=3Dvideo 49300 RTP/AVP 97 =0A= a=3Dsendonly =0A= b=3DAS:520 =0A= a=3Drtpmap:97 H264/90000 =0A= a=3Dfmtp:97 profile-level-id=3D42c01e =0A= a=3Dimageattr:97 send [x=3D640=2Cy=3D360]=20 =0A= m=3Dvideo 49302 RTP/AVP 98 =0A= a=3Dsendonly =0A= a=3Drtpmap:98 H264/90000 =0A= a=3Dfmtp:98 profile-level-id=3D42c01e =0A= a=3Dimageattr:98 send [x=3D320=2Cy=3D180] =0A= m=3Dvideo 49304 RTP/AVP 100 99 =0A= a=3Drecvonly =0A= a=3Drtpmap:100 H264/90000 =0A= a=3Dfmtp:100 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]=20 =0A= a=3Drtpmap:99 H264/90000 =0A= a=3Dfmtp:99 profile-level-id=3D42c01e =0A= a=3Dimageattr:99 recv [x=3D320=2Cy=3D180] =0A= =20 =0A= =20 =0A= Example Answer:=20 =0A= =20 =0A= v=3D0 =0A= o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 =0A= s=3DAnswer to Simulcast Enabled Unified Plan Client =0A= t=3D0 0 =0A= c=3DIN IP4 192.0.2.43 =0A= b=3DAS:665 =0A= m=3Dvideo 48000 RTP/AVP 97 =0A= a=3Drecvonly =0A= b=3DAS:520 =0A= a=3Drtpmap:97 H264/90000 =0A= a=3Dfmtp:97 profile-level-id=3D42c01e =0A= a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]=20 =0A= m=3Dvideo 48002 RTP/AVP 98 =0A= a=3Drecvonly =0A= a=3Drtpmap:98 H264/90000 =0A= a=3Dfmtp:98 profile-level-id=3D42c01e =0A= a=3Dimageattr:98 recv [x=3D320=2Cy=3D180] =0A= m=3Dvideo 48004 RTP/AVP 100 99 =0A= a=3Dsendonly =0A= a=3Drtpmap:100 H264/90000 =0A= a=3Dfmtp:100 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 send [x=3D640=2Cy=3D360]=20 =0A= a=3Drtpmap:99 H264/90000 =0A= a=3Dfmtp:99 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 send [x=3D320=2Cy=3D180]=20 =0A= =20 =0A= =0A= = --_458fb067-642a-4ab4-a551-5d1a1751e310_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Christer =
asked:
"In your e=
xample=2C how does the answerer know that the offered m- lines are for simu=
lcast? As far as O/A is concerned=2C it could just be a number of completel=
y separate (different content etc) uni-directional streams."
[BA] The most obvious way would be grouping. Looking at RF= C 5888/5583=2C it doesn't appear that either FID or DDP grouping would appl= y to simulcast. So perhaps a new group type would be needed. 
=0A=
=0A=
Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B wrote:=0A=
=0A=
=0A=
=0A=
At IETF 88=2C a number of =3B participants (including = myself) expressed the view that draft-westerlund-avtcore-rtp-simulcast was = too complicated. =3B =3BBelow=2C I will attempt to explain how simu= lcast might be =3Bnegotiated in a simplified Offer/Answer exchange = =3Bbased=0A= on the principles of Unified Plan.
=0A=  =3B
=0A= Typically in simulcast we have an endpoint sending multiple streams =3B= in parallel =3Bto the Selective Forwarding Unit (SFU)=2C while receivin= g one among a set of potential streams from the SFU=2C with the SFU being a= ble to switch between the streams that it is sending=0A= to the endpoint =3Bwithout signaling. =3B RFC 3264 describes how t= o handle each of these situations.=0A=
=0A=  =3B
=0A= With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=0A=
=0A=  =3B
=0A=
If the offerer wishes to only send media= on a stream to its peer=2C it =3BMUST mark the stream as sendonly with= the "a=3Dsendonly" attribute. =3B We =3B refer to a stream as bein= g marked with a certain direction if a =3Bdirection=0A= attribute was present as either a media stream attribute or a session attr= ibute. =3BFor sendonly RTP streams=2C the payload type numbers indicate= the value of the payload type field in RTP packet =3Bthe offerer is pl= anning to send for that codec... =3B In all cases=2C=0A= the formats in the "m=3D" line MUST be listed in order of =3Bpreferenc= e=2C with the first format listed being preferred. =3B In this =3Bc= ase=2C preferred means that the recipient of the offer SHOULD use the forma= t with the highest preference that is acceptable to it. If=0A= multiple media streams of different types are present=2C it means that the= offerer wishes to use those streams at the same time. =3B A =3Btyp= ical case is an audio and a video stream as part of a videoconference.
= =0A=  =3B
=0A= If multiple media streams of the same type are present in an offer=2C = =3B it means that the offerer wishes to send (and/or receive) multiple stre= ams of that type at the same time... =3B Each stream MAY use =3Bdif= ferent encodings.=0A=
=0A=
=0A=  =3B
=0A= With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=0A=
=0A=  =3B
=0A=
If the offerer wishes to only receive me= dia from its peer=2C it MUST mark the stream as recvonly... If multiple for= mats are listed=2C it means that the offerer is capable =3Bof making us= e of any of those formats during=0A= the session. =3B In other =3Bwords=2C the answerer MAY change form= ats in the middle of the session=2C making use of any of the formats listed= =2C without sending a new offer. =3B =3BFor a sendonly stream=2C th= e offer SHOULD indicate those formats the =3Bofferer is willing to send= =0A= for this stream. =3B For a recvonly stream=2C =3B the offer SHOULD= indicate those formats the offerer is willing to receive for this stream..= ..
=0A=  =3B =3B
=0A= For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to =3B r= eceive for that codec. =3B=0A=
=0A=
=0A=  =3B
=0A= Based on the above:
=0A=  =3B
=0A= 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . =3B The offer would also include a single m=3Dline (with a=3Drecvonly= ) describing the streams that the endpoint is prepared=0A= to receive=2C each with their own payload type.
=0A=  =3B
=0A= 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). =3B In addition=2C the answer would include a single m=3Dlin= e (with a=3Dsendonly) indicating the streams from=0A= among those proposed by the endpoint that the SFU is prepared to send.&nbs= p=3B The SFU can then switch between those streams without having to signal= the endpoint.=0A=
=0A=  =3B
=0A= Since it is possible for the =3BAnswerer to accept/reject each of the p= roposed streams the Offerer is proposing to send=2C an =3BAnswerer can = indicate how many streams it is prepared to receive (might only be one if s= imulcast isn't supported). =3B =3B Similarly=2C an Answerer=0A= can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).=0A=
=0A=  =3B
=0A= Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio): <= br>=0A=  =3B
=0A=  =3B =3B v=3D0
=0A=  =3B =3B o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
=0A=  =3B =3B s=3DSimulcast Enabled Unified Plan Client
=0A=  =3B =3B t=3D0 0
=0A=  =3B =3B c=3DIN IP4 192.0.2.156
=0A=  =3B =3B b=3DAS:665
=0A=  =3B =3B m=3Dvideo 49300 RTP/AVP 97
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B b=3DAS:520
=0A=  =3B =3B a=3Drtpmap:97 H264/90000
=0A=  =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:97 send [x=3D640=2Cy=3D360]
=0A=  =3B =3B m=3Dvideo 49302 RTP/AVP 98
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B a=3Drtpmap:98 H264/90000
=0A=  =3B =3B a=3Dfmtp:98 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:98 send [x=3D320=2Cy=3D180]
=0A=  =3B =3B m=3Dvideo 49304 RTP/AVP 100 99
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B a=3Drtpmap:100 H264/90000
=0A=  =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]
=0A=  =3B =3B a=3Drtpmap:99 H264/90000
=0A=  =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]
=0A=  =3B
=0A=  =3B
=0A= Example Answer:
=0A=  =3B
=0A=  =3B =3B v=3D0
=0A=  =3B =3B o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
=0A=  =3B =3B s=3DAnswer to Simulcast Enabled Unified Plan Client
=0A=  =3B =3B t=3D0 0
=0A=  =3B =3B c=3DIN IP4 192.0.2.43
=0A=  =3B =3B b=3DAS:665
=0A=  =3B =3B m=3Dvideo 48000 RTP/AVP 97
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B b=3DAS:520
=0A=  =3B =3B a=3Drtpmap:97 H264/90000
=0A=  =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]
=0A=  =3B =3B m=3Dvideo 48002 RTP/AVP 98
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B a=3Drtpmap:98 H264/90000
=0A=  =3B =3B a=3Dfmtp:98 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:98 recv [x=3D320=2Cy=3D180]
=0A=  =3B =3B m=3Dvideo 48004 RTP/AVP 100 99
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B a=3Drtpmap:100 H264/90000
=0A=  =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 send [x=3D640=2Cy=3D360]
=0A=  =3B =3B a=3Drtpmap:99 H264/90000
=0A=  =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 send [x=3D320=2Cy=3D180]
=0A=  =3B
=0A=
=0A=
= --_458fb067-642a-4ab4-a551-5d1a1751e310_-- From sm@resistor.net Sat Nov 30 15:19:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91461AE4AE for ; Sat, 30 Nov 2013 15:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqBZ-6JgrhxH for ; Sat, 30 Nov 2013 15:19:17 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2A1AE4AD for ; Sat, 30 Nov 2013 15:19:17 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAUNJ3vE025481; Sat, 30 Nov 2013 15:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1385853551; bh=SXrlpoTPLN4VBS4KqlMPp0j9O+5lbc/Ua4oyNIxfjgk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0gr1M0Tzp8rKTY0N1bYDMDPU5KN0EWbcJEuCAQTldPUrpNdTGLOsq2Ib8ftPmjR90 +zqS+w0Fu/dh9QAv6ori9h4iKlzmajn3XRgCP5skX4fkosnS+Cc5ARl/yZwqTjbqE8 eYHcrQu8YZseWpsqhl3zHTXEZc8bS71N9W676vpI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1385853551; i=@resistor.net; bh=SXrlpoTPLN4VBS4KqlMPp0j9O+5lbc/Ua4oyNIxfjgk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cY0rWe9vZzoXrGY9ZbFBGVaAxURqIXXXtCLgYh16IIphWxo9gbJMAgT8H11pAQlpk lR4mEN5In5W3aPwjg99lWLXABdOL3CErrQ3EwK9uvOK1qCmoeCVN46aT9MuL1/WTaw ix3JfVOM+2W1VeA9VYtWx3Ov/sPHPglPs9vav3uE= Message-Id: <6.2.5.6.2.20131130003721.0d65a980@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 30 Nov 2013 00:54:13 -0800 To: Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: <016d01ceed31$aa7a1130$ff6e3390$@co.in> References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Flemming Andreasen , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 30 Nov 2013 23:19:19 -0000 Hi Ari, I read the PROTO write-up. There isn't any answer to the following= question: "Why is this the proper type of RFC?" At 10:34 29-11-2013, Parthasarathi R wrote: >The draft-ietf-mmusic-sdp-g723-g729-04.txt related minutes of IETF84 is >given below for your reference: > >"draft-muthu-mmusic-offer-answer-g723-g729-00.txt - Parthasarathi Ravindran > >Hadriel had clarifying questions on the proposed solution. > >Christer asked why this isn=92t addressed by change to the document that >defined this payload (RFC 4856), to include the o/a considerations. IOW do= a >bis of that document. Cullen said this should either be an update or a bis >to the original doc =AD it should not be a BCP. > >Jonathan agreed with doing a bis. Roni said that when discussed in PAYLOAD >WG (with many of same people) they suggested bringing it to MMUSIC and= doing >as BCP. Robert said BCP is almost certainly wrong. > >Chairs noted that nobody disagrees there is an issue. Chairs will discuss >with PAYLOAD WG chairs and ADs about what the proper process should be for >resolving and documenting it." > >The related link is >http://www.ietf.org/proceedings/84/minutes/minutes-84-mmusic. The draft is >submitted as "Standards track" as per WG chairs & AD instructions after the >meeting and the relevant link is >http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html. > >Your other comments are related to RFC 4856 and I have initiated in the= mail >thread to discuss those comments separately. According to the message quoted above: (a) Cullen said that the document should either be an update or a bis to the original document. (b) Robert said that BCP was certainly wrong. (c) The draft was submitted as "Standards track" as that was the instructions given by the WG Chairs and Area Director. There isn't any explanation. Media type=20 registrations are usually published as=20 Informational RFCs. I suggest publishing=20 draft-ietf-mmusic-sdp-g723-g729-04 as an Information RFC. Regards, -sm