From nobody Tue Apr 1 09:05:55 2014 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 717E01A099C for ; Tue, 1 Apr 2014 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=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 dsGra787TbbC for ; Tue, 1 Apr 2014 09:05:49 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 028B61A0994 for ; Tue, 1 Apr 2014 09:05:48 -0700 (PDT) Received: from userPC (unknown [122.167.217.42]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 4CF7215C810B; Tue, 1 Apr 2014 16:05:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1396368345; bh=D4FdqtuF5LiaehWdqrOz97J2Y0hwOucf2ZpWBIyNegs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=iOG/bWqBIkd4qgeTcV6M2GnbrQvtDKCmucofLzOUlnRWqikaEuD+XYDv97a5cfHaT 9eZCtTQ8N6KgFso1YmUxbp/T1TQDFPYlaA+4LXDkstHTMf087DUOT5v7R5bs7A1mKd 2Qi7E6qrV2gQxpFPqfUHBzPGLDtEmHT2eiSNHEO0= From: "Parthasarathi R" To: "'Emil Ivov'" , "'Paul Kyzivat'" References: <01e601cf423c$57255890$057009b0$@co.in> <00c901cf4687$0a48dbb0$1eda9310$@co.in> <532F216E.7090400@alum.mit.edu> <532F2D8C.2010104@jitsi.org> <01b701cf4893$afbf0e80$0f3d2b80$@co.in> <010501cf491b$c44b0830$4ce11890$@co.in> <5333254E.1060804@alum.mit.edu> <533358CF.1080107@jitsi.org> In-Reply-To: <533358CF.1080107@jitsi.org> Date: Tue, 1 Apr 2014 21:35:33 +0530 Message-ID: <007f01cf4dc4$3b0955b0$b11c0110$@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: Ac9JRUeb7P7/VBJMQMuXZ/wMdZWQNgEfiW9g Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.533AE3D9.009F, 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 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sbFD8L7zt9oGr6Oe_tXE_rbIV-s Cc: 'mmusic' Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft 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, 01 Apr 2014 16:05:51 -0000 As Paul indicated, "o" line input acts as event for O/A FSM in the remote side to decide whether the given SDP fragment has to be accepted or not. Please note that the similar logic is used in case SIP session timer SDP wherein "o" line will not be incremented from the previous to indicate that there is no change in SDP. The first "ice-ufrag" & "ice-pwd" in SDP shall be used to differentiate but O/A FSM impact is unavoidable. Also, Please note that the multiple "ice-ufrag" & "ice-pwd" is possible in the given SDP because of multiple "m" lines (with different ports). > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: Thursday, March 27, 2014 4:17 AM > To: Paul Kyzivat > Cc: 'mmusic' > Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft > > > > On 26.03.14, 20:06, Paul Kyzivat wrote: > > I think it makes sense to include the o= line. It will still require > > some text to fully explain what it means and how to use it. > > After reading your mail I am not so sure any more. > > > Note that the values of o= are also independent in the two > directions, > > so (like CSeq) can't be used directly to correlate messages in > opposite > > directions. > > > > However the O/A process does correlate pairs of o=, one from each > side. > > > > What we end up with is: > > > > - a session has a series of O/A exchanges. Each O and A contains an > > SDP. And each SDP has has an o= line. > > - From that you can identify a series of SDP pairs. Viewed from one > > side each pair has one local and one remote SDP. > > - the version numbers in the o= lines of the local SDPs form a > > non-decreasing sequence. The same is true for the remote SDPs. > > (But two in a sequence may have the *same* version.) > > > > What we are talking about is for the trickle ICE SDP fragments to > > contain the o= line from the SDP most recently sent in an offer or > > answer by the sender of the fragment. > > > > If you receive a trickle ICE fragment, then you should compare the o= > > line to that of the most recent SDP received in an offer or answer. > If > > those match, and you have no unanswered offer outstanding, then all > is ok. > > > > If they differ and you have no unanswered offer outstanding, then > > something is wrong. (I haven't thought through all the possibilities > here.) > > > > If they differ and you have an unanswered outstanding offer, then it > may > > be that an answer is enroute and this trickle was intended to follow > it. > > > > Note that if you have an unanswered offer outstanding, it is possible > > that the answer will be identical to the prior offer, and that the > > trickle fragment was sent after the answer. I *think* this doesn't > > matter - treating it as if it was sent first will yield the same > result. > > This is really great insight! Thanks Paul! > > It does make me wonder however if o= is the best way to handle things > here though. For example, it hadn't occurred to me that an O/A can > increment the o=values without having an impact on ICE processing. This > would happen if ice-ufrag and ice-pwd remain the same. > > So all this makes me think that ufrag and pwd may still be the easiest > and most straightforward way of matching INFOs to a specific ICE > context. > > Thoughts? > Emil > > > > > Thanks, > > Paul > > > > On 3/26/14 1:49 PM, Parthasarathi R wrote: > >> Hi Emil, > >> > >> Could you please clarify your intention of sending Origin "o" line > or > >> ICE-ufrag & ICE-pwd in this INFO & UPDATE scenario. > >> > >> I have mentioned "o" line by which it will be trivial for everybody > to > >> understand that offer/answer state machine is impacted by these > INFO. > >> > >> Thanks > >> > >> Partha > >> > >> *From:*Emil Ivov [mailto:emcho@jitsi.org] > >> *Sent:* Wednesday, March 26, 2014 11:23 AM > >> *To:* Parthasarathi R > >> *Cc:* Paul Kyzivat; mmusic > >> *Subject:* RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO > draft > >> > >> > >> On 26 Mar 2014 2:35 AM, "Parthasarathi R" > >> > wrote: > >> > > >> > Hi Emil, > >> > > >> > > OK, I see. Then the easiest way to tackle this would be > to > >> mandate > >> > that > >> > > all INFOs contain the ICE ufrag and pwd of the offer/answer > they are > >> > > pertaining to. > >> > > > >> > > Does anyone see a problem with that? > >> > > >> > > >> > I guess that your intention is to pass the corresponding Origin > ("o") > >> line > >> > in each INFO message by which INFO will be identified for the > >> corresponding > >> > SDP by which the ICE candidates are passed. > >> > >> No, that wasn't my intention but sending the origin line would also > work > >> indeed. Thanks for pointing it out! > >> > >> We could actually make that a requirement of the sdpfrag format. > >> > >> --sent from my mobile > >> > >> > I'm saying so as there is no > >> > purpose of passing ICE ufrag & pwd in each INFO message > >> > > >> > Thanks > >> > Partha > >> > > >> > > >> > > -----Original Message----- > >> > > From: mmusic [mailto:mmusic-bounces@ietf.org > >> ] On Behalf Of Emil Ivov > >> > > Sent: Monday, March 24, 2014 12:23 AM > >> > > To: Paul Kyzivat; mmusic@ietf.org > >> > > Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO > draft > >> > > > >> > > > >> > > > >> > > On 23.03.14, 19:01, Paul Kyzivat wrote: > >> > > > One comment > >> > > > > >> > > > On 3/23/14 7:54 AM, Emil Ivov wrote: > >> > > > > >> > > >> This is analogous to an UPDATE that is received before > regular > >> 5245 > >> > > ICE > >> > > >> processing has completed. > >> > > >> > >> > > >> > > a) INVITE from local > >> > > >> > > b) 183 session progress from remote > >> > > >> > > c) PRACK from local > >> > > >> > > d) INFO from local (relay candidates) > >> > > >> > > e) UPDATE from remote > >> > > >> > > > >> > > >> > > Here, the remote has to consider whether INFO belongs > to > >> UPDATE > >> > > or > >> > > >> > > INVITE as > >> > > >> > > it is possible for INFO to reach before 200 OK for > UPDATE as > >> > > well in > >> > > >> > > the > >> > > >> > > same sequence. > >> > > >> > >> > > >> And CSeq headers wouldn't help here because ....? > >> > > > > >> > > > IIUC, the question is whether the remote can tell whether the > INFO > >> > > was > >> > > > sent before or after receiving the UPDATE. > >> > > > > >> > > > CSeq values are independent in each direction. So they are > >> useless to > >> > > > answer this question. Something else will be needed. > >> > > > >> > > OK, I see. Then the easiest way to tackle this would be to > >> mandate that > >> > > all INFOs contain the ICE ufrag and pwd of the offer/answer > they are > >> > > pertaining to. > >> > > > >> > > Does anyone see a problem with that? > >> > > > >> > > Emil > >> > > > >> > > -- > >> > > https://jitsi.org > >> > > > >> > > _______________________________________________ > >> > > mmusic mailing list > >> > > mmusic@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/mmusic > >> > > >> > > > > -- > https://jitsi.org > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Apr 1 10:42:17 2014 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 551521A08A3 for ; Tue, 1 Apr 2014 10:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3NXvKm9r3KED for ; Tue, 1 Apr 2014 10:42:14 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.18]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7C1A098F for ; Tue, 1 Apr 2014 10:42:14 -0700 (PDT) Received: from userPC (unknown [122.167.104.66]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 21E7763913F; Tue, 1 Apr 2014 17:42:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1396374130; bh=yQT2L0bN1hogyYhRa+biF7DEcUK79Eq6UgOeCg+GVkA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Uv0GmsaMqUruBpUVQAZ8LL3s3HWh4wxJTGGQDUKFitNz5I32IfAt3gROzDphUmUWD w/jh94gU7/gdsBwtJzn5qX3mkO3XIQItBFC9dhxxLHUBxTtXGr8laCLbq2NjKlc3iO n/CAViGZJtIM6V/wgd7M/6ZjG07d1dbuSkBBp2B8= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Emil Ivov'" References: <01e601cf423c$57255890$057009b0$@co.in> <00c901cf4687$0a48dbb0$1eda9310$@co.in> <013601cf4923$754b35e0$5fe1a1a0$@co.in>, <53335D95.6000806@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D26BE29@ESESSMB209.ericsson.se>, <53387EE5.3050501@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D26C6D2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26C6D2@ESESSMB209.ericsson.se> Date: Tue, 1 Apr 2014 23:11:57 +0530 Message-ID: <001101cf4dd1$b2c39720$184ac560$@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: AQHPRocL8dnxxOHFaUGVW6LszOxaAJruf3aAgAUpmQCAAElPgIAFdqWNgACWL4CAADN1hIACxQvw Content-Language: en-us X-CTCH-RefID: str=0001.0A020207.533AFA72.00AB, 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 172.18.214.134 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Db5Fpllarj4EiLxKX8ff5EuhgOY Cc: 'mmusic' Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft 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, 01 Apr 2014 17:42:16 -0000 Hi Christer/Emil, > But I agree that an o= line is not the most convenient way to handle > this and using ice-ufrag and ice-pwd would be better. Or, some part of the o= line. Keep in mind that you don't need to put everything in the INFO message body. You can also define parameters associated with the info package. As both of you mentioned, there is a need to indicate Trickle ICE SDP fragment information to O/A FSM. From the offer/answer perspective, "o" line input or equivalent SDP parameter will be act as the event to O/A FSM whether the given SDP Fragment has to be considered as a event for O/A FSM or not. Please note that I'm not concerned about the syntax of "o" line but I'm concerned about the methods used for exchange these SDP fragment. From the current Trickle ICE proposal, INFO method with SDP fragment has to considered as an event for O/A FSM input. This impacts the existing O/A implementation based on SIP methods namely INVITE, RE-INVITE, UPDATE. Based on the current discussion, I could not understand why Trickle ICE SDP fragment *MUST* be sent using INFO (package) only and why *MUST NOT* using UPDATE as Trickle ICE SDP fragment is method independent message body. Thanks Partha > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, March 31, 2014 3:31 AM > To: Emil Ivov; Parthasarathi R > Cc: 'mmusic'; 'Enrico Marocco (TiLab)' > Subject: RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft > > Hi, > > >> I have tried to understand the whole issue discussed here, with > little success :) > >> > >> So, rather than trying to come up with a solution, I think we first > need to agree on some basic assumptions. > >> > >> If we claim that Trickle ICE has no impact on the SDP O/A state, > then: > >> > >> 1) There should be no need to figure out whether an INFO is sent > before an UPDATE; and > > > > That's not exactly true because, like ICE, trickle ICE does depend on > > O/A in order to operate. In other words: if you change your location > and > > do a new Offer/Answer, you don't expect vanilla ICE to magically > > continue, blissfully ignorant of that fact. It needs to restart and > so > > does Trickle ICE. > > Ok, I hear what you are syaing. You need a way to indicate whether the > trickled candidates are pre-restart or not. > > >> 2) There should be no need to include the o= line, or any other > information that binds the INFO to a specific SDP O/A state. > > > > The main reason you need that is so that you can drop stray INFOs > that > > have been delayed and have arrived when the ICE processing context > they > > were related to is no longer valid (i.e. after an ICE restart). > > > > But I agree that an o= line is not the most convenient way to handle > > this and using ice-ufrag and ice-pwd would be better. > > Or, some part of the o= line. > > Keep in mind that you don't need to put everything in the INFO message > body. You can also define parameters associated with the info package. > > >>> Instead, Trickle ICE is only a mechanism to transport candidate > information from one endpoint to another. > >> > >> Agreed. > >> > >> Endpoints may of course add those candidates to subsequent > Offer/Answers. > > > >This should be clarified. I think it's not necessary. Basically an O/A > >can have the following two possible relations to trickle ICE: > > > >1. ICE restart: (ice-ufrag and ice-pwd have changed). This basically > >means that your addressing situation has most likely changed and you > >need to start everything from scratch. So you do. > > > >2. Non-ICE session modification: you are currently doing ICE and while > >you are at it, you change some aspect of your session that has > >no-relation to addressing. For example, you add formats, change the > >direction of a stream, or something like that. In this case trickle > ICE > >continues with no modification. > > > >Case 1 obviously doesn't need any of the trickle candidates but they > can > >be included if the agent is comfortable reusing them. This is > compatible > >with 5245 which says something like this: > > > > If ICE is restarting [...] the set of candidates MAY include some, > > none, or all of the previous candidates for that stream and MAY > > include a totally new set of candidates > > > >Case 2 is less obvious to me. Requiring agents to include all > currently > >known addresses sounds a bit risky to me because it's easy to get into > >situations where an agent receives a set of candidates that does not > >match its current view of the session: > > > >Case 2.1: New candidates appear > >Case 2.2: Some candidates are not there. > > > >Case 2.1 is easy to handle: the new candidates are handled as if they > >were trickled. > > > >Case 2.2 is kind of a headache. 5245 says that it MUST NOT happen but > I > >don't think this can be guaranteed because various race conditions may > >cause trickled candidates to arrive before the O/A and make an agent > >believe that some of them are lacking. > > > >I think the easiest way to handle this would be to say that, when > using > >Trickle ICE, candidates and addressinf information from offers that DO > >NOT restart ICE MUST be ignored. > > Well, you can't ignore the "ice completed" Offer, can you? > > Regards, > > Christer > > > > > ________________________________________ > > From: Emil Ivov [emcho@jitsi.org] > > Sent: Thursday, 27 March 2014 1:07 AM > > To: Parthasarathi R > > Cc: 'mmusic'; Christer Holmberg; 'Enrico Marocco (TiLab)' > > Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft > > > > On 26.03.14, 19:44, Parthasarathi R wrote: > >> > > This race condition is very much possible during > >> > > early > >> > > dialog scenarios with UPDATE. > >> > > > >> > > Could you please explain how SIP trickle ICE using INFO works > for > >> > > > >> > > 1) UPDATE from remote before Trickle ICE is completed > >> > >> This is analogous to an UPDATE that is received before regular 5245 > ICE > >> processing has completed. > >> > >> No, in case UDPATE before the offer is completed, 491 > response > >> will send out whereas it will not happen in case of INFO > > > > I think you might be confusing "before ICE processing has completed" > and > > "before O/A has completed" > > > > An UPDATE that is received while "vanilla ICE processing is in > progress" > > would have exactly the same effect as an UPDATE received while > "trickle > > ICE processing is in progress". If O/A has completed then the UPDATE > > will NOT cause a 491 in either case. > > > >> > > a) INVITE from local > >> > > b) 183 session progress from remote > >> > > c) PRACK from local > >> > > d) INFO from local (relay candidates) > >> > > e) UPDATE from remote > >> > > > >> > > Here, the remote has to consider whether INFO belongs to > UPDATE or > >> > > INVITE as > >> > > it is possible for INFO to reach before 200 OK for UPDATE as > well in > >> > > the > >> > > same sequence. > >> > >> And CSeq headers wouldn't help here because ....? > >> > >> > > Also, RFC 2976 > >> > >> which FWIW is obsoleted by RFC6086 > >> > >> Thanks..I still majorly interwork with RFC 2976 > implementation > >> :-( but please note that RFC 6086 does not change much in these SIP > >> dialog or session aspects. The exact snippet of RFC 6086 is as > follows: > >> > >> "Note that the INFO method is not used to update characteristics of > a > >> SIP dialog or session, but to allow the applications that use > the SIP > >> session to exchange information (which might update the state > of > >> those applications)." > > > > Trickle ICE does not update the characteristics of a SIP dialog and I > > don't believe it violates the above in any way. > > > >> > > " - The extensions that use the INFO message MUST NOT rely on > the > >> > > INFO message to do anything that effects the SIP call > state or the > >> > > state of related sessions." > >> > >> And I don't believe that it does. > >> > >> No, it is not possible to implement this draft without > impact > >> offer/answer state machine > > > > Please provide an example where you think it actually breaks > something. > > (It might be worth waiting until we submit the new version, which > should > > probably clarify a few things). > > > >> > > 2) Trickle ICE INFO with serial forking > >> > >> INFO requests are sent within a dialog. They will go through the > prong > >> associated with that dialog and would not be forked. > >> > >> IOW, Trickle ICE INFO will be buffered till 18x response is > >> received. So, INFO has no much advantage compare to UPDATE except > for > >> the non-reliable response scenario. > > > > No advantage? INFOs can be send in both directions and arrive > completely > > asynchronously without ever causing glare or without having to worry > > whose turn it is to send an offer or an answer because you need to > > piggyback candidates on top of it. > > > > We've been through this exact same argument several times already, > you > > haven't pointed out any flaws with this logic so I can't see a reason > > why you keep coming back to it. > > > > You claim you are worried about needing to modify the offer/answer > state > > machine in your implementation, but that is a very strange argument > > since that implementation would be much more heavily impacted if you > > were to try and trickle with offers and answers. > > > > I think the source of the confusion might be the fact that the draft > is > > currently in a relatively poor state, which is my fault, and I am > > hopeful that you may find many of your answers in the next version. > > > > Emil= From nobody Tue Apr 1 11:30:26 2014 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 87BE41A088C for ; Tue, 1 Apr 2014 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 VN9DcsVyMGXE for ; Tue, 1 Apr 2014 11:30:22 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 15B441A0505 for ; Tue, 1 Apr 2014 11:30:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3619420A6D for ; Tue, 1 Apr 2014 14:30:18 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 01 Apr 2014 14:30:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=CkrBp2e2/AqD9iqjIjMkwfo6CS0=; b=ydxD9lWADbrwgTSoDsHfHvpu1jVE F+Dz7xzgHxZ/1AFJgSdA8sbT1w+DCDWIdN2S8tDjB6mvkeX94kFMylqC/wje6/Ei IH1WuNYcvvjS3LJBfSvxq2wnFO+ukUSH3xbiHb++/G/Xm4/K5tDmpCKCrI3A7xGE swsc49VfQcnOVsw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=CkrBp2e2/AqD9iqjIjMkwf o6CS0=; b=Qem4YX/gw2U1UzSO9kWYJSUFsY2OzR8RGiwVq5APA5jGQ95ZEXIKQX M/wd6Pf57d7zRzAPXdgRb7zNRVH+J6Ntof2bgHrZ69HVEMVqjzthbgsAgHTTzVe9 /Kk1uUukNBxAhCo47/SN24TZ4atHEQWrvbUW+eBxf78AcdjXb2zlU= X-Sasl-enc: dkF5VdZwy6uV4EgSSUiE7K4A/cGrfzo3m1Pk7V/wOIKQ 1396377017 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id F3897C007AA; Tue, 1 Apr 2014 14:30:16 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Tue, 01 Apr 2014 11:30:13 -0700 From: Alissa Cooper To: Emil Ivov Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fIm_yryoxDwAyaa05ZY8t4qt_4I Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 01 Apr 2014 18:30:24 -0000 Hi Emil, Thanks for responding. Comments inline. On 3/19/14 1:51 AM, "Emil Ivov" wrote: >Hey Alissa, > >Apologies for the delay. My mail filters were somewhat messed up and I >missed on some of the MMUSIC traffic. > >More inline. > >On Fri, Mar 14, 2014 at 8:41 PM, Alissa Cooper wrote: >> I have reviewed this draft in preparation for IETF LC. I have one issue >>that >> I'd like to see the group discuss before issuing the LC: Section 1 says >>"the >> latching mechanism is considered inappropriate for general use on the >> Internet unless all security considerations are taken into account and >> solved." But given the lack of mitigations for attacks originating from >> behind large-scale NATs as described in Section 5, it's not obvious to >>me >> that that condition can realistically be met. > >The draft suggests use of SRTP for authenticating media which does >resolve the security issues (from a privacy/confidentiality >perspective). I was more concerned with the DoS aspect. >That's part of section 5: > > Naturally, SRTP [RFC3711] would help mitigate such threats and should > be used independently of HNT. For example, in cases where end-to-end > encryption is used it would still be possible for an attacker to > hijack a session despite the use of SRTP and perform a denial of > service attack. However, media integrity would not be compromised. > >How does this sound to you? > >Now that I am reading it actually, I am thinking that there's no need >for such a DoS to have permanent consequences. As long as an SRTP >supporting SBC continues to latch to any new source until it >authenticates one, then things should be fine. > >If this sounds reasonable, we will update the text in the next iteration. Could you propose the text change on the list and we can hash it out here? > >Also it is worth reminding that the above threats apply mostly to >generic Internet deployments. Many people using latching today, do so >in controlled environments, where that kind of hijacking could not >occur. This was my point in raising the question about the characterization in section 1. I think something like the following might capture the situation better: OLD: Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet unless all security considerations are taken into account and solved. NEW: Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet, and in controlled environments unless all security considerations are taken into account and solved. > >> There is an in-text reference to "[tcp-splicing]," but there is no such >> reference in the references section. > >Oh right! Do we have a good reference about this at the IETF? >Otherwise we could just go for something like this: > >"TCP Splice for application layer proxy performance" DA Maltz, P >Bhagwat - Journal of High Speed Networks, 1999 - IOS Pressure I think that's fine. I'm not aware of an IETF spec. Alissa > >Emil > >-- >https://jitsi.org From nobody Tue Apr 1 11:42:49 2014 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 115C21A08AC for ; Tue, 1 Apr 2014 11:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 4kFz9jI1AZZj for ; Tue, 1 Apr 2014 11:42:45 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE151A09C0 for ; Tue, 1 Apr 2014 11:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4020; q=dns/txt; s=iport; t=1396377761; x=1397587361; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CM9sDmh8qBWcD0EBcMZXrncvQqeCAo9YYPyFVRmsy/0=; b=mwthm1nVknhY+fNVO06FnShwGukaiEMRAlvPOPCHV5iFxCfBzzcUqCdK ourHlMFyFiZ/VsVPZnw9Evsc04yXXtVs9DqfBIF7uY/6EkRJhDHlgl9QJ /EaeDmGuMYQlWQbjp66hhxtlWfOy6sc4m2kE2nehCt0NjsSlzH/BmmhcM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMoHO1OrRDoG/2dsb2JhbABZgwbEW4EcFnSCJQEBAQMBOj8FCwsYFRlXBhOHcQfRYReOPTMHCoMagRQEiVaPAJI5g1Ad X-IronPort-AV: E=Sophos;i="4.97,774,1389744000"; d="scan'208";a="106298453" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 01 Apr 2014 18:42:41 +0000 Received: from dhcp-10-155-84-38.cisco.com (dhcp-10-155-84-38.cisco.com [10.155.84.38]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s31Igedl011840; Tue, 1 Apr 2014 18:42:40 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Tue, 1 Apr 2014 11:42:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alissa Cooper X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SY-dsKmqyY-0nBTB6ol9o9OmcXY Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 01 Apr 2014 18:42:47 -0000 On Apr 1, 2014, at 11:30 AM, Alissa Cooper wrote: > Hi Emil, >=20 > Thanks for responding. Comments inline. >=20 > On 3/19/14 1:51 AM, "Emil Ivov" wrote: >=20 >> Hey Alissa, >>=20 >> Apologies for the delay. My mail filters were somewhat messed up and = I >> missed on some of the MMUSIC traffic. >>=20 >> More inline. >>=20 >> On Fri, Mar 14, 2014 at 8:41 PM, Alissa Cooper = wrote: >>> I have reviewed this draft in preparation for IETF LC. I have one = issue >>> that >>> I'd like to see the group discuss before issuing the LC: Section 1 = says >>> "the >>> latching mechanism is considered inappropriate for general use on = the >>> Internet unless all security considerations are taken into account = and >>> solved." But given the lack of mitigations for attacks originating = from >>> behind large-scale NATs as described in Section 5, it's not obvious = to >>> me >>> that that condition can realistically be met. That same paragraph goes on to say that ICE [RFC5245] is the = IETF-advised way of doing things, rather than using Latching. >> The draft suggests use of SRTP for authenticating media which does >> resolve the security issues (from a privacy/confidentiality >> perspective).=20 >=20 > I was more concerned with the DoS aspect. The DoS aspect of authenticating incoming SRTP packets to the SBC? >=20 >> That's part of section 5: >>=20 >> Naturally, SRTP [RFC3711] would help mitigate such threats and = should >> be used independently of HNT. For example, in cases where = end-to-end >> encryption is used it would still be possible for an attacker to >> hijack a session despite the use of SRTP and perform a denial of >> service attack. However, media integrity would not be compromised. >>=20 >> How does this sound to you? >>=20 >> Now that I am reading it actually, I am thinking that there's no need >> for such a DoS to have permanent consequences. As long as an SRTP >> supporting SBC continues to latch to any new source until it >> authenticates one, then things should be fine. >>=20 >> If this sounds reasonable, we will update the text in the next = iteration. >=20 > Could you propose the text change on the list and we can hash it out = here? >=20 >>=20 >> Also it is worth reminding that the above threats apply mostly to >> generic Internet deployments. Many people using latching today, do so >> in controlled environments, where that kind of hijacking could not >> occur. >=20 > This was my point in raising the question about the characterization = in > section 1. I think something like the following might capture the > situation better: >=20 > OLD: > Due to the security issues presented in Section 5, the latching = mechanism > is considered inappropriate for general use on the Internet unless all > security considerations are taken into account and solved. >=20 >=20 > NEW: > Due to the security issues presented in Section 5, the latching = mechanism > is considered inappropriate for general use on the Internet, and in > controlled environments unless all security considerations are taken = into > account and solved. "General use on the Internet" and "in controlled environments" are 100% = of all networks, so perhaps simplifying to: NEW: Due to the security issues presented in Section 5, the latching = mechanism is considered appropriate only when all security considerations are = taken into account and solved. -d >>> There is an in-text reference to "[tcp-splicing]," but there is no = such >>> reference in the references section. >>=20 >> Oh right! Do we have a good reference about this at the IETF? >> Otherwise we could just go for something like this: >>=20 >> "TCP Splice for application layer proxy performance" DA Maltz, P >> Bhagwat - Journal of High Speed Networks, 1999 - IOS Pressure >=20 > I think that's fine. I'm not aware of an IETF spec. From nobody Tue Apr 1 16:00:56 2014 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 543221A0A38 for ; Tue, 1 Apr 2014 16:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 szwcvis4P6RG for ; Tue, 1 Apr 2014 16:00:50 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C68EB1A6EE2 for ; Tue, 1 Apr 2014 16:00:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 76C0E7C50FC; Wed, 2 Apr 2014 01:00:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgmxqd2WwbrD; Wed, 2 Apr 2014 01:00:41 +0200 (CEST) Received: from [10.20.1.105] (114.red-80-28-236.adsl.static.ccgg.telefonica.net [80.28.236.114]) by mork.alvestrand.no (Postfix) with ESMTPSA id A1F7F7C50E0; Wed, 2 Apr 2014 01:00:38 +0200 (CEST) Message-ID: <533B4512.1030308@alvestrand.no> Date: Wed, 02 Apr 2014 01:00:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: avtcore@ietf.org, mmusic@ietf.org References: <20140401224948.4662.48077.idtracker@ietfa.amsl.com> In-Reply-To: <20140401224948.4662.48077.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140401224948.4662.48077.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080708070205060801030505" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ElqPrglCpWyxKhRIDFQLmMvmGq0 Subject: [MMUSIC] Fwd: New Version Notification for draft-alvestrand-sdp-header-00.txt 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, 01 Apr 2014 23:00:54 -0000 This is a multi-part message in MIME format. --------------080708070205060801030505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Some of the issues we have been having with the relationship between SDP and RTP may be illuminated by studying the missive below. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-sdp-header-00.txt Date: Tue, 01 Apr 2014 15:49:48 -0700 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-alvestrand-sdp-header-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-alvestrand-sdp-header Revision: 00 Title: The SDP RTCP Extension Document date: 2014-04-01 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-sdp-header-00.txt Status: https://datatracker.ietf.org/doc/draft-alvestrand-sdp-header/ Htmlized: http://tools.ietf.org/html/draft-alvestrand-sdp-header-00 Abstract: This document specifies an RTCP extension that allows SDP information to be carried over an RTP session. This extension obivates the need for a separate negotiation channel, thereby avoiding the risk of desynchronization between the SDP session description and the RTP session state. 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 --------------080708070205060801030505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Some of the issues we have been having with the relationship between SDP and RTP may be illuminated by studying the missive below.

Harald


-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-sdp-header-00.txt
Date: Tue, 01 Apr 2014 15:49:48 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-alvestrand-sdp-header-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name:		draft-alvestrand-sdp-header
Revision:	00
Title:		The SDP RTCP Extension
Document date:	2014-04-01
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-alvestrand-sdp-header-00.txt
Status:         https://datatracker.ietf.org/doc/draft-alvestrand-sdp-header/
Htmlized:       http://tools.ietf.org/html/draft-alvestrand-sdp-header-00


Abstract:
   This document specifies an RTCP extension that allows SDP information
   to be carried over an RTP session.  This extension obivates the need
   for a separate negotiation channel, thereby avoiding the risk of
   desynchronization between the SDP session description and the RTP
   session state.


                                                                                  


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


--------------080708070205060801030505-- From nobody Wed Apr 2 11:22:43 2014 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 80FD81A0326 for ; Wed, 2 Apr 2014 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 KxWkGqRtwVnE for ; Wed, 2 Apr 2014 11:22:37 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8F53C1A0374 for ; Wed, 2 Apr 2014 11:22:36 -0700 (PDT) X-AuditID: c1b4fb28-b7fd58e000007bb5-87-533c556716da Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5F.0F.31669.7655C335; Wed, 2 Apr 2014 20:22:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Wed, 2 Apr 2014 20:22:30 +0200 From: Christer Holmberg To: "mmusic (E-mail)" Thread-Topic: Coming soon Thread-Index: Ac9OoG70iXmRE0oMTRm4sPCe0hNsvA== Date: Wed, 2 Apr 2014 18:22:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D273981@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D273981ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvjW56qE2wwawXlhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsO6n6wFjWIVt5//YWxgPCncxcjJISFgInH7WSMzhC0mceHe erYuRi4OIYGTjBLLL79ggnAWM0p0N/WxdDFycLAJWEh0/9MGaRARUJdo3dzHCmILC4hIPG9c yAQRl5R4f/YolK0ncfn6RXaQVhYBFYm/N9RATF4BX4nFD9NAKhiB1n4/tQasmllAXOLWk/lM EOcISCzZcx7qNFGJl4//sULYShKLbn+Gqs+X+HLrHxuIzSsgKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbI4tbg4N93IUC83PbdEL7UoM7m4OD9P rzh1EyMwLg5u+a2xg7H7mv0hRmkOFiVx3qqZnUFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GJl9dnnuKzp5QO5O7XE/k0WnuS0frbL9PNuypf2hW+s0njs6l+4yGmofCVLcUbih8zT3znYe 178XF7T9zw53XPn2nO43dnuhS1Zeb4vj2N2q8nTnO1X2qWmkPvp44eAMvqq2ZyH6W2+84pdU mTQ/RdGztP7uWgXxTuaZcgmzuA7NKN+/SmdPjRJLcUaioRZzUXEiACnSoXtZAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FiEbwk5BH4GDrCsKExOKjKNIvsA Subject: [MMUSIC] Coming soon 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, 02 Apr 2014 18:22:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D273981ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You have been waiting. Soon you shall not need to wait anymore :) http://youtu.be/B7ZGzPweTCU Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D273981ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You have been waiting. Soon you shall not need to wa= it anymore J

 

http://youtu= .be/B7ZGzPweTCU

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D273981ESESSMB209erics_-- From nobody Wed Apr 2 14:49:07 2014 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 B12F71A03D9 for ; Wed, 2 Apr 2014 14:49:05 -0700 (PDT) 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 8CHI0b-S6f5S for ; Wed, 2 Apr 2014 14:49:01 -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 3AEB01A03EC for ; Wed, 2 Apr 2014 14:49:01 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id l0XR1n0050bG4ec599oxnK; Wed, 02 Apr 2014 21:48:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:f1cd:ca9a:c851:433e]) by omta03.westchester.pa.mail.comcast.net with comcast id l9nv1n0121vrKXX3P9nwQU; Wed, 02 Apr 2014 21:48:57 +0000 Message-ID: <533C8575.8030802@alum.mit.edu> Date: Wed, 02 Apr 2014 17:47:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@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=q20140121; t=1396475337; bh=W4bz8kpbmruAROdEl5ZLLifyvnwLBBsnNvKicgpwOWU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AjwpFidMcXDlCVIfzYESEV7o1etjptUHr5RurK8C/v5b+qlUud873pI+P+kwWJLzp lzK68R0k1/Ys+rGeV8A/0RAs1ucvh69UPCD7EI6Q3CZ3tINTzfDSkooZJp9gIB+Ydv MkMZZBiwjQ24IHBIBhfrUXeWcutf1+ecZD9yxWqNqTOV23zz937mdB7U3nAMSEWpZr DoIJpHZKAtMgdlPB9aWQc/wCbkzPxcOZPbMjYtGuUN0RIrr+ipSZhqTrC8ykmn3heb E78n3f5tl3JxXAghzr2+wT5tkaHXanO4JvF9tldaYVEYRIH8UfdtMrONfzvJlueGX3 QGmAvgHeIPy6Q== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zAf3Sp6cZT88RIWTtJvnhz479A4 Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING 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, 02 Apr 2014 21:49:06 -0000 Just to clarify: INFOs are never forked. An INFO isn't sent until there is an early (or confirmed) dialog. And then each INFO is sent within a particular dialog. If the INVITE is forked, then *separate* INFOs can be sent, each in one of the dialogs. Thanks, Paul On 3/30/14 5:48 AM, Christer Holmberg wrote: > Hi, > >> 2) Trickle ICE INFO with serial forking >> >> a) INVITE from local >> b) INVITE is forked by proxy to first remote destination >> c) 100 trying is reaching local >> d) INFO with Trickle ICE from local >> e) INFO is forward by proxy to first remote destination >> f) INVITE is forked by proxy to second remote destination >> g) Whether INFO has to be forked? >> >> It is not mentioned in the draft whether INFO has to be forked to the >> second remote destination as well. Could you please explain the expect >> behavior for this scenario. > > I am not sure what you mean by the INFO being forked. > > When a new fork is created (i.e. when the offerer receives a 18x response from a new destination), whatever candidates have been trickled on previously created fork(s) of course need to be provided also on the new fork. > > And, when multiple forks exist, whenever a new candidate is to be trickled, an INFO carrying the candidate needs to be sent on each fork. > > I don't see a problem with this, but if it is unclear in the spec then some additional text might be needed. > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Apr 2 14:49:23 2014 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 E93A71A03EC for ; Wed, 2 Apr 2014 14:49:21 -0700 (PDT) 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 j8MewXuZy7gi for ; Wed, 2 Apr 2014 14:49:17 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0FF1A03D9 for ; Wed, 2 Apr 2014 14:49:17 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id l9cc1n0030QuhwU519pDgS; Wed, 02 Apr 2014 21:49:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:8c32:6f0f:1357:9383]) by omta02.westchester.pa.mail.comcast.net with comcast id l9p91n00D3oQGAY3N9p94q; Wed, 02 Apr 2014 21:49:13 +0000 Message-ID: <533C85D5.3060700@alum.mit.edu> Date: Wed, 02 Apr 2014 17:49:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@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=q20140121; t=1396475353; bh=W4bz8kpbmruAROdEl5ZLLifyvnwLBBsnNvKicgpwOWU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B2WCnhAmgMShzlqjx8rjavGlGKIJRXuy82XIsdqEjAB9U8lwCNzQaQNfpv0Dnb7Ep tyarJjCmOKqsv+f5XuhTPLM+a+wLgDcRtIYkA6HndocY3WuLglqzUjzZP5VSbMmeIQ dpvl6NlMZgrwLrmcbqqrkUjQ8ufrudZYTO0eD/mfObF8+5UnGUsy2SDduFtb6kEvTc GYT9PlHz9ZQIek32LSFjR9G8nG5f9tipA9lqCfGeliRMKrdQwW3c3VU+0iB4fj2Gcq 9Mvg07r2oXDxEJQHrO29Nj7noyrfsU+yw0UolVLD4DzOZCf/BgRNn0jxyWvELzBD5I yJ51xsdzky0uA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rZsO6s8S1kJG8cHsqAoxhNri7vA Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING 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, 02 Apr 2014 21:49:22 -0000 Just to clarify: INFOs are never forked. An INFO isn't sent until there is an early (or confirmed) dialog. And then each INFO is sent within a particular dialog. If the INVITE is forked, then *separate* INFOs can be sent, each in one of the dialogs. Thanks, Paul On 3/30/14 5:48 AM, Christer Holmberg wrote: > Hi, > >> 2) Trickle ICE INFO with serial forking >> >> a) INVITE from local >> b) INVITE is forked by proxy to first remote destination >> c) 100 trying is reaching local >> d) INFO with Trickle ICE from local >> e) INFO is forward by proxy to first remote destination >> f) INVITE is forked by proxy to second remote destination >> g) Whether INFO has to be forked? >> >> It is not mentioned in the draft whether INFO has to be forked to the >> second remote destination as well. Could you please explain the expect >> behavior for this scenario. > > I am not sure what you mean by the INFO being forked. > > When a new fork is created (i.e. when the offerer receives a 18x response from a new destination), whatever candidates have been trickled on previously created fork(s) of course need to be provided also on the new fork. > > And, when multiple forks exist, whenever a new candidate is to be trickled, an INFO carrying the candidate needs to be sent on each fork. > > I don't see a problem with this, but if it is unclear in the spec then some additional text might be needed. > > Regards, > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Apr 3 01:03:24 2014 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 BDF601A0117 for ; Thu, 3 Apr 2014 01:03:13 -0700 (PDT) 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 4ijp6ULEc3Ib for ; Thu, 3 Apr 2014 01:03:02 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 611BA1A00B2 for ; Thu, 3 Apr 2014 01:03:01 -0700 (PDT) X-AuditID: c1b4fb38-b7f518e000000889-9b-533d14f9cc7b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 9A.B6.02185.9F41D335; Thu, 3 Apr 2014 09:59:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 3 Apr 2014 09:59:38 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING Thread-Index: AQHPS/02PLTBD8bHIkyTiQF+pdjMC5r+wT+AgADMF+c= Date: Thu, 3 Apr 2014 07:59:37 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@ESESSMB209.ericsson.se>, <533C85D5.3060700@alum.mit.edu> In-Reply-To: <533C85D5.3060700@alum.mit.edu> 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+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje4GUdtggy8npC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjyZXdbAV9AhVHzlxgbWA8xtPFyMkhIWAi cbbrPxuELSZx4d56IJuLQ0jgKKPExQdTWCCcxYwSfy7eZ+xi5OBgE7CQ6P6nDdIgIuAr8ezx bbBmYYEAiZ8b37FDxAMlPn9dzAxhW0lM2viJFcRmEVCR2LfjNCOIzSvgJnHwFURcSCBXonn5 MzCbU0BHovHbVxYQmxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghanQkFuz+ xAZha0ssW/iaGWKXoMTJmU9YJjCKzEIyahaSlllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMOgP bvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAssc/vLhNb 8fRWVZ5+/9y5z9ZeVTo6cbuRpJ8iW6hzn/Xrz9f6H5d2OOfbpew3Y7BaOSda9zOz3L5JXPXH 3PlVXrXM64jJvch4xG3SpWLPpxMWbX/h5s6x3XHKiyes55o4XZinSrQlb2A4/me6SPaC1rk1 m8+xTej7nC0596H2aU2DKT4fNn1VYinOSDTUYi4qTgQABgcTWkgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/i1tbY_1njqPshJuZOELf_Lh2poA Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING 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, 03 Apr 2014 08:03:18 -0000 Hi, That is what I tried to say :) The INFO itself is not forked, but once you have multiple early dialogs you= need to send INFO on all of them. Regards, Christer Sent from my Sony Ericsson Xperia arc S Paul Kyzivat wrote: Just to clarify: INFOs are never forked. An INFO isn't sent until there is an early (or confirmed) dialog. And then each INFO is sent within a particular dialog. If the INVITE is forked, then *separate* INFOs can be sent, each in one of the dialogs. Thanks, Paul On 3/30/14 5:48 AM, Christer Holmberg wrote: > Hi, > >> 2) Trickle ICE INFO with serial forking >> >> a) INVITE from local >> b) INVITE is forked by proxy to first remote destination >> c) 100 trying is reaching local >> d) INFO with Trickle ICE from local >> e) INFO is forward by proxy to first remote destination >> f) INVITE is forked by proxy to second remote destination >> g) Whether INFO has to be forked? >> >> It is not mentioned in the draft whether INFO has to be forked to the >> second remote destination as well. Could you please explain the expect >> behavior for this scenario. > > I am not sure what you mean by the INFO being forked. > > When a new fork is created (i.e. when the offerer receives a 18x response= from a new destination), whatever candidates have been trickled on previou= sly created fork(s) of course need to be provided also on the new fork. > > And, when multiple forks exist, whenever a new candidate is to be trickle= d, an INFO carrying the candidate needs to be sent on each fork. > > I don't see a problem with this, but if it is unclear in the spec then so= me additional text might be needed. > > 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 nobody Thu Apr 3 10:28:40 2014 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 57E0D1A024E for ; Thu, 3 Apr 2014 10:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 kxxlkGnMtNbY for ; Thu, 3 Apr 2014 10:28:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB41A0273 for ; Thu, 3 Apr 2014 10:28:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 27C0D20720 for ; Thu, 3 Apr 2014 13:28:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Apr 2014 13:28:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=wzKXvHaQhflrDDAtnpp0YGPIN7g=; b=w8AjNstIsz5zHwNCflQ/Y40dZH3w yxy160bgqWZBLaKcFv8Ey3XdHmKVWjRyuEvXNVUeSfSv/bzWuegCkylV8lq6/IWr PVqejfepUH65nT65CqbMSdI5Pm76ZJ0O0lTIVIs2e8OMams05Iyy0bzPyEWoPyXy grJqMVd7qRPUINY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=wzKXvHaQhflrDDAtnpp0YG PIN7g=; b=Ry35eMa4j8La1fSFIcnAbn2ch1LSEqKGS6TtGs9I+sg85H54EWIGBU vR/c+TgPrqiHaicE8VrJ28836lEAJpG4QmI6cg42h7by2gXxWXlcXcmyj2CuTKNt Ouj00nDHw9hjYLOWC7iTfStquSYduLaHTIMP+Z4VYeuRTgIoe5EGg= X-Sasl-enc: O0XMAWSSlrI8NsYSpCY9Kb5uKP2YDj65A7NxB2CKgMsF 1396546102 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 8AEC5C007B2; Thu, 3 Apr 2014 13:28:19 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 03 Apr 2014 10:28:16 -0700 From: Alissa Cooper To: Dan Wing Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uOe1rJ5CLOmHMPtSdMZmWxA0Tyo Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 03 Apr 2014 17:28:36 -0000 Hi Dan, On 4/1/14 11:42 AM, "Dan Wing" wrote: > >>> The draft suggests use of SRTP for authenticating media which does >>> resolve the security issues (from a privacy/confidentiality >>> perspective). >> >> I was more concerned with the DoS aspect. > >The DoS aspect of authenticating incoming SRTP packets to the SBC? The DoS aspect that is described in the paragraph Emil quoted below. > > >> >>> That's part of section 5: >>> >>> Naturally, SRTP [RFC3711] would help mitigate such threats and should >>> be used independently of HNT. For example, in cases where end-to-end >>> encryption is used it would still be possible for an attacker to >>> hijack a session despite the use of SRTP and perform a denial of >>> service attack. However, media integrity would not be compromised. >>> >> I think something like the following might capture the >> situation better: >> >> OLD: >> Due to the security issues presented in Section 5, the latching >>mechanism >> is considered inappropriate for general use on the Internet unless all >> security considerations are taken into account and solved. >> >> >> NEW: >> Due to the security issues presented in Section 5, the latching >>mechanism >> is considered inappropriate for general use on the Internet, and in >> controlled environments unless all security considerations are taken >>into >> account and solved. > >"General use on the Internet" and "in controlled environments" are 100% >of all networks, so perhaps simplifying to: > >NEW: > Due to the security issues presented in Section 5, the latching >mechanism > is considered appropriate only when all security considerations are >taken into > account and solved. I think the text in the -04 is preferable to this, as it is more specific. I would be interested in others' thoughts on the text I proposed above. Thanks, Alissa From nobody Thu Apr 3 10:39:56 2014 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 9D17C1A0218 for ; Thu, 3 Apr 2014 10:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CoYuydPtCoRC for ; Thu, 3 Apr 2014 10:39:50 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EBCE11A020E for ; Thu, 3 Apr 2014 10:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2362; q=dns/txt; s=iport; t=1396546786; x=1397756386; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8zomF2HeWkqu5Flsx9K2bWhMPCpAg3cQF5/jyDABZBE=; b=ayUmydzvEjgTWAqbde2nbf+yoP429mEI+z9VJLLFYehf76/s4nLvLYvu kQYFnJy2eilcgp8XFnPVJufW00n0U8PHfeepFatSGq63W10dNiXkC4pfv h2EsGFjj15otiwTB5O6MVUjU5RZYpjc5vSRk3Rd7Km6qN2e0E4X/dabef c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAicPVOrRDoG/2dsb2JhbABYgwbFCYEfFnSCJQEBAQMBOj8FCwsYFRlXBhOHcQfPKBeOPjMHCoMagRQEiVqPAYZRi22DUB0 X-IronPort-AV: E=Sophos;i="4.97,788,1389744000"; d="scan'208";a="109779681" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 03 Apr 2014 17:39:45 +0000 Received: from [10.21.70.110] ([10.21.70.110]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s33HdjJF014559; Thu, 3 Apr 2014 17:39:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Thu, 3 Apr 2014 10:39:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> References: To: Alissa Cooper X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZWVik4QOOAmjTSps3HXx6pyPwMo Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 03 Apr 2014 17:39:55 -0000 On Apr 3, 2014, at 10:28 AM, Alissa Cooper wrote: > Hi Dan, >=20 > On 4/1/14 11:42 AM, "Dan Wing" wrote: >>=20 >>>> The draft suggests use of SRTP for authenticating media which does >>>> resolve the security issues (from a privacy/confidentiality >>>> perspective).=20 >>>=20 >>> I was more concerned with the DoS aspect. >>=20 >> The DoS aspect of authenticating incoming SRTP packets to the SBC? >=20 > The DoS aspect that is described in the paragraph Emil quoted below. >=20 >>=20 >>=20 >>>=20 >>>> That's part of section 5: >>>>=20 >>>> Naturally, SRTP [RFC3711] would help mitigate such threats and = should >>>> be used independently of HNT. For example, in cases where = end-to-end >>>> encryption is used it would still be possible for an attacker to >>>> hijack a session despite the use of SRTP and perform a denial of >>>> service attack. However, media integrity would not be compromised. >>>>=20 Sorry, I read it again and I'm still not clear on the concern. Could = you restate or rephrase. >=20 >>> I think something like the following might capture the >>> situation better: >>>=20 >>> OLD: >>> Due to the security issues presented in Section 5, the latching >>> mechanism >>> is considered inappropriate for general use on the Internet unless = all >>> security considerations are taken into account and solved. >>>=20 >>>=20 >>> NEW: >>> Due to the security issues presented in Section 5, the latching >>> mechanism >>> is considered inappropriate for general use on the Internet, and in >>> controlled environments unless all security considerations are taken >>> into >>> account and solved. >>=20 >> "General use on the Internet" and "in controlled environments" are = 100% >> of all networks, so perhaps simplifying to: >>=20 >> NEW: >> Due to the security issues presented in Section 5, the latching >> mechanism >> is considered appropriate only when all security considerations are >> taken into >> account and solved. >=20 > I think the text in the -04 is preferable to this, as it is more = specific. >=20 > I would be interested in others' thoughts on the text I proposed = above. Could we at least eliminate the double negatives ("inappropriate ... = unless")? -d >=20 > Thanks, > Alissa >=20 >=20 From nobody Thu Apr 3 11:20:01 2014 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 297471A024D for ; Thu, 3 Apr 2014 11:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 TwtfVZXKm--a for ; Thu, 3 Apr 2014 11:19:45 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 63F861A022E for ; Thu, 3 Apr 2014 11:19:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7082420B53 for ; Thu, 3 Apr 2014 14:19:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Apr 2014 14:19:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=I2Q48C5KjLtuw6B6RewvcB6NeUk=; b=A9ji+997cnAq+P4HtXKZ8gPFyxn5 98mr6OgluUBegm0bByNf/BWUM+JIuwNN09Gc0AfdhvbUlaBGusEzJpcl4heOKCk2 y1WuDXoPWIYx0rBoGJAZbqEU+HdlH2sn/wVjps0egUdxKX/8B3uoc7fabVCYSQKo c3A5Mx7FvsBAH3A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=I2Q48C5KjLtuw6B6RewvcB 6NeUk=; b=Cu8aJijeyCnAG5tqJi3YmxFMUIXMzQAYIdmZGL90HM/6T3R8mPOtgs 3GHyxMs5yavzeBXufN5SSQJ26e+YymHI5EdGvZ5X2fd7AyqxZlB6ld6O+6ayq1mS Em21I6e0KvCCKxW1hX6pblgIWWj6GLKFSKmu5WergQB8b51RkkqIA= X-Sasl-enc: RtsEBI+81U8PRkKgACaPdW+7I18uzgONtht5iZmrYxFg 1396549179 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id D3CCCC00005; Thu, 3 Apr 2014 14:19:38 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 03 Apr 2014 11:19:32 -0700 From: Alissa Cooper To: Dan Wing Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 References: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> In-Reply-To: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MxfGapW80rwiRAfLEnNm5s1k__A Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 03 Apr 2014 18:19:51 -0000 On 4/3/14 10:39 AM, "Dan Wing" wrote: > >On Apr 3, 2014, at 10:28 AM, Alissa Cooper wrote: > >> Hi Dan, >> >> On 4/1/14 11:42 AM, "Dan Wing" wrote: >>> >>>>> The draft suggests use of SRTP for authenticating media which does >>>>> resolve the security issues (from a privacy/confidentiality >>>>> perspective). >>>>> >>>> >>>> I was more concerned with the DoS aspect. In response to Emil's note above about the SRTP text resolving the security issues "from a privacy/confidentiality perspective," all I was saying was that my initial question was prompted not because I was concerned about a breach of confidentiality, but about the ability to perform a DoS attack even when SRTP is in use. I think the text in Section 5 that describes this is ok though. >>> >>> The DoS aspect of authenticating incoming SRTP packets to the SBC? >> >> The DoS aspect that is described in the paragraph Emil quoted below. >> >>> >>> >>>> >>>>> That's part of section 5: >>>>> >>>>> Naturally, SRTP [RFC3711] would help mitigate such threats and should >>>>> be used independently of HNT. For example, in cases where end-to-end >>>>> encryption is used it would still be possible for an attacker to >>>>> hijack a session despite the use of SRTP and perform a denial of >>>>> service attack. However, media integrity would not be compromised. >>>>> > >Sorry, I read it again and I'm still not clear on the concern. Could you >restate or rephrase. > > >> >>>> I think something like the following might capture the >>>> situation better: >>>> >>>> OLD: >>>> Due to the security issues presented in Section 5, the latching >>>> mechanism >>>> is considered inappropriate for general use on the Internet unless all >>>> security considerations are taken into account and solved. >>>> >>>> >>>> NEW: >>>> Due to the security issues presented in Section 5, the latching >>>> mechanism >>>> is considered inappropriate for general use on the Internet, and in >>>> controlled environments unless all security considerations are taken >>>> into >>>> account and solved. >>> >>> "General use on the Internet" and "in controlled environments" are 100% >>> of all networks, so perhaps simplifying to: >>> >>> NEW: >>> Due to the security issues presented in Section 5, the latching >>> mechanism >>> is considered appropriate only when all security considerations are >>> taken into >>> account and solved. >> >> I think the text in the -04 is preferable to this, as it is more >>specific. >> >> I would be interested in others' thoughts on the text I proposed above. > >Could we at least eliminate the double negatives ("inappropriate ... >unless")? In principle, yes, but it seems much easier to enumerate the situations where it's inappropriate than where it's appropriate -- I'm finding it difficult to think of better phrasing. Alissa > >-d > > >> >> Thanks, >> Alissa >> >> > From nobody Thu Apr 3 18:43:39 2014 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 DFE611A0391 for ; Thu, 3 Apr 2014 18:43:36 -0700 (PDT) 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 Fy5wywmtGXSZ for ; Thu, 3 Apr 2014 18:43:31 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BC31A0197 for ; Thu, 3 Apr 2014 18:43:31 -0700 (PDT) Received: from ppp118-209-196-251.lns20.mel6.internode.on.net ([118.209.196.251]:54036 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WVtAA-0007xN-2I for mmusic@ietf.org; Fri, 04 Apr 2014 12:43:22 +1100 Message-ID: <533E0E37.1040404@nteczone.com> Date: Fri, 04 Apr 2014 12:43:19 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <786615F3A85DF44AA2A76164A71FE1AC1DAAF2@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC1DAAF2@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8pYn0Dffm3OdM2BIWt-BvopiUDw Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt 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, 04 Apr 2014 01:43:37 -0000 Hello Albrecht, Thanks for submitting the draft. I support the addition of the extra codepoints for scenarios where a gateway performs application agnostic inter working. In general the background to H.248/Megaco usage of SDP is good but I'm not sure if the reasons for the new codepoints are documented sufficiently in the draft. Some specific comments below: Clause 1.4 Scope: I propose to word this slightly differently to indicate the scope is the collection of SDP codepoints for GCPs in order to identify additional ones that REQUIRE registration with IANA. Clause 4: There appears to be some duplication in the headings, i.e. 4 and 4.5. Perhaps also " element" needs to be removed from the title of heading 4 as clause 4.4 covers the element? Clause 4.1 Purpose, Last Para: To me this is the reason for the entire draft. The draft has cataloged how SDP is used by GCPs(H.248/Megaco) however hasn't really gone into much depth on why the additional codepoints are needed. Perhaps a paragraph for each additional codepoint could be added indicating where it is used/needed? Clause 4.4: I think the draft could indicate that H.248 uses the values as defined on the IANA registry and no additional IANA registrations are required. Clause 5.1: I think it would be good to note that this has already been registered with IANA. Clause 7.1: TCP/TLS is already registered. See RFC4572 clause 4. However I'm not sure that in the case of agnostic interworking that the MUST indicated in that clause (/An 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using a fmt identifier to indicate the application being run over TLS./) applies. I've also noticed some other minor editorial issues that i'll forward to you off-line. Regards, Christian On 27/03/2014 8:48 PM, Schwarz, Albrecht (Albrecht) wrote: > fyi, this is a spin off activity from > draft-ietf-mmusic-udptl-dtls > in order to define additional codepoints as required for DTLS security session termination (so called end-to-access edge security mode) and DTLS transparent forwarding (e.g. as part of end-to-end security mode) in middleboxes. > -Albrecht > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Donnerstag, 27. März 2014 10:03 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-schwarz-sdp-for-gw-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SDP codepoints for gateway control > Author : Albrecht Schwarz > Filename : draft-schwarz-sdp-for-gw-01.txt > Pages : 12 > Date : 2014-03-27 > > Abstract: > SDP is used in many signalling protocols at call control level (such > as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and > gateway control level (such as H.248/MEGACO, MGCP). Scope of this RFC > is related to gateway control specific SDP usage. Gateway control > protocols do usually NOT define and introduce any new SDP parameters, > however, gateway control protocols need specific SDP parameter values > in addition to SDP usage at call or bearer control level. Such SDP > codepoints are collected by this RFC with the purpose of registration > with IANA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-schwarz-sdp-for-gw/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-schwarz-sdp-for-gw-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-schwarz-sdp-for-gw-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/ > > _______________________________________________ > 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 > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Apr 3 18:45:48 2014 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 08D031A03CC for ; Thu, 3 Apr 2014 18:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wFw2AvYgopF7 for ; Thu, 3 Apr 2014 18:45:42 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5FE1A0390 for ; Thu, 3 Apr 2014 18:45:42 -0700 (PDT) Received: from userPC (unknown [122.167.110.233]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 760F9868AE1; Fri, 4 Apr 2014 01:45:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1396575938; bh=vsF0OGxFYYNtpp5Z8hWXwWGF6DYY5K3/Nz7AUNjXe4g=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LKTliJ93vXduc2hhfsLaaOqq/3vzCX4kGFFl0oarbk5xUqqYpt4nre3UC/KlwrBa5 nylG2R4Tlu0e0MG7HWDa+/wdHi0HhkviZ2cYgMvv9bbSRYwXp1fwglLTnyL6yU0kdE R2I/bTVirG9mt3Y1ptQsNWNTguT8ED5yQ5Y/1uLk= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Paul Kyzivat'" , References: <7594FB04B1934943A5C02806D1A2204B1D26BE6A@ESESSMB209.ericsson.se>, <533C85D5.3060700@alum.mit.edu> In-Reply-To: Date: Fri, 4 Apr 2014 07:15:22 +0530 Message-ID: <003401cf4fa7$901f0b00$b05d2100$@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: AQHPS/02PLTBD8bHIkyTiQF+pdjMC5r+wT+AgADMF+eAAGnuYA== Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.533E0EC2.0014, 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 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zk68jL1TXNN9M10CTiT1mgWgaZg Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING 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, 04 Apr 2014 01:45:47 -0000 Hi Paul/Christer, We are all in the same page that INFO is not forked and possible to be send only within the dialg after receiving 18x response. I have provided this example to clarify that "INFO" as a method does not any advantage over "UPDATE" in sending SIP Trickle ICE fragments. In IETF-89 meeting, it was mentioned that INFO has advantage over other SIP methods. As I mailed earlier, SIP Trickle ICE fragments has to send in any SIP method within the dialog and particularly should be possible using "UPDATE" as well. We can also discuss whether PRACK shall have SIP trickle ICE fragment or not. Thanks Partha > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Thursday, April 03, 2014 1:30 PM > To: Paul Kyzivat; mmusic@ietf.org > Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - > FORKING > > Hi, > > That is what I tried to say :) > > The INFO itself is not forked, but once you have multiple early dialogs > you need to send INFO on all of them. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Paul Kyzivat wrote: > > > Just to clarify: INFOs are never forked. > > An INFO isn't sent until there is an early (or confirmed) dialog. And > then each INFO is sent within a particular dialog. If the INVITE is > forked, then *separate* INFOs can be sent, each in one of the dialogs. > > Thanks, > Paul > > On 3/30/14 5:48 AM, Christer Holmberg wrote: > > Hi, > > > >> 2) Trickle ICE INFO with serial forking > >> > >> a) INVITE from local > >> b) INVITE is forked by proxy to first remote destination > >> c) 100 trying is reaching local > >> d) INFO with Trickle ICE from local > >> e) INFO is forward by proxy to first remote destination > >> f) INVITE is forked by proxy to second remote destination > >> g) Whether INFO has to be forked? > >> > >> It is not mentioned in the draft whether INFO has to be forked to > the > >> second remote destination as well. Could you please explain the > expect > >> behavior for this scenario. > > > > I am not sure what you mean by the INFO being forked. > > > > When a new fork is created (i.e. when the offerer receives a 18x > response from a new destination), whatever candidates have been > trickled on previously created fork(s) of course need to be provided > also on the new fork. > > > > And, when multiple forks exist, whenever a new candidate is to be > trickled, an INFO carrying the candidate needs to be sent on each fork. > > > > I don't see a problem with this, but if it is unclear in the spec > then some additional text might be needed. > > > > 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 nobody Fri Apr 4 04:42:20 2014 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 31D351A013E for ; Fri, 4 Apr 2014 04:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QXd0a_oiCM9X for ; Fri, 4 Apr 2014 04:42:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 97CD31A0133 for ; Fri, 4 Apr 2014 04:42:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DC6DF7FC39C; Fri, 4 Apr 2014 04:42:08 -0700 (PDT) To: jdrosen@jdrosen.net, rlb@ipv.sx, alissa@cooperw.in, fandreas@cisco.com, ari.keranen@ericsson.com From: RFC Errata System Message-Id: <20140404114208.DC6DF7FC39C@rfc-editor.org> Date: Fri, 4 Apr 2014 04:42:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/qJqeHGKZ6SNTmcopdEx8sbBM8ZI Cc: tsuresh20@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Technical Errata Reported] RFC5245 (3952) 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, 04 Apr 2014 11:42:18 -0000 The following errata report has been submitted for RFC5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3952 -------------------------------------- Type: Technical Reported by: Suresh Tummala Section: 15.1 Original Text ------------- priority = 1*10DIGIT Corrected Text -------------- Notes ----- priority = 1*10DIGIT Here the maximum value it can hold is "9999999999"(ten-nines)(priority is of maximum length 10 DIGIT as per grammar in sec 15.1). The number of bits required to hold the maximum value(ten-nines) is 34. Which requires a "double" value instead of integer of 32 bit. Can i know why the priority is maximum of 10 DIGIT length? If possible we may decrease to 9 DIGIT, so that the value will be fit into integer of 32bit. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5245 (draft-ietf-mmusic-ice-19) -------------------------------------- Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Publication Date : April 2010 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Fri Apr 4 08:37:22 2014 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 629B91A0209 for ; Fri, 4 Apr 2014 08:37:19 -0700 (PDT) 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 1bnNbV3AaUJf for ; Fri, 4 Apr 2014 08:37:14 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 925911A0205 for ; Fri, 4 Apr 2014 08:37:14 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so1525146wiv.0 for ; Fri, 04 Apr 2014 08:37:09 -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=IxNn+myvE90iGtWhmwjTURAtY5YOzKflPcKndxtTl6s=; b=GoA1Kpxc0W8eNIyK/sIlBh5+TgN+rO/eKaGliloEwdrO1gmF2SxmKtCOhobSw5Pyl6 Z/0pGIWf4AiX8ylzm9jx7pZ1k8qpwhoPkXHJbBXE0BIvn1tg8t7is9xj/u1Ru4+ZTm1L Sk6a+Vhe+Qja68Rse/AyK5thtslan+5ya5CsyT6C01NTRhdkmHQQSCtWJj/srZ/FlgvB L1UWXAOZhi2IAYh2NnIFCqmpWCyRWg8Eu/iVAmPdcYKIiKLo1oW1rcx3sbiKOk+PCHrf FfppvHvvxINRoYftEign8SsCMzU5msb0iIKxA+OJ2Mic7vD2JR7aQKrzaZ9SMdPKqZPe sG0A== MIME-Version: 1.0 X-Received: by 10.180.185.197 with SMTP id fe5mr5574150wic.56.1396625829229; Fri, 04 Apr 2014 08:37:09 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Fri, 4 Apr 2014 08:37:09 -0700 (PDT) In-Reply-To: <20140404114208.DC6DF7FC39C@rfc-editor.org> References: <20140404114208.DC6DF7FC39C@rfc-editor.org> Date: Fri, 4 Apr 2014 08:37:09 -0700 Message-ID: From: Martin Thomson To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xzLwQVd57Gt_yliIvfUcDJmcwN4 Cc: Flemming Andreasen , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , tsuresh20@gmail.com Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3952) 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, 04 Apr 2014 15:37:19 -0000 On 4 April 2014 04:42, RFC Errata System wrote: > Can i know why the priority is maximum of 10 DIGIT length? If possible we may decrease to 9 DIGIT, so that the value will be fit into integer of 32bit. I don't think that the ABNF has to be perfectly prescriptive. There is text that covers the actual limit (2^32-1). An exact ABNF would be much harder to understand. Anyone using ABNF and only ABNF to validate syntax is welcome to construct a more precise grammar for their needs. What is described here is perfectly adequate for an RFC. From nobody Fri Apr 4 14:54:31 2014 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 7666F1A0150 for ; Fri, 4 Apr 2014 14:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 wd2D3OFQ7d-8 for ; Fri, 4 Apr 2014 14:54:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 368821A014B for ; Fri, 4 Apr 2014 14:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=310; q=dns/txt; s=iport; t=1396648461; x=1397858061; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WC+Ago6UnliCN/65XfQxtERW1XGyilFY7ifnyTtAllI=; b=Ls38aMHvQibRj3mrPY4LhcZt8rRCX+6nOEXDiwjb7LCByekeWtfk17k5 2mr/hsMhuuy0k5PD8Bbuazcm2fS6BUWeyxbPDrr7msMaPDdZObLTEEMNo BJhE1dI4GKnR4ACpycKUIrAWq3nzQ4cBqWLvM3eTfezYy06w1WgqKzzHA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAF0pP1OtJA2E/2dsb2JhbABZgwY7qzCZLYEsFnSCZEA9FhgDAgECAUsNCAEBBYdwDZ4zsgAXjh2FEwEDmFuSP4NMIQ X-IronPort-AV: E=Sophos;i="4.97,797,1389744000"; d="scan'208";a="315460567" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 04 Apr 2014 21:54:19 +0000 Received: from FANDREAS-M-201A.CISCO.COM (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s34LsI7Q032167 for ; Fri, 4 Apr 2014 21:54:18 GMT Message-ID: <533F2A09.8040808@cisco.com> Date: Fri, 04 Apr 2014 17:54:17 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/p7lgQw72FKM4rKH076iJcONXH6g Subject: [MMUSIC] Draft MMUSIC Meeting Minutes from IETF 89, London 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, 04 Apr 2014 21:54:29 -0000 Greetings We have uploaded the draft meeting minutes for the two MMUSIC sessions at IETF 89 in London at: http://www.ietf.org/proceedings/89/minutes/minutes-89-mmusic Please take a look and let us know if you have any questions or comments. Thanks Ari & Flemming (MMUSIC co-chairs) From nobody Mon Apr 7 00:56:13 2014 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 867C41A0693; Mon, 7 Apr 2014 00:56:11 -0700 (PDT) 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 uDODsXfKtDyJ; Mon, 7 Apr 2014 00:56:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7291A0697; Mon, 7 Apr 2014 00:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407075603.16879.85415.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 00:56:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/T1Rkmtk234Xr-qll2616D8-RLLw Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-06.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, 07 Apr 2014 07:56:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-06.txt Pages : 38 Date : 2014-04-07 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m=" lines). This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264, in order to allow an answerer to in an SDP answer assign a non- zero port value to an "m=" line, even if the offerer in the associated SDP offer had assigned a zero port value to the "m=" line. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-06 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 nobody Mon Apr 7 01:06:32 2014 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 3F6841A069C for ; Mon, 7 Apr 2014 01:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 4GSQ9PlDrYtN for ; Mon, 7 Apr 2014 01:06:26 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 81E771A06AC for ; Mon, 7 Apr 2014 01:06:25 -0700 (PDT) X-AuditID: c1b4fb28-b7fd58e000007bb5-66-53425c7ac9ff Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F4.AF.31669.A7C52435; Mon, 7 Apr 2014 10:06:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 10:06:18 +0200 From: Christer Holmberg To: "mmusic (E-mail)" Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 Thread-Index: Ac9SN5ps/O1lyhCQRcaNUBLfQBoRxg== Date: Mon, 7 Apr 2014 08:06:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2AB260@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2AB260ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvjW51jFOwwbur3Bb/9iZZTF3+mMWB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyti5fQtrwQeZihfbVjA2MM6W7GLk5JAQMJGY vKiDBcIWk7hwbz1bFyMXh5DASUaJXdf2sEM4ixklGtadYe1i5OBgE7CQ6P6nDdIgIqAu0bq5 jxXEZhZwlDh7azsTiC0s4C6x4tZxRpByEQEfiXfHYyHK9STe/XnCBhJmEVCRaDoCtpZXwFdi VeMUdhCbEeiE76fWMEFMFJe49WQ+E8RpAhJL9pxnhrBFJV4+/scKYStKXJ2+HKo+X+Lomfls EDMFJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxShan FhfnphsZ6uWm55bopRZlJhcX5+fpFaduYgRG0MEtvzV2MHZfsz/EKM3BoiTOWzWzM0hIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDo9kJx7mBMQ19vqpSU96UK6TeL7nNlLBKR21ZyL3wAx/+ 1S1h1zw9+bZ8aI/uF6vufE83RVUb03I3v4J39rz7dQ9rOwfItzuufHZisvOne98PCcy5M3V3 8d7bcnUV32xcT+qwXNT1kXS+t2CrhrH8g3sXIkIMi+5btJc+aJJ/fsZQY7NX+OcnSizFGYmG WsxFxYkAqhN2Dm4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Y-Nf0Zs8UczexL83WGbt2mK-qHw Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 07 Apr 2014 08:06:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2AB260ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have submitted a new version (-06) of BUNDLE. As you will see, the document has been re-structured quite a bit. The main = reason for that was to align the SDP offer/answer procedures with the RFC 3= 264 structure (I had to do that for another draft, so I decided to do the s= ame thing also for BUNDLE - rather now than when we reach WGLC). The draft does have a dependency on an RTP header indicator, and the comple= tion of draft-ietf-mmusic-sdp-mux-attributes, but otherwise there are curre= ntly no BUNDLE specific open issues. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2AB260ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have submitted a new version (-06) of BUNDLE.

 

As you will see, the document has been re-structured= quite a bit. The main reason for that was to align the SDP offer/answer pr= ocedures with the RFC 3264 structure (I had to do that for another draft, s= o I decided to do the same thing also for BUNDLE – rather now than when we reach WGLC).

 

The draft does have a dependency on an RTP header in= dicator, and the completion of draft-ietf-mmusic-sdp-mux-attributes, but ot= herwise there are currently no BUNDLE specific open issues.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D2AB260ESESSMB209erics_-- From nobody Mon Apr 7 02:06:17 2014 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 A92061A06A8 for ; Mon, 7 Apr 2014 02:06:16 -0700 (PDT) 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 Gsror-W0AvMu for ; Mon, 7 Apr 2014 02:06:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BAD671A06AD for ; Mon, 7 Apr 2014 02:06:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-dd-53426a7a8792 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0E.2E.04779.A7A62435; Mon, 7 Apr 2014 11:06:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 11:06:01 +0200 From: Christer Holmberg To: "mmusic (E-mail)" Thread-Topic: BUNDLE: Draft title confusion Thread-Index: Ac9SQI8H+zF4cUUbRRuEh881mNyM0g== Date: Mon, 7 Apr 2014 09:06:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2AD883@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2AD883ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW5VllOwwc5TahZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtb+K0wF12Qq5r/7x9zAeESyi5GTQ0LARGLL709sELaYxIV7 64FsLg4hgcOMEs/2r2SHcBYzSnxcvYG1i5GDg03AQqL7nzZIg4iAukTr5j5WEFtYQE1i1r2n bBBxbYltRxYyQ9h6ErdvnWECsVkEVCTmrmpiBxnDK+ArMXUGP0iYEWjv91NrwEqYBcQlbj2Z zwRxj4DEkj3nmSFsUYmXj/+xQtiKElenL4eqz5e4fW47mM0rIChxcuYTlgmMQrOQjJqFpGwW kjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73ccBMjMOgPbvmtu4Px1DmR Q4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcKFwfkDvhQpuhOfO8g5wa e498kOeNvyec1M5aoaXiuLCWe9+2ezWFNybJCsUb/r4xYc751NllO2SjGjVae/Nt61bXX5Ve svdG1OkVum5bp856UckwwW+nz9mnXovPd3NM3PZ3+5LyCYzca4Uu3LLOq2/a4vamUvuI8dbj QmYJf31PvjiZdKFViaU4I9FQi7moOBEAHBjpZ0gCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ddzA6Hc6-PWknqF04vY_X3nM0Jc Subject: [MMUSIC] BUNDLE: Draft title confusion 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, 07 Apr 2014 09:06:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2AD883ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It has been commented that the BUNDLE draft title: "Multiplexing Negotiation Using Session Description Protoco= l (SDP) Port Numbers" ...is a little confusing, especially the "Port Numbers" part. So, unless someone has another proposal, our intention is to re-name it to: "Multiplexing Negotiation Using Session Description Protocol (SDP)" Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2AD883ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It has been commented that the BUNDLE draft title:

 

        &nbs= p;       “Multiplexing Negotiation Usin= g Session Description Protocol (SDP) Port Numbers”

 

…is a little confusing, especially the “= Port Numbers” part.

 

So, unless someone has another proposal, our intenti= on is to re-name it to:

 

“Multiplexing Neg= otiation Using Session Description Protocol (SDP)”

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D2AD883ESESSMB209erics_-- From nobody Mon Apr 7 06:40:25 2014 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 750F81A0426 for ; Mon, 7 Apr 2014 06:40:22 -0700 (PDT) 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 eNyQYRQ8CPHg for ; Mon, 7 Apr 2014 06:40:18 -0700 (PDT) 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 8E1541A0418 for ; Mon, 7 Apr 2014 06:40:10 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id n1au1n0051c6gX8571g4tR; Mon, 07 Apr 2014 13:40:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id n1g41n00R3ZTu2S3j1g4jo; Mon, 07 Apr 2014 13:40:04 +0000 Message-ID: <5342AAB4.3040400@alum.mit.edu> Date: Mon, 07 Apr 2014 09:40:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2AD883@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2AD883@ESESSMB209.ericsson.se> 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=q20140121; t=1396878004; bh=+FYYaEydwEHn35/yd57qG1ygPppr2Gh18KPSmQDBd1Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IMiNh3wDp9OlcXAqAPsPnme/spBxpuUllCyoL5Kb14fhZGF+zctUYCLDXQiv/+fZH h1U7eKCHOPLXNUIi4KFOOLoO1W0tq3XcD57P9OAPiJVIqhaYTVuxtCH5173xLcl7fK Q7cRg4MJubTWFavaznLI1ARf3AiKp5DKRaoNJ9ezYyhKQILHnuVV1GiatOng3sAa1E 793WtIWM6+FVgyzo1RBTUSYoK80LFdJ6CUYani43omKwMnS6TOdH+aBz/VPRqjSvR1 PCrfslYQug0wV8CJIYajOGjNhv0bSYT48uhSI/0BPyAWbl4o1i4YuyT8NehQe08qdS C1KuIAFrwwJSw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4JV03-vAE7NGzn5RDCY2556DKnA Subject: Re: [MMUSIC] BUNDLE: Draft title confusion 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, 07 Apr 2014 13:40:22 -0000 On 4/7/14 5:06 AM, Christer Holmberg wrote: > Hi, > > It has been commented that the BUNDLE draft title: > > “Multiplexing Negotiation Using Session Description > Protocol (SDP) Port Numbers” > > …is a little confusing, especially the “Port Numbers” part. > > So, unless someone has another proposal, our intention is to re-name it to: > > “Multiplexing Negotiation Using Session Description Protocol (SDP)” It isn't about multiplexing *negotiation*. Rather it's about negotiating the multiplexing of media-sections on a single 5-tuple. How about: "Negotiating Media Section Multiplexing in the Session Description Protocol (SDP)"? Thanks, Paul From nobody Mon Apr 7 07:28:37 2014 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 754B31A0782 for ; Mon, 7 Apr 2014 07:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 1G-gG8C6VvCd for ; Mon, 7 Apr 2014 07:28:28 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDF01A076E for ; Mon, 7 Apr 2014 07:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 60B7E7C50F5 for ; Mon, 7 Apr 2014 16:28:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqFmsiy2GgTt for ; Mon, 7 Apr 2014 16:28:21 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id A3AE07C50F4 for ; Mon, 7 Apr 2014 16:28:21 +0200 (CEST) Message-ID: <5342B605.6090007@alvestrand.no> Date: Mon, 07 Apr 2014 16:28:21 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2AD883@ESESSMB209.ericsson.se> <5342AAB4.3040400@alum.mit.edu> In-Reply-To: <5342AAB4.3040400@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3sUZiFjJj6lOdEq9hBfa7SUnl1k Subject: Re: [MMUSIC] BUNDLE: Draft title confusion 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, 07 Apr 2014 14:28:34 -0000 On 04/07/2014 03:40 PM, Paul Kyzivat wrote: > On 4/7/14 5:06 AM, Christer Holmberg wrote: >> Hi, >> >> It has been commented that the BUNDLE draft title: >> >> “Multiplexing Negotiation Using Session Description >> Protocol (SDP) Port Numbers” >> >> …is a little confusing, especially the “Port Numbers” part. >> >> So, unless someone has another proposal, our intention is to re-name >> it to: >> >> “Multiplexing Negotiation Using Session Description Protocol (SDP)” > > It isn't about multiplexing *negotiation*. Rather it's about > negotiating the multiplexing of media-sections on a single 5-tuple. The issue here is that either "multiplexing" or "negotiation" can be interpreted as the verb in that sentence. > > How about: > > "Negotiating Media Section Multiplexing in the Session Description > Protocol (SDP)"? We're not multiplexing media sections either, we're multiplexing media that is described by multiple media sections. "Negotiating Media Multiplexing in the Session Description Protocol (SDP)" would work for me - the qualifier "Media" signals that "Multiplexing" is to be treated as a noun, not a verb. Unless someone thinks that we should be multiplexing "negotiating media", whatever that is....) > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Apr 7 07:43:24 2014 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 016C61A0468 for ; Mon, 7 Apr 2014 07:43:23 -0700 (PDT) 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 n0waClTLX9ZI for ; Mon, 7 Apr 2014 07:43:15 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2801A072C for ; Mon, 7 Apr 2014 07:43:14 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id mz3U1n00417dt5G532j9h9; Mon, 07 Apr 2014 14:43:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id n2j91n00E3ZTu2S3Z2j9tD; Mon, 07 Apr 2014 14:43:09 +0000 Message-ID: <5342B97D.7090907@alum.mit.edu> Date: Mon, 07 Apr 2014 10:43:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2AD883@ESESSMB209.ericsson.se> <5342AAB4.3040400@alum.mit.edu> <5342B605.6090007@alvestrand.no> In-Reply-To: <5342B605.6090007@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396881789; bh=W9+BYe0MbmNPQD4kmbVMKCYDJW8INrtnzIstSyTsFcE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eU1uzDtGJEdDhpoOnxSKQelDn9ntXmci3n3qiukFsMZSa21k1JtP6x4oisQ4z9vKB 5F7uQ6XnM0GW4yvbNkJ+iWQrQ0a86sFlj0QFz92nHEjYZj6i4pUXcrsp57SQVCdu7e EmqmAj8BEnAXc06aN9OMAHaFGyK/yDEoV4+m4M/R61leK7ykhKQliC9JBLoB52CqcB tU4HoWuJM3wRLwWHxCZVZFYN5xfgnXv5HXdmUKG2N0l2HVxDQPcPSY68ok2t2ruJ1a E/RDCp68GrZc1U4InyHt6an8JZXjShmS2vhU3XQHKAP9DDQ7YpT5PEDGTu+LNCcoT3 3HDf0fKOFslRQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/t1-D49ARx5xHU_vD5SSRT8zhdHY Subject: Re: [MMUSIC] BUNDLE: Draft title confusion 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, 07 Apr 2014 14:43:23 -0000 On 4/7/14 10:28 AM, Harald Alvestrand wrote: > "Negotiating Media Multiplexing in the Session Description Protocol > (SDP)" would work for me - WFM From nobody Mon Apr 7 08:36:42 2014 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 A8E081A0781 for ; Mon, 7 Apr 2014 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 T1i7S6Aq4XJ2 for ; Mon, 7 Apr 2014 08:36:36 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 827DA1A0455 for ; Mon, 7 Apr 2014 08:36:36 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-3b-5342c5fd2177 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 0A.DD.15972.DF5C2435; Mon, 7 Apr 2014 17:36:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Mon, 7 Apr 2014 17:36:29 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Draft title confusion Thread-Index: Ac9SQI8H+zF4cUUbRRuEh881mNyM0gAFY7oAAAGvsIAAAIRSgAAGDaBc Date: Mon, 7 Apr 2014 15:36:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2AD883@ESESSMB209.ericsson.se> <5342AAB4.3040400@alum.mit.edu> <5342B605.6090007@alvestrand.no>,<5342B97D.7090907@alum.mit.edu> In-Reply-To: <5342B97D.7090907@alum.mit.edu> 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+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvje7fo07BBovu6llMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGyxWP2AqeMVe83P2JsYGxm7mLkZNDQsBE Yv32LjYIW0ziwr31QDYXh5DASUaJz7PPsUA4ixkl9i35yt7FyMHBJmAh0f1PG6RBRMBX4tnj 22DNwgLGEq8/fmaFiJtILDv2mQ3CdpOY++IhK0gri4CKxOeHOSBhXqDw9Yuz2UFsIYFNjBKH V4iA2JwCOhIX5+xiBLEZge75fmoNE4jNLCAucevJfCaIOwUkluw5D3W/qMTLx/9YIWp0JBbs /sQGYWtLLFv4mhlil6DEyZlPWCYwisxCMmoWkpZZSFpmIWlZwMiyilGyOLU4KTfdyFAvNz23 RC+1KDO5uDg/T684dRMjMCoObvltuINx4jX7Q4zSHCxK4rwM0zuDhATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTDGVrz+ZPX6ubXcx0lnr2Zorbh9yGxJULd4ySndNVZeBUnGk7hqTnYYl+Ve jOSY6bbgdniBW2JDCN+RrZef5qmJPl26+bK8dbZyv6Dvvw+yBcfbs/cJpIl8f8z1ce+mGuWK ndP0e1fvPzv53KHLn09buZrwfMme1seyXEWs+8pL7puvy5/s/LlHiaU4I9FQi7moOBEAdAyB 11gCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4Hm9FsIZaJ06mCgVXHSWuMKc5IM Subject: Re: [MMUSIC] BUNDLE: Draft title confusion 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, 07 Apr 2014 15:36:40 -0000 Hi, Works for me too, but perhaps "USING the Session Description...."? Regards, Christer Sent from my Sony Ericsson Xperia arc S Paul Kyzivat wrote: On 4/7/14 10:28 AM, Harald Alvestrand wrote: > "Negotiating Media Multiplexing in the Session Description Protocol > (SDP)" would work for me - WFM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Apr 7 20:47:50 2014 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 09C4D1A00BF for ; Mon, 7 Apr 2014 20:47:49 -0700 (PDT) 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=[BAYES_40=-0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6] 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 e0gRJS_aVaUk for ; Mon, 7 Apr 2014 20:47:45 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F2B1A00BC for ; Mon, 7 Apr 2014 20:47:44 -0700 (PDT) Received: from ppp118-209-163-70.lns20.mel6.internode.on.net ([118.209.163.70]:54285 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXN0W-0005wA-9Y for mmusic@ietf.org; Tue, 08 Apr 2014 13:47:32 +1000 Message-ID: <53437158.2010909@nteczone.com> Date: Tue, 08 Apr 2014 13:47:36 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53092D9B.80904@alum.mit.edu> In-Reply-To: <53092D9B.80904@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: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0Jkb1axhXQfex0WwhX5pQRdw0FY Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06 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, 08 Apr 2014 03:47:49 -0000 Hello Salvatore, Is there any plans to update the draft according to Paul's comments? I think he has valid concerns regarding how fmt is currently specified in the draft. Regards, Christian On 23/02/2014 10:07 AM, Paul Kyzivat wrote: > I've commented earlier on some threads about this draft. > Now I'm going through it carefully again, and have new comments: > > * Section 4: > > This covers media descriptions using three different fields: > 'SCTP', 'SCTP/DTLS', and 'DTLS/SCTP'. > > For both 'SCTP' and 'SCTP/DTLS' the "bottom" of the protocol stack is > SCTP, and the identifier of one end for an association consists of an > IP address and an SCTP port. This fits with m-line syntax - the SCTP > port number can be carried in the field. > > For 'DTLS/SCTP', the "bottom" of the protocol stack is UDP, with SCTP > over it. In this case the identifier for one end of an association > consists of an IP address, an SCTP port, and a UDP port. This doesn't > fit well into the syntax of an m-line. > > Because the *UDP* port is carried in the field, for a single > m-line there can be multiple DTLS/SCTP associations, one per SCTP port > number. The field is repurposed to carry the SCTP port numbers. > > Then, the problems caused by DTLS/SCTP are propagated to 'SCTP' and > 'SCTP/DTLS' usages, by also placing the SCTP port number in the > field in these usages. (For these protos it is redundant.) > > Because is used this way, it was necessary to introduce > a=sctpmap to specify what otherwise could have been specified using > the field. > > IMO this could be made much clearer by making the following changes: > > - an m-line with of 'SCTP', 'SCTP/DTLS', or 'DTLS/SCTP' always > describes a *single* SCTP association. > > - define the usage of for these protos so that it can be used to > carry the info currently in sctpmap, and in the DTLS/SCTP the SCTP > port number. > > - use BUNDLE for the (unlikely) case of multiple SCTP associations > over a single UDP port. > > It is a little difficult, but possible, to fit they necessary info > into the restricted syntax of . Here is an example of one > possibility: > > m=application 12345 DTLS/SCTP webrtc-datachannel \ > sctp-port#1 streams#16 max-message-size#100000 > > The following is a syntax that does does that: > > sctp-m-line = %x6d "=" > ("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) / > ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) / > ("application" SP udp-port SP "DTLS/SCTP" SP sctp-fmt CRLF) > > sctp-port = port > > udp-port = port > > sctp-fmt = sctp-app *(SP sctp-param) > > sctp-app = token > > sctp-param = maxmsg-param / streams-param / sctp-port-param > > maxmsg-param = "max-message-size#" port > > streams-param = "streams#" 1*DIGIT > > sctp-port-param = "sctp-port#" sctp-port > > (The use of "#" as separator isn't ideal, but it is the best choice of > what is permitted in a token, and it seems to read reasonably well. If > people hate this there are other ways to get the same effect.) > > Of course sctp-port-param is only meaningful with DTLS/SCTP. It and > the other sctp-params can be optional, with suitable defaults defined. > (For normal use, with only one association per UDP port everyone would > probably take the default sctp port, and so the parameter could be > omitted.) > > This then also allows a=fmtp to be used with these - most likely only > with sctp-app. E.g., > > m=application 12345 DTLS/SCTP webrtc-datachannel \ > sctp-port#1 streams#16 max-message-size#100000 > c=IN IP4 example.com > a=fmtp:webrtc-datachannel > > At the moment nothing webrtc-datachannel specific has been defined > that needs to be declared in SDP, so this may not be needed. It > *could* be used as a replacement for "a=dcmap" in > draft-ejzak-mmusic-data-channel-sdpneg. > > Bundling would apply in a case such as in section 10.1 of > draft-ietf-mmusic-sdp-bundle-negotiation-05. That example would be > rewritten as follows: > > a=group:BUNDLE dc bfcp t38 > m=application 12345 DTLS/SCTP webrtc-datachannel \ > sctp-port#5000 streams#16 max-message-size#100000 > c=IN IP4 example.com > a=mid:dc > m=application 12345 DTLS/SCTP bfcp \ > sctp-port#5001 streams#1 max-message-size#16384 > c=IN IP4 example.com > a=mid:bfcp > > m=application 12345 DTLS/SCTP t38 \ > sctp-port#5002 streams#1 max-message-size#65536 > c=IN IP4 example.com > a=mid:t38 > > * Section 5.1: > > This section starts out with: > > The sctpmap attribute maps from a port number (as used in an "m=" > line) to an encoding name denoting the payload format to be used on > top of the SCTP association or the actual protocol running on top of > it. > > This is just wrong. It doesn't really map to an encoding name denoted > a payload format. Immediately following the above is: > > The sctpmap MUST include the app parameter indicating the application > running on top of the association. > > And the syntax defines an app parameter, instead of an encoding name. > And as best I can tell the app parameter doesn't denote a payload > format. (Payload formats can vary from stream to stream.) The app > seems to denote the overall set of conventions that are used to > ascribe meaning and format to the streams. (This needs better > definition. Section 11.1 has an open issue to define a new IANA > registry for this. But there is also need to say more about the > semantics - what a new value must specify.) > > Later in this section: > > Any offered association MAY be rejected in the answer, for any > reason. If an association offer is rejected, the offerer and > answerer MUST NOT establish an SCTP association for it. To reject an > SCTP association, the SCTP port number in the "a=sctpmap:" attribute > line in the answer MUST be set to zero. > > In the case of DTLS/SCTP there are two ports - the udp port and the > sctp port. Either can be set to zero, with different consequences. > Something should be said about the behavior when the udp port is set > to zero. (Of course my suggestion to revamp the m-line renders this > moot.) > > * Section 7: > > What if the c= line contains a DNS name rather than an IP address? > Can that cause the initialization of more than one IP address? > > * Section 8: > > This contains the following statements: > > ... Therefore, this > specification does not define how to describe SCTP-over-UDP streams > in SDP or how to establish and maintain SCTP associations using ICE. > Should these features be specified for SCTP in the future, there will > be a need to specify how to use them in an SDP environment as well. > > Doesn't the definition of DTLS/SCTP render the above incorrect? > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Apr 7 21:15:00 2014 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 764051A00D7 for ; Mon, 7 Apr 2014 21:14:57 -0700 (PDT) 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_50=0.8, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6] 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 HRV7xa629gyL for ; Mon, 7 Apr 2014 21:14:53 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6F41A00C3 for ; Mon, 7 Apr 2014 21:14:52 -0700 (PDT) Received: from ppp118-209-163-70.lns20.mel6.internode.on.net ([118.209.163.70]:54429 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WXNQn-0002DJ-RP for mmusic@ietf.org; Tue, 08 Apr 2014 14:14:41 +1000 Message-ID: <534377B6.7070708@nteczone.com> Date: Tue, 08 Apr 2014 14:14:46 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic mailing list 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: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UVHza9cdUIh_gl_SgL2Qj5ZSkfA Subject: [MMUSIC] BUNDLE and SCTP 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, 08 Apr 2014 04:14:57 -0000 Hello Currently the BUNDLE draft focuses of the use of BUNDLE wrt to RTP. However a recent email from Paul K highlighted a potential use for SCTP, e.g. /Bundling would apply in a case such as in section 10.1 of draft-ietf-mmusic-sdp-bundle-negotiation-05. That example would be rewritten as follows: // //// // a=group:BUNDLE dc bfcp t38 // // m=application 12345 DTLS/SCTP webrtc-datachannel \ // // sctp-port#5000 streams#16 max-message-size#100000 // // c=IN IP4 example.com // // a=mid:dc // // m=application 12345 DTLS/SCTP bfcp \ // // sctp-port#5001 streams#1 max-message-size#16384 // // c=IN IP4 example.com // // a=mid:bfcp // //// // m=application 12345 DTLS/SCTP t38 \ // // sctp-port#5002 streams#1 max-message-size#65536 // // c=IN IP4 example.com // // a=mid:t38 / Clause 7.1/draft-ietf-mmusic-sdp-bundle-negotiation-06 indicates several mechanisms that need to be described by a specification for new protocols (e.g. SCTP). I wonder if we should add a clause to draft-ietf-mmusic-sctp-sdp-06 to document the relation of the SCTP SDP to BUNDLE usage? Regards, Christian From nobody Mon Apr 7 23:32:30 2014 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 9B5C41A00E6 for ; Mon, 7 Apr 2014 23:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=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 XbI1JzTQOzum for ; Mon, 7 Apr 2014 23:32:23 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 552A61A0032 for ; Mon, 7 Apr 2014 23:32:23 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-52-534397f08c23 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 5C.E6.15972.0F793435; Tue, 8 Apr 2014 08:32:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Tue, 8 Apr 2014 08:32:16 +0200 From: Christer Holmberg To: Christian Groves , mmusic mailing list Thread-Topic: [MMUSIC] BUNDLE and SCTP Thread-Index: AQHPUuEbwayfPpGMZEGm2abKWEa/45sHQSRA Date: Tue, 8 Apr 2014 06:32:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B210B@ESESSMB209.ericsson.se> References: <534377B6.7070708@nteczone.com> In-Reply-To: <534377B6.7070708@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje6H6c7BBpd7NS2+vG9ksZi6/DGL A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXx599+loK7/BX7p75maWC8x9PFyMkhIWAi MeHmKVYIW0ziwr31bF2MXBxCAicZJQ7c2MgK4SxmlJh5cw5TFyMHB5uAhUT3P22QBhGBWInG qdvZQWxhAVWJSS/PsUPE1SSOzT/FAmEbSTRf+Aa2gEVARaL910pGEJtXwFfi+e9mNhBbSEBb ouHoabAaTgEdiX8XToLZjEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+B/WAosTO s+3MEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShZnFqc lJtuZKiXm55bopdalJlcXJyfp1ecuokRGC8Ht/w23ME48Zr9IUZpDhYlcV6G6Z1BQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhh3650UPPvF1fC53iOL8Gp1OQUtvYnLVwde3O0grX5MSXrC vbTzL1eaHS261bLm/lkpxvz1e5f8yEvJu/V+1ppvV2RLHCYfnPh21cWrizUjPr+5tuXOznLz 8n7rHMuGP2HzXS5c2L/jl8WtDwv/P+122ZIe6rWNo+WUZb5Xweae3a8eVl701pVUVmIpzkg0 1GIuKk4EAGIohAplAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/P0HCbzj9BjQ9QEpDAi5p0DOIy8M Subject: Re: [MMUSIC] BUNDLE and SCTP 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, 08 Apr 2014 06:32:27 -0000 Hi, In the example below, SCTP is running on top of DTLS, and BUNDLE does descr= ibe how to distinguish between DTLS and (S)RTP. Now, if you run multiple SCTP associations on top of that DTLS connection, = you would use the SCTP port number to distinguish them. The general agreement has been that we, within the BUNDLE draft, describe w= hat is needed for RTCWEB (the main "customer" for BUNDLE at the moment), bu= t that we allow extensibility. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: 8. huhtikuuta 2014 7:15 To: mmusic mailing list Subject: [MMUSIC] BUNDLE and SCTP Hello Currently the BUNDLE draft focuses of the use of BUNDLE wrt to RTP.=20 However a recent email from Paul K highlighted a potential use for SCTP, e.= g. /Bundling would apply in a case such as in section 10.1 of draft-ietf-mmusi= c-sdp-bundle-negotiation-05. That example would be rewritten as follows: //= //// // a=3Dgroup:BUNDLE dc bfcp t38 // // m=3Dapplication 12345 DTLS/SC= TP webrtc-datachannel \ // // sctp-port#5000 streams#16 max-message-size#100000 // // c=3DIN IP4 example.com // // a=3Dmid:dc // // m=3Dapplication 12345 DTLS/SCTP bfcp \ // // sctp-port#5001 streams#1 max-message-size#16384 // // c=3DIN IP4 example.com // // a=3Dmid:bfcp // //// // m=3Dapplication 12345 DTLS/SCTP t38 \ // // sctp-port#5002 streams#1 max-message-size#65536 // // c=3DIN IP4 example.com // // a=3Dmid:t38 / Clause 7.1/draft-ietf-mmusic-sdp-bundle-negotiation-06 indicates several me= chanisms that need to be described by a specification for new protocols (e.= g. SCTP). I wonder if we should add a clause to draft-ietf-mmusic-sctp-sdp-06 to document the relation of the SCTP SDP to B= UNDLE usage? Regards, Christian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Apr 8 08:53:13 2014 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 BCB3E1A0491 for ; Tue, 8 Apr 2014 08:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.865 X-Spam-Level: *** X-Spam-Status: No, score=3.865 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, 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 PdC9Ky0v3ZlS for ; Tue, 8 Apr 2014 08:53:06 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F81A049D for ; Tue, 8 Apr 2014 08:53:01 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id nQQ51n0021vXlb858Tt1NX; Tue, 08 Apr 2014 15:53:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id nTt11n00N3ZTu2S3dTt1R3; Tue, 08 Apr 2014 15:53:01 +0000 Message-ID: <53441B5D.1020809@alum.mit.edu> Date: Tue, 08 Apr 2014 11:53:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53092D9B.80904@alum.mit.edu> <53437158.2010909@nteczone.com> In-Reply-To: <53437158.2010909@nteczone.com> 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=q20140121; t=1396972381; bh=JEbpdWPDtCn2VWtmZ8Zvoa4niuGmHxpAqVVKGBVxLAY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mTy05mff4NjT8tz/5o5Qsn2Nm0Ial2NCpzPRF16uby06f8Jub9wU3k0QkgO3sdor7 CAwfjNxlK6E1hxWqoAAO7Sy5kR6NgmEohnmvjCE3GpD8rmUFK57r+6Ufbr6O9gQhbm 5Fw+Fe/cBPiiVRE56SNqj0BRlIzgmqw4wmoHjBMcCnapxHOVYtSEPQWzG+T2roRcZF /RXC04lXfziGRMfmkGX+VxXHTqt3+u4PU0ZDK2qQZfoqufGYphqxgj0XzexoY0xH0a VEanR8mbatqVwHdurYBptyTg50AoANsWFUc3owcWu+Aber61UQCCiGq32M4r9rQChe oKC1FF7ykx7rg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/68YBvAmPTNOmxhfMPfCHGtwg7Ro Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sctp-sdp-06 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, 08 Apr 2014 15:53:07 -0000 We had an offline discussion of this in London - not exactly what is below, but similar. I thought we had agreement in principle and that Sal would be issuing a new version. But I don't recall hearing anything more since then. Thanks, Paul On 4/7/14 11:47 PM, Christian Groves wrote: > Hello Salvatore, > > Is there any plans to update the draft according to Paul's comments? I > think he has valid concerns regarding how fmt is currently specified in > the draft. > > Regards, Christian > > On 23/02/2014 10:07 AM, Paul Kyzivat wrote: >> I've commented earlier on some threads about this draft. >> Now I'm going through it carefully again, and have new comments: >> >> * Section 4: >> >> This covers media descriptions using three different fields: >> 'SCTP', 'SCTP/DTLS', and 'DTLS/SCTP'. >> >> For both 'SCTP' and 'SCTP/DTLS' the "bottom" of the protocol stack is >> SCTP, and the identifier of one end for an association consists of an >> IP address and an SCTP port. This fits with m-line syntax - the SCTP >> port number can be carried in the field. >> >> For 'DTLS/SCTP', the "bottom" of the protocol stack is UDP, with SCTP >> over it. In this case the identifier for one end of an association >> consists of an IP address, an SCTP port, and a UDP port. This doesn't >> fit well into the syntax of an m-line. >> >> Because the *UDP* port is carried in the field, for a single >> m-line there can be multiple DTLS/SCTP associations, one per SCTP port >> number. The field is repurposed to carry the SCTP port numbers. >> >> Then, the problems caused by DTLS/SCTP are propagated to 'SCTP' and >> 'SCTP/DTLS' usages, by also placing the SCTP port number in the >> field in these usages. (For these protos it is redundant.) >> >> Because is used this way, it was necessary to introduce >> a=sctpmap to specify what otherwise could have been specified using >> the field. >> >> IMO this could be made much clearer by making the following changes: >> >> - an m-line with of 'SCTP', 'SCTP/DTLS', or 'DTLS/SCTP' always >> describes a *single* SCTP association. >> >> - define the usage of for these protos so that it can be used to >> carry the info currently in sctpmap, and in the DTLS/SCTP the SCTP >> port number. >> >> - use BUNDLE for the (unlikely) case of multiple SCTP associations >> over a single UDP port. >> >> It is a little difficult, but possible, to fit they necessary info >> into the restricted syntax of . Here is an example of one >> possibility: >> >> m=application 12345 DTLS/SCTP webrtc-datachannel \ >> sctp-port#1 streams#16 max-message-size#100000 >> >> The following is a syntax that does does that: >> >> sctp-m-line = %x6d "=" >> ("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) / >> ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) / >> ("application" SP udp-port SP "DTLS/SCTP" SP sctp-fmt CRLF) >> >> sctp-port = port >> >> udp-port = port >> >> sctp-fmt = sctp-app *(SP sctp-param) >> >> sctp-app = token >> >> sctp-param = maxmsg-param / streams-param / sctp-port-param >> >> maxmsg-param = "max-message-size#" port >> >> streams-param = "streams#" 1*DIGIT >> >> sctp-port-param = "sctp-port#" sctp-port >> >> (The use of "#" as separator isn't ideal, but it is the best choice of >> what is permitted in a token, and it seems to read reasonably well. If >> people hate this there are other ways to get the same effect.) >> >> Of course sctp-port-param is only meaningful with DTLS/SCTP. It and >> the other sctp-params can be optional, with suitable defaults defined. >> (For normal use, with only one association per UDP port everyone would >> probably take the default sctp port, and so the parameter could be >> omitted.) >> >> This then also allows a=fmtp to be used with these - most likely only >> with sctp-app. E.g., >> >> m=application 12345 DTLS/SCTP webrtc-datachannel \ >> sctp-port#1 streams#16 max-message-size#100000 >> c=IN IP4 example.com >> a=fmtp:webrtc-datachannel >> >> At the moment nothing webrtc-datachannel specific has been defined >> that needs to be declared in SDP, so this may not be needed. It >> *could* be used as a replacement for "a=dcmap" in >> draft-ejzak-mmusic-data-channel-sdpneg. >> >> Bundling would apply in a case such as in section 10.1 of >> draft-ietf-mmusic-sdp-bundle-negotiation-05. That example would be >> rewritten as follows: >> >> a=group:BUNDLE dc bfcp t38 >> m=application 12345 DTLS/SCTP webrtc-datachannel \ >> sctp-port#5000 streams#16 max-message-size#100000 >> c=IN IP4 example.com >> a=mid:dc >> m=application 12345 DTLS/SCTP bfcp \ >> sctp-port#5001 streams#1 max-message-size#16384 >> c=IN IP4 example.com >> a=mid:bfcp >> >> m=application 12345 DTLS/SCTP t38 \ >> sctp-port#5002 streams#1 max-message-size#65536 >> c=IN IP4 example.com >> a=mid:t38 >> >> * Section 5.1: >> >> This section starts out with: >> >> The sctpmap attribute maps from a port number (as used in an "m=" >> line) to an encoding name denoting the payload format to be used on >> top of the SCTP association or the actual protocol running on top of >> it. >> >> This is just wrong. It doesn't really map to an encoding name denoted >> a payload format. Immediately following the above is: >> >> The sctpmap MUST include the app parameter indicating the application >> running on top of the association. >> >> And the syntax defines an app parameter, instead of an encoding name. >> And as best I can tell the app parameter doesn't denote a payload >> format. (Payload formats can vary from stream to stream.) The app >> seems to denote the overall set of conventions that are used to >> ascribe meaning and format to the streams. (This needs better >> definition. Section 11.1 has an open issue to define a new IANA >> registry for this. But there is also need to say more about the >> semantics - what a new value must specify.) >> >> Later in this section: >> >> Any offered association MAY be rejected in the answer, for any >> reason. If an association offer is rejected, the offerer and >> answerer MUST NOT establish an SCTP association for it. To reject an >> SCTP association, the SCTP port number in the "a=sctpmap:" attribute >> line in the answer MUST be set to zero. >> >> In the case of DTLS/SCTP there are two ports - the udp port and the >> sctp port. Either can be set to zero, with different consequences. >> Something should be said about the behavior when the udp port is set >> to zero. (Of course my suggestion to revamp the m-line renders this >> moot.) >> >> * Section 7: >> >> What if the c= line contains a DNS name rather than an IP address? >> Can that cause the initialization of more than one IP address? >> >> * Section 8: >> >> This contains the following statements: >> >> ... Therefore, this >> specification does not define how to describe SCTP-over-UDP streams >> in SDP or how to establish and maintain SCTP associations using ICE. >> Should these features be specified for SCTP in the future, there will >> be a need to specify how to use them in an SDP environment as well. >> >> Doesn't the definition of DTLS/SCTP render the above incorrect? >> >> 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 nobody Tue Apr 8 10:43:02 2014 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 172601A0671 for ; Tue, 8 Apr 2014 10:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9UMzMQMu6lyO for ; Tue, 8 Apr 2014 10:42:57 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id EBD251A0221 for ; Tue, 8 Apr 2014 10:42:56 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id nP4z1n0011swQuc5FViwhb; Tue, 08 Apr 2014 17:42:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id nViw1n00e3ZTu2S3bViwna; Tue, 08 Apr 2014 17:42:56 +0000 Message-ID: <53443520.90706@alum.mit.edu> Date: Tue, 08 Apr 2014 13:42:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: IETF MMUSIC WG 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=q20140121; t=1396978976; bh=4b/WNgALvZvXpcXCVHzliL1ELOvCx1d3CnNMvMOoVr4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dPcR13wG1ZsDK6AeLzEkDVq32KrQdPZne2qSEmWoURkCovtoimRAV/rOmqsl2oDNg cnfVRFFByWic9IQkAT5PUQW/U0BM5B+NuzxM9Cjp/YsiTxECNm3dEhC1B0QOauCmBQ ZmC1lTBsU/38RQCqRBXXNQGfuJqUB14RpM7UMexvI8CkEkFb1qAMVOF3q9s/NOJaI7 UEq4lDyJfoi0z1NLMTCrYQDUcsfGYwNHvHckuvsMmhqy3Sunl+oooHn6KoEdNzzQwQ L0jfiQRNDOA4OqjYD7hO1uSmXwKZgh80yVioE0fA76ERU2aiI/I4eTNZcXnKm6oPtV rVZ/z3Y7Fm5Dw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-yoM4lum5pMqJYMLZKpEpzSr4x4 Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 08 Apr 2014 17:42:58 -0000 Here are comments on the latest version: Section 1: I had trouble parsing the following: Once it is known that both the offerer and the answerer supports the BUNDLE mechanism, a BUNDLE group and the associated BUNDLE addresses have been negotiated, each endpoint can assign its BUNDLE address to each "m=" line within, and use the address to send and receive all media associated with, the BUNDLE group. I suggest: Once it is known that both the offerer and the answerer support the BUNDLE mechanism, and a BUNDLE group and the associated BUNDLE addresses have been negotiated, each endpoint can assign its BUNDLE address to each "m=" line within, and use the address to send and receive all media associated with, the BUNDLE group. Later in the section, in the following: The procedures in this specification apply to a given BUNDLE group. I suggest a change: s/apply/apply independently/ Section 2: In the following: Offerer BUNDLE address: Within a given BUNDLE group, an IP address and IP port combination used by an offerer to send and receive all media associated with each "m=" line within the BUNDLE group. Answerer BUNDLE address: Within a given BUNDLE group, an IP address and IP port combination used by an answerer to send and receive all media associated with each "m=" line within the BUNDLE group. I question the "to send and" in the above. In general with O/A the address is only for receive - there is no promise that media will also be sent from that address. Then, in the following: Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer, associated with a BUNDLE group. Is an m-line a bundled m-line if it is included in the a=group:bundle of the offer, but not in the answer??? IOW, for an offer do I determine if an m-line is bundled based on the a=group:bundle in the *offer*, or in the *answer*? Section 5.2.1: s/BUNDEL/BUNDLE/ Section 5.2.3: This fits into the general format for documenting O/A. So this section specifically describes the processing of the first offer. (E.g., in the sip session.) But this section is also used as *the* place to describe the initial offer that creates a BUNDLE group. That suggests that you can only create a bundle group within the first O/A of a sip session. Certainly that is not the intent. (A BUNDLE group can be first created in an offer that modifies an SDP session.) I don't currently have a suggestion for how to fix this. It is hard! Section 5.2.4.2: In the last line of the following: When an answerer generates an SDP answer, it MUST select a BUNDLE address for the offerer, referred to as the offerer BUNDLE address. The answerer MUST select an address which the offerer in the associated SDP answer requested to be within the BUNDLE group. s/answer/offer/ Section 5.2.6.2: The following has some grammar problems: NOTE: If the offerer wants that the answerer selects the address associated with the added "m=" as the offerer BUNDLE address, the offerer suggested BUNDLE mid MUST represent the added "m=" line [Section 5.2.3.2]. I suggest: NOTE: If the offerer wants the answerer to select the address associated with the added "m=" as the offerer BUNDLE address, the offerer suggested BUNDLE mid MUST represent the added "m=" line [Section 5.2.3.2]. Thanks, Paul From nobody Tue Apr 8 14:18:37 2014 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 AF5801A02A2 for ; Tue, 8 Apr 2014 14:18:31 -0700 (PDT) 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 aCpsAtPk7Unz for ; Tue, 8 Apr 2014 14:18:26 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 57C741A02C8 for ; Tue, 8 Apr 2014 14:18:26 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so1569300wgh.4 for ; Tue, 08 Apr 2014 14:18:25 -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=a5T4dXDoBRyNis55YUQQ2k/TcPTYe+p8KfrYL4YtynY=; b=rVOUFgHEQBmvX+MPXhAr7MgmnfjvE3cKYnml/gAhBG/Y0jk/vKDCMyh7iBvl8Y/Tzb 1DEHwAabsbxlj2ftjgEsxrTk16GB39k+2OMuDSJfrBR8zreQx4Pe6AjoFUb8O/2EBVHO c56xtChSgB/NHhmj5FFz1Gy0LwPGhXKmM+1VtXinYe4IdxQlesJxZfQ6VYl6u4TAeVtT WD74nLENNZoYpHQ8tR6GS5dCwXPaMBS3Z0EAwudWJtBEKH0cebpw8Qs40UhWJVytKyV6 KdUtj3QgF36wgUuiOSZtxUjqu8nOAcK7Xkz7aX5zhC4+2GmBhnSD9oRiEbos/3Ev5jZN TE6Q== MIME-Version: 1.0 X-Received: by 10.194.94.39 with SMTP id cz7mr93158wjb.78.1396991905625; Tue, 08 Apr 2014 14:18:25 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 8 Apr 2014 14:18:25 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2B210B@ESESSMB209.ericsson.se> References: <534377B6.7070708@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D2B210B@ESESSMB209.ericsson.se> Date: Tue, 8 Apr 2014 14:18:25 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0IkwRdis7MBQTpQEFzpawSnmhnc Cc: mmusic mailing list Subject: Re: [MMUSIC] BUNDLE and SCTP 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, 08 Apr 2014 21:18:31 -0000 On 7 April 2014 23:32, Christer Holmberg wrote: > Now, if you run multiple SCTP associations on top of that DTLS connection, you would use the SCTP port number to distinguish them. Or the PPID on individual frames. The data channels draft doesn't really describe what to do with unknown PPIDs, but it could. > The general agreement has been that we, within the BUNDLE draft, describe what is needed for RTCWEB (the main "customer" for BUNDLE at the moment), but that we allow extensibility. Sounds like a good candidate for a new internet draft to me. From nobody Wed Apr 9 00:22:17 2014 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 4A1431A0122 for ; Wed, 9 Apr 2014 00:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Jdq17hzjpAvR for ; Wed, 9 Apr 2014 00:22:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5091A0023 for ; Wed, 9 Apr 2014 00:22:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-6f-5344f524658e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B3.F2.04779.425F4435; Wed, 9 Apr 2014 09:22:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 09:22:12 +0200 From: Christer Holmberg To: Paul Kyzivat , IETF MMUSIC WG Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06 - Paul's comments Thread-Index: Ac9TwY60zFbh/6gBR0CQjgdTUqhFTw== Date: Wed, 9 Apr 2014 07:22:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B6381@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvja7KV5dgg1+P1CymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj6G2pgkNqFT83X2RrYLwp28XIySEhYCJx YutcNghbTOLCvfVgtpDAYUaJtyeLuxi5gOzFjBLv+x8AJTg42AQsJLr/aYPUiAh4SZz4exqs XlggUeL1pzY2iHiSxPrZK5lAykUE9CQe/MsFCbMIqEh0n2oFK+EV8JV4+raFGcRmBFr7/dQa JhCbWUBc4taT+UwQ5whILNlznhnCFpV4+fgfK4StJPFjwyUWiHodiQW7P7FB2NoSyxa+ZoaY LyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS833MQIDOqDW37r7mA8dU7kEKM0 B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhnr+bOtzkfaZXJuoS7eX1256H5 feusfvstM3/Ky6t16/ia0y+TpXsbWp7k6206W1b+Z46UyuHChn+PY06JFczPF80q/hKTf73n 2Ua7SBahD2bpV9NE1kfMLqhns1E7M0n+b/ed0hIznlDvf9oRBpuFm+YcPMwTHylxIOmxhrPv /F35blxfVyixFGckGmoxFxUnAgAr8gO5OAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YUe2LKEUoBNhVlYPeWSU7t2BvKA Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-06 - Paul's comments 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, 09 Apr 2014 07:22:17 -0000 Hi Paul, Thanks for your comments! See inline. > Here are comments on the latest version: > > Section 1: > > I had trouble parsing the following: > > Once it is known that both the offerer and the answerer supports the > BUNDLE mechanism, a BUNDLE group and the associated BUNDLE addresses > have been negotiated, each endpoint can assign its BUNDLE address to > each "m=3D" line within, and use the address to send and receive all > media associated with, the BUNDLE group. > > I suggest: > > Once it is known that both the offerer and the answerer support the > BUNDLE mechanism, and a BUNDLE group and the associated BUNDLE > addresses have been negotiated, each endpoint can assign its BUNDLE > address to each "m=3D" line within, and use the address to send and > receive all media associated with, the BUNDLE group. I don't think we even need to say "Once it is known that both the offerer a= nd the answerer support the BUNDLE mechanism". Because, if both endpoints d= on't support BUNDLE, they will not negotiate a BUNDLE group etc. So, maybe something like: "Once the offerer and the answerer have negotiated a BUNDLE group, and the= associated BUNDLE addresses,=20 each endpoint can assign its BUNDLE address to each "m=3D" line within, an= d use the address to send and receive all media associated with, the BUNDLE group." ------------ >Later in the section, in the following: > > The procedures in this specification apply to a given BUNDLE group. > > I suggest a change: s/apply/apply independently/ Ok. ------------ >Section 2: > >In the following: > > Offerer BUNDLE address: Within a given BUNDLE group, an IP address > and IP port combination used by an offerer to send and receive all > media associated with each "m=3D" line within the BUNDLE group. > > Answerer BUNDLE address: Within a given BUNDLE group, an IP address > and IP port combination used by an answerer to send and receive all > media associated with each "m=3D" line within the BUNDLE group. > > I question the "to send and" in the above. In general with O/A the addres= s is only for receive - there is no promise that media will also be sent fr= om that address. Ok. ------------ >Then, in the following: > > Bundled "m=3D" line: An "m=3D" line, in an SDP offer or SDP answer, > associated with a BUNDLE group. > > Is an m-line a bundled m-line if it is included in the a=3Dgroup:bundle o= f the offer, but not in the answer??? > > IOW, for an offer do I determine if an m-line is bundled based on the a= =3Dgroup:bundle in the *offer*, or in the *answer*? Note that the text talk about an "m=3D" line being associated with a BUNDLE= group. So, if the BUNDLE group hasn't been created yet, the "m=3D" line is= n't considered being bundled. ------------ >Section 5.2.1: > >s/BUNDEL/BUNDLE/ Ok. ------------ >Section 5.2.3: > >This fits into the general format for documenting O/A. So this section spe= cifically describes the processing of the first offer. (E.g., in the sip se= ssion.) > >But this section is also used as *the* place to describe the initial offer= that creates a BUNDLE group. That suggests that you can only create a bund= le group within the=20 >first O/A of a sip session. Certainly that is not the intent. (A BUNDLE gr= oup can be first created in an offer that modifies an SDP session.) > > I don't currently have a suggestion for how to fix this. It is hard! I tried to cover that in section 2: "Initial SDP offer: The first SDP offer, in which the offerer indicates that it wants to create a given BUNDLE group." Maybe we could say: "The first SDP offer, within an SDP session, in which..." ...to make it more clear that it does not necessarily have to be the first = offer within the SDP session. ------------ >Section 5.2.4.2: > >In the last line of the following: > > When an answerer generates an SDP answer, it MUST select a BUNDLE > address for the offerer, referred to as the offerer BUNDLE address. > The answerer MUST select an address which the offerer in the > associated SDP answer requested to be within the BUNDLE group. > > s/answer/offer/ Ok. ------------ >Section 5.2.6.2: > >The following has some grammar problems: > > NOTE: If the offerer wants that the answerer selects the address > associated with the added "m=3D" as the offerer BUNDLE address, the > offerer suggested BUNDLE mid MUST represent the added "m=3D" line > [Section 5.2.3.2]. > >I suggest: > > NOTE: If the offerer wants the answerer to select the address > associated with the added "m=3D" as the offerer BUNDLE address, the > offerer suggested BUNDLE mid MUST represent the added "m=3D" line > [Section 5.2.3.2]. Ok. Regards, Christer From nobody Wed Apr 9 02:27:33 2014 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 85BE31A07BC for ; Wed, 9 Apr 2014 02:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 aMnP3HO158j2 for ; Wed, 9 Apr 2014 02:27:31 -0700 (PDT) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 53DE31A07B4 for ; Wed, 9 Apr 2014 02:27:30 -0700 (PDT) X-AuditID: c1b4fb28-b7fd58e000007bb5-05-534512813632 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 66.CD.31669.18215435; Wed, 9 Apr 2014 11:27:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 11:27:28 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] BUNDLE and SCTP Thread-Index: AQHPUuEbwayfPpGMZEGm2abKWEa/45sHQSRAgADXuoCAAOt8IA== Date: Wed, 9 Apr 2014 09:27:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B7844@ESESSMB209.ericsson.se> References: <534377B6.7070708@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D2B210B@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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvjW6jkGuwwZu9UhZf3jeyWFw784/R YuryxywOzB47Z91l91iy5CeTx4rzM1kCmKO4bFJSczLLUov07RK4MvY/3stS0MFRMf3QFMYG xjfsXYycHBICJhJrP/9lg7DFJC7cWw9kc3EICZxklJiz5CQThLOYUWLTryUsXYwcHGwCFhLd /7RBGkQEdCUWnX0ANohZIFbi9PPFjCC2sICqxKSX59ghatQkjs0/xQJhO0lMevAXzGYRUJHY cHYpWA2vgK/E3yutrCC2kMA2RonZLZYgNqdAoMT2FyeYQWxGoOO+n1rDBLFLXOLWk/lMEEcL SCzZc54ZwhaVePn4HyuErSTxY8MlsJOZBTQl1u/Sh2hVlJjS/RBqraDEyZlPWCYwis1CMnUW QscsJB2zkHQsYGRZxShZnFpcnJtuZKiXm55bopdalJlcXJyfp1ecuokRGFcHt/zW2MHYfc3+ EKM0B4uSOG/VzM4gIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYz5YdZH5p8+wZZwb//LOulp F/PzGVwCuJtXXDkXrhP3Q/qJdL6xIkuUS93yLdN1zstPviXskzLJNHGzg/HSKWzzSt9Xf/z4 j8mntLf/25boq0VT7C+qvur8ESEyXfbPzX+5XELLqpuiKia+MXjiqPZNIDl/0dJ/KVu3Brmc dlXw1OTKiJjmnaDEUpyRaKjFXFScCADjybzleQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GqE5bfwVpkVVukouyi2mq2buV1M Cc: mmusic mailing list Subject: Re: [MMUSIC] BUNDLE and SCTP 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, 09 Apr 2014 09:27:32 -0000 SGksDQoNCj4+IE5vdywgaWYgeW91IHJ1biBtdWx0aXBsZSBTQ1RQIGFzc29jaWF0aW9ucyBvbiB0 b3Agb2YgdGhhdCBEVExTIGNvbm5lY3Rpb24sIHlvdSB3b3VsZCB1c2UgdGhlIFNDVFAgcG9ydCBu dW1iZXIgdG8gZGlzdGluZ3Vpc2ggdGhlbS4NCj4NCj4gT3IgdGhlIFBQSUQgb24gaW5kaXZpZHVh bCBmcmFtZXMuICBUaGUgZGF0YSBjaGFubmVscyBkcmFmdCBkb2Vzbid0IHJlYWxseSBkZXNjcmli ZSB3aGF0IHRvIGRvIHdpdGggdW5rbm93biBQUElEcywgYnV0IGl0IGNvdWxkLg0KDQpBY3R1YWxs eSwgaWYgeW91IGhhdmUgbXVsdGlwbGUgU0NUUCBhc3NvY2lhdGlvbnMgd2l0aGluIGEgQlVORExF IGdyb3VwLCBub25lIG9mIHRoZSBhYm92ZSB3b3VsZCB3b3JrLiBCZWNhdXNlLCB5b3UgY291bGQg ZW5kIHVwIHVzaW5nIHRoZSBzYW1lIFNDVFAgcG9ydCBudW1iZXJzIGluIGVhY2ggU0NUUCBhc3Nv Y2lhdGlvbi4NCg0KPj4gVGhlIGdlbmVyYWwgYWdyZWVtZW50IGhhcyBiZWVuIHRoYXQgd2UsIHdp dGhpbiB0aGUgQlVORExFIGRyYWZ0LCBkZXNjcmliZSB3aGF0IGlzIG5lZWRlZCBmb3IgUlRDV0VC ICh0aGUgbWFpbiAiY3VzdG9tZXIiIGZvciBCVU5ETEUgYXQgdGhlIG1vbWVudCksIGJ1dCB0aGF0 IHdlIGFsbG93IGV4dGVuc2liaWxpdHkuDQo+DQo+IFNvdW5kcyBsaWtlIGEgZ29vZCBjYW5kaWRh dGUgZm9yIGEgbmV3IGludGVybmV0IGRyYWZ0IHRvIG1lLg0KDQpZZXMuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQo= From nobody Wed Apr 9 03:55:32 2014 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 75C971A021E for ; Wed, 9 Apr 2014 03:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 if3TeHncgIxN for ; Wed, 9 Apr 2014 03:55:25 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id D32641A01FA for ; Wed, 9 Apr 2014 03:55:24 -0700 (PDT) Received: from [130.209.247.112] (port=64847 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WXqA1-0007Cb-Cc; Wed, 09 Apr 2014 11:55:22 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> Date: Wed, 9 Apr 2014 11:55:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yMK1WEkHJYVRN-M--HVgUHY0r_g Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 09 Apr 2014 10:55:30 -0000 Christer, Section 8.1.1 starts: By default, all RTP based media within a BUNDLE group belong to a single RTP session [RFC3550]. Multiple BUNDLE groups will form multiple RTP Sessions. NOTE: The usage of multiple RTP sessions within a BUNDLE group, or the usage of a single RTP session that spans over multiple BUNDLE groups, is outside the scope of this specification. Other specification needs to extend the BUNDLE mechanism in order to allow such usages. When a single RTP session is used, all bundled "m=3D" lines representing RTP based media share a single SSRC numbering space [RFC3550]. I suggest rephrasing this as: All RTP-based media within a single BUNDLE group belong to a=20 single RTP session [RFC3550]. Multiple BUNDLE groups will form=20 multiple RTP sessions, one per bundle group. Since a single RTP session is used for each bundle group, all=20 =93m=3D=93 lines representing RTP-based media in a bundle group will=20= share a single SSRC numbering space [RFC3550]. Similarly, in the Introduction, I suggest changing: The default assumption is that all Real-Time Protocol (RTP) [RFC3550] based media flows associated with a BUNDLE group belong to the same RTP Session [RFC3550]. Future extensions can change that assumption. to All Real-time Transport Protocol (RTP) [RFC3550] based media flows=20 associated with a single BUNDLE group belong to a single RTP session=20= [RFC3550]. The rationale for this change is that supporting multiple RTP sessions = on a single 5-tuple is a significant change to RTP, for example to = introduce a shim-layer, that did not receive consensus in AVTCORE. These = changes align the bundle draft with that decision, and reword the text = for clarity. Colin On 7 Apr 2014, at 09:06, Christer Holmberg = wrote: > We have submitted a new version (-06) of BUNDLE. > =20 > As you will see, the document has been re-structured quite a bit. The = main reason for that was to align the SDP offer/answer procedures with = the RFC 3264 structure (I had to do that for another draft, so I decided = to do the same thing also for BUNDLE =96 rather now than when we reach = WGLC). > =20 > The draft does have a dependency on an RTP header indicator, and the = completion of draft-ietf-mmusic-sdp-mux-attributes, but otherwise there = are currently no BUNDLE specific open issues. > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From nobody Wed Apr 9 04:26:38 2014 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 40A051A0231 for ; Wed, 9 Apr 2014 04:26:36 -0700 (PDT) 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 SIGBbhTeiW5B for ; Wed, 9 Apr 2014 04:26:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC531A00AF for ; Wed, 9 Apr 2014 04:26:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-65-53452e652f01 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A9.7E.04779.56E25435; Wed, 9 Apr 2014 13:26:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 13:26:29 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 - Colin's comments Thread-Index: Ac9T4uSBodGdfTerQn2caqXr4Jz90g== Date: Wed, 9 Apr 2014 11:26:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2B7AC9@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvjW6anmuwwZ5WDovlL08wWkxd/pjF gclj2v37bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4/HsbS8FlsYp9PSsYGxhfCnYxcnJICJhI PHnwjg3CFpO4cG89kM3FISRwmFFixs8ZzBDOYkaJ/1fOMXUxcnCwCVhIdP/TBmkQEVCV2HH8 HyOIzSygLtHzu4UZxBYWyJTo/7efCaImS+J70zdGCFtP4u6BOewgY1gEVCQmThcCCfMK+Eqs PPCaHcRmBLrh+6k1TBAjxSVuPZnPBHGbgMSSPeeZIWxRiZeP/7FC2EoSPzZcYoGo15FYsPsT G4StLbFs4WtmiPmCEidnPmGZwCgyC8nYWUhaZiFpmYWkZQEjyypG9tzEzJz0csNNjMCAP7jl t+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUeq66rsn6/+e 2DnB6tJh3p8XlGfp5qvtPW/7rPGnqVb5y69aC3I+7fkxtTt4y9F/C7527ex7W1odGcTxNjJ5 zd4pG2VnqMxOfxqS/Y2Hk/GqS4PATLW5JYzX1bRzXp0u2t5RmbhxkdWjapmTuUU9xRca28v/ 3Mww/OSy7lr2Pe0pN3vPseTN+KrEUpyRaKjFXFScCABdBZClRgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uJCb77or9EOuWgu3t_5NQJjdBLM Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 - Colin's comments 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, 09 Apr 2014 11:26:36 -0000 HI Colin, >Section 8.1.1 starts: > > By default, all RTP based media within a BUNDLE group belong to a > single RTP session [RFC3550]. Multiple BUNDLE groups will form > multiple RTP Sessions. > > NOTE: The usage of multiple RTP sessions within a BUNDLE group, or > the usage of a single RTP session that spans over multiple BUNDLE > groups, is outside the scope of this specification. Other > specification needs to extend the BUNDLE mechanism in order to allow > such usages. > > When a single RTP session is used, all bundled "m=3D" lines > representing RTP based media share a single SSRC numbering space > [RFC3550]. > > I suggest rephrasing this as: > > All RTP-based media within a single BUNDLE group belong to a=20 > single RTP session [RFC3550]. Multiple BUNDLE groups will form=20 > multiple RTP sessions, one per bundle group. > > Since a single RTP session is used for each bundle group, all=20 > "m=3D" lines representing RTP-based media in a bundle group will=20 > share a single SSRC numbering space [RFC3550]. > > Similarly, in the Introduction, I suggest changing: > > The default assumption is that all Real-Time Protocol (RTP) [RFC3550] > based media flows associated with a BUNDLE group belong to the same > RTP Session [RFC3550]. Future extensions can change that assumption. > > to > > All Real-time Transport Protocol (RTP) [RFC3550] based media flows=20 > associated with a single BUNDLE group belong to a single RTP session=20 > [RFC3550]. > > The rationale for this change is that supporting multiple RTP sessions on= a single 5-tuple is a significant change to RTP, for example=20 > to introduce a shim-layer, that did not receive consensus in AVTCORE. The= se changes align the bundle draft with that decision, and reword the text f= or clarity. I am ok with your suggestion, as long as other multiple-RTP-session advocat= es don't object :) Regards, Christer On 7 Apr 2014, at 09:06, Christer Holmberg = wrote: > We have submitted a new version (-06) of BUNDLE. > =20 > As you will see, the document has been re-structured quite a bit. The mai= n reason for that was to align the SDP offer/answer procedures with the RFC= 3264 structure (I had to do that for another draft, so I decided to do the= same thing also for BUNDLE - rather now than when we reach WGLC). > =20 > The draft does have a dependency on an RTP header indicator, and the comp= letion of draft-ietf-mmusic-sdp-mux-attributes, but otherwise there are cur= rently no BUNDLE specific open issues. > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From nobody Wed Apr 9 05:30:24 2014 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 29BF91A0228 for ; Wed, 9 Apr 2014 05:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, 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 geO46-aww6W6 for ; Wed, 9 Apr 2014 05:30:18 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0170B1A020F for ; Wed, 9 Apr 2014 05:30:17 -0700 (PDT) X-AuditID: c1b4fb38-b7f518e000000889-97-53453d58682b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D2.89.02185.85D35435; Wed, 9 Apr 2014 14:30:17 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.174.1; Wed, 9 Apr 2014 14:30:16 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6AF02110200; Wed, 9 Apr 2014 15:30:16 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 78FBC5722D; Wed, 9 Apr 2014 15:30:15 +0300 (EEST) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 215B45722C; Wed, 9 Apr 2014 15:30:15 +0300 (EEST) Message-ID: <53453D5B.9020108@ericsson.com> Date: Wed, 9 Apr 2014 15:30:19 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "mmusic@ietf.org" , References: <20140404114208.DC6DF7FC39C@rfc-editor.org> 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+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvjW6krWuwwbJHrBbvL+haXDvzj9Fi 6vLHLBYvuieyOLB4TPm9kdVj56y77B5LlvxkCmCO4rJJSc3JLEst0rdL4MqY/+4De8EetooL W34xNzD2sHYxcnBICJhIXH6b1MXICWSKSVy4t56ti5GLQ0jgKKPE3N41zBDOekaJI1dmMkI4 exklTn8/CJVZxyix9M09JghnBaPExG8bmUCG8QpoS5zZ0w1mswioSMxb0MYOYrMJ2EqsfnWT BcQWFUiWuL3xK1S9oMTJmU/A4iICdhKXd91gBbGZBSIkjj58BRYXFnCQ+LDgPzOILSRQI/Hj YTtYDadAoMS+5ReZIOotJBa/OcgOYctLbH87hxniOTWJq+c2QfWqSlz994pxAqPoLCSrZyFp n4WkfQEj8ypGjuLU4qTcdCODTYzAuDi45bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgZFxYtT8nTy7X55xDdm3dP2C3NpK5qseH7+EiolNLK70rHq4iM1P j9H17Fz/5qxt4pN0759ePEd3lvlRm95e174XMz4/dFt8IvxEivC3S6+nrUwSYFkqfjVhbk90 wIEn34+8C+4Pklmaa22lfPGtgaCIY+RJcW6eJXr99dHnnqwN+1XusaJHdqYSS3FGoqEWc1Fx IgCiyb1gWQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cjQnWeLNKbRNP8dV4yoQ3Xj8JVU Cc: Flemming Andreasen Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3952) 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, 09 Apr 2014 12:30:22 -0000 On 04/04/14 18:37, Martin Thomson wrote: > On 4 April 2014 04:42, RFC Errata System wrote: >> Can i know why the priority is maximum of 10 DIGIT length? If possible we may decrease to 9 DIGIT, so that the value will be fit into integer of 32bit. > > I don't think that the ABNF has to be perfectly prescriptive. There > is text that covers the actual limit (2^32-1). An exact ABNF would be > much harder to understand. > > Anyone using ABNF and only ABNF to validate syntax is welcome to > construct a more precise grammar for their needs. What is described > here is perfectly adequate for an RFC. I agree with Martin and to clarify: you need up to 10 decimal digits to express the whole range of 32 bit integers and hence "1*9 DIGIT" would not be sufficient. Cheers, Ari From nobody Wed Apr 9 07:28:57 2014 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 683C61A0346 for ; Wed, 9 Apr 2014 07:28:55 -0700 (PDT) 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 etGhhd_iYRrf for ; Wed, 9 Apr 2014 07:28:54 -0700 (PDT) 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 8675A1A032E for ; Wed, 9 Apr 2014 07:28:54 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta07.westchester.pa.mail.comcast.net with comcast id noAq1n0031uE5Es57qUueK; Wed, 09 Apr 2014 14:28:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id nqUt1n00R3ZTu2S3cqUtGn; Wed, 09 Apr 2014 14:28:54 +0000 Message-ID: <53455925.4060002@alum.mit.edu> Date: Wed, 09 Apr 2014 10:28:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <534377B6.7070708@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D2B210B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2B7844@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2B7844@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=q20140121; t=1397053734; bh=azGDEcwkUEzegtCHbvo9HaiWT5sD8Jnn/k5Y0wmlifo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZxNWp93TodBDMJNNwpZ+QNz5Io9aQOhqv2nPqLaNwQoHxOk8ZDjgUK5gD0arSTwgQ HFFafIIFoYmju6krnxKBjtuHZMpZZ3BvrGIJpm7LxZBcdk3S8z0F++OclAGg+/PgZU XXX/u+OIiZjkmhJPJERlqsLLku2E7afwwitN7G8K7z0HR9hXmrKigD5lm6nnc+Ujzi Tt3BuVvnKf1TKiV7xx35JYYvRz5Kzjh4cWv/yVx45F9M+/9kYIv2pgZyGikbC7udXn NLejoGjIf3J0bFT7Fk/a89QdAxHCQAzSr2/zcJQYhqjBgU93utyEWJQjv82c2IgP4q hfvIjUFpM8DoQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/o7pZiDSuqQzf0g_oubx5VDSKWCM Subject: Re: [MMUSIC] BUNDLE and SCTP 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, 09 Apr 2014 14:28:55 -0000 On 4/9/14 5:27 AM, Christer Holmberg wrote: > Hi, > >>> Now, if you run multiple SCTP associations on top of that DTLS connection, you would use the SCTP port number to distinguish them. >> >> Or the PPID on individual frames. The data channels draft doesn't really describe what to do with unknown PPIDs, but it could. > > Actually, if you have multiple SCTP associations within a BUNDLE group, none of the above would work. Because, you could end up using the same SCTP port numbers in each SCTP association. If "two" SCTP associations have the same 5-tuple and the same SCTP ports on both ends then they are not really separate SCTP associations. If the goal is to have two in the same bundle group, sharing the same 5-tuple, then there must be a different SCTP port to distinguish them. That would have to be part of the rule for associating packets with m-lines in the bundle group. If you wanted to associate to m-lines based on PPID, then you would need PPID-specific media sections. We don't currently have a way to do that. Thanks, Paul From nobody Wed Apr 9 07:52:44 2014 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 41C1A1A034A for ; Wed, 9 Apr 2014 07:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 GYDGRonppwcR for ; Wed, 9 Apr 2014 07:52:28 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C17221A035C for ; Wed, 9 Apr 2014 07:51:45 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n16so2837223oag.17 for ; Wed, 09 Apr 2014 07:51:45 -0700 (PDT) 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=kZPmlI6xaQRyRZIe7CPZg2LQMkzBypIpagWJ4HSOqqc=; b=hKIT8ZArXcYJ8pQKmlj9DQlG2gt5m0Tn9DZH9/zajOVfBlcEhexAy87ek9TrHSqP1D dXW5g3qX087e6nytZueY/axBlTPpXStmirUobCAg7E1gN9OSacMSDJThwKzqdX3duLjs xd85UoSuMKDMCoIUchdHGYRAyzR33D7gPE1Grntcfegt0giKgCfpv1m1p8w6f06xHPYj gCf+U0cQ3/qzarT9rF8QxvOJcSdcYQFT2obAOFh/zpRlOnxUo1ELUANYWOBNS29X7Qky ZRmpeI6ItqLMR5+NwvtxO+8jXoqQ/PFW+anq5W5eTupxCRHQuoSi7TAnlXKXoFzZe6Ib qmbw== X-Gm-Message-State: ALoCoQmd8BikBujJIv3JO4JZLDs/VRgdwgp+449V7Qswz5f97/iLpQrDDQlpX5go6uAtMd00N5bx MIME-Version: 1.0 X-Received: by 10.182.28.195 with SMTP id d3mr9147885obh.19.1397055105245; Wed, 09 Apr 2014 07:51:45 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Wed, 9 Apr 2014 07:51:45 -0700 (PDT) In-Reply-To: <53453D5B.9020108@ericsson.com> References: <20140404114208.DC6DF7FC39C@rfc-editor.org> <53453D5B.9020108@ericsson.com> Date: Wed, 9 Apr 2014 10:51:45 -0400 Message-ID: From: Richard Barnes To: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Content-Type: multipart/alternative; boundary=001a11c2cd1847b8b404f69d3d65 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nV5UYQYeqNoOWKN-N5K40qNhFJs Cc: Flemming Andreasen , tsuresh20@gmail.com, "mmusic@ietf.org" Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3952) 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, 09 Apr 2014 14:52:38 -0000 --001a11c2cd1847b8b404f69d3d65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the quick feedback. I have marked this as Rejected. On Wed, Apr 9, 2014 at 8:30 AM, Ari Ker=E4nen wro= te: > On 04/04/14 18:37, Martin Thomson wrote: > >> On 4 April 2014 04:42, RFC Errata System >> wrote: >> >>> Can i know why the priority is maximum of 10 DIGIT length? If possible >>> we may decrease to 9 DIGIT, so that the value will be fit into integer = of >>> 32bit. >>> >> >> I don't think that the ABNF has to be perfectly prescriptive. There >> is text that covers the actual limit (2^32-1). An exact ABNF would be >> much harder to understand. >> >> Anyone using ABNF and only ABNF to validate syntax is welcome to >> construct a more precise grammar for their needs. What is described >> here is perfectly adequate for an RFC. >> > > I agree with Martin and to clarify: you need up to 10 decimal digits to > express the whole range of 32 bit integers and hence "1*9 DIGIT" would no= t > be sufficient. > > > Cheers, > Ari > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c2cd1847b8b404f69d3d65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the quick feedback. =A0I have marked this as Re= jected.


= On Wed, Apr 9, 2014 at 8:30 AM, Ari Ker=E4nen <ari.keranen@ericsson= .com> wrote:
On 04/04/14 18:37, Martin Th= omson wrote:
On 4 April 2014 04:42, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
Can i know why the priority is maximum of 10 DIGIT length? If possible we m= ay decrease to 9 DIGIT, so that the value will be fit into integer of 32bit= .

I don't think that the ABNF has to be perfectly prescriptive. =A0There<= br> is text that covers the actual limit (2^32-1). =A0An exact ABNF would be much harder to understand.

Anyone using ABNF and only ABNF to validate syntax is welcome to
construct a more precise grammar for their needs. =A0What is described
here is perfectly adequate for an RFC.

I agree with Martin and to clarify: you need up to 10 decimal digits to exp= ress the whole range of 32 bit integers and hence "1*9 DIGIT" wou= ld not be sufficient.


Cheers,
Ari


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

--001a11c2cd1847b8b404f69d3d65-- From nobody Wed Apr 9 09:07:57 2014 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 E4C891A03A1 for ; Wed, 9 Apr 2014 09:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-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 rbc0_Galup9t for ; Wed, 9 Apr 2014 09:07:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA071A03B3 for ; Wed, 9 Apr 2014 09:07:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DD15818000C; Wed, 9 Apr 2014 09:07:43 -0700 (PDT) To: tsuresh20@gmail.com, jdrosen@jdrosen.net, alissa@cooperw.in, fandreas@cisco.com, ari.keranen@ericsson.com X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140409160743.DD15818000C@rfc-editor.org> Date: Wed, 9 Apr 2014 09:07:43 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/oSz3vYnau1BodKFMpTEjUYiHWZQ Cc: mmusic@ietf.org, RFC Editor Subject: [MMUSIC] [Errata Rejected] RFC5245 (3952) 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, 09 Apr 2014 16:07:54 -0000 The following errata report has been rejected for RFC5245, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3952 -------------------------------------- Status: Rejected Type: Technical Reported by: Suresh Tummala Date Reported: 2014-04-04 Rejected by: Richard Barnes (IESG) Section: 15.1 Original Text ------------- priority = 1*10DIGIT Corrected Text -------------- Notes ----- priority = 1*10DIGIT Here the maximum value it can hold is "9999999999"(ten-nines)(priority is of maximum length 10 DIGIT as per grammar in sec 15.1). The number of bits required to hold the maximum value(ten-nines) is 34. Which requires a "double" value instead of integer of 32 bit. Can i know why the priority is maximum of 10 DIGIT length? If possible we may decrease to 9 DIGIT, so that the value will be fit into integer of 32bit. -- VERIFIER NOTES -- The limitation to 2^32-1 is made clear elsewhere in the text. The ABNF does not need to enforce this constraint -------------------------------------- RFC5245 (draft-ietf-mmusic-ice-19) -------------------------------------- Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Publication Date : April 2010 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Wed Apr 9 09:34:10 2014 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 053F11A032E for ; Wed, 9 Apr 2014 09:34:09 -0700 (PDT) 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 yOFwTOgQotIt for ; Wed, 9 Apr 2014 09:34:04 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 351781A0380 for ; Wed, 9 Apr 2014 09:34:04 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so2722585wgg.13 for ; Wed, 09 Apr 2014 09:34:03 -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=RuK+Y/SnFPEQfSfJMEpgo4rhfVM/9vLWz16k5T5i5xU=; b=cjeRQgH/l3Xeo0eaeu71vRmQcsMd+UK02ZEOTzpG4JT/Tc9x91Ta/ril1x/VAg4c78 uSadosz6rTsaufZoVGSLP/HuOu4495dxv5Aw3e91kts2oPYTxsiEpH0vrfPQAJc1sNgO mClJtN6uwQDVgiyLLNx55ix9ZSUuckpz8GHUo8jb3fuIFG0RlaDI64icmxhSLSzdFF2X ka9deE8sDHtz7HYAl4uO/GJjn4GD0/2rsT3//A1J+jRefqOB/rCe0lmc6mEbvMrFbL2q Qc3DntQnySKfc/0YJvZXHTfN+syLAvNeMzpxOFY5UbwUf2FBTU4/7vCiZGiVn6iQnHmk 3mgg== MIME-Version: 1.0 X-Received: by 10.194.203.170 with SMTP id kr10mr10642721wjc.19.1397061243090; Wed, 09 Apr 2014 09:34:03 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 09:34:03 -0700 (PDT) In-Reply-To: <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> Date: Wed, 9 Apr 2014 09:34:03 -0700 Message-ID: From: Martin Thomson To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5ukY1Rxn_9KeMgG0Zt89ULPJsrQ Cc: "mmusic \(E-mail\)" , Christer Holmberg Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 09 Apr 2014 16:34:09 -0000 Looks easier to read. On 9 April 2014 03:55, Colin Perkins wrote: > Multiple BUNDLE groups will form > multiple RTP sessions, one per bundle group. ...unless they happen to be the same RTP session seen from different perspectives. From nobody Wed Apr 9 11:40:09 2014 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 D5D421A042E for ; Wed, 9 Apr 2014 11:40:07 -0700 (PDT) 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 LApk9Us7b42E for ; Wed, 9 Apr 2014 11:40:06 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4371A0421 for ; Wed, 9 Apr 2014 11:40:05 -0700 (PDT) X-AuditID: c1b4fb2d-b7f328e0000012ab-5b-534594048b14 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EC.51.04779.40495435; Wed, 9 Apr 2014 20:40:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Wed, 9 Apr 2014 20:40:04 +0200 From: Christer Holmberg To: Martin Thomson , Colin Perkins Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 Thread-Index: AQHPU+I1IoFhCIHQL0iEoZQg8YbIKpsJWb2AgABVNPA= Date: Wed, 9 Apr 2014 18:40:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BA456@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> 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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvjS7LFNdgg2eTNC2WvzzBaHHtzD9G i6nLH7M4MHtMu3+fzWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgypi1+ANbwSvmiiWN51ga GO8wdzFyckgImEh8WX6MFcIWk7hwbz0biC0kcJhR4uNMqy5GLiB7MaPEt4ddQAkODjYBC4nu f9ogpohAkER/XzFIObOAukTP7xawkcICYRJfL7eC2SIC4RJ7Du9jgbCtJHZca2UBaWURUJHY e44JJMwr4Ctx8tocdohNpxklPm3dCpbgFAiU+Dv3OdhpjECnfT+1hglil7jErSfzmSBOFpBY suc81CuiEi8f/4N6RUli0e3PTCC7mAU0Jdbv0odoVZSY0v2QHWKvoMTJmU9YJjCKzUIydRZC xywkHbOQdCxgZFnFyJ6bmJmTXm64iREYLwe3/NbdwXjqnMghRmkOFiVx3g9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MFZeP1N31SdhlnROvGz+EdkaWe0dm06saraft4OdbdWrtEXq AhzaZTrvOL6z7Qo9sKpx/g7VNs9P3jFH5qRe2xzt9zF5gkDqjy2PkyPc+F78S9tsuuauwu/1 t74f8H68uyJ6195iMaZHQVybfaZNjsgSUb8l67X6Xt/S6LfNGa9Y3KbM8M2eM1GJpTgj0VCL uag4EQBjM5LPZQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/qVnuDLNZ5Yltc2Q-Ok-7U-qt63U Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 09 Apr 2014 18:40:08 -0000 SGksDQoNCj5Mb29rcyBlYXNpZXIgdG8gcmVhZC4NCg0KSSdtIGdsYWQgdG8gaGVhciB0aGF0IDop DQoNCj4+IE9uIDkgQXByaWwgMjAxNCAwMzo1NSwgQ29saW4gUGVya2lucyA8Y3NwQGNzcGVya2lu cy5vcmc+IHdyb3RlOg0KPj4gTXVsdGlwbGUgQlVORExFIGdyb3VwcyB3aWxsIGZvcm0NCj4+ICAg IG11bHRpcGxlIFJUUCBzZXNzaW9ucywgb25lIHBlciBidW5kbGUgZ3JvdXAuDQo+DQo+IC4uLnVu bGVzcyB0aGV5IGhhcHBlbiB0byBiZSB0aGUgc2FtZSBSVFAgc2Vzc2lvbiBzZWVuIGZyb20gZGlm ZmVyZW50IHBlcnNwZWN0aXZlcy4NCg0KTm90IHN1cmUgSSB1bmRlcnN0YW5kLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0K From nobody Wed Apr 9 12:49:10 2014 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 249711A041F for ; Wed, 9 Apr 2014 12:49:08 -0700 (PDT) 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 MoIY0kQuSZrL for ; Wed, 9 Apr 2014 12:49:03 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 614C81A01BA for ; Wed, 9 Apr 2014 12:49:03 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so2967895wes.29 for ; Wed, 09 Apr 2014 12:49:02 -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=WtdZ2JBa4t9DhQs3ZbflnHYMXbLlzwJqgKslJJaJoSw=; b=Yrj6kdg3qi7Dt8SLz/EQ2vjSZHao/j6Kve/G0tve1YBTXJilK7IGnQGcJU02X8sbOu 87g9iCZy6subC7lrcJrZ+g5QjzEcI3Go8Zlecp2sLCmkdleo9emom0lZwEGoqJMbgJ+7 HB8+6qEwEcp0+YHNDugDRkfsIGAek73GQHGHAcGhnyzcuEfGrxnGwe5Zc2KqkxMpWkHU bHSKFeAcqxiOYiKefF/cgk/V80QsDV38zVX38GgXzrdBnK+nZdQ8oj0dkp8CLEWola9A EbzMOlrr8hqe8skwmGeI8tpDixWayKzvoOusHdUha9HwGZn9WI2ISSrORVRuBlykTncq 0dQw== MIME-Version: 1.0 X-Received: by 10.180.108.13 with SMTP id hg13mr3577849wib.56.1397072942381; Wed, 09 Apr 2014 12:49:02 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 12:49:02 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2BA456@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1D2BA456@ESESSMB209.ericsson.se> Date: Wed, 9 Apr 2014 12:49:02 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8eIaN2MVu9CzNH4hu4XI--2OSEc Cc: Colin Perkins , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 09 Apr 2014 19:49:08 -0000 On 9 April 2014 11:40, Christer Holmberg wrote: >>> On 9 April 2014 03:55, Colin Perkins wrote: >>> Multiple BUNDLE groups will form >>> multiple RTP sessions, one per bundle group. >> >> ...unless they happen to be the same RTP session seen from different perspectives. > > Not sure I understand. The definition of RTP session is such that you could be seeing the same session on two 5 tuples and yet be ignorant of this fact. a a \ / | b From nobody Wed Apr 9 13:39:46 2014 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 4380A1A031E for ; Wed, 9 Apr 2014 13:39:45 -0700 (PDT) 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 y6P3vG99IM3v for ; Wed, 9 Apr 2014 13:39:41 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4B11A02B3 for ; Wed, 9 Apr 2014 13:39:40 -0700 (PDT) Received: from [81.187.2.149] (port=38919 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WXzHT-0001rR-0i; Wed, 09 Apr 2014 21:39:38 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: Date: Wed, 9 Apr 2014 21:39:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1D2BA456@ESESSMB209.ericsson.se> To: Martin Thomson X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GejEnw6AHDikMaf6sX81hYp4P7g Cc: "mmusic \(E-mail\)" , Christer Holmberg Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 09 Apr 2014 20:39:45 -0000 On 9 Apr 2014, at 20:49, Martin Thomson = wrote: > On 9 April 2014 11:40, Christer Holmberg = wrote: >>>> On 9 April 2014 03:55, Colin Perkins wrote: >>>> Multiple BUNDLE groups will form >>>> multiple RTP sessions, one per bundle group. >>>=20 >>> ...unless they happen to be the same RTP session seen from different = perspectives. >>=20 >> Not sure I understand. >=20 > The definition of RTP session is such that you could be seeing the > same session on two 5 tuples and yet be ignorant of this fact. >=20 > a a > \ / > | > b Right. A better phrasing might be =93Disjoint BUNDLE groups will form = multiple RTP sessions, one per bundle group=94? --=20 Colin Perkins http://csperkins.org/ From nobody Thu Apr 10 00:51:14 2014 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 DC2241A0133 for ; Thu, 10 Apr 2014 00:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 gWG5sWp6iZeo for ; Thu, 10 Apr 2014 00:51:08 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3621A0127 for ; Thu, 10 Apr 2014 00:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1397116268; x=1398325868; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=v8thmMWg1xusO1wjkj6WbOktCbG5nX2vbl8O7gALMUA=; b=RY9Zw2bT58NbkP6iH2ppfCRyjKdY/zc3AuB1f+c4oI90yNq2u+qzqOrO 0rkJ3pKIuhiKOEmSsXv+WO3LT1GX44JKxe6JWUd5au5IvnJYoBQ4ApdWz d3G2luC6+Tcg1sXeUE6yPqGnNGEg0+Fjs57VWAhGPsPF+UBsrcdKgRv/R g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFACdNRlOtJA2I/2dsb2JhbABZgwaBEsVJFnSCLIELAYEAJwSID5oasjcXkheBFASJI487kkKDMIIr X-IronPort-AV: E=Sophos;i="4.97,832,1389744000"; d="scan'208";a="34564885" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 10 Apr 2014 07:50:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3A7omVx016510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Apr 2014 07:50:48 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.19]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 02:50:48 -0500 From: "Pal Martinsen (palmarti)" To: "mmusic (E-mail)" Thread-Topic: ICEbis clarification regarding component id Thread-Index: AQHPVJGVg867j+sye0qbqNJMVGDRXw== Date: Thu, 10 Apr 2014 07:50:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.75] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5CE21E5D55E7CB4CAC9AAD589218B275@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uovhRNqcqNKz26vRLPsT12lL11Q Subject: [MMUSIC] ICEbis clarification regarding component id 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, 10 Apr 2014 07:51:13 -0000 Hi, Nitpicking, but I just got a question from someone I really could not answe= r. ICE usage with RTP and RTCP are well described in RFC5245. However, it doe= s not specify how to choose the component id for non RTP/RTCP protocols. In= our implementation we have just chosen 1 and really never given it any mor= e thought for protocols like BFCP.=20 Would it be worthwhile having some clarification text in ICEbis? Something = like: If ICE is used to help non RTP/RTCP protocols through a NAT and that protoc= ol only have one component the component id MUST be set to 1, unless ICE us= age is described for that particular protocol elsewhere. For protocols cont= aining more than one component, ICE usage should be described in the protoc= ol description or in a separate RFC. Apologies if I missed some ting in RFC5245 that spells this out. .-. P=E5l-Erik From nobody Thu Apr 10 04:00:35 2014 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 E8E291A01F4 for ; Thu, 10 Apr 2014 04:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 wP5LQD-PiJzb for ; Thu, 10 Apr 2014 04:00:29 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3831A01CC for ; Thu, 10 Apr 2014 04:00:28 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-e8-534679ca5b52 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FC.C5.13555.AC976435; Thu, 10 Apr 2014 13:00:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 13:00:26 +0200 From: Christer Holmberg To: Colin Perkins , Martin Thomson Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 Thread-Index: AQHPU+I1IoFhCIHQL0iEoZQg8YbIKpsJWb2AgABVNPD//+FGAIAADhuAgAER0vA= Date: Thu, 10 Apr 2014 11:00:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2BC8BE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2AB260@ESESSMB209.ericsson.se> <51F4517A-9FED-4880-9495-28A5A53192ED@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1D2BA456@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvje7pSrdgg9/XWSyWvzzBaHHtzD9G i6nLH7M4MHtMu3+fzWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgypjTO5epYCFrxZlpc5ka GLtYuhg5OSQETCRuNuyAssUkLtxbz9bFyMUhJHCSUeLtlm1QzhJGie8XHjJ3MXJwsAlYSHT/ 0wZpEBEIkjh/6AwTiM0soC7R87uFGcQWFgiT+Hq5lRmiJlxiz+F9LBC2n8TuE/vA4iwCqhK9 nxaxg4zkFfCV+LY6FyQsJNDLLPHynAmIzSngKPG3YwojiM0IdNv3U2ugVolL3HoynwniZgGJ JXvOM0PYohIvH/9jhbAVJdqfNjBC1OtILNj9iQ3C1pZYtvA1WD2vgKDEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyilGyOLW4ODfdyEAvNz23RC+1KDO5uDg/T684dRMjMLIObvlttIPx5B77 Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTC2xRe99O+8erVP+qXPfxvW 9PuOddwa6R+U/sa847NzOsHcqn8/YdKGGtOKyNhzvzYk6bzsmv7tlur+02Y++5+d2bpTb6X0 gbgP1zKUb7c/mH7dZlvDSi/JjSVl/rvnt1eX7dMNujT1fUjEqasTElR/f2OMqr/7r+qi99Ot DCuNdBYu23sx5lq2EktxRqKhFnNRcSIA6pK9j3oCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nBp5jIWzJ_7_-r4lWWeChAhQdzo Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-06 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, 10 Apr 2014 11:00:33 -0000 Hi, >>>>> On 9 April 2014 03:55, Colin Perkins wrote: >>>>> Multiple BUNDLE groups will form >>>>> multiple RTP sessions, one per bundle group. >>>>=20 >>>> ...unless they happen to be the same RTP session seen from different p= erspectives. >>>=20 >>> Not sure I understand. >>=20 >> The definition of RTP session is such that you could be seeing the=20 >> same session on two 5 tuples and yet be ignorant of this fact. >>=20 >> a a >> \ / >> | >> b > > Right. A better phrasing might be "Disjoint BUNDLE groups will form multi= ple RTP sessions, one per bundle group"? Whatever makes you happy :) Regards, Christer From nobody Fri Apr 11 00:45:39 2014 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 4F8471A0420 for ; Fri, 11 Apr 2014 00:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 Pu01Jd8TapLV for ; Fri, 11 Apr 2014 00:45:36 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE281A0132 for ; Fri, 11 Apr 2014 00:45:36 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3B7jX15017727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Apr 2014 02:45:34 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3B7jXnT024472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 09:45:33 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 11 Apr 2014 09:45:33 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Thread-Index: AQHPSZ11tlxeVOi9qUaF/6Ya6nB3kJr0rpiAgAvrKICAC4amgA== Date: Fri, 11 Apr 2014 07:45:32 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC21144B@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC1DAAF2@FR711WXCHMBA03.zeu.alcatel-lucent.com> <533E0E37.1040404@nteczone.com> In-Reply-To: <533E0E37.1040404@nteczone.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/J67LARxDfgio0EbdtVFyb-dZdas Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt 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, 11 Apr 2014 07:45:38 -0000 Hello Christian, thanks for review and comments. Agree to all enhancement proposals. Good catch concerning RFC 4572. There should be an update -02 available today. Regards, Albrecht -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: Freitag, 4. April 2014 03:43 To: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Hello Albrecht, Thanks for submitting the draft. I support the addition of the extra codepoints for scenarios where a gateway performs application agnostic in= ter working. In general the background to H.248/Megaco usage of SDP is good= but I'm not sure if the reasons for the new codepoints are documented suff= iciently in the draft. Some specific comments below: Clause 1.4 Scope: I propose to word this slightly differently to indicate t= he scope is the collection of SDP codepoints for GCPs in order to identify = additional ones that REQUIRE registration with IANA. Clause 4: There appears to be some duplication in the headings, i.e. 4 and = 4.5. Perhaps also " element" needs to be removed from the title of h= eading 4 as clause 4.4 covers the element? Clause 4.1 Purpose, Last Para: To me this is the reason for the entire draf= t. The draft has cataloged how SDP is used by GCPs(H.248/Megaco) however ha= sn't really gone into much depth on why the additional codepoints are neede= d. Perhaps a paragraph for each additional codepoint could be added indicat= ing where it is used/needed? Clause 4.4: I think the draft could indicate that H.248 uses the = values as defined on the IANA registry and no additional IANA registration= s are required. Clause 5.1: I think it would be good to note that this has already been reg= istered with IANA. Clause 7.1: TCP/TLS is already registered. See RFC4572 clause 4. However I'= m not sure that in the case of agnostic interworking that the MUST indicate= d in that clause (/An 'm' line that specifies 'TCP/TLS' MUST further qualif= y the protocol using a fmt identifier to indicate the application being run= over TLS./) applies. I've also noticed some other minor editorial issues that i'll forward to yo= u off-line. Regards, Christian On 27/03/2014 8:48 PM, Schwarz, Albrecht (Albrecht) wrote: > fyi, this is a spin off activity from > draft-ietf-mmusic-udptl-dtls > in order to define additional codepoints as required for DTLS security se= ssion termination (so called end-to-access edge security mode) and DTLS tra= nsparent forwarding (e.g. as part of end-to-end security mode) in middlebox= es. > -Albrecht > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: Donnerstag, 27. M=E4rz 2014 10:03 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-schwarz-sdp-for-gw-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : SDP codepoints for gateway control > Author : Albrecht Schwarz > Filename : draft-schwarz-sdp-for-gw-01.txt > Pages : 12 > Date : 2014-03-27 > > Abstract: > SDP is used in many signalling protocols at call control level (such > as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and > gateway control level (such as H.248/MEGACO, MGCP). Scope of this RFC > is related to gateway control specific SDP usage. Gateway control > protocols do usually NOT define and introduce any new SDP parameters, > however, gateway control protocols need specific SDP parameter values > in addition to SDP usage at call or bearer control level. Such SDP > codepoints are collected by this RFC with the purpose of registration > with IANA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-schwarz-sdp-for-gw/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-schwarz-sdp-for-gw-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-schwarz-sdp-for-gw-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion 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 > > _______________________________________________ > 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 nobody Fri Apr 11 09:46:55 2014 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 2D9011A06FF for ; Fri, 11 Apr 2014 09:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 1ti879NtHX_8 for ; Fri, 11 Apr 2014 09:46:51 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (hwsga01-in.huaweimarine.com [119.145.15.223]) by ietfa.amsl.com (Postfix) with ESMTP id 05A791A0702 for ; Fri, 11 Apr 2014 09:46:50 -0700 (PDT) Received: from 172.24.1.78 (EHLO szxpml201-edg.exmail.huawei.com) ([172.24.1.78]) by szxrg11-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZY53427; Sat, 12 Apr 2014 00:46:46 +0800 (CST) Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml201-edg.exmail.huawei.com (172.24.2.66) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 12 Apr 2014 00:46:42 +0800 Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.46]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.03.0158.001; Sat, 12 Apr 2014 00:46:42 +0800 From: Roni Even To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-even-mmusic-application-token-03.txt Thread-Index: AQHPVaN5WvGalTaPX0i13vmV4oIK3ZsMn3Hr Date: Fri, 11 Apr 2014 16:46:42 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com> References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com> In-Reply-To: <20140411163112.6591.91881.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-BsJLPT5EH9VHttJwkXc2s9YNDk Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-03.txt 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, 11 Apr 2014 16:46:54 -0000 Hi , Based on the mailing list and London discussion this new version limited th= e scope of the token to be just a token with no semantics that can be used= as appId or recv-appId Roni ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, April 11, 2014 7:31 PM To: Jonathan Lennox; Roni Even; Qin Wu; Roni Even; Jonathan Lennox; Qin Wu Subject: New Version Notification for draft-even-mmusic-application-token-0= 3.txt A new version of I-D, draft-even-mmusic-application-token-03.txt has been successfully submitted by Roni Even and posted to the IETF repository. Name: draft-even-mmusic-application-token Revision: 03 Title: The Session Description Protocol (SDP) Application Token At= tribute Document date: 2014-04-11 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-appli= cation-token-03.txt Status: https://datatracker.ietf.org/doc/draft-even-mmusic-applicat= ion-token/ Htmlized: http://tools.ietf.org/html/draft-even-mmusic-application-to= ken-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-mmusic-applic= ation-token-03 Abstract: The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how to de-multiplex streams within an RTP session, but in some use cases applications need further identifiers in order to identify the signaling descriptions associated with particular RTP media streams. This document defines a mechanism to provide the mapping between the SSRCs of RTP streams and the SDP m-line description by defining extensions to RTP and RTCP messages. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Apr 11 10:41:07 2014 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 EB33C1A0724 for ; Fri, 11 Apr 2014 10:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bQB4QyitB5NI for ; Fri, 11 Apr 2014 10:41:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 597FB1A072E for ; Fri, 11 Apr 2014 10:40:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s3BHeMfW005766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Apr 2014 17:40:22 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s3BHeMtl021708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 19:40:22 +0200 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.104]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0181.006; Fri, 11 Apr 2014 19:40:21 +0200 From: "Belling, Thomas (NSN - DE/Munich)" To: "Schwarz, Albrecht (Albrecht)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Thread-Index: AQHPSZ11tlxeVOi9qUaF/6Ya6nB3kJr0rpiAgAvrKICADCrMcA== Date: Fri, 11 Apr 2014 17:40:20 +0000 Message-ID: References: <786615F3A85DF44AA2A76164A71FE1AC1DAAF2@FR711WXCHMBA03.zeu.alcatel-lucent.com> <533E0E37.1040404@nteczone.com> In-Reply-To: <533E0E37.1040404@nteczone.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="iso-8859-1" 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: 5567 X-purgate-ID: 151667::1397238022-00001326-F6B48AEE/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tXO_y0upIzZvZQHT6eZmKnbcEtU Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt 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, 11 Apr 2014 17:41:04 -0000 Hi Albrecht, thanks for your attempt to register the codepoints in Clause 8 of your draf= t at IANA. I understand this is the main intention of this draft and a inte= rnet draft seems indeed required for that purpose. Perhaps you should choose a filename containing "mmusic", e.g. "draft-schwa= rz-mmusic-sdp-for-gw" to direct new version notifications and discussions t= o the proper group. I understand a version 2 of the draft is now available. I believe clauses 1 and 2 are rather long and could be shortened a bit. Is = all the history essential and are all abbreviations and conventions really = used within the draft? Regards, Thomas -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Christian Gr= oves Sent: Friday, April 04, 2014 3:43 AM To: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Hello Albrecht, Thanks for submitting the draft. I support the addition of the extra codepoints for scenarios where a gateway performs application agnostic in= ter working. In general the background to H.248/Megaco usage of SDP is good= but I'm not sure if the reasons for the new codepoints are documented suff= iciently in the draft. Some specific comments below: Clause 1.4 Scope: I propose to word this slightly differently to indicate t= he scope is the collection of SDP codepoints for GCPs in order to identify = additional ones that REQUIRE registration with IANA. Clause 4: There appears to be some duplication in the headings, i.e. 4 and = 4.5. Perhaps also " element" needs to be removed from the title of h= eading 4 as clause 4.4 covers the element? Clause 4.1 Purpose, Last Para: To me this is the reason for the entire draf= t. The draft has cataloged how SDP is used by GCPs(H.248/Megaco) however ha= sn't really gone into much depth on why the additional codepoints are neede= d. Perhaps a paragraph for each additional codepoint could be added indicat= ing where it is used/needed? Clause 4.4: I think the draft could indicate that H.248 uses the = values as defined on the IANA registry and no additional IANA registration= s are required. Clause 5.1: I think it would be good to note that this has already been reg= istered with IANA. Clause 7.1: TCP/TLS is already registered. See RFC4572 clause 4. However I'= m not sure that in the case of agnostic interworking that the MUST indicate= d in that clause (/An 'm' line that specifies 'TCP/TLS' MUST further qualif= y the protocol using a fmt identifier to indicate the application being run= over TLS./) applies. I've also noticed some other minor editorial issues that i'll forward to yo= u off-line. Regards, Christian On 27/03/2014 8:48 PM, Schwarz, Albrecht (Albrecht) wrote: > fyi, this is a spin off activity from > draft-ietf-mmusic-udptl-dtls > in order to define additional codepoints as required for DTLS security se= ssion termination (so called end-to-access edge security mode) and DTLS tra= nsparent forwarding (e.g. as part of end-to-end security mode) in middlebox= es. > -Albrecht > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: Donnerstag, 27. M=E4rz 2014 10:03 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-schwarz-sdp-for-gw-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : SDP codepoints for gateway control > Author : Albrecht Schwarz > Filename : draft-schwarz-sdp-for-gw-01.txt > Pages : 12 > Date : 2014-03-27 > > Abstract: > SDP is used in many signalling protocols at call control level (such > as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and > gateway control level (such as H.248/MEGACO, MGCP). Scope of this RFC > is related to gateway control specific SDP usage. Gateway control > protocols do usually NOT define and introduce any new SDP parameters, > however, gateway control protocols need specific SDP parameter values > in addition to SDP usage at call or bearer control level. Such SDP > codepoints are collected by this RFC with the purpose of registration > with IANA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-schwarz-sdp-for-gw/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-schwarz-sdp-for-gw-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-schwarz-sdp-for-gw-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion 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 > > _______________________________________________ > 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 nobody Mon Apr 14 09:43:37 2014 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 2A30E1A03D7 for ; Mon, 14 Apr 2014 09:43:33 -0700 (PDT) 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 U_7bi1EcLChG for ; Mon, 14 Apr 2014 09:43:32 -0700 (PDT) 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 3DE761A02CF for ; Mon, 14 Apr 2014 09:43:32 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id pqvh1n0051GhbT855sjVSh; Mon, 14 Apr 2014 16:43:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id psjV1n0093ZTu2S3TsjV36; Mon, 14 Apr 2014 16:43:29 +0000 Message-ID: <534C1031.2000809@alum.mit.edu> Date: Mon, 14 Apr 2014 12:43:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com> 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=q20140121; t=1397493809; bh=pHmYxfmqd8BvjpHDGceasMSfumnGL8NwuvatcpqUx+c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=keebCojqxT6vMryJVBbhdpNtIRHnOlxcM62aorzzW/aKJsCSW2Dto1yqlMBPYWYIC ze7XS9JnpEJ692SENTV47BgRBMEF+hXSy/3fYXJYGL7sOhLKA4q4PpcZM+2+xRQZ2N umgwEYeTw3JO8uWMO3jG+Q00IjnLQs10PPKYw3+ZWuzLaMKuFNzW4AEIt4CDWh98/J H36IjOnh3scux/Wk/pqERJtd9MGW4MbzAy0ZjKMDl75wBClRrXbraHJUsiOOaY97ZW PCIrjhPb58iesUznWbH+3aTHiJd5wLoh7pRGCHzCCLiRHa7CWhGlO4aWNAodvL4Ryp Lhgg/Q73+AQxg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/msfdNgtfxdeUsyD5tR3MlkzlmUA Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-03.txt 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, 14 Apr 2014 16:43:33 -0000 I have a couple of comments on the new version: Section 4: An answerer, receiving an offer containing appId or recv-appId attributes, MUST respond with mirrored recv-appId and appId values for the subset of m= lines and packet streams indicated in the answer, maintaining the same recv-appId and appId values. IIUC these aren't *mirrored*. Rather, for each appId in the offer there should be a recv-appId (with the same id value) in the answer, and for each recv-appId in the offer there should be a matching appId in the answer. It is this matching indication in the answer that tells the offerer that the answerer agrees. IIUC, a recv-appId in the offer is intended so that media can be identified even before the answer is received. But at that time the offerer doesn't yet know if the answerer will accept it. So is the offerer just hoping it will work? Also, this section makes it mandatory to use recv-appId with bundle. Isn't it only needed of the pt isn't unique? Thanks, Paul From nobody Mon Apr 14 14:10:39 2014 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 B40671A0636 for ; Mon, 14 Apr 2014 14:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 x9YO0QyF4gu8 for ; Mon, 14 Apr 2014 14:10:34 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9C81A0225 for ; Mon, 14 Apr 2014 14:10:34 -0700 (PDT) X-Note-AR-ScanTimeLocal: 4/14/2014 5:10:31 PM 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-126/SG:2 4/14/2014 5:10:18 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.87106 p=-0.976962 Source White X-Signature-Violations: 0-0-0-4711-c X-Note-419: 15.6006 ms. Fail:0 Chk:1342 of 1342 total X-Note: SCH-CT/SI:0-1342/SG:1 4/14/2014 5:10:26 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> 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: G327 G328 G329 G330 G334 G335 G445 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 114996257; Mon, 14 Apr 2014 17:10:31 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 14 Apr 2014 16:10:29 -0500 From: Jonathan Lennox To: Paul Kyzivat Thread-Topic: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-03.txt Thread-Index: AQHPVaOlwNWvJvMEwUO2zvW9axTsTJsRnxVegABVYQA= Date: Mon, 14 Apr 2014 21:10:29 +0000 Message-ID: <0458F74A-9B29-43EE-9814-567EA7B85DDE@vidyo.com> References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com> <534C1031.2000809@alum.mit.edu> In-Reply-To: <534C1031.2000809@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <03148DD83B73D84898212A9D2CEA52F1@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Tph09kHg6jeAaQ2INah5EWpxsEw Cc: mmusic Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-03.txt 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, 14 Apr 2014 21:10:35 -0000 On Apr 14, 2014, at 12:43 PM, Paul Kyzivat wrote: > I have a couple of comments on the new version: >=20 > Section 4: >=20 > An answerer, receiving an offer containing appId or recv-appId > attributes, MUST respond with mirrored recv-appId and appId values > for the subset of m=3D lines and packet streams indicated in the > answer, maintaining the same recv-appId and appId values. >=20 > IIUC these aren't *mirrored*. Rather, for each appId in the offer there s= hould be a recv-appId (with the same id value) in the answer, and for each = recv-appId in the offer there should be a matching appId in the answer. It = is this matching indication in the answer that tells the offerer that the a= nswerer agrees. Right. =93Mirrored=94 was a poor choice of words. We=92ll clarify the wor= ding in the next version. > IIUC, a recv-appId in the offer is intended so that media can be identifi= ed even before the answer is received. But at that time the offerer doesn't= yet know if the answerer will accept it. So is the offerer just hoping it = will work? Yes. In general, you send an offer hoping it will work, yes? I don=92t se= e why recv-appId is any different. If you mean, what happens if the answerer doesn=92t support recv-appId? I = think appId needs to be mandatory for BUNDLE. > Also, this section makes it mandatory to use recv-appId with bundle. Isn'= t it only needed of the pt isn't unique? That=92s a good point; the MUST should be changed to be scoped to non-uniqu= e PT values. I=92m inclined to say that appId and recv-appId MAY be used even if PTs are= unique, and SHOULD be used if you expect you might re-offer with non-uniqu= e PTs in the future. From nobody Tue Apr 15 16:03:36 2014 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 1473F1A0027 for ; Tue, 15 Apr 2014 16:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=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 BcP1f8gBbY2y for ; Tue, 15 Apr 2014 16:03:31 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 926781A0023 for ; Tue, 15 Apr 2014 16:03:31 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AA00D21079 for ; Tue, 15 Apr 2014 19:03:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 15 Apr 2014 19:03:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=+STDYiHZ0/jF+Xrpl9QcBmbl9ag=; b=p3xXud1j/pgOGxYxmaGIzTScwTs9 qCPV+zAYvcJeYbXTyNEOcvFGRIkCzvF0SzM0+QGbngyijiLF2Prv7imZe7BIIyJR QzzhVqVZf2GjQQzNGQf89hA8iD/koIxF4kvO0xS72DBPl+IXxavrTgdojJSDmFTM 4vSoKWgBPjtF3SY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=+STDYiHZ0/jF+Xrpl9QcBm bl9ag=; b=D8CZn9u0HkxXeGBwvRsgSrmrzsQjKYPEx1f4UVtDbOWN1Pnm9nq0e3 tVCiUmfYOXC70gQyrYOx0vcNMq8uYM2gCyEdee6atd/TNVdc8mE/JbAgkltn2tEl QdHJkCYBs5LKela923JcHB0sORlGA1R1fuHWyc2EwwSHmF6OKAyPc= X-Sasl-enc: do4Y9W2aT3RAHrWckVNJodF1Zgvt7IJgjM4RRNSPqo7d 1397603007 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 45875C007AA; Tue, 15 Apr 2014 19:03:24 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Tue, 15 Apr 2014 16:03:21 -0700 From: Alissa Cooper To: Alissa Cooper , Dan Wing Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 References: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Oc770uQj6e4ofS8IJRtPL44q_FI Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 15 Apr 2014 23:03:34 -0000 I=E2=80=99d like to close out this thread. Are folks on board with this proposed change to Section 1? OLD: Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet unless all security considerations are taken into account and solved. NEW: Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet, and in controlled environments unless all security considerations are taken into account and solved. Thanks, Alissa On 4/3/14, 11:19 AM, "Alissa Cooper" wrote: >On 4/3/14 10:39 AM, "Dan Wing" wrote: > >> >>On Apr 3, 2014, at 10:28 AM, Alissa Cooper wrote: >> >>> Hi Dan, >>>=20 >>> On 4/1/14 11:42 AM, "Dan Wing" wrote: >>>>=20 >>>>>> The draft suggests use of SRTP for authenticating media which does >>>>>> resolve the security issues (from a privacy/confidentiality >>>>>> perspective). >>>>>>=20 >>>>>=20 >>>>> I was more concerned with the DoS aspect. > >In response to Emil's note above about the SRTP text resolving the >security issues "from a privacy/confidentiality perspective," all I was >saying was that my initial question was prompted not because I was >concerned about a breach of confidentiality, but about the ability to >perform a DoS attack even when SRTP is in use. I think the text in Section >5 that describes this is ok though. > >>>>=20 >>>> The DoS aspect of authenticating incoming SRTP packets to the SBC? >>>=20 >>> The DoS aspect that is described in the paragraph Emil quoted below. >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> That's part of section 5: >>>>>>=20 >>>>>> Naturally, SRTP [RFC3711] would help mitigate such threats and >>>>>>should >>>>>> be used independently of HNT. For example, in cases where >>>>>>end-to-end >>>>>> encryption is used it would still be possible for an attacker to >>>>>> hijack a session despite the use of SRTP and perform a denial of >>>>>> service attack. However, media integrity would not be compromised. >>>>>>=20 >> >>Sorry, I read it again and I'm still not clear on the concern. Could you >>restate or rephrase. >> >> >>>=20 >>>>> I think something like the following might capture the >>>>> situation better: >>>>>=20 >>>>> OLD: >>>>> Due to the security issues presented in Section 5, the latching >>>>> mechanism >>>>> is considered inappropriate for general use on the Internet unless >>>>>all >>>>> security considerations are taken into account and solved. >>>>>=20 >>>>>=20 >>>>> NEW: >>>>> Due to the security issues presented in Section 5, the latching >>>>> mechanism >>>>> is considered inappropriate for general use on the Internet, and in >>>>> controlled environments unless all security considerations are taken >>>>> into >>>>> account and solved. >>>>=20 >>>> "General use on the Internet" and "in controlled environments" are >>>>100% >>>> of all networks, so perhaps simplifying to: >>>>=20 >>>> NEW: >>>> Due to the security issues presented in Section 5, the latching >>>> mechanism >>>> is considered appropriate only when all security considerations are >>>> taken into >>>> account and solved. >>>=20 >>> I think the text in the -04 is preferable to this, as it is more >>>specific. >>>=20 >>> I would be interested in others' thoughts on the text I proposed above. >> >>Could we at least eliminate the double negatives ("inappropriate ... >>unless")? > >In principle, yes, but it seems much easier to enumerate the situations >where it's inappropriate than where it's appropriate -- I'm finding it >difficult to think of better phrasing. > >Alissa > >> >>-d >> >> >>>=20 >>> Thanks, >>> Alissa >>>=20 >>>=20 >> > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Apr 15 16:32:05 2014 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 E616B1A000B for ; Tue, 15 Apr 2014 16:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 DEa9nqX82aXJ for ; Tue, 15 Apr 2014 16:31:58 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id C270B1A0002 for ; Tue, 15 Apr 2014 16:31:58 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta12.emeryville.ca.mail.comcast.net with comcast id qLDH1n0030QkzPw01PXwkR; Tue, 15 Apr 2014 23:31:56 +0000 Received: from mail-yk0-f176.google.com ([209.85.160.176]) by omta02.emeryville.ca.mail.comcast.net with comcast id qPVv1n00K3oeyFl8NPVvvP; Tue, 15 Apr 2014 23:29:56 +0000 Received: by mail-yk0-f176.google.com with SMTP id 19so9418383ykq.7 for ; Tue, 15 Apr 2014 16:29:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.42.43 with SMTP id i31mr7088962yhb.31.1397604595320; Tue, 15 Apr 2014 16:29:55 -0700 (PDT) Received: by 10.170.216.213 with HTTP; Tue, 15 Apr 2014 16:29:55 -0700 (PDT) In-Reply-To: References: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> Date: Tue, 15 Apr 2014 17:29:55 -0600 Message-ID: From: Kevin Gross To: Alissa Cooper Content-Type: multipart/alternative; boundary=20cf3010e5b171f5bf04f71d2d93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397604716; bh=Iz3WxIzTybm0ilUD24o3L+Wx+WBSvlL5vVC413V3o9U=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=kVUk6gzt5F2UaToXp/kac/Qm6Imx/plpfbckR3YeR9gzva6vgLCwSStg80P5OFTYf 8Z5leVi/yKRp+AJOUkpiOUBM5oaEOWwOxSS2oV+0CuHKPR8UJWmHpxWhJqANb033dk 2Zn4QpD6AbC7xXWEzMXyZYry2b5ZSNJWbEX2HbwF+4hNkyOJYYXsM8PnuvmKcbPqjB EihEYFz27SzZDo35WohcTJ/+OJJxUdncN/O2+WbZvaberzz+nkvctVQ8rhs5Ui236F pHiLAVxlCxsmJV5pUf4oZrZwuqL2n5qPVFCS9+J+5SAL86DwP73TmuryCxQrrm6HHy yo5y93bHIc59Q== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ahaOmjYFBvI-yCRRBUI1Qo9j2mI Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic , Dan Wing Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 15 Apr 2014 23:32:03 -0000 --20cf3010e5b171f5bf04f71d2d93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As fresh eyes on this, I'm having trouble understanding what NEW is trying to say. Seems like the union of Internet and controlled environments is everything. How about just saying: Due to the security issues presented in Section 5, the latching mechanism is not recommended unless all security considerations are taken into account and solved. Also, if you're going to change this in section 1, you'll also want to change the treatment of the same subject in the last paragraph of the abstract. Also, although there's a brief definition of "latching" in the abstract, there's no mention of "latching" in section 1 until the paragraph under discussion. It would be helpful to add better context for "latching" in section 1. Kevin Gross - AVA Networks On Tue, Apr 15, 2014 at 5:03 PM, Alissa Cooper wrote: > I=E2=80=99d like to close out this thread. Are folks on board with this p= roposed > change to Section 1? > > OLD: > Due to the security issues presented in Section 5, the latching mechanism > is considered inappropriate for general use on the Internet unless all > security considerations are taken into account and solved. > > NEW: > Due to the security issues presented in Section 5, the latching mechanism > is considered inappropriate for general use on the Internet, and in > controlled environments unless all security considerations are taken into > account and solved. > > > Thanks, > Alissa > > On 4/3/14, 11:19 AM, "Alissa Cooper" wrote: > > >On 4/3/14 10:39 AM, "Dan Wing" wrote: > > > >> > >>On Apr 3, 2014, at 10:28 AM, Alissa Cooper wrote: > >> > >>> Hi Dan, > >>> > >>> On 4/1/14 11:42 AM, "Dan Wing" wrote: > >>>> > >>>>>> The draft suggests use of SRTP for authenticating media which does > >>>>>> resolve the security issues (from a privacy/confidentiality > >>>>>> perspective). > >>>>>> > >>>>> > >>>>> I was more concerned with the DoS aspect. > > > >In response to Emil's note above about the SRTP text resolving the > >security issues "from a privacy/confidentiality perspective," all I was > >saying was that my initial question was prompted not because I was > >concerned about a breach of confidentiality, but about the ability to > >perform a DoS attack even when SRTP is in use. I think the text in Secti= on > >5 that describes this is ok though. > > > >>>> > >>>> The DoS aspect of authenticating incoming SRTP packets to the SBC? > >>> > >>> The DoS aspect that is described in the paragraph Emil quoted below. > >>> > >>>> > >>>> > >>>>> > >>>>>> That's part of section 5: > >>>>>> > >>>>>> Naturally, SRTP [RFC3711] would help mitigate such threats and > >>>>>>should > >>>>>> be used independently of HNT. For example, in cases where > >>>>>>end-to-end > >>>>>> encryption is used it would still be possible for an attacker to > >>>>>> hijack a session despite the use of SRTP and perform a denial of > >>>>>> service attack. However, media integrity would not be compromised= . > >>>>>> > >> > >>Sorry, I read it again and I'm still not clear on the concern. Could y= ou > >>restate or rephrase. > >> > >> > >>> > >>>>> I think something like the following might capture the > >>>>> situation better: > >>>>> > >>>>> OLD: > >>>>> Due to the security issues presented in Section 5, the latching > >>>>> mechanism > >>>>> is considered inappropriate for general use on the Internet unless > >>>>>all > >>>>> security considerations are taken into account and solved. > >>>>> > >>>>> > >>>>> NEW: > >>>>> Due to the security issues presented in Section 5, the latching > >>>>> mechanism > >>>>> is considered inappropriate for general use on the Internet, and in > >>>>> controlled environments unless all security considerations are take= n > >>>>> into > >>>>> account and solved. > >>>> > >>>> "General use on the Internet" and "in controlled environments" are > >>>>100% > >>>> of all networks, so perhaps simplifying to: > >>>> > >>>> NEW: > >>>> Due to the security issues presented in Section 5, the latching > >>>> mechanism > >>>> is considered appropriate only when all security considerations are > >>>> taken into > >>>> account and solved. > >>> > >>> I think the text in the -04 is preferable to this, as it is more > >>>specific. > >>> > >>> I would be interested in others' thoughts on the text I proposed abov= e. > >> > >>Could we at least eliminate the double negatives ("inappropriate ... > >>unless")? > > > >In principle, yes, but it seems much easier to enumerate the situations > >where it's inappropriate than where it's appropriate -- I'm finding it > >difficult to think of better phrasing. > > > >Alissa > > > >> > >>-d > >> > >> > >>> > >>> Thanks, > >>> Alissa > >>> > >>> > >> > > > > > >_______________________________________________ > >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 > --20cf3010e5b171f5bf04f71d2d93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As fresh eyes on this, I'm having trouble understandin= g what NEW is trying to say. Seems like the union of Internet and controlle= d environments is everything. How about just saying:

Due to the security issues presented in Section 5, the latching me= chanism
is not recommended=C2=A0unless all = security considerations are taken into
account and solved.

Also, if you're goin= g to change this in section 1, you'll also want to change the treatment= of the same subject in the last paragraph of the abstract.

Also, = although there's a brief definition of "latching" in the abst= ract, there's no mention of "latching" in section 1 until the= paragraph under discussion. It would be helpful to add better context for = "latching" in section 1.

Ke= vin Gross - AVA Networks


On Tue, Apr 15, 2014 at 5:03 PM, Alissa = Cooper <alissa@cooperw.in> wrote:
I=E2=80=99d like to close out this thread. Are folks on board with this pro= posed
change to Section 1?

OLD:
Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet unless all
security considerations are taken into account and solved.

NEW:
Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet, and in
controlled environments unless all security considerations are taken into account and solved.


Thanks,
Alissa

On 4/3/14, 11:19 AM, "Alissa Cooper" <alissa@cooperw.in> wrote:

>On 4/3/14 10:39 AM, "Dan Wing" <dwing@cisco.com> wrote:
>
>>
>>On Apr 3, 2014, at 10:28 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>>
>>> Hi Dan,
>>>
>>> On 4/1/14 11:42 AM, "Dan Wing" <dwing@cisco.com> wrote:
>>>>
>>>>>> The draft suggests use of SRTP for authenticating = media which does
>>>>>> resolve the security issues (from a privacy/confid= entiality
>>>>>> perspective).
>>>>>>
>>>>>
>>>>> I was more concerned with the DoS aspect.
>
>In response to Emil's note above about the SRTP text resolving the<= br> >security issues "from a privacy/confidentiality perspective,"= all I was
>saying was that my initial question was prompted not because I was
>concerned about a breach of confidentiality, but about the ability to >perform a DoS attack even when SRTP is in use. I think the text in Sect= ion
>5 that describes this is ok though.
>
>>>>
>>>> The DoS aspect of authenticating incoming SRTP packets to = the SBC?
>>>
>>> The DoS aspect that is described in the paragraph Emil quoted = below.
>>>
>>>>
>>>>
>>>>>
>>>>>> That's part of section 5:
>>>>>>
>>>>>> Naturally, SRTP [RFC3711] would help mitigate such= threats and
>>>>>>should
>>>>>> be used independently of HNT. =C2=A0For example, i= n cases where
>>>>>>end-to-end
>>>>>> encryption is used it would still be possible for = an attacker to
>>>>>> hijack a session despite the use of SRTP and perfo= rm a denial of
>>>>>> service attack. =C2=A0However, media integrity wou= ld not be compromised.
>>>>>>
>>
>>Sorry, I read it again and I'm still not clear on the concern. = =C2=A0Could you
>>restate or rephrase.
>>
>>
>>>
>>>>> I think something like the following might capture the=
>>>>> situation better:
>>>>>
>>>>> OLD:
>>>>> Due to the security issues presented in Section 5, the= latching
>>>>> mechanism
>>>>> is considered inappropriate for general use on the Int= ernet unless
>>>>>all
>>>>> security considerations are taken into account and sol= ved.
>>>>>
>>>>>
>>>>> NEW:
>>>>> Due to the security issues presented in Section 5, the= latching
>>>>> mechanism
>>>>> is considered inappropriate for general use on the Int= ernet, and in
>>>>> controlled environments unless all security considerat= ions are taken
>>>>> into
>>>>> account and solved.
>>>>
>>>> "General use on the Internet" and "in contr= olled environments" are
>>>>100%
>>>> of all networks, so perhaps simplifying to:
>>>>
>>>> NEW:
>>>> Due to the security issues presented in Section 5, the lat= ching
>>>> mechanism
>>>> is considered appropriate only when all security considera= tions are
>>>> taken into
>>>> account and solved.
>>>
>>> I think the text in the -04 is preferable to this, as it is mo= re
>>>specific.
>>>
>>> I would be interested in others' thoughts on the text I pr= oposed above.
>>
>>Could we at least eliminate the double negatives ("inappropria= te ...
>>unless")?
>
>In principle, yes, but it seems much easier to enumerate the situations=
>where it's inappropriate than where it's appropriate -- I'm= finding it
>difficult to think of better phrasing.
>
>Alissa
>
>>
>>-d
>>
>>
>>>
>>> Thanks,
>>> Alissa
>>>
>>>
>>
>
>
>_______________________________________________
>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

--20cf3010e5b171f5bf04f71d2d93-- From nobody Wed Apr 16 11:57:08 2014 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 1B17A1A02B7; Wed, 16 Apr 2014 11:56:57 -0700 (PDT) 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 ip-MXW1hVDzr; Wed, 16 Apr 2014 11:56:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ACC1A02AF; Wed, 16 Apr 2014 11:56:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416185654.9919.92712.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 11:56:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XaYvk6-Frhwm_4u1xiu4F5A-ru4 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-07.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: Wed, 16 Apr 2014 18:56:57 -0000 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 : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) Authors : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-07.txt Pages : 23 Date : 2014-04-16 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-07 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 nobody Wed Apr 16 12:20:09 2014 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 1CE231A02B4 for ; Wed, 16 Apr 2014 12:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, 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 26jMEjX-G8f4 for ; Wed, 16 Apr 2014 12:20:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (unknown [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4023C1A02D4 for ; Wed, 16 Apr 2014 12:20:03 -0700 (PDT) X-AuditID: c1b4fb25-f798a6d000005ede-47-534ed7de97c5 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9D.A0.24286.ED7DE435; Wed, 16 Apr 2014 21:19:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Wed, 16 Apr 2014 21:19:58 +0200 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-even-mmusic-application-token-03.txt Thread-Index: AQHPVaN5WvGalTaPX0i13vmV4oIK3ZsMn3HrgAgEirA= Date: Wed, 16 Apr 2014 19:19:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje79637BBns2cFtMXf6YxeJJyw9m ByaPJUt+Mnns2PyANYApissmJTUnsyy1SN8ugSvjz6ab7AVzJSq+dS9namDcL9zFyMkhIWAi sXjnIhYIW0ziwr31bF2MXBxCAkcZJeav2MoI4SxhlLj66SlzFyMHB5uAhUT3P22QBhGBIInm WUcYQWxhgTCJkw93s0DEwyWmLzzGDGFbSaz5eoMVxGYRUJU4s7OXDcTmFfCVuHpmGjvE/F5G iWM/VzKBJDiBmrc+/ckOYjMCXfT91BqwOLOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW0li 0e3PUPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqc lJtuZKyXWpSZXFycn6eXl1qyiREYKQe3/FbdwXj5jeMhRgEORiUeXjY1v2Ah1sSy4srcQ4zS HCxK4rxfbvkECwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBs7jGuFTmQ8er9dKZVKu9lqnZI C81+7RnJr6fp33aKO20Ft3fDdR9P7Tnu5RMnc/+T+XVn7cJZB7dqVxfND3TS41z7t3Dee1O7 so3GB3+s3V02qa5iQry6qN5k3f/m6qF12+5ukWg+9iO7ZtOsyY/5L93tSHzwb+qRV0/eBuqF bmotO1BQa2+pxFKckWioxVxUnAgAUrHXfXUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BOIpjVKm7IOqapawXXWklIbhUxw Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt 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, 16 Apr 2014 19:20:07 -0000 Hi, A few comments. First, it is a little difficult for me to process the changes from the prev= ious version. I am not sure what "token without semantics" mean. My underst= anding from London was that this draft was only going to define recv-appId,= and the other stuff was going to be defined in a separate draft, but maybe= I misunderstood. Second, the draft defines BUNDLE procedures. I think those shall be defined= in BUNDLE. Third, the draft says that the appId token MUST be used with BUNDLE. Howeve= r, what BUNDLE currently needs is the recv-appId mechanism. Have we decided= to mandate usage of appId with BUNDLE? Fourth, the draft will need quite a bit of editorial work :) Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roni Even Sent: 11 April 2014 19:47 To: mmusic@ietf.org Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-applic= ation-token-03.txt Hi , Based on the mailing list and London discussion this new version limited th= e scope of the token to be just a token with no semantics that can be used= as appId or recv-appId Roni ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, April 11, 2014 7:31 PM To: Jonathan Lennox; Roni Even; Qin Wu; Roni Even; Jonathan Lennox; Qin Wu Subject: New Version Notification for draft-even-mmusic-application-token-0= 3.txt A new version of I-D, draft-even-mmusic-application-token-03.txt has been successfully submitted by Roni Even and posted to the IETF reposit= ory. Name: draft-even-mmusic-application-token Revision: 03 Title: The Session Description Protocol (SDP) Application Token At= tribute Document date: 2014-04-11 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-even-mmusic-appli= cation-token-03.txt Status: https://datatracker.ietf.org/doc/draft-even-mmusic-applicat= ion-token/ Htmlized: http://tools.ietf.org/html/draft-even-mmusic-application-to= ken-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-mmusic-applic= ation-token-03 Abstract: The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how to de-multiplex streams within an RTP session, but in some use cases applications need further identifiers in order to identify the signaling descriptions associated with particular RTP media streams. This document defines a mechanism to provide the mapping between the SSRCs of RTP streams and the SDP m-line description by defining extensions to RTP and RTCP messages. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Apr 16 15:11:32 2014 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 6557F1A0332 for ; Wed, 16 Apr 2014 15:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 RqAdXal9OEvJ for ; Wed, 16 Apr 2014 15:11:23 -0700 (PDT) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id 752B01A02B7 for ; Wed, 16 Apr 2014 15:11:23 -0700 (PDT) Received: from BLU181-W18 ([65.55.116.74]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Apr 2014 15:11:20 -0700 X-TMN: [NT9uUO4tq9DZjffiSww3WtVD+uYCOg7jUyLd1ZA2tkk=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_49bf16cc-d760-4490-8836-10d81f1bc0b3_" From: Bernard Aboba To: Christer Holmberg , "mmusic@ietf.org" Date: Wed, 16 Apr 2014 15:11:19 -0700 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com>, <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com>, <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2014 22:11:20.0128 (UTC) FILETIME=[CB96BC00:01CF59C0] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/i4WOc9rkYqeW_bvmR4CcQT2R3f0 Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt 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, 16 Apr 2014 22:11:29 -0000 --_49bf16cc-d760-4490-8836-10d81f1bc0b3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer Holmberg said: "I am not sure what "token without semantics" mean." [BA] In this case=2C I think it means: "there actually are semantics=2C bu= t we're not going to tell you what they are" :) For example=2C when an appId is included in an RTP packet with a given SSRC= =2C and the appId is matched within the SDP=2C that RTP stream continues to= be processed as if contained the appId=2C even when the appId is no longer= present in the RTP packets.=20 There are corner cases that can arise as a result of this=2C such as: 1. RTP packet 1 arrives with appId=3D"foo" and SSRC=3D1. 2. RTP packet 2 ar= rives with appId=3D"bar" and SSRC=3D1.3. RTP packet 3 arrives with no appId= and SSRC=3D1. Is it processed as though it contained "foo" or "bar"? Inq= uiring minds want to know :) = --_49bf16cc-d760-4490-8836-10d81f1bc0b3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christer Holmberg said:

=
"I am not sure what "token without semantics" mean."

[B= A] In this case=2C I think it means:  =3B"there actually are semantics= =2C but we're not going to tell you what they are" :)

For example=2C when an= appId is included in an RTP packet with a given SSRC=2C and the appId is m= atched within the SDP=2C that RTP stream continues to be processed as if co= ntained the appId=2C even when the appId is no longer present in the RTP pa= ckets. =3B

There are corner cases that can ari= se as a result of this=2C such as:

1. RTP packet 1= arrives with appId=3D"foo" and SSRC=3D1. =3B
2. RTP packet 2= arrives with appId=3D"bar" and SSRC=3D1.
3. RTP packet 3 arrives= with no appId and SSRC=3D1.  =3BIs it processed as though it contained= "foo" or "bar"?  =3BInquiring minds want to know :)


= --_49bf16cc-d760-4490-8836-10d81f1bc0b3_-- From nobody Thu Apr 17 02:43:57 2014 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 EFF471A02EF for ; Thu, 17 Apr 2014 02:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=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 cEqF_9XgaDfB for ; Thu, 17 Apr 2014 02:43:53 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A24251A02EB for ; Thu, 17 Apr 2014 02:43:52 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so440308eek.3 for ; Thu, 17 Apr 2014 02:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=vs0ixwc+2As6IPZMpBdI7pYTANhpj0M6vEo6LBC2pEw=; b=w6aHR7/qDGGu1BY9/cmeQg4hzttcV89lIZ90CZJy/+Lr95KONzOm1kL1uT1xrGd+nL 8iuJ7OQ8swtRnoTFwiqfiP91LnRskWQitgzverbz2VUaIdHVOa8McGjtK3Vredi09+ct MIY0WaaJlYGcWmFMLM5GGCM70q3Ogt9zWSGCd6ttxA8IgCOt5C18rlz+v9/PdOIKWO+h bdOAXMUHZr/+a8enw6RE88UFoRxs0KVtC9DKZyrClNNut+Qo3bF9BidIZt3i2/AkmrAt SHP7eK6PSiqhYVoS0xVfyiFPH+KoGkzCeWFaA2FV/tn9dOjvaNtJPzoEiaIwfjO9lFda zwow== X-Received: by 10.15.54.137 with SMTP id t9mr12709634eew.39.1397727828317; Thu, 17 Apr 2014 02:43:48 -0700 (PDT) Received: from RoniE ([109.67.104.144]) by mx.google.com with ESMTPSA id q41sm65784811eez.7.2014.04.17.02.43.46 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Apr 2014 02:43:47 -0700 (PDT) From: "Roni Even" To: "'Bernard Aboba'" , "'Christer Holmberg'" , References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com>, <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com>, <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> In-Reply-To: Date: Thu, 17 Apr 2014 12:43:44 +0300 Message-ID: <011201cf5a21$8767a150$9636e3f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0113_01CF5A3A.ACB5EAC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJRAFfkqM1fI1f2qLRSksXTeQ65KwIePylaAss0OIwCQtJr6ZnY2fAg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UX631WjE1UnyFE6gxwWW97ARGL8 Cc: 'Jonathan Lennox' Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt 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, 17 Apr 2014 09:43:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0113_01CF5A3A.ACB5EAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, By no semantics we meant that it is just a token with no parameters that maps the RTP stream (packet stream) to a description in the SDP m-line. (we agreed to take out the SSRC like functionality and have it at the end of the document as issues that we may want to address for simulcast for example) It addressed the cases described by Christer where the RTP arrives before the SDP answer but also on the send direction for cases where the offerer does not know the SSRC that will be used (see for example of the three camera case bellow) As for 1. RTP packet 1 arrives with appId="foo" and SSRC=1. 2. RTP packet 2 arrives with appId="bar" and SSRC=1. 3. RTP packet 3 arrives with no appId and SSRC=1. Is it processed as though it contained "foo" or "bar"? Inquiring minds want to know :) In this case the last appId is valid so SSRC=1 is mapped appId="bar". I think we missed this case in section 3.1 (the first bullet is about having a new SSRC mapped to an existing appID which may happen for example when we describe three m-lines each for one of three cameras using the same PT number and a fourth m-line describing the active speaker with an appId. So if the answerer only wants to receive the steam from the fourth m-line the appId will map to a different SSRC with each speaker switch. This is an example use case for the appId in the offer) Roni From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 17 April, 2014 1:11 AM To: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt Christer Holmberg said: "I am not sure what "token without semantics" mean." [BA] In this case, I think it means: "there actually are semantics, but we're not going to tell you what they are" :) For example, when an appId is included in an RTP packet with a given SSRC, and the appId is matched within the SDP, that RTP stream continues to be processed as if contained the appId, even when the appId is no longer present in the RTP packets. There are corner cases that can arise as a result of this, such as: 1. RTP packet 1 arrives with appId="foo" and SSRC=1. 2. RTP packet 2 arrives with appId="bar" and SSRC=1. 3. RTP packet 3 arrives with no appId and SSRC=1. Is it processed as though it contained "foo" or "bar"? Inquiring minds want to know :) ------=_NextPart_000_0113_01CF5A3A.ACB5EAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

By no semantics we meant that it is just a token with no parameters = that maps the RTP stream (packet stream) to a description in the SDP = m-line. (we agreed to take out the SSRC like functionality and have it = at the end of the document as issues that we may want to address for = simulcast for example)

It addressed the cases described by Christer where the RTP arrives = before the SDP answer but also on the send direction for cases where the = offerer does not know the SSRC that will be used (see for example of the = three camera case bellow)

 

As for

1. RTP packet 1 arrives = with appId=3D"foo" and SSRC=3D1. 

2. = RTP packet 2 arrives with appId=3D"bar" and = SSRC=3D1.

3. RTP packet 3 arrives = with no appId and SSRC=3D1.  Is it processed as though it contained = "foo" or "bar"?  Inquiring minds want to know = :)

 

In this case the last appId is valid  so SSRC=3D1 is mapped = appId=3D”bar”. I think we missed this case in section 3.1 = (the first bullet is about having a new SSRC mapped to an existing appID = which may happen for example when we describe three m-lines each for one = of  three cameras using the same PT number and a fourth m-line = describing the active speaker with an appId. So if the answerer only = wants to receive the steam from the fourth m-line the appId will map to = a different SSRC with each speaker switch. This is an example use case = for the appId in the offer)

 

Roni

 

From:= = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard = Aboba
Sent: 17 April, 2014 1:11 AM
To: Christer = Holmberg; mmusic@ietf.org
Subject: Re: [MMUSIC] New Version = Notification for = draft-even-mmusic-application-token-03.txt

 

Christer Holmberg = said:

 

=

"I am not sure what "token without = semantics" mean."

=

 

=

[BA] In this case, I think it means:  "there actually are = semantics, but we're not going to tell you what they are" = :)

=

 

=

For example, when an appId = is included in an RTP packet with a given SSRC, and the appId is matched = within the SDP, that RTP stream continues to be processed as if = contained the appId, even when the appId is no longer present in the RTP = packets. 

 

=

There are corner cases that = can arise as a result of this, such = as:

 

=

1. RTP packet 1 arrives = with appId=3D"foo" and = SSRC=3D1. 

2. = RTP packet 2 arrives with appId=3D"bar" and = SSRC=3D1.

3. RTP packet 3 arrives = with no appId and SSRC=3D1.  Is it processed as though it contained = "foo" or "bar"?  Inquiring minds want to know = :)

 

=

 

=
------=_NextPart_000_0113_01CF5A3A.ACB5EAC0-- From nobody Thu Apr 17 03:49:40 2014 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 CA6211A0090 for ; Thu, 17 Apr 2014 03:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, 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 XiC5ApMYvAiX for ; Thu, 17 Apr 2014 03:49:36 -0700 (PDT) Received: from sessmg23.ericsson.net (unknown [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6A1A004A for ; Thu, 17 Apr 2014 03:49:35 -0700 (PDT) X-AuditID: c1b4fb2d-f79fa6d000007cbe-27-534fb1bb7ea9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.EC.31934.BB1BF435; Thu, 17 Apr 2014 12:49:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 12:49:31 +0200 From: Christer Holmberg To: Roni Even , 'Bernard Aboba' , "mmusic@ietf.org" Thread-Topic: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt Thread-Index: AQHPVaN5WvGalTaPX0i13vmV4oIK3ZsMn3HrgAgEirCAABDMgIAAwXYAgAAylrA= Date: Thu, 17 Apr 2014 10:49:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2CD51D@ESESSMB209.ericsson.se> References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com>, <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com>, <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> <011201cf5a21$8767a150$9636e3f0$@gmail.com> In-Reply-To: <011201cf5a21$8767a150$9636e3f0$@gmail.com> 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_7594FB04B1934943A5C02806D1A2204B1D2CD51DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvje7ujf7BBtMemVjsX3KZ2WL/4vPM FlOXP2ax+NvO7MDisXPWXXaPxz1n2DyWLPnJ5NH27A57AEsUl01Kak5mWWqRvl0CV8a6j33s BbcsKnYv7mJtYNxi1MXIySEhYCJxc9UqFghbTOLCvfVsXYxcHEICRxkl3p9dxwThLGGU+PR6 L2sXIwcHm4CFRPc/bZAGEYEqibUPethAbGYBLYn/c6+wg9jCAvESy25OYoSoSZC4uHwOO4Tt J/H92XJmEJtFQFXi/+4NYDavgK/EuxUvmSF2bWSSaJy+AmwoJ9CuOWd/sILYjEDXfT+1hgli mbjErSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtJYsX2S4wQ9fkSnZtfM0IsE5Q4OfMJywRG0VlI Rs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpcnJtuZKyXWpSZXFyc n6eXl1qyiREYlwe3/Nbdwbj6teMhRgEORiUeXjY1v2Ah1sSy4srcQ4zSHCxK4rxtd72DhQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTCm7nneaX/wxt+TR8VFfM+tY+/ZK2FR0eeRkmcy7cY3 AX0po0MGkWsb+63lXna9P3xulkwHK9fZLzZ7lgp7qV4Q+ndq8Y3yeN6cCq2grxOlTq6JNJbq XHT1hKHa7JOfF14015TcFPSz5GmHhH267O7Pn66eeXf57M/AA96OSTx5GpcPiz4Q0tygxFKc kWioxVxUnAgAwBPYDawCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dJ_w2NWd3VJd3UOhLlMpyIXHHAw Cc: 'Jonathan Lennox' Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt 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, 17 Apr 2014 10:49:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2CD51DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >By no semantics we meant that it is just a token with no parameters that m= aps the RTP stream >(packet stream) to a description in the SDP m-line. Well, then that IS the semantics :) > (we agreed to take out the SSRC like functionality and have it at the end= of the document as issues > that we may want to address for simulcast for = example) > It addressed the cases described by Christer where the RTP arrives before= the SDP answer but also > on the send direction for cases where the offere= r does not know the SSRC that will be used (see for > example of the three = camera case bellow) Is there a reason why you don't call the 'appId' attribute 'send-appId' ins= tead? Also, assuming the previous answerer in a subsequent O/A exchange becomes t= he offerer, which attribute (if any) does it include in the Offer? You need= to describe how a change of the Offerer/Answerer roles affect affects the = usage. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2CD51DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>By no = semantics we meant that it is just a token with no parameters that maps the= RTP stream >(packet stream) to a description in the SDP m-line.

 = ;

Well, then= that IS the semantics :)

 = ;

> (we a= greed to take out the SSRC like functionality and have it at the end of the= document as issues > that we may want to address for simulcast for example)

> It ad= dressed the cases described by Christer where the RTP arrives before the SD= P answer but also > on the send direction for cases where the offerer does not know the SSRC that will be used (see for > example of = the three camera case bellow)

 = ;

Is there a= reason why you don’t call the ‘appId’ attribute ‘s= end-appId’ instead?

 = ;

Also, assu= ming the previous answerer in a subsequent O/A exchange becomes the offerer= , which attribute (if any) does it include in the Offer? You need to describe how a change of the Offerer/Answerer roles affect affects= the usage.

 = ;

Regards,

 = ;

Christer

 = ;

--_000_7594FB04B1934943A5C02806D1A2204B1D2CD51DESESSMB209erics_-- From nobody Thu Apr 17 08:25:46 2014 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 E4E021A01C0 for ; Thu, 17 Apr 2014 08:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 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, FRT_BELOW2=2.154, HTML_MESSAGE=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 Vs2_9Qwm0qyx for ; Thu, 17 Apr 2014 08:25:39 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 782041A024F for ; Thu, 17 Apr 2014 08:25:38 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so793568eek.35 for ; Thu, 17 Apr 2014 08:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=nwv9C7ehCWk9BD56zw1YUs26zefELBf0k0grWccPPJo=; b=DMtqGA/gf516uMD0q3UVKyys8GPwmAXqJIqAY0TOnXaGVYTw4Vms02Q4PPgPxolr6O l9ly5jpw2hi/AYuQoOnZZHQpZUf60w6nqkAsMbNirfOauWNjIB1kFukJpcW5nKVrJw88 c4LhPORIKEaVD+svAala13fQ6BpCXGkphplb2RDsFfKFoxgNo/2dJYCMR/2xNqdjGJuK g4cn2Ky0iHfciIvSsP8VbOk+yrytlII6pLOAVoEYN3Kjl8MX4zQE92DuTO6y7BnjZofU lvv2AFvClVWtxkeS5sPr45/cqVIlfLYWFkPDV4R3iWmoNnrAgNXLYHWWAFJKLNBtYvxU xubw== X-Received: by 10.15.75.9 with SMTP id k9mr2764497eey.110.1397748334334; Thu, 17 Apr 2014 08:25:34 -0700 (PDT) Received: from RoniE ([109.67.104.144]) by mx.google.com with ESMTPSA id s46sm68248069ees.3.2014.04.17.08.25.31 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Apr 2014 08:25:33 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Bernard Aboba'" , References: <20140411163112.6591.91881.idtracker@ietfa.amsl.com>, <760B7D45D1EFF74988DBF5C2122830C23E55A79C@szxpml507-mbx.exmail.huawei.com>, <7594FB04B1934943A5C02806D1A2204B1D2CC7BB@ESESSMB209.ericsson.se> <011201cf5a21$8767a150$9636e3f0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D2CD51D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2CD51D@ESESSMB209.ericsson.se> Date: Thu, 17 Apr 2014 18:25:30 +0300 Message-ID: <014301cf5a51$45d2afc0$d1780f40$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01CF5A6A.6B20D220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJRAFfkqM1fI1f2qLRSksXTeQ65KwIePylaAss0OIwCQtJr6QK37sFiASW3dMyZulFkkA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IJAvsIBehPN7Pura-xmvqzDzkhE Cc: 'Jonathan Lennox' Subject: Re: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt 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, 17 Apr 2014 15:25:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0144_01CF5A6A.6B20D220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Inline Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 17 April, 2014 1:50 PM To: Roni Even; 'Bernard Aboba'; mmusic@ietf.org Cc: 'Jonathan Lennox' Subject: RE: [MMUSIC] New Version Notification for draft-even-mmusic-application-token-03.txt Hi, >By no semantics we meant that it is just a token with no parameters that maps the RTP stream >(packet stream) to a description in the SDP m-line. Well, then that IS the semantics :) > (we agreed to take out the SSRC like functionality and have it at the end of the document as issues > that we may want to address for simulcast for example) > It addressed the cases described by Christer where the RTP arrives before the SDP answer but also > on the send direction for cases where the offerer does not know the SSRC that will be used (see for > example of the three camera case bellow) Is there a reason why you don't call the 'appId' attribute 'send-appId' instead? [Roni Even] No reason and we may have a different name for appId, was discussed on the list. We assume appId is sent-appId Also, assuming the previous answerer in a subsequent O/A exchange becomes the offerer, which attribute (if any) does it include in the Offer? You need to describe how a change of the Offerer/Answerer roles affect affects the usage. [Roni Even] The current text talks about having the answer use the recv-appId as the appId. We need to add text about subsequent offer/answer, do we mandate keeping current appId. Other issue we have is if we need to send appId (send-appId) or can only send the recv-appId Regards, Christer ------=_NextPart_000_0144_01CF5A6A.6B20D220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Inline

Roni

 

From:= = Christer Holmberg [mailto:christer.holmberg@ericsson.com] =
Sent: 17 April, 2014 1:50 PM
To: Roni Even; = 'Bernard Aboba'; mmusic@ietf.org
Cc: 'Jonathan = Lennox'
Subject: RE: [MMUSIC] New Version Notification for = draft-even-mmusic-application-token-03.txt

 

Hi,

 

>By no semantics we meant that it is just a token with no = parameters that maps the RTP stream >(packet stream) to a description = in the SDP m-line.

 

Well, then that IS the semantics :)

 

> (we agreed to take out the SSRC like functionality and have it = at the end of the document as issues > that we may want to address = for simulcast for example)

> It addressed the cases described by Christer where the RTP = arrives before the SDP answer but also > on the send direction for = cases where the offerer does not know the SSRC that will be used (see = for > example of the three camera case = bellow)

 

Is there a reason why you don’t call the ‘appId’ = attribute ‘send-appId’ instead?

[Roni Even] No reason and we may have a different name for appId, was = discussed on the list. We assume appId is sent-appId

 

Also, assuming the previous answerer in a subsequent O/A exchange = becomes the offerer, which attribute (if any) does it include in the = Offer? You need to describe how a change of the Offerer/Answerer roles = affect affects the usage.

 

[Roni Even] The current text talks about having the answer use the = recv-appId as the appId.

We need to add text about subsequent offer/answer, do we mandate = keeping current appId.

 

Other issue we have is if we need to send appId (send-appId) or can = only send the recv-appId

 

Regards,

 

Christer

 

------=_NextPart_000_0144_01CF5A6A.6B20D220-- From nobody Fri Apr 18 14:07:16 2014 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 000A21A045C for ; Fri, 18 Apr 2014 14:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 4QAqb827gF3O for ; Fri, 18 Apr 2014 14:07:10 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 349BB1A043E for ; Fri, 18 Apr 2014 14:07:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CB99820FA8 for ; Fri, 18 Apr 2014 17:07:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 18 Apr 2014 17:07:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:cc:message-id:references:in-reply-to :mime-version:content-type; s=mesmtp; bh=88gAbE5odnyKXDd20dyLpNH CY/A=; b=mvIObCKfW684rVS1yQ8ErD7DjXcKq2mXzaT8G56hscxs5rcMTbu1+I6 idjG5Q4WWkUUodRGlzr9+v5NB/03sAnP4xFeKX0EUIiyYfbyGwRMlx2EM1pT3NrT cJJR9vBPvsDyN4KmP7QTorAdH98+7xD1SUVRzLCLZ6zPOItBNSEI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:cc:message-id :references:in-reply-to:mime-version:content-type; s=smtpout; bh=88gAbE5odnyKXDd20dyLpNHCY/A=; b=Yznxk/dfZtB1S2SDrxkLhnPstU8y rCGwQyUYusdmHlCuehsuzhfTNTMuZpxLKdIxxPKHU/+U8+j/d33WFmuzxbT/yflV grU/LiF6AuKEe0PCEhmqWsA+LII5OXykR5VousFayPIrjAa/Pc40Z2oXnTSc2bDJ 5h8vyufqL2634oQ= X-Sasl-enc: xtiZMcUyUoOXLQhLNwdOHdGVBRZqwxBMqU0OKnzG22mb 1397855222 Received: from [171.68.18.132] (unknown [171.68.18.132]) by mail.messagingengine.com (Postfix) with ESMTPA id E9C7EC007AB; Fri, 18 Apr 2014 17:06:58 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 18 Apr 2014 14:06:54 -0700 From: Alissa Cooper To: Kevin Gross Message-ID: Thread-Topic: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 References: <7CB15B3C-4A35-4397-8029-1396722EB2CC@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3480674824_12674869" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-T6RnbPc02cdEzmP7Y8EY4REXmQ Cc: draft-ietf-mmusic-latching@tools.ietf.org, mmusic , Dan Wing Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04 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, 18 Apr 2014 21:07:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3480674824_12674869 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 4/15/14, 4:29 PM, "Kevin Gross" wrote: > As fresh eyes on this, I'm having trouble understanding what NEW is tryin= g to > say. Seems like the union of Internet and controlled environments is > everything. How about just saying: >=20 >> Due to the security issues presented in Section 5, the latching mechanis= m >> is not recommended unless all security considerations are taken into >> account and solved. This is basically the same as what the text currently says, so I think it=E2=80= =99s better to just leave the text as-is and close out this discussion. >>=20 > Also, if you're going to change this in section 1, you'll also want to ch= ange > the treatment of the same subject in the last paragraph of the abstract. >=20 > Also, although there's a brief definition of "latching" in the abstract, > there's no mention of "latching" in section 1 until the paragraph under > discussion. It would be helpful to add better context for "latching" in > section 1. Seems like a reasonable suggestion. Could the authors make a run at that an= d publish a rev that includes the other edits from my AD review? Thanks, Alissa >=20 > Kevin Gross - AVA Networks >=20 >=20 > On Tue, Apr 15, 2014 at 5:03 PM, Alissa Cooper wrote: >> I=E2=80=99d like to close out this thread. Are folks on board with this propos= ed >> change to Section 1? >>=20 >> OLD: >> Due to the security issues presented in Section 5, the latching mechanis= m >> is considered inappropriate for general use on the Internet unless all >> security considerations are taken into account and solved. >>=20 >> NEW: >> Due to the security issues presented in Section 5, the latching mechanis= m >> is considered inappropriate for general use on the Internet, and in >> controlled environments unless all security considerations are taken int= o >> account and solved. >>=20 >>=20 >> Thanks, >> Alissa >>=20 >> On 4/3/14, 11:19 AM, "Alissa Cooper" wrote: >>=20 >>> >On 4/3/14 10:39 AM, "Dan Wing" wrote: >>> > >>>> >> >>>> >>On Apr 3, 2014, at 10:28 AM, Alissa Cooper wrote= : >>>> >> >>>>> >>> Hi Dan, >>>>> >>> >>>>> >>> On 4/1/14 11:42 AM, "Dan Wing" wrote: >>>>>> >>>> >>>>>>>> >>>>>> The draft suggests use of SRTP for authenticating media whi= ch does >>>>>>>> >>>>>> resolve the security issues (from a privacy/confidentiality >>>>>>>> >>>>>> perspective). >>>>>>>> >>>>>> >>>>>>> >>>>> >>>>>>> >>>>> I was more concerned with the DoS aspect. >>> > >>> >In response to Emil's note above about the SRTP text resolving the >>> >security issues "from a privacy/confidentiality perspective," all I wa= s >>> >saying was that my initial question was prompted not because I was >>> >concerned about a breach of confidentiality, but about the ability to >>> >perform a DoS attack even when SRTP is in use. I think the text in Sec= tion >>> >5 that describes this is ok though. >>> > >>>>>> >>>> >>>>>> >>>> The DoS aspect of authenticating incoming SRTP packets to the S= BC? >>>>> >>> >>>>> >>> The DoS aspect that is described in the paragraph Emil quoted bel= ow. >>>>> >>> >>>>>> >>>> >>>>>> >>>> >>>>>>> >>>>> >>>>>>>> >>>>>> That's part of section 5: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Naturally, SRTP [RFC3711] would help mitigate such threats = and >>>>>>>> >>>>>>should >>>>>>>> >>>>>> be used independently of HNT. For example, in cases where >>>>>>>> >>>>>>end-to-end >>>>>>>> >>>>>> encryption is used it would still be possible for an attack= er to >>>>>>>> >>>>>> hijack a session despite the use of SRTP and perform a deni= al of >>>>>>>> >>>>>> service attack. However, media integrity would not be >>>>>>>> compromised. >>>>>>>> >>>>>> >>>> >> >>>> >>Sorry, I read it again and I'm still not clear on the concern. Coul= d you >>>> >>restate or rephrase. >>>> >> >>>> >> >>>>> >>> >>>>>>> >>>>> I think something like the following might capture the >>>>>>> >>>>> situation better: >>>>>>> >>>>> >>>>>>> >>>>> OLD: >>>>>>> >>>>> Due to the security issues presented in Section 5, the latchi= ng >>>>>>> >>>>> mechanism >>>>>>> >>>>> is considered inappropriate for general use on the Internet u= nless >>>>>>> >>>>>all >>>>>>> >>>>> security considerations are taken into account and solved. >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> NEW: >>>>>>> >>>>> Due to the security issues presented in Section 5, the latchi= ng >>>>>>> >>>>> mechanism >>>>>>> >>>>> is considered inappropriate for general use on the Internet, = and in >>>>>>> >>>>> controlled environments unless all security considerations ar= e taken >>>>>>> >>>>> into >>>>>>> >>>>> account and solved. >>>>>> >>>> >>>>>> >>>> "General use on the Internet" and "in controlled environments" = are >>>>>> >>>>100% >>>>>> >>>> of all networks, so perhaps simplifying to: >>>>>> >>>> >>>>>> >>>> NEW: >>>>>> >>>> Due to the security issues presented in Section 5, the latching >>>>>> >>>> mechanism >>>>>> >>>> is considered appropriate only when all security considerations= are >>>>>> >>>> taken into >>>>>> >>>> account and solved. >>>>> >>> >>>>> >>> I think the text in the -04 is preferable to this, as it is more >>>>> >>>specific. >>>>> >>> >>>>> >>> I would be interested in others' thoughts on the text I proposed >>>>> above. >>>> >> >>>> >>Could we at least eliminate the double negatives ("inappropriate ... >>>> >>unless")? >>> > >>> >In principle, yes, but it seems much easier to enumerate the situation= s >>> >where it's inappropriate than where it's appropriate -- I'm finding it >>> >difficult to think of better phrasing. >>> > >>> >Alissa >>> > >>>> >> >>>> >>-d >>>> >> >>>> >> >>>>> >>> >>>>> >>> Thanks, >>>>> >>> Alissa >>>>> >>> >>>>> >>> >>>> >> >>> > >>> > >>> >_______________________________________________ >>> >mmusic mailing list >>> >mmusic@ietf.org >>> >https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 --B_3480674824_12674869 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
On 4/15/14, 4:29 PM, "Kevin G= ross" <kevin.gross@avanw.com&g= t; wrote:

As fresh eyes on this, I'm h= aving trouble understanding what NEW is trying to say. Seems like the union = of Internet and controlled environments is everything. How about just saying= :

Due to the security issues presented in Section 5, the latc= hing mechanism
is not recommended unless all security considerations are taken into
account and solved.

This is basically the same as what the text currently= says, so I think it’s better to just leave the text as-is and close o= ut this discussion.


=
Also, if you're g= oing to change this in section 1, you'll also want to change the treatment o= f the same subject in the last paragraph of the abstract.

Also, although there's a brief definition of = "latching" in the abstract, there's no mention of "latching" in section 1 un= til the paragraph under discussion. It would be helpful to add better contex= t for "latching" in section 1.
Seems like a reasonable suggestion. Could the authors make a ru= n at that and publish a rev that includes the other edits from my AD review?=

Thanks,
Alissa


Kevin Gross - AVA= Networks


On Tue, Apr 15, 2014 a= t 5:03 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I’d like to close out this thread. Are folks on board with this propo= sed
change to Section 1?

OLD:
Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet unless all
security considerations are taken into account and solved.

NEW:
Due to the security issues presented in Section 5, the latching mechanism is considered inappropriate for general use on the Internet, and in
controlled environments unless all security considerations are taken into account and solved.


Thanks,
Alissa

On 4/3/14, 11:19 AM, "Alissa Cooper" <alissa@cooperw.in> wrote:

>On 4/3/14 10:39 AM, "Dan Wing" <dwi= ng@cisco.com> wrote:
>
>>
>>On Apr 3, 2014, at 10:28 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>>
>>> Hi Dan,
>>>
>>> On 4/1/14 11:42 AM, "Dan Wing" <dwing@cisco.com> wrote:
>>>>
>>>>>> The draft suggests use of SRTP for authenticating = media which does
>>>>>> resolve the security issues (from a privacy/confid= entiality
>>>>>> perspective).
>>>>>>
>>>>>
>>>>> I was more concerned with the DoS aspect.
>
>In response to Emil's note above about the SRTP text resolving the
>security issues "from a privacy/confidentiality perspective," all I was=
>saying was that my initial question was prompted not because I was
>concerned about a breach of confidentiality, but about the ability to >perform a DoS attack even when SRTP is in use. I think the text in Sect= ion
>5 that describes this is ok though.
>
>>>>
>>>> The DoS aspect of authenticating incoming SRTP packets to = the SBC?
>>>
>>> The DoS aspect that is described in the paragraph Emil quoted = below.
>>>
>>>>
>>>>
>>>>>
>>>>>> That's part of section 5:
>>>>>>
>>>>>> Naturally, SRTP [RFC3711] would help mitigate such= threats and
>>>>>>should
>>>>>> be used independently of HNT.  For example, i= n cases where
>>>>>>end-to-end
>>>>>> encryption is used it would still be possible for = an attacker to
>>>>>> hijack a session despite the use of SRTP and perfo= rm a denial of
>>>>>> service attack.  However, media integrity wou= ld not be compromised.
>>>>>>
>>
>>Sorry, I read it again and I'm still not clear on the concern. &nbs= p;Could you
>>restate or rephrase.
>>
>>
>>>
>>>>> I think something like the following might capture the=
>>>>> situation better:
>>>>>
>>>>> OLD:
>>>>> Due to the security issues presented in Section 5, the= latching
>>>>> mechanism
>>>>> is considered inappropriate for general use on the Int= ernet unless
>>>>>all
>>>>> security considerations are taken into account and sol= ved.
>>>>>
>>>>>
>>>>> NEW:
>>>>> Due to the security issues presented in Section 5, the= latching
>>>>> mechanism
>>>>> is considered inappropriate for general use on the Int= ernet, and in
>>>>> controlled environments unless all security considerat= ions are taken
>>>>> into
>>>>> account and solved.
>>>>
>>>> "General use on the Internet" and "in controlled environme= nts" are
>>>>100%
>>>> of all networks, so perhaps simplifying to:
>>>>
>>>> NEW:
>>>> Due to the security issues presented in Section 5, the lat= ching
>>>> mechanism
>>>> is considered appropriate only when all security considera= tions are
>>>> taken into
>>>> account and solved.
>>>
>>> I think the text in the -04 is preferable to this, as it is mo= re
>>>specific.
>>>
>>> I would be interested in others' thoughts on the text I propos= ed above.
>>
>>Could we at least eliminate the double negatives ("inappropriate ..= .
>>unless")?
>
>In principle, yes, but it seems much easier to enumerate the situations=
>where it's inappropriate than where it's appropriate -- I'm finding it<= br> >difficult to think of better phrasing.
>
>Alissa
>
>>
>>-d
>>
>>
>>>
>>> Thanks,
>>> Alissa
>>>
>>>
>>
>
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>= https://www.ietf.org/mailman/listinfo/mmusic


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

--B_3480674824_12674869-- From nobody Wed Apr 23 02:52:27 2014 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 978261A0176; Wed, 23 Apr 2014 02:52:25 -0700 (PDT) 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 pUlW9NNqPmig; Wed, 23 Apr 2014 02:52:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F31A0109; Wed, 23 Apr 2014 02:52:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423095224.23059.43664.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 02:52:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xtTyjYo6eV5nbVuzVCzcHCzuUjA Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-07.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: Wed, 23 Apr 2014 09:52:25 -0000 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 : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-07.txt Pages : 39 Date : 2014-04-23 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m=" lines). This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264, in order to allow an answerer to in an SDP answer assign a non- zero port value to an "m=" line, even if the offerer in the associated SDP offer had assigned a zero port value to the "m=" line. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-07 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 nobody Wed Apr 23 02:55:01 2014 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 2D5C71A0175 for ; Wed, 23 Apr 2014 02:54:59 -0700 (PDT) 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, HTML_MESSAGE=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 DdgyH5w6HWmB for ; Wed, 23 Apr 2014 02:54:57 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 46D0B1A004E for ; Wed, 23 Apr 2014 02:54:57 -0700 (PDT) X-AuditID: c1b4fb3a-f79156d000001144-c7-53578dea4a5b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9A.CF.04420.AED87535; Wed, 23 Apr 2014 11:54:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Wed, 23 Apr 2014 11:54:50 +0200 From: Christer Holmberg To: "mmusic (E-mail)" Thread-Topic: Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-07 Thread-Index: Ac9e2dIVt/AoJ6LVTqW4g1LmVq492A== Date: Wed, 23 Apr 2014 09:54:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2D6DC3@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2D6DC3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6r3vBgg+UrTS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL+tE9gKXkhVTPn7h7WB8aZ4FyMnh4SAicSlzqeMELaYxIV7 69m6GLk4hASOMkpMf/SeHSQhJLCEUeLvNP0uRg4ONgELie5/2iBhEQF1idbNfawgtrCAu8Sa Aw8YIeI+EkufTYOy9STOTb8JVsMioCrx+dxcMJtXwFdi5e8bzCA2I9De76fWMIHYzALiEree zGeCuEdAYsme88wQtqjEy8f/WCFsRYn2pw2MEPX5EnMW32aGmCkocXLmE5YJjEKzkIyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg33chIL7UoM7m4OD9PLy+1 ZBMjMCIObvlttYPx4HPHQ4wCHIxKPLxsan7BQqyJZcWVuYcYpTlYlMR5Jy1yDxYSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAGPOm695Nq6kxkVvKZbY8nql1/vXsGKMlJgY2Wg+OTOm78Gx5 zcO9R9/8nyq4N3hlS5nJxI161vduMk5plC6Z/LJlklOe4De23WoywduERGfvWFC6Wjh2peCG Ooa42xuPP8gL+8qx74TTpY3T+eebxWR+mfJg4f1dHb/X2Yj+OGogJvLUWWDtmQYlluKMREMt 5qLiRAAMHqMjaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1MV5_QjmTjErHySbYTC3aNfpWDY Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-07 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, 23 Apr 2014 09:54:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2D6DC3ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of BUNDLE, with some fixes based on the commen= ts given on the -06 version. The biggest change is the removal of text talking about multiple RTP sessio= ns within a BUNDLE group. Note that the title of the document has been clarified, and is now: "Negotiating Media Multiplexing Using the Session Description Protocol (SDP= )" Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2D6DC3ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of BUNDLE, with s= ome fixes based on the comments given on the -06 version.

 

The biggest change is the removal of text talking ab= out multiple RTP sessions within a BUNDLE group.

 

Note that the title of the document has been clarifi= ed, and is now:

 

“Negotiating Medi= a Multiplexing Using the Session Description Protocol (SDP)”

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D2D6DC3ESESSMB209erics_-- From nobody Wed Apr 23 03:45:27 2014 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 488361A01D1 for ; Wed, 23 Apr 2014 03:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GsGMVEOgYpWk for ; Wed, 23 Apr 2014 03:45:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1576F1A014E for ; Wed, 23 Apr 2014 03:45:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79b16d00000734d-d9-535799bc47fd Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.A5.29517.CB997535; Wed, 23 Apr 2014 12:45:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Wed, 23 Apr 2014 12:45:16 +0200 From: Christer Holmberg To: "mmusic (E-mail)" Thread-Topic: SDP directorate review of draft-ietf-xrblock-rtcp-xr-psi-decodability-02 Thread-Index: Ac9e34bT8uRPa5C7TbaBxzCYiGKRmQ== Date: Wed, 23 Apr 2014 10:45:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2D70A8@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2D70A8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje6emeHBBh9n6FvseV5sMXX5YxYH Jo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2Ne1272ghmyFUve9jA1MB6X7GLk5JAQMJH4 tnYhI4QtJnHh3nq2LkYuDiGBo4wSbS+PMIEkhASWMEr0Pk7pYuTgYBOwkOj+pw0SFhFQl2jd 3McKYjML1Eu8+tbOAmILCwRLtL++xQhSLiIQIXH7ahZEuZ7Em0vXmEFsFgFViUeX14O18gr4 Ssz8PQUszgh0wvdTa5ggRopL3HoynwniNAGJJXvOM0PYohIvH/9jhbAVJdqfNjBC1OdLbN0z hxlipqDEyZlPWCYwCs9CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR 4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAyDm45bfuDsbVrx0PMQpwMCrx8LKp+QULsSaWFVfm HmKU5mBREudtu+sdLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx/vLru9aX1TCGbrHetnDJ ATMhJQehynTFoBqObolvK2cLi1dX7Zv4zuhwe9ekfuUtcj7mGo1tLntLih63v+hWK0m96NTT ZVO48trUI2HbTdcLxhUlNOprrODJfLu8gDNbY4vNtQCJj2Gvlfs59q42Wbs258ZyT+blJyS7 /jofctxssOpCGrcSS3FGoqEWc1FxIgCPJ4wifQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AOl37T-TGXFLQR-TYsLem8oMJpA Cc: "draft-ietf-xrblock-rtcp-xr-psi-decodability@tools.ietf.org" Subject: [MMUSIC] SDP directorate review of draft-ietf-xrblock-rtcp-xr-psi-decodability-02 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, 23 Apr 2014 10:45:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2D70A8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have performed the SDP directorate review of draft-ietf-xrblock-rtcp-xr-p= si-decodability-02. As the document only extends the SDP rtcp-xr-attrib attribute, and refers t= o RFC 3611 for the associated Offer/Answer procedures. Now, the Offer/Answer procedures in RFC 3611 could REALLY use some work, bu= t it is of course not the purpose of this draft to fix that :) However, RFC 3611 does also have a section (5.3) about non-Offer/Answer usa= ge, but the draft does not say anything about that. For completeness, shoul= d there be a section, referring to RFC 3611 also for that? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2D70A8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have performed the SDP directorate review of draft= -ietf-xrblock-rtcp-xr-psi-decodability-02.

 

As the document only extends the SDP rtcp-xr-attrib = attribute, and refers to RFC 3611 for the associated Offer/Answer procedure= s.

 

Now, the Offer/Answer procedures in RFC 3611 could R= EALLY use some work, but it is of course not the purpose of this draft to f= ix that :)

 

However, RFC 3611 does also have a section (5.3) abo= ut non-Offer/Answer usage, but the draft does not say anything about that. = For completeness, should there be a section, referring to RFC 3611 also for= that?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D2D70A8ESESSMB209erics_-- From nobody Wed Apr 23 08:28:00 2014 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 A25871A0389 for ; Wed, 23 Apr 2014 08:27:58 -0700 (PDT) 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 ipdayCQW39KY for ; Wed, 23 Apr 2014 08:27:57 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E00C1A0354 for ; Wed, 23 Apr 2014 08:27:56 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id tPjb1n0020xGWP858TTqlh; Wed, 23 Apr 2014 15:27:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id tTTq1n0093ZTu2S3YTTqTT; Wed, 23 Apr 2014 15:27:50 +0000 Message-ID: <5357DBF6.7090301@alum.mit.edu> Date: Wed, 23 Apr 2014 11:27:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2D6DC3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2D6DC3@ESESSMB209.ericsson.se> 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=q20140121; t=1398266870; bh=Oj4pRSy4iyxY78EQjZ7u5eJuHEodrKMXzvzPxERh3zQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bv581yFsCCSVxksjtQcvZGCFKgpPe0fW66ziR+Gs5Z5O/88xhbW5Sc0zxYbDpwUIT 4kVG0zwpi7DLnAc0iaJjObYCD/kIAC1B8krGjv+xNASLupljuaGZ8NZwL8lktrQiec UR2+2vb9gEClmDHgFqs/reWx9z4EgKoE6Od1AH1SyKl7ZRpKokubqho74xZZCO0Yqz pff9+UF1gjroadkBzKuF9am658rennEVRUeqLJwuOMqc4khxIPeEsM6om5jOBVaaiH 3929Er6A35nI/EtolXFeKEa/WusNpvAaR41ggV7OHjGIaLFgKMoH3+5cLeJr6OiDxj kljSbu9Nv1FXA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/KwWszDWh6JfHht_Y5omthek9QeA Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-07 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, 23 Apr 2014 15:27:58 -0000 Christer, This update has pretty much addressed my issues. I have one *possible* issue remaining: I previously noted that while you had adopted the RFC 3264 structure for documenting O/A behavior, your usage of the terms "Initial Offer" and "Initial Answer" was inconsistent with 3264. I see that for this version you have made an explicit statement that this is what you are doing, and otherwise left the structure alone. IMO one motivation for for using a common style for documenting O/A is so that all the independently defined extensions can be understood in a consistent way. Retaining the style while changing the definition of the terms doesn't provide that consistency. OTOH, viewed independently, the descriptions as you have them work well to describe the intended behavior for bundle. And doing something different, to align better with 3264 would be hard. I can live with this, but I hope others will give it some thought and comment if this is acceptable. Thanks, Paul On 4/23/14 5:54 AM, Christer Holmberg wrote: > Hi, > > I’ve submitted a new version of BUNDLE, with some fixes based on the > comments given on the -06 version. > > The biggest change is the removal of text talking about multiple RTP > sessions within a BUNDLE group. > > Note that the title of the document has been clarified, and is now: > > “Negotiating Media Multiplexing Using the Session Description Protocol > (SDP)” > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Apr 23 19:11:55 2014 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 DF12D1A0103; Wed, 23 Apr 2014 19:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.478 X-Spam-Level: * X-Spam-Status: No, score=1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 tZLbxylACWV0; Wed, 23 Apr 2014 19:11:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 276751A00F4; Wed, 23 Apr 2014 19:11:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDK83963; Thu, 24 Apr 2014 02:11:44 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 03:11:02 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 03:11:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 10:11:36 +0800 From: Qin Wu To: "Romascanu, Dan (Dan)" , "xrblock@ietf.org" Thread-Topic: SDP directorate review of draft-ietf-xrblock-rtcp-xr-psi-decodability-02 Thread-Index: Ac9e34bT8uRPa5C7TbaBxzCYiGKRmQABT4dwAB9NP7A= Date: Thu, 24 Apr 2014 02:11:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2D70A8@ESESSMB209.ericsson.se> <9904FB1B0159DA42B0B887B7FA8119CA5C7C51E0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7C51E0@AZ-FFEXMB04.global.avaya.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.114] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84514991nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dyNJz8xS9EajhORpGP5Rl9l8iMM Cc: "mmusic@ietf.org" , Christer Holmberg Subject: [MMUSIC] =?gb2312?b?tPC4tDogU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBk?= =?gb2312?b?cmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wc2ktZGVjb2RhYmlsaXR5LTAy?= 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, 24 Apr 2014 02:11:54 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84514991nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WWVzLCB0YWtpbmcgY29tcGxldGVuZXNzIGludG8gY29uc2lkZXJhdGlvbiwgQ2hyaXN0ZXKhr3Mg c3VnZ2VzdGlvbiBtYWtlcyBzZW5zZSB0byBtZS4NCldlIGNhbiBhZGQgYSBuZXcgc3Vic2VjdGlv biB0byBzYXkgZm9yIG5vbi1PZmZlci9BbnN3ZXIgdXNhZ2UsIHNlY3Rpb24gNS4zIG9mIFJGQzM2 MTEgYXBwbGllcy4NCg0KUmVnYXJkcyENCi1RaW4NCreivP7IyzogeHJibG9jayBbbWFpbHRvOnhy YmxvY2stYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb21hc2NhbnUsIERhbiAoRGFuKQ0Kt6LLzcqx vOQ6IDIwMTTE6jTUwjIzyNUgMTk6MTMNCsrVvP7IyzogeHJibG9ja0BpZXRmLm9yZw0Ks63LzTog Q2hyaXN0ZXIgSG9sbWJlcmcNCtb3zOI6IFt4cmJsb2NrXSBGVzogU0RQIGRpcmVjdG9yYXRlIHJl dmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1wc2ktZGVjb2RhYmlsaXR5LTAyDQoN ClNlZSBiZWxvdyB0aGUgU0RQIHJldmlldyBieSBDaHJpc3RlciBIb2xtYmVyZy4NCg0KVGhhbmtz LCBDaHJpc3RlciENCg0KQXV0aG9ycyCoQyBjYW4geW91IGFkZHJlc3MgdGhlIHF1ZXN0aW9uIGFz a2VkIGJ5IHRoZSByZXZpZXdlcj8NCg0KVGhhbmtzIGFuZCBSZWdhcmRzLA0KDQpEYW4NCg0KDQpG cm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIzLCAyMDE0IDE6NDUg UE0NClRvOiBtbXVzaWMgKEUtbWFpbCkNCkNjOiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1w c2ktZGVjb2RhYmlsaXR5QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXhyYmxvY2st cnRjcC14ci1wc2ktZGVjb2RhYmlsaXR5QHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogW01NVVNJ Q10gU0RQIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1w c2ktZGVjb2RhYmlsaXR5LTAyDQoNCkhpLA0KDQpJIGhhdmUgcGVyZm9ybWVkIHRoZSBTRFAgZGly ZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBzaS1kZWNvZGFi aWxpdHktMDIuDQoNCkFzIHRoZSBkb2N1bWVudCBvbmx5IGV4dGVuZHMgdGhlIFNEUCBydGNwLXhy LWF0dHJpYiBhdHRyaWJ1dGUsIGFuZCByZWZlcnMgdG8gUkZDIDM2MTEgZm9yIHRoZSBhc3NvY2lh dGVkIE9mZmVyL0Fuc3dlciBwcm9jZWR1cmVzLg0KDQpOb3csIHRoZSBPZmZlci9BbnN3ZXIgcHJv Y2VkdXJlcyBpbiBSRkMgMzYxMSBjb3VsZCBSRUFMTFkgdXNlIHNvbWUgd29yaywgYnV0IGl0IGlz IG9mIGNvdXJzZSBub3QgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCB0byBmaXggdGhhdCA6KQ0K DQpIb3dldmVyLCBSRkMgMzYxMSBkb2VzIGFsc28gaGF2ZSBhIHNlY3Rpb24gKDUuMykgYWJvdXQg bm9uLU9mZmVyL0Fuc3dlciB1c2FnZSwgYnV0IHRoZSBkcmFmdCBkb2VzIG5vdCBzYXkgYW55dGhp bmcgYWJvdXQgdGhhdC4gRm9yIGNvbXBsZXRlbmVzcywgc2hvdWxkIHRoZXJlIGJlIGEgc2VjdGlv biwgcmVmZXJyaW5nIHRvIFJGQyAzNjExIGFsc28gZm9yIHRoYXQ/DQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQo= --_000_B8F9A780D330094D99AF023C5877DABA84514991nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Yes, taking completeness into consideration, Christer=A1=AFs sugg= estion makes sense to me.

We can add a new subsection to say for non-Offer/Answer usage, se= ction 5.3 of RFC3611 applies.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: xrblock [mailto:xrblo= ck-bounces@ietf.org] =B4=FA=B1=ED = Romascanu, Dan (Dan)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA4=D4=C2<= span lang=3D"EN-US">23=C8=D5 19:13
=CA=D5=BC=FE=C8=CB: xrblock@ietf.org
=B3=AD=CB=CD: Christer Holmberg
=D6=F7=CC=E2: [xrblock] FW: SDP directorate review of draft-ietf-xrblock-rtcp-xr-psi-de= codability-02

 

See bel= ow the SDP review by Christer Holmberg.

&n= bsp;

Thanks,= Christer!

&n= bsp;

Authors= =A8C can you address the question asked by the reviewer?

&n= bsp;

Thanks = and Regards,

&n= bsp;

Dan

&n= bsp;

&n= bsp;

From: mmusic [ma= ilto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, April 23, 2014 1:45 PM
To: mmusic (E-mail)
Cc: draft-ietf-xrblock-rtcp-xr-psi-decodability@tools.ietf.org
Subject: [MMUSIC] SDP directorate review of draft-ietf-xrblock-rtcp-= xr-psi-decodability-02

 

Hi,

 

I have performed the SDP direct= orate review of draft-ietf-xrblock-rtcp-xr-psi-decodability-02.<= /span>

 

As the document only extends th= e SDP rtcp-xr-attrib attribute, and refers to RFC 3611 for the associated O= ffer/Answer procedures.

 

Now, the Offer/Answer procedure= s in RFC 3611 could REALLY use some work, but it is of course not the purpo= se of this draft to fix that :)

 

However, RFC 3611 does also hav= e a section (5.3) about non-Offer/Answer usage, but the draft does not say = anything about that. For completeness, should there be a section, referring= to RFC 3611 also for that?

 

Regards,

 

Christer

--_000_B8F9A780D330094D99AF023C5877DABA84514991nkgeml501mbschi_-- From nobody Thu Apr 24 05:12:16 2014 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 256031A01B7 for ; Thu, 24 Apr 2014 05:12:06 -0700 (PDT) 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 4I9TyXA6Zt4v for ; Thu, 24 Apr 2014 05:12:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id C86F41A01B0 for ; Thu, 24 Apr 2014 05:11:46 -0700 (PDT) X-AuditID: c1b4fb3a-f79156d000001144-de-5358ff7c757c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 16.CA.04420.C7FF8535; Thu, 24 Apr 2014 14:11:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 14:11:39 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-07 Thread-Index: AQHPXwiajKSw3TSLQEu5na2h47ArVJsgp6KA Date: Thu, 24 Apr 2014 12:11:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2D8BBE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2D6DC3@ESESSMB209.ericsson.se> <5357DBF6.7090301@alum.mit.edu> In-Reply-To: <5357DBF6.7090301@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7N/4hggzcXBS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujZ/cFtoL7ghV3V01kamCczdfFyMEhIWAi MXehaBcjJ5ApJnHh3nq2LkYuDiGBo4wSD16+Z4VwljBKHP58kw2kgU3AQqL7nzZIg4iAr8Sz x7fZQGxhgTCJWcs3sUDEwyVats5ih7CNJLr27WUGsVkEVCV+TZ7OBGLzAvXuWfYGLC4kkC+x /epFsDmcAjoSLYeXgc1hBDro+6k1YPXMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIX5RlFje LwdRriOxYPcnNghbW2LZwtfMEGsFJU7OfMIygVF0FpKps5C0zELSMgtJywJGllWMosWpxcW5 6UZGeqlFmcnFxfl5enmpJZsYgTFycMtvqx2MB587HmIU4GBU4uFlU/MLFmJNLCuuzD3EKM3B oiTOO2mRe7CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRvXso1/mTJ0Z5hPNUL2Z83nd9Dtf uAIPCNXOljDcuDDU9ze7vsvDd0UHrn9YWCVnOnkB+/4NPSfl52vuN9jkprCzQejgk5iNFWk5 0cvPzJCeIFzwru/xF5M6VnM3vT/q99u4vK7Mb9nPLXBllX6dukH55mmO39ZNkwj8+OEa6/oY iYy9j3cHSCixFGckGmoxFxUnAgBMI+DYcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8JpISWg2tLPN-mOz--AS7FQ3iJI Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-07 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, 24 Apr 2014 12:12:06 -0000 Hi, >This update has pretty much addressed my issues. > >I have one *possible* issue remaining: > >I previously noted that while you had adopted the RFC 3264 structure for d= ocumenting O/A behavior, your usage of the terms "Initial Offer" and "Initi= al Answer" was inconsistent with 3264. > > I see that for this version you have made an explicit statement that this= is what you are doing, and otherwise left the structure alone. I don't use "Initial Answer", do I? > IMO one motivation for for using a common style for documenting O/A is so= that all the independently defined extensions can be understood in a=20 > consistent way. Retaining the style while changing the definition of the = terms doesn't provide that consistency. > > OTOH, viewed independently, the descriptions as you have them work well t= o describe the intended behavior for bundle. And doing something different,= to align better with 3264 would be hard. I am not sure there is a misalignment with 3264. At least not a BUNDLE spec= ific one. Because, I think that, for *any* SDP extension, "Initial Offer" refers to t= he Offer where the extension is initially used (in one way or another). It = may, or may not, be the first Offer within the session.=20 In 3264 "Initial Offer" of course always refers to the first Offer within t= he session, as 3264 talks about the whole SDP (you can't send an Offer with= out SDP :), not a specific SDP extension. Regards, Christer On 4/23/14 5:54 AM, Christer Holmberg wrote: > Hi, > > I've submitted a new version of BUNDLE, with some fixes based on the=20 > comments given on the -06 version. > > The biggest change is the removal of text talking about multiple RTP=20 > sessions within a BUNDLE group. > > Note that the title of the document has been clarified, and is now: > > "Negotiating Media Multiplexing Using the Session Description Protocol=20 > (SDP)" > > 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 nobody Thu Apr 24 07:41:11 2014 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 683B51A0318 for ; Thu, 24 Apr 2014 07:41:07 -0700 (PDT) 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 bSWaJLoY3Zs4 for ; Thu, 24 Apr 2014 07:41:06 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 22B7C1A031D for ; Thu, 24 Apr 2014 07:41:06 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id tmyo1n0051vXlb854qgzCm; Thu, 24 Apr 2014 14:40:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id tqgz1n00x3ZTu2S3dqgzgL; Thu, 24 Apr 2014 14:40:59 +0000 Message-ID: <5359227B.4010301@alum.mit.edu> Date: Thu, 24 Apr 2014 10:40:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2D6DC3@ESESSMB209.ericsson.se> <5357DBF6.7090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2D8BBE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2D8BBE@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=q20140121; t=1398350460; bh=2jC9vMv8O/vRQ2PHAMElezRvaEii2+7VtHitKaOko40=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=igjHje06GNZX4gFTQtQJfV3fQxyRy8HimUStLe5ukrFXzvU1E33WmwsVpEIRof7ha xPQYUDVExiTTKt5jiCAgWtgmVxqWXHOoqxNkV+SFOih7hEXJLJkhfvB1v/4w6+0E3l Yrdx1IO1vu9G8i2Osj9M9UOr40atSsZ81hZxAcz0+Bx5id/aOA7WUErE9eOVwijlNH xOnumTJDmAwRJ7OUCkWZb+F8TwjLLihHsw4zK/vAVI8i3UIGJQq5WapURd2USu8TIj MMYzfKifJybEJyTLopEtqXGQ3oSCpaEP4XPD0OiE4op+L7uPd0EyVRVdvv5TDQoPG2 2+Pjp5Fq7R9Yw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/co9TxppnzRVLZCPhOZEDYrm3bEQ Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-07 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, 24 Apr 2014 14:41:07 -0000 On 4/24/14 8:11 AM, Christer Holmberg wrote: > Hi, > >> This update has pretty much addressed my issues. >> >> I have one *possible* issue remaining: >> >> I previously noted that while you had adopted the RFC 3264 structure for documenting O/A behavior, your usage of the terms "Initial Offer" and "Initial Answer" was inconsistent with 3264. >> >> I see that for this version you have made an explicit statement that this is what you are doing, and otherwise left the structure alone. > > I don't use "Initial Answer", do I? maybe not. >> IMO one motivation for for using a common style for documenting O/A is so that all the independently defined extensions can be understood in a >> consistent way. Retaining the style while changing the definition of the terms doesn't provide that consistency. >> >> OTOH, viewed independently, the descriptions as you have them work well to describe the intended behavior for bundle. And doing something different, to align better with 3264 would be hard. > > I am not sure there is a misalignment with 3264. At least not a BUNDLE specific one. > > Because, I think that, for *any* SDP extension, "Initial Offer" refers to the Offer where the extension is initially used (in one way or another). It may, or may not, be the first Offer within the session. > > In 3264 "Initial Offer" of course always refers to the first Offer within the session, as 3264 talks about the whole SDP (you can't send an Offer without SDP :), not a specific SDP extension. I guess that is a judgement call. 3264 didn't give specific instructions on how to document the o/a behavior of an extension. People are simply looking to it as an example and extrapolating how to apply that to an extension. And we aren't all extrapolating in the same way. As I said, I am ok with this draft as you have done it, with the clear specification of what is meant by "initial offer", even though I might have done it differently if I was doing it. But I think it is important for those who are acting as "O/A police" and requesting the use of this format to think about whether this is what they want. Thanks, Paul > Regards, > > Christer > > > > > > > On 4/23/14 5:54 AM, Christer Holmberg wrote: >> Hi, >> >> I've submitted a new version of BUNDLE, with some fixes based on the >> comments given on the -06 version. >> >> The biggest change is the removal of text talking about multiple RTP >> sessions within a BUNDLE group. >> >> Note that the title of the document has been clarified, and is now: >> >> "Negotiating Media Multiplexing Using the Session Description Protocol >> (SDP)" >> >> 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 nobody Fri Apr 25 11:42:09 2014 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 7558E1A0687; Fri, 25 Apr 2014 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 dlntOAqIKsOK; Fri, 25 Apr 2014 11:42:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id F181D1A067D; Fri, 25 Apr 2014 11:42:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8791C1801A2; Fri, 25 Apr 2014 11:41:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140425184101.8791C1801A2@rfc-editor.org> Date: Fri, 25 Apr 2014 11:41:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FWIZnmD8n9P6iD2Bl0SeuFawKGc Cc: drafts-update-ref@iana.org, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 7197 on Duplication Delay Attribute in the Session Description Protocol 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, 25 Apr 2014 18:42:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7197 Title: Duplication Delay Attribute in the Session Description Protocol Author: A. Begen, Y. Cai, H. Ou Status: Standards Track Stream: IETF Date: April 2014 Mailbox: abegen@cisco.com, yiqunc@microsoft.com, hou@cisco.com Pages: 11 Characters: 22559 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-delayed-duplication-03.txt URL: http://www.rfc-editor.org/rfc/rfc7197.txt A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Apr 28 08:47:38 2014 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 C1F0D1A07A6 for ; Mon, 28 Apr 2014 08:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 EJJ5G4odXUmh for ; Mon, 28 Apr 2014 08:47:34 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id AED491A0352 for ; Mon, 28 Apr 2014 08:47:34 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3SFlWYt001259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Apr 2014 10:47:33 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3SFlVJa025639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 17:47:31 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 28 Apr 2014 17:47:32 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Belling, Thomas (NSN - DE/Munich)" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Thread-Index: AQHPSZ11tlxeVOi9qUaF/6Ya6nB3kJr0rpiAgAvrKICADCrMcIAamYQg Date: Mon, 28 Apr 2014 15:47:30 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC220BA6@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC1DAAF2@FR711WXCHMBA03.zeu.alcatel-lucent.com> <533E0E37.1040404@nteczone.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/O6CGHpfHRiT2rTTxcIvAIA7Ndkw Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt 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, 28 Apr 2014 15:47:36 -0000 Thanks for support of this activity Thomas! to filename: dependent on adoption by MMUSIC of this draft to introductory text: the lenghty background was motivated by the fact that= this draft doesn't originate in MMUSIC itself, hence we need to provide mo= re description (than for the H.248 experts community in ITU-T). Regards, Albrecht -----Original Message----- From: Belling, Thomas (NSN - DE/Munich) [mailto:thomas.belling@nsn.com]=20 Sent: Freitag, 11. April 2014 19:40 To: Schwarz, Albrecht (Albrecht); mmusic@ietf.org Subject: RE: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Hi Albrecht, thanks for your attempt to register the codepoints in Clause 8 of your draf= t at IANA. I understand this is the main intention of this draft and a inte= rnet draft seems indeed required for that purpose. Perhaps you should choose a filename containing "mmusic", e.g. "draft-schwa= rz-mmusic-sdp-for-gw" to direct new version notifications and discussions t= o the proper group. I understand a version 2 of the draft is now available. I believe clauses 1 and 2 are rather long and could be shortened a bit. Is = all the history essential and are all abbreviations and conventions really = used within the draft? Regards, Thomas -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Christian Gr= oves Sent: Friday, April 04, 2014 3:43 AM To: mmusic@ietf.org Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt Hello Albrecht, Thanks for submitting the draft. I support the addition of the extra codepoints for scenarios where a gateway performs application agnostic in= ter working. In general the background to H.248/Megaco usage of SDP is good= but I'm not sure if the reasons for the new codepoints are documented suff= iciently in the draft. Some specific comments below: Clause 1.4 Scope: I propose to word this slightly differently to indicate t= he scope is the collection of SDP codepoints for GCPs in order to identify = additional ones that REQUIRE registration with IANA. Clause 4: There appears to be some duplication in the headings, i.e. 4 and = 4.5. Perhaps also " element" needs to be removed from the title of h= eading 4 as clause 4.4 covers the element? Clause 4.1 Purpose, Last Para: To me this is the reason for the entire draf= t. The draft has cataloged how SDP is used by GCPs(H.248/Megaco) however ha= sn't really gone into much depth on why the additional codepoints are neede= d. Perhaps a paragraph for each additional codepoint could be added indicat= ing where it is used/needed? Clause 4.4: I think the draft could indicate that H.248 uses the = values as defined on the IANA registry and no additional IANA registration= s are required. Clause 5.1: I think it would be good to note that this has already been reg= istered with IANA. Clause 7.1: TCP/TLS is already registered. See RFC4572 clause 4. However I'= m not sure that in the case of agnostic interworking that the MUST indicate= d in that clause (/An 'm' line that specifies 'TCP/TLS' MUST further qualif= y the protocol using a fmt identifier to indicate the application being run= over TLS./) applies. I've also noticed some other minor editorial issues that i'll forward to yo= u off-line. Regards, Christian On 27/03/2014 8:48 PM, Schwarz, Albrecht (Albrecht) wrote: > fyi, this is a spin off activity from > draft-ietf-mmusic-udptl-dtls > in order to define additional codepoints as required for DTLS security se= ssion termination (so called end-to-access edge security mode) and DTLS tra= nsparent forwarding (e.g. as part of end-to-end security mode) in middlebox= es. > -Albrecht > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: Donnerstag, 27. M=E4rz 2014 10:03 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-schwarz-sdp-for-gw-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : SDP codepoints for gateway control > Author : Albrecht Schwarz > Filename : draft-schwarz-sdp-for-gw-01.txt > Pages : 12 > Date : 2014-03-27 > > Abstract: > SDP is used in many signalling protocols at call control level (such > as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and > gateway control level (such as H.248/MEGACO, MGCP). Scope of this RFC > is related to gateway control specific SDP usage. Gateway control > protocols do usually NOT define and introduce any new SDP parameters, > however, gateway control protocols need specific SDP parameter values > in addition to SDP usage at call or bearer control level. Such SDP > codepoints are collected by this RFC with the purpose of registration > with IANA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-schwarz-sdp-for-gw/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-schwarz-sdp-for-gw-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-schwarz-sdp-for-gw-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion 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 > > _______________________________________________ > 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 nobody Wed Apr 30 12:38:02 2014 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 09AC31A889C; Wed, 30 Apr 2014 12:38:00 -0700 (PDT) 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 L5YyY1Qt23sm; Wed, 30 Apr 2014 12:37:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 008591A8839; Wed, 30 Apr 2014 12:37:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: schulzrinne@cs.columbia.edu, anrao@cisco.com, robla@robla.net, magnus.westerlund@ericsson.com, mls.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430193757.7102.12512.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 12:37:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cEKL22o5yb8ZDZ0SULkbfKyHBpk Cc: ari.keranen@ericsson.com, mmusic@ietf.org, fandreas@cisco.com, ipr-announce@ietf.org Subject: [MMUSIC] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mmusic-rfc2326bis-40 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: Wed, 30 Apr 2014 19:38:00 -0000 Dear Dr. Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling: An IPR disclosure that pertains to your Internet-Draft entitled "Real Time Streaming Protocol 2.0 (RTSP)" (draft-ietf-mmusic-rfc2326bis) was submitted to the IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2348/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mmusic- rfc2326bis-40.""); The IETF Secretariat