From pkyzivat@alum.mit.edu Wed Dec 5 15:10:30 2012 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5150021F8BE6 for ; Wed, 5 Dec 2012 15:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7nou0+d9m4x for ; Wed, 5 Dec 2012 15:10:29 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 7787B21F8BCB for ; Wed, 5 Dec 2012 15:10:29 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id Xnoy1k0021swQuc51zAUNs; Wed, 05 Dec 2012 23:10:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id XzAU1k00p3ZTu2S3bzAUHA; Wed, 05 Dec 2012 23:10:28 +0000 Message-ID: <50BFD464.6090204@alum.mit.edu> Date: Wed, 05 Dec 2012 18:10:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: straw@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354749028; bh=voOAsd/YYIlJfTxIy1VTJSCz+FdOAiXZDJJGz9h8Gvg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YrCLZUSn5V+LSKi0R/bPnHOiTpfm3v9X2Ud/PkAILAXP+CanWpbSLx1I/xSQ3QDn8 HOwhWzBM4bkIDRpsIV4uTudSXrGBUn2OqzkVITwh4vqlgUnWcsTeYKOoAkKmX84vlw vwvMptTarSNcDqYimiJvUKq2rDjYM8Oz3dHNids/8mR3KshQA2j/lhYke9T+AlDtMi iCL8PWTBkrz3koNe3rpgSKhiFjtneeKbR9Ht6bhAGcmR7ikPUil8cTHzk+mBLNy8hm pbBbe4c7/1+JNvzjYWxD2CYmw5g2TX0HZhqeTpbGq2dJisxUgtf4gZqJPiYrfVMhCG U4d2rluRKiU2g== Cc: Victor Pascual , Christer Holmberg Subject: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:10:30 -0000 I've only been looking at changes in this for awhile. Now that we are at WGLC I actually carefully read through it again. I have more comments than I thought I would. Section 3: Within the context of this document, the terms refer to a B2BUA role, not a particular system type. A given system type may change its role in the middle of a SIP session, for example when a Stateful Proxy tears-down a session by generating BYEs; or for example when an SBC performs transcoding or REFER termination. The first example above is good. But I don't understand how the mentioned SBC demonstrates the point of this paragraph. How is this SBC changing role? A few more words to explain this would help. Same section: Likewise, a one-armed third-party call control transcoder as described in section 3.1 of [RFC5369] is not a B2BUA; whereas an inline transcoder based on [RFC5370] is a B2BUA. IMO this is very subjective. There clearly *is* a distinction between the two cases, but that doesn't necessarily mean they aren't both B2BUAs. It would be very helpful to have both types of transcoders included so that it is possible to contrast the differences between the two. I think the problem here is that we don't have clear criteria for what to include and what to exclude. In this case I think the key distinction is whether or not the transcoder is on the signaling path between the caller and the UA that represents the callee. (Interestingly, that is also true of a conference focus, and for a UA that splits a multimedia call, sending the different media to different devices.) So maybe that is the criterion that matters. If so, it would be helpful to explicitly state this and ensure that the decisions are all made based on this. Section 3.1.1: As I brought up at the Atlanta meeting, a Proxy-B2BUA that generates in-dialog messages will need to "make room" in the progression of CSeq values for the messages it generates. This means, once it generates a message, that CSeq values will differ on the two "sides". The b2bua then must modify CSeq values to perform the mapping. (A Proxy-B2BUA that only generates a BYE message probably segments the session at that time, no longer forwarding messages, and so won't need to update CSeq values. But it will still need to know what CSeq value it can use for the BYE, so it will need to keep state.) This is a fairly significant issue, and IMO should be mentioned explicitly. Section 3.1.2: I have always considered that there is a major distinction between those b2buas that replace the Contact with one of their own, and those that leave the Contact and use Record-Route to stay in the call. For example, one that replaces the contact can potentially use callee-caps to represent its capabilities/features, while the other kind must use Proxy-Feature to identify itself. The Proxy-Feature draft danced all around this, pretending it was only talking about proxies when in fact we all know it was intending to cover B2BUAs. If it had been able to reference this draft then having that distinction available could have been important. Section 3.2: Such a B2BUA may or may not replace the Contact URI, modify or remove all Via and Record-Route headers, modify the To and From header fields, etc. I think you are saying that any of the Media-plane roles is compatible with any of the Signaling-plane roles. I wish you would say it explicitly. This would then mean that we could describe every B2BUA by naming both its signaling role and its media role. Section 3.2.1: Such a role may only support UDP or only TCP or both, as well as other transport types or not. Should these be different roles? What does it mean to *not* support some transport type? Does it mean that it is a signaling-only B2BUA wrt that media? Or that it blocks that media? (ISTM blocking the media is a signaling-only function - a variant on the SDP-Modifying Signaling-only role.) Section 4.4: ... Some transcoders save and remove SDP offers in INVITEs form the UAC, ... s/form/from/ idnits reports: The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. That's all. Thanks, Paul On 11/27/12 10:39 AM, Victor Pascual wrote: > Paul, > > would you be so kind to volunteer for this? > > Thanks, > -Victor > > On 11/21/12 2:16 PM, "Christer Holmberg" > wrote: > > [As co-chair] > > Hi, > > As indicated in Atlanta, we were going to initiate the *WGLC for > draft-ietf-straw-b2bua-taxonomy-00*. > > Due to upcoming holidays (Thanksgiving etc) the WGLC will last for 3 > weeks, until *12^th December*. > > Everyone is encouraged to read the document and provide comments. > > However, the chairs would also like to ask for at least a couple of > *volunteers*, who commit to thoughtfully reading the document. > Please contact the chairs if You can help with that :) > > Best regards, > > Victor & Christer > From christer.holmberg@ericsson.com Thu Dec 6 10:15:22 2012 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24E321F87E1 for ; Thu, 6 Dec 2012 10:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+qwF66DnJDb for ; Thu, 6 Dec 2012 10:15:21 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 541A721F87FE for ; Thu, 6 Dec 2012 10:15:21 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-f1-50c0e0b8c0ac Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A7.50.06323.8B0E0C05; Thu, 6 Dec 2012 19:15:20 +0100 (CET) Received: from ESESSHC021.ericsson.se (153.88.183.81) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Dec 2012 19:15:20 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 19:15:19 +0100 From: Christer Holmberg To: Paul Kyzivat , "straw@ietf.org" Thread-Topic: WGLC: for draft-ietf-straw-b2bua-taxonomy-00 Thread-Index: AQHN0zvjRUSJumDOxUCNOUIu9d4L85gME+IV Date: Thu, 6 Dec 2012 18:15:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0500B1@ESESSMB209.ericsson.se> References: , <50BFD151.1060703@alum.mit.edu> In-Reply-To: <50BFD151.1060703@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje6OBwcCDDrnSVms2HCA1eJW82NW izuTzrM5MHtsmryZzePv+w9MHkuW/GQKYI7isklJzcksSy3St0vgynj2yLrgO2vF0nn7mRsY n7N0MXJySAiYSNw484cNwhaTuHBvPZDNxSEkcJJR4tij2+wQzg5GiTPTVjCCVAkJLGaU2L1U u4uRg4NNwEKi+x+YKSLgLfHwRT5IBbOAjsS9K5PA5gsLWEqcWbmXHcQWEbCS+HjwGyuEbSTR ueU22EQWARWJlf/mM4PYvEBjenZuZQMZKSQQLHH3VD1ImBNo5IP9d8DOZAQ68/upNUwQq8Ql bj2ZzwRxvoDEkj3nmSFsUYmXj/+xQtiKEjvPtjPDnLZg9yc2CFtbYtnC11BrBSVOznzCAvGg tkTL4gnsExglZiFZMQtJ+ywk7bOQtC9gZFnFyJ6bmJmTXm6+iREYYQe3/DbYwbjpvtghRmkO FiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPNbl8SXnttVnrCi5ZXr66udvewW QjIdrs0vvKfuU3V5aDKl2H5n0XP+bV5L3n2qlZSL0VGJqJRK6uh78rl7ctGV7Iqvd4RP/bh4 7pb6pEn3T/VNFjW195/FI+446bOeavnNOU3Lvv91jVlUeODl8qe5Z9j7JqV9s5mzV7klTazr 8a/9PNcvZSuxFGckGmoxFxUnAgASdEBbfgIAAA== Cc: Victor Pascual Subject: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:15:22 -0000 [As proxy-feature author] Hi, >Section 3.1.2: > >I have always considered that there is a major distinction between those >b2buas that replace the Contact with one of their own, and those that >leave the Contact and use Record-Route to stay in the call. > >For example, one that replaces the contact can potentially use >callee-caps to represent its capabilities/features, while the other kind >must use Proxy-Feature to identify itself. The Proxy-Feature draft >danced all around this, pretending it was only talking about proxies >when in fact we all know it was intending to cover B2BUAs. Not really related to the b2bua-taxonomy draft, but Proxy-Feature does talk= explicitly about both B2BUAs and proxies. Regards, Christer From christer.holmberg@ericsson.com Wed Dec 12 02:54:39 2012 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0421F8973 for ; Wed, 12 Dec 2012 02:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdZY-JsLiOt9 for ; Wed, 12 Dec 2012 02:54:38 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 57BDC21F8946 for ; Wed, 12 Dec 2012 02:54:38 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-1f-50c8626d784d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.DE.10459.D6268C05; Wed, 12 Dec 2012 11:54:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 11:54:36 +0100 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: WGLC: for draft-ietf-straw-b2bua-taxonomy-00 Thread-Index: Ac3YVh3Ty+uRgMuKSiimKboB6xzynw== Date: Wed, 12 Dec 2012 10:54:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053DF9@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B053DF9ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW5u0okAg7tbRS1+nXjIZnGr+TGr A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWx6tUW1oI++YpFjYvYGxgXSHcxcnJICJhI fHm0lB3CFpO4cG89WxcjF4eQwCFGiX23XzNCOEsYJe5NXAhUxcHBJmAh0f1PG6RBREBVYsKX m4wgYWYBS4m+71UgYWEBU4kFD9exQpRYSXw8+A3K1pP4fGw1I4jNAtR6ffEUNpBWXgFvia4u FZAwI9AJ30+tYQKxmQXEJW49mc8EcZqAxJI955khbFGJl4//sYK0SggoSizvl4Moz5c4sek6 C4jNKyAocXLmE5YJjMKzkEyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqR PTcxMye93HATIzA6Dm75rbuD8dQ5kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUw8umLRJokKbE+DN34NC1gGUONfPXDiVkVgpYL9qqUS+REdjL7L0546nB6Zs3CPIZz X31qrS9ImYaeU3E9bZXc/vCtYEZhd8omAdGLkpUOu2df3Xm0mK1a/MWUalaF6qQ+cWOXzLju ba0/dv44clXb87nU/t3e8VXsB5l4WDb/fP263e3at4NKLMUZiYZazEXFiQBTI5zaXAIAAA== Cc: "straw-ads@tools.ietf.org" Subject: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 10:54:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B053DF9ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [As co-chair] Hi, Today is the day we announced as the end date for the WGLC of draft-ietf-st= raw-b2bua-taxonomy. The chairs would like to give a big Thank You to Mary, Andrew and Paul for = reading the document, and providing comments. Hadriel has informed us that he is away on vacation this week, but that he = will address the comments next week. ...which means there is still some room if someone still wants to provide c= omments :) Thanks! Regards, Victor & Christer --_000_7594FB04B1934943A5C02806D1A2204B053DF9ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[As co-chair]

 

Hi,

 

Today is the day we announced as the end date for th= e WGLC of draft-ietf-straw-b2bua-taxonomy.

 

The chairs would like to give a big Thank You to Mar= y, Andrew and Paul for reading the document, and providing comments.

 

Hadriel has informed us that he is away on vacation = this week, but that he will address the comments next week.

 

…which means there is still some room if someo= ne still wants to provide comments J

 

Thanks!

 

Regards,

 

Victor & Christer

--_000_7594FB04B1934943A5C02806D1A2204B053DF9ESESSMB209ericsso_-- From btv1==702717fa800==HKaplan@acmepacket.com Fri Dec 21 13:08:56 2012 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47FB21F8472 for ; Fri, 21 Dec 2012 13:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dz0BuRhzgia for ; Fri, 21 Dec 2012 13:08:55 -0800 (PST) Received: from mx2.acmepacket.com (mx2.acmepacket.com [216.41.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id C063721F845D for ; Fri, 21 Dec 2012 13:08:54 -0800 (PST) X-ASG-Debug-ID: 1356124133-03fc2110a84bdc30001-uMHarY Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx2.acmepacket.com with ESMTP id pppbTZxKw0E8o8S0 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 16:08:53 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.174]) by Mail1.acmepacket.com ([169.254.1.77]) with mapi id 14.02.0283.003; Fri, 21 Dec 2012 16:08:53 -0500 From: Hadriel Kaplan To: Mary Barnes Thread-Topic: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-ASG-Orig-Subj: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 Thread-Index: AQHN379g7qaIiSHH8kSINsJfrMNPTQ== Date: Fri, 21 Dec 2012 21:08:52 +0000 Message-ID: <6EB25A40-6DAE-45C4-9194-1A56DC15A453@acmepacket.com> References: <7594FB04B1934943A5C02806D1A2204B0414B2@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_6EB25A406DAE45C491941A56DC15A453acmepacketcom_" MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1356124133 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://216.41.24.99:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117682 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: "straw-ads@tools.ietf.org" , "straw-chairs@tools.ietf.org" , "straw@ietf.org" , Hadriel Kaplan , Christer Holmberg Subject: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:08:56 -0000 --_000_6EB25A406DAE45C491941A56DC15A453acmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, Thanks for the review! Comments/actions inline... On Nov 29, 2012, at 5:19 PM, Mary Barnes > wrote: General comments: --------------------------- - A fair number of references need to be added - I've identified many below= . - The document discusses Application Servers and PBXs throughout section 3,= but those terms aren't described until section 4, so I think at least a fo= rward reference should be added (although, that kindof makes it circular, s= o maybe adding a generic definition something like the following to the ter= minology section might be useful) and/or the terminology added to section 1= . OK. Minor comments: ----------------------- - Abstract - really could use a bit more intro. I would suggest to borrow = some text from the introduction - maybe the first paragraph. You're the second person to suggest this, but I don't see it - or rather I = don't see how to do so in a useful way without repeating the intro section,= and really this is supposed to be an abstract not an intro - just enough i= nformation for someone to decide whether to read the doc or not, right? Do= es it not fulfill that goal? If not, what exact wording should be added? - Section 1 - Terminology: -- Remove the reference to RFC 2119. I don't think it's necessary. Done. -- Also, I don't think B2BUA, UAS and UAC need to be defined here. They sh= ould just be expanded on the first usage. I would just refer to the defin= itions in RFC 3261 as you have for RFC 2828. -- Per my comment above - Section 3, 2nd paragraph, last sentence. What is a "one-armed 3rd party = call control transcoder"? There is a reference to section 3.1 of RFC 5369,= but that doesn't use the "one-armed" terminology. I don't think referring= to "one-armed" adds value. I suggest simply removing it. Done. - Section 3.2.2: Add references for SRTP Terminator and RTCP for QoS done - Section 3.2.3: Add a reference for MSRP done - Section 4.6: Expand P-CSCF and IBCF. Add references to 3GPP architecture= and media plane gateway specs. - Section 4.7: Expand S-CSCF. Can I get away with just a reference to 3gpp's website of specs? - Section 5: I would suggest to reword something like "The security consid= erations related to the functionality described in this document are addres= sed in the relevant references." done. Nits: ------ - Section 4.2: -- expand VCC & IVR -- last sentence: "Poxy-B2BUA" -> "Proxy-B2BUA" - Section 4.4.: Expand TDM. Done. -hadriel --_000_6EB25A406DAE45C491941A56DC15A453acmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <69E57604A105D14788EFE1C8977F8F30@acmepacket.com> Content-Transfer-Encoding: quoted-printable
Hi Mary,
Thanks for the review!
Comments/actions inline...

On Nov 29, 2012, at 5:19 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

General comments:
---------------------------
- A fair number of references need to be added - I've identified many below= . 
- The document discusses Application Servers and PBXs throughout section 3,= but those terms aren't described until section 4, so I think at least a fo= rward reference should be added (although, that kindof makes it circular, s= o maybe adding a generic definition something like the following to the terminology section might be useful) a= nd/or the terminology added to section 1.  

OK.


Minor comments:
-----------------------
- Abstract - really could use a bit more intro.  I would suggest to bo= rrow some text from the introduction - maybe the first paragraph.

You're the second person to suggest this, but I don't see it - or rath= er I don't see how to do so in a useful way without repeating the intro sec= tion, and really this is supposed to be an abstract not an intro - just eno= ugh information for someone to decide whether to read the doc or not, right?  Does it not fulfill that goal= ?  If not, what exact wording should be added?


- Section 1 - Terminology:
-- Remove the reference to RFC 2119.  I don't think it's necessary.

Done.

 
-- Also, I don't think B2BUA, UAS and UAC need to be defined here.  Th= ey should just be expanded on the first usage.   I would just refer to= the definitions in RFC 3261 as you have for RFC 2828.  
-- Per my comment above

- Section 3, 2nd paragraph, last sentence.  What is a "one-armed = 3rd party call control transcoder"?  There is a reference to sect= ion 3.1 of RFC 5369, but that doesn't use the "one-armed" termino= logy.  I don't think referring to "one-armed" adds value.&nb= sp; I suggest simply removing it. 

Done.


- Section 3.2.2: Add references for SRTP Terminator and RTCP for QoS
done
- Section 3.2.3:  Add a reference for MSRP
done
- Section 4.6:  Expand P-CSCF and IBCF. Add references to 3GPP archite= cture and media plane gateway specs. 
- Section 4.7:  Expand S-CSCF.  

Can I get away with just a reference to 3gpp's website of specs?  = ;

- Section 5:  I would suggest to reword something like "The secur= ity considerations related to the functionality described in this document = are addressed in the relevant references."

done.


Nits:
------
- Section 4.2:  
-- expand VCC & IVR
-- last sentence: "Poxy-B2BUA" -> "Proxy-B2BUA"
- Section 4.4.: Expand TDM.

Done.

-hadriel


--_000_6EB25A406DAE45C491941A56DC15A453acmepacketcom_-- From btv1==702717fa800==HKaplan@acmepacket.com Fri Dec 21 13:21:18 2012 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05D521F85C8 for ; Fri, 21 Dec 2012 13:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ar17S3UFbyx for ; Fri, 21 Dec 2012 13:21:12 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37D21F87D5 for ; Fri, 21 Dec 2012 13:21:10 -0800 (PST) X-ASG-Debug-ID: 1356124869-03fc200e93233ca0001-uMHarY Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id HoOQftQXg5Kr8Ri0 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 16:21:09 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.174]) by Mail1.acmepacket.com ([169.254.1.77]) with mapi id 14.02.0283.003; Fri, 21 Dec 2012 16:21:09 -0500 From: Hadriel Kaplan To: "Hutton, Andrew" Thread-Topic: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-ASG-Orig-Subj: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 Thread-Index: AQHN38EXZf4b3c6Hf0iG6vsdKAKayA== Date: Fri, 21 Dec 2012 21:21:08 +0000 Message-ID: <2E29CD95-9F0A-4F63-8CF6-3D3E683C614A@acmepacket.com> References: <7594FB04B1934943A5C02806D1A2204B0414B2@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF0137640A@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0137640A@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F21587B6A50CE419D4A11EB6F670A05@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1356124869 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117682 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "straw-ads@tools.ietf.org" , "straw-chairs@tools.ietf.org" , "straw@ietf.org" , Christer Holmberg Subject: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:21:18 -0000 Hi Andy, thanks for reviewing the draft! Comments/actions inline... On Nov 30, 2012, at 11:56 AM, "Hutton, Andrew" wrote: > 1. Abstract. Could do with a bit more detail on what a SIP B2BUA actually= is and the roles it performs the statement "... performing different roles= in different ways" is I think a bit too vague. Maybe you could mention so= me examples includes SBC's and Application Servers. I can add that example - would that be sufficient for the abstract? >=20 > 2. Section 2, 3rd para. ", the odds of a SIP session the odds of a SIP se= ssion crossing such media-plane B2BUAs increases". I am not sure of the rel= evance of "media-plane B2BUAs" in this context. In fact I think it would no= t harm to lose this paragraph altogether. The point of it was to explain to folks why they should care. A lot of peo= ple think of their own B2BUA being deployed in isolation, rather than the S= IP call continuing to hit other B2BUAs along its way to wherever it's going= . OK to keep it? > 3. Section 3.1 states "This implies it does not modify SDP bodies, althou= gh it may save them and/or operate on other MIME body types". This is incor= rect and in fact the subsection 3.1.3 describes such a B2BUA which does mod= ify SDP. I suggest the following text "A Signaling-plane B2BUA is one that = operates only on the SIP message protocol layer, and only with SIP messages= , bodies, and headers but not the media itself in any way". The sentence a= bout other MIME body types can then be removed. >=20 > 4. Section 3.1.2 and 3.1.3. I am not sure why it is necessary to separate= the "SDP-Modifying Signaling Only" B2BUA from the "Signaling Only B2BUA". = The signaling only B2BUA section states that such a B2B UA may "modify or i= nspect specific MIME bodies," why does it not just include SDP as one of th= e MIME types a signaling-only B2BUA may modify? Because for RAI mechanisms which use this taxonomy doc, it may make a big d= ifference - i.e., if you define something that operates in SDP it will not = matter to "normal" signaling B2BUAs, but may have an impact for SDP-aware o= nes. For example the BUNDLE stuff, or much of MMUSIC's work. If you're a vendor that builds a B2BUA that is agnostic to SDP, you don't h= ave to worry about BUNDLE et al. If you build a signaling B2BUA that inspe= cts/modifies SDP, you do... even if your B2BUA doesn't actually handle medi= a itself. >=20 > 5. Section 4.1 "SIP PBXs and Softswitches". I don't understand the refere= nce to the UAC & UAS being "connected with a logical PRI loopback;". I don'= t think this is really a valid analogy. If it is meant to mean there may be= signaling transcoding between the SIP UAS and UAC then that it is what it = should say.=20 It's just meant to explain that the term 'PBX' is a marketing term, and tha= t in practice some PBXes are full B2BUAs at all layers, while some are not.= (In a previous life I worked on a PBX that was a UAC/UAS with a logical TD= M layer connecting the call-halves) >=20 > 6. Section 4.2. "Poxy-B2BUA" -> "Proxy-B2BUA" I assume Yup. >=20 > 7. Section 4.4 The last sentence states: >=20 > "Some transcoders save and remove SDP offers in INVITEs form the UAC, and= wait for an offer in the response from the UAS, similar to a 3PCC model; o= thers just insert additional codecs in SDP offers and only transcode if the= inserted codec(s) are selected in the answer." >=20 > I think this goes in to too much detail about how a transcoder might work= is not necessary and anyway the 3PCC bit sounds like rather dubious practi= ce which we don't need to say anything about. This whole section (section 4) is about what SIP device types in the market= match up to what B2BUA roles in this doc. It does not prescribe any behav= ior as being better or worse, but is more like a helper for normal (non-IET= F) people reading this doc. I have sen transcoders operate in the 3pcc man= ner, and others not. So the point of calling it out here was to say "it de= pends, and there is no one-size-fits-all mapping in call cases". -hadriel From btv1==702717fa800==HKaplan@acmepacket.com Fri Dec 21 13:45:53 2012 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4150121F88E8 for ; Fri, 21 Dec 2012 13:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh8CKBIowigp for ; Fri, 21 Dec 2012 13:45:50 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1404F21F879E for ; Fri, 21 Dec 2012 13:45:50 -0800 (PST) X-ASG-Debug-ID: 1356126348-03fc200e93235b70001-uMHarY Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by mx1.acmepacket.com with ESMTP id IgBfBrd6auTDHG55 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 16:45:48 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.174]) by Mail1.acmepacket.com ([169.254.1.77]) with mapi id 14.02.0283.003; Fri, 21 Dec 2012 16:45:47 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-ASG-Orig-Subj: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 Thread-Index: AQHN38SI4pmwXG7kEEytjVMNNWesbA== Date: Fri, 21 Dec 2012 21:45:46 +0000 Message-ID: References: <50BFD464.6090204@alum.mit.edu> In-Reply-To: <50BFD464.6090204@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1356126348 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117684 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Victor Pascual , "" , Christer Holmberg Subject: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:45:53 -0000 Hi Paul, thanks for reviewing the draft! Comments/actions inline... On Dec 5, 2012, at 6:10 PM, Paul Kyzivat wrote: > I've only been looking at changes in this for awhile. Now that we are at = WGLC I actually carefully read through it again. I have more comments than = I thought I would. >=20 > Section 3: >=20 > Within the context of this document, the terms refer to a B2BUA > role, not a particular system type. A given system type may change > its role in the middle of a SIP session, for example when a Stateful > Proxy tears-down a session by generating BYEs; or for example when > an SBC performs transcoding or REFER termination. >=20 > The first example above is good. But I don't understand how the mentioned= SBC demonstrates the point of this paragraph. How is this SBC changing rol= e? A few more words to explain this would help. OK I'll add them. >=20 > Same section: >=20 > Likewise, a one-armed > third-party call control transcoder as described in section 3.1 of > [RFC5369] is not a B2BUA; whereas an inline transcoder based on > [RFC5370] is a B2BUA. >=20 > IMO this is very subjective. There clearly *is* a distinction between the= two cases, but that doesn't necessarily mean they aren't both B2BUAs. It w= ould be very helpful to have both types of transcoders included so that it = is possible to contrast the differences between the two. >=20 > I think the problem here is that we don't have clear criteria for what to= include and what to exclude. In this case I think the key distinction is w= hether or not the transcoder is on the signaling path between the caller an= d the UA that represents the callee. (Interestingly, that is also true of a= conference focus, and for a UA that splits a multimedia call, sending the = different media to different devices.) So maybe that is the criterion that = matters. If so, it would be helpful to explicitly state this and ensure tha= t the decisions are all made based on this. Right, exactly - it goes back to the debate we've had in the WG about wheth= er a server acting as a UAS for multiple sessions (ie, is the target of the= m) is a "B2BUA" in the sense that we want to cover it with this doc, or not= . I don't believe there's been resolution on that, has there? > Section 3.1.1: >=20 > As I brought up at the Atlanta meeting, a Proxy-B2BUA that generates in-d= ialog messages will need to "make room" in the progression of CSeq values f= or the messages it generates. This means, once it generates a message, that= CSeq values will differ on the two "sides". The b2bua then must modify CSe= q values to perform the mapping. >=20 > (A Proxy-B2BUA that only generates a BYE message probably segments the se= ssion at that time, no longer forwarding messages, and so won't need to upd= ate CSeq values. But it will still need to know what CSeq value it can use = for the BYE, so it will need to keep state.) >=20 > This is a fairly significant issue, and IMO should be mentioned explicitl= y. Right, Brett Tate had brought this up as well, when the draft used to descr= ibe that a Proxy-B2BUA might send UPDATEs for session refresh/liveness. So= I deleted the sentence that said so, in order to avoid having to explain w= hat all such a Proxy-B2BUA might need to do. But I'll put it in, as you've pointed out it's unavoidable. :) >=20 > Section 3.1.2: >=20 > I have always considered that there is a major distinction between those = b2buas that replace the Contact with one of their own, and those that leave= the Contact and use Record-Route to stay in the call. >=20 > For example, one that replaces the contact can potentially use callee-cap= s to represent its capabilities/features, while the other kind must use Pro= xy-Feature to identify itself. The Proxy-Feature draft danced all around th= is, pretending it was only talking about proxies when in fact we all know i= t was intending to cover B2BUAs. If it had been able to reference this draf= t then having that distinction available could have been important. What textual changes do you want made to the draft for the above? > Section 3.2: >=20 > Such a B2BUA may or may not replace the > Contact URI, modify or remove all Via and Record-Route headers, > modify the To and From header fields, etc. >=20 > I think you are saying that any of the Media-plane roles is compatible wi= th any of the Signaling-plane roles. I wish you would say it explicitly. >=20 > This would then mean that we could describe every B2BUA by naming both it= s signaling role and its media role. That as not my intention - I think any media-plane B2BUA has to modify the = SDP, so the intention was that media-plane B2BUAs are a superset-of/go-beyo= nd the SDP-modifying signaling level. > Section 3.2.1: >=20 > Such a role may only > support UDP or only TCP or both, as well as other transport types or > not. >=20 > Should these be different roles? Should what be different roles? I'm confused by what you're referring to. >=20 > What does it mean to *not* support some transport type? Does it mean that= it is a signaling-only B2BUA wrt that media? Or that it blocks that media? > (ISTM blocking the media is a signaling-only function - a variant on the = SDP-Modifying Signaling-only role.) In practice I've only ever seen such devices block TCP media (or even just = fail calls with TCP-based media). But I guess one could do a hybrid. Does= it matter though? I mean if there's some new TCP-based media mechanism co= ming out of MMUSIC, that needs to say something about B2BUAs, can't they ju= st say "Media-relay B2BUAs as defined in [RFCXXXX] need to support TCP and = do X for our new mechanism to work"? >=20 > Section 4.4: >=20 > ... Some transcoders > save and remove SDP offers in INVITEs form the UAC, ... >=20 > s/form/from/ Done. >=20 > idnits reports: >=20 > The document doesn't use any RFC 2119 keywords, > yet seems to have RFC 2119 boilerplate text. Right, I'm removing the 2119 boilerplate per someone else's review. -hadriel