From christer.holmberg@ericsson.com Wed Jun 1 00:04:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013A4E0741 for ; Wed, 1 Jun 2011 00:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-M2XNHMnVTX for ; Wed, 1 Jun 2011 00:04:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D3F30E0697 for ; Wed, 1 Jun 2011 00:04:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-bc-4de5e473ce13 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 83.7F.20773.374E5ED4; Wed, 1 Jun 2011 09:04:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 1 Jun 2011 09:04:16 +0200 From: Christer Holmberg To: Saul Ibarra Corretge Date: Wed, 1 Jun 2011 09:04:16 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwgKRIuENJ6wrr7SaOdrmhpsv0/QgAAOa5w Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C96@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> <76E967BB-C645-4BC6-836C-8AF628A4EBA0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C73@ESESSCMS0356.eemea.ericsson.se> <2322F281-5AFD-4162-A07B-944C53576324@ag-projects.com> In-Reply-To: <2322F281-5AFD-4162-A07B-944C53576324@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:04:23 -0000 Hi,=20 >Great! I really like that we have this as a must, it means we=20 >have no breakage when users behind an ALG and users not=20 >behind an ALG interact with each other :-) Yes. It is also good because it will allow 4975 UAs to communicate with each oth= er when there is an ALG in the path. Regards, Christer From christer.holmberg@ericsson.com Wed Jun 1 02:02:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6241AE07A6 for ; Wed, 1 Jun 2011 02:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYcioAKvUm0A for ; Wed, 1 Jun 2011 02:02:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D1E07A1 for ; Wed, 1 Jun 2011 02:02:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f3-4de600282448 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.5B.20773.82006ED4; Wed, 1 Jun 2011 11:02:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 1 Jun 2011 11:02:30 +0200 From: Christer Holmberg To: Ben Campbell Date: Wed, 1 Jun 2011 11:02:28 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: Acwf2kvKZsy5Z3jcT32kGst7Z3dT3QATisjAAARuySA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4E5A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 09:02:35 -0000 =20 Actually, when reading RFC 4975 it is a little unclear what address will be= in the SDP c/m-line when a UA uses a relay. There is text saying: "MSRP devices do not use the c-line address field, or the m-line port and format list fields to determine where to connect. Rather, they use the attributes defined in this specification. The connection information is copied to the c-line and m-line for purposes of backwards compatibility with conventional SDP usages. While MSRP could theoretically carry any media-type, "message" is appropriate." In my opinion "connection information" refers to the address where a connec= tion is to be established, and that is the address of the relay. IF we can assume that the c/m-line contains the relay address, then B2BUA m= ode will only be used when the UA behind the relay is "active". Regards, Christer > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 1. kes=E4kuuta 2011 9:59 > To: Ben Campbell > Cc: simple@ietf.org > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 >=20 > Hi Ben,=20 >=20 > >How does this work when the peer is behind an MSRP Relay?=20 > >Keep in mind that, in this case, the c/m lines will refer to the=20 > >endpoint itself, not to the relay. >=20 > You are probably right. If the 4975 UA is behind a relay, the=20 > sessmatch UA needs to trigger a fallback to 4975 (in a=20 > similar way as when the 4975 UA is "active"). The sessmatch=20 > UA can do if it detects that the remote SDP contains multiple=20 > a=3Dpath attributes, indicating that there is relay(s) in the path. >=20 > The reason is that the 4975 UA has inserted its own address=20 > in the SDP c-line (at least I can't find text in RFC 4976=20 > which says otherwise), so the ALG would try to connect to the=20 > 4975 UA rather than the relay. >=20 > Good point! >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > On May 30, 2011, at 2:40 PM, Christer Holmberg wrote: > >=20 > > > Hi, > > >=20 > > > Based on the issues that have been raised on sessmatch, I > > would like to present a modified version, that solves some of the=20 > > raised issues related to security, backward compability,=20 > usage of the=20 > > Require header filed, and specifying of ALG behavior. It has the=20 > > following advantages over the current sessmatch mechanism: > > >=20 > > > 1. Except for one case, that still requires MSRP B2BUA, it > > works with > > > "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the > > > a=3Dpath) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA; > > >=20 > > > 2. It works with name based authentication; > > >=20 > > > 3. It works when a 4975 UA is behind a relay; > > >=20 > > > 4. It works without a need for the offerer, or for the > > SIP-ALG, to use > > > the Require header field; and > > >=20 > > > 5. It atually REMOVES the need to update the session matching=20 > > > procedure in the first place :) > > >=20 > > >=20 > > > The idea is based on the very original sessmatch proposal, > > where a sessmatch UA sends the TCP SYN for the MSRP=20 > connection based=20 > > on the SDP c/m-line, rather than the a=3Dpath. > > >=20 > > > BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI > > into the MSRP message, use it for name based=20 > authentication, and use=20 > > if for session matching - all according to existing RFC 4975=20 > > procedures. > > >=20 > > >=20 > > > Let's look at how it works. > > >=20 > > >=20 > > > Peer-to-peer (no SIP-ALG) > > > ----------------------------- > > >=20 > > > As in the current sessmatch proposal, there is still full > > backward compability. As the a=3Dpath and SDP c/m-line values will be=20 > > identical, it doesn't matter which the sessmatch UA uses=20 > for sending=20 > > the TCP SYN. > > >=20 > > > (In fact, we could even specify that the sessmatch UA uses > > the a=3Dpath > > > in case it is identical to the SDP c/m-line, and everything > > would be > > > identical to RFC 4975.) > > >=20 > > >=20 > > > SIP-ALG in the path > > > --------------------- > > >=20 > > >=20 > > > 1. A sessmatch UA sends a request that offers MSRP, and > > includes a sessmatch support indication (option-tag, SDP=20 > attribute, or=20 > > whatever we choose). > > >=20 > > > 2. The SIP-ALG modifies the SDP c/m-line of the offer, and > > the corresponding answer, in order to anchor the MSRP media.=20 > > The a=3Dpath is NOT modified. > > >=20 > > > 3. The sessmatch UA receives the answer from the remote UA. > > >=20 > > > 4a. If the remote UA supports sessmatch, everthing is fine.=20 > > Whoever is "active" sends the TCP SYN according to the SDP c/m line=20 > > (which points to the ALG). > > >=20 > > > 4b. If the remote UA does NOT support sessmatch, BUT is > > "passive" (default if it does not support MSRP ACM), everything is=20 > > fine. The sessmatch sends the TCP SYN according to the SDP c/m line=20 > > (which points to the ALG). > > >=20 > > > 4c. If the remote UA does NOT support sessmatch, AND is > > "active", things will NOT work (unless SIP-ALG bypass is=20 > allowed), as=20 > > the remote UA will try to send the TCP SYN according to=20 > a=3Dpath (which=20 > > points to the sessmatch UA, rather than to the ALG). > > >=20 > > > 5. In case of 4c, the sessmatch UA does a "fallback" to > > 4975, by sending a new offer where it does NOT include a sessmatch=20 > > support indication. The SIP-ALG, in order to support MSRP, will now=20 > > have to enable MSRP B2BUA functionality. > > >=20 > > >=20 > > > It works the same in the other direction, where the 4975 UA > > sends the offer. If the 4975 UA becomes "active", the sessmatch UA=20 > > will have to send an offer without sessmatch indication. > > >=20 > > >=20 > > > Regards, > > >=20 > > > Christer > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www.ietf.org/mailman/listinfo/simple > >=20 > >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From ben@estacado.net Wed Jun 1 06:18:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB3E07EC for ; Wed, 1 Jun 2011 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN5wuUqCLK8S for ; Wed, 1 Jun 2011 06:18:06 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id F37E8E06D4 for ; Wed, 1 Jun 2011 06:18:04 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p51DHrdA031036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2011 08:17:58 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:17:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:18:07 -0000 On Jun 1, 2011, at 1:58 AM, Christer Holmberg wrote: >=20 > Hi Ben,=20 >=20 >> How does this work when the peer is behind an MSRP Relay?=20 >> Keep in mind that, in this case, the c/m lines will refer to=20 >> the endpoint itself, not to the relay. >=20 > You are probably right. If the 4975 UA is behind a relay, the = sessmatch UA needs to trigger a fallback to 4975 (in a similar way as = when the 4975 UA is "active"). The sessmatch UA can do if it detects = that the remote SDP contains multiple a=3Dpath attributes, indicating = that there is relay(s) in the path. >=20 > The reason is that the 4975 UA has inserted its own address in the SDP = c-line (at least I can't find text in RFC 4976 which says otherwise), so = the ALG would try to connect to the 4975 UA rather than the relay. I looked for that too, and can't find anything that tells an endpoint to = use the relay address/port in c/m. >=20 > Good point! >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> On May 30, 2011, at 2:40 PM, Christer Holmberg wrote: >>=20 >>> Hi, >>>=20 >>> Based on the issues that have been raised on sessmatch, I=20 >> would like to present a modified version, that solves some of=20 >> the raised issues related to security, backward compability,=20 >> usage of the Require header filed, and specifying of ALG=20 >> behavior. It has the following advantages over the current=20 >> sessmatch mechanism: >>>=20 >>> 1. Except for one case, that still requires MSRP B2BUA, it=20 >> works with=20 >>> "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the=20 >>> a=3Dpath) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA; >>>=20 >>> 2. It works with name based authentication; >>>=20 >>> 3. It works when a 4975 UA is behind a relay; >>>=20 >>> 4. It works without a need for the offerer, or for the=20 >> SIP-ALG, to use=20 >>> the Require header field; and >>>=20 >>> 5. It atually REMOVES the need to update the session matching=20 >>> procedure in the first place :) >>>=20 >>>=20 >>> The idea is based on the very original sessmatch proposal,=20 >> where a sessmatch UA sends the TCP SYN for the MSRP=20 >> connection based on the SDP c/m-line, rather than the a=3Dpath. >>>=20 >>> BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI=20 >> into the MSRP message, use it for name based authentication,=20 >> and use if for session matching - all according to existing=20 >> RFC 4975 procedures. >>>=20 >>>=20 >>> Let's look at how it works. >>>=20 >>>=20 >>> Peer-to-peer (no SIP-ALG) >>> ----------------------------- >>>=20 >>> As in the current sessmatch proposal, there is still full=20 >> backward compability. As the a=3Dpath and SDP c/m-line values=20 >> will be identical, it doesn't matter which the sessmatch UA=20 >> uses for sending the TCP SYN.=20 >>>=20 >>> (In fact, we could even specify that the sessmatch UA uses=20 >> the a=3Dpath=20 >>> in case it is identical to the SDP c/m-line, and everything=20 >> would be=20 >>> identical to RFC 4975.) >>>=20 >>>=20 >>> SIP-ALG in the path >>> --------------------- >>>=20 >>>=20 >>> 1. A sessmatch UA sends a request that offers MSRP, and=20 >> includes a sessmatch support indication (option-tag, SDP=20 >> attribute, or whatever we choose). >>>=20 >>> 2. The SIP-ALG modifies the SDP c/m-line of the offer, and=20 >> the corresponding answer, in order to anchor the MSRP media.=20 >> The a=3Dpath is NOT modified. >>>=20 >>> 3. The sessmatch UA receives the answer from the remote UA. >>>=20 >>> 4a. If the remote UA supports sessmatch, everthing is fine.=20 >> Whoever is "active" sends the TCP SYN according to the SDP=20 >> c/m line (which points to the ALG). >>>=20 >>> 4b. If the remote UA does NOT support sessmatch, BUT is=20 >> "passive" (default if it does not support MSRP ACM),=20 >> everything is fine. The sessmatch sends the TCP SYN according=20 >> to the SDP c/m line (which points to the ALG). >>>=20 >>> 4c. If the remote UA does NOT support sessmatch, AND is=20 >> "active", things will NOT work (unless SIP-ALG bypass is=20 >> allowed), as the remote UA will try to send the TCP SYN=20 >> according to a=3Dpath (which points to the sessmatch UA, rather=20 >> than to the ALG). >>>=20 >>> 5. In case of 4c, the sessmatch UA does a "fallback" to=20 >> 4975, by sending a new offer where it does NOT include a=20 >> sessmatch support indication. The SIP-ALG, in order to=20 >> support MSRP, will now have to enable MSRP B2BUA functionality. >>>=20 >>>=20 >>> It works the same in the other direction, where the 4975 UA=20 >> sends the offer. If the 4975 UA becomes "active", the=20 >> sessmatch UA will have to send an offer without sessmatch indication. >>>=20 >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >>=20 From ben@estacado.net Wed Jun 1 06:25:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DB8E079C for ; Wed, 1 Jun 2011 06:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 AlTf0iW6FT1A for ; Wed, 1 Jun 2011 06:25:02 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0CE07C2 for ; Wed, 1 Jun 2011 06:25:00 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p51DOplI032319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2011 08:24:57 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4E5A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:24:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4E5A@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:25:02 -0000 On Jun 1, 2011, at 4:02 AM, Christer Holmberg wrote: >=20 > Actually, when reading RFC 4975 it is a little unclear what address = will be in the SDP c/m-line when a UA uses a relay. >=20 > There is text saying: >=20 > "MSRP devices do not use the c-line address field, or the m-line > port and format list fields to determine where to connect. > Rather, they use the attributes defined in this specification. > The connection information is copied to the c-line and m-line for > purposes of backwards compatibility with conventional SDP usages. > While MSRP could theoretically carry any media-type, "message" is > appropriate." >=20 > In my opinion "connection information" refers to the address where a = connection is to be established, and that is the address of the relay. >=20 > IF we can assume that the c/m-line contains the relay address, then = B2BUA mode will only be used when the UA behind the relay is "active". >=20 =46rom 4975, section 8.1: > The network type and address type fields are used as normal for = SDP. > The connection address field MUST be set to the IP address or fully > qualified domain name from the MSRP URI identifying the endpoint in > its path attribute. >=20 and > The port field value MUST match the port value used in the = endpoint's > MSRP URI in the path attribute... I think that's pretty clear that it talks about the endpoint's MSRP URI, = since it uses the words "endpoint's MSRP URI". You might find implementers of 4976 deciding on their own to put the = first relay in a chain in the m/c lines. But since there's no guidance = to do that in 4976, we can't depend on it. I'd be curious what any deployed implementations of 4976 do. From christer.holmberg@ericsson.com Wed Jun 1 06:31:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0BE080B for ; Wed, 1 Jun 2011 06:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h7a1hot1-kG for ; Wed, 1 Jun 2011 06:31:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 63D3FE0808 for ; Wed, 1 Jun 2011 06:31:41 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-62-4de63f3c5ee9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 12.C1.09774.C3F36ED4; Wed, 1 Jun 2011 15:31:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 1 Jun 2011 15:31:40 +0200 From: Christer Holmberg To: Ben Campbell Date: Wed, 1 Jun 2011 15:26:59 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwgX05iuA3hdwbsSnmbF32XQSBg6AAAEdq7 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3FC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4E5A@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:31:43 -0000 Hi, >> Actually, when reading RFC 4975 it is a little unclear what address will= be in the SDP c/m-line when a UA uses a relay. >> >> There is text saying: >> >> "MSRP devices do not use the c-line address field, or the m-line >> port and format list fields to determine where to connect. >> Rather, they use the attributes defined in this specification. >> The connection information is copied to the c-line and m-line for >> purposes of backwards compatibility with conventional SDP usages. >> While MSRP could theoretically carry any media-type, "message" is >> appropriate." >> >> In my opinion "connection information" refers to the address where a con= nection is to be established, and that is the address of the relay. >> >> IF we can assume that the c/m-line contains the relay address, then B2BU= A mode will only be used when the UA behind the relay is "active". >> > >From 4975, section 8.1: > > The network type and address type fields are used as normal for SDP. > The connection address field MUST be set to the IP address or fully > qualified domain name from the MSRP URI identifying the endpoint in > its path attribute. > > >and > > The port field value MUST match the port value used in the endpoint's > MSRP URI in the path attribute... > > >I think that's pretty clear that it talks about the endpoint's MSRP URI, s= ince it uses the words "endpoint's MSRP URI". > >You might find implementers of 4976 deciding on their own to put the first= relay in a chain in the m/c lines. But since there's no guidance to do tha= t in 4976, we can't depend on it. You're probably right. I also noted that the examples in section 11 of 4976= use the UA adderss in the c/m line. However, we CAN specify that a sessmatch UA behind a relay must insert the = address of the relay in the c/m line, and then there won't be a need for B2= BUA mode, at least not because of the sessmatch UA. Regards, Christer= From ag@ag-projects.com Wed Jun 1 06:34:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED915E0818 for ; Wed, 1 Jun 2011 06:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, WEIRD_PORT=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 Ph8lL+5mLmkR for ; Wed, 1 Jun 2011 06:34:55 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C6A6BE081E for ; Wed, 1 Jun 2011 06:32:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 456E2B01BA; Wed, 1 Jun 2011 15:32:27 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 1A468B017D; Wed, 1 Jun 2011 15:32:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-62948582 From: Adrian Georgescu In-Reply-To: Date: Wed, 1 Jun 2011 15:32:26 +0200 Message-Id: <628AFB9F-17F9-4955-BBFE-3E190CF4894C@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4E5A@ESESSCMS0356.eemea.ericsson.se> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:34:56 -0000 --Apple-Mail-2-62948582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > =46rom 4975, section 8.1: >=20 >> The network type and address type fields are used as normal for = SDP. >> The connection address field MUST be set to the IP address or fully >> qualified domain name from the MSRP URI identifying the endpoint in >> its path attribute. >>=20 >=20 >=20 > and >=20 >> The port field value MUST match the port value used in the = endpoint's >> MSRP URI in the path attribute... >=20 >=20 > I think that's pretty clear that it talks about the endpoint's MSRP = URI, since it uses the words "endpoint's MSRP URI". >=20 > You might find implementers of 4976 deciding on their own to put the = first relay in a chain in the m/c lines. But since there's no guidance = to do that in 4976, we can't depend on it. >=20 > I'd be curious what any deployed implementations of 4976 do. >=20 INVITE sip:agp@conference.sip2sip.info SIP/2.0 Via: SIP/2.0/UDP = 192.168.1.6:53801;rport;branch=3Dz9hG4bKPjKLKpmKrBKMsrbqm8N5K9YSGr9AyluN4b= Max-Forwards: 70 From: "Adrian Georgescu" = ;tag=3DaNgZOMfUHAWrZEk8O4V.UNTA7DhMjQBz To: Contact: Call-ID: URMwCeJgVDb88LWQnNTKryn1-Lu2LeRC CSeq: 24276 INVITE Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, = MESSAGE, REFER Supported: 100rel, norefersub User-Agent: Blink Pro 1.1.0 (MacOSX) Content-Type: application/sdp Content-Length: 411 v=3D0 o=3D- 3515923660 3515923660 IN IP4 192.168.1.6 s=3DBlink Pro 1.1.0 (MacOSX) c=3DIN IP4 192.168.1.6 t=3D0 0 m=3Dmessage 61328 TCP/TLS/MSRP * = a=3Dpath:msrps://node03.dns-hosting.info:2855/l/KNsOeOcGJ/5ZbY6lVRPDEzMDY5= MzQ4NjAuNDQyOjgwLjEwMS45Ni4yMA=3D=3D;tcp = msrps://192.168.1.6:61328/553d54d23aed8350fe25;tcp a=3Daccept-types:message/cpim text/* application/im-iscomposing+xml a=3Daccept-wrapped-types:* --Apple-Mail-2-62948582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=46rom 4975, section = 8.1:

  The network type and = address type fields are used as normal for = SDP.
  The = connection address field MUST be set to the IP address or = fully
  qualified = domain name from the MSRP URI identifying the endpoint = in
  its path = attribute.



and

  The port field value MUST match the port = value used in the endpoint's
=   MSRP URI in the path attribute...


I = think that's pretty clear that it talks about the endpoint's MSRP URI, = since it uses the words "endpoint's MSRP URI".

You might find = implementers of 4976 deciding on their own to put the first relay in a = chain in the m/c lines. But since there's no guidance to do that in = 4976, we can't depend on it.

I'd be curious what any deployed = implementations of 4976 = do.


Call-ID: = URMwCeJgVDb88LWQnNTKryn1-Lu2LeRC
CSeq: 24276 INVITE
Supported: 100rel, norefersub
Content-Type: = application/sdp
Content-Length:   411

v=3D0
c=3DIN IP4 192.168.1.6
t=3D0 0
61328 TCP/TLS/MSRP *
192.168.1.6:61328/553d54d23aed8350fe25;tcp


Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:37:08 -0000 --Apple-Mail-42-63216001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 1, 2011, at 8:32 AM, Adrian Georgescu wrote: >> =46rom 4975, section 8.1: >>=20 >>> The network type and address type fields are used as normal for = SDP. >>> The connection address field MUST be set to the IP address or = fully >>> qualified domain name from the MSRP URI identifying the endpoint = in >>> its path attribute. >>>=20 >>=20 >>=20 >> and >>=20 >>> The port field value MUST match the port value used in the = endpoint's >>> MSRP URI in the path attribute... >>=20 >>=20 >> I think that's pretty clear that it talks about the endpoint's MSRP = URI, since it uses the words "endpoint's MSRP URI". >>=20 >> You might find implementers of 4976 deciding on their own to put the = first relay in a chain in the m/c lines. But since there's no guidance = to do that in 4976, we can't depend on it. >>=20 >> I'd be curious what any deployed implementations of 4976 do. >>=20 >=20 > INVITE sip:agp@conference.sip2sip.info SIP/2.0 > Via: SIP/2.0/UDP = 192.168.1.6:53801;rport;branch=3Dz9hG4bKPjKLKpmKrBKMsrbqm8N5K9YSGr9AyluN4b= > Max-Forwards: 70 > From: "Adrian Georgescu" = ;tag=3DaNgZOMfUHAWrZEk8O4V.UNTA7DhMjQBz > To: > Contact: > Call-ID: URMwCeJgVDb88LWQnNTKryn1-Lu2LeRC > CSeq: 24276 INVITE > Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, = MESSAGE, REFER > Supported: 100rel, norefersub > User-Agent: Blink Pro 1.1.0 (MacOSX) > Content-Type: application/sdp > Content-Length: 411 >=20 > v=3D0 > o=3D- 3515923660 3515923660 IN IP4 192.168.1.6 > s=3DBlink Pro 1.1.0 (MacOSX) > c=3DIN IP4 192.168.1.6 > t=3D0 0 > m=3Dmessage 61328 TCP/TLS/MSRP * > = a=3Dpath:msrps://node03.dns-hosting.info:2855/l/KNsOeOcGJ/5ZbY6lVRPDEzMDY5= MzQ4NjAuNDQyOjgwLjEwMS45Ni4yMA=3D=3D;tcp = msrps://192.168.1.6:61328/553d54d23aed8350fe25;tcp > a=3Daccept-types:message/cpim text/* application/im-iscomposing+xml > a=3Daccept-wrapped-types:* >=20 >=20 Thanks Adrian! That has the endpoint address and port in c and m. I think that answers = the question. >=20 --Apple-Mail-42-63216001 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=46rom 4975, section 8.1:

  The network type and address type fields are = used as normal for SDP.
=   The connection address field MUST be set to the IP address = or fully
=   qualified domain name from the MSRP URI identifying the = endpoint in
  its = path attribute.



and

  The port field value MUST match the port = value used in the endpoint's
=   MSRP URI in the path attribute...


I = think that's pretty clear that it talks about the endpoint's MSRP URI, = since it uses the words "endpoint's MSRP URI".

You might find = implementers of 4976 deciding on their own to put the first relay in a = chain in the m/c lines. But since there's no guidance to do that in = 4976, we can't depend on it.

I'd be curious what any deployed = implementations of 4976 = do.


Call-ID: = URMwCeJgVDb88LWQnNTKryn1-Lu2LeRC
CSeq: 24276 INVITE
Supported: 100rel, norefersub
Content-Type: = application/sdp
Content-Length:   411

v=3D0
c=3DIN IP4 192.168.1.6
t=3D0 0
61328 TCP/TLS/MSRP *
192.168.1.6:61328/553d54d23aed8350fe25;tcp

Subject: [Simple] MSRP-sessmatch discussion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:24:42 -0000 (as chair) Hi everyone, We've had a lot of discussion about the msrp-sessmatch extension draft = over the last couple of weeks. For those who have been involved in or = are following the discussions, do you think that a face-to-face meeting = at IETF81 would help? We'd appreciate quick responses, since the deadline for requesting a = meeting slot is coming up Monday. Thanks! Ben. From christer.holmberg@ericsson.com Wed Jun 1 14:38:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25DE09A6 for ; Wed, 1 Jun 2011 14:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCJXqh7HJNqz for ; Wed, 1 Jun 2011 14:38:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 85779E09A1 for ; Wed, 1 Jun 2011 14:38:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ea-4de6b167c7d9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4A.90.09774.761B6ED4; Wed, 1 Jun 2011 23:38:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 1 Jun 2011 23:38:46 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG Date: Wed, 1 Jun 2011 23:38:46 +0200 Thread-Topic: [Simple] MSRP-sessmatch discussion Thread-Index: AcwgolWJsuSrWghaSR68NmWm+XFVpgAAHwY7 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple-chairs@tools.ietf.org Chairs" Subject: Re: [Simple] MSRP-sessmatch discussion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:38:52 -0000 Hi, Personally, at this point, I see no need for a face-to-face meeting. I don't want to wait for Quebec for making a decission on whether to move f= orward with the new sessmatch alternative.=20 Based on the feedback so far, people seem to be ok (or, at least more ok th= an before :) with it, and we intend to submit a new version of the draft, d= escribing the new alternative, by the end of next week. If anyone wants to = go on with the old alternative, I would ask him/her to indicate so asap, an= d justfiy why. Also, the new alternative solves some of the issues we've had in the past, = so those don't need to be discussed at all anymore. And, AFAIK, it hasn't b= rough up any NEW issues. Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben Ca= mpbell [ben@nostrum.com] Sent: Thursday, June 02, 2011 12:24 AM To: Simple WG Cc: simple-chairs@tools.ietf.org Chairs Subject: [Simple] MSRP-sessmatch discussion (as chair) Hi everyone, We've had a lot of discussion about the msrp-sessmatch extension draft over= the last couple of weeks. For those who have been involved in or are follo= wing the discussions, do you think that a face-to-face meeting at IETF81 wo= uld help? We'd appreciate quick responses, since the deadline for requesting a meetin= g slot is coming up Monday. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From adam@nostrum.com Wed Jun 1 14:57:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538BAE082A for ; Wed, 1 Jun 2011 14:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywE8q-mEsfgf for ; Wed, 1 Jun 2011 14:57:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69FCEE08E8 for ; Wed, 1 Jun 2011 14:57:35 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p51LvVlf061988 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 16:57:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4DE6B5CB.8000108@nostrum.com> Date: Wed, 01 Jun 2011 16:57:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] MSRP-sessmatch discussion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:57:47 -0000 I think it would be hard to gauge response this quickly. No one has had time to do the kind of serious analysis that would be necessary to determine whether the new proposal has any of the same kinds of flaws as the previous one. Personally, I haven't had time, in the almost two work days since it was published, to study whether the new mechanism introduces any showstopping incompatibilities. I'd be surprised if anyone else thinks they've done a suitable level of diligence either. If we go down the path of using a whole new mechanism, I can't imagine a world in which we don't need a face-to-face discussion in Quebec. /a On 6/1/11 4:38 PM, Christer Holmberg wrote: > Hi, > > Personally, at this point, I see no need for a face-to-face meeting. > > I don't want to wait for Quebec for making a decission on whether to move forward with the new sessmatch alternative. > > Based on the feedback so far, people seem to be ok (or, at least more ok than before :) with it, and we intend to submit a new version of the draft, describing the new alternative, by the end of next week. If anyone wants to go on with the old alternative, I would ask him/her to indicate so asap, and justfiy why. > > Also, the new alternative solves some of the issues we've had in the past, so those don't need to be discussed at all anymore. And, AFAIK, it hasn't brough up any NEW issues. > > Regards, > > Christer > > > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben Campbell [ben@nostrum.com] > Sent: Thursday, June 02, 2011 12:24 AM > To: Simple WG > Cc: simple-chairs@tools.ietf.org Chairs > Subject: [Simple] MSRP-sessmatch discussion > > (as chair) > > Hi everyone, > > We've had a lot of discussion about the msrp-sessmatch extension draft over the last couple of weeks. For those who have been involved in or are following the discussions, do you think that a face-to-face meeting at IETF81 would help? > > We'd appreciate quick responses, since the deadline for requesting a meeting slot is coming up Monday. > > Thanks! > > Ben. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ag@ag-projects.com Wed Jun 1 15:28:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87887E091E for ; Wed, 1 Jun 2011 15:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 3SH4fRDZQ9xl for ; Wed, 1 Jun 2011 15:28:24 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C1495E06D1 for ; Wed, 1 Jun 2011 15:28:23 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 630C2B01BC; Thu, 2 Jun 2011 00:28:20 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 764A6B00E6; Thu, 2 Jun 2011 00:28:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 2 Jun 2011 00:28:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <072E76F3-9E57-45DD-9936-4C8F61B8EA95@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Cc: "simple-chairs@tools.ietf.org Chairs" Subject: Re: [Simple] MSRP-sessmatch discussion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:28:24 -0000 Gents, Nobody can claim to understand the full consequences of this endless = trial-and error approach to legitimate the insertion of an intermediate = into an end-to-end Internet protocol. The consequences can only be seen = later after the damage has been done and too late for anyone to fix as = the working group has been closed. There is nothing OK with this draft, it is fundamentally wrong starting = with the very problem it tries to solve. Even worse, it creates a dangerous precedent to do similar things with = other Internet protocols in the future. Regards, Adrian On Jun 1, 2011, at 11:38 PM, Christer Holmberg wrote: > Hi, >=20 > Personally, at this point, I see no need for a face-to-face meeting. >=20 > I don't want to wait for Quebec for making a decission on whether to = move forward with the new sessmatch alternative.=20 >=20 > Based on the feedback so far, people seem to be ok (or, at least more = ok than before :) with it, and we intend to submit a new version of the = draft, describing the new alternative, by the end of next week. If = anyone wants to go on with the old alternative, I would ask him/her to = indicate so asap, and justfiy why. >=20 > Also, the new alternative solves some of the issues we've had in the = past, so those don't need to be discussed at all anymore. And, AFAIK, it = hasn't brough up any NEW issues. >=20 > Regards, >=20 > Christer >=20 >=20 > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Ben Campbell [ben@nostrum.com] > Sent: Thursday, June 02, 2011 12:24 AM > To: Simple WG > Cc: simple-chairs@tools.ietf.org Chairs > Subject: [Simple] MSRP-sessmatch discussion >=20 > (as chair) >=20 > Hi everyone, >=20 > We've had a lot of discussion about the msrp-sessmatch extension draft = over the last couple of weeks. For those who have been involved in or = are following the discussions, do you think that a face-to-face meeting = at IETF81 would help? >=20 > We'd appreciate quick responses, since the deadline for requesting a = meeting slot is coming up Monday. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Thu Jun 2 01:18:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2DE068B for ; Thu, 2 Jun 2011 01:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34g6ENampQwI for ; Thu, 2 Jun 2011 01:18:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 300ADE0734 for ; Thu, 2 Jun 2011 01:17:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ea-4de746db35c9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 75.80.09774.BD647ED4; Thu, 2 Jun 2011 10:16:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 2 Jun 2011 10:16:24 +0200 From: Christer Holmberg To: Adam Roach Date: Thu, 2 Jun 2011 10:11:59 +0200 Thread-Topic: [Simple] MSRP-sessmatch discussion Thread-Index: AcwgpumQnKOcRJHVS9eVjhFLqKeSpgAVdU6h Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A409@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se>, <4DE6B5CB.8000108@nostrum.com> In-Reply-To: <4DE6B5CB.8000108@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] MSRP-sessmatch discussion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 08:18:44 -0000 Hi Adam, I don't expect people to fully understand the new alternative just like tha= t. The general idea, however, should be quite easy to understand, so I was = more wondering whether people think we should even look into it.=20 But, then we of course need to make sure we get the details correct etc. BTW, regarding "a whole new mechanism", we would actually re-use more of th= e 4975 procedures than in the current mechanism :) Regards, Christer ________________________________________ From: Adam Roach [adam@nostrum.com] Sent: Thursday, June 02, 2011 12:57 AM To: Christer Holmberg Cc: Ben Campbell; Simple WG; simple-chairs@tools.ietf.org Chairs Subject: Re: [Simple] MSRP-sessmatch discussion I think it would be hard to gauge response this quickly. No one has had time to do the kind of serious analysis that would be necessary to determine whether the new proposal has any of the same kinds of flaws as the previous one. Personally, I haven't had time, in the almost two work days since it was published, to study whether the new mechanism introduces any showstopping incompatibilities. I'd be surprised if anyone else thinks they've done a suitable level of diligence either. If we go down the path of using a whole new mechanism, I can't imagine a world in which we don't need a face-to-face discussion in Quebec. /a On 6/1/11 4:38 PM, Christer Holmberg wrote: > Hi, > > Personally, at this point, I see no need for a face-to-face meeting. > > I don't want to wait for Quebec for making a decission on whether to move= forward with the new sessmatch alternative. > > Based on the feedback so far, people seem to be ok (or, at least more ok = than before :) with it, and we intend to submit a new version of the draft,= describing the new alternative, by the end of next week. If anyone wants t= o go on with the old alternative, I would ask him/her to indicate so asap, = and justfiy why. > > Also, the new alternative solves some of the issues we've had in the past= , so those don't need to be discussed at all anymore. And, AFAIK, it hasn't= brough up any NEW issues. > > Regards, > > Christer > > > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben = Campbell [ben@nostrum.com] > Sent: Thursday, June 02, 2011 12:24 AM > To: Simple WG > Cc: simple-chairs@tools.ietf.org Chairs > Subject: [Simple] MSRP-sessmatch discussion > > (as chair) > > Hi everyone, > > We've had a lot of discussion about the msrp-sessmatch extension draft ov= er the last couple of weeks. For those who have been involved in or are fol= lowing the discussions, do you think that a face-to-face meeting at IETF81 = would help? > > We'd appreciate quick responses, since the deadline for requesting a meet= ing slot is coming up Monday. > > Thanks! > > Ben. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple= From internet-drafts@ietf.org Fri Jun 3 08:06:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58342E0773; Fri, 3 Jun 2011 08:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-EHv9JXFZtr; Fri, 3 Jun 2011 08:06:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63F0E0763; Fri, 3 Jun 2011 08:06:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603150610.32690.55375.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2011 08:06:10 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-chat-09.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:06:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protoco= l (MSRP) Author(s) : Aki Niemi Miguel A. Garcia-Martin Geir A. Sandbakken Filename : draft-ietf-simple-chat-09.txt Pages : 32 Date : 2011-06-03 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-chat-09.txt From geirsand@cisco.com Fri Jun 3 08:17:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B838BE070F for ; Fri, 3 Jun 2011 08:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 ygwb84UFIesC for ; Fri, 3 Jun 2011 08:17:26 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 75F88E06E9 for ; Fri, 3 Jun 2011 08:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=geirsand@cisco.com; l=2125; q=dns/txt; s=iport; t=1307114246; x=1308323846; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=q1CaNvJUhg0NYiRfxEwgCw4pd0D5UqHmUOVStNQATEk=; b=ZhOL/PYd/YUUTPCdWbwm3JJZCjyVpginQLpx87c7v9CI2MDyoSoGkGpU D7o97sNoT7V5NUyh9L4JvDRPdtnr2jYlUxUgcMPhbXEwvctetRzdT30dR MoNOp4LRxxus1H3IpvfyfhzBdvqKFJvqTuhkDeRP63orEjElFUkuRyqk/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8bAMn66E2Q/khL/2dsb2JhbABTglKVSIZWHIZBagJ3qnSBHZ1qhiEEkHSEUYcMg14 X-IronPort-AV: E=Sophos;i="4.65,315,1304294400"; d="scan'208,217";a="33617182" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Jun 2011 15:17:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p53FHHXg000985 for ; Fri, 3 Jun 2011 15:17:17 GMT Received: from xmb-ams-213.cisco.com ([144.254.75.24]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 17:17:17 +0200 Received: from 173.38.133.8 ([173.38.133.8]) by XMB-AMS-213.cisco.com ([144.254.75.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Jun 2011 15:17:16 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 03 Jun 2011 17:17:16 +0200 From: Geir Arne Sandbakken To: Message-ID: Thread-Topic: Multi-party Chat version 9 submitted Thread-Index: AcwiABaEJQaJXt8ttEmnFo8ltF2iewAATvke In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389966236_5335162" X-OriginalArrivalTime: 03 Jun 2011 15:17:17.0023 (UTC) FILETIME=[5307BEF0:01CC2201] Subject: [Simple] Multi-party Chat version 9 submitted X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:17:27 -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_3389966236_5335162 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable A new version of Multi-party Chat Using the Message Session Relay Protocol (MSRP) has been submitted based on feedback and review from Miguel and Ben. The new version can be found here: http://www.ietf.org/id/draft-ietf-simple-chat-09.txt Changes from version =AD08: -------------------------------------------- - HTTP digest authentication change - Removed REQ-8 not addressed in the draft - Removed section 7.5 - Support of nickname extensions also recommended for endpoints - Added response in example - New wording in the security section - Two informative references made normative - Various ambiguous wording and spelling errors Thanks, Geir A --B_3389966236_5335162 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Multi-party Chat version 9 submitted A new version of Multi-party Chat Using the Message Session Relay Protocol= (MSRP) has been submitted based on feedback and review from Miguel and Ben.=

The new version can be found here:
http://www.i= etf.org/id/draft-ietf-simple-chat-09.txt

Changes from version –08:
--------------------------------------------
- HTTP digest authentication change
- Removed REQ-8 not addressed in the draft
- Removed section 7.5
- Support of nickname extensions also recommended for endpoints
- Added response in example
- New wording in the security section
- Two informative references made normative
-  Various ambiguous wording and spelling errors

Thanks,
Geir A
 --B_3389966236_5335162-- From christian.1.schmidt@nsn.com Mon Jun 6 08:15:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF3011E8166 for ; Mon, 6 Jun 2011 08:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbdrrqCxgaY8 for ; Mon, 6 Jun 2011 08:15:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DB6DA11E815C for ; Mon, 6 Jun 2011 08:15:54 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p56FFovR014760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jun 2011 17:15:50 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p56FFlIT011314; Mon, 6 Jun 2011 17:15:47 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Jun 2011 17:15:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2011 17:15:44 +0200 Message-ID: In-reply-to: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A409@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] MSRP-sessmatch discussion Thread-index: AcwgpumQnKOcRJHVS9eVjhFLqKeSpgAVdU6hANfhRAA= References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A408@ESESSCMS0356.eemea.ericsson.se>, <4DE6B5CB.8000108@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A409@ESESSCMS0356.eemea.ericsson.se> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Christer Holmberg" , "Adam Roach" X-OriginalArrivalTime: 06 Jun 2011 15:15:47.0235 (UTC) FILETIME=[9CC06F30:01CC245C] Cc: simple-chairs@tools.ietf.org, Simple WG Subject: Re: [Simple] MSRP-sessmatch discussion X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:15:56 -0000 Hi Christer, I think, this new idea is worth further investigation. Regards Christian -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Christer Holmberg Sent: Thursday, June 02, 2011 10:12 AM To: Adam Roach Cc: simple-chairs@tools.ietf.org Chairs; Simple WG Subject: Re: [Simple] MSRP-sessmatch discussion Hi Adam, I don't expect people to fully understand the new alternative just like that. The general idea, however, should be quite easy to understand, so I was more wondering whether people think we should even look into it.=20 But, then we of course need to make sure we get the details correct etc. BTW, regarding "a whole new mechanism", we would actually re-use more of the 4975 procedures than in the current mechanism :) Regards, Christer ________________________________________ From: Adam Roach [adam@nostrum.com] Sent: Thursday, June 02, 2011 12:57 AM To: Christer Holmberg Cc: Ben Campbell; Simple WG; simple-chairs@tools.ietf.org Chairs Subject: Re: [Simple] MSRP-sessmatch discussion I think it would be hard to gauge response this quickly. No one has had time to do the kind of serious analysis that would be necessary to determine whether the new proposal has any of the same kinds of flaws as the previous one. Personally, I haven't had time, in the almost two work days since it was published, to study whether the new mechanism introduces any showstopping incompatibilities. I'd be surprised if anyone else thinks they've done a suitable level of diligence either. If we go down the path of using a whole new mechanism, I can't imagine a world in which we don't need a face-to-face discussion in Quebec. /a On 6/1/11 4:38 PM, Christer Holmberg wrote: > Hi, > > Personally, at this point, I see no need for a face-to-face meeting. > > I don't want to wait for Quebec for making a decission on whether to move forward with the new sessmatch alternative. > > Based on the feedback so far, people seem to be ok (or, at least more ok than before :) with it, and we intend to submit a new version of the draft, describing the new alternative, by the end of next week. If anyone wants to go on with the old alternative, I would ask him/her to indicate so asap, and justfiy why. > > Also, the new alternative solves some of the issues we've had in the past, so those don't need to be discussed at all anymore. And, AFAIK, it hasn't brough up any NEW issues. > > Regards, > > Christer > > > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben Campbell [ben@nostrum.com] > Sent: Thursday, June 02, 2011 12:24 AM > To: Simple WG > Cc: simple-chairs@tools.ietf.org Chairs > Subject: [Simple] MSRP-sessmatch discussion > > (as chair) > > Hi everyone, > > We've had a lot of discussion about the msrp-sessmatch extension draft over the last couple of weeks. For those who have been involved in or are following the discussions, do you think that a face-to-face meeting at IETF81 would help? > > We'd appreciate quick responses, since the deadline for requesting a meeting slot is coming up Monday. > > Thanks! > > Ben. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From wwwrun@ietfa.amsl.com Mon Jun 6 09:43:53 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 322EC21F8523; Mon, 6 Jun 2011 09:43:53 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@ietfa.amsl.com, Context@ietfa.amsl.com (SNMP), EngineID@ietfa.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110606164353.322EC21F8523@ietfa.amsl.com> Date: Mon, 6 Jun 2011 09:43:53 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:43:53 -0000 'State Changes to RFC Published from Approved-announcement sent by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1 From Umang.Singh@globallogic.com Tue Jun 7 05:02:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE6811E80F6 for ; Tue, 7 Jun 2011 05:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXUyKjYHVu-7 for ; Tue, 7 Jun 2011 05:02:20 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2011E8101 for ; Tue, 7 Jun 2011 05:02:19 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hto9ko0171sa for ; Tue, 7 Jun 2011 17:32:16 +0530 (envelope-from ) Received: from ex2-del1.synapse.com ([172.16.2.50]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Tue, 07 Jun 2011 17:32:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 17:32:15 +0530 Message-ID: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: Acwffav2wYY0OBTxTUq0cwIfOZtMlgFi5FnQ References: From: "Umang Singh" To: X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201106071202160052504 Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 12:02:25 -0000 Hi Christer, What about the scenario where 2 RFC 4975 compliant UA's try to establish MSRP session on the basis of a=3Dpath with an ALG(more specifically SBC) in the path? As SBC won't modify the a=3Dpath, the UA's can bypass the = SBC in the media path. Media anchoring would not work in this case. The assumption that a firewall will drop any traffic not directed to the ALG might not be a valid one specially if both the UA's are in the same network. Also, one of the basic functions of the SBC is topology hiding which will not be done on the a=3Dpath attribute. I don't agree with mandating the fallback mechanism either. Apart from performance, another valid reason for not implementing the MSRP B2BUA functionality in SBC's is the cost associated with the same. Regards, Umang Date: Mon, 30 May 2011 21:40:25 +0200 From: Christer Holmberg To: "simple@ietf.org" Subject: [Simple] Sessmatch - an alternative approach Message-ID: =09 <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson. se> =09 Content-Type: text/plain; charset=3D"us-ascii" Hi, =20 Based on the issues that have been raised on sessmatch, I would like to present a modified version, that solves some of the raised issues related to security, backward compability, usage of the Require header filed, and specifying of ALG behavior. It has the following advantages over the current sessmatch mechanism: =20 1. Except for one case, that still requires MSRP B2BUA, it works with "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the a=3Dpath) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA; =20 2. It works with name based authentication; =20 3. It works when a 4975 UA is behind a relay; 4. It works without a need for the offerer, or for the SIP-ALG, to use the Require header field; and =20 5. It atually REMOVES the need to update the session matching procedure in the first place :) =20 =20 The idea is based on the very original sessmatch proposal, where a sessmatch UA sends the TCP SYN for the MSRP connection based on the SDP c/m-line, rather than the a=3Dpath. BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI into the MSRP message, use it for name based authentication, and use if for session matching - all according to existing RFC 4975 procedures. Let's look at how it works. Peer-to-peer (no SIP-ALG) ----------------------------- As in the current sessmatch proposal, there is still full backward compability. As the a=3Dpath and SDP c/m-line values will be identical, = it doesn't matter which the sessmatch UA uses for sending the TCP SYN.=20 (In fact, we could even specify that the sessmatch UA uses the a=3Dpath = in case it is identical to the SDP c/m-line, and everything would be identical to RFC 4975.) SIP-ALG in the path --------------------- 1. A sessmatch UA sends a request that offers MSRP, and includes a sessmatch support indication (option-tag, SDP attribute, or whatever we choose). 2. The SIP-ALG modifies the SDP c/m-line of the offer, and the corresponding answer, in order to anchor the MSRP media. The a=3Dpath is NOT modified. 3. The sessmatch UA receives the answer from the remote UA. 4a. If the remote UA supports sessmatch, everthing is fine. Whoever is "active" sends the TCP SYN according to the SDP c/m line (which points to the ALG). 4b. If the remote UA does NOT support sessmatch, BUT is "passive" (default if it does not support MSRP ACM), everything is fine. The sessmatch sends the TCP SYN according to the SDP c/m line (which points to the ALG). 4c. If the remote UA does NOT support sessmatch, AND is "active", things will NOT work (unless SIP-ALG bypass is allowed), as the remote UA will try to send the TCP SYN according to a=3Dpath (which points to the sessmatch UA, rather than to the ALG). 5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending a new offer where it does NOT include a sessmatch support indication. The SIP-ALG, in order to support MSRP, will now have to enable MSRP B2BUA functionality. It works the same in the other direction, where the 4975 UA sends the offer. If the 4975 UA becomes "active", the sessmatch UA will have to send an offer without sessmatch indication. =20 Regards, =20 Christer From saul@ag-projects.com Tue Jun 7 05:31:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCA921F8608 for ; Tue, 7 Jun 2011 05:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yEjGzC28-oR for ; Tue, 7 Jun 2011 05:31:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0942F11E808F for ; Tue, 7 Jun 2011 05:31:15 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 83347B01B9; Tue, 7 Jun 2011 14:31:14 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E7CCFB017D; Tue, 7 Jun 2011 14:31:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> Date: Tue, 7 Jun 2011 14:31:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> To: Umang Singh X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 12:31:17 -0000 Hi, On Jun 7, 2011, at 2:02 PM, Umang Singh wrote: > Hi Christer, > What about the scenario where 2 RFC 4975 compliant UA's try to = establish > MSRP session on the basis of a=3Dpath with an ALG(more specifically = SBC) > in the path? As SBC won't modify the a=3Dpath, the UA's can bypass the = SBC > in the media path. Media anchoring would not work in this case. The > assumption that a firewall will drop any traffic not directed to the = ALG > might not be a valid one specially if both the UA's are in the same > network. >=20 > Also, one of the basic functions of the SBC is topology hiding which > will not be done on the a=3Dpath attribute. >=20 Is there any document/draft/spec where SBC recommended or mandatory = features are listed? > I don't agree with mandating the fallback mechanism either. Apart from > performance, another valid reason for not implementing the MSRP B2BUA > functionality in SBC's is the cost associated with the same. >=20 Cost can't justify breaking an IETF protocol. What is your suggestion, = just not having a fallback mechanism? -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Jun 7 05:43:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD6811E80DA for ; Tue, 7 Jun 2011 05:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa5mlfaPALHW for ; Tue, 7 Jun 2011 05:43:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id BC70C11E808F for ; Tue, 7 Jun 2011 05:43:00 -0700 (PDT) Received: by qyk7 with SMTP id 7so3136828qyk.10 for ; Tue, 07 Jun 2011 05:43:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr4448950qcb.171.1307450579976; Tue, 07 Jun 2011 05:42:59 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 05:42:59 -0700 (PDT) In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> Date: Tue, 7 Jun 2011 14:42:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Umang Singh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 12:43:01 -0000 2011/6/7 Umang Singh : > Hi Christer, > What about the scenario where 2 RFC 4975 compliant UA's try to establish > MSRP session on the basis of a=3Dpath with an ALG(more specifically SBC) > in the path? As SBC won't modify the a=3Dpath, the UA's can bypass the SB= C > in the media path. Media anchoring would not work in this case. The > assumption that a firewall will drop any traffic not directed to the ALG > might not be a valid one specially if both the UA's are in the same > network. > > Also, one of the basic functions of the SBC is topology hiding which > will not be done on the a=3Dpath attribute. In this case the ALG/SBC would do just nothing (just changing the "m" line which means nothing in MSRP) so it would behave as a normal "router" without anchoring the media. Then the MSRP communication could work or not (depending on NAT scenario, MSRP relays, and so, like in a normal environment). What is the problem? in fact the "problem" you describe is the *normal* behaviour of an MSRP communication when there is no ALG/SBC. If an SBC cannot do its "magic", which is the problem? does such hipotetic problem deserve an IETF specification? > I don't agree with mandating the fallback mechanism either. Apart from > performance, another valid reason for not implementing the MSRP B2BUA > functionality in SBC's is the cost associated with the same. As I said above, if the SBC cannot do its ugly magic then just do nothing (things could work or not, as in the absence of the SBC). Or become a MSRP B2BUA if it supports it. But *why* should a IETF specification mandate this fallback mechanism? I insist: if there is not an SBC the MSRP communication could work or not, depending on NAT, presence of MSRP relays, etc). IETF does not (and cannot) mandate a "fallback mechanism" in this normal scenario, why should it mandate a "fallback mechanism" in case there is an ALG/SBC? This sounds terrible, even more taking into account that SBC/ALG's are specified nowhere and they basically breaks/corrupt OSI/Internet layers and Internet protocols. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jun 7 05:49:16 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B5F11E8105 for ; Tue, 7 Jun 2011 05:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sEUG092wnG3 for ; Tue, 7 Jun 2011 05:49:15 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id CC90511E80FA for ; Tue, 7 Jun 2011 05:49:14 -0700 (PDT) Received: by qyk7 with SMTP id 7so3140415qyk.10 for ; Tue, 07 Jun 2011 05:49:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr4453892qcb.171.1307450954321; Tue, 07 Jun 2011 05:49:14 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 05:49:14 -0700 (PDT) In-Reply-To: <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> Date: Tue, 7 Jun 2011 14:49:14 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 12:49:16 -0000 2011/6/7 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> I don't agree with mandating the fallback mechanism either. Apart from >> performance, another valid reason for not implementing the MSRP B2BUA >> functionality in SBC's is the cost associated with the same. >> > > Cost can't justify breaking an IETF protocol. What is your suggestion, ju= st not having a fallback mechanism? If Alice and Bob, behind different NAT routers (no ALG) and with no MSRP relays, try to establish an MSRP communication, it would fail (obvious). Should IETF mandate (MUST) that in this case the *normal* NAT router (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback mechanism"? If the answer is "not" (and of course it's "not"), why should IETF mandate such a mechanism for an ALG/SBC box? So, if the ALG cannot anchor the MSRP media let it to behave as a "normal IP/TCP box" which does not play at protocol level. If some vendor wants to include "fallback mechanism behaving as a MSRP B2BUA" it's ok, but why to mandate it? --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jun 7 06:38:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81E21F84A7 for ; Tue, 7 Jun 2011 06:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QhS4cxsMLkS for ; Tue, 7 Jun 2011 06:38:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3921F84A2 for ; Tue, 7 Jun 2011 06:38:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-5d-4dee29d0d5c5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F7.6E.09774.0D92EED4; Tue, 7 Jun 2011 15:38:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 7 Jun 2011 15:38:23 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Tue, 7 Jun 2011 15:38:22 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlEVPwsC3Kt5N4R+KBKYUe02ddwQABKAGw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E323A80@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:38:26 -0000 Hi, I am not sure I understood the issues - maybe I should have waited for 30-4= 0 additional e-mails before replying ;) Anyway, let's start where we were before sessmatch: If two 4975 UAs wanted to communicate, and there was an ALG present in the = network, unless the ALG acted as a MSRP B2BUA (or, allowed bypass, which I = don't think it very uncommon - there is a reason ALGs are inserted) things = wouldn't not work. We can blame whoever, but that's a fact. Now, let's see wehre we are today: What sessmatch suggests, is that ALGs do implement MSRP B2BUA functionality= . Not only will it allow sessmatch UAs to communicate with 4975 UAs in any = scenario (again, the B2BUA functionality does not need to be applied in all= cases), but it will also allow 4975 UAs to communicate with each other. If a vendors chooses not to implement the specification, there is nothing w= e can do about that. If a vendor chooses not to implement it, they will be = able to keep their ALGs, *AND* support MSRP, but without having to apply B2= BUA functionality for every call.=20 If you are a customer who needs an ALG, but also wants to provide MSRP, whi= ch vendor would you choose? Regards, Christer =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of I=F1aki Baz Castillo > Sent: 7. kes=E4kuuta 2011 15:49 > To: Sa=FAl Ibarra Corretg=E9 > Cc: Umang Singh; simple@ietf.org > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 > 2011/6/7 Sa=FAl Ibarra Corretg=E9 : > >> I don't agree with mandating the fallback mechanism either. Apart=20 > >> from performance, another valid reason for not=20 > implementing the MSRP=20 > >> B2BUA functionality in SBC's is the cost associated with the same. > >> > > > > Cost can't justify breaking an IETF protocol. What is your=20 > suggestion, just not having a fallback mechanism? >=20 > If Alice and Bob, behind different NAT routers (no ALG) and=20 > with no MSRP relays, try to establish an MSRP communication,=20 > it would fail (obvious). > Should IETF mandate (MUST) that in this case the *normal* NAT=20 > router (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback=20 > mechanism"? > If the answer is "not" (and of course it's "not"), why should=20 > IETF mandate such a mechanism for an ALG/SBC box? >=20 > So, if the ALG cannot anchor the MSRP media let it to behave=20 > as a "normal IP/TCP box" which does not play at protocol=20 > level. If some vendor wants to include "fallback mechanism=20 > behaving as a MSRP B2BUA" > it's ok, but why to mandate it? >=20 >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From christer.holmberg@ericsson.com Tue Jun 7 06:47:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5089F21F851F for ; Tue, 7 Jun 2011 06:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl5JOqRwKPiL for ; Tue, 7 Jun 2011 06:47:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBF221F851D for ; Tue, 7 Jun 2011 06:47:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-22-4dee2be4b02f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.AA.20773.4EB2EED4; Tue, 7 Jun 2011 15:47:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 7 Jun 2011 15:47:16 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Tue, 7 Jun 2011 15:47:14 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlEVPwsC3Kt5N4R+KBKYUe02ddwQAB6YFw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E323A9E@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:47:18 -0000 Hi,=20 >If Alice and Bob, behind different NAT routers (no ALG) and=20 >with no MSRP relays, try to establish an MSRP communication,=20 >it would fail (obvious). >Should IETF mandate (MUST) that in this case the *normal* NAT=20 >router (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback=20 >mechanism"? >If the answer is "not" (and of course it's "not"), why should=20 >IETF mandate such a mechanism for an ALG/SBC box? >=20 >So, if the ALG cannot anchor the MSRP media let it to behave=20 >as a "normal IP/TCP box" which does not play at protocol=20 >level. If some vendor wants to include "fallback mechanism=20 >behaving as a MSRP B2BUA" >it's ok, but why to mandate it? Let's be clear. Sessmatch is ONLY talking about ALGs that need to be able t= o modify the SDP in order to anchor media. If they choose to instead behave like a normal IP/TCP box, or whatever, of = course they don't need to implement B2BUA functionality. Regards, Christer From ibc@aliax.net Tue Jun 7 07:04:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0D21F854D for ; Tue, 7 Jun 2011 07:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1B51Ay0LC+R for ; Tue, 7 Jun 2011 07:04:49 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5521F854C for ; Tue, 7 Jun 2011 07:04:49 -0700 (PDT) Received: by qyk29 with SMTP id 29so1843981qyk.10 for ; Tue, 07 Jun 2011 07:04:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr4527274qcb.171.1307455488656; Tue, 07 Jun 2011 07:04:48 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 07:04:48 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E323A9E@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E323A9E@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Jun 2011 16:04:48 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:04:50 -0000 2011/6/7 Christer Holmberg : > Let's be clear. Sessmatch is ONLY talking about ALGs that need to be able= to modify the SDP in order to anchor media. > > If they choose to instead behave like a normal IP/TCP box, or whatever, o= f course they don't need to implement B2BUA functionality. That's the point. And since ALG's are "anomalies" (don't take me wrong), why should them be specified my an IETF document? and why should such a document mandate nothing about an ALG? I like the new specification proposal as ***it does not break nothing that would work without the ALG box in the middle*** but, anyhow, why to make an IETF specification about ALG's? --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Tue Jun 7 07:08:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D35921F8558 for ; Tue, 7 Jun 2011 07:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3U3m7SNILPo for ; Tue, 7 Jun 2011 07:08:52 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2099921F854D for ; Tue, 7 Jun 2011 07:08:52 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 5F8F9B01B9; Tue, 7 Jun 2011 16:08:51 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A15C5B017D; Tue, 7 Jun 2011 16:08:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Tue, 7 Jun 2011 16:08:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:08:52 -0000 On Jun 7, 2011, at 2:49 PM, I=F1aki Baz Castillo wrote: > 2011/6/7 Sa=FAl Ibarra Corretg=E9 : >>> I don't agree with mandating the fallback mechanism either. Apart = from >>> performance, another valid reason for not implementing the MSRP = B2BUA >>> functionality in SBC's is the cost associated with the same. >>>=20 >>=20 >> Cost can't justify breaking an IETF protocol. What is your = suggestion, just not having a fallback mechanism? >=20 > If Alice and Bob, behind different NAT routers (no ALG) and with no > MSRP relays, try to establish an MSRP communication, it would fail > (obvious). > Should IETF mandate (MUST) that in this case the *normal* NAT router > (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback mechanism"? > If the answer is "not" (and of course it's "not"), why should IETF > mandate such a mechanism for an ALG/SBC box? >=20 The sessmatch spec is targeted towards ALGs that modify the SDP for = anchoring media, not home routers. > So, if the ALG cannot anchor the MSRP media let it to behave as a > "normal IP/TCP box" which does not play at protocol level. If some > vendor wants to include "fallback mechanism behaving as a MSRP B2BUA" > it's ok, but why to mandate it? >=20 The draft should probably change the title (since 'sessmatch' doesn't = really apply now) and also mention that this is behavior specific to = ALGs. -- Sa=FAl Ibarra Corretg=E9 AG Projects From md3135@att.com Tue Jun 7 07:09:37 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0170421F8558 for ; Tue, 7 Jun 2011 07:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryiOMIKWS5IN for ; Tue, 7 Jun 2011 07:09:35 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 709FC21F8579 for ; Tue, 7 Jun 2011 07:09:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1307455771!21505870!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 20021 invoked from network); 7 Jun 2011 14:09:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 14:09:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57E8PsO003431 for ; Tue, 7 Jun 2011 10:08:25 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57E8Kr7003329 for ; Tue, 7 Jun 2011 10:08:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 10:09:26 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: Acwffav2wYY0OBTxTUq0cwIfOZtMlgFi5FnQAAS0ZqA= References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> From: "DOLLY, MARTIN C (ATTSI)" To: "Umang Singh" , Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:09:37 -0000 Umang, SBC's will do whatever service providers tell them. Solutions should assume that the media will transverse an SBC. Regards, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Umang Singh Sent: Tuesday, June 07, 2011 8:02 AM To: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach Hi Christer, What about the scenario where 2 RFC 4975 compliant UA's try to establish MSRP session on the basis of a=3Dpath with an ALG(more specifically SBC) in the path? As SBC won't modify the a=3Dpath, the UA's can bypass the = SBC in the media path. Media anchoring would not work in this case. The assumption that a firewall will drop any traffic not directed to the ALG might not be a valid one specially if both the UA's are in the same network. Also, one of the basic functions of the SBC is topology hiding which will not be done on the a=3Dpath attribute. I don't agree with mandating the fallback mechanism either. Apart from performance, another valid reason for not implementing the MSRP B2BUA functionality in SBC's is the cost associated with the same. Regards, Umang Date: Mon, 30 May 2011 21:40:25 +0200 From: Christer Holmberg To: "simple@ietf.org" Subject: [Simple] Sessmatch - an alternative approach Message-ID: =09 <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson. se> =09 Content-Type: text/plain; charset=3D"us-ascii" Hi, =20 Based on the issues that have been raised on sessmatch, I would like to present a modified version, that solves some of the raised issues related to security, backward compability, usage of the Require header filed, and specifying of ALG behavior. It has the following advantages over the current sessmatch mechanism: =20 1. Except for one case, that still requires MSRP B2BUA, it works with "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the a=3Dpath) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA; =20 2. It works with name based authentication; =20 3. It works when a 4975 UA is behind a relay; 4. It works without a need for the offerer, or for the SIP-ALG, to use the Require header field; and =20 5. It atually REMOVES the need to update the session matching procedure in the first place :) =20 =20 The idea is based on the very original sessmatch proposal, where a sessmatch UA sends the TCP SYN for the MSRP connection based on the SDP c/m-line, rather than the a=3Dpath. BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI into the MSRP message, use it for name based authentication, and use if for session matching - all according to existing RFC 4975 procedures. Let's look at how it works. Peer-to-peer (no SIP-ALG) ----------------------------- As in the current sessmatch proposal, there is still full backward compability. As the a=3Dpath and SDP c/m-line values will be identical, = it doesn't matter which the sessmatch UA uses for sending the TCP SYN.=20 (In fact, we could even specify that the sessmatch UA uses the a=3Dpath = in case it is identical to the SDP c/m-line, and everything would be identical to RFC 4975.) SIP-ALG in the path --------------------- 1. A sessmatch UA sends a request that offers MSRP, and includes a sessmatch support indication (option-tag, SDP attribute, or whatever we choose). 2. The SIP-ALG modifies the SDP c/m-line of the offer, and the corresponding answer, in order to anchor the MSRP media. The a=3Dpath is NOT modified. 3. The sessmatch UA receives the answer from the remote UA. 4a. If the remote UA supports sessmatch, everthing is fine. Whoever is "active" sends the TCP SYN according to the SDP c/m line (which points to the ALG). 4b. If the remote UA does NOT support sessmatch, BUT is "passive" (default if it does not support MSRP ACM), everything is fine. The sessmatch sends the TCP SYN according to the SDP c/m line (which points to the ALG). 4c. If the remote UA does NOT support sessmatch, AND is "active", things will NOT work (unless SIP-ALG bypass is allowed), as the remote UA will try to send the TCP SYN according to a=3Dpath (which points to the sessmatch UA, rather than to the ALG). 5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending a new offer where it does NOT include a sessmatch support indication. The SIP-ALG, in order to support MSRP, will now have to enable MSRP B2BUA functionality. It works the same in the other direction, where the 4975 UA sends the offer. If the 4975 UA becomes "active", the sessmatch UA will have to send an offer without sessmatch indication. =20 Regards, =20 Christer _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Jun 7 07:14:48 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045B911E810C for ; Tue, 7 Jun 2011 07:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZDaArkrjywo for ; Tue, 7 Jun 2011 07:14:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB2911E80F0 for ; Tue, 7 Jun 2011 07:14:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-8e-4dee3256313a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.4A.09774.6523EED4; Tue, 7 Jun 2011 16:14:46 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 7 Jun 2011 16:14:43 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 7 Jun 2011 16:14:42 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlG93qcv5t0p3RSMShfBSBOiM8FQAAB+EA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E323AEF@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E323A9E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:14:48 -0000 Hi,=20 >>Let's be clear. Sessmatch is ONLY talking about ALGs that=20 >>need to be able to modify the SDP in order to anchor media. >> >>If they choose to instead behave like a normal IP/TCP box,=20 >>or whatever, of course they don't need to implement B2BUA=20 >>functionality. >=20 >That's the point. And since ALG's are "anomalies" (don't take=20 >me wrong), why should them be specified my an IETF document?=20 >and why should such a document mandate nothing about an ALG? >=20 >I like the new specification proposal as ***it does not break=20 >nothing that would work without the ALG box in the middle***=20 >but, anyhow, why to make an IETF specification about ALG's? I think sessmatch provides a win-win situation, as it makes life easier for= both those who deploy ALGs and those who use MSRP. Regards, Christer From saul@ag-projects.com Tue Jun 7 07:16:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04B11E8116 for ; Tue, 7 Jun 2011 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psjPwR3olcF3 for ; Tue, 7 Jun 2011 07:16:03 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC111E811F for ; Tue, 7 Jun 2011 07:16:03 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 34E61B01B9; Tue, 7 Jun 2011 16:16:02 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6203CB017D; Tue, 7 Jun 2011 16:16:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Tue, 7 Jun 2011 16:16:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65751543-78CC-4877-A00D-EE3D4F8B92D0@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E323A9E@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:16:04 -0000 On Jun 7, 2011, at 4:04 PM, I=F1aki Baz Castillo wrote: > 2011/6/7 Christer Holmberg : >> Let's be clear. Sessmatch is ONLY talking about ALGs that need to be = able to modify the SDP in order to anchor media. >>=20 >> If they choose to instead behave like a normal IP/TCP box, or = whatever, of course they don't need to implement B2BUA functionality. >=20 > That's the point. And since ALG's are "anomalies" (don't take me > wrong), why should them be specified my an IETF document? and why > should such a document mandate nothing about an ALG? >=20 > I like the new specification proposal as ***it does not break nothing > that would work without the ALG box in the middle*** but, anyhow, why > to make an IETF specification about ALG's? >=20 I think this is a lost battle. We can argue infinitely but vendors will = do whatever they want to do. So lets seize the opportunity to contribute = to a specification that doesn't break MSRP for the rest of us. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Jun 7 07:16:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB411E8112 for ; Tue, 7 Jun 2011 07:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC2AJhQg1dxJ for ; Tue, 7 Jun 2011 07:16:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D323711E80F0 for ; Tue, 7 Jun 2011 07:16:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so3687334qwc.31 for ; Tue, 07 Jun 2011 07:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr4489590qcb.285.1307456200249; Tue, 07 Jun 2011 07:16:40 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 07:16:40 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 16:16:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:16:41 -0000 2011/6/7 DOLLY, MARTIN C (ATTSI) : > SBC's will do whatever service providers tell them. Also breaking an existing protocol? > Solutions should assume that the media will transverse an SBC. Which "solutions" do you mean? Could you be more explicit please? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jun 7 07:18:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7BF11E8123 for ; Tue, 7 Jun 2011 07:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAd-0g4FdRty for ; Tue, 7 Jun 2011 07:18:58 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02411E8112 for ; Tue, 7 Jun 2011 07:18:58 -0700 (PDT) Received: by qyk29 with SMTP id 29so1854165qyk.10 for ; Tue, 07 Jun 2011 07:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr4541932qcb.171.1307456332183; Tue, 07 Jun 2011 07:18:52 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 07:18:52 -0700 (PDT) In-Reply-To: References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> Date: Tue, 7 Jun 2011 16:18:52 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:18:59 -0000 2011/6/7 Sa=C3=BAl Ibarra Corretg=C3=A9 : > The sessmatch spec is targeted towards ALGs that modify the SDP for ancho= ring media, not home routers. Right, but nothing will prevent home routers vendor to also implement MSRP ALG the same as they've implemented poor/pathetic SIP ALG "feature". --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jun 7 07:19:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD7A11E811A for ; Tue, 7 Jun 2011 07:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF+SQi81QGuu for ; Tue, 7 Jun 2011 07:19:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CDBE311E8118 for ; Tue, 7 Jun 2011 07:19:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ad-4dee338d5d12 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DA.0C.09774.D833EED4; Tue, 7 Jun 2011 16:19:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 7 Jun 2011 16:19:50 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 7 Jun 2011 16:19:50 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlHHI9e5MrMXA2RvOHiP3EXf31fgAAPYYA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E323B00@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:19:59 -0000 Hi,=20 >>If Alice and Bob, behind different NAT routers (no ALG) and with no=20 >>MSRP relays, try to establish an MSRP communication, it would fail=20 >>(obvious). >>Should IETF mandate (MUST) that in this case the *normal*=20 >>NAT router (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback mechanism= "? >>If the answer is "not" (and of course it's "not"), why should IETF=20 >>mandate such a mechanism for an ALG/SBC box? >>=20 >=20 >The sessmatch spec is targeted towards ALGs that modify the=20 >SDP for anchoring media, not home routers. If people think that is unclear I will do my best to make it more clear. >>So, if the ALG cannot anchor the MSRP media let it to behave as a=20 >>"normal IP/TCP box" which does not play at protocol level. If some=20 >>vendor wants to include "fallback mechanism behaving as a=20 >>MSRP B2BUA" it's ok, but why to mandate it? >=20 >The draft should probably change the title (since 'sessmatch'=20 >doesn't really apply now) and also mention that this is=20 >behavior specific to ALGs. The current working title is "Alternative Connection Establishment (ACE)" := ) The applicability section will make it clear that the procedures can be use= d when a UA is communicating with an ALG. Regards, Christer From saul@ag-projects.com Tue Jun 7 07:21:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8C111E812A for ; Tue, 7 Jun 2011 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhkkDStmsWay for ; Tue, 7 Jun 2011 07:21:32 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7D711E8129 for ; Tue, 7 Jun 2011 07:21:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D803EB01B8; Tue, 7 Jun 2011 16:21:31 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 3182FB017C; Tue, 7 Jun 2011 16:21:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Tue, 7 Jun 2011 16:21:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:21:33 -0000 On Jun 7, 2011, at 4:18 PM, I=F1aki Baz Castillo wrote: > 2011/6/7 Sa=FAl Ibarra Corretg=E9 : >> The sessmatch spec is targeted towards ALGs that modify the SDP for = anchoring media, not home routers. >=20 > Right, but nothing will prevent home routers vendor to also implement > MSRP ALG the same as they've implemented poor/pathetic SIP ALG > "feature". >=20 I think you are talking about two different kinds of ALGs: the ones that = anchor media and the ones that want to "help" the user and "fix" SIP on = his home router.=20 -- Sa=FAl Ibarra Corretg=E9 AG Projects From ag@ag-projects.com Tue Jun 7 07:25:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DED11E811E for ; Tue, 7 Jun 2011 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 wfF1nKeLGMIB for ; Tue, 7 Jun 2011 07:25:50 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03B11E811A for ; Tue, 7 Jun 2011 07:25:50 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AC1ABB01B8; Tue, 7 Jun 2011 16:25:49 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 3A52AB017C; Tue, 7 Jun 2011 16:25:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 16:25:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:25:50 -0000 On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: > Umang, >=20 > SBC's will do whatever service providers tell them. Solutions should > assume that the media will transverse an SBC. >=20 Dolly, You are completely wrong.=20 MSRP sessions flow just fine on the Internet without any explicit need = for an SBC by using MSRP relays for NAT traversal. No solution should be based on such broken assumption. Adrian From ibc@aliax.net Tue Jun 7 07:47:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E9E11E8132 for ; Tue, 7 Jun 2011 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB2IZCoSDUOV for ; Tue, 7 Jun 2011 07:47:28 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA7711E8120 for ; Tue, 7 Jun 2011 07:47:28 -0700 (PDT) Received: by qyk7 with SMTP id 7so3220489qyk.10 for ; Tue, 07 Jun 2011 07:47:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr4544135qci.209.1307458047766; Tue, 07 Jun 2011 07:47:27 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 07:47:27 -0700 (PDT) In-Reply-To: References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> Date: Tue, 7 Jun 2011 16:47:27 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:47:29 -0000 2011/6/7 Sa=C3=BAl Ibarra Corretg=C3=A9 : > I think you are talking about two different kinds of ALGs: the ones that = anchor media and the ones that want to "help" the user and "fix" SIP on his= home router. Right. But both of them could make usage of this spec, am I right? --=20 I=C3=B1aki Baz Castillo From md3135@att.com Tue Jun 7 07:48:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5F311E810C for ; Tue, 7 Jun 2011 07:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU5roKzHbQT4 for ; Tue, 7 Jun 2011 07:48:58 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B411E816A for ; Tue, 7 Jun 2011 07:48:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1307458137!21486434!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32760 invoked from network); 7 Jun 2011 14:48:57 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 14:48:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57Elo13030591 for ; Tue, 7 Jun 2011 10:47:51 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57EliA9030085 for ; Tue, 7 Jun 2011 10:47:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 10:48:49 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlHtLnz96fwHPAStCfczKXoWfVcgAAv1Mg References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> From: "DOLLY, MARTIN C (ATTSI)" To: "Adrian Georgescu" Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:48:58 -0000 Adrian, I guess you do not deal in reality... Regards, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 Sent: Tuesday, June 07, 2011 10:26 AM To: DOLLY, MARTIN C (ATTSI) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: > Umang, >=20 > SBC's will do whatever service providers tell them. Solutions should > assume that the media will transverse an SBC. >=20 Dolly, You are completely wrong.=20 MSRP sessions flow just fine on the Internet without any explicit need for an SBC by using MSRP relays for NAT traversal. No solution should be based on such broken assumption. Adrian From saul@ag-projects.com Tue Jun 7 07:54:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0A11E812B for ; Tue, 7 Jun 2011 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NIhJNbEJ7eI for ; Tue, 7 Jun 2011 07:54:13 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0D611E8119 for ; Tue, 7 Jun 2011 07:54:13 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 93B42B01BC; Tue, 7 Jun 2011 16:54:12 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E3D2BB017C; Tue, 7 Jun 2011 16:54:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Tue, 7 Jun 2011 16:54:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <847212B1-9062-4190-B9F9-CA1EA1559202@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Umang Singh , simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:54:14 -0000 On Jun 7, 2011, at 4:47 PM, I=F1aki Baz Castillo wrote: > 2011/6/7 Sa=FAl Ibarra Corretg=E9 : >> I think you are talking about two different kinds of ALGs: the ones = that anchor media and the ones that want to "help" the user and "fix" = SIP on his home router. >=20 > Right. But both of them could make usage of this spec, am I right? >=20 The spec should make clear that this mechanism should only be used by = ALGs anchoring media. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ag@ag-projects.com Tue Jun 7 07:55:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA00911E8123 for ; Tue, 7 Jun 2011 07:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 5HSaG+Um+sMc for ; Tue, 7 Jun 2011 07:55:46 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8ED11E811A for ; Tue, 7 Jun 2011 07:55:46 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id A44A4B01BC; Tue, 7 Jun 2011 16:55:45 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id A9FDEB017C; Tue, 7 Jun 2011 16:55:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 16:55:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:55:47 -0000 You must be kidding right? I have multiple MSTP sessions in progress as = I write this email. It is unbelievable how you can question the fact that MSRP exists = outside of your narrow mind closed garden thinking. Adrian On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: > Adrian, >=20 > I guess you do not deal in reality... >=20 > Regards, >=20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 > Sent: Tuesday, June 07, 2011 10:26 AM > To: DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 >=20 > On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >=20 >> Umang, >>=20 >> SBC's will do whatever service providers tell them. Solutions should >> assume that the media will transverse an SBC. >>=20 >=20 >=20 > Dolly, >=20 > You are completely wrong.=20 >=20 > MSRP sessions flow just fine on the Internet without any explicit need > for an SBC by using MSRP relays for NAT traversal. >=20 > No solution should be based on such broken assumption. >=20 > Adrian >=20 >=20 >=20 From md3135@att.com Tue Jun 7 07:59:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D038A11E813E for ; Tue, 7 Jun 2011 07:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ghk5Z7ha6xs for ; Tue, 7 Jun 2011 07:59:39 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 156F311E8134 for ; Tue, 7 Jun 2011 07:59:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1307458778!22904273!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28504 invoked from network); 7 Jun 2011 14:59:38 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 14:59:38 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57EwVf7015008 for ; Tue, 7 Jun 2011 10:58:32 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57EwQ0p014800 for ; Tue, 7 Jun 2011 10:58:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 10:59:30 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlIv+15L+9Ue/MRX+qN4fssfxBZwAABICg References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> From: "DOLLY, MARTIN C (ATTSI)" To: "Adrian Georgescu" Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:59:39 -0000 Adrian, I understand your use case, but it seems that you do not understand ours. And without ours you will not have full Deployment Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 Sent: Tuesday, June 07, 2011 10:56 AM To: DOLLY, MARTIN C (ATTSI) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach You must be kidding right? I have multiple MSTP sessions in progress as I write this email. It is unbelievable how you can question the fact that MSRP exists outside of your narrow mind closed garden thinking. Adrian On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: > Adrian, >=20 > I guess you do not deal in reality... >=20 > Regards, >=20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 > Sent: Tuesday, June 07, 2011 10:26 AM > To: DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 >=20 > On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >=20 >> Umang, >>=20 >> SBC's will do whatever service providers tell them. Solutions should >> assume that the media will transverse an SBC. >>=20 >=20 >=20 > Dolly, >=20 > You are completely wrong.=20 >=20 > MSRP sessions flow just fine on the Internet without any explicit need > for an SBC by using MSRP relays for NAT traversal. >=20 > No solution should be based on such broken assumption. >=20 > Adrian >=20 >=20 >=20 From ibc@aliax.net Tue Jun 7 08:01:30 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E2311E8143 for ; Tue, 7 Jun 2011 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh6ugpr1x-UU for ; Tue, 7 Jun 2011 08:01:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1DDD11E813E for ; Tue, 7 Jun 2011 08:01:29 -0700 (PDT) Received: by qwc23 with SMTP id 23so3727449qwc.31 for ; Tue, 07 Jun 2011 08:01:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr4534358qcb.285.1307458889149; Tue, 07 Jun 2011 08:01:29 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 08:01:29 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 17:01:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:01:30 -0000 2011/6/7 DOLLY, MARTIN C (ATTSI) : > Adrian, > > I guess you do not deal in reality... Right, not all of us are big vendors, neither not all of us can break an Internet protocol in favour of our interests and still promote an IETF specification justifying that. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Tue Jun 7 08:16:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14E611E808E for ; Tue, 7 Jun 2011 08:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 n4yuvuh1otGj for ; Tue, 7 Jun 2011 08:16:01 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 12BBD1F0C36 for ; Tue, 7 Jun 2011 08:16:01 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 71414B01B9; Tue, 7 Jun 2011 17:16:00 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 86FDDB017C; Tue, 7 Jun 2011 17:15:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 17:15:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <240B76EC-8395-482A-814A-F0BCAD168457@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:16:02 -0000 One can do whatever is technically necessary inside a walled garden to = increase throughput and use a protocol gateway to bridge to the outside = if ever needed. There is no need to invent a new MSRP related standard = or MSRP connection model to make this possible. I t is between ATT and = its vendors to agree on how to do this the best way not the task of an = IETF WG. Breaking well established standards RFC4975 and RFC4976 in order to = satisfy your personal needs that has nothing to do with Internet is not = right. Adrian On Jun 7, 2011, at 4:59 PM, DOLLY, MARTIN C (ATTSI) wrote: > Adrian, >=20 > I understand your use case, but it seems that you do not understand > ours. And without ours you will not have full > Deployment >=20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 > Sent: Tuesday, June 07, 2011 10:56 AM > To: DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 > You must be kidding right? I have multiple MSTP sessions in progress = as > I write this email. >=20 > It is unbelievable how you can question the fact that MSRP exists > outside of your narrow mind closed garden thinking. >=20 > Adrian >=20 >=20 > On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: >=20 >> Adrian, >>=20 >> I guess you do not deal in reality... >>=20 >> Regards, >>=20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Services, Inc. >> md3135@att.com >> +1-609-903-3360 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 >> Sent: Tuesday, June 07, 2011 10:26 AM >> To: DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Subject: Re: [Simple] Sessmatch - an alternative approach >>=20 >>=20 >> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >>=20 >>> Umang, >>>=20 >>> SBC's will do whatever service providers tell them. Solutions should >>> assume that the media will transverse an SBC. >>>=20 >>=20 >>=20 >> Dolly, >>=20 >> You are completely wrong.=20 >>=20 >> MSRP sessions flow just fine on the Internet without any explicit = need >> for an SBC by using MSRP relays for NAT traversal. >>=20 >> No solution should be based on such broken assumption. >>=20 >> Adrian >>=20 >>=20 >>=20 >=20 From ibc@aliax.net Tue Jun 7 08:25:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2360C11E8112 for ; Tue, 7 Jun 2011 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OK3-fVjGclF for ; Tue, 7 Jun 2011 08:25:22 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id CA7EB11E8157 for ; Tue, 7 Jun 2011 08:25:16 -0700 (PDT) Received: by qyk7 with SMTP id 7so3248684qyk.10 for ; Tue, 07 Jun 2011 08:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr4567750qcb.247.1307460316169; Tue, 07 Jun 2011 08:25:16 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 08:25:15 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 17:25:15 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:25:23 -0000 2011/6/7 DOLLY, MARTIN C (ATTSI) : > I understand your use case, but it seems that you do not understand > ours. Let's then speak about "your case" and "our case": - Our case doesn't break your case. - Your case *does* break our case (at least in the previous versions of the draft, but it doesn't seem to worry you as per your previous mails). - Our case was before your case (as there are already IETF RFC's 4875 and 4= 876). - Our case is pure Internet. - Your case is an anomaly. > And without ours you will not have full Deployment We *already* have "full deployment" (or whatever that means). --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jun 7 08:43:32 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B7711E816A for ; Tue, 7 Jun 2011 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyHTJIJ1ople for ; Tue, 7 Jun 2011 08:43:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 162A811E8162 for ; Tue, 7 Jun 2011 08:43:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9f-4dee47214285 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2E.D9.20773.1274EED4; Tue, 7 Jun 2011 17:43:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 7 Jun 2011 17:43:29 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 7 Jun 2011 17:42:42 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlIsb6Oym6y2RKSd22zZ5MR8yXBgABsM4U Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A41C@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> , <847212B1-9062-4190-B9F9-CA1EA1559202@ag-projects.com> In-Reply-To: <847212B1-9062-4190-B9F9-CA1EA1559202@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:43:32 -0000 Hi, >>> I think you are talking about two different kinds of ALGs: the ones tha= t anchor media and the ones that >>>want to "help" the user and "fix" SIP o= n his home router. >> >>Right. But both of them could make usage of this spec, am I right? > > >The spec should make clear that this mechanism should only be used by ALGs= anchoring media. Absolutely. Regards, Christer _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From christer.holmberg@ericsson.com Tue Jun 7 09:11:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BC311E8123 for ; Tue, 7 Jun 2011 09:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAiPEv9eUaiV for ; Tue, 7 Jun 2011 09:11:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2A11E810C for ; Tue, 7 Jun 2011 09:11:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f4-4dee4dbd3dd0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CC.60.20773.DBD4EED4; Tue, 7 Jun 2011 18:11:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 7 Jun 2011 18:11:40 +0200 From: Christer Holmberg To: Adrian Georgescu , "DOLLY, MARTIN C (ATTSI)" Date: Tue, 7 Jun 2011 18:07:49 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlJdS18CmhPRVAQgWxLuTJ5gfiQQABzdFV Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A420@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com>, <240B76EC-8395-482A-814A-F0BCAD168457@ag-projects.com> In-Reply-To: <240B76EC-8395-482A-814A-F0BCAD168457@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:11:46 -0000 Hi, >One can do whatever is technically necessary inside a walled garden to inc= rease throughput and use a=20 >protocol gateway to bridge to the outside if ever needed. There is no nee= d to invent a new MSRP related=20 >standard or MSRP connection model to make this possible. I t is between AT= T and its vendors to agree on=20 >how to do this the best way not the task of an IETF WG. > >Breaking well established standards RFC4975 and RFC4976 in order to satisf= y your personal needs that has=20 >nothing to do with Internet is not right. I don't know what is broken. The WG made a decisison, quite a while ago, to= , rather than updating any of the existing RFCs, define sessmatch as an opt= ional extension.=20 Nobody is mandating you to implement it, and all your ongoing MSRP sessions= will continue to work just fine. But, quite many needs are fullfilled by this. And, yes, if it was only between ONE operator and ONE vendor, they could si= t down and agree on whatever. But, even in the so called walled gardens, th= ere are products by multiple vendors, and traffic between multiple operator= s - and in many cases also connectivity to other types of networks, both so= called walled gardens AND the so called "Internet" - where you of course n= ever will find any ALGs... And, ALGs are not only used for NAT traversal, and MSRP is not the only med= ia for which NAT traversal is needed. Regards, Christer > Adrian, > > I understand your use case, but it seems that you do not understand > ours. And without ours you will not have full > Deployment > > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 > > > > > -----Original Message----- > From: Adrian Georgescu [mailto:ag@ag-projects.com] > Sent: Tuesday, June 07, 2011 10:56 AM > To: DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Subject: Re: [Simple] Sessmatch - an alternative approach > > You must be kidding right? I have multiple MSTP sessions in progress as > I write this email. > > It is unbelievable how you can question the fact that MSRP exists > outside of your narrow mind closed garden thinking. > > Adrian > > > On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: > >> Adrian, >> >> I guess you do not deal in reality... >> >> Regards, >> >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Services, Inc. >> md3135@att.com >> +1-609-903-3360 >> >> >> >> >> -----Original Message----- >> From: Adrian Georgescu [mailto:ag@ag-projects.com] >> Sent: Tuesday, June 07, 2011 10:26 AM >> To: DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Subject: Re: [Simple] Sessmatch - an alternative approach >> >> >> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >> >>> Umang, >>> >>> SBC's will do whatever service providers tell them. Solutions should >>> assume that the media will transverse an SBC. >>> >> >> >> Dolly, >> >> You are completely wrong. >> >> MSRP sessions flow just fine on the Internet without any explicit need >> for an SBC by using MSRP relays for NAT traversal. >> >> No solution should be based on such broken assumption. >> >> Adrian >> >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From md3135@att.com Tue Jun 7 09:25:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2778711E818F for ; Tue, 7 Jun 2011 09:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUkZyBoglECh for ; Tue, 7 Jun 2011 09:25:07 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9011E8198 for ; Tue, 7 Jun 2011 09:24:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1307463898!22926880!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 29208 invoked from network); 7 Jun 2011 16:24:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 16:24:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57GNqG5021877 for ; Tue, 7 Jun 2011 12:23:52 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57GNkpN021786 for ; Tue, 7 Jun 2011 12:23:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 7 Jun 2011 12:24:52 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlJdS18CmhPRVAQgWxLuTJ5gfiQQABzdFVAACYaQ8= From: "DOLLY, MARTIN C (ATTSI)" To: , Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:25:08 -0000 Q2hyaXN0ZXIgaXMgY29ycmVjdCBpbiB0aGF0IGNhcnJpZXJzIG1heSBoYXZlIG11bHRpcGxlIHZl bmRvcnMsIHNvIGEgc3RhbmRhcmQgZW5zdXJlcyB1bmlmb3JtaXR5IFdSVCBpbXBsZW1lbnRhdGlv bi4NCg0KTWFueSB1c2VycyBhdHRhY2hlZCB0byBjYXJyaWVyIG5ldHdvcmtzLCBzbyBpZiB5b3Ug d2FudCBNU1JQIHN1cHBvcnRlZCB3aXRoIHRoZSBtYXhpbXVtIG51bWJlciBvZiB1c2VycywgeW91 IHdvdWxkIG5vdCBiZSBvYmplY3RpbmcgdG8gdGhpcw0KDQpVbmxlc3MgcHVyaXR5IHRha2VzIHBy ZWNlZGVudCBvdmVyIHN1cHBvcnQgaW4gdGhlIGluZHVzdHJ5DQpNYXJ0aW4gQy4gRG9sbHkNClNl bnQgdG8geW91IGJ5IEFUJlQuLi4gQW1lcmljYSdzIEZhc3Rlc3QgTW9iaWxlIEJyb2FkYmFuZCBO ZXR3b3JrLiBSZXRoaW5rIFBvc3NpYmxlLg0KKzEuNjA5LjkwMy4zMzYwDQoNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQpUbzogQWRyaWFuIEdlb3JnZXNjdSA8YWdAYWctcHJvamVjdHMu Y29tPjsgRE9MTFksIE1BUlRJTiBDIChBVFRTSSkNCkNjOiBTaW1wbGUgV0cgPHNpbXBsZUBpZXRm Lm9yZz4NClNlbnQ6IFR1ZSBKdW4gMDcgMTI6MDc6NDkgMjAxMQ0KU3ViamVjdDogUkU6IFtTaW1w bGVdIFNlc3NtYXRjaCAtIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoDQoNCg0KSGksDQoNCj5PbmUg Y2FuIGRvIHdoYXRldmVyIGlzIHRlY2huaWNhbGx5IG5lY2Vzc2FyeSBpbnNpZGUgYSB3YWxsZWQg Z2FyZGVuIHRvIGluY3JlYXNlIHRocm91Z2hwdXQgYW5kIHVzZSBhIA0KPnByb3RvY29sIGdhdGV3 YXkgdG8gYnJpZGdlIHRvIHRoZSBvdXRzaWRlIGlmIGV2ZXIgbmVlZGVkLiAgVGhlcmUgaXMgbm8g bmVlZCB0byBpbnZlbnQgYSBuZXcgTVNSUCByZWxhdGVkIA0KPnN0YW5kYXJkIG9yIE1TUlAgY29u bmVjdGlvbiBtb2RlbCB0byBtYWtlIHRoaXMgcG9zc2libGUuIEkgdCBpcyBiZXR3ZWVuIEFUVCBh bmQgaXRzIHZlbmRvcnMgdG8gYWdyZWUgb24gDQo+aG93IHRvIGRvIHRoaXMgdGhlIGJlc3Qgd2F5 IG5vdCB0aGUgdGFzayBvZiBhbiBJRVRGIFdHLg0KPg0KPkJyZWFraW5nIHdlbGwgZXN0YWJsaXNo ZWQgc3RhbmRhcmRzIFJGQzQ5NzUgYW5kIFJGQzQ5NzYgaW4gb3JkZXIgdG8gc2F0aXNmeSB5b3Vy IHBlcnNvbmFsIG5lZWRzIHRoYXQgaGFzIA0KPm5vdGhpbmcgdG8gZG8gd2l0aCBJbnRlcm5ldCBp cyBub3QgcmlnaHQuDQoNCkkgZG9uJ3Qga25vdyB3aGF0IGlzIGJyb2tlbi4gVGhlIFdHIG1hZGUg YSBkZWNpc2lzb24sIHF1aXRlIGEgd2hpbGUgYWdvLCB0bywgcmF0aGVyIHRoYW4gdXBkYXRpbmcg YW55IG9mIHRoZSBleGlzdGluZyBSRkNzLCBkZWZpbmUgc2Vzc21hdGNoIGFzIGFuIG9wdGlvbmFs IGV4dGVuc2lvbi4gDQoNCk5vYm9keSBpcyBtYW5kYXRpbmcgeW91IHRvIGltcGxlbWVudCBpdCwg YW5kIGFsbCB5b3VyIG9uZ29pbmcgTVNSUCBzZXNzaW9ucyB3aWxsIGNvbnRpbnVlIHRvIHdvcmsg anVzdCBmaW5lLg0KDQpCdXQsIHF1aXRlIG1hbnkgbmVlZHMgYXJlIGZ1bGxmaWxsZWQgYnkgdGhp cy4NCg0KQW5kLCB5ZXMsIGlmIGl0IHdhcyBvbmx5IGJldHdlZW4gT05FIG9wZXJhdG9yIGFuZCBP TkUgdmVuZG9yLCB0aGV5IGNvdWxkIHNpdCBkb3duIGFuZCBhZ3JlZSBvbiB3aGF0ZXZlci4gQnV0 LCBldmVuIGluIHRoZSBzbyBjYWxsZWQgd2FsbGVkIGdhcmRlbnMsIHRoZXJlIGFyZSBwcm9kdWN0 cyBieSBtdWx0aXBsZSB2ZW5kb3JzLCBhbmQgdHJhZmZpYyBiZXR3ZWVuIG11bHRpcGxlIG9wZXJh dG9ycyAtIGFuZCBpbiBtYW55IGNhc2VzIGFsc28gY29ubmVjdGl2aXR5IHRvIG90aGVyIHR5cGVz IG9mIG5ldHdvcmtzLCBib3RoIHNvIGNhbGxlZCB3YWxsZWQgZ2FyZGVucyBBTkQgdGhlIHNvIGNh bGxlZCAiSW50ZXJuZXQiIC0gd2hlcmUgeW91IG9mIGNvdXJzZSBuZXZlciB3aWxsIGZpbmQgYW55 IEFMR3MuLi4NCg0KQW5kLCBBTEdzIGFyZSBub3Qgb25seSB1c2VkIGZvciBOQVQgdHJhdmVyc2Fs LCBhbmQgTVNSUCBpcyBub3QgdGhlIG9ubHkgbWVkaWEgZm9yIHdoaWNoIE5BVCB0cmF2ZXJzYWwg aXMgbmVlZGVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KPiBBZHJpYW4sDQo+DQo+ IEkgdW5kZXJzdGFuZCB5b3VyIHVzZSBjYXNlLCBidXQgaXQgc2VlbXMgdGhhdCB5b3UgZG8gbm90 IHVuZGVyc3RhbmQNCj4gb3Vycy4gQW5kIHdpdGhvdXQgb3VycyB5b3Ugd2lsbCBub3QgaGF2ZSBm dWxsDQo+IERlcGxveW1lbnQNCj4NCj4gTWFydGluIERvbGx5DQo+IExlYWQgTWVtYmVyIFRlY2hu aWNhbCBTdGFmZg0KPiBDb3JlICYgR292ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJkcw0KPiBB VCZUIFNlcnZpY2VzLCBJbmMuDQo+IG1kMzEzNUBhdHQuY29tDQo+ICsxLTYwOS05MDMtMzM2MA0K Pg0KPg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZHJpYW4g R2Vvcmdlc2N1IFttYWlsdG86YWdAYWctcHJvamVjdHMuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBK dW5lIDA3LCAyMDExIDEwOjU2IEFNDQo+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVFNJKQ0KPiBD YzogU2ltcGxlIFdHDQo+IFN1YmplY3Q6IFJlOiBbU2ltcGxlXSBTZXNzbWF0Y2ggLSBhbiBhbHRl cm5hdGl2ZSBhcHByb2FjaA0KPg0KPiBZb3UgbXVzdCBiZSBraWRkaW5nIHJpZ2h0PyBJIGhhdmUg bXVsdGlwbGUgTVNUUCBzZXNzaW9ucyBpbiBwcm9ncmVzcyBhcw0KPiBJIHdyaXRlIHRoaXMgZW1h aWwuDQo+DQo+IEl0IGlzIHVuYmVsaWV2YWJsZSBob3cgeW91IGNhbiBxdWVzdGlvbiB0aGUgZmFj dCB0aGF0IE1TUlAgZXhpc3RzDQo+IG91dHNpZGUgb2YgeW91ciBuYXJyb3cgbWluZCBjbG9zZWQg Z2FyZGVuIHRoaW5raW5nLg0KPg0KPiBBZHJpYW4NCj4NCj4NCj4gT24gSnVuIDcsIDIwMTEsIGF0 IDQ6NDggUE0sIERPTExZLCBNQVJUSU4gQyAoQVRUU0kpIHdyb3RlOg0KPg0KPj4gQWRyaWFuLA0K Pj4NCj4+IEkgZ3Vlc3MgeW91IGRvIG5vdCBkZWFsIGluIHJlYWxpdHkuLi4NCj4+DQo+PiBSZWdh cmRzLA0KPj4NCj4+IE1hcnRpbiBEb2xseQ0KPj4gTGVhZCBNZW1iZXIgVGVjaG5pY2FsIFN0YWZm DQo+PiBDb3JlICYgR292ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJkcw0KPj4gQVQmVCBTZXJ2 aWNlcywgSW5jLg0KPj4gbWQzMTM1QGF0dC5jb20NCj4+ICsxLTYwOS05MDMtMzM2MA0KPj4NCj4+ DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBBZHJpYW4g R2Vvcmdlc2N1IFttYWlsdG86YWdAYWctcHJvamVjdHMuY29tXQ0KPj4gU2VudDogVHVlc2RheSwg SnVuZSAwNywgMjAxMSAxMDoyNiBBTQ0KPj4gVG86IERPTExZLCBNQVJUSU4gQyAoQVRUU0kpDQo+ PiBDYzogU2ltcGxlIFdHDQo+PiBTdWJqZWN0OiBSZTogW1NpbXBsZV0gU2Vzc21hdGNoIC0gYW4g YWx0ZXJuYXRpdmUgYXBwcm9hY2gNCj4+DQo+Pg0KPj4gT24gSnVuIDcsIDIwMTEsIGF0IDQ6MDkg UE0sIERPTExZLCBNQVJUSU4gQyAoQVRUU0kpIHdyb3RlOg0KPj4NCj4+PiBVbWFuZywNCj4+Pg0K Pj4+IFNCQydzIHdpbGwgZG8gd2hhdGV2ZXIgc2VydmljZSBwcm92aWRlcnMgdGVsbCB0aGVtLiBT b2x1dGlvbnMgc2hvdWxkDQo+Pj4gYXNzdW1lIHRoYXQgdGhlIG1lZGlhIHdpbGwgdHJhbnN2ZXJz ZSBhbiBTQkMuDQo+Pj4NCj4+DQo+Pg0KPj4gRG9sbHksDQo+Pg0KPj4gWW91IGFyZSBjb21wbGV0 ZWx5IHdyb25nLg0KPj4NCj4+IE1TUlAgc2Vzc2lvbnMgZmxvdyBqdXN0IGZpbmUgb24gdGhlIElu dGVybmV0IHdpdGhvdXQgYW55IGV4cGxpY2l0IG5lZWQNCj4+IGZvciBhbiBTQkMgYnkgdXNpbmcg TVNSUCByZWxheXMgZm9yIE5BVCB0cmF2ZXJzYWwuDQo+Pg0KPj4gTm8gc29sdXRpb24gc2hvdWxk IGJlIGJhc2VkIG9uIHN1Y2ggYnJva2VuIGFzc3VtcHRpb24uDQo+Pg0KPj4gQWRyaWFuDQo+Pg0K Pj4NCj4+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpTaW1wbGUgbWFpbGluZyBsaXN0DQpTaW1wbGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlDQo= From Umang.Singh@globallogic.com Tue Jun 7 09:29:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751C11E818F for ; Tue, 7 Jun 2011 09:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0R+1jhzIKf8 for ; Tue, 7 Jun 2011 09:29:38 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6266111E8168 for ; Tue, 7 Jun 2011 09:29:37 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id htp8v20171sr for ; Tue, 7 Jun 2011 21:59:35 +0530 (envelope-from ) Received: from ex2-del1.synapse.com ([172.16.2.50]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.2.1.2841) with ESMTP; Tue, 07 Jun 2011 21:59:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 21:55:09 +0530 Message-ID: <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> In-Reply-To: <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlDszpi+FP+4wRTWCNJit07kWT7wAGU2bQ References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> From: "Umang Singh" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201106071629350077781 Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:29:38 -0000 Hi, Requirements from SBC are defined in an IETF spec = (http://tools.ietf.org/html/rfc5853). Topology hiding and media = anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I = think we should accept the presence and proliferation of SBCs and not = call them an anomaly as it is specified in an IETF specification. The reasons for not mandating a fallback which in turn would mean adding = the MSRP B2BUA functionality in a SBC is that SBC could anchor media by = just functioning as a TCP/IP relay just as it does for RTP traffic. The = difference with MSRP is that MSRP packets contain MSRP URIs exchanged in = signaling and matching of MSRP session to TCP connection is done on the = basis of that. For a node like the SBC, functioning as a MSRP B2BUA has = a huge performance overhead as compared to functioning as a TCP/IP = relay. As the draft in question discusses possibilities of making MSRP = work with such ALGs/SBCs in the path, I think this point is worthy of = discussion. Regards, Umang -----Original Message----- From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]=20 Sent: Tuesday, June 07, 2011 6:01 PM To: Umang Singh Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach Hi, On Jun 7, 2011, at 2:02 PM, Umang Singh wrote: > Hi Christer, > What about the scenario where 2 RFC 4975 compliant UA's try to = establish > MSRP session on the basis of a=3Dpath with an ALG(more specifically = SBC) > in the path? As SBC won't modify the a=3Dpath, the UA's can bypass the = SBC > in the media path. Media anchoring would not work in this case. The > assumption that a firewall will drop any traffic not directed to the = ALG > might not be a valid one specially if both the UA's are in the same > network. >=20 > Also, one of the basic functions of the SBC is topology hiding which > will not be done on the a=3Dpath attribute. >=20 Is there any document/draft/spec where SBC recommended or mandatory = features are listed? > I don't agree with mandating the fallback mechanism either. Apart from > performance, another valid reason for not implementing the MSRP B2BUA > functionality in SBC's is the cost associated with the same. >=20 Cost can't justify breaking an IETF protocol. What is your suggestion, = just not having a fallback mechanism? -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Jun 7 09:30:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD2811E8190 for ; Tue, 7 Jun 2011 09:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08GRm6UUn7bF for ; Tue, 7 Jun 2011 09:30:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3311E81A8 for ; Tue, 7 Jun 2011 09:29:56 -0700 (PDT) Received: by qyk7 with SMTP id 7so3291284qyk.10 for ; Tue, 07 Jun 2011 09:29:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr4627711qcb.285.1307464195609; Tue, 07 Jun 2011 09:29:55 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 09:29:55 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A420@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395ECB@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F69@gaalpa1msgusr7e.ugd.att.com> <669DE46F-B5E9-4B38-B776-CFC91CADE08D@ag-projects.com> <14C85D6CCBE92743AF33663BF5D24EBA0A395F90@gaalpa1msgusr7e.ugd.att.com> <240B76EC-8395-482A-814A-F0BCAD168457@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A420@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Jun 2011 18:29:55 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:30:01 -0000 2011/6/7 Christer Holmberg : > Nobody is mandating you to implement it, and all your ongoing MSRP sessio= ns will continue to work just fine. Hi Christer. I assume you are speaking about your recent new proposal which does not break RFC 4875/4876, am I right? If not, I would not like to resucit long threads already discussed about this topic :) --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Tue Jun 7 09:34:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CD321F8485 for ; Tue, 7 Jun 2011 09:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 Z6FI0MCjDx6t for ; Tue, 7 Jun 2011 09:34:56 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B3DD621F8483 for ; Tue, 7 Jun 2011 09:34:55 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 762B0B01BC; Tue, 7 Jun 2011 18:34:54 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 4332EB017D; Tue, 7 Jun 2011 18:34:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 18:34:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:34:56 -0000 Dear Dolly, This has nothing do with purism. It is a fact today that SIP is broken by the same advocates of your = idea. What you try to do with MSRP today is a mirror copy with what has = happened with SIP already. You try to do the same now for MSRP. Allowing intermediates to insert themselves into un-encrypted signaling = path. MSRP today is end-to-end and uses encryption hop by hop. You try = to break that to insert yourself between connections and you cannot by = obeying to the protocol so you must destroy it first. You people never learn from mistakes not you admit you made any. Is no wonder that everyone is looking for alternatives to SIP and soon = MSRP as they will both be broken. You will obtain a huge throughput increase for no user adoption of this = protocol. Congratulation for your excellent contribution to IETF! Adrian On Jun 7, 2011, at 6:24 PM, DOLLY, MARTIN C (ATTSI) wrote: > Christer is correct in that carriers may have multiple vendors, so a = standard ensures uniformity WRT implementation. >=20 > Many users attached to carrier networks, so if you want MSRP supported = with the maximum number of users, you would not be objecting to this >=20 > Unless purity takes precedent over support in the industry > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband Network. = Rethink Possible. > +1.609.903.3360 >=20 > ----- Original Message ----- > From: Christer Holmberg > To: Adrian Georgescu ; DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Sent: Tue Jun 07 12:07:49 2011 > Subject: RE: [Simple] Sessmatch - an alternative approach >=20 >=20 > Hi, >=20 >> One can do whatever is technically necessary inside a walled garden = to increase throughput and use a=20 >> protocol gateway to bridge to the outside if ever needed. There is = no need to invent a new MSRP related=20 >> standard or MSRP connection model to make this possible. I t is = between ATT and its vendors to agree on=20 >> how to do this the best way not the task of an IETF WG. >>=20 >> Breaking well established standards RFC4975 and RFC4976 in order to = satisfy your personal needs that has=20 >> nothing to do with Internet is not right. >=20 > I don't know what is broken. The WG made a decisison, quite a while = ago, to, rather than updating any of the existing RFCs, define sessmatch = as an optional extension.=20 >=20 > Nobody is mandating you to implement it, and all your ongoing MSRP = sessions will continue to work just fine. >=20 > But, quite many needs are fullfilled by this. >=20 > And, yes, if it was only between ONE operator and ONE vendor, they = could sit down and agree on whatever. But, even in the so called walled = gardens, there are products by multiple vendors, and traffic between = multiple operators - and in many cases also connectivity to other types = of networks, both so called walled gardens AND the so called "Internet" = - where you of course never will find any ALGs... >=20 > And, ALGs are not only used for NAT traversal, and MSRP is not the = only media for which NAT traversal is needed. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> Adrian, >>=20 >> I understand your use case, but it seems that you do not understand >> ours. And without ours you will not have full >> Deployment >>=20 >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Services, Inc. >> md3135@att.com >> +1-609-903-3360 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Adrian Georgescu [mailto:ag@ag-projects.com] >> Sent: Tuesday, June 07, 2011 10:56 AM >> To: DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Subject: Re: [Simple] Sessmatch - an alternative approach >>=20 >> You must be kidding right? I have multiple MSTP sessions in progress = as >> I write this email. >>=20 >> It is unbelievable how you can question the fact that MSRP exists >> outside of your narrow mind closed garden thinking. >>=20 >> Adrian >>=20 >>=20 >> On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: >>=20 >>> Adrian, >>>=20 >>> I guess you do not deal in reality... >>>=20 >>> Regards, >>>=20 >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Services, Inc. >>> md3135@att.com >>> +1-609-903-3360 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>> Sent: Tuesday, June 07, 2011 10:26 AM >>> To: DOLLY, MARTIN C (ATTSI) >>> Cc: Simple WG >>> Subject: Re: [Simple] Sessmatch - an alternative approach >>>=20 >>>=20 >>> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >>>=20 >>>> Umang, >>>>=20 >>>> SBC's will do whatever service providers tell them. Solutions = should >>>> assume that the media will transverse an SBC. >>>>=20 >>>=20 >>>=20 >>> Dolly, >>>=20 >>> You are completely wrong. >>>=20 >>> MSRP sessions flow just fine on the Internet without any explicit = need >>> for an SBC by using MSRP relays for NAT traversal. >>>=20 >>> No solution should be based on such broken assumption. >>>=20 >>> Adrian >>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Jun 7 09:40:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49C311E81C7 for ; Tue, 7 Jun 2011 09:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFKcOXNk24gV for ; Tue, 7 Jun 2011 09:40:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 173C711E81BD for ; Tue, 7 Jun 2011 09:40:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-6c-4dee5470ef2d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BA.07.20773.0745EED4; Tue, 7 Jun 2011 18:40:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 7 Jun 2011 18:40:16 +0200 From: Christer Holmberg To: Umang Singh , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Tue, 7 Jun 2011 18:40:16 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlDszpi+FP+4wRTWCNJit07kWT7wAGU2bQAAIwLIE= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A424@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com>, <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:40:27 -0000 Hi, >The reasons for not mandating a fallback which in turn would mean adding t= he MSRP B2BUA functionality in a SBC is that SBC could anchor media by just= functioning as a TCP/IP relay just as it does for RTP traffic. The differe= nce with MSRP is that MSRP packets=20 >contain MSRP URIs exchanged in signaling and matching of MSRP session to T= CP connection is done on the basis of that. For a node like the SBC, functi= oning as a MSRP B2BUA has a huge performance overhead as compared to functi= oning as a TCP/IP relay. As the=20 >draft in question discusses possibilities of making MSRP work with such AL= Gs/SBCs in the path, I think this point is worthy of discussion. I am not sure I understand. The whole idea is to allow the SBC to handle MS= RP as any other media. But, in some cases MSRP B2BUA functionality is needed. Regards, Christer -----Original Message----- From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] Sent: Tuesday, June 07, 2011 6:01 PM To: Umang Singh Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach Hi, On Jun 7, 2011, at 2:02 PM, Umang Singh wrote: > Hi Christer, > What about the scenario where 2 RFC 4975 compliant UA's try to establish > MSRP session on the basis of a=3Dpath with an ALG(more specifically SBC) > in the path? As SBC won't modify the a=3Dpath, the UA's can bypass the SB= C > in the media path. Media anchoring would not work in this case. The > assumption that a firewall will drop any traffic not directed to the ALG > might not be a valid one specially if both the UA's are in the same > network. > > Also, one of the basic functions of the SBC is topology hiding which > will not be done on the a=3Dpath attribute. > Is there any document/draft/spec where SBC recommended or mandatory feature= s are listed? > I don't agree with mandating the fallback mechanism either. Apart from > performance, another valid reason for not implementing the MSRP B2BUA > functionality in SBC's is the cost associated with the same. > Cost can't justify breaking an IETF protocol. What is your suggestion, just= not having a fallback mechanism? -- Sa=FAl Ibarra Corretg=E9 AG Projects _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From ag@ag-projects.com Tue Jun 7 09:46:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAE11E8164 for ; Tue, 7 Jun 2011 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqo51D+RNU6N for ; Tue, 7 Jun 2011 09:46:50 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC4D11E8076 for ; Tue, 7 Jun 2011 09:46:49 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id BBF2CB01BC; Tue, 7 Jun 2011 18:46:48 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 87CF5B017D; Tue, 7 Jun 2011 18:46:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-593009100 From: Adrian Georgescu In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> Date: Tue, 7 Jun 2011 18:46:47 +0200 Message-Id: <87E2D719-C37E-4179-9E02-A9F8004DF8BB@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> To: "Umang Singh" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:46:51 -0000 --Apple-Mail-1-593009100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear Umang, Mentioning an isolated entry into some obscure RFC to justify doing = obvious damage to established IETF protocols which are operating just = fine is a flawed argument. Adrian On Jun 7, 2011, at 6:25 PM, Umang Singh wrote: > Hi, > Requirements from SBC are defined in an IETF spec = (http://tools.ietf.org/html/rfc5853). Topology hiding and media = anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I = think we should accept the presence and proliferation of SBCs and not = call them an anomaly as it is specified in an IETF specification. >=20 > The reasons for not mandating a fallback which in turn would mean = adding the MSRP B2BUA functionality in a SBC is that SBC could anchor = media by just functioning as a TCP/IP relay just as it does for RTP = traffic. The difference with MSRP is that MSRP packets contain MSRP URIs = exchanged in signaling and matching of MSRP session to TCP connection is = done on the basis of that. For a node like the SBC, functioning as a = MSRP B2BUA has a huge performance overhead as compared to functioning as = a TCP/IP relay. As the draft in question discusses possibilities of = making MSRP work with such ALGs/SBCs in the path, I think this point is = worthy of discussion. >=20 > Regards, > Umang >=20 > -----Original Message----- > From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]=20 > Sent: Tuesday, June 07, 2011 6:01 PM > To: Umang Singh > Cc: simple@ietf.org > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 > Hi, >=20 > On Jun 7, 2011, at 2:02 PM, Umang Singh wrote: >=20 >> Hi Christer, >> What about the scenario where 2 RFC 4975 compliant UA's try to = establish >> MSRP session on the basis of a=3Dpath with an ALG(more specifically = SBC) >> in the path? As SBC won't modify the a=3Dpath, the UA's can bypass = the SBC >> in the media path. Media anchoring would not work in this case. The >> assumption that a firewall will drop any traffic not directed to the = ALG >> might not be a valid one specially if both the UA's are in the same >> network. >>=20 >> Also, one of the basic functions of the SBC is topology hiding which >> will not be done on the a=3Dpath attribute. >>=20 >=20 > Is there any document/draft/spec where SBC recommended or mandatory = features are listed? >=20 >=20 >> I don't agree with mandating the fallback mechanism either. Apart = from >> performance, another valid reason for not implementing the MSRP B2BUA >> functionality in SBC's is the cost associated with the same. >>=20 >=20 > Cost can't justify breaking an IETF protocol. What is your suggestion, = just not having a fallback mechanism? >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail-1-593009100 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = Umang,

Mentioning an isolated entry into some obscure = RFC to justify doing obvious damage to established IETF protocols which = are operating just fine is a flawed argument.

Hi,
Requirements from SBC are defined in an IETF = spec (http://tools.ietf.org/html/rfc= 5853). Topology hiding and media anchoring are mentioned in Section = 3.1 and Section 3.2 respectively. I think we should accept the presence = and proliferation of SBCs and not call them an anomaly as it is = specified in an IETF specification.

The reasons for not mandating = a fallback which in turn would mean adding the MSRP B2BUA functionality = in a SBC is that SBC could anchor media by just functioning as a TCP/IP = relay just as it does for RTP traffic. The difference with MSRP is that = MSRP packets contain MSRP URIs exchanged in signaling and matching of = MSRP session to TCP connection is done on the basis of that. For a node = like the SBC, functioning as a MSRP B2BUA has a huge performance = overhead as compared to functioning as a TCP/IP relay. As the draft in = question discusses possibilities of making MSRP work with such ALGs/SBCs = in the path, I think this point is worthy of = discussion.

Regards,
Umang

-----Original = Message-----
From: Sa=FAl Ibarra Corretg=E9 = [mailto:saul@ag-projects.com]
Sent: Tuesday, June 07, 2011 6:01 = PM
To: Umang Singh
Cc: simple@ietf.org
Subject: Re: = [Simple] Sessmatch - an alternative approach

Hi,

On Jun 7, = 2011, at 2:02 PM, Umang Singh wrote:

Hi = Christer,
What about the = scenario where 2 RFC 4975 compliant UA's try to = establish
MSRP session on the = basis of a=3Dpath with an ALG(more specifically = SBC)
in the path? As SBC won't = modify the a=3Dpath, the UA's can bypass the = SBC
in the media path. Media = anchoring would not work in this case. The
assumption that a firewall will drop any traffic not = directed to the ALG
might not = be a valid one specially if both the UA's are in the = same
network.

Also, one of = the basic functions of the SBC is topology hiding = which
will not be done on the = a=3Dpath attribute.


Is there any document/draft/spec = where SBC recommended or mandatory features are = listed?


I don't agree with = mandating the fallback mechanism either. Apart = from
performance, another = valid reason for not implementing the MSRP = B2BUA
functionality in SBC's = is the cost associated with the same.


Cost can't justify breaking an IETF = protocol. What is your suggestion, just not having a fallback = mechanism?

--
Sa=FAl Ibarra Corretg=E9
AG = Projects



_______________________________________________Simple mailing list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple


=
= --Apple-Mail-1-593009100-- From christer.holmberg@ericsson.com Tue Jun 7 09:48:16 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96811E8084 for ; Tue, 7 Jun 2011 09:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvrE4C6Gn2Ra for ; Tue, 7 Jun 2011 09:48:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6D111E8076 for ; Tue, 7 Jun 2011 09:48:15 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-53-4dee564e71ab Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 12.E8.20773.E465EED4; Tue, 7 Jun 2011 18:48:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 7 Jun 2011 18:48:05 +0200 From: Christer Holmberg To: Adrian Georgescu , "DOLLY, MARTIN C (ATTSI)" Date: Tue, 7 Jun 2011 18:43:47 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlMNwmlAn5rJcXSge00NGuAlXWQQAATZao Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com>, <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> In-Reply-To: <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:48:16 -0000 Adrian, Before sessmatch many people were looking for an alternative to MSRP. At le= ast in my experience (I can't of course speak on behalf of others, and it i= s very clear that you and I live in different realities, so you might have = another opinion) the number of people has gone down dramatically. Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Adrian= Georgescu [ag@ag-projects.com] Sent: Tuesday, June 07, 2011 7:34 PM To: DOLLY, MARTIN C (ATTSI) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach Dear Dolly, This has nothing do with purism. It is a fact today that SIP is broken by the same advocates of your idea. W= hat you try to do with MSRP today is a mirror copy with what has happened w= ith SIP already. You try to do the same now for MSRP. Allowing intermediates to insert themselves into un-encrypted signaling pat= h. MSRP today is end-to-end and uses encryption hop by hop. You try to brea= k that to insert yourself between connections and you cannot by obeying to = the protocol so you must destroy it first. You people never learn from mistakes not you admit you made any. Is no wonder that everyone is looking for alternatives to SIP and soon MSRP= as they will both be broken. You will obtain a huge throughput increase for no user adoption of this pro= tocol. Congratulation for your excellent contribution to IETF! Adrian On Jun 7, 2011, at 6:24 PM, DOLLY, MARTIN C (ATTSI) wrote: > Christer is correct in that carriers may have multiple vendors, so a stan= dard ensures uniformity WRT implementation. > > Many users attached to carrier networks, so if you want MSRP supported wi= th the maximum number of users, you would not be objecting to this > > Unless purity takes precedent over support in the industry > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethin= k Possible. > +1.609.903.3360 > > ----- Original Message ----- > From: Christer Holmberg > To: Adrian Georgescu ; DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Sent: Tue Jun 07 12:07:49 2011 > Subject: RE: [Simple] Sessmatch - an alternative approach > > > Hi, > >> One can do whatever is technically necessary inside a walled garden to i= ncrease throughput and use a >> protocol gateway to bridge to the outside if ever needed. There is no n= eed to invent a new MSRP related >> standard or MSRP connection model to make this possible. I t is between = ATT and its vendors to agree on >> how to do this the best way not the task of an IETF WG. >> >> Breaking well established standards RFC4975 and RFC4976 in order to sati= sfy your personal needs that has >> nothing to do with Internet is not right. > > I don't know what is broken. The WG made a decisison, quite a while ago, = to, rather than updating any of the existing RFCs, define sessmatch as an o= ptional extension. > > Nobody is mandating you to implement it, and all your ongoing MSRP sessio= ns will continue to work just fine. > > But, quite many needs are fullfilled by this. > > And, yes, if it was only between ONE operator and ONE vendor, they could = sit down and agree on whatever. But, even in the so called walled gardens, = there are products by multiple vendors, and traffic between multiple operat= ors - and in many cases also connectivity to other types of networks, both = so called walled gardens AND the so called "Internet" - where you of course= never will find any ALGs... > > And, ALGs are not only used for NAT traversal, and MSRP is not the only m= edia for which NAT traversal is needed. > > Regards, > > Christer > > > >> Adrian, >> >> I understand your use case, but it seems that you do not understand >> ours. And without ours you will not have full >> Deployment >> >> Martin Dolly >> Lead Member Technical Staff >> Core & Government/Regulatory Standards >> AT&T Services, Inc. >> md3135@att.com >> +1-609-903-3360 >> >> >> >> >> -----Original Message----- >> From: Adrian Georgescu [mailto:ag@ag-projects.com] >> Sent: Tuesday, June 07, 2011 10:56 AM >> To: DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Subject: Re: [Simple] Sessmatch - an alternative approach >> >> You must be kidding right? I have multiple MSTP sessions in progress as >> I write this email. >> >> It is unbelievable how you can question the fact that MSRP exists >> outside of your narrow mind closed garden thinking. >> >> Adrian >> >> >> On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: >> >>> Adrian, >>> >>> I guess you do not deal in reality... >>> >>> Regards, >>> >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Services, Inc. >>> md3135@att.com >>> +1-609-903-3360 >>> >>> >>> >>> >>> -----Original Message----- >>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>> Sent: Tuesday, June 07, 2011 10:26 AM >>> To: DOLLY, MARTIN C (ATTSI) >>> Cc: Simple WG >>> Subject: Re: [Simple] Sessmatch - an alternative approach >>> >>> >>> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >>> >>>> Umang, >>>> >>>> SBC's will do whatever service providers tell them. Solutions should >>>> assume that the media will transverse an SBC. >>>> >>> >>> >>> Dolly, >>> >>> You are completely wrong. >>> >>> MSRP sessions flow just fine on the Internet without any explicit need >>> for an SBC by using MSRP relays for NAT traversal. >>> >>> No solution should be based on such broken assumption. >>> >>> Adrian >>> >>> >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From ag@ag-projects.com Tue Jun 7 09:53:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BB911E816A for ; Tue, 7 Jun 2011 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 OL5aoxvFTQEb for ; Tue, 7 Jun 2011 09:53:46 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B713A11E8076 for ; Tue, 7 Jun 2011 09:53:45 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 0579EB01BC; Tue, 7 Jun 2011 18:53:44 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 90E7DB017D; Tue, 7 Jun 2011 18:53:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Jun 2011 18:53:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com>, <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:53:46 -0000 You started from the assumption that nobody has adopted MSRP in the real = world and you thought that you may change the original specifications = to serve your purpose. This assumptions was wrong at the base so must revise your approach and = deal with the fact that MSRP protocol is adopted, it works OK and your = proposal breaks it. Adrian On Jun 7, 2011, at 6:43 PM, Christer Holmberg wrote: > Adrian, >=20 > Before sessmatch many people were looking for an alternative to MSRP. = At least in my experience (I can't of course speak on behalf of others, = and it is very clear that you and I live in different realities, so you = might have another opinion) the number of people has gone down = dramatically. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Adrian Georgescu [ag@ag-projects.com] > Sent: Tuesday, June 07, 2011 7:34 PM > To: DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 > Dear Dolly, >=20 > This has nothing do with purism. >=20 > It is a fact today that SIP is broken by the same advocates of your = idea. What you try to do with MSRP today is a mirror copy with what has = happened with SIP already. You try to do the same now for MSRP. >=20 > Allowing intermediates to insert themselves into un-encrypted = signaling path. MSRP today is end-to-end and uses encryption hop by hop. = You try to break that to insert yourself between connections and you = cannot by obeying to the protocol so you must destroy it first. >=20 > You people never learn from mistakes not you admit you made any. >=20 > Is no wonder that everyone is looking for alternatives to SIP and soon = MSRP as they will both be broken. >=20 > You will obtain a huge throughput increase for no user adoption of = this protocol. >=20 > Congratulation for your excellent contribution to IETF! >=20 > Adrian >=20 >=20 > On Jun 7, 2011, at 6:24 PM, DOLLY, MARTIN C (ATTSI) wrote: >=20 >> Christer is correct in that carriers may have multiple vendors, so a = standard ensures uniformity WRT implementation. >>=20 >> Many users attached to carrier networks, so if you want MSRP = supported with the maximum number of users, you would not be objecting = to this >>=20 >> Unless purity takes precedent over support in the industry >> Martin C. Dolly >> Sent to you by AT&T... America's Fastest Mobile Broadband Network. = Rethink Possible. >> +1.609.903.3360 >>=20 >> ----- Original Message ----- >> From: Christer Holmberg >> To: Adrian Georgescu ; DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Sent: Tue Jun 07 12:07:49 2011 >> Subject: RE: [Simple] Sessmatch - an alternative approach >>=20 >>=20 >> Hi, >>=20 >>> One can do whatever is technically necessary inside a walled garden = to increase throughput and use a >>> protocol gateway to bridge to the outside if ever needed. There is = no need to invent a new MSRP related >>> standard or MSRP connection model to make this possible. I t is = between ATT and its vendors to agree on >>> how to do this the best way not the task of an IETF WG. >>>=20 >>> Breaking well established standards RFC4975 and RFC4976 in order to = satisfy your personal needs that has >>> nothing to do with Internet is not right. >>=20 >> I don't know what is broken. The WG made a decisison, quite a while = ago, to, rather than updating any of the existing RFCs, define sessmatch = as an optional extension. >>=20 >> Nobody is mandating you to implement it, and all your ongoing MSRP = sessions will continue to work just fine. >>=20 >> But, quite many needs are fullfilled by this. >>=20 >> And, yes, if it was only between ONE operator and ONE vendor, they = could sit down and agree on whatever. But, even in the so called walled = gardens, there are products by multiple vendors, and traffic between = multiple operators - and in many cases also connectivity to other types = of networks, both so called walled gardens AND the so called "Internet" = - where you of course never will find any ALGs... >>=20 >> And, ALGs are not only used for NAT traversal, and MSRP is not the = only media for which NAT traversal is needed. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>> Adrian, >>>=20 >>> I understand your use case, but it seems that you do not understand >>> ours. And without ours you will not have full >>> Deployment >>>=20 >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Services, Inc. >>> md3135@att.com >>> +1-609-903-3360 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>> Sent: Tuesday, June 07, 2011 10:56 AM >>> To: DOLLY, MARTIN C (ATTSI) >>> Cc: Simple WG >>> Subject: Re: [Simple] Sessmatch - an alternative approach >>>=20 >>> You must be kidding right? I have multiple MSTP sessions in progress = as >>> I write this email. >>>=20 >>> It is unbelievable how you can question the fact that MSRP exists >>> outside of your narrow mind closed garden thinking. >>>=20 >>> Adrian >>>=20 >>>=20 >>> On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: >>>=20 >>>> Adrian, >>>>=20 >>>> I guess you do not deal in reality... >>>>=20 >>>> Regards, >>>>=20 >>>> Martin Dolly >>>> Lead Member Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T Services, Inc. >>>> md3135@att.com >>>> +1-609-903-3360 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>>> Sent: Tuesday, June 07, 2011 10:26 AM >>>> To: DOLLY, MARTIN C (ATTSI) >>>> Cc: Simple WG >>>> Subject: Re: [Simple] Sessmatch - an alternative approach >>>>=20 >>>>=20 >>>> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >>>>=20 >>>>> Umang, >>>>>=20 >>>>> SBC's will do whatever service providers tell them. Solutions = should >>>>> assume that the media will transverse an SBC. >>>>>=20 >>>>=20 >>>>=20 >>>> Dolly, >>>>=20 >>>> You are completely wrong. >>>>=20 >>>> MSRP sessions flow just fine on the Internet without any explicit = need >>>> for an SBC by using MSRP relays for NAT traversal. >>>>=20 >>>> No solution should be based on such broken assumption. >>>>=20 >>>> Adrian >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From saul@ag-projects.com Tue Jun 7 09:54:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79C311E81A8 for ; Tue, 7 Jun 2011 09:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vN0CDvAebxZ for ; Tue, 7 Jun 2011 09:54:55 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id EA12711E8189 for ; Tue, 7 Jun 2011 09:54:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D080BB01BC; Tue, 7 Jun 2011 18:54:53 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E5F9DB017D; Tue, 7 Jun 2011 18:54:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> Date: Tue, 7 Jun 2011 18:54:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54FC704D-3B1A-443A-A9D0-250F0BC49B25@ag-projects.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> To: "Umang Singh" X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:54:55 -0000 Hi, On Jun 7, 2011, at 6:25 PM, Umang Singh wrote: > Hi, > Requirements from SBC are defined in an IETF spec = (http://tools.ietf.org/html/rfc5853). Topology hiding and media = anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I = think we should accept the presence and proliferation of SBCs and not = call them an anomaly as it is specified in an IETF specification. >=20 Thanks for the pointer, I'll go though it. > The reasons for not mandating a fallback which in turn would mean = adding the MSRP B2BUA functionality in a SBC is that SBC could anchor = media by just functioning as a TCP/IP relay just as it does for RTP = traffic. The difference with MSRP is that MSRP packets contain MSRP URIs = exchanged in signaling and matching of MSRP session to TCP connection is = done on the basis of that. For a node like the SBC, functioning as a = MSRP B2BUA has a huge performance overhead as compared to functioning as = a TCP/IP relay. As the draft in question discusses possibilities of = making MSRP work with such ALGs/SBCs in the path, I think this point is = worthy of discussion. >=20 An SBC can't anchor media just by mangling some headers and acting as a = TCP/IP relay, not for MSRP. SBCs created this problem in the first = place, but I can live with that, now we need a way to make everyone = happy. The B2BUA fallback is needed in order for interoperability to be = respected. It will not be used if all endpoints are aware of this = specification and are behind ALGs. That is, if you deploy a network with = an ALG and sessmatch (or ACE :-) ) enabled devices and you'll never use = the B2BUA. But if I'm outside of your network and I want to comunicate = with one of your users I'll need the B2BUA, in the cases previously = described in this thread. About the topology hiding, I see no way of doing it without acting as a = B2BUA, since the path line should remain untouched. Thoughts, Christen = and others? Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From md3135@att.com Tue Jun 7 09:59:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CB411E81BE for ; Tue, 7 Jun 2011 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbtg5rVfNooB for ; Tue, 7 Jun 2011 09:59:36 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id AC75711E81AB for ; Tue, 7 Jun 2011 09:59:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1307465974!22928178!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28053 invoked from network); 7 Jun 2011 16:59:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 16:59:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57GwSE0002555 for ; Tue, 7 Jun 2011 12:58:28 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57GwQAd002543 for ; Tue, 7 Jun 2011 12:58:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 7 Jun 2011 12:59:32 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC2@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlM4BuvqIoUczCTOKSi3V6/VNcFQAAMT8v From: "DOLLY, MARTIN C (ATTSI)" To: , Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 16:59:36 -0000 QWRyaWFuDQoNClRoZSBpc3N1ZSBpcyBob3cgbGFyZ2Ugb2YgYSBkZXBsb3ltZW50IGlzIGl0IGN1 cnJlbnRseSBzdXBwb3J0ZWQgaW4/DQpUaGlzIGNhcGFiaWxpdHksIHdoaWNoIGRvZXMgbm90IGFm ZmVjdCB5b3UsIHdpbGwgYnJvYWRlbiBNU1JQIHN1cHBvcnQsIGFuZCBpcyB0aGF0IG5vdCB0aGUg dWx0aW1hdGUgZ29hbD8NCg0KQXQgbGVhc3QgSSB0aGluayBzbw0KDQpDaGVlcnMsDQoNCk1hcnRp bg0KTWFydGluIEMuIERvbGx5DQpTZW50IHRvIHlvdSBieSBBVCZULi4uIEFtZXJpY2EncyBGYXN0 ZXN0IE1vYmlsZSBCcm9hZGJhbmQgTmV0d29yay4gUmV0aGluayBQb3NzaWJsZS4NCisxLjYwOS45 MDMuMzM2MA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBzaW1wbGUtYm91 bmNlc0BpZXRmLm9yZyA8c2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBTaW1wbGUgV0cgPHNp bXBsZUBpZXRmLm9yZz4NClNlbnQ6IFR1ZSBKdW4gMDcgMTI6NTM6NDMgMjAxMQ0KU3ViamVjdDog UmU6IFtTaW1wbGVdIFNlc3NtYXRjaCAtIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoDQoNCllvdSBz dGFydGVkIGZyb20gdGhlIGFzc3VtcHRpb24gdGhhdCBub2JvZHkgaGFzIGFkb3B0ZWQgTVNSUCBp biB0aGUgcmVhbCB3b3JsZCAgYW5kIHlvdSB0aG91Z2h0IHRoYXQgeW91IG1heSBjaGFuZ2UgdGhl IG9yaWdpbmFsIHNwZWNpZmljYXRpb25zIHRvIHNlcnZlIHlvdXIgcHVycG9zZS4NCg0KVGhpcyBh c3N1bXB0aW9ucyB3YXMgd3JvbmcgYXQgdGhlIGJhc2Ugc28gbXVzdCByZXZpc2UgeW91ciBhcHBy b2FjaCBhbmQgZGVhbCB3aXRoIHRoZSBmYWN0IHRoYXQgTVNSUCBwcm90b2NvbCBpcyBhZG9wdGVk LCBpdCB3b3JrcyBPSyBhbmQgeW91ciBwcm9wb3NhbCBicmVha3MgaXQuDQoNCkFkcmlhbg0KDQpP biBKdW4gNywgMjAxMSwgYXQgNjo0MyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQoNCj4g QWRyaWFuLA0KPiANCj4gQmVmb3JlIHNlc3NtYXRjaCBtYW55IHBlb3BsZSB3ZXJlIGxvb2tpbmcg Zm9yIGFuIGFsdGVybmF0aXZlIHRvIE1TUlAuIEF0IGxlYXN0IGluIG15IGV4cGVyaWVuY2UgKEkg Y2FuJ3Qgb2YgY291cnNlIHNwZWFrIG9uIGJlaGFsZiBvZiBvdGhlcnMsIGFuZCBpdCBpcyB2ZXJ5 IGNsZWFyIHRoYXQgeW91IGFuZCBJIGxpdmUgaW4gZGlmZmVyZW50IHJlYWxpdGllcywgc28geW91 IG1pZ2h0IGhhdmUgYW5vdGhlciBvcGluaW9uKSB0aGUgbnVtYmVyIG9mIHBlb3BsZSBoYXMgZ29u ZSBkb3duIGRyYW1hdGljYWxseS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBzaW1w bGUtYm91bmNlc0BpZXRmLm9yZyBbc2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBBZHJpYW4gR2Vvcmdlc2N1IFthZ0BhZy1wcm9qZWN0cy5jb21dDQo+IFNlbnQ6IFR1ZXNkYXks IEp1bmUgMDcsIDIwMTEgNzozNCBQTQ0KPiBUbzogRE9MTFksIE1BUlRJTiBDIChBVFRTSSkNCj4g Q2M6IFNpbXBsZSBXRw0KPiBTdWJqZWN0OiBSZTogW1NpbXBsZV0gU2Vzc21hdGNoIC0gYW4gYWx0 ZXJuYXRpdmUgYXBwcm9hY2gNCj4gDQo+IERlYXIgRG9sbHksDQo+IA0KPiBUaGlzIGhhcyBub3Ro aW5nIGRvIHdpdGggcHVyaXNtLg0KPiANCj4gSXQgaXMgYSBmYWN0IHRvZGF5IHRoYXQgU0lQIGlz IGJyb2tlbiBieSB0aGUgc2FtZSBhZHZvY2F0ZXMgb2YgeW91ciBpZGVhLiBXaGF0IHlvdSB0cnkg dG8gZG8gd2l0aCBNU1JQIHRvZGF5IGlzIGEgbWlycm9yIGNvcHkgd2l0aCB3aGF0IGhhcyBoYXBw ZW5lZCB3aXRoIFNJUCBhbHJlYWR5LiAgWW91IHRyeSB0byBkbyB0aGUgc2FtZSBub3cgZm9yIE1T UlAuDQo+IA0KPiBBbGxvd2luZyBpbnRlcm1lZGlhdGVzIHRvIGluc2VydCB0aGVtc2VsdmVzIGlu dG8gdW4tZW5jcnlwdGVkIHNpZ25hbGluZyBwYXRoLiBNU1JQIHRvZGF5IGlzIGVuZC10by1lbmQg YW5kIHVzZXMgZW5jcnlwdGlvbiBob3AgYnkgaG9wLiBZb3UgdHJ5IHRvIGJyZWFrIHRoYXQgdG8g aW5zZXJ0IHlvdXJzZWxmIGJldHdlZW4gY29ubmVjdGlvbnMgYW5kIHlvdSBjYW5ub3QgYnkgb2Jl eWluZyB0byB0aGUgcHJvdG9jb2wgc28geW91IG11c3QgZGVzdHJveSBpdCBmaXJzdC4NCj4gDQo+ IFlvdSBwZW9wbGUgbmV2ZXIgbGVhcm4gZnJvbSBtaXN0YWtlcyBub3QgeW91IGFkbWl0IHlvdSBt YWRlIGFueS4NCj4gDQo+IElzIG5vIHdvbmRlciB0aGF0IGV2ZXJ5b25lIGlzIGxvb2tpbmcgZm9y IGFsdGVybmF0aXZlcyB0byBTSVAgYW5kIHNvb24gTVNSUCBhcyB0aGV5IHdpbGwgYm90aCBiZSBi cm9rZW4uDQo+IA0KPiBZb3Ugd2lsbCBvYnRhaW4gYSBodWdlIHRocm91Z2hwdXQgaW5jcmVhc2Ug Zm9yIG5vIHVzZXIgYWRvcHRpb24gb2YgdGhpcyBwcm90b2NvbC4NCj4gDQo+IENvbmdyYXR1bGF0 aW9uIGZvciB5b3VyIGV4Y2VsbGVudCBjb250cmlidXRpb24gdG8gSUVURiENCj4gDQo+IEFkcmlh bg0KPiANCj4gDQo+IE9uIEp1biA3LCAyMDExLCBhdCA2OjI0IFBNLCBET0xMWSwgTUFSVElOIEMg KEFUVFNJKSB3cm90ZToNCj4gDQo+PiBDaHJpc3RlciBpcyBjb3JyZWN0IGluIHRoYXQgY2Fycmll cnMgbWF5IGhhdmUgbXVsdGlwbGUgdmVuZG9ycywgc28gYSBzdGFuZGFyZCBlbnN1cmVzIHVuaWZv cm1pdHkgV1JUIGltcGxlbWVudGF0aW9uLg0KPj4gDQo+PiBNYW55IHVzZXJzIGF0dGFjaGVkIHRv IGNhcnJpZXIgbmV0d29ya3MsIHNvIGlmIHlvdSB3YW50IE1TUlAgc3VwcG9ydGVkIHdpdGggdGhl IG1heGltdW0gbnVtYmVyIG9mIHVzZXJzLCB5b3Ugd291bGQgbm90IGJlIG9iamVjdGluZyB0byB0 aGlzDQo+PiANCj4+IFVubGVzcyBwdXJpdHkgdGFrZXMgcHJlY2VkZW50IG92ZXIgc3VwcG9ydCBp biB0aGUgaW5kdXN0cnkNCj4+IE1hcnRpbiBDLiBEb2xseQ0KPj4gU2VudCB0byB5b3UgYnkgQVQm VC4uLiBBbWVyaWNhJ3MgRmFzdGVzdCBNb2JpbGUgQnJvYWRiYW5kIE5ldHdvcmsuIFJldGhpbmsg UG9zc2libGUuDQo+PiArMS42MDkuOTAzLjMzNjANCj4+IA0KPj4gLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KPj4gRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4NCj4+IFRvOiBBZHJpYW4gR2Vvcmdlc2N1IDxhZ0BhZy1wcm9qZWN0cy5j b20+OyBET0xMWSwgTUFSVElOIEMgKEFUVFNJKQ0KPj4gQ2M6IFNpbXBsZSBXRyA8c2ltcGxlQGll dGYub3JnPg0KPj4gU2VudDogVHVlIEp1biAwNyAxMjowNzo0OSAyMDExDQo+PiBTdWJqZWN0OiBS RTogW1NpbXBsZV0gU2Vzc21hdGNoIC0gYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2gNCj4+IA0KPj4g DQo+PiBIaSwNCj4+IA0KPj4+IE9uZSBjYW4gZG8gd2hhdGV2ZXIgaXMgdGVjaG5pY2FsbHkgbmVj ZXNzYXJ5IGluc2lkZSBhIHdhbGxlZCBnYXJkZW4gdG8gaW5jcmVhc2UgdGhyb3VnaHB1dCBhbmQg dXNlIGENCj4+PiBwcm90b2NvbCBnYXRld2F5IHRvIGJyaWRnZSB0byB0aGUgb3V0c2lkZSBpZiBl dmVyIG5lZWRlZC4gIFRoZXJlIGlzIG5vIG5lZWQgdG8gaW52ZW50IGEgbmV3IE1TUlAgcmVsYXRl ZA0KPj4+IHN0YW5kYXJkIG9yIE1TUlAgY29ubmVjdGlvbiBtb2RlbCB0byBtYWtlIHRoaXMgcG9z c2libGUuIEkgdCBpcyBiZXR3ZWVuIEFUVCBhbmQgaXRzIHZlbmRvcnMgdG8gYWdyZWUgb24NCj4+ PiBob3cgdG8gZG8gdGhpcyB0aGUgYmVzdCB3YXkgbm90IHRoZSB0YXNrIG9mIGFuIElFVEYgV0cu DQo+Pj4gDQo+Pj4gQnJlYWtpbmcgd2VsbCBlc3RhYmxpc2hlZCBzdGFuZGFyZHMgUkZDNDk3NSBh bmQgUkZDNDk3NiBpbiBvcmRlciB0byBzYXRpc2Z5IHlvdXIgcGVyc29uYWwgbmVlZHMgdGhhdCBo YXMNCj4+PiBub3RoaW5nIHRvIGRvIHdpdGggSW50ZXJuZXQgaXMgbm90IHJpZ2h0Lg0KPj4gDQo+ PiBJIGRvbid0IGtub3cgd2hhdCBpcyBicm9rZW4uIFRoZSBXRyBtYWRlIGEgZGVjaXNpc29uLCBx dWl0ZSBhIHdoaWxlIGFnbywgdG8sIHJhdGhlciB0aGFuIHVwZGF0aW5nIGFueSBvZiB0aGUgZXhp c3RpbmcgUkZDcywgZGVmaW5lIHNlc3NtYXRjaCBhcyBhbiBvcHRpb25hbCBleHRlbnNpb24uDQo+ PiANCj4+IE5vYm9keSBpcyBtYW5kYXRpbmcgeW91IHRvIGltcGxlbWVudCBpdCwgYW5kIGFsbCB5 b3VyIG9uZ29pbmcgTVNSUCBzZXNzaW9ucyB3aWxsIGNvbnRpbnVlIHRvIHdvcmsganVzdCBmaW5l Lg0KPj4gDQo+PiBCdXQsIHF1aXRlIG1hbnkgbmVlZHMgYXJlIGZ1bGxmaWxsZWQgYnkgdGhpcy4N Cj4+IA0KPj4gQW5kLCB5ZXMsIGlmIGl0IHdhcyBvbmx5IGJldHdlZW4gT05FIG9wZXJhdG9yIGFu ZCBPTkUgdmVuZG9yLCB0aGV5IGNvdWxkIHNpdCBkb3duIGFuZCBhZ3JlZSBvbiB3aGF0ZXZlci4g QnV0LCBldmVuIGluIHRoZSBzbyBjYWxsZWQgd2FsbGVkIGdhcmRlbnMsIHRoZXJlIGFyZSBwcm9k dWN0cyBieSBtdWx0aXBsZSB2ZW5kb3JzLCBhbmQgdHJhZmZpYyBiZXR3ZWVuIG11bHRpcGxlIG9w ZXJhdG9ycyAtIGFuZCBpbiBtYW55IGNhc2VzIGFsc28gY29ubmVjdGl2aXR5IHRvIG90aGVyIHR5 cGVzIG9mIG5ldHdvcmtzLCBib3RoIHNvIGNhbGxlZCB3YWxsZWQgZ2FyZGVucyBBTkQgdGhlIHNv IGNhbGxlZCAiSW50ZXJuZXQiIC0gd2hlcmUgeW91IG9mIGNvdXJzZSBuZXZlciB3aWxsIGZpbmQg YW55IEFMR3MuLi4NCj4+IA0KPj4gQW5kLCBBTEdzIGFyZSBub3Qgb25seSB1c2VkIGZvciBOQVQg dHJhdmVyc2FsLCBhbmQgTVNSUCBpcyBub3QgdGhlIG9ubHkgbWVkaWEgZm9yIHdoaWNoIE5BVCB0 cmF2ZXJzYWwgaXMgbmVlZGVkLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBDaHJpc3Rlcg0K Pj4gDQo+PiANCj4+IA0KPj4+IEFkcmlhbiwNCj4+PiANCj4+PiBJIHVuZGVyc3RhbmQgeW91ciB1 c2UgY2FzZSwgYnV0IGl0IHNlZW1zIHRoYXQgeW91IGRvIG5vdCB1bmRlcnN0YW5kDQo+Pj4gb3Vy cy4gQW5kIHdpdGhvdXQgb3VycyB5b3Ugd2lsbCBub3QgaGF2ZSBmdWxsDQo+Pj4gRGVwbG95bWVu dA0KPj4+IA0KPj4+IE1hcnRpbiBEb2xseQ0KPj4+IExlYWQgTWVtYmVyIFRlY2huaWNhbCBTdGFm Zg0KPj4+IENvcmUgJiBHb3Zlcm5tZW50L1JlZ3VsYXRvcnkgU3RhbmRhcmRzDQo+Pj4gQVQmVCBT ZXJ2aWNlcywgSW5jLg0KPj4+IG1kMzEzNUBhdHQuY29tDQo+Pj4gKzEtNjA5LTkwMy0zMzYwDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ PiBGcm9tOiBBZHJpYW4gR2Vvcmdlc2N1IFttYWlsdG86YWdAYWctcHJvamVjdHMuY29tXQ0KPj4+ IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMDcsIDIwMTEgMTA6NTYgQU0NCj4+PiBUbzogRE9MTFksIE1B UlRJTiBDIChBVFRTSSkNCj4+PiBDYzogU2ltcGxlIFdHDQo+Pj4gU3ViamVjdDogUmU6IFtTaW1w bGVdIFNlc3NtYXRjaCAtIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoDQo+Pj4gDQo+Pj4gWW91IG11 c3QgYmUga2lkZGluZyByaWdodD8gSSBoYXZlIG11bHRpcGxlIE1TVFAgc2Vzc2lvbnMgaW4gcHJv Z3Jlc3MgYXMNCj4+PiBJIHdyaXRlIHRoaXMgZW1haWwuDQo+Pj4gDQo+Pj4gSXQgaXMgdW5iZWxp ZXZhYmxlIGhvdyB5b3UgY2FuIHF1ZXN0aW9uIHRoZSBmYWN0IHRoYXQgTVNSUCBleGlzdHMNCj4+ PiBvdXRzaWRlIG9mIHlvdXIgbmFycm93IG1pbmQgY2xvc2VkIGdhcmRlbiB0aGlua2luZy4NCj4+ PiANCj4+PiBBZHJpYW4NCj4+PiANCj4+PiANCj4+PiBPbiBKdW4gNywgMjAxMSwgYXQgNDo0OCBQ TSwgRE9MTFksIE1BUlRJTiBDIChBVFRTSSkgd3JvdGU6DQo+Pj4gDQo+Pj4+IEFkcmlhbiwNCj4+ Pj4gDQo+Pj4+IEkgZ3Vlc3MgeW91IGRvIG5vdCBkZWFsIGluIHJlYWxpdHkuLi4NCj4+Pj4gDQo+ Pj4+IFJlZ2FyZHMsDQo+Pj4+IA0KPj4+PiBNYXJ0aW4gRG9sbHkNCj4+Pj4gTGVhZCBNZW1iZXIg VGVjaG5pY2FsIFN0YWZmDQo+Pj4+IENvcmUgJiBHb3Zlcm5tZW50L1JlZ3VsYXRvcnkgU3RhbmRh cmRzDQo+Pj4+IEFUJlQgU2VydmljZXMsIEluYy4NCj4+Pj4gbWQzMTM1QGF0dC5jb20NCj4+Pj4g KzEtNjA5LTkwMy0zMzYwDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBBZHJpYW4gR2Vvcmdlc2N1IFttYWlsdG86 YWdAYWctcHJvamVjdHMuY29tXQ0KPj4+PiBTZW50OiBUdWVzZGF5LCBKdW5lIDA3LCAyMDExIDEw OjI2IEFNDQo+Pj4+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVFNJKQ0KPj4+PiBDYzogU2ltcGxl IFdHDQo+Pj4+IFN1YmplY3Q6IFJlOiBbU2ltcGxlXSBTZXNzbWF0Y2ggLSBhbiBhbHRlcm5hdGl2 ZSBhcHByb2FjaA0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIEp1biA3LCAyMDExLCBhdCA0OjA5IFBN LCBET0xMWSwgTUFSVElOIEMgKEFUVFNJKSB3cm90ZToNCj4+Pj4gDQo+Pj4+PiBVbWFuZywNCj4+ Pj4+IA0KPj4+Pj4gU0JDJ3Mgd2lsbCBkbyB3aGF0ZXZlciBzZXJ2aWNlIHByb3ZpZGVycyB0ZWxs IHRoZW0uIFNvbHV0aW9ucyBzaG91bGQNCj4+Pj4+IGFzc3VtZSB0aGF0IHRoZSBtZWRpYSB3aWxs IHRyYW5zdmVyc2UgYW4gU0JDLg0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gRG9sbHksDQo+ Pj4+IA0KPj4+PiBZb3UgYXJlIGNvbXBsZXRlbHkgd3JvbmcuDQo+Pj4+IA0KPj4+PiBNU1JQIHNl c3Npb25zIGZsb3cganVzdCBmaW5lIG9uIHRoZSBJbnRlcm5ldCB3aXRob3V0IGFueSBleHBsaWNp dCBuZWVkDQo+Pj4+IGZvciBhbiBTQkMgYnkgdXNpbmcgTVNSUCByZWxheXMgZm9yIE5BVCB0cmF2 ZXJzYWwuDQo+Pj4+IA0KPj4+PiBObyBzb2x1dGlvbiBzaG91bGQgYmUgYmFzZWQgb24gc3VjaCBi cm9rZW4gYXNzdW1wdGlvbi4NCj4+Pj4gDQo+Pj4+IEFkcmlhbg0KPj4+PiANCj4+Pj4gDQo+Pj4+ IA0KPj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KPj4gU2ltcGxlQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU2ltcGxlIG1haWxp bmcgbGlzdA0KPiBTaW1wbGVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaW1wbGUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KPiBTaW1wbGVAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCj4gDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaW1wbGUgbWFpbGlu ZyBsaXN0DQpTaW1wbGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ltcGxlDQo= From saul@ag-projects.com Tue Jun 7 10:00:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5411E807A for ; Tue, 7 Jun 2011 10:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0acov2UnTX6 for ; Tue, 7 Jun 2011 10:00:43 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 57BBD11E81A8 for ; Tue, 7 Jun 2011 10:00:43 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B01D0B01BC; Tue, 7 Jun 2011 19:00:42 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 3294BB017D; Tue, 7 Jun 2011 19:00:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC2@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 19:00:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7051A50A-589C-47CE-82C9-23B9B7B35F3F@ag-projects.com> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC2@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: ag@ag-projects.com, simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:00:44 -0000 On Jun 7, 2011, at 6:59 PM, DOLLY, MARTIN C (ATTSI) wrote: > Adrian >=20 > The issue is how large of a deployment is it currently supported in? > This capability, which does not affect you, will broaden MSRP support, = and is that not the ultimate goal? >=20 > At least I think so >=20 Not at the price of breaking the protocol. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue Jun 7 10:00:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFEE11E808D for ; Tue, 7 Jun 2011 10:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb6H-COlLTnl for ; Tue, 7 Jun 2011 10:00:56 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC8B711E807A for ; Tue, 7 Jun 2011 10:00:55 -0700 (PDT) Received: by qyk29 with SMTP id 29so1962844qyk.10 for ; Tue, 07 Jun 2011 10:00:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr4684005qci.209.1307466055239; Tue, 07 Jun 2011 10:00:55 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 10:00:55 -0700 (PDT) In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> Date: Tue, 7 Jun 2011 19:00:55 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Umang Singh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:00:56 -0000 2011/6/7 Umang Singh : > Requirements from SBC are defined in an IETF spec (http://tools.ietf.org/= html/rfc5853). Topology hiding and media anchoring are mentioned in Section= 3.1 and Section 3.2 respectively. I think we should accept the presence an= d proliferation of SBCs and not call them an anomaly as it is specified in = an IETF specification. Just some phrases extracted from that RFC 5853: Even though many SBCs currently behave in ways that can break end-to- end security and impact feature negotiations, there is clearly a market for them. [...] The purpose of this document is to describe functions implemented in SBCs. A special focus is given to those practices that conflict with SIP architectural principles in some way [...] The term SBC is relatively non-specific, since it is not standardized or defined anywhere. So this is just an informational RFC which just talks about the SBC (including the pain they produce!). It standarizes *nothing* and it means absolutely nothing, at least for me. Regards. -- I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jun 7 10:02:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5406211E81BE for ; Tue, 7 Jun 2011 10:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBTP5y+ckZmF for ; Tue, 7 Jun 2011 10:02:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A111E808D for ; Tue, 7 Jun 2011 10:02:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4a-4dee598960e4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.16.09774.9895EED4; Tue, 7 Jun 2011 19:02:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 7 Jun 2011 19:01:59 +0200 From: Christer Holmberg To: Adrian Georgescu Date: Tue, 7 Jun 2011 19:01:59 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlM3iI3tQK9v61Sp2uxKi4RhXUdgAACfOa Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com>, <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se>, <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> In-Reply-To: <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:02:04 -0000 Hi, >You started from the assumption that nobody has adopted MSRP in the real w= orld=20 >and you thought that you may change the original specifications to serve y= our purpose. I never said that nobody has adopted it. >This assumptions was wrong at the base so must revise your approach and de= al with the fact that MSRP=20 >protocol is adopted, My approach is to get it even more adopted. >it works OK=20 I am sure it does, in some places. >and your proposal breaks it. With the current proposal there ARE issues with fingerprint based authentic= ation. I am not sure of anything else that would be "broken". Just because you can use something in a little different way doesn't mean y= ou have broken it - especially if it works with what already exists. Regards, Christer On Jun 7, 2011, at 6:43 PM, Christer Holmberg wrote: > Adrian, > > Before sessmatch many people were looking for an alternative to MSRP. At = least in my experience (I can't of course speak on behalf of others, and it= is very clear that you and I live in different realities, so you might hav= e another opinion) the number of people has gone down dramatically. > > Regards, > > Christer > > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Adri= an Georgescu [ag@ag-projects.com] > Sent: Tuesday, June 07, 2011 7:34 PM > To: DOLLY, MARTIN C (ATTSI) > Cc: Simple WG > Subject: Re: [Simple] Sessmatch - an alternative approach > > Dear Dolly, > > This has nothing do with purism. > > It is a fact today that SIP is broken by the same advocates of your idea.= What you try to do with MSRP today is a mirror copy with what has happened= with SIP already. You try to do the same now for MSRP. > > Allowing intermediates to insert themselves into un-encrypted signaling p= ath. MSRP today is end-to-end and uses encryption hop by hop. You try to br= eak that to insert yourself between connections and you cannot by obeying t= o the protocol so you must destroy it first. > > You people never learn from mistakes not you admit you made any. > > Is no wonder that everyone is looking for alternatives to SIP and soon MS= RP as they will both be broken. > > You will obtain a huge throughput increase for no user adoption of this p= rotocol. > > Congratulation for your excellent contribution to IETF! > > Adrian > > > On Jun 7, 2011, at 6:24 PM, DOLLY, MARTIN C (ATTSI) wrote: > >> Christer is correct in that carriers may have multiple vendors, so a sta= ndard ensures uniformity WRT implementation. >> >> Many users attached to carrier networks, so if you want MSRP supported w= ith the maximum number of users, you would not be objecting to this >> >> Unless purity takes precedent over support in the industry >> Martin C. Dolly >> Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethi= nk Possible. >> +1.609.903.3360 >> >> ----- Original Message ----- >> From: Christer Holmberg >> To: Adrian Georgescu ; DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Sent: Tue Jun 07 12:07:49 2011 >> Subject: RE: [Simple] Sessmatch - an alternative approach >> >> >> Hi, >> >>> One can do whatever is technically necessary inside a walled garden to = increase throughput and use a >>> protocol gateway to bridge to the outside if ever needed. There is no = need to invent a new MSRP related >>> standard or MSRP connection model to make this possible. I t is between= ATT and its vendors to agree on >>> how to do this the best way not the task of an IETF WG. >>> >>> Breaking well established standards RFC4975 and RFC4976 in order to sat= isfy your personal needs that has >>> nothing to do with Internet is not right. >> >> I don't know what is broken. The WG made a decisison, quite a while ago,= to, rather than updating any of the existing RFCs, define sessmatch as an = optional extension. >> >> Nobody is mandating you to implement it, and all your ongoing MSRP sessi= ons will continue to work just fine. >> >> But, quite many needs are fullfilled by this. >> >> And, yes, if it was only between ONE operator and ONE vendor, they could= sit down and agree on whatever. But, even in the so called walled gardens,= there are products by multiple vendors, and traffic between multiple opera= tors - and in many cases also connectivity to other types of networks, both= so called walled gardens AND the so called "Internet" - where you of cours= e never will find any ALGs... >> >> And, ALGs are not only used for NAT traversal, and MSRP is not the only = media for which NAT traversal is needed. >> >> Regards, >> >> Christer >> >> >> >>> Adrian, >>> >>> I understand your use case, but it seems that you do not understand >>> ours. And without ours you will not have full >>> Deployment >>> >>> Martin Dolly >>> Lead Member Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T Services, Inc. >>> md3135@att.com >>> +1-609-903-3360 >>> >>> >>> >>> >>> -----Original Message----- >>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>> Sent: Tuesday, June 07, 2011 10:56 AM >>> To: DOLLY, MARTIN C (ATTSI) >>> Cc: Simple WG >>> Subject: Re: [Simple] Sessmatch - an alternative approach >>> >>> You must be kidding right? I have multiple MSTP sessions in progress as >>> I write this email. >>> >>> It is unbelievable how you can question the fact that MSRP exists >>> outside of your narrow mind closed garden thinking. >>> >>> Adrian >>> >>> >>> On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: >>> >>>> Adrian, >>>> >>>> I guess you do not deal in reality... >>>> >>>> Regards, >>>> >>>> Martin Dolly >>>> Lead Member Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T Services, Inc. >>>> md3135@att.com >>>> +1-609-903-3360 >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>>> Sent: Tuesday, June 07, 2011 10:26 AM >>>> To: DOLLY, MARTIN C (ATTSI) >>>> Cc: Simple WG >>>> Subject: Re: [Simple] Sessmatch - an alternative approach >>>> >>>> >>>> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >>>> >>>>> Umang, >>>>> >>>>> SBC's will do whatever service providers tell them. Solutions should >>>>> assume that the media will transverse an SBC. >>>>> >>>> >>>> >>>> Dolly, >>>> >>>> You are completely wrong. >>>> >>>> MSRP sessions flow just fine on the Internet without any explicit need >>>> for an SBC by using MSRP relays for NAT traversal. >>>> >>>> No solution should be based on such broken assumption. >>>> >>>> Adrian >>>> >>>> >>>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >= From ag@ag-projects.com Tue Jun 7 10:02:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6F011E81D7 for ; Tue, 7 Jun 2011 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 EIwQgOlJ+jSS for ; Tue, 7 Jun 2011 10:02:21 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id DC9DD11E808D for ; Tue, 7 Jun 2011 10:02:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 449FFB01BC; Tue, 7 Jun 2011 19:02:20 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id C053BB017D; Tue, 7 Jun 2011 19:02:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC2@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 19:02:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26EC4550-877C-478A-95FA-7022B1168F49@ag-projects.com> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC2@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:02:22 -0000 Why cannot you deploy your favorite vendor solution and use a B2BUA to = break out to the internet? No need to break any standard for this. On Jun 7, 2011, at 6:59 PM, DOLLY, MARTIN C (ATTSI) wrote: > Adrian >=20 > The issue is how large of a deployment is it currently supported in? > This capability, which does not affect you, will broaden MSRP support, = and is that not the ultimate goal? >=20 > At least I think so >=20 > Cheers, >=20 > Martin > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband Network. = Rethink Possible. > +1.609.903.3360 >=20 > ----- Original Message ----- > From: simple-bounces@ietf.org > To: Christer Holmberg > Cc: Simple WG > Sent: Tue Jun 07 12:53:43 2011 > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 > You started from the assumption that nobody has adopted MSRP in the = real world and you thought that you may change the original = specifications to serve your purpose. >=20 > This assumptions was wrong at the base so must revise your approach = and deal with the fact that MSRP protocol is adopted, it works OK and = your proposal breaks it. >=20 > Adrian >=20 > On Jun 7, 2011, at 6:43 PM, Christer Holmberg wrote: >=20 >> Adrian, >>=20 >> Before sessmatch many people were looking for an alternative to MSRP. = At least in my experience (I can't of course speak on behalf of others, = and it is very clear that you and I live in different realities, so you = might have another opinion) the number of people has gone down = dramatically. >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Adrian Georgescu [ag@ag-projects.com] >> Sent: Tuesday, June 07, 2011 7:34 PM >> To: DOLLY, MARTIN C (ATTSI) >> Cc: Simple WG >> Subject: Re: [Simple] Sessmatch - an alternative approach >>=20 >> Dear Dolly, >>=20 >> This has nothing do with purism. >>=20 >> It is a fact today that SIP is broken by the same advocates of your = idea. What you try to do with MSRP today is a mirror copy with what has = happened with SIP already. You try to do the same now for MSRP. >>=20 >> Allowing intermediates to insert themselves into un-encrypted = signaling path. MSRP today is end-to-end and uses encryption hop by hop. = You try to break that to insert yourself between connections and you = cannot by obeying to the protocol so you must destroy it first. >>=20 >> You people never learn from mistakes not you admit you made any. >>=20 >> Is no wonder that everyone is looking for alternatives to SIP and = soon MSRP as they will both be broken. >>=20 >> You will obtain a huge throughput increase for no user adoption of = this protocol. >>=20 >> Congratulation for your excellent contribution to IETF! >>=20 >> Adrian >>=20 >>=20 >> On Jun 7, 2011, at 6:24 PM, DOLLY, MARTIN C (ATTSI) wrote: >>=20 >>> Christer is correct in that carriers may have multiple vendors, so a = standard ensures uniformity WRT implementation. >>>=20 >>> Many users attached to carrier networks, so if you want MSRP = supported with the maximum number of users, you would not be objecting = to this >>>=20 >>> Unless purity takes precedent over support in the industry >>> Martin C. Dolly >>> Sent to you by AT&T... America's Fastest Mobile Broadband Network. = Rethink Possible. >>> +1.609.903.3360 >>>=20 >>> ----- Original Message ----- >>> From: Christer Holmberg >>> To: Adrian Georgescu ; DOLLY, MARTIN C (ATTSI) >>> Cc: Simple WG >>> Sent: Tue Jun 07 12:07:49 2011 >>> Subject: RE: [Simple] Sessmatch - an alternative approach >>>=20 >>>=20 >>> Hi, >>>=20 >>>> One can do whatever is technically necessary inside a walled garden = to increase throughput and use a >>>> protocol gateway to bridge to the outside if ever needed. There is = no need to invent a new MSRP related >>>> standard or MSRP connection model to make this possible. I t is = between ATT and its vendors to agree on >>>> how to do this the best way not the task of an IETF WG. >>>>=20 >>>> Breaking well established standards RFC4975 and RFC4976 in order to = satisfy your personal needs that has >>>> nothing to do with Internet is not right. >>>=20 >>> I don't know what is broken. The WG made a decisison, quite a while = ago, to, rather than updating any of the existing RFCs, define sessmatch = as an optional extension. >>>=20 >>> Nobody is mandating you to implement it, and all your ongoing MSRP = sessions will continue to work just fine. >>>=20 >>> But, quite many needs are fullfilled by this. >>>=20 >>> And, yes, if it was only between ONE operator and ONE vendor, they = could sit down and agree on whatever. But, even in the so called walled = gardens, there are products by multiple vendors, and traffic between = multiple operators - and in many cases also connectivity to other types = of networks, both so called walled gardens AND the so called "Internet" = - where you of course never will find any ALGs... >>>=20 >>> And, ALGs are not only used for NAT traversal, and MSRP is not the = only media for which NAT traversal is needed. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>> Adrian, >>>>=20 >>>> I understand your use case, but it seems that you do not understand >>>> ours. And without ours you will not have full >>>> Deployment >>>>=20 >>>> Martin Dolly >>>> Lead Member Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T Services, Inc. >>>> md3135@att.com >>>> +1-609-903-3360 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>>> Sent: Tuesday, June 07, 2011 10:56 AM >>>> To: DOLLY, MARTIN C (ATTSI) >>>> Cc: Simple WG >>>> Subject: Re: [Simple] Sessmatch - an alternative approach >>>>=20 >>>> You must be kidding right? I have multiple MSTP sessions in = progress as >>>> I write this email. >>>>=20 >>>> It is unbelievable how you can question the fact that MSRP exists >>>> outside of your narrow mind closed garden thinking. >>>>=20 >>>> Adrian >>>>=20 >>>>=20 >>>> On Jun 7, 2011, at 4:48 PM, DOLLY, MARTIN C (ATTSI) wrote: >>>>=20 >>>>> Adrian, >>>>>=20 >>>>> I guess you do not deal in reality... >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Martin Dolly >>>>> Lead Member Technical Staff >>>>> Core & Government/Regulatory Standards >>>>> AT&T Services, Inc. >>>>> md3135@att.com >>>>> +1-609-903-3360 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Adrian Georgescu [mailto:ag@ag-projects.com] >>>>> Sent: Tuesday, June 07, 2011 10:26 AM >>>>> To: DOLLY, MARTIN C (ATTSI) >>>>> Cc: Simple WG >>>>> Subject: Re: [Simple] Sessmatch - an alternative approach >>>>>=20 >>>>>=20 >>>>> On Jun 7, 2011, at 4:09 PM, DOLLY, MARTIN C (ATTSI) wrote: >>>>>=20 >>>>>> Umang, >>>>>>=20 >>>>>> SBC's will do whatever service providers tell them. Solutions = should >>>>>> assume that the media will transverse an SBC. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> Dolly, >>>>>=20 >>>>> You are completely wrong. >>>>>=20 >>>>> MSRP sessions flow just fine on the Internet without any explicit = need >>>>> for an SBC by using MSRP relays for NAT traversal. >>>>>=20 >>>>> No solution should be based on such broken assumption. >>>>>=20 >>>>> Adrian >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ag@ag-projects.com Tue Jun 7 10:04:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D7211E81EA for ; Tue, 7 Jun 2011 10:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 0yunIgaBmxEQ for ; Tue, 7 Jun 2011 10:04:14 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 03AAD11E81E9 for ; Tue, 7 Jun 2011 10:04:14 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 5A259B017D; Tue, 7 Jun 2011 19:04:13 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id E065DB017D; Tue, 7 Jun 2011 19:04:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Jun 2011 19:04:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com>, <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se>, <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:04:14 -0000 >> it works OK > > I am sure it does, in some places. It works on Internet, and this is the point, isn't it? IETF is developing Internet standards not something else as far as I know. From ibc@aliax.net Tue Jun 7 10:05:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EEF11E8153 for ; Tue, 7 Jun 2011 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qwdo-CwGS385 for ; Tue, 7 Jun 2011 10:05:46 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6643411E81D7 for ; Tue, 7 Jun 2011 10:05:46 -0700 (PDT) Received: by qyk29 with SMTP id 29so1965550qyk.10 for ; Tue, 07 Jun 2011 10:05:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr4688983qci.209.1307466345782; Tue, 07 Jun 2011 10:05:45 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 10:05:45 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Jun 2011 19:05:45 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:05:47 -0000 2011/6/7 Christer Holmberg : >>it works OK (MSRP) > > I am sure it does, in some places. In all nature places. Adding an ALG in a network is not a "nature place". RFC 4875 in conjunction with 4876 could work correctly in ANY pure IP/TCP scenario. If you add an ALG you are breaking the scenario. >>and your proposal breaks it. > > With the current proposal there ARE issues with fingerprint based authent= ication. I am not sure of anything else that would be "broken". That's right. BTW what does fingerprint based authentication? is it related to the origin IP? something as mathing the origin IP with the IP belonging to the provided domain? --=20 I=C3=B1aki Baz Castillo From md3135@att.com Tue Jun 7 10:07:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D029C11E8072 for ; Tue, 7 Jun 2011 10:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb8xGSDlECnp for ; Tue, 7 Jun 2011 10:07:43 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 77DBD11E80E0 for ; Tue, 7 Jun 2011 10:07:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1307466462!22941605!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28361 invoked from network); 7 Jun 2011 17:07:42 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jun 2011 17:07:42 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57H6aH8014018 for ; Tue, 7 Jun 2011 13:06:36 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p57H6VdO013939 for ; Tue, 7 Jun 2011 13:06:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 7 Jun 2011 13:07:37 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC3@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlNLtnNr3cdnwqQJaFlKUYy+9flgAAKtmr From: "DOLLY, MARTIN C (ATTSI)" To: Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:07:44 -0000 QmVjYXVzZSBhIHN0YW5kYXJkIGlzIG5lZWRlZCBpbiB0aGUgY2FycmllciBzcGFjZS4NCg0KQlRX LCB0aGUgc2FtZSBjYXJyaWVycyB3aG8gZGVwbG95IHJvdXRlcnMgdGhhdCBtYWtlIHVwIHRoZSAi aW50ZXJuZXQiDQoNCk1hcnRpbiBDLiBEb2xseQ0KU2VudCB0byB5b3UgYnkgQVQmVC4uLiBBbWVy aWNhJ3MgRmFzdGVzdCBNb2JpbGUgQnJvYWRiYW5kIE5ldHdvcmsuIFJldGhpbmsgUG9zc2libGUu DQorMS42MDkuOTAzLjMzNjANCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTog QWRyaWFuIEdlb3JnZXNjdSA8YWdAYWctcHJvamVjdHMuY29tPg0KVG86IERPTExZLCBNQVJUSU4g QyAoQVRUU0kpDQpDYzogU2ltcGxlIFdHIDxzaW1wbGVAaWV0Zi5vcmc+DQpTZW50OiBUdWUgSnVu IDA3IDEzOjAyOjE3IDIwMTENClN1YmplY3Q6IFJlOiBbU2ltcGxlXSBTZXNzbWF0Y2ggLSBhbiBh bHRlcm5hdGl2ZSBhcHByb2FjaA0KDQpXaHkgY2Fubm90IHlvdSBkZXBsb3kgeW91ciBmYXZvcml0 ZSB2ZW5kb3Igc29sdXRpb24gYW5kIHVzZSBhIEIyQlVBIHRvIGJyZWFrIG91dCB0byB0aGUgaW50 ZXJuZXQ/DQoNCk5vIG5lZWQgdG8gYnJlYWsgYW55IHN0YW5kYXJkIGZvciB0aGlzLg0KDQpPbiBK dW4gNywgMjAxMSwgYXQgNjo1OSBQTSwgRE9MTFksIE1BUlRJTiBDIChBVFRTSSkgd3JvdGU6DQoN Cj4gQWRyaWFuDQo+IA0KPiBUaGUgaXNzdWUgaXMgaG93IGxhcmdlIG9mIGEgZGVwbG95bWVudCBp cyBpdCBjdXJyZW50bHkgc3VwcG9ydGVkIGluPw0KPiBUaGlzIGNhcGFiaWxpdHksIHdoaWNoIGRv ZXMgbm90IGFmZmVjdCB5b3UsIHdpbGwgYnJvYWRlbiBNU1JQIHN1cHBvcnQsIGFuZCBpcyB0aGF0 IG5vdCB0aGUgdWx0aW1hdGUgZ29hbD8NCj4gDQo+IEF0IGxlYXN0IEkgdGhpbmsgc28NCj4gDQo+ IENoZWVycywNCj4gDQo+IE1hcnRpbg0KPiBNYXJ0aW4gQy4gRG9sbHkNCj4gU2VudCB0byB5b3Ug YnkgQVQmVC4uLiBBbWVyaWNhJ3MgRmFzdGVzdCBNb2JpbGUgQnJvYWRiYW5kIE5ldHdvcmsuIFJl dGhpbmsgUG9zc2libGUuDQo+ICsxLjYwOS45MDMuMzM2MA0KPiANCj4gLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiBzaW1wbGUtYm91bmNlc0BpZXRmLm9yZyA8c2ltcGxlLWJv dW5jZXNAaWV0Zi5vcmc+DQo+IFRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPg0KPiBDYzogU2ltcGxlIFdHIDxzaW1wbGVAaWV0Zi5vcmc+DQo+IFNl bnQ6IFR1ZSBKdW4gMDcgMTI6NTM6NDMgMjAxMQ0KPiBTdWJqZWN0OiBSZTogW1NpbXBsZV0gU2Vz c21hdGNoIC0gYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2gNCj4gDQo+IFlvdSBzdGFydGVkIGZyb20g dGhlIGFzc3VtcHRpb24gdGhhdCBub2JvZHkgaGFzIGFkb3B0ZWQgTVNSUCBpbiB0aGUgcmVhbCB3 b3JsZCAgYW5kIHlvdSB0aG91Z2h0IHRoYXQgeW91IG1heSBjaGFuZ2UgdGhlIG9yaWdpbmFsIHNw ZWNpZmljYXRpb25zIHRvIHNlcnZlIHlvdXIgcHVycG9zZS4NCj4gDQo+IFRoaXMgYXNzdW1wdGlv bnMgd2FzIHdyb25nIGF0IHRoZSBiYXNlIHNvIG11c3QgcmV2aXNlIHlvdXIgYXBwcm9hY2ggYW5k IGRlYWwgd2l0aCB0aGUgZmFjdCB0aGF0IE1TUlAgcHJvdG9jb2wgaXMgYWRvcHRlZCwgaXQgd29y a3MgT0sgYW5kIHlvdXIgcHJvcG9zYWwgYnJlYWtzIGl0Lg0KPiANCj4gQWRyaWFuDQo+IA0KPiBP biBKdW4gNywgMjAxMSwgYXQgNjo0MyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+IA0K Pj4gQWRyaWFuLA0KPj4gDQo+PiBCZWZvcmUgc2Vzc21hdGNoIG1hbnkgcGVvcGxlIHdlcmUgbG9v a2luZyBmb3IgYW4gYWx0ZXJuYXRpdmUgdG8gTVNSUC4gQXQgbGVhc3QgaW4gbXkgZXhwZXJpZW5j ZSAoSSBjYW4ndCBvZiBjb3Vyc2Ugc3BlYWsgb24gYmVoYWxmIG9mIG90aGVycywgYW5kIGl0IGlz IHZlcnkgY2xlYXIgdGhhdCB5b3UgYW5kIEkgbGl2ZSBpbiBkaWZmZXJlbnQgcmVhbGl0aWVzLCBz byB5b3UgbWlnaHQgaGF2ZSBhbm90aGVyIG9waW5pb24pIHRoZSBudW1iZXIgb2YgcGVvcGxlIGhh cyBnb25lIGRvd24gZHJhbWF0aWNhbGx5Lg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBDaHJp c3Rlcg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBGcm9tOiBzaW1wbGUtYm91bmNlc0BpZXRmLm9yZyBbc2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBBZHJpYW4gR2Vvcmdlc2N1IFthZ0BhZy1wcm9qZWN0cy5jb21dDQo+PiBT ZW50OiBUdWVzZGF5LCBKdW5lIDA3LCAyMDExIDc6MzQgUE0NCj4+IFRvOiBET0xMWSwgTUFSVElO IEMgKEFUVFNJKQ0KPj4gQ2M6IFNpbXBsZSBXRw0KPj4gU3ViamVjdDogUmU6IFtTaW1wbGVdIFNl c3NtYXRjaCAtIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoDQo+PiANCj4+IERlYXIgRG9sbHksDQo+ PiANCj4+IFRoaXMgaGFzIG5vdGhpbmcgZG8gd2l0aCBwdXJpc20uDQo+PiANCj4+IEl0IGlzIGEg ZmFjdCB0b2RheSB0aGF0IFNJUCBpcyBicm9rZW4gYnkgdGhlIHNhbWUgYWR2b2NhdGVzIG9mIHlv dXIgaWRlYS4gV2hhdCB5b3UgdHJ5IHRvIGRvIHdpdGggTVNSUCB0b2RheSBpcyBhIG1pcnJvciBj b3B5IHdpdGggd2hhdCBoYXMgaGFwcGVuZWQgd2l0aCBTSVAgYWxyZWFkeS4gIFlvdSB0cnkgdG8g ZG8gdGhlIHNhbWUgbm93IGZvciBNU1JQLg0KPj4gDQo+PiBBbGxvd2luZyBpbnRlcm1lZGlhdGVz IHRvIGluc2VydCB0aGVtc2VsdmVzIGludG8gdW4tZW5jcnlwdGVkIHNpZ25hbGluZyBwYXRoLiBN U1JQIHRvZGF5IGlzIGVuZC10by1lbmQgYW5kIHVzZXMgZW5jcnlwdGlvbiBob3AgYnkgaG9wLiBZ b3UgdHJ5IHRvIGJyZWFrIHRoYXQgdG8gaW5zZXJ0IHlvdXJzZWxmIGJldHdlZW4gY29ubmVjdGlv bnMgYW5kIHlvdSBjYW5ub3QgYnkgb2JleWluZyB0byB0aGUgcHJvdG9jb2wgc28geW91IG11c3Qg ZGVzdHJveSBpdCBmaXJzdC4NCj4+IA0KPj4gWW91IHBlb3BsZSBuZXZlciBsZWFybiBmcm9tIG1p c3Rha2VzIG5vdCB5b3UgYWRtaXQgeW91IG1hZGUgYW55Lg0KPj4gDQo+PiBJcyBubyB3b25kZXIg dGhhdCBldmVyeW9uZSBpcyBsb29raW5nIGZvciBhbHRlcm5hdGl2ZXMgdG8gU0lQIGFuZCBzb29u IE1TUlAgYXMgdGhleSB3aWxsIGJvdGggYmUgYnJva2VuLg0KPj4gDQo+PiBZb3Ugd2lsbCBvYnRh aW4gYSBodWdlIHRocm91Z2hwdXQgaW5jcmVhc2UgZm9yIG5vIHVzZXIgYWRvcHRpb24gb2YgdGhp cyBwcm90b2NvbC4NCj4+IA0KPj4gQ29uZ3JhdHVsYXRpb24gZm9yIHlvdXIgZXhjZWxsZW50IGNv bnRyaWJ1dGlvbiB0byBJRVRGIQ0KPj4gDQo+PiBBZHJpYW4NCj4+IA0KPj4gDQo+PiBPbiBKdW4g NywgMjAxMSwgYXQgNjoyNCBQTSwgRE9MTFksIE1BUlRJTiBDIChBVFRTSSkgd3JvdGU6DQo+PiAN Cj4+PiBDaHJpc3RlciBpcyBjb3JyZWN0IGluIHRoYXQgY2FycmllcnMgbWF5IGhhdmUgbXVsdGlw bGUgdmVuZG9ycywgc28gYSBzdGFuZGFyZCBlbnN1cmVzIHVuaWZvcm1pdHkgV1JUIGltcGxlbWVu dGF0aW9uLg0KPj4+IA0KPj4+IE1hbnkgdXNlcnMgYXR0YWNoZWQgdG8gY2FycmllciBuZXR3b3Jr cywgc28gaWYgeW91IHdhbnQgTVNSUCBzdXBwb3J0ZWQgd2l0aCB0aGUgbWF4aW11bSBudW1iZXIg b2YgdXNlcnMsIHlvdSB3b3VsZCBub3QgYmUgb2JqZWN0aW5nIHRvIHRoaXMNCj4+PiANCj4+PiBV bmxlc3MgcHVyaXR5IHRha2VzIHByZWNlZGVudCBvdmVyIHN1cHBvcnQgaW4gdGhlIGluZHVzdHJ5 DQo+Pj4gTWFydGluIEMuIERvbGx5DQo+Pj4gU2VudCB0byB5b3UgYnkgQVQmVC4uLiBBbWVyaWNh J3MgRmFzdGVzdCBNb2JpbGUgQnJvYWRiYW5kIE5ldHdvcmsuIFJldGhpbmsgUG9zc2libGUuDQo+ Pj4gKzEuNjA5LjkwMy4zMzYwDQo+Pj4gDQo+Pj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LQ0KPj4+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+DQo+Pj4gVG86IEFkcmlhbiBHZW9yZ2VzY3UgPGFnQGFnLXByb2plY3RzLmNvbT47IERP TExZLCBNQVJUSU4gQyAoQVRUU0kpDQo+Pj4gQ2M6IFNpbXBsZSBXRyA8c2ltcGxlQGlldGYub3Jn Pg0KPj4+IFNlbnQ6IFR1ZSBKdW4gMDcgMTI6MDc6NDkgMjAxMQ0KPj4+IFN1YmplY3Q6IFJFOiBb U2ltcGxlXSBTZXNzbWF0Y2ggLSBhbiBhbHRlcm5hdGl2ZSBhcHByb2FjaA0KPj4+IA0KPj4+IA0K Pj4+IEhpLA0KPj4+IA0KPj4+PiBPbmUgY2FuIGRvIHdoYXRldmVyIGlzIHRlY2huaWNhbGx5IG5l Y2Vzc2FyeSBpbnNpZGUgYSB3YWxsZWQgZ2FyZGVuIHRvIGluY3JlYXNlIHRocm91Z2hwdXQgYW5k IHVzZSBhDQo+Pj4+IHByb3RvY29sIGdhdGV3YXkgdG8gYnJpZGdlIHRvIHRoZSBvdXRzaWRlIGlm IGV2ZXIgbmVlZGVkLiAgVGhlcmUgaXMgbm8gbmVlZCB0byBpbnZlbnQgYSBuZXcgTVNSUCByZWxh dGVkDQo+Pj4+IHN0YW5kYXJkIG9yIE1TUlAgY29ubmVjdGlvbiBtb2RlbCB0byBtYWtlIHRoaXMg cG9zc2libGUuIEkgdCBpcyBiZXR3ZWVuIEFUVCBhbmQgaXRzIHZlbmRvcnMgdG8gYWdyZWUgb24N Cj4+Pj4gaG93IHRvIGRvIHRoaXMgdGhlIGJlc3Qgd2F5IG5vdCB0aGUgdGFzayBvZiBhbiBJRVRG IFdHLg0KPj4+PiANCj4+Pj4gQnJlYWtpbmcgd2VsbCBlc3RhYmxpc2hlZCBzdGFuZGFyZHMgUkZD NDk3NSBhbmQgUkZDNDk3NiBpbiBvcmRlciB0byBzYXRpc2Z5IHlvdXIgcGVyc29uYWwgbmVlZHMg dGhhdCBoYXMNCj4+Pj4gbm90aGluZyB0byBkbyB3aXRoIEludGVybmV0IGlzIG5vdCByaWdodC4N Cj4+PiANCj4+PiBJIGRvbid0IGtub3cgd2hhdCBpcyBicm9rZW4uIFRoZSBXRyBtYWRlIGEgZGVj aXNpc29uLCBxdWl0ZSBhIHdoaWxlIGFnbywgdG8sIHJhdGhlciB0aGFuIHVwZGF0aW5nIGFueSBv ZiB0aGUgZXhpc3RpbmcgUkZDcywgZGVmaW5lIHNlc3NtYXRjaCBhcyBhbiBvcHRpb25hbCBleHRl bnNpb24uDQo+Pj4gDQo+Pj4gTm9ib2R5IGlzIG1hbmRhdGluZyB5b3UgdG8gaW1wbGVtZW50IGl0 LCBhbmQgYWxsIHlvdXIgb25nb2luZyBNU1JQIHNlc3Npb25zIHdpbGwgY29udGludWUgdG8gd29y ayBqdXN0IGZpbmUuDQo+Pj4gDQo+Pj4gQnV0LCBxdWl0ZSBtYW55IG5lZWRzIGFyZSBmdWxsZmls bGVkIGJ5IHRoaXMuDQo+Pj4gDQo+Pj4gQW5kLCB5ZXMsIGlmIGl0IHdhcyBvbmx5IGJldHdlZW4g T05FIG9wZXJhdG9yIGFuZCBPTkUgdmVuZG9yLCB0aGV5IGNvdWxkIHNpdCBkb3duIGFuZCBhZ3Jl ZSBvbiB3aGF0ZXZlci4gQnV0LCBldmVuIGluIHRoZSBzbyBjYWxsZWQgd2FsbGVkIGdhcmRlbnMs IHRoZXJlIGFyZSBwcm9kdWN0cyBieSBtdWx0aXBsZSB2ZW5kb3JzLCBhbmQgdHJhZmZpYyBiZXR3 ZWVuIG11bHRpcGxlIG9wZXJhdG9ycyAtIGFuZCBpbiBtYW55IGNhc2VzIGFsc28gY29ubmVjdGl2 aXR5IHRvIG90aGVyIHR5cGVzIG9mIG5ldHdvcmtzLCBib3RoIHNvIGNhbGxlZCB3YWxsZWQgZ2Fy ZGVucyBBTkQgdGhlIHNvIGNhbGxlZCAiSW50ZXJuZXQiIC0gd2hlcmUgeW91IG9mIGNvdXJzZSBu ZXZlciB3aWxsIGZpbmQgYW55IEFMR3MuLi4NCj4+PiANCj4+PiBBbmQsIEFMR3MgYXJlIG5vdCBv bmx5IHVzZWQgZm9yIE5BVCB0cmF2ZXJzYWwsIGFuZCBNU1JQIGlzIG5vdCB0aGUgb25seSBtZWRp YSBmb3Igd2hpY2ggTkFUIHRyYXZlcnNhbCBpcyBuZWVkZWQuDQo+Pj4gDQo+Pj4gUmVnYXJkcywN Cj4+PiANCj4+PiBDaHJpc3Rlcg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+PiBBZHJpYW4sDQo+Pj4+ IA0KPj4+PiBJIHVuZGVyc3RhbmQgeW91ciB1c2UgY2FzZSwgYnV0IGl0IHNlZW1zIHRoYXQgeW91 IGRvIG5vdCB1bmRlcnN0YW5kDQo+Pj4+IG91cnMuIEFuZCB3aXRob3V0IG91cnMgeW91IHdpbGwg bm90IGhhdmUgZnVsbA0KPj4+PiBEZXBsb3ltZW50DQo+Pj4+IA0KPj4+PiBNYXJ0aW4gRG9sbHkN Cj4+Pj4gTGVhZCBNZW1iZXIgVGVjaG5pY2FsIFN0YWZmDQo+Pj4+IENvcmUgJiBHb3Zlcm5tZW50 L1JlZ3VsYXRvcnkgU3RhbmRhcmRzDQo+Pj4+IEFUJlQgU2VydmljZXMsIEluYy4NCj4+Pj4gbWQz MTM1QGF0dC5jb20NCj4+Pj4gKzEtNjA5LTkwMy0zMzYwDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+ Pj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBBZHJpYW4g R2Vvcmdlc2N1IFttYWlsdG86YWdAYWctcHJvamVjdHMuY29tXQ0KPj4+PiBTZW50OiBUdWVzZGF5 LCBKdW5lIDA3LCAyMDExIDEwOjU2IEFNDQo+Pj4+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVFNJ KQ0KPj4+PiBDYzogU2ltcGxlIFdHDQo+Pj4+IFN1YmplY3Q6IFJlOiBbU2ltcGxlXSBTZXNzbWF0 Y2ggLSBhbiBhbHRlcm5hdGl2ZSBhcHByb2FjaA0KPj4+PiANCj4+Pj4gWW91IG11c3QgYmUga2lk ZGluZyByaWdodD8gSSBoYXZlIG11bHRpcGxlIE1TVFAgc2Vzc2lvbnMgaW4gcHJvZ3Jlc3MgYXMN Cj4+Pj4gSSB3cml0ZSB0aGlzIGVtYWlsLg0KPj4+PiANCj4+Pj4gSXQgaXMgdW5iZWxpZXZhYmxl IGhvdyB5b3UgY2FuIHF1ZXN0aW9uIHRoZSBmYWN0IHRoYXQgTVNSUCBleGlzdHMNCj4+Pj4gb3V0 c2lkZSBvZiB5b3VyIG5hcnJvdyBtaW5kIGNsb3NlZCBnYXJkZW4gdGhpbmtpbmcuDQo+Pj4+IA0K Pj4+PiBBZHJpYW4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPbiBKdW4gNywgMjAxMSwgYXQgNDo0OCBQ TSwgRE9MTFksIE1BUlRJTiBDIChBVFRTSSkgd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gQWRyaWFuLA0K Pj4+Pj4gDQo+Pj4+PiBJIGd1ZXNzIHlvdSBkbyBub3QgZGVhbCBpbiByZWFsaXR5Li4uDQo+Pj4+ PiANCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiANCj4+Pj4+IE1hcnRpbiBEb2xseQ0KPj4+Pj4gTGVh ZCBNZW1iZXIgVGVjaG5pY2FsIFN0YWZmDQo+Pj4+PiBDb3JlICYgR292ZXJubWVudC9SZWd1bGF0 b3J5IFN0YW5kYXJkcw0KPj4+Pj4gQVQmVCBTZXJ2aWNlcywgSW5jLg0KPj4+Pj4gbWQzMTM1QGF0 dC5jb20NCj4+Pj4+ICsxLTYwOS05MDMtMzM2MA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogQWRyaWFu IEdlb3JnZXNjdSBbbWFpbHRvOmFnQGFnLXByb2plY3RzLmNvbV0NCj4+Pj4+IFNlbnQ6IFR1ZXNk YXksIEp1bmUgMDcsIDIwMTEgMTA6MjYgQU0NCj4+Pj4+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFU VFNJKQ0KPj4+Pj4gQ2M6IFNpbXBsZSBXRw0KPj4+Pj4gU3ViamVjdDogUmU6IFtTaW1wbGVdIFNl c3NtYXRjaCAtIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4g T24gSnVuIDcsIDIwMTEsIGF0IDQ6MDkgUE0sIERPTExZLCBNQVJUSU4gQyAoQVRUU0kpIHdyb3Rl Og0KPj4+Pj4gDQo+Pj4+Pj4gVW1hbmcsDQo+Pj4+Pj4gDQo+Pj4+Pj4gU0JDJ3Mgd2lsbCBkbyB3 aGF0ZXZlciBzZXJ2aWNlIHByb3ZpZGVycyB0ZWxsIHRoZW0uIFNvbHV0aW9ucyBzaG91bGQNCj4+ Pj4+PiBhc3N1bWUgdGhhdCB0aGUgbWVkaWEgd2lsbCB0cmFuc3ZlcnNlIGFuIFNCQy4NCj4+Pj4+ PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBEb2xseSwNCj4+Pj4+IA0KPj4+Pj4gWW91IGFyZSBj b21wbGV0ZWx5IHdyb25nLg0KPj4+Pj4gDQo+Pj4+PiBNU1JQIHNlc3Npb25zIGZsb3cganVzdCBm aW5lIG9uIHRoZSBJbnRlcm5ldCB3aXRob3V0IGFueSBleHBsaWNpdCBuZWVkDQo+Pj4+PiBmb3Ig YW4gU0JDIGJ5IHVzaW5nIE1TUlAgcmVsYXlzIGZvciBOQVQgdHJhdmVyc2FsLg0KPj4+Pj4gDQo+ Pj4+PiBObyBzb2x1dGlvbiBzaG91bGQgYmUgYmFzZWQgb24gc3VjaCBicm9rZW4gYXNzdW1wdGlv bi4NCj4+Pj4+IA0KPj4+Pj4gQWRyaWFuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0K Pj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KPj4+IFNpbXBsZUBpZXRmLm9yZw0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlDQo+PiANCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBTaW1wbGUgbWFpbGlu ZyBsaXN0DQo+PiBTaW1wbGVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ltcGxlDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KPj4gU2ltcGxlQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KPj4gDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBT aW1wbGUgbWFpbGluZyBsaXN0DQo+IFNpbXBsZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KDQo= From ibc@aliax.net Tue Jun 7 10:11:00 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0711E8072 for ; Tue, 7 Jun 2011 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2MWnfxNf6tB for ; Tue, 7 Jun 2011 10:11:00 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D919811E80E0 for ; Tue, 7 Jun 2011 10:10:59 -0700 (PDT) Received: by qwc23 with SMTP id 23so3813595qwc.31 for ; Tue, 07 Jun 2011 10:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr4668753qcb.285.1307466659353; Tue, 07 Jun 2011 10:10:59 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 7 Jun 2011 10:10:59 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC3@gaalpa1msgusr7e.ugd.att.com> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEC3@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 7 Jun 2011 19:10:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ag@ag-projects.com, simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:11:00 -0000 2011/6/7 DOLLY, MARTIN C (ATTSI) : > BTW, the same carriers who deploy routers that make up the "internet" Thanks a lot carriers for making Internet possible. PS: Please don't break it now. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jun 7 10:14:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8721F8465 for ; Tue, 7 Jun 2011 10:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blZOeRCBdG3O for ; Tue, 7 Jun 2011 10:14:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 338FD21F8467 for ; Tue, 7 Jun 2011 10:14:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-c2-4dee5c878a75 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FC.E8.09774.78C5EED4; Tue, 7 Jun 2011 19:14:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 7 Jun 2011 19:14:47 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 7 Jun 2011 19:14:47 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlNSVFR6UhQxwAQSask8pPOr9J0QAAIzBC Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42A@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:14:50 -0000 Hi, >>>it works OK (MSRP) >> >> I am sure it does, in some places. > >In all nature places. Adding an ALG in a network is not a "nature place". >RFC 4875 in conjunction with 4876 could work correctly in ANY pure >IP/TCP scenario. If you add an ALG you are breaking the scenario. Whatever we want to call them, they are out there. >>>and your proposal breaks it. >> >> With the current proposal there ARE issues with fingerprint based authen= tication. I am not sure of anything else that would be "broken". > >That's right. BTW what does fingerprint based authentication? is it >related to the origin IP? something as mathing the origin IP with the >IP belonging to the provided domain? It relies on SDP integrity, as a self-signed certificate hash value is carr= ied in the SDP. Regards, Christer= From ag@ag-projects.com Tue Jun 7 10:21:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375E11E8080 for ; Tue, 7 Jun 2011 10:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 eAKgkq7oNNCs for ; Tue, 7 Jun 2011 10:21:24 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 42CCC11E8165 for ; Tue, 7 Jun 2011 10:21:23 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 767A9B01C0; Tue, 7 Jun 2011 19:21:22 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 0FA29B017D; Tue, 7 Jun 2011 19:21:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42A@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 7 Jun 2011 19:21:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01CBE593-5748-4716-8F5C-3341FF89C616@ag-projects.com> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42A@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:21:25 -0000 > It relies on SDP integrity, as a self-signed certificate hash value is = carried in the SDP. >=20 I have deployed SIP for years in many countries with several vendors and = I never say this happening. I have attended many SIPIT events and I do not recall anyone testing = such thing . Relying on phantom concepts seldom to be found as a fallback mechanisms = is a weak argument. Adrian From christer.holmberg@ericsson.com Tue Jun 7 10:28:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA15711E80AA for ; Tue, 7 Jun 2011 10:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbGM5UHPbf0m for ; Tue, 7 Jun 2011 10:28:31 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E712D11E807F for ; Tue, 7 Jun 2011 10:28:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-3d-4dee5fbdb84e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.EB.09774.DBF5EED4; Tue, 7 Jun 2011 19:28:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 7 Jun 2011 19:28:29 +0200 From: Christer Holmberg To: Adrian Georgescu Date: Tue, 7 Jun 2011 19:27:04 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlN1PY4pDo0WGvQg+spieWEad+WgAAMqwh Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42C@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com> <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se> <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42A@ESESSCMS0356.eemea.ericsson.se>, <01CBE593-5748-4716-8F5C-3341FF89C616@ag-projects.com> In-Reply-To: <01CBE593-5748-4716-8F5C-3341FF89C616@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:28:32 -0000 Adrian, I was talking about fingerprint authentication, as defined in RFC 4975.=20 But, if you say that nobody is using it, then I guess it may not matter so = much that there are issues with sessmatch. Regards, Christer ________________________________________ From: Adrian Georgescu [ag@ag-projects.com] Sent: Tuesday, June 07, 2011 8:21 PM To: Christer Holmberg Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach > It relies on SDP integrity, as a self-signed certificate hash value is ca= rried in the SDP. > I have deployed SIP for years in many countries with several vendors and I = never say this happening. I have attended many SIPIT events and I do not recall anyone testing such t= hing . Relying on phantom concepts seldom to be found as a fallback mechanisms is = a weak argument. Adrian= From christer.holmberg@ericsson.com Tue Jun 7 10:29:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE521F846B for ; Tue, 7 Jun 2011 10:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peaajEusHYqg for ; Tue, 7 Jun 2011 10:29:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0830121F8460 for ; Tue, 7 Jun 2011 10:29:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-68-4dee600b7fc2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B1.3C.09774.B006EED4; Tue, 7 Jun 2011 19:29:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 7 Jun 2011 19:29:47 +0200 From: Christer Holmberg To: Adrian Georgescu Date: Tue, 7 Jun 2011 19:28:37 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlNO+Z4i1PzL2iSHSUa/Xz0wQaLAAA2ZTH Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42D@ESESSCMS0356.eemea.ericsson.se> References: <14C85D6CCBE92743AF33663BF5D24EBA093DBEBF@gaalpa1msgusr7e.ugd.att.com>, <4E49AE0E-5075-43C8-B907-ACDAB5203396@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A426@ESESSCMS0356.eemea.ericsson.se>, <76A11EC8-CED4-4CFE-BAAA-E3D8431707AC@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A428@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 17:29:49 -0000 Hi, >>> it works OK >> >>I am sure it does, in some places. > >It works on Internet, and this is the point, isn't it? > >IETF is developing Internet standards not something else as far as I know. There is also an agreement between IETF and 3GPP that you might want to loo= k into. But, at the end of the day, IETF will do whatever the WGs and ADs agree to = do. Regards, Christer= From ben@nostrum.com Tue Jun 7 11:16:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D29F11E811F for ; Tue, 7 Jun 2011 11:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRtMRmJyy6G4 for ; Tue, 7 Jun 2011 11:16:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57111E811E for ; Tue, 7 Jun 2011 11:16:53 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p57IGfQC036117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 13:16:44 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> Date: Tue, 7 Jun 2011 13:16:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> To: Umang Singh X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:16:55 -0000 (As individual) On Jun 7, 2011, at 11:25 AM, Umang Singh wrote: > Hi, > Requirements from SBC are defined in an IETF spec = (http://tools.ietf.org/html/rfc5853). Topology hiding and media = anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I = think we should accept the presence and proliferation of SBCs and not = call them an anomaly as it is specified in an IETF specification. >=20 I think that RFC5853 is badly named. It doesn't define requirements in = the sense of protocol or standards requirements. It's more of a = collection of common behaviors of SBCs. Note that it is an informational = RFC, not a standards track one. Or more to the point, nothing in RFC 5853 should be taken to recommend = or condone SBC behavior, other than places where it may suggest = solutions to certain problems that might be more friendly to the SIP = architecture. > The reasons for not mandating a fallback which in turn would mean = adding the MSRP B2BUA functionality in a SBC is that SBC could anchor = media by just functioning as a TCP/IP relay just as it does for RTP = traffic. The difference with MSRP is that MSRP packets contain MSRP URIs = exchanged in signaling and matching of MSRP session to TCP connection is = done on the basis of that. For a node like the SBC, functioning as a = MSRP B2BUA has a huge performance overhead as compared to functioning as = a TCP/IP relay. As the draft in question discusses possibilities of = making MSRP work with such ALGs/SBCs in the path, I think this point is = worthy of discussion. >=20 > Regards, > Umang >=20 > -----Original Message----- > From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]=20 > Sent: Tuesday, June 07, 2011 6:01 PM > To: Umang Singh > Cc: simple@ietf.org > Subject: Re: [Simple] Sessmatch - an alternative approach >=20 > Hi, >=20 > On Jun 7, 2011, at 2:02 PM, Umang Singh wrote: >=20 >> Hi Christer, >> What about the scenario where 2 RFC 4975 compliant UA's try to = establish >> MSRP session on the basis of a=3Dpath with an ALG(more specifically = SBC) >> in the path? As SBC won't modify the a=3Dpath, the UA's can bypass = the SBC >> in the media path. Media anchoring would not work in this case. The >> assumption that a firewall will drop any traffic not directed to the = ALG >> might not be a valid one specially if both the UA's are in the same >> network. >>=20 >> Also, one of the basic functions of the SBC is topology hiding which >> will not be done on the a=3Dpath attribute. >>=20 >=20 > Is there any document/draft/spec where SBC recommended or mandatory = features are listed? >=20 >=20 >> I don't agree with mandating the fallback mechanism either. Apart = from >> performance, another valid reason for not implementing the MSRP B2BUA >> functionality in SBC's is the cost associated with the same. >>=20 >=20 > Cost can't justify breaking an IETF protocol. What is your suggestion, = just not having a fallback mechanism? >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Jun 7 11:28:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9558511E8165 for ; Tue, 7 Jun 2011 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkdiPmq4j6mK for ; Tue, 7 Jun 2011 11:28:43 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 55BE211E816E for ; Tue, 7 Jun 2011 11:28:41 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p57ISbqh037108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 13:28:39 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 13:28:37 -0500 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "simple-chairs@tools.ietf.org Chairs" Subject: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 18:28:43 -0000 (as chair) Hi Everyone, Given the new proposals and spirited discussion related to = draft-ietf-simple-msrp-sessmatch currently happening on the work group = list, the chairs have requested meeting time at the IETF81 meeting in = Quebec City. We've asked for an hour slot, and currently expect this to = be the only significant agenda item. However, please do not defer discussion until the meeting. If we resolve = the issues prior to the meeting, and end up canceling the meeting as a = result, we would count that as a success. Thanks! Ben.= From christer.holmberg@ericsson.com Tue Jun 7 23:28:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4311E809F for ; Tue, 7 Jun 2011 23:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3TRNK5lXUo3 for ; Tue, 7 Jun 2011 23:28:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 20CBA11E807E for ; Tue, 7 Jun 2011 23:28:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-43-4def16a63041 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 72.81.20773.6A61FED4; Wed, 8 Jun 2011 08:28:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 8 Jun 2011 08:28:53 +0200 From: Christer Holmberg To: Ben Campbell , Umang Singh Date: Wed, 8 Jun 2011 08:28:52 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwlPxkadOssQhLKRN23DEBtPZ1IugAZSjpQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E323C94@ESESSCMS0356.eemea.ericsson.se> References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 06:28:56 -0000 Hi,=20 >I think that RFC5853 is badly named. It doesn't define=20 >requirements in the sense of protocol or standards=20 >requirements. It's more of a collection of common behaviors=20 >of SBCs. Note that it is an informational RFC, not a=20 >standards track one. >=20 >Or more to the point, nothing in RFC 5853 should be taken to=20 >recommend or condone SBC behavior, other than places where it=20 >may suggest solutions to certain problems that might be more=20 >friendly to the SIP architecture. I agree with Ben.=20 RFC 5853 was meant to collect functions normally performed by SBCs, which c= ould then be used as background information for future work in IETF. And, eventhough the introduction of the sessmatch draft also gives a few ex= amples of functions performed by SBCs, the focus of the "ALG assumptions" i= s more related to the protocol actions taken in order to anchor media, and = not so much about the reasons why it's done. Regards, Christer= From internet-drafts@ietf.org Thu Jun 9 08:30:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87111E80F9; Thu, 9 Jun 2011 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zobfAN9toMc1; Thu, 9 Jun 2011 08:30:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC311E80DB; Thu, 9 Jun 2011 08:30:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110609153020.24295.69998.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 08:30:20 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-sessmatch-12.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:30:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Alternative Connection Establishment (ACE) for the Messa= ge Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Filename : draft-ietf-simple-msrp-sessmatch-12.txt Pages : 13 Date : 2011-06-09 This document defines an MSRP extension, Alternative Connection Establishment (ACE). Support of the extension is optional. MSRP endpoints can implement the extension in order to allow MSRP communication in networks where SIP Application Layer Gateways (ALGs) anchor the MSRP connection, without the need for the ALGs to enable MSRP B2BUA functionality. The document also defines a Session Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-ace, that can be used by MSRP endpoints to indicate support of the ACE extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-12.txt From christer.holmberg@ericsson.com Thu Jun 9 08:31:48 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1176C11E80EC for ; Thu, 9 Jun 2011 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGhJ2FKZFuCr for ; Thu, 9 Jun 2011 08:31:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5FE11E80F2 for ; Thu, 9 Jun 2011 08:31:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c1-4df0e7606866 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CC.7A.20773.067E0FD4; Thu, 9 Jun 2011 17:31:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 9 Jun 2011 17:31:31 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Thu, 9 Jun 2011 17:31:29 +0200 Thread-Topic: Draft new version: ACE - the extension previously known as sessmatch Thread-Index: Acwmuk2jfFwKLT8IShSpSbUilAkYJA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E36016BESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 15:31:48 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E36016BESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In order for people to easier understand, and get a full picture of the new= alternative sessmatch mechanism, now known as ACE, we have submitted a new= version (-12) of the draft-ietf-simple-msrp-sessmatch (for administrative = reasons the draft name still contains sessmatch), which tries to describe i= t. Happy reading :) Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E36016BESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
In order for people to easier understand, and get a f= ull picture of the new alternative sessmatch mechanism, now known as ACE, w= e have submitted a new version (-12) of the draft-ietf-simple-msrp-sessmatc= h (for administrative reasons the draft name still contains sessmatch), which tries to describe it.
 
Happy reading :)
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E36016BESESSCMS0356e_-- From ibc@aliax.net Thu Jun 9 09:05:19 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E311311E8126 for ; Thu, 9 Jun 2011 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQNquFkIgBB4 for ; Thu, 9 Jun 2011 09:05:19 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 293A811E810D for ; Thu, 9 Jun 2011 09:05:19 -0700 (PDT) Received: by qwc23 with SMTP id 23so1106427qwc.31 for ; Thu, 09 Jun 2011 09:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.17 with SMTP id q17mr662840qca.154.1307635518400; Thu, 09 Jun 2011 09:05:18 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Thu, 9 Jun 2011 09:05:18 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 9 Jun 2011 18:05:18 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:05:20 -0000 2011/6/9 Christer Holmberg : > In order for people to easier understand, and get a full picture of the n= ew > alternative sessmatch mechanism, now known as ACE, we have submitted a ne= w > version (-12) of the draft-ietf-simple-msrp-sessmatch (for administrative > reasons the draft name still contains sessmatch), which tries to describe > it. Hi, honestly I don't like the name ACE. It's too "cool". I don't think this strange specification (involving ALG's and so....) deserves such a cool and short name. I wouldn't like people confusing ICE with ACE, neither I'd like people thinking that "ACE" is a cool new feature (as it's just a specification for making big vendors happy in their wallen gardens). Also, the title of the draft "Alternative Connection Establishment (ACE) for MSRP" says nothing about ALG's. Don't take me wrong, please, but I strongly would prefer some draft name li= ke: "ALG Aware Connection Mechanism for MSRP" This is: - Don't create a new cool abbreviation (as this is not a cool protocol or feature for Internet). - Include the word "ALG" in the title. Regards. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Thu Jun 9 09:35:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF6511E8115 for ; Thu, 9 Jun 2011 09:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 MsVcsz1HbEgY for ; Thu, 9 Jun 2011 09:35:42 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4287811E808F for ; Thu, 9 Jun 2011 09:35:40 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 378A4B01B1; Thu, 9 Jun 2011 18:35:38 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 56D57B017D for ; Thu, 9 Jun 2011 18:35:38 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 9 Jun 2011 18:35:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:35:43 -0000 After having already MSRP Alternative Connection Model, having yet = another MSRP Alternative Connection Establishment is a very confusing = set of terms. An outsider will look at MSRP protocol and two of its alternative = mechanisms, what will he understand of this!? Which alternative of the = alternative shall one use to build an MSRP client? An alternative to = what? =20 Is a ridicule name. On Jun 9, 2011, at 5:31 PM, Christer Holmberg wrote: > =20 > Hi, > =20 > In order for people to easier understand, and get a full picture of = the new alternative sessmatch mechanism, now known as ACE, we have = submitted a new version (-12) of the draft-ietf-simple-msrp-sessmatch = (for administrative reasons the draft name still contains sessmatch), = which tries to describe it. > =20 > Happy reading :) > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From atle.monrad@ericsson.com Fri Jun 10 00:15:09 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E176311E80D7 for ; Fri, 10 Jun 2011 00:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYHBIeMGhclQ for ; Fri, 10 Jun 2011 00:15:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1D11E80D1 for ; Fri, 10 Jun 2011 00:15:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e1-4df1c44c822a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D8.B9.20773.C44C1FD4; Fri, 10 Jun 2011 09:14:20 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.129]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 10 Jun 2011 09:14:18 +0200 From: Atle Monrad To: Ben Campbell , Simple WG Date: Fri, 10 Jun 2011 09:14:16 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwlQL4vMt2GzAQQQ9yLeSbHJ15VOgBVfjWQ Message-ID: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple-chairs@tools.ietf.org Chairs" Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 07:15:09 -0000 Ben / all Christer has actively answered and incorporated comments given to progress = draft-ietf-simple-msrp-sessmatch since the draft became a WG-item, and it w= ould be good to get some clear guideance how to progress and complete the w= ork .=20 This draft is one of the remaining dependencies in 3GPP rel-8, and a conclu= sion from IETF would be appreciated in order for 3GPP to conclude and compl= ete the work.=20 =20 thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Ben Campbell Sent: 7. juni 2011 20:29 To: Simple WG Cc: simple-chairs@tools.ietf.org Chairs Subject: [Simple] SIMPLE meeting at IETF81 (as chair) Hi Everyone, Given the new proposals and spirited discussion related to draft-ietf-simpl= e-msrp-sessmatch currently happening on the work group list, the chairs hav= e requested meeting time at the IETF81 meeting in Quebec City. We've asked = for an hour slot, and currently expect this to be the only significant agen= da item. However, please do not defer discussion until the meeting. If we resolve th= e issues prior to the meeting, and end up canceling the meeting as a result= , we would count that as a success. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From md3135@att.com Fri Jun 10 04:28:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5711E8099 for ; Fri, 10 Jun 2011 04:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.378 X-Spam-Level: X-Spam-Status: No, score=-106.378 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d6XPW446zjN for ; Fri, 10 Jun 2011 04:28:49 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3884711E8083 for ; Fri, 10 Jun 2011 04:28:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1307705328!23439384!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12843 invoked from network); 10 Jun 2011 11:28:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jun 2011 11:28:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5ABRf85000708; Fri, 10 Jun 2011 07:27:41 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5ABRcbB000672; Fri, 10 Jun 2011 07:27:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 10 Jun 2011 07:28:42 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwmvxATt9pXFHFaRH+pyAQnRGbwjwAol4Xw References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> From: "DOLLY, MARTIN C (ATTSI)" To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Christer Holmberg" Cc: simple@ietf.org Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:28:50 -0000 QVQmVCBzdXBwb3J0cyBuYW1lICJBQ0UiLCBhbmQgZmVlbHMgdGhpcyB3b3JrIG5lZWRzIHRvIG1v dmUgZm9yd2FyZCwgbm93Lg0KDQpUaGFuayB5b3UsDQoNCk1hcnRpbiBEb2xseQ0KTGVhZCBNZW1i ZXIgVGVjaG5pY2FsIFN0YWZmDQpDb3JlICYgR292ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJk cw0KQVQmVCBTZXJ2aWNlcywgSW5jLg0KbWQzMTM1QGF0dC5jb20NCisxLTYwOS05MDMtMzM2MA0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpbXBsZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86c2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJw7Fh a2kgQmF6IENhc3RpbGxvDQpTZW50OiBUaHVyc2RheSwgSnVuZSAwOSwgMjAxMSAxMjowNSBQTQ0K VG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogc2ltcGxlQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W1NpbXBsZV0gRHJhZnQgbmV3IHZlcnNpb246IEFDRSAtIHRoZSBleHRlbnNpb24gcHJldmlvdXNs eSBrbm93biBhcyBzZXNzbWF0Y2gNCg0KMjAxMS82LzkgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT46DQo+IEluIG9yZGVyIGZvciBwZW9wbGUgdG8gZWFz aWVyIHVuZGVyc3RhbmQsIGFuZCBnZXQgYSBmdWxsIHBpY3R1cmUgb2YgdGhlIG5ldw0KPiBhbHRl cm5hdGl2ZSBzZXNzbWF0Y2ggbWVjaGFuaXNtLCBub3cga25vd24gYXMgQUNFLCB3ZSBoYXZlIHN1 Ym1pdHRlZCBhIG5ldw0KPiB2ZXJzaW9uICgtMTIpIG9mIHRoZSBkcmFmdC1pZXRmLXNpbXBsZS1t c3JwLXNlc3NtYXRjaCAoZm9yIGFkbWluaXN0cmF0aXZlDQo+IHJlYXNvbnMgdGhlIGRyYWZ0IG5h bWUgc3RpbGwgY29udGFpbnMgc2Vzc21hdGNoKSwgd2hpY2ggdHJpZXMgdG8gZGVzY3JpYmUNCj4g aXQuDQoNCkhpLCBob25lc3RseSBJIGRvbid0IGxpa2UgdGhlIG5hbWUgQUNFLiBJdCdzIHRvbyAi Y29vbCIuIEkgZG9uJ3QgdGhpbmsNCnRoaXMgc3RyYW5nZSBzcGVjaWZpY2F0aW9uIChpbnZvbHZp bmcgQUxHJ3MgYW5kIHNvLi4uLikgZGVzZXJ2ZXMgc3VjaA0KYSBjb29sIGFuZCBzaG9ydCBuYW1l LiBJIHdvdWxkbid0IGxpa2UgcGVvcGxlIGNvbmZ1c2luZyBJQ0Ugd2l0aCBBQ0UsDQpuZWl0aGVy IEknZCBsaWtlIHBlb3BsZSB0aGlua2luZyB0aGF0ICJBQ0UiIGlzIGEgY29vbCBuZXcgZmVhdHVy ZSAoYXMNCml0J3MganVzdCBhIHNwZWNpZmljYXRpb24gZm9yIG1ha2luZyBiaWcgdmVuZG9ycyBo YXBweSBpbiB0aGVpciB3YWxsZW4NCmdhcmRlbnMpLg0KDQpBbHNvLCB0aGUgdGl0bGUgb2YgdGhl IGRyYWZ0ICJBbHRlcm5hdGl2ZSBDb25uZWN0aW9uIEVzdGFibGlzaG1lbnQNCihBQ0UpIGZvciBN U1JQIiBzYXlzIG5vdGhpbmcgYWJvdXQgQUxHJ3MuDQoNCkRvbid0IHRha2UgbWUgd3JvbmcsIHBs ZWFzZSwgYnV0IEkgc3Ryb25nbHkgd291bGQgcHJlZmVyIHNvbWUgZHJhZnQgbmFtZSBsaWtlOg0K DQogICJBTEcgQXdhcmUgQ29ubmVjdGlvbiBNZWNoYW5pc20gZm9yIE1TUlAiDQoNClRoaXMgaXM6 DQotIERvbid0IGNyZWF0ZSBhIG5ldyBjb29sIGFiYnJldmlhdGlvbiAoYXMgdGhpcyBpcyBub3Qg YSBjb29sIHByb3RvY29sDQpvciBmZWF0dXJlIGZvciBJbnRlcm5ldCkuDQotIEluY2x1ZGUgdGhl IHdvcmQgIkFMRyIgaW4gdGhlIHRpdGxlLg0KDQoNClJlZ2FyZHMuDQoNCg0KDQoNCi0tIA0KScOx YWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KU2ltcGxlIG1haWxpbmcgbGlzdA0KU2ltcGxlQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0K From ibc@aliax.net Fri Jun 10 04:41:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D947C11E80B3 for ; Fri, 10 Jun 2011 04:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH1geUCNC62i for ; Fri, 10 Jun 2011 04:41:00 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 813EA11E807E for ; Fri, 10 Jun 2011 04:41:00 -0700 (PDT) Received: by qyk29 with SMTP id 29so1459523qyk.10 for ; Fri, 10 Jun 2011 04:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.151 with SMTP id n23mr1400495qci.268.1307705871717; Fri, 10 Jun 2011 04:37:51 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 04:37:51 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com> Date: Fri, 10 Jun 2011 13:37:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:41:02 -0000 2011/6/10 DOLLY, MARTIN C (ATTSI) : > AT&T supports name "ACE", and feels this work needs to move forward, now. Dolly, could you please reply to the arguments Adrian and me have exposed against "ACE" name? just ignoring them doesn't seem very polite. --=20 I=C3=B1aki Baz Castillo From md3135@att.com Fri Jun 10 04:42:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EEE11E807E for ; Fri, 10 Jun 2011 04:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9+TLHZKU9EA for ; Fri, 10 Jun 2011 04:42:12 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2180C11E80B3 for ; Fri, 10 Jun 2011 04:42:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1307706131!23472802!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24331 invoked from network); 10 Jun 2011 11:42:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jun 2011 11:42:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5ABf47I011416; Fri, 10 Jun 2011 07:41:04 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5ABex6D011368; Fri, 10 Jun 2011 07:41:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 10 Jun 2011 07:42:05 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnY0wVYml5Lh2bQf6O8+43NFDmygAABY4Q References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se><14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com> From: "DOLLY, MARTIN C (ATTSI)" To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Cc: simple@ietf.org Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:42:15 -0000 SXQgaXMgYSBuYW1lLCBwbGVhc2UgZ2V0IG92ZXIgaXQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0g DQpTZW50OiBGcmlkYXksIEp1bmUgMTAsIDIwMTEgNzozOCBBTQ0KVG86IERPTExZLCBNQVJUSU4g QyAoQVRUU0kpDQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7IHNpbXBsZUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtTaW1wbGVdIERyYWZ0IG5ldyB2ZXJzaW9uOiBBQ0UgLSB0aGUgZXh0ZW5zaW9uIHBy ZXZpb3VzbHkga25vd24gYXMgc2Vzc21hdGNoDQoNCjIwMTEvNi8xMCBET0xMWSwgTUFSVElOIEMg KEFUVFNJKSA8bWQzMTM1QGF0dC5jb20+Og0KPiBBVCZUIHN1cHBvcnRzIG5hbWUgIkFDRSIsIGFu ZCBmZWVscyB0aGlzIHdvcmsgbmVlZHMgdG8gbW92ZSBmb3J3YXJkLCBub3cuDQoNCkRvbGx5LCBj b3VsZCB5b3UgcGxlYXNlIHJlcGx5IHRvIHRoZSBhcmd1bWVudHMgQWRyaWFuIGFuZCBtZSBoYXZl DQpleHBvc2VkIGFnYWluc3QgIkFDRSIgbmFtZT8ganVzdCBpZ25vcmluZyB0aGVtIGRvZXNuJ3Qg c2VlbSB2ZXJ5DQpwb2xpdGUuDQoNCi0tIA0KScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlh eC5uZXQ+DQo= From ag@ag-projects.com Fri Jun 10 04:57:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5F11E8072 for ; Fri, 10 Jun 2011 04:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 bjWUplRCtEgb for ; Fri, 10 Jun 2011 04:57:54 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 943A311E8071 for ; Fri, 10 Jun 2011 04:57:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 0D84CB01BF; Fri, 10 Jun 2011 13:57:52 +0200 (CEST) Received: from [192.168.1.122] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 5D4FEB00E6; Fri, 10 Jun 2011 13:57:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> Date: Fri, 10 Jun 2011 13:57:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se><14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:57:58 -0000 This name creates the ultimate confusion of having 3 ways to using MSRP = protocol with the last one incompatible with the previous ones. This draft is addressing OMA/ALG style deployments only where only = pieces of MSRP protocol are being used and not the usage of MSRP = protocol over the open Internet. The title of this draft should reflect this simple fact. Adrian On Jun 10, 2011, at 1:42 PM, DOLLY, MARTIN C (ATTSI) wrote: > It is a name, please get over it. >=20 > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 > Sent: Friday, June 10, 2011 7:38 AM > To: DOLLY, MARTIN C (ATTSI) > Cc: Christer Holmberg; simple@ietf.org > Subject: Re: [Simple] Draft new version: ACE - the extension = previously known as sessmatch >=20 > 2011/6/10 DOLLY, MARTIN C (ATTSI) : >> AT&T supports name "ACE", and feels this work needs to move forward, = now. >=20 > Dolly, could you please reply to the arguments Adrian and me have > exposed against "ACE" name? just ignoring them doesn't seem very > polite. >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Fri Jun 10 04:59:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3360611E8072 for ; Fri, 10 Jun 2011 04:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCghH9hHD9TF for ; Fri, 10 Jun 2011 04:59:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEF911E80B1 for ; Fri, 10 Jun 2011 04:59:34 -0700 (PDT) Received: by qwc23 with SMTP id 23so1615529qwc.31 for ; Fri, 10 Jun 2011 04:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.218 with SMTP id s26mr1622481qci.40.1307707174022; Fri, 10 Jun 2011 04:59:34 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 04:59:33 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> Date: Fri, 10 Jun 2011 13:59:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:59:35 -0000 2011/6/10 DOLLY, MARTIN C (ATTSI) : > It is a name, please get over it. So you want promote the existence of two specifications with these names: 1) MSRP Alternative Connection Model 2) MSRP Alternative Connection Establishment I think they are confusing enough, do you? PS: This is not Twitter, you are able to write mails longer than 1-2 lines. Take your time please, as the rest of people here. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Fri Jun 10 05:07:13 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6576911E80AB for ; Fri, 10 Jun 2011 05:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 AhmqMcEgxuXW for ; Fri, 10 Jun 2011 05:07:12 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 112E111E80A2 for ; Fri, 10 Jun 2011 05:07:12 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4F13AB01B8; Fri, 10 Jun 2011 14:07:10 +0200 (CEST) Received: from [192.168.1.122] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 63588B00E6; Fri, 10 Jun 2011 14:07:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> Date: Fri, 10 Jun 2011 14:07:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> To: Atle Monrad X-Mailer: Apple Mail (2.1084) Cc: "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:07:13 -0000 Hello Atle, As this draft is not required for MSRP protocol on Internet but = addresses strictly the needs of 3GPP rel-8 it should explicitly state = this simple fact in its title and description.=20 Adrian On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote: > Ben / all >=20 > Christer has actively answered and incorporated comments given to = progress draft-ietf-simple-msrp-sessmatch since the draft became a = WG-item, and it would be good to get some clear guideance how to = progress and complete the work .=20 >=20 > This draft is one of the remaining dependencies in 3GPP rel-8, and a = conclusion from IETF would be appreciated in order for 3GPP to conclude = and complete the work.=20 >=20 > thanks > /atle >=20 > ________________________________=20 >=20 >=20 > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management=20 > Ericsson >=20 >=20 >=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Ben Campbell > Sent: 7. juni 2011 20:29 > To: Simple WG > Cc: simple-chairs@tools.ietf.org Chairs > Subject: [Simple] SIMPLE meeting at IETF81 >=20 > (as chair) >=20 > Hi Everyone, >=20 > Given the new proposals and spirited discussion related to = draft-ietf-simple-msrp-sessmatch currently happening on the work group = list, the chairs have requested meeting time at the IETF81 meeting in = Quebec City. We've asked for an hour slot, and currently expect this to = be the only significant agenda item. >=20 > However, please do not defer discussion until the meeting. If we = resolve the issues prior to the meeting, and end up canceling the = meeting as a result, we would count that as a success. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From saul@ag-projects.com Fri Jun 10 05:18:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE221F84C3 for ; Fri, 10 Jun 2011 05:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQnVrg13FWrP for ; Fri, 10 Jun 2011 05:18:26 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8905D21F847C for ; Fri, 10 Jun 2011 05:18:26 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9AE55B01B8; Fri, 10 Jun 2011 14:18:25 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1893FB017C; Fri, 10 Jun 2011 14:18:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 14:18:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:18:27 -0000 Hi, On Jun 9, 2011, at 5:31 PM, Christer Holmberg wrote: > =20 > Hi, > =20 > In order for people to easier understand, and get a full picture of = the new alternative sessmatch mechanism, now known as ACE, we have = submitted a new version (-12) of the draft-ietf-simple-msrp-sessmatch = (for administrative reasons the draft name still contains sessmatch), = which tries to describe it. > =20 > Happy reading :) > =20 I didn't have the time to go through all of it, but since the title = doesn't seem to be appropriate for everyone I'll throw my 2 cents. ACE feels too generic, like ACM, which could be confusing. Also, ACE = requires ACM so an alternative needs an alternative, which sounds a bit = weird. I'd suggest something along these lines: "MSRP media anchoring mechanism = for ALGs". Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Fri Jun 10 05:27:37 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AFE11E80A5 for ; Fri, 10 Jun 2011 05:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-NBNZHTdLrM for ; Fri, 10 Jun 2011 05:27:37 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83911E807C for ; Fri, 10 Jun 2011 05:27:37 -0700 (PDT) Received: by qyk29 with SMTP id 29so1491495qyk.10 for ; Fri, 10 Jun 2011 05:27:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.119.151 with SMTP id z23mr1615595qcq.2.1307708856607; Fri, 10 Jun 2011 05:27:36 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 05:27:36 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 14:27:36 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:27:38 -0000 2011/6/10 Sa=C3=BAl Ibarra Corretg=C3=A9 : > "MSRP media anchoring mechanism for ALGs" Great name: descriptive and focused to its real scenario. Please Christer, consider it ;) --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Fri Jun 10 05:34:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4C11E80DC for ; Fri, 10 Jun 2011 05:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJFiFIOmMza1 for ; Fri, 10 Jun 2011 05:34:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3A811E80C4 for ; Fri, 10 Jun 2011 05:34:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-76-4df20f4ca720 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.DC.20773.C4F02FD4; Fri, 10 Jun 2011 14:34:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 10 Jun 2011 14:34:18 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Fri, 10 Jun 2011 14:34:18 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnaIBpVr4Msuv2SkGU+EPOvmWKggAAB5xg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:34:22 -0000 Hi,=20 >I didn't have the time to go through all of it, but since the=20 >title doesn't seem to be appropriate for everyone I'll throw=20 >my 2 cents. >=20 >ACE feels too generic, like ACM, which could be confusing.=20 >Also, ACE requires ACM so an alternative needs an=20 >alternative, which sounds a bit weird. Actually, ACE as such does not require ACM. However, as is described in the= draft, ACM further adds cases where it will be possible to use ACE, withou= t the ALG having to enable MSRP B2BUA functionlaity. Personally I don't see why it would be strange for one extension to require= support of another (there are many other examples of that).=20 But, if people have problems to mandate support of ACM, I have no problem t= o change it to "SHOULD" or "STRONGLY RECOMMENDED". But, considering the advantages that ACM brings, I would like to get some j= ustification for such change. >I'd suggest something along these lines: "MSRP media anchoring mechanism f= or ALGs". I am not religious regarding the name.=20 I just think it's weird to base arguments on a "coolness" comparison betwee= n a draft name and a draft content... Regards, Christer From christer.holmberg@ericsson.com Fri Jun 10 05:35:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C6D11E80FF for ; Fri, 10 Jun 2011 05:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mf74mS8Ww0Y for ; Fri, 10 Jun 2011 05:35:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CF57F11E80C4 for ; Fri, 10 Jun 2011 05:35:52 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c8-4df20fa7991d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.9D.20773.7AF02FD4; Fri, 10 Jun 2011 14:35:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 10 Jun 2011 14:35:49 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Fri, 10 Jun 2011 14:35:49 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnachytbdGR8BfS3Sg2VNhkryHxgAAQ1gA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E360631@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:35:53 -0000 Hi,=20 >>"MSRP media anchoring mechanism for ALGs" >=20 >Great name: descriptive and focused to its real scenario. >=20 >Please Christer, consider it ;) I am considering any proposal which helps bringing the work forward :) Regards, Christer From ibc@aliax.net Fri Jun 10 05:37:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4604811E80DC for ; Fri, 10 Jun 2011 05:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvL0fP9MW3e0 for ; Fri, 10 Jun 2011 05:37:40 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9337611E807C for ; Fri, 10 Jun 2011 05:37:40 -0700 (PDT) Received: by qyk7 with SMTP id 7so1548334qyk.10 for ; Fri, 10 Jun 2011 05:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.71.77 with SMTP id g13mr1635966qcj.116.1307709459684; Fri, 10 Jun 2011 05:37:39 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 05:37:39 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 14:37:39 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:37:41 -0000 2011/6/10 Christer Holmberg : > I just think it's weird to base arguments on a "coolness" comparison betw= een a draft name and a draft content... The draft title must represent the draft content. If the content clearly talks about scenarios with ALG's, and such devices are out of the scope of "pure" internet, I strongly think that the draft title should notice it. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Fri Jun 10 05:38:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B311E80B1 for ; Fri, 10 Jun 2011 05:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fplb1AWDxg1 for ; Fri, 10 Jun 2011 05:38:43 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6CA11E807C for ; Fri, 10 Jun 2011 05:38:42 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B17AEB01B8; Fri, 10 Jun 2011 14:38:41 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1BAFCB017C; Fri, 10 Jun 2011 14:38:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 14:38:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F0A9A93-53ED-430B-8694-4E5BB70B9FA2@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:38:44 -0000 Hi, > Actually, ACE as such does not require ACM. However, as is described = in the draft, ACM further adds cases where it will be possible to use = ACE, without the ALG having to enable MSRP B2BUA functionlaity. >=20 > Personally I don't see why it would be strange for one extension to = require support of another (there are many other examples of that).=20 >=20 The reason I said that is because both begin with "Alternate Connection" = not because of the fact that both are extensions. I actually think that = this new spec should mandate ACM. > But, if people have problems to mandate support of ACM, I have no = problem to change it to "SHOULD" or "STRONGLY RECOMMENDED". >=20 > But, considering the advantages that ACM brings, I would like to get = some justification for such change. >=20 >> I'd suggest something along these lines: "MSRP media anchoring = mechanism for ALGs". >=20 > I am not religious regarding the name.=20 >=20 > I just think it's weird to base arguments on a "coolness" comparison = between a draft name and a draft content... >=20 My argument base if not coolness, is the fact that it could be confusing = for newcomer implementors. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From christian.1.schmidt@nsn.com Fri Jun 10 05:42:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E4611E80FF for ; Fri, 10 Jun 2011 05:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uutjm+h5TJEd for ; Fri, 10 Jun 2011 05:42:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 70A9011E80DC for ; Fri, 10 Jun 2011 05:42:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5ACgBwX022384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2011 14:42:11 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5ACg3Am017781; Fri, 10 Jun 2011 14:42:11 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 14:42:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 10 Jun 2011 14:42:09 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-index: AcwnZeH5IWkmRDBPS3qmL9de81dbVQAASSjA References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se><14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com><14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: =?UTF-8?B?ZXh0IEnDsWFraSBCYXogQ2FzdGlsbG8=?= , "DOLLY, MARTIN C (ATTSI)" , "ext Christer Holmberg" X-OriginalArrivalTime: 10 Jun 2011 12:42:10.0915 (UTC) FILETIME=[D10C9B30:01CC276B] Cc: simple@ietf.org Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:42:18 -0000 VG8gYmUgaG9uZXN0LCBJIGRvIG5vdCByZWFsbHkgY2FyZSBhYm91dCB0aGUgbmFtZSBvZiB0aGlz IHNwZWNpZmljYXRpb24uDQpJZiB5b3Ugd2FudCB0byBjYWxsIGl0IEFDTSwgeW91IGNhbiBhbmQg c2hvdWxkIGV4cGxhaW4gdGhlIHJlbGF0aW9uc2hpcCwgZS5nLiB0byB0aGUgTVNSUCBBbHRlcm5h dGl2ZSBDb25uZWN0aW9uIE1vZGVsIGluIHRoZSBhYnN0cmFjdCBvZiB0aGUgc3BlY2lmaWNhdGlv bi4NCg0KV2hhdCBzZWVtcyB0byBiZSBtb3JlIGltcG9ydGFudCBpcyB0aGUgZm9sbG93aW5nIHF1 ZXN0aW9uOg0KDQpMZXRzIGFzc3VtZSB0aGUgZm9sbG93aW5nIG1vZGVsOg0KTVNSUCBlbmRwb2lu dCBBIC0+IGNvbWJpbmF0aW9uIG9mIE5BVHMsIE1TUlAtUHJveGllcywgQUxHcyAtPiBNU1JQIGVu ZHBvaW50IEIuDQoNCklzIHRoZXJlIGFueSBjb21iaW5hdGlvbiBvZiBOQVRzLCBNU1JQLVByb3hp ZXMgYW5kIEFMR3Mgd2hlcmUgDQotIGEgTVNSUCBjb25uZWN0aW9uIGlzIHN1Y2Nlc3NmdWwgKHdp dGggYm90aCBNUlNQIGVuZHBvaW50cyBhY3RpbmcgYWNjb3JkaW5nIFJGQzQ5NzUpDQotIGEgTVNS UCBjb25uZWN0aW9uIGlzIG5vdCBzdWNjZXNzZnVsIGR1ZSB0byB0aGUgZmFjdCwgdGhhdCBvbmUg b3IgYm90aCBNUlNQIGVuZHBvaW50cyBhY3RzIGFjY29yZGluZyB0aGlzIEFDRSBzcGVjaWZpY2F0 aW9uPw0KDQpSZWdhcmRzDQpDaHJpc3RpYW4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpbXBsZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 c2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgScOxYWtpIEJheiBDYXN0 aWxsbw0KU2VudDogRnJpZGF5LCBKdW5lIDEwLCAyMDExIDI6MDAgUE0NClRvOiBET0xMWSwgTUFS VElOIEMgKEFUVFNJKQ0KQ2M6IHNpbXBsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTaW1wbGVd IERyYWZ0IG5ldyB2ZXJzaW9uOiBBQ0UgLSB0aGUgZXh0ZW5zaW9uIHByZXZpb3VzbHkga25vd24g YXMgc2Vzc21hdGNoDQoNCjIwMTEvNi8xMCBET0xMWSwgTUFSVElOIEMgKEFUVFNJKSA8bWQzMTM1 QGF0dC5jb20+Og0KPiBJdCBpcyBhIG5hbWUsIHBsZWFzZSBnZXQgb3ZlciBpdC4NCg0KU28geW91 IHdhbnQgcHJvbW90ZSB0aGUgZXhpc3RlbmNlIG9mIHR3byBzcGVjaWZpY2F0aW9ucyB3aXRoIHRo ZXNlIG5hbWVzOg0KDQogIDEpIE1TUlAgQWx0ZXJuYXRpdmUgQ29ubmVjdGlvbiBNb2RlbA0KICAy KSBNU1JQIEFsdGVybmF0aXZlIENvbm5lY3Rpb24gRXN0YWJsaXNobWVudA0KDQpJIHRoaW5rIHRo ZXkgYXJlIGNvbmZ1c2luZyBlbm91Z2gsIGRvIHlvdT8NCg0KUFM6IFRoaXMgaXMgbm90IFR3aXR0 ZXIsIHlvdSBhcmUgYWJsZSB0byB3cml0ZSBtYWlscyBsb25nZXIgdGhhbiAxLTINCmxpbmVzLiBU YWtlIHlvdXIgdGltZSBwbGVhc2UsIGFzIHRoZSByZXN0IG9mIHBlb3BsZSBoZXJlLg0KDQoNCi0t IA0KScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2ltcGxlIG1haWxpbmcgbGlzdA0KU2lt cGxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBs ZQ0K From christer.holmberg@ericsson.com Fri Jun 10 05:43:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481C111E8102 for ; Fri, 10 Jun 2011 05:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPodQqN0lM6y for ; Fri, 10 Jun 2011 05:43:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2972611E80B1 for ; Fri, 10 Jun 2011 05:43:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-04-4df21166a80f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D8.E5.09774.66112FD4; Fri, 10 Jun 2011 14:43:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 10 Jun 2011 14:43:17 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Fri, 10 Jun 2011 14:43:16 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: Acwna1TMk/s/R4rFTbaUQ0u5l0SO4AAAGZ5A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E360646@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> <0F0A9A93-53ED-430B-8694-4E5BB70B9FA2@ag-projects.com> In-Reply-To: <0F0A9A93-53ED-430B-8694-4E5BB70B9FA2@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:43:20 -0000 Hi,=20 >> Actually, ACE as such does not require ACM. However, as is=20 >> described in the draft, ACM further adds cases where it will=20 >> be possible to use ACE, without the ALG having to enable MSRP=20 >> B2BUA functionlaity. >>=20 >> Personally I don't see why it would be strange for one=20 >> extension to require support of another (there are many other=20 >> examples of that).=20 >>=20 >=20 >The reason I said that is because both begin with "Alternate=20 >Connection" not because of the fact that both are extensions.=20 >I actually think that this new spec should mandate ACM. Ok. >> But, if people have problems to mandate support of ACM, I=20 >> have no problem to change it to "SHOULD" or "STRONGLY RECOMMENDED". >>=20 >> But, considering the advantages that ACM brings, I would=20 >> like to get some justification for such change. >>=20 >> I'd suggest something along these lines: "MSRP media=20 >> anchoring mechanism for ALGs". >>=20 >> I am not religious regarding the name.=20 >>=20 >> I just think it's weird to base arguments on a "coolness"=20 >> comparison between a draft name and a draft content... >> =20 >My argument base if not coolness, is the fact that it could=20 >be confusing for newcomer implementors. My comment was not against you. Sorry for the confusion. Regards, Christer From ag@ag-projects.com Fri Jun 10 05:44:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4162211E80B1 for ; Fri, 10 Jun 2011 05:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRoKa9TiKvrf for ; Fri, 10 Jun 2011 05:44:05 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5A11711E807C for ; Fri, 10 Jun 2011 05:44:05 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B98FFB01B8; Fri, 10 Jun 2011 14:44:04 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 8530FB017C; Fri, 10 Jun 2011 14:43:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Adrian Georgescu In-Reply-To: Date: Fri, 10 Jun 2011 14:43:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:44:06 -0000 The title of the document must describe its function so people who = deploy on the Internet do not need to look at it. This short title can = for example explain what it does and why: "MSRP media anchoring for 3GPP deployments" Adrian On Jun 10, 2011, at 2:37 PM, I=C3=B1aki Baz Castillo wrote: > 2011/6/10 Christer Holmberg : >> I just think it's weird to base arguments on a "coolness" comparison = between a draft name and a draft content... >=20 > The draft title must represent the draft content. If the content > clearly talks about scenarios with ALG's, and such devices are out of > the scope of "pure" internet, I strongly think that the draft title > should notice it. >=20 >=20 >=20 > --=20 > I=C3=B1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Fri Jun 10 05:44:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949C21F8470 for ; Fri, 10 Jun 2011 05:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvXWG4wp0WhD for ; Fri, 10 Jun 2011 05:44:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF321F846D for ; Fri, 10 Jun 2011 05:44:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c9-4df211c59b82 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E1.21.20773.5C112FD4; Fri, 10 Jun 2011 14:44:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 10 Jun 2011 14:44:53 +0200 From: Christer Holmberg To: "Schmidt, Christian 1. (NSN - DE/Munich)" , =?iso-8859-1?Q?ext_I=F1aki_Baz_Castillo?= , "DOLLY, MARTIN C (ATTSI)" Date: Fri, 10 Jun 2011 14:44:52 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnZeH5IWkmRDBPS3qmL9de81dbVQAASSjAAAFEXTA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E360649@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se><14C85D6CCBE92743AF33663BF5D24EBA0A4A2FE8@gaalpa1msgusr7e.ugd.att.com><14C85D6CCBE92743AF33663BF5D24EBA0A4A2FF8@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:44:55 -0000 Hi Christian, Before I try to address your question, could you clarify what you mean by M= SRP-Proxy. Do you mean MSRP relay?=20 Regards, Christer > -----Original Message----- > From: Schmidt, Christian 1. (NSN - DE/Munich)=20 > [mailto:christian.1.schmidt@nsn.com]=20 > Sent: 10. kes=E4kuuta 2011 15:42 > To: ext I=F1aki Baz Castillo; DOLLY, MARTIN C (ATTSI); Christer Holmberg > Cc: simple@ietf.org > Subject: RE: [Simple] Draft new version: ACE - the extension=20 > previously known as sessmatch >=20 > To be honest, I do not really care about the name of this=20 > specification. > If you want to call it ACM, you can and should explain the=20 > relationship, e.g. to the MSRP Alternative Connection Model=20 > in the abstract of the specification. >=20 > What seems to be more important is the following question: >=20 > Lets assume the following model: > MSRP endpoint A -> combination of NATs, MSRP-Proxies, ALGs ->=20 > MSRP endpoint B. >=20 > Is there any combination of NATs, MSRP-Proxies and ALGs where > - a MSRP connection is successful (with both MRSP endpoints=20 > acting according RFC4975) > - a MSRP connection is not successful due to the fact, that=20 > one or both MRSP endpoints acts according this ACE specification? >=20 > Regards > Christian >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of ext I=F1aki Baz Castillo > Sent: Friday, June 10, 2011 2:00 PM > To: DOLLY, MARTIN C (ATTSI) > Cc: simple@ietf.org > Subject: Re: [Simple] Draft new version: ACE - the extension=20 > previously known as sessmatch >=20 > 2011/6/10 DOLLY, MARTIN C (ATTSI) : > > It is a name, please get over it. >=20 > So you want promote the existence of two specifications with=20 > these names: >=20 > 1) MSRP Alternative Connection Model > 2) MSRP Alternative Connection Establishment >=20 > I think they are confusing enough, do you? >=20 > PS: This is not Twitter, you are able to write mails longer=20 > than 1-2 lines. Take your time please, as the rest of people here. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From atle.monrad@ericsson.com Fri Jun 10 05:56:03 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14511E807C for ; Fri, 10 Jun 2011 05:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJiLewB8hk-A for ; Fri, 10 Jun 2011 05:56:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7811E8077 for ; Fri, 10 Jun 2011 05:56:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d8-4df21461282f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.76.20773.16412FD4; Fri, 10 Jun 2011 14:56:01 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.129]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 10 Jun 2011 14:56:00 +0200 From: Atle Monrad To: Adrian Georgescu Date: Fri, 10 Jun 2011 14:55:59 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwnZvAH2/3CC48aRFibYyJQgsvL3gAAgyfg Message-ID: <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:56:03 -0000 Adrian as I am not an expert on the formalities on how the extentions under the re= sponsibility of SIMPLE are handled and documented, this has to be left to o= thers to comment and decide on. However, a point that I'd like to raise, is that 3GPP would like to get our= requirements included into the RFCs as normative requirements that can be = expressed as mandatory or optional statements.=20 When requirements described in drafts become WG-items it seems natural to m= e that such options are seen as general options. Why these options have to = be phrased explicitly as options strictly for 3GPP isn't actually what I ha= d expected. WRT the title - if this turns out to be the main blocking point, I'm sure t= hat this can be modified, as long as this doesn't restart and alter the tec= hnical discussions already held and concluded. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 Sent: 10. juni 2011 14:07 To: Atle Monrad Cc: Ben Campbell; Simple WG; simple-chairs@tools.ietf.org Chairs Subject: Re: [Simple] SIMPLE meeting at IETF81 Hello Atle, As this draft is not required for MSRP protocol on Internet but addresses s= trictly the needs of 3GPP rel-8 it should explicitly state this simple fact= in its title and description.=20 Adrian On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote: > Ben / all >=20 > Christer has actively answered and incorporated comments given to progres= s draft-ietf-simple-msrp-sessmatch since the draft became a WG-item, and it= would be good to get some clear guideance how to progress and complete the= work .=20 >=20 > This draft is one of the remaining dependencies in 3GPP rel-8, and a conc= lusion from IETF would be appreciated in order for 3GPP to conclude and com= plete the work.=20 >=20 > thanks > /atle >=20 > ________________________________ >=20 >=20 > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management Ericsson >=20 >=20 >=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Ben Campbell > Sent: 7. juni 2011 20:29 > To: Simple WG > Cc: simple-chairs@tools.ietf.org Chairs > Subject: [Simple] SIMPLE meeting at IETF81 >=20 > (as chair) >=20 > Hi Everyone, >=20 > Given the new proposals and spirited discussion related to draft-ietf-sim= ple-msrp-sessmatch currently happening on the work group list, the chairs h= ave requested meeting time at the IETF81 meeting in Quebec City. We've aske= d for an hour slot, and currently expect this to be the only significant ag= enda item. >=20 > However, please do not defer discussion until the meeting. If we resolve = the issues prior to the meeting, and end up canceling the meeting as a resu= lt, we would count that as a success. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From R.Jesske@telekom.de Fri Jun 10 05:57:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD4911E807C for ; Fri, 10 Jun 2011 05:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFc2HPntN+RR for ; Fri, 10 Jun 2011 05:57:43 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 1A74F11E8077 for ; Fri, 10 Jun 2011 05:57:42 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jun 2011 14:57:38 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 10 Jun 2011 14:57:38 +0200 From: To: , , Date: Fri, 10 Jun 2011 14:57:36 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwnZwGz6fN8AmzBR8qIH6UB+nXskQAAwYJw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BECA@HE111648.emea1.cds.t-internal.com> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: simple-chairs@tools.ietf.org, simple@ietf.org Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 12:57:44 -0000 Hello Adrian, I'm wondering that we are discussing now about this fact that 3GPP does nee= d this mechanism and should now state this in the title. Such mechanism could also be used within other networks like an TISPAN NGN = should we name that too? (We are using TISPAN NGN and would need such mecha= nism too) Nevertheless Christer put the 3GPP use case into the introduction of his do= cument. 1. Introduction The Message Session Relay Protocol (MSRP) [RFC4975] is designed to use MSRP relays [RFC4976] as a means for Network Address Translation (NAT) traversal and policy enforcement. However, many Session Initiation Protocol (SIP) [RFC3261] networks, in which MSRP usage is emerging, also contain SIP Application Layer Gateways (ALGs), that anchor and controls media, perform tasks such as NAT traversal, performance monitoring, lawful intercept, address domain bridging, interconnect Service Layer Agreement (SLA) policy enforcement, etc. An example is the Interconnection Border Control Function (IBCF) [3GPP.23.228], defined by the 3rd Generation Partnership Project (3GPP). The IBCF controls a media relay that handles all types of SIP session media (voice, video, MSRP, etc). It was asked for guidance on this issue. I would prefer to start the real d= iscussion instead of discussing the name of the draft. As long as it is an = agreed work item. At least I don't care about the name but it must be a cool one, or is this = really restricted only for internet ;-). I fully support his work. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > Im Auftrag von Adrian Georgescu > Gesendet: Freitag, 10. Juni 2011 14:07 > An: Atle Monrad > Cc: simple-chairs@tools.ietf.org Chairs; Simple WG > Betreff: Re: [Simple] SIMPLE meeting at IETF81 > > Hello Atle, > > As this draft is not required for MSRP protocol on Internet > but addresses strictly the needs of 3GPP rel-8 it should > explicitly state this simple fact in its title and description. > > Adrian > > On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote: > > > Ben / all > > > > Christer has actively answered and incorporated comments > given to progress draft-ietf-simple-msrp-sessmatch since the > draft became a WG-item, and it would be good to get some > clear guideance how to progress and complete the work . > > > > This draft is one of the remaining dependencies in 3GPP > rel-8, and a conclusion from IETF would be appreciated in > order for 3GPP to conclude and complete the work. > > > > thanks > > /atle > > > > ________________________________ > > > > > > Atle Monrad > > 3GPP CT Chairman > > Standardization and Regulation, > > Group Function Technology and Portfolio Management > > Ericsson > > > > > > > > > > -----Original Message----- > > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell > > Sent: 7. juni 2011 20:29 > > To: Simple WG > > Cc: simple-chairs@tools.ietf.org Chairs > > Subject: [Simple] SIMPLE meeting at IETF81 > > > > (as chair) > > > > Hi Everyone, > > > > Given the new proposals and spirited discussion related to > draft-ietf-simple-msrp-sessmatch currently happening on the > work group list, the chairs have requested meeting time at > the IETF81 meeting in Quebec City. We've asked for an hour > slot, and currently expect this to be the only significant > agenda item. > > > > However, please do not defer discussion until the meeting. > If we resolve the issues prior to the meeting, and end up > canceling the meeting as a result, we would count that as a success. > > > > Thanks! > > > > Ben. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ag@ag-projects.com Fri Jun 10 06:05:10 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E813311E8134 for ; Fri, 10 Jun 2011 06:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 ifScXXGE-2Pr for ; Fri, 10 Jun 2011 06:05:10 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id ADD6D11E8130 for ; Fri, 10 Jun 2011 06:05:09 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1B722B01BA; Fri, 10 Jun 2011 15:05:09 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id D2AB6B017C; Fri, 10 Jun 2011 15:04:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-2 From: Adrian Georgescu In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BECA@HE111648.emea1.cds.t-internal.com> Date: Fri, 10 Jun 2011 15:04:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BECA@HE111648.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1084) Cc: simple-chairs@tools.ietf.org, simple@ietf.org Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:05:11 -0000 OK 3GPP, Tispan NGN are all closed networks with explicit gateways to = the Internet. So: "MSRP media anchoring for closed IP networks" Would this be capturing all non-Internet style deployments? Adrian On Jun 10, 2011, at 2:57 PM, wrote: > Hello Adrian, > I'm wondering that we are discussing now about this fact that 3GPP = does need this mechanism and should now state this in the title. >=20 > Such mechanism could also be used within other networks like an TISPAN = NGN should we name that too? (We are using TISPAN NGN and would need = such mechanism too) > Nevertheless Christer put the 3GPP use case into the introduction of = his document. >=20 > 1. Introduction >=20 > The Message Session Relay Protocol (MSRP) [RFC4975] is designed to > use MSRP relays [RFC4976] as a means for Network Address Translation > (NAT) traversal and policy enforcement. >=20 > However, many Session Initiation Protocol (SIP) [RFC3261] networks, > in which MSRP usage is emerging, also contain SIP Application Layer > Gateways (ALGs), that anchor and controls media, perform tasks such > as NAT traversal, performance monitoring, lawful intercept, address > domain bridging, interconnect Service Layer Agreement (SLA) policy > enforcement, etc. An example is the Interconnection Border Control > Function (IBCF) [3GPP.23.228], defined by the 3rd Generation > Partnership Project (3GPP). The IBCF controls a media relay that > handles all types of SIP session media (voice, video, MSRP, etc). >=20 > It was asked for guidance on this issue. I would prefer to start the = real discussion instead of discussing the name of the draft. As long as = it is an agreed work item. >=20 > At least I don't care about the name but it must be a cool one, or is = this really restricted only for internet ;-). >=20 > I fully support his work. >=20 >=20 > Best Regards > Roland >=20 >=20 >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] >> Im Auftrag von Adrian Georgescu >> Gesendet: Freitag, 10. Juni 2011 14:07 >> An: Atle Monrad >> Cc: simple-chairs@tools.ietf.org Chairs; Simple WG >> Betreff: Re: [Simple] SIMPLE meeting at IETF81 >>=20 >> Hello Atle, >>=20 >> As this draft is not required for MSRP protocol on Internet >> but addresses strictly the needs of 3GPP rel-8 it should >> explicitly state this simple fact in its title and description. >>=20 >> Adrian >>=20 >> On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote: >>=20 >>> Ben / all >>>=20 >>> Christer has actively answered and incorporated comments >> given to progress draft-ietf-simple-msrp-sessmatch since the >> draft became a WG-item, and it would be good to get some >> clear guideance how to progress and complete the work . >>>=20 >>> This draft is one of the remaining dependencies in 3GPP >> rel-8, and a conclusion from IETF would be appreciated in >> order for 3GPP to conclude and complete the work. >>>=20 >>> thanks >>> /atle >>>=20 >>> ________________________________ >>>=20 >>>=20 >>> Atle Monrad >>> 3GPP CT Chairman >>> Standardization and Regulation, >>> Group Function Technology and Portfolio Management >>> Ericsson >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell >>> Sent: 7. juni 2011 20:29 >>> To: Simple WG >>> Cc: simple-chairs@tools.ietf.org Chairs >>> Subject: [Simple] SIMPLE meeting at IETF81 >>>=20 >>> (as chair) >>>=20 >>> Hi Everyone, >>>=20 >>> Given the new proposals and spirited discussion related to >> draft-ietf-simple-msrp-sessmatch currently happening on the >> work group list, the chairs have requested meeting time at >> the IETF81 meeting in Quebec City. We've asked for an hour >> slot, and currently expect this to be the only significant >> agenda item. >>>=20 >>> However, please do not defer discussion until the meeting. >> If we resolve the issues prior to the meeting, and end up >> canceling the meeting as a result, we would count that as a success. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 From pkyzivat@cisco.com Fri Jun 10 06:19:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0051F0C52 for ; Fri, 10 Jun 2011 06:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.329 X-Spam-Level: X-Spam-Status: No, score=-110.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAWYCOjA2SE1 for ; Fri, 10 Jun 2011 06:19:36 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E809B1F0C51 for ; Fri, 10 Jun 2011 06:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1371; q=dns/txt; s=iport; t=1307711975; x=1308921575; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=O21Gb3Q3ko9imYbYY4wCjiNY6f0+SpQq1TQ8Xw7fcjc=; b=SSfOYG9bh1invK4DQZVPtCu443xRZw8lHrBP+mCVmXbWXqKwMP+x5YE+ UR95o9x5yPb0dvWJD8rxRcZ4aVXCtQGWR5/MD2Ho0FG3oxegNtMkfKfe6 OVxHIEphjMMUh/QK47pL56PRsBXnjRwcijzqdzJtVg3Ykg/XvGw9TSzj+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugGAPAY8k2tJV2Z/2dsb2JhbABSmBKOM3eoF54PhiMEkSuETosl X-IronPort-AV: E=Sophos;i="4.65,347,1304294400"; d="scan'208";a="334347057" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 13:19:35 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5ADJYT2020276 for ; Fri, 10 Jun 2011 13:19:35 GMT Message-ID: <4DF219E6.2090109@cisco.com> Date: Fri, 10 Jun 2011 09:19:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: simple@ietf.org References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:19:36 -0000 Atle, On 6/10/2011 8:55 AM, Atle Monrad wrote: > Adrian > > as I am not an expert on the formalities on how the extentions under the responsibility of SIMPLE are handled and documented, this has to be left to others to comment and decide on. > > However, a point that I'd like to raise, is that 3GPP would like to get our requirements included into the RFCs as normative requirements that can be expressed as mandatory or optional statements. > > When requirements described in drafts become WG-items it seems natural to me that such options are seen as general options. Why these options have to be phrased explicitly as options strictly for 3GPP isn't actually what I had expected. There are two cases here: 1) requirements identified by 3gpp that are also applicable in the internet at large. 2) requirements that are only applicable when operating in a 3gpp environment. Both kinds can be considered as work items. But it is important for all the people working on these things to understand which is which. Understanding those that are specific to 3gpp typically require a level of understanding of 3gpp that few non-3gpp-affiliated ietf participants have. And when the work eventually leads to an RFC, future readers of that RFC should have that context to help in understanding if the RFC applies to them. Thanks, Paul From ag@ag-projects.com Fri Jun 10 06:30:29 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D4211E80B2 for ; Fri, 10 Jun 2011 06:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 Nhp7j8MkdBMN for ; Fri, 10 Jun 2011 06:30:28 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1744B11E80B1 for ; Fri, 10 Jun 2011 06:30:28 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 552ACB01BC; Fri, 10 Jun 2011 15:30:27 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 1CFCAB00E6; Fri, 10 Jun 2011 15:30:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> Date: Fri, 10 Jun 2011 15:30:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> To: Atle Monrad X-Mailer: Apple Mail (2.1084) Cc: "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:30:29 -0000 Hi Atle, It is critical that implementors can chose what standard to implement = for their customers. In this case is a clear delimitation of scope. An implementor should not = consider this draft when deploying for the Internet. An implementor for = 3GPP must because it is a clear requirement. In its current form, this draft may well be adopted for dubious reasons. = For example cheap residential router manufacturers will want it so that = 'they are MSRP compliant'. They will like the idea to have the same = feature of an Ericsson router, which is well implemented but they will = not do it good enough and things will break. With current MSRP design = you cannot break it, by opening this gate of new possibilities of = anchoring media things will break guaranteed. There are so many ifs in = the specification that if you hire 100 people you will end up with 100 = different solutions working in as many different ways. This draft must clearly be applied to its scope and no more, to avoid = breaking the rest of the MSRP traffic over the Internet. Adrian On Jun 10, 2011, at 2:55 PM, Atle Monrad wrote: > Adrian >=20 > as I am not an expert on the formalities on how the extentions under = the responsibility of SIMPLE are handled and documented, this has to be = left to others to comment and decide on. >=20 > However, a point that I'd like to raise, is that 3GPP would like to = get our requirements included into the RFCs as normative requirements = that can be expressed as mandatory or optional statements.=20 >=20 > When requirements described in drafts become WG-items it seems natural = to me that such options are seen as general options. Why these options = have to be phrased explicitly as options strictly for 3GPP isn't = actually what I had expected. >=20 > WRT the title - if this turns out to be the main blocking point, I'm = sure that this can be modified, as long as this doesn't restart and = alter the technical discussions already held and concluded. >=20 > /atle >=20 >=20 > ________________________________=20 >=20 >=20 > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management=20 > Ericsson >=20 >=20 >=20 >=20 > -----Original Message----- > From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 > Sent: 10. juni 2011 14:07 > To: Atle Monrad > Cc: Ben Campbell; Simple WG; simple-chairs@tools.ietf.org Chairs > Subject: Re: [Simple] SIMPLE meeting at IETF81 >=20 > Hello Atle, >=20 > As this draft is not required for MSRP protocol on Internet but = addresses strictly the needs of 3GPP rel-8 it should explicitly state = this simple fact in its title and description.=20 >=20 > Adrian >=20 > On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote: >=20 >> Ben / all >>=20 >> Christer has actively answered and incorporated comments given to = progress draft-ietf-simple-msrp-sessmatch since the draft became a = WG-item, and it would be good to get some clear guideance how to = progress and complete the work .=20 >>=20 >> This draft is one of the remaining dependencies in 3GPP rel-8, and a = conclusion from IETF would be appreciated in order for 3GPP to conclude = and complete the work.=20 >>=20 >> thanks >> /atle >>=20 >> ________________________________ >>=20 >>=20 >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management Ericsson >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Ben Campbell >> Sent: 7. juni 2011 20:29 >> To: Simple WG >> Cc: simple-chairs@tools.ietf.org Chairs >> Subject: [Simple] SIMPLE meeting at IETF81 >>=20 >> (as chair) >>=20 >> Hi Everyone, >>=20 >> Given the new proposals and spirited discussion related to = draft-ietf-simple-msrp-sessmatch currently happening on the work group = list, the chairs have requested meeting time at the IETF81 meeting in = Quebec City. We've asked for an hour slot, and currently expect this to = be the only significant agenda item. >>=20 >> However, please do not defer discussion until the meeting. If we = resolve the issues prior to the meeting, and end up canceling the = meeting as a result, we would count that as a success. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Fri Jun 10 06:33:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D872611E80AC for ; Fri, 10 Jun 2011 06:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDXnuSHr6PBP for ; Fri, 10 Jun 2011 06:33:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45A11E8075 for ; Fri, 10 Jun 2011 06:33:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fa-4df21d24a11d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 74.B9.20773.42D12FD4; Fri, 10 Jun 2011 15:33:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 10 Jun 2011 15:33:21 +0200 From: Christer Holmberg To: Paul Kyzivat , "simple@ietf.org" Date: Fri, 10 Jun 2011 15:33:20 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwncW+WRwAsz+6YRACiOfIu5cOFgQAACaqw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> <4DF219E6.2090109@cisco.com> In-Reply-To: <4DF219E6.2090109@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:33:27 -0000 Hi, Eventhough there is a requirement in 3GPP (and OMA) for this, it is not onl= y applicable to 3GPP/OMA. It is applicable to ANY network where ALGs might anchor media - functionalt= iy that you will find in many other networks than the ones defined by 3GPP/= OMA. 3GPP/OMA didn't invent the ALG :) But, as Roland also indicated, the draft provides some background text rega= rding the usage of ALGs in IMS. There is also an RFC giving some general AL= G description. It is also useful for MSRP endpoints located in non-ALG networks, when they= communicate with MSRP endpoints in networks with ALGs. Regards, Christer =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 10. kes=E4kuuta 2011 16:20 > To: simple@ietf.org > Subject: Re: [Simple] SIMPLE meeting at IETF81 >=20 > Atle, >=20 > On 6/10/2011 8:55 AM, Atle Monrad wrote: > > Adrian > > > > as I am not an expert on the formalities on how the=20 > extentions under the responsibility of SIMPLE are handled and=20 > documented, this has to be left to others to comment and decide on. > > > > However, a point that I'd like to raise, is that 3GPP would=20 > like to get our requirements included into the RFCs as=20 > normative requirements that can be expressed as mandatory or=20 > optional statements. > > > > When requirements described in drafts become WG-items it=20 > seems natural to me that such options are seen as general=20 > options. Why these options have to be phrased explicitly as=20 > options strictly for 3GPP isn't actually what I had expected. >=20 > There are two cases here: >=20 > 1) requirements identified by 3gpp that are also applicable=20 > in the internet at large. >=20 > 2) requirements that are only applicable when operating in a=20 > 3gpp environment. >=20 > Both kinds can be considered as work items. But it is=20 > important for all the people working on these things to=20 > understand which is which.=20 > Understanding those that are specific to 3gpp typically=20 > require a level of understanding of 3gpp that few=20 > non-3gpp-affiliated ietf participants have. And when the work=20 > eventually leads to an RFC, future readers of that RFC should=20 > have that context to help in understanding if the RFC applies to them. >=20 > Thanks, > Paul > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From christer.holmberg@ericsson.com Fri Jun 10 06:35:54 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9010211E814D for ; Fri, 10 Jun 2011 06:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t5uFPKzRWKj for ; Fri, 10 Jun 2011 06:35:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21C11E8135 for ; Fri, 10 Jun 2011 06:35:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-c1-4df21db7b028 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BC.44.09774.7BD12FD4; Fri, 10 Jun 2011 15:35:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 10 Jun 2011 15:35:48 +0200 From: Christer Holmberg To: Adrian Georgescu , Atle Monrad Date: Fri, 10 Jun 2011 15:35:47 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwncsV3zaowcPRnQ66Iq14R5qAaDQAAFhvw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3606D5@ESESSCMS0356.eemea.ericsson.se> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:35:54 -0000 Hi,=20 >It is critical that implementors can chose what standard to=20 >implement for their customers. >=20 >In this case is a clear delimitation of scope. An implementor=20 >should not consider this draft when deploying for the=20 >Internet. An implementor for 3GPP must because it is a clear=20 >requirement. >=20 >In its current form, this draft may well be adopted for=20 >dubious reasons. For example cheap residential router=20 >manufacturers will want it so that 'they are MSRP compliant'.=20 >They will like the idea to have the same feature of an=20 >Ericsson router, which is well implemented but they will not=20 >do it good enough and things will break. With current MSRP=20 >design you cannot break it, by opening this gate of new=20 >possibilities of anchoring media things will break=20 >guaranteed. There are so many ifs in the specification that=20 >if you hire 100 people you will end up with 100 different=20 >solutions working in as many different ways. >=20 >This draft must clearly be applied to its scope and no more,=20 >to avoid breaking the rest of the MSRP traffic over the Internet. If you deploy an MSRP endpoint compliant to the draft on the Internet, it i= s not going to break anything. There will be a fallback to 4975 behavior, a= nd everything will work fine. Regards, Christer > On Jun 10, 2011, at 2:55 PM, Atle Monrad wrote: >=20 > > Adrian > >=20 > > as I am not an expert on the formalities on how the=20 > extentions under the responsibility of SIMPLE are handled and=20 > documented, this has to be left to others to comment and decide on. > >=20 > > However, a point that I'd like to raise, is that 3GPP would=20 > like to get our requirements included into the RFCs as=20 > normative requirements that can be expressed as mandatory or=20 > optional statements.=20 > >=20 > > When requirements described in drafts become WG-items it=20 > seems natural to me that such options are seen as general=20 > options. Why these options have to be phrased explicitly as=20 > options strictly for 3GPP isn't actually what I had expected. > >=20 > > WRT the title - if this turns out to be the main blocking=20 > point, I'm sure that this can be modified, as long as this=20 > doesn't restart and alter the technical discussions already=20 > held and concluded. > >=20 > > /atle > >=20 > >=20 > > ________________________________ > >=20 > >=20 > > Atle Monrad > > 3GPP CT Chairman > > Standardization and Regulation, > > Group Function Technology and Portfolio Management Ericsson > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 > > Sent: 10. juni 2011 14:07 > > To: Atle Monrad > > Cc: Ben Campbell; Simple WG; simple-chairs@tools.ietf.org Chairs > > Subject: Re: [Simple] SIMPLE meeting at IETF81 > >=20 > > Hello Atle, > >=20 > > As this draft is not required for MSRP protocol on Internet=20 > but addresses strictly the needs of 3GPP rel-8 it should=20 > explicitly state this simple fact in its title and description.=20 > >=20 > > Adrian > >=20 > > On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote: > >=20 > >> Ben / all > >>=20 > >> Christer has actively answered and incorporated comments=20 > given to progress draft-ietf-simple-msrp-sessmatch since the=20 > draft became a WG-item, and it would be good to get some=20 > clear guideance how to progress and complete the work .=20 > >>=20 > >> This draft is one of the remaining dependencies in 3GPP=20 > rel-8, and a conclusion from IETF would be appreciated in=20 > order for 3GPP to conclude and complete the work.=20 > >>=20 > >> thanks > >> /atle > >>=20 > >> ________________________________ > >>=20 > >>=20 > >> Atle Monrad > >> 3GPP CT Chairman > >> Standardization and Regulation, > >> Group Function Technology and Portfolio Management Ericsson > >>=20 > >>=20 > >>=20 > >>=20 > >> -----Original Message----- > >> From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell > >> Sent: 7. juni 2011 20:29 > >> To: Simple WG > >> Cc: simple-chairs@tools.ietf.org Chairs > >> Subject: [Simple] SIMPLE meeting at IETF81 > >>=20 > >> (as chair) > >>=20 > >> Hi Everyone, > >>=20 > >> Given the new proposals and spirited discussion related to=20 > draft-ietf-simple-msrp-sessmatch currently happening on the=20 > work group list, the chairs have requested meeting time at=20 > the IETF81 meeting in Quebec City. We've asked for an hour=20 > slot, and currently expect this to be the only significant=20 > agenda item. > >>=20 > >> However, please do not defer discussion until the meeting.=20 > If we resolve the issues prior to the meeting, and end up=20 > canceling the meeting as a result, we would count that as a success. > >>=20 > >> Thanks! > >>=20 > >> Ben. > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple > >>=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From christer.holmberg@ericsson.com Fri Jun 10 06:40:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2711E8181 for ; Fri, 10 Jun 2011 06:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBjk7DezIuv9 for ; Fri, 10 Jun 2011 06:40:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B782711E817F for ; Fri, 10 Jun 2011 06:40:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b9-4df21ee611bb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DC.1D.20773.6EE12FD4; Fri, 10 Jun 2011 15:40:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 10 Jun 2011 15:40:54 +0200 From: Christer Holmberg To: Simple WG Date: Fri, 10 Jun 2011 15:40:53 +0200 Thread-Topic: Scope and applicability of draft-sessmatch Thread-Index: AcwndASCRGIJePjyQ/+clEf491mVFw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3606E3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3606E3ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Scope and applicability of draft-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:40:56 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3606E3ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Regarding the name, scope and applicability of the sessmatch draft, I am su= re everyone more or less has a common understanding of the environments whe= re the extension is useful, and I am sure we will be able to come up with t= ext that everyone can live with. However, I would not want that to stop us from moving forward with the tech= nical work. Have a nice weekend! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3606E3ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Regarding the name, scope and applicability of the se= ssmatch draft, I am sure everyone more or less has a common understanding o= f the environments where the extension is useful, and I am sure we will be = able to come up with text that everyone can live with.
 
However, I would not want that to stop us from moving= forward with the technical work.
 
Have a nice weekend!
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3606E3ESESSCMS0356e_-- From ibc@aliax.net Fri Jun 10 06:43:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3FD11E817F for ; Fri, 10 Jun 2011 06:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syOl+oQ4jl4x for ; Fri, 10 Jun 2011 06:43:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61A11E8185 for ; Fri, 10 Jun 2011 06:43:00 -0700 (PDT) Received: by qyk7 with SMTP id 7so1611623qyk.10 for ; Fri, 10 Jun 2011 06:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.71.77 with SMTP id g13mr1699602qcj.116.1307713379831; Fri, 10 Jun 2011 06:42:59 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 06:42:59 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> <4DF219E6.2090109@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 15:42:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:43:01 -0000 2011/6/10 Christer Holmberg : > But, as Roland also indicated, the draft provides some background text re= garding the usage of ALGs in IMS. There is also an RFC giving some general = ALG description. > > It is also useful for MSRP endpoints located in non-ALG networks, when th= ey communicate with MSRP endpoints in networks with ALGs. Hi Christer, please let's be clear: do you still prefer "ACE" name over the suggestions made here? Do you prefer "ACE" over "MSRP media anchoring mechanism for ALGs"? --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Fri Jun 10 06:44:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ACA11E8185 for ; Fri, 10 Jun 2011 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 7lWJe+ITpl-7 for ; Fri, 10 Jun 2011 06:44:21 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7C11E8181 for ; Fri, 10 Jun 2011 06:44:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 46958B01AE; Fri, 10 Jun 2011 15:44:20 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id CA80DB00E6; Fri, 10 Jun 2011 15:44:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 15:44:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> <4DF219E6.2090109@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 13:44:21 -0000 On Jun 10, 2011, at 3:33 PM, Christer Holmberg wrote: > Hi, >=20 > Eventhough there is a requirement in 3GPP (and OMA) for this, it is = not only applicable to 3GPP/OMA. Then again starting from a 3GPP requirement, you encourage and promote = the breaking of the public Internet by legitimate the usage of ALG into = the public internet and explain how to do such thing in detail in an = IETF specification. From ben@nostrum.com Fri Jun 10 07:17:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099711E818A for ; Fri, 10 Jun 2011 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.012 X-Spam-Level: X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i08iwIo1a-vv for ; Fri, 10 Jun 2011 07:17:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5D8811E80CA for ; Fri, 10 Jun 2011 07:17:33 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p5AEHPPA023852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2011 09:17:27 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Fri, 10 Jun 2011 09:17:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:17:35 -0000 (replying to thread in general, not specifically to I=F1aki's email) While the naming conversation is "interesting", I'd like to remind = people that there are technical aspects of this draft that need to be = considered as well. Or should I assume that if we agree on a name, = everyone agrees with the _rest_ of the draft? ;-) Thanks! Ben. On Jun 10, 2011, at 7:37 AM, I=F1aki Baz Castillo wrote: > 2011/6/10 Christer Holmberg : >> I just think it's weird to base arguments on a "coolness" comparison = between a draft name and a draft content... >=20 > The draft title must represent the draft content. If the content > clearly talks about scenarios with ALG's, and such devices are out of > the scope of "pure" internet, I strongly think that the draft title > should notice it. >=20 >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Fri Jun 10 07:46:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F2A11E80BD for ; Fri, 10 Jun 2011 07:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-7wh93U+w81 for ; Fri, 10 Jun 2011 07:46:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC011E80B3 for ; Fri, 10 Jun 2011 07:46:49 -0700 (PDT) Received: by qwc23 with SMTP id 23so1776293qwc.31 for ; Fri, 10 Jun 2011 07:46:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.212 with SMTP id e20mr1636250qce.192.1307717209256; Fri, 10 Jun 2011 07:46:49 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 07:46:49 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 16:46:49 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 14:46:50 -0000 2011/6/10 Ben Campbell : > While the naming conversation is "interesting", I'd like to remind people= that there are technical aspects of this draft that need to be considered = as well. Or should I assume that if we agree on a name, everyone agrees wit= h the _rest_ of the draft? ;-) Hi Ben. I think that Christian Schmidt has already asked important question= s: > Lets assume the following model: > MSRP endpoint A -> combination of NATs, MSRP-Proxies, ALGs -> MSRP endpoi= nt B. > > Is there any combination of NATs, MSRP-Proxies and ALGs where > - a MSRP connection is successful (with both MRSP endpoints acting accord= ing RFC4975) > - a MSRP connection is not successful due to the fact, that one or both M= RSP endpoints acts according this ACE specification? IMHO the draft should clarify all those scenarios *in detail*. Honestly I don't have the strength to simulate and analyze them. Depending on the results we would know whether this draft breaks something (I mean something already working just with RFC 4975/4976) or not. Further discussions will happen then. Personally, if it breaks nothing I'm happy. I will just ignore this specification and hopefully this specification will ignore me for the rest of my days. The remaining issue would be, of course, the draft title. Arguments already exposed in these mail threads. My main points are: - This is not a cool/useful spec for Internet, so don't use a "cool" name/abbreviation. It does not deserve it. - The draft name should clearly reference walled gardens scenarios, so implementors in pure internet can discard it without having to read the draft content. Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Fri Jun 10 08:23:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED15611E80F0 for ; Fri, 10 Jun 2011 08:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkODRP4Uo8vc for ; Fri, 10 Jun 2011 08:23:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D86E411E80E0 for ; Fri, 10 Jun 2011 08:23:09 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8d-4df236d94455 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.67.20773.9D632FD4; Fri, 10 Jun 2011 17:23:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 10 Jun 2011 17:23:02 +0200 From: Christer Holmberg To: Adrian Georgescu Date: Fri, 10 Jun 2011 17:19:40 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwndIBsnHSehslBQrae9JFhTpSP0QADVExa Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A42F@ESESSCMS0356.eemea.ericsson.se> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> <4DF219E6.2090109@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:23:12 -0000 Hi, >>Eventhough there is a requirement in 3GPP (and OMA) for this, it is not o= nly applicable to 3GPP/OMA. > >Then again starting from a 3GPP requirement, you encourage and promote the= breaking of the public Internet=20 >by legitimate the usage of ALG into the public internet and explain how to= do such thing in detail in an IETF=20 >specification. I encourage people to implement the draft, so that MSRP can be used in netw= orks where ALGs have been deployed. Because, people are not going to remove the ALGs just in order to be able t= o run MSRP. That is not based on my decission or "encouragement" - that's a= fact based on feedback from customers etc. Regards, Christer= From christer.holmberg@ericsson.com Fri Jun 10 08:25:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF25011E80E0 for ; Fri, 10 Jun 2011 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KPHJMcd7dIu for ; Fri, 10 Jun 2011 08:25:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DAAE811E80C0 for ; Fri, 10 Jun 2011 08:25:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-56-4df2376bf9fd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 27.AA.09774.B6732FD4; Fri, 10 Jun 2011 17:25:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 10 Jun 2011 17:25:27 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 10 Jun 2011 17:23:08 +0200 Thread-Topic: [Simple] SIMPLE meeting at IETF81 Thread-Index: AcwndFCJEFeXaUc/RES72baOyrEkSAADf1Gh Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A430@ESESSCMS0356.eemea.ericsson.se> References: <7A051DFAA46D0246A82293C7CEF621E905690BAE34@ESESSCMS0352.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E905690BAECF@ESESSCMS0352.eemea.ericsson.se> <4DF219E6.2090109@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3606CC@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] SIMPLE meeting at IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:25:33 -0000 Hi, >> But, as Roland also indicated, the draft provides some background text r= egarding the usage of ALGs in=20 >>IMS. There is also an RFC giving some general ALG description. >> >>It is also useful for MSRP endpoints located in non-ALG networks, when th= ey communicate with MSRP >>endpoints in networks with ALGs. > >Hi Christer, please let's be clear: do you still prefer "ACE" name >over the suggestions made here? >Do you prefer "ACE" over "MSRP media anchoring mechanism for ALGs"? I will have to go through the suggestions. I also have some suggestions mys= elf. But, as I said, I am not religious about the name, so I am sure we will fin= d something that we can agree upon :) Regards, Christer -- I=F1aki Baz Castillo = From christer.holmberg@ericsson.com Fri Jun 10 09:43:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2621F843B for ; Fri, 10 Jun 2011 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvxXG1of1b5L for ; Fri, 10 Jun 2011 09:43:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36821F8438 for ; Fri, 10 Jun 2011 09:43:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-bb-4df249ccbf84 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E9.7B.09774.CC942FD4; Fri, 10 Jun 2011 18:43:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 10 Jun 2011 18:43:55 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Ben Campbell Date: Fri, 10 Jun 2011 18:43:55 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnfTwRFD7Suu/WSoOl+MEOljOumAABZxtB Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A431@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:43:59 -0000 Hi, >>While the naming conversation is "interesting", I'd like to remind people= that there are technical aspects of this draft that need to=20 >>be considered as well. Or should I assume that if we agree on a name, eve= ryone agrees with the _rest_ of the draft? ;-) > >Hi Ben. I think that Christian Schmidt has already asked important questio= ns: > >> Lets assume the following model: >> MSRP endpoint A -> combination of NATs, MSRP-Proxies, ALGs -> MSRP endpo= int B. >> >> Is there any combination of NATs, MSRP-Proxies and ALGs where >> - a MSRP connection is successful (with both MRSP endpoints acting accor= ding RFC4975) >> - a MSRP connection is not successful due to the fact, that one or both = MRSP endpoints acts according this ACE specification? All combinations will work, but there are cases where an ALG still needs to= enable MSRP B2BUA functionality. Those cases are basically where (in the presence of an ALG) an RFC 4975 ent= ity becomes "active", ie cases where a 4975 UA or a 4976 relay establishes = the MSRP TCP connection. There are no impacts regarding NATs. >IMHO the draft should clarify all those scenarios *in detail*. >Honestly I don't have the strength to simulate and analyze them. > >Depending on the results we would know whether this draft breaks >something (I mean something already working just with RFC 4975/4976) >or not. Further discussions will happen then. Everything that works today will continue to work. Also, there is probably text in the draft that can be further simplified. T= he main focus of version -12 was to describe the mechanism, so that it is e= asier for people go get a picture of it. >Personally, if it breaks nothing I'm happy. I will just ignore this >specification and hopefully this specification will ignore me for the >rest of my days. The remaining issue would be, of course, the draft >title. Arguments already exposed in these mail threads. My main points >are: > >- This is not a cool/useful spec for Internet, so don't use a "cool" >name/abbreviation. It does not deserve it. In order to be really cool it would have to be the name of an alcoholic dri= nk. The only "ACE" drink I could find was an energy drink and a vitamine ju= ice :) >- The draft name should clearly reference walled gardens scenarios, so >implementors in pure internet can discard it without having to read >the draft content. I really hope that implementors don't do implementation decissions purely b= ased on draft titles... :) Regards, Christer= From HKaplan@acmepacket.com Fri Jun 10 10:07:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DC211E80E1 for ; Fri, 10 Jun 2011 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 mY92FW3NLmIs for ; Fri, 10 Jun 2011 10:07:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6783711E80CC for ; Fri, 10 Jun 2011 10:07:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Jun 2011 13:07:17 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Jun 2011 13:07:17 -0400 From: Hadriel Kaplan To: Simple WG Date: Fri, 10 Jun 2011 13:07:16 -0400 Thread-Topic: Sessmatch "breaking" legacy MSRP Thread-Index: AcwnkNnQs7r/QyxhQ3CSVrDSCtQpFA== Message-ID: <16DF222A-7915-4DC4-B921-0A89E1E5A29E@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFV Subject: [Simple] Sessmatch "breaking" legacy MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:07:20 -0000 Howdy, several people have raised arguments that the Sessmatch extension is bad be= cause it doesn't interoperate with legacy MSRP. Ignoring the fact that there's very little deployed legacy MSRP to be broke= n, I'm not sure it's a valid argument anyway. We've extended SIP numerous = times with mechanisms that require both ends to support them to work - for = example, PRACK. The option-tag mechanism is there to handle that for SIP, = and anytime an option-tag is put in a Requires header, the far-end has to s= upport it for the request to succeed. More importantly, MSRP is indicated in SDP, and SDP's raison d'=EAtre is to= indicate not only addressing information but also capabilities... possibly= incompatible capabilities. No one argue G.729 should not be allowed becau= se a device only supporting G.729 does not interop with one supporting only= G.711. Nor does a device only support SRTP interop with one only support = cleartext RTP. Nor does one only supporting RTP over UDP interop with one = supporting only RTP over TCP. Etc., etc. Sessmatch is an extension, and one that both sides must support to do sessm= atch. That isn't a new concept to grasp. -hadriel From HKaplan@acmepacket.com Fri Jun 10 10:07:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2E011E810F for ; Fri, 10 Jun 2011 10:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfChSWB7BEzV for ; Fri, 10 Jun 2011 10:07:23 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id D589411E810A for ; Fri, 10 Jun 2011 10:07:21 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 10 Jun 2011 13:07:21 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Jun 2011 13:07:20 -0400 From: Hadriel Kaplan To: Christer Holmberg Date: Fri, 10 Jun 2011 13:07:19 -0400 Thread-Topic: Draft ACE: ALG terminology Thread-Index: AcwnkNurP0r43X0vRKSzS6ufPhFsqg== Message-ID: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFT Cc: Simple WG Subject: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:07:23 -0000 Howdy, In the latest ACE draft sessmatch-12 (and previous versions of sessmatch), = the term "ALG" is used to describe the middlebox. I think this causes mass= confusion and angst for people. An "ALG" is generally used to describe a = function that performs protocol modification in an inline fashion, without = being an addressed entity - for example inside a router or NAT - by inspect= ing packet contents unbeknownst to the client application. That is NOT wha= t the ACE extension is meant to enable, afaik; nor is ACE necessary to enab= le such. =20 For example, a 3GPP IBCF is not an "ALG", nor is a P-CSCF+BGF, nor is an SB= C. Instead, they are addressed hosts - the hosts to which the SIP+MSRP UAs= target their packets/connections. From a SIP perspective, such hosts are = B2BUA's not ALGs; and from an MSRP perspective such hosts are transport rel= ays, similar to SOCKS relays. =20 This is not a small difference. True "ALGs", such as those in routers/NATs= , cannot be easily avoided by host applications, except by obfuscating thei= r protocol traffic (e.g., by using encryption, or changing port numbers); a= nd if they happen to use encryption or authentication then the ALG function= no longer works, if it was needed. A SIP B2BUA/Proxy, on the other hand, = is addressed by the host application - the application can use TLS or IPsec= to the B2BUA, or avoid the B2BUA by addressing a different next-hop. The reason I bring this up is that several emails so far seem to believe th= is is actually about ALGs, and raise concerns about accommodating such devi= ces. -hadriel From ibc@aliax.net Fri Jun 10 10:48:54 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478B111E81C6 for ; Fri, 10 Jun 2011 10:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+U+IoNu7KmK for ; Fri, 10 Jun 2011 10:48:53 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAA611E8138 for ; Fri, 10 Jun 2011 10:48:51 -0700 (PDT) Received: by qyk29 with SMTP id 29so1792734qyk.10 for ; Fri, 10 Jun 2011 10:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.212 with SMTP id e20mr1833331qce.192.1307728130850; Fri, 10 Jun 2011 10:48:50 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 10:48:50 -0700 (PDT) In-Reply-To: <16DF222A-7915-4DC4-B921-0A89E1E5A29E@acmepacket.com> References: <16DF222A-7915-4DC4-B921-0A89E1E5A29E@acmepacket.com> Date: Fri, 10 Jun 2011 19:48:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Sessmatch "breaking" legacy MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:48:54 -0000 2011/6/10 Hadriel Kaplan : > Howdy, > several people have raised arguments that the Sessmatch extension is bad = because it doesn't interoperate with legacy MSRP. > Ignoring the fact that there's very little deployed legacy MSRP to be bro= ken, I'm not sure it's a valid argument anyway. =C2=A0We've extended SIP nu= merous times with mechanisms that require both ends to support them to work= - for example, PRACK. =C2=A0The option-tag mechanism is there to handle th= at for SIP, and anytime an option-tag is put in a Requires header, the far-= end has to support it for the request to succeed. > > More importantly, MSRP is indicated in SDP, and SDP's raison d'=C3=AAtre = is to indicate not only addressing information but also capabilities... pos= sibly incompatible capabilities. =C2=A0No one argue G.729 should not be all= owed because a device only supporting G.729 does not interop with one suppo= rting only G.711. =C2=A0Nor does a device only support SRTP interop with on= e only support cleartext RTP. =C2=A0Nor does one only supporting RTP over U= DP interop with one supporting only RTP over TCP. =C2=A0Etc., etc. > > Sessmatch is an extension, and one that both sides must support to do ses= smatch. =C2=A0That isn't a new concept to grasp. Hadriel, don't take me wrong but it seems you have missed all the threads about this topic in which lot of arguments were given. Just to summarize: > Ignoring the fact that there's very little deployed legacy MSRP to be bro= ken. This can NEVER be a reason to break an existing protocol. And there *are* existing MSRP implementations outside legacy boring walled gardens. I mean: "Internet". > We've extended SIP numerous times with mechanisms that require both ends = to support them to work - for example, PRACK. The option-tag mechanism is = there to handle that for SIP, and anytime an option-tag is put in a Require= s header, the far-end has to support it for the request to succeed. > No one argue G.729 should not be allowed because a device only supporting= G.729 does not interop with one supporting only G.711. Nor does a device = only support SRTP interop with one only support cleartext RTP. The critical difference here is that PRACK is useful for Internet and provides a real added value to the SIP protocol (no matter it was originally designed by an IMS requirement). In the other side, sessmatch is just useful for corrupted networks in which ALG's boxes break OSI/Internet layers because vendors want to anchor MSRP media by requiring *unencrypted* SIP sessions (SIP over TLS avoids media anchoring). In short, this document does not specify a new feature (it's not a codec or a new media transport). This document wants to standarize an aberration against Internet design just in favour of big vendors. If the new draft does not break existing MSRP scenarios, it's ok, you are strong enough to force IETF to approve such an aberration. At least it will not disturb people in the real Internet as me and much others. We can just ignore it and hope IETF will never publish a document like this. But if the new draft does still break today's working scenarios (those in which RFC 4975/4976 work), and you still promote the draft in IETF, then congratulations for your great contributtion to the world. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Jun 10 10:58:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2769C11E8204 for ; Fri, 10 Jun 2011 10:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef+XBXXXMOug for ; Fri, 10 Jun 2011 10:58:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20211E81FC for ; Fri, 10 Jun 2011 10:58:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so1941849qwc.31 for ; Fri, 10 Jun 2011 10:58:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.212 with SMTP id e20mr1843661qce.192.1307728719636; Fri, 10 Jun 2011 10:58:39 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 10:58:39 -0700 (PDT) In-Reply-To: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> Date: Fri, 10 Jun 2011 19:58:39 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 17:58:41 -0000 2011/6/10 Hadriel Kaplan : > This is not a small difference. =C2=A0True "ALGs", such as those in route= rs/NATs, cannot be easily avoided by host applications, except by obfuscati= ng their protocol traffic (e.g., by using encryption, or changing port numb= ers); and if they happen to use encryption or authentication then the ALG f= unction no longer works, if it was needed. =C2=A0A SIP B2BUA/Proxy, on the = other hand, is addressed by the host application - the application can use = TLS or IPsec to the B2BUA, or avoid the B2BUA by addressing a different nex= t-hop. I understand the rest of your mail, but don't get what you mean in this last paragraph in which you are talking about ALG-enabled devices (as routers) and B2BUA's. Of course a B2BUA handles the application protocol at application level, so it does not perform ALG functions. In the other side an ALG-enabled device (as a NAT router) handles the application protocol (i.e. SIP) at UDP/TCP level (not respecting Internet layers) so it's not a B2BUA. Ok, so an ALG-enabled device is not a B2BUA, and a B2BUA is not an ALG-enabled device. And what? Where is the confusion? the draft clearly talks about ALG devices, those which don't work at application level (but at transport level). sessmatch/ACE mechanism is just useful for SIP ALG enabled nodes in the network, no more. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Fri Jun 10 11:04:29 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13F511E8208 for ; Fri, 10 Jun 2011 11:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZRukVfxVJHz for ; Fri, 10 Jun 2011 11:04:29 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF57A11E81C7 for ; Fri, 10 Jun 2011 11:04:28 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id A238EB01B8; Fri, 10 Jun 2011 20:04:27 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 855BCB00E6; Fri, 10 Jun 2011 20:04:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> Date: Fri, 10 Jun 2011 20:04:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:04:29 -0000 Hadriel, This confusion is created by the very idea of trying to legitimate the = use of intermediates in a by design end-to-end protocol with clients and = servers.=20 The only thing sure about ALG is that they break things by design. When = they work, is an exception. ALG terminology? Google for it. The word failure is associated with it = in each result. =20 On Jun 10, 2011, at 7:07 PM, Hadriel Kaplan wrote: > Howdy, > In the latest ACE draft sessmatch-12 (and previous versions of = sessmatch), the term "ALG" is used to describe the middlebox. I think = this causes mass confusion and angst for people. An "ALG" is generally = used to describe a function that performs protocol modification in an = inline fashion, without being an addressed entity - for example inside a = router or NAT - by inspecting packet contents unbeknownst to the client = application. That is NOT what the ACE extension is meant to enable, = afaik; nor is ACE necessary to enable such. =20 >=20 > For example, a 3GPP IBCF is not an "ALG", nor is a P-CSCF+BGF, nor is = an SBC. Instead, they are addressed hosts - the hosts to which the = SIP+MSRP UAs target their packets/connections. =46rom a SIP = perspective, such hosts are B2BUA's not ALGs; and from an MSRP = perspective such hosts are transport relays, similar to SOCKS relays. =20= >=20 > This is not a small difference. True "ALGs", such as those in = routers/NATs, cannot be easily avoided by host applications, except by = obfuscating their protocol traffic (e.g., by using encryption, or = changing port numbers); and if they happen to use encryption or = authentication then the ALG function no longer works, if it was needed. = A SIP B2BUA/Proxy, on the other hand, is addressed by the host = application - the application can use TLS or IPsec to the B2BUA, or = avoid the B2BUA by addressing a different next-hop. >=20 > The reason I bring this up is that several emails so far seem to = believe this is actually about ALGs, and raise concerns about = accommodating such devices. >=20 > -hadriel >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ag@ag-projects.com Fri Jun 10 11:20:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6019F9E8016 for ; Fri, 10 Jun 2011 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 6Lqz0p3WRQDe for ; Fri, 10 Jun 2011 11:20:21 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6DC9E800D for ; Fri, 10 Jun 2011 11:20:21 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 75D20B01B8; Fri, 10 Jun 2011 20:20:20 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 95A38B017C; Fri, 10 Jun 2011 20:20:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: Date: Fri, 10 Jun 2011 20:20:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84566181-E54F-4868-844F-5321F50C39ED@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:20:22 -0000 Hi Ben, No person on this mailing list can claim to understand the consequences = of the act of legitimating the insertion of a intermediate in the path = of an end-to end protocol like MSRP. =20 MSRP sess-match does exactly this act. This act leads to non-deterministic behavior.=20 For this reason alone, this aberration must be confined to the = environment where vendors and their customers (3GPP OMA deployments in = this very case) can fix the problems and a standardization body like = IETF cannot be made responsible for creating such aberration as a = standard for how things work on the open Internet. I assume that what 3GPP and IETF have agreed to do together in terms of = standardization is not a blank check for destroying every other work = that has been done previously in the IETF for the sake of some vendors = selling equipment to closed IP networks. If it is, then of course I will = stop complaining uselessly and barking at trees. Adrian On Jun 10, 2011, at 4:17 PM, Ben Campbell wrote: > (replying to thread in general, not specifically to I=F1aki's email) >=20 > While the naming conversation is "interesting", I'd like to remind = people that there are technical aspects of this draft that need to be = considered as well. Or should I assume that if we agree on a name, = everyone agrees with the _rest_ of the draft? ;-) >=20 > Thanks! >=20 > Ben. >=20 > On Jun 10, 2011, at 7:37 AM, I=F1aki Baz Castillo wrote: >=20 >> 2011/6/10 Christer Holmberg : >>> I just think it's weird to base arguments on a "coolness" comparison = between a draft name and a draft content... >>=20 >> The draft title must represent the draft content. If the content >> clearly talks about scenarios with ALG's, and such devices are out of >> the scope of "pure" internet, I strongly think that the draft title >> should notice it. >>=20 >>=20 >>=20 >> --=20 >> I=F1aki Baz Castillo >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Fri Jun 10 11:32:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF39711E80E8 for ; Fri, 10 Jun 2011 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cymw8n0cxPlk for ; Fri, 10 Jun 2011 11:32:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE1611E8075 for ; Fri, 10 Jun 2011 11:32:58 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-24-4df263599ab6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 78.BF.20773.95362FD4; Fri, 10 Jun 2011 20:32:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 10 Jun 2011 20:32:57 +0200 From: Christer Holmberg To: Adrian Georgescu , Ben Campbell Date: Fri, 10 Jun 2011 20:32:56 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnmxOqoIQw6za/TgyXzTCNEtqbegAAJ/wP Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A433@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> , <84566181-E54F-4868-844F-5321F50C39ED@ag-projects.com> In-Reply-To: <84566181-E54F-4868-844F-5321F50C39ED@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:33:00 -0000 Hi, >No person on this mailing list can claim to understand the consequences of= the act of legitimating the insertion >of a intermediate in the path of an= end-to end protocol like MSRP. > >MSRP sess-match does exactly this act. > >This act leads to non-deterministic behavior. > >For this reason alone, this aberration must be confined to the environment= where vendors and their=20 >customers (3GPP OMA deployments in this very case) can fix the problems a= nd a standardization body like=20 >IETF cannot be made responsible for creating such aberration as a standard= for how things work on the open=20 >Internet. > >I assume that what 3GPP and IETF have agreed to do together in terms of st= andardization is not a blank=20 >check for destroying every other work that has been done previously in the= IETF for the sake of some=20 >vendors selling equipment to closed IP networks. If it is, then of course = I will stop complaining uselessly and=20 >barking at trees. There is no blank check.=20 For example, people have indicated that there needs to be a backward compab= ility story - which the draft tries to describe. The very first version of = the mechanism (at that time still part of the ACM draft) did NOT provide ba= ckward compability, and was rejected by the WG. Also keep in mind that some of the "closed IP networks" are conneted to the= Internet, and/or to other networks with 4975 endpoints, so it is also in t= heir interest to know how to provide backward compability. Last, the main reason behind the mechanism has been known from the beginnin= g, when the SIMPLE milestone was created. It has never been a "secret". Regards, Christer On Jun 10, 2011, at 4:17 PM, Ben Campbell wrote: > (replying to thread in general, not specifically to I=F1aki's email) > > While the naming conversation is "interesting", I'd like to remind people= that there are technical aspects of this draft that need to be considered = as well. Or should I assume that if we agree on a name, everyone agrees wit= h the _rest_ of the draft? ;-) > > Thanks! > > Ben. > > On Jun 10, 2011, at 7:37 AM, I=F1aki Baz Castillo wrote: > >> 2011/6/10 Christer Holmberg : >>> I just think it's weird to base arguments on a "coolness" comparison be= tween a draft name and a draft content... >> >> The draft title must represent the draft content. If the content >> clearly talks about scenarios with ALG's, and such devices are out of >> the scope of "pure" internet, I strongly think that the draft title >> should notice it. >> >> >> >> -- >> I=F1aki Baz Castillo >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From christer.holmberg@ericsson.com Fri Jun 10 11:42:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E01411E8192 for ; Fri, 10 Jun 2011 11:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6HoKRMe-szb for ; Fri, 10 Jun 2011 11:42:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE9B11E8196 for ; Fri, 10 Jun 2011 11:42:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e5-4df2658a7b25 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 53.2C.09774.A8562FD4; Fri, 10 Jun 2011 20:42:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 10 Jun 2011 20:42:17 +0200 From: Christer Holmberg To: Christer Holmberg , Adrian Georgescu , Ben Campbell Date: Fri, 10 Jun 2011 20:42:17 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnmxOqoIQw6za/TgyXzTCNEtqbegAAJ/wPAABcFJw= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A435@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> , <84566181-E54F-4868-844F-5321F50C39ED@ag-projects.com>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A433@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A433@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:42:25 -0000 Hi, Another example showing that we're not talking about a "blank check" is the= conserns people raised due to the fact that name based authentication didn= 't work with the previuos version.=20 3GPP provides other authentication mechanisms, but people still wanted that= the main authentication mechanism of 4975 should still work. There may als= o be other parts of the security considerations that don't apply to 3GPP. Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Friday, June 10, 2011 9:32 PM To: Adrian Georgescu; Ben Campbell Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously = known as sessmatch Hi, >No person on this mailing list can claim to understand the consequences of= the act of legitimating the insertion >of a intermediate in the path of an= end-to end protocol like MSRP. > >MSRP sess-match does exactly this act. > >This act leads to non-deterministic behavior. > >For this reason alone, this aberration must be confined to the environment= where vendors and their >customers (3GPP OMA deployments in this very case) can fix the problems a= nd a standardization body like >IETF cannot be made responsible for creating such aberration as a standard= for how things work on the open >Internet. > >I assume that what 3GPP and IETF have agreed to do together in terms of st= andardization is not a blank >check for destroying every other work that has been done previously in the= IETF for the sake of some >vendors selling equipment to closed IP networks. If it is, then of course = I will stop complaining uselessly and >barking at trees. There is no blank check. For example, people have indicated that there needs to be a backward compab= ility story - which the draft tries to describe. The very first version of = the mechanism (at that time still part of the ACM draft) did NOT provide ba= ckward compability, and was rejected by the WG. Also keep in mind that some of the "closed IP networks" are conneted to the= Internet, and/or to other networks with 4975 endpoints, so it is also in t= heir interest to know how to provide backward compability. Last, the main reason behind the mechanism has been known from the beginnin= g, when the SIMPLE milestone was created. It has never been a "secret". Regards, Christer On Jun 10, 2011, at 4:17 PM, Ben Campbell wrote: > (replying to thread in general, not specifically to I=F1aki's email) > > While the naming conversation is "interesting", I'd like to remind people= that there are technical aspects of this draft that need to be considered = as well. Or should I assume that if we agree on a name, everyone agrees wit= h the _rest_ of the draft? ;-) > > Thanks! > > Ben. > > On Jun 10, 2011, at 7:37 AM, I=F1aki Baz Castillo wrote: > >> 2011/6/10 Christer Holmberg : >>> I just think it's weird to base arguments on a "coolness" comparison be= tween a draft name and a draft content... >> >> The draft title must represent the draft content. If the content >> clearly talks about scenarios with ALG's, and such devices are out of >> the scope of "pure" internet, I strongly think that the draft title >> should notice it. >> >> >> >> -- >> I=F1aki Baz Castillo >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From HKaplan@acmepacket.com Fri Jun 10 11:53:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41411E80CB for ; Fri, 10 Jun 2011 11:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFv3lq2b5mTY for ; Fri, 10 Jun 2011 11:53:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 974ED11E8075 for ; Fri, 10 Jun 2011 11:53:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Jun 2011 14:53:01 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Jun 2011 14:53:01 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 10 Jun 2011 14:53:00 -0400 Thread-Topic: [Simple] Sessmatch "breaking" legacy MSRP Thread-Index: Acwnn58p/5+NM7WFTTaCSCXADxD7vg== Message-ID: References: <16DF222A-7915-4DC4-B921-0A89E1E5A29E@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Sessmatch "breaking" legacy MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:53:08 -0000 On Jun 10, 2011, at 1:48 PM, I=F1aki Baz Castillo wrote: >=20 > Hadriel, don't take me wrong but it seems you have missed all the > threads about this topic in which lot of arguments were given. I tried to catch up, but there are so many it's impractical, so I did rando= m selection. :) > Just to > summarize: >=20 >> Ignoring the fact that there's very little deployed legacy MSRP to be br= oken. >=20 > This can NEVER be a reason to break an existing protocol. Sure it can. You can change the status of a previous RFC to Historic, for = example. But that's not what's being proposed. What's being proposed isn'= t to "break" MSRP - it's to create an extension. > In the other side, sessmatch is just useful for corrupted networks in > which ALG's boxes break OSI/Internet layers because vendors want to > anchor MSRP media by requiring *unencrypted* SIP sessions (SIP over > TLS avoids media anchoring). No, I really don't think that's the goal of sessmatch. I know the draft sa= ys "ALG", but it's misleading/wrong. The use-case they have in mind is ess= entially a SIP B2BUA. It is the target of your SIP request. SIP _can_ use= TLS.=20 -hadriel From ag@ag-projects.com Fri Jun 10 12:02:37 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AA411E8154 for ; Fri, 10 Jun 2011 12:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 7ineimOsygJz for ; Fri, 10 Jun 2011 12:02:37 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1611E8075 for ; Fri, 10 Jun 2011 12:02:33 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E9436B01B8; Fri, 10 Jun 2011 21:02:31 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 217F9B017C; Fri, 10 Jun 2011 21:02:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A433@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 10 Jun 2011 21:02:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> , <84566181-E54F-4868-844F-5321F50C39ED@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A433@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 19:02:37 -0000 On Jun 10, 2011, at 8:32 PM, Christer Holmberg wrote: > Hi, >=20 >> No person on this mailing list can claim to understand the = consequences of the act of legitimating the insertion >of a intermediate = in the path of an end-to end protocol like MSRP. >>=20 >> MSRP sess-match does exactly this act. >>=20 >> This act leads to non-deterministic behavior. >>=20 >> For this reason alone, this aberration must be confined to the = environment where vendors and their=20 >> customers (3GPP OMA deployments in this very case) can fix the = problems and a standardization body like=20 >> IETF cannot be made responsible for creating such aberration as a = standard for how things work on the open=20 >> Internet. >>=20 >> I assume that what 3GPP and IETF have agreed to do together in terms = of standardization is not a blank=20 >> check for destroying every other work that has been done previously = in the IETF for the sake of some=20 >> vendors selling equipment to closed IP networks. If it is, then of = course I will stop complaining uselessly and=20 >> barking at trees. >=20 > There is no blank check.=20 >=20 > For example, people have indicated that there needs to be a backward = compability story - which the draft tries to describe. The very first = version of the mechanism (at that time still part of the ACM draft) did = NOT provide backward compability, and was rejected by the WG. After +200 emails do you honestly think there is a clear cut here? > Also keep in mind that some of the "closed IP networks" are conneted = to the Internet, and/or to other networks with 4975 endpoints, so it is = also in their interest to know how to provide backward compability. There is always a gateway between such environment. A B2BUA for both = signaling and media. There is no need for other mechanism to be = specified between the two. > Last, the main reason behind the mechanism has been known from the = beginning, when the SIMPLE milestone was created. It has never been a = "secret". Yes, but the nature of this act emerged once people started zooming on = it. And it reveals all the signs of poor design decisions that can later = break things with no one being accountable anymore.=20 So if this solves a problem for a particular environment where specific = assumptions were made is fine but coin as such. Do not call it a generic = mechanism for Internet usage.=20 Adrian =20 From ibc@aliax.net Fri Jun 10 12:03:13 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3763F11E81AA for ; Fri, 10 Jun 2011 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTBeoE404MVO for ; Fri, 10 Jun 2011 12:03:12 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5C611E8198 for ; Fri, 10 Jun 2011 12:03:12 -0700 (PDT) Received: by qyk29 with SMTP id 29so24643qyk.10 for ; Fri, 10 Jun 2011 12:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.151 with SMTP id n23mr1830398qci.268.1307732585381; Fri, 10 Jun 2011 12:03:05 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 12:03:05 -0700 (PDT) In-Reply-To: References: <16DF222A-7915-4DC4-B921-0A89E1E5A29E@acmepacket.com> Date: Fri, 10 Jun 2011 21:03:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Sessmatch "breaking" legacy MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 19:03:13 -0000 2011/6/10 Hadriel Kaplan : >> Just to >> summarize: >> >>> Ignoring the fact that there's very little deployed legacy MSRP to be b= roken. >> >> This can NEVER be a reason to break an existing protocol. > > Sure it can. =C2=A0You can change the status of a previous RFC to Histori= c, for example. =C2=A0But that's not what's being proposed. =C2=A0What's be= ing proposed isn't to "break" MSRP - it's to create an extension. ...an extension that, at least until previous draft version, *did* break the existing MSRP protocol. Don't name it "extension" please. Breaking a protocol without adding a real value can never be called an "extension". > >> In the other side, sessmatch is just useful for corrupted networks in >> which ALG's boxes break OSI/Internet layers because vendors want to >> anchor MSRP media by requiring *unencrypted* SIP sessions (SIP over >> TLS avoids media anchoring). > > No, I really don't think that's the goal of sessmatch. =C2=A0I know the d= raft says "ALG", but it's misleading/wrong. =C2=A0The use-case they have in= mind is essentially a SIP B2BUA. =C2=A0It is the target of your SIP reques= t. =C2=A0SIP _can_ use TLS. After 100-200 mails about this topic, I'm pettry sure the document mainly means "ALG" devices (those which mangle/inspect SIP at transport layer level, so they are not B2BUA). If we were speaking about SIP and MSRP B2BUA's, then sessmatch was no reason to exist. Am I wrong? --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Fri Jun 10 13:13:10 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A011E81BC for ; Fri, 10 Jun 2011 13:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+Dp26aJIPWR for ; Fri, 10 Jun 2011 13:13:09 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAAC11E8197 for ; Fri, 10 Jun 2011 13:13:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 10 Jun 2011 16:13:07 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Jun 2011 16:13:07 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 10 Jun 2011 16:13:06 -0400 Thread-Topic: [Simple] Draft ACE: ALG terminology Thread-Index: Acwnqs/dvSO+2yEoQzOj3sgFvICO4Q== Message-ID: <54BA2106-697C-4C39-8465-DE5DD62607F3@acmepacket.com> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 20:13:10 -0000 On Jun 10, 2011, at 1:58 PM, I=F1aki Baz Castillo wrote: > Of course a B2BUA handles the application protocol at application > level, so it does not perform ALG functions. >=20 > In the other side an ALG-enabled device (as a NAT router) handles the > application protocol (i.e. SIP) at UDP/TCP level (not respecting > Internet layers) so it's not a B2BUA. >=20 > Ok, so an ALG-enabled device is not a B2BUA, and a B2BUA is not an > ALG-enabled device. And what? Where is the confusion? the draft > clearly talks about ALG devices, those which don't work at application > level (but at transport level). sessmatch/ACE mechanism is just useful > for SIP ALG enabled nodes in the network, no more. The draft uses the term "ALG", but actually is intended to address the B2BU= A case... *SIP* B2BUA's. If the SIP B2BUA wants to relay the MSRP session = traffic, legacy MSRP requires it to also be either an RFC 4976 MSRP Relay, = or an MSRP B2BUA. Sessmatch is an extension to let it do so as a transport= -layer relay instead, for the MSRP layer. =20 We can argue about whether it's useful to do that, whether there's demand, = etc. But we shouldn't be arguing about it "breaking the Internet model", b= ecause it does NOT. It changes what layer the middlebox does the relaying = at for MSRP traffic, and obviously it changes MSRP, but that's kinda the po= int. We could just as well argue about why MSRP was ever defined the way i= t is, creating such a ridiculously heavy relay architecture, but there's no= point to debating that... we're proposing an alternate way to avoid it. -hadriel From HKaplan@acmepacket.com Fri Jun 10 13:22:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA511E8093 for ; Fri, 10 Jun 2011 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKDF--3gkv+c for ; Fri, 10 Jun 2011 13:22:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3E93A11E807D for ; Fri, 10 Jun 2011 13:22:32 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Jun 2011 16:22:31 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 10 Jun 2011 16:22:31 -0400 From: Hadriel Kaplan To: Adrian Georgescu Date: Fri, 10 Jun 2011 16:22:30 -0400 Thread-Topic: [Simple] Draft ACE: ALG terminology Thread-Index: AcwnrB/uEbDw6AZ+Sa2KtXdS+lGTUQ== Message-ID: <55A0FAAE-74B3-4E72-AA7A-7595A2FAFD71@acmepacket.com> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 20:22:33 -0000 On Jun 10, 2011, at 2:04 PM, Adrian Georgescu wrote: > Hadriel, >=20 > This confusion is created by the very idea of trying to legitimate the us= e of intermediates in a by design end-to-end protocol with clients and serv= ers.=20 >=20 > The only thing sure about ALG is that they break things by design. When t= hey work, is an exception. >=20 > ALG terminology? Google for it. The word failure is associated with it in= each result. I don't rely on Google for it - I rely on Wikipedia. :) http://en.wikipedia.org/wiki/Application-level_gateway I honestly don't believe the author of the draft, nor the other proponents = for it, actually intend for sessmatch to address/aid "ALGs", as defined by = Wikipedia. I believe they don't, because the example in the draft is a 3GP= P IBCF (and previously SBCs have been used as an example as well). An IBCF= , SBC, etc. is NOT an "ALG".=20 -hadriel From christer.holmberg@ericsson.com Fri Jun 10 14:21:19 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5110D11E80C6 for ; Fri, 10 Jun 2011 14:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XmE9qg-15Ly for ; Fri, 10 Jun 2011 14:21:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1CE11E80A2 for ; Fri, 10 Jun 2011 14:21:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-57-4df28acc62b4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.B9.09774.CCA82FD4; Fri, 10 Jun 2011 23:21:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 10 Jun 2011 23:21:16 +0200 From: Christer Holmberg To: Adrian Georgescu Date: Fri, 10 Jun 2011 23:21:15 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch Thread-Index: AcwnoPRZXk6TACrOQRqgRFup4DvgFAAEbc31 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A438@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E360629@ESESSCMS0356.eemea.ericsson.se> , <84566181-E54F-4868-844F-5321F50C39ED@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A433@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 21:21:19 -0000 Hi, >> Also keep in mind that some of the "closed IP networks" are conneted to = the Internet, and/or to other networks with 4975 endpoints, so it is also i= n their interest to know how to provide backward compability. > >There is always a gateway between such environment. A B2BUA for both signa= ling and media. There is no need for other mechanism to be specified betwee= n the two. First, it is not true that there is always a B2BUA for both signaling and m= edia between the networks. It depends on many things, related to both proto= cols and trust policies. Second, the mechanism allows such gateway not to enable MSRP B2BUA function= ality in all cases. It consumes as much resources in a gateway as in any ot= her node. >>Last, the main reason behind the mechanism has been known from the beginn= ing, when the SIMPLE milestone was created. It has never been a "secret". > >Yes, but the nature of this act emerged once people started zooming on it.= And it reveals all the signs of poor design decisions that can later break= things with no one being accountable anymore. > >So if this solves a problem for a particular environment where specific a= ssumptions were made is fine but coin as such. Do not call it a generic mec= hanism for Internet usage. Based on previous discussions, the document describes assumptions on how AL= Gs behave in environments where the mechanism is used.=20 Regards, Chrsiter= From gregwel@verizon.net Fri Jun 10 15:04:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FE011E81C3 for ; Fri, 10 Jun 2011 15:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV3Hcpgfsnr5 for ; Fri, 10 Jun 2011 15:04:14 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by ietfa.amsl.com (Postfix) with ESMTP id D935F11E81A0 for ; Fri, 10 Jun 2011 15:04:04 -0700 (PDT) Received: from macintosh-3.home ([unknown] [71.163.132.117]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LML0023GHA5FRD0@vms173019.mailsrvcs.net> for Simple@ietf.org; Fri, 10 Jun 2011 17:03:42 -0500 (CDT) From: Greg Welenson Content-type: multipart/alternative; boundary=Apple-Mail-32-871223196 Date: Fri, 10 Jun 2011 18:03:41 -0400 Message-id: <729DAF7C-01C8-4F8F-9D18-8CD06D78D422@verizon.net> To: Simple@ietf.org MIME-version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Simple] unsubscribe X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:04:15 -0000 --Apple-Mail-32-871223196 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Greg Welenson glw@deixis.com HO: +1-703-425-1861 M: +1-215-378-5922 AIM: GLWelenson --Apple-Mail-32-871223196 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Greg = Welenson

HO:  +1-703-425-1861
M:   =  +1-215-378-5922
AIM: =  GLWelenson



<= /span>


= --Apple-Mail-32-871223196-- From pkyzivat@cisco.com Fri Jun 10 17:24:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EC29E8013 for ; Fri, 10 Jun 2011 17:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.074 X-Spam-Level: X-Spam-Status: No, score=-110.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDZRxXLuw8pg for ; Fri, 10 Jun 2011 17:24:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 345489E8007 for ; Fri, 10 Jun 2011 17:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2765; q=dns/txt; s=iport; t=1307751854; x=1308961454; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=sZS38o6Cy5spxVaAWLMKWHI8KB7Rdsd7CNYXFiaIPEw=; b=IUbaF3yKeW+XBBifOhfyL7AjMBFyWBjHTQIWKVM+waB+NC+A0qkKXtzs wU5JwOE2mUtaecPMpCzE3mp6+JITfHewGzdft4QQmEBRaifaHZ1T6jM3f Nd/AijkSV+Zsz4itb6iBe9nKLrG3H6nAxGsOJZzLD+wZsKzn36xny6lDL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGAIu08k2rRDoI/2dsb2JhbABSmBaON3eIcp1BnguGJASRMYRPiyU X-IronPort-AV: E=Sophos;i="4.65,350,1304294400"; d="scan'208";a="711896364" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2011 00:24:11 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5B0OBhQ023274 for ; Sat, 11 Jun 2011 00:24:11 GMT Message-ID: <4DF2B5AA.5030202@cisco.com> Date: Fri, 10 Jun 2011 20:24:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: simple@ietf.org References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> In-Reply-To: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 00:24:15 -0000 Hadriel, On 6/10/2011 1:07 PM, Hadriel Kaplan wrote: > For example, a 3GPP IBCF is not an "ALG", nor is a P-CSCF+BGF, nor is > an SBC. Instead, they are addressed hosts - the hosts to which the > SIP+MSRP UAs target their packets/connections. From a SIP perspective, > such hosts are B2BUA's not ALGs; and from an MSRP perspective such > hosts are transport relays, similar to SOCKS relays. > > This is not a small difference. True "ALGs", such as those in > routers/NATs, cannot be easily avoided by host applications, except by > obfuscating their protocol traffic (e.g., by using encryption, or > changing port numbers); and if they happen to use encryption or > authentication then the ALG function no longer works, if it was > needed. A SIP B2BUA/Proxy, on the other hand, is addressed by the host > application - the application can use TLS or IPsec to the B2BUA, or > avoid the B2BUA by addressing a different next-hop. I'd like to clarify something you seem to be saying about an SBC and/or B2BUA. (Because I think there are things calling themselves SBCs that aren't truly B2BUAs and hence aren't actually *any* well defined sip entity.) AFAIK a UA always has an address which addresses itself, that it inserts as the Contact address of sip messages it sends. And so a B2BUA also has this property, on each "side". A UA, and a B2BUA, end up receiving messages that contain their address in the R-URI and that have no Route header. (A very clear example of a B2BUA is a conference focus. All the participating devices know they are exchanging signaling with the focus.) IMO a device that receives and processes sip messages while there is still a non-empty Route header, or that receives messages that contain some address other than its own in the R-URI, is not a UA/B2BUA. It can be a proxy if it follows the 3261 rules for proxies. If it doesn't follow the rules for proxies, then it is not a well defined sip server of any sort. This includes devices that claim to be proxies except that they sometimes generate their own 200 responses to REGISTER, or sometimes originate an in-dialog BYE. AFAIK an SBC could in some cases be constructed as a B2BUA, but in many/most cases SBCs is actually an example of the less-well-defined "thing". And ISTM that ALGs as Wikipedia defines them are also this fuzzy sort of thing. I don't know if there is a meaningful distinction between an ALG and an SBC. Do you find this taxonomy valid, or do you have something different in mind? Thanks, Paul BTW, if this turns out to be an interesting discussion we should move it to some other list. But I'll leave it here for now, since that is where the context has been established. From ibc@aliax.net Fri Jun 10 22:13:45 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8559E8010 for ; Fri, 10 Jun 2011 22:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5pbTCDkin7Z for ; Fri, 10 Jun 2011 22:13:45 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D100C9E800B for ; Fri, 10 Jun 2011 22:13:44 -0700 (PDT) Received: by qwc23 with SMTP id 23so2142795qwc.31 for ; Fri, 10 Jun 2011 22:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.151 with SMTP id n23mr2116201qci.268.1307769222113; Fri, 10 Jun 2011 22:13:42 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 22:13:42 -0700 (PDT) In-Reply-To: <54BA2106-697C-4C39-8465-DE5DD62607F3@acmepacket.com> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <54BA2106-697C-4C39-8465-DE5DD62607F3@acmepacket.com> Date: Sat, 11 Jun 2011 07:13:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 05:13:45 -0000 2011/6/10 Hadriel Kaplan : > The draft uses the term "ALG", but actually is intended to address the B2= BUA case... *SIP* B2BUA's. =C2=A0If the SIP B2BUA wants to relay the MSRP s= ession traffic, legacy MSRP requires it to also be either an RFC 4976 MSRP = Relay, or an MSRP B2BUA. =C2=A0Sessmatch is an extension to let it do so as= a transport-layer relay instead, for the MSRP layer. > > We can argue about whether it's useful to do that, whether there's demand= , etc. =C2=A0But we shouldn't be arguing about it "breaking the Internet mo= del", because it does NOT. =C2=A0It changes what layer the middlebox does t= he relaying at for MSRP traffic, and obviously it changes MSRP, but that's = kinda the point. =C2=A0We could just as well argue about why MSRP was ever = defined the way it is, creating such a ridiculously heavy relay architectur= e, but there's no point to debating that... we're proposing an alternate wa= y to avoid it. Hi Hadriel, please take a look to the mail sent by Paul Kyzivat in which the definition of B2BUA is described. Main question is: should the box you name "B2BUA" receive the client's request when performing RFC 3263 resolution on request Route/RURI? or not? If not, that is not a B2BUA but a SIP "interceptor". Or maybe the scenario is like this?: alice@dom.com ----> InBoundProxy (dom.com) -----> MSRP M2BUA ------> Registrar (dom.com) ----> bob@dom.com In this case, of course, the MSRP B2BUA is a valid SIP entity an receives the request from the InBoundProxy due to local policy (i.e. for anchoring the media). --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Sat Jun 11 05:36:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B705211E8093 for ; Sat, 11 Jun 2011 05:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 9rDkSXc9Unkk for ; Sat, 11 Jun 2011 05:36:47 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2411E8072 for ; Sat, 11 Jun 2011 05:36:46 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 95E15B01AE; Sat, 11 Jun 2011 14:36:44 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 9AF37B00E6 for ; Sat, 11 Jun 2011 14:36:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: <55A0FAAE-74B3-4E72-AA7A-7595A2FAFD71@acmepacket.com> Date: Sat, 11 Jun 2011 14:36:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <55A0FAAE-74B3-4E72-AA7A-7595A2FAFD71@acmepacket.com> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 12:36:47 -0000 Hadriel, Wikipedia is a nice dictionary.=20 Please also get down to the reality where things are pasted from the = real life by many people having the problem we aim to prevent happing = again with MSRP: http://www.voip-info.org/wiki/view/Routers+SIP+ALG You are a good engineer, you must understand the things explained there. Adrian On Jun 10, 2011, at 10:22 PM, Hadriel Kaplan wrote: >=20 > On Jun 10, 2011, at 2:04 PM, Adrian Georgescu wrote: >=20 >> Hadriel, >>=20 >> This confusion is created by the very idea of trying to legitimate = the use of intermediates in a by design end-to-end protocol with clients = and servers.=20 >>=20 >> The only thing sure about ALG is that they break things by design. = When they work, is an exception. >>=20 >> ALG terminology? Google for it. The word failure is associated with = it in each result. >=20 > I don't rely on Google for it - I rely on Wikipedia. :) > http://en.wikipedia.org/wiki/Application-level_gateway >=20 > I honestly don't believe the author of the draft, nor the other = proponents for it, actually intend for sessmatch to address/aid "ALGs", = as defined by Wikipedia. I believe they don't, because the example in = the draft is a 3GPP IBCF (and previously SBCs have been used as an = example as well). An IBCF, SBC, etc. is NOT an "ALG".=20 >=20 > -hadriel >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From HKaplan@acmepacket.com Sat Jun 11 09:53:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C234E11E80F6 for ; Sat, 11 Jun 2011 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 oUHLO5CAEAjC for ; Sat, 11 Jun 2011 09:53:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6511E80F1 for ; Sat, 11 Jun 2011 09:53:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 11 Jun 2011 12:53:50 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jun 2011 12:53:50 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sat, 11 Jun 2011 12:53:48 -0400 Thread-Topic: [Simple] terminology - B2BUA / SBC / ALG / "other" Thread-Index: AcwoWCLMgGmCJt+kQX646WHaK/gcgg== Message-ID: References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <4DF2B5AA.5030202@cisco.com> In-Reply-To: <4DF2B5AA.5030202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFQ Cc: "simple@ietf.org" Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 16:53:52 -0000 Paul, The distinction I'm trying to point out is not Proxy vs. B2BUA vs. somethin= g in between, but rather that they're not "ALGs". An "ALG" is a function p= erformed transparently - i.e., by an inline device such as in a Router. Th= e SIP messages aren't addressed to it even at the IP layer, and the TCP con= nection is not actually terminated at the ALG. For example an FTP ALG: the= FTP ALG in a NAT only "works" because all packets between the two happen t= o cross it due to IP routing, and FTP is in cleartext. If IP routing chang= es to route around the ALG, or were FTP to run over TLS, the ALG would not = work. I'm fairly positive that an "ALG" is not the type of device the seesmatch d= raft is trying to support. Other comments inline... On Jun 10, 2011, at 8:24 PM, Paul Kyzivat wrote: > AFAIK a UA always has an address which addresses itself, that it inserts= =20 > as the Contact address of sip messages it sends. And so a B2BUA also has= =20 > this property, on each "side". A UA, and a B2BUA, end up receiving=20 > messages that contain their address in the R-URI and that have no Route=20 > header. (A very clear example of a B2BUA is a conference focus. All the=20 > participating devices know they are exchanging signaling with the focus.) I don't know of any normative language that says a UAS can only receive mes= sages without Route headers or with itself in the RURI. The only language = around that I know of is this in 3261: If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Luckily, the UAS side of SBCs are willing to accept requests for a lot. ;) If your UAC in cisco.com is set to use a PBX as its local outbound proxy fo= r all requests, and the UAC generates a request to hkaplan@acmepacket.com, = the request will have a RURI not belonging to the PBX when the PBX receives= it, but the PBX can still act the role of B2BUA, replacing the Contact wit= h itself, etc. Arguably a true P-CSCF is not a full B2BUA because it does not put itself i= n the Contact, but it does mess with SDP, generate BYEs, hide Via/Record-Ro= ute, etc. > IMO a device that receives and processes sip messages while there is=20 > still a non-empty Route header, or that receives messages that contain=20 > some address other than its own in the R-URI, is not a UA/B2BUA. > It can be a proxy if it follows the 3261 rules for proxies. If it=20 > doesn't follow the rules for proxies, then it is not a well defined sip=20 > server of any sort. I'm a little confused by your description of server types based on what SIP= headers/fields they receive. If I build a pure rfc3261 UAS (eg, a softpho= ne) and someone sends it a SIP request with a Route header or a RURI not id= entifying it, does that change the type of device I built? What if my UAS = has a config setting that, when enabled, makes my UAS do something with suc= h a request other than reject it? It just seems weird to describe role in = terms of what you receive, as opposed to what you do. (maybe I'm taking you= too literally) Regardless, as you've said many times, the terms aren't really system types= but rather "roles", which can change dynamically based on policies/situati= ons.=20 > AFAIK an SBC could in some cases be constructed as a B2BUA, but in=20 > many/most cases SBCs is actually an example of the less-well-defined=20 > "thing". And ISTM that ALGs as Wikipedia defines them are also this=20 > fuzzy sort of thing. I don't know if there is a meaningful distinction=20 > between an ALG and an SBC. Afaik most "SBCs" are constructed to perform the role of B2BUAs. At least = of the half dozen vendors or so I know of, which comprise most of the SBC m= arket. There are probably devices which claim to be SBCs that are inline A= LGs instead, just as there are probably devices which claim to be Proxies b= ut aren't. -hadriel From HKaplan@acmepacket.com Sat Jun 11 10:32:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E7D11E8233 for ; Sat, 11 Jun 2011 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYXfvNRXocj1 for ; Sat, 11 Jun 2011 10:32:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9033411E822F for ; Sat, 11 Jun 2011 10:32:22 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 11 Jun 2011 13:32:20 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jun 2011 13:32:20 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Sat, 11 Jun 2011 13:32:19 -0400 Thread-Topic: [Simple] Draft ACE: ALG terminology Thread-Index: AcwoXYRYhWQRjBkgStmB0teelwUVeg== Message-ID: References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <54BA2106-697C-4C39-8465-DE5DD62607F3@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFR Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 17:32:23 -0000 On Jun 11, 2011, at 1:13 AM, I=F1aki Baz Castillo wrote: > Main question is: should the box you name "B2BUA" receive the client's > request when performing RFC 3263 resolution on request Route/RURI? or > not? If not, that is not a B2BUA but a SIP "interceptor". Afaik, the type of devices sessmatch is actually trying to support are inde= ed either the host/server resolved through rfc3263 resolution, or reached/r= outed-through due to local policy on the client. For example, if alice@dom.com generates a request to bob@dom.com, the middl= ebox doing sessmatch-type msrp-relaying is either the SIP server resolved b= y rfc3263 for dom.com, or alice uses it due to local policy - for example i= ts her UA's configured "outbound-proxy" (even though it isn't a Proxy). > Or maybe the scenario is like this?: >=20 > alice@dom.com ----> InBoundProxy (dom.com) -----> MSRP M2BUA ------> > Registrar (dom.com) ----> bob@dom.com >=20 > In this case, of course, the MSRP B2BUA is a valid SIP entity an > receives the request from the InBoundProxy due to local policy (i.e. > for anchoring the media). Right, it's more likely this for SIP: alice@dom.com --> InBoundProxy --> Registrar --> OutBoundProxy --> bob@dom.= com InBoundProxy and OutBoundProxy happen to be middleboxes able to relay media= at a transport layer, by acting as SIP B2BUAs. For every "media" type oth= er than MSRP, including other TCP-based ones such as rfc4582 BFCP, such mid= dleboxes typically perform relaying at the transport layer, splicing togeth= er TCP sockets or UDP ports without modifying application payload. =20 There are some exceptions like SRTP encryption or codec transcoding, which = obviously require going higher layers... but that comes at a price - a pric= e either in terms of reduced capacity or additional hardware to handle it. = Legacy MSRP has such a cost, and any additional cost/price for MSRP is a b= ig problem. (for example additional cost is the number one cited reason car= riers say they don't do much SRTP) A secondary problem is installed base: = there are tens of thousands of such middleboxes already deployed, most of w= hich can do sessmatch without replacement... but not legacy MSRP. -hadriel From HKaplan@acmepacket.com Sat Jun 11 10:59:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C1111E80C3 for ; Sat, 11 Jun 2011 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Qz1v-EcsQi2y for ; Sat, 11 Jun 2011 10:59:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 716D011E80B5 for ; Sat, 11 Jun 2011 10:59:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 11 Jun 2011 13:59:56 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jun 2011 13:59:56 -0400 From: Hadriel Kaplan To: Adrian Georgescu Date: Sat, 11 Jun 2011 13:59:54 -0400 Thread-Topic: [Simple] Draft ACE: ALG terminology Thread-Index: AcwoYV6rFDqMhWv/SSmEM506VJ6luw== Message-ID: <60EE71E4-6B14-4F29-90E8-B854C44208CC@acmepacket.com> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <55A0FAAE-74B3-4E72-AA7A-7595A2FAFD71@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 17:59:58 -0000 On Jun 11, 2011, at 8:36 AM, Adrian Georgescu wrote: > Hadriel, >=20 > Wikipedia is a nice dictionary.=20 >=20 > Please also get down to the reality where things are pasted from the real= life by many people having the problem we aim to prevent happing again wit= h MSRP: >=20 > http://www.voip-info.org/wiki/view/Routers+SIP+ALG Right, I concur with that voip-info wiki page. I am fairly confident those are not the type of devices sessmatch is really= aimed at "helping". I doubt any of those ALG products will even support s= essmatch, let alone legacy MSRP. Sessmatch is really aimed for SIP middleb= oxes: IBCFs, P-CSCFs, SBCs, etc. But let's pretend this is about helping ALGs... router/NAT vendors are moti= vated to create ALGs to "fix" protocols that would otherwise break due to N= AT, when the protocol is popular enough to warrant it. MSRP isn't popular = enough yet, but someday it may be (I think we all hope it *will* be). So i= f that day comes, and we DON'T have sessmatch, the ALG will be modifying th= e SIP/SDP *AND* the to-address/from-address inside MSRP messages. Do we re= ally want ALGs to be parsing and modifying (and screwing up) MSRP messages = as well, or would we rather they just muck with SIP/SDP and leave MSRP alon= e? -hadriel From ben@nostrum.com Sat Jun 11 11:33:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7411E820B for ; Sat, 11 Jun 2011 11:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vCyaCAA+9Q1 for ; Sat, 11 Jun 2011 11:33:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A459E11E81F1 for ; Sat, 11 Jun 2011 11:33:05 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p5BIViHr076274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 13:31:45 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <60EE71E4-6B14-4F29-90E8-B854C44208CC@acmepacket.com> Date: Sat, 11 Jun 2011 13:31:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <73300424-3AB3-4599-A18C-868ACC778D7B@nostrum.com> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <55A0FAAE-74B3-4E72-AA7A-7595A2FAFD71@acmepacket.com> <60EE71E4-6B14-4F29-90E8-B854C44208CC@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 18:33:06 -0000 (as individual) On Jun 11, 2011, at 12:59 PM, Hadriel Kaplan wrote: >=20 > On Jun 11, 2011, at 8:36 AM, Adrian Georgescu wrote: >=20 >> Hadriel, >>=20 >> Wikipedia is a nice dictionary.=20 >>=20 >> Please also get down to the reality where things are pasted from the = real life by many people having the problem we aim to prevent happing = again with MSRP: >>=20 >> http://www.voip-info.org/wiki/view/Routers+SIP+ALG >=20 > Right, I concur with that voip-info wiki page. >=20 > I am fairly confident those are not the type of devices sessmatch is = really aimed at "helping". I doubt any of those ALG products will even = support sessmatch, let alone legacy MSRP. Sessmatch is really aimed for = SIP middleboxes: IBCFs, P-CSCFs, SBCs, etc. I concur. >=20 > But let's pretend this is about helping ALGs... router/NAT vendors are = motivated to create ALGs to "fix" protocols that would otherwise break = due to NAT, when the protocol is popular enough to warrant it. MSRP = isn't popular enough yet, but someday it may be (I think we all hope it = *will* be). So if that day comes, and we DON'T have sessmatch, the ALG = will be modifying the SIP/SDP *AND* the to-address/from-address inside = MSRP messages. Do we really want ALGs to be parsing and modifying (and = screwing up) MSRP messages as well, or would we rather they just muck = with SIP/SDP and leave MSRP alone? >=20 I'd personally rather that ALGs, particularly the ones in residential = gateways where the users either don't know how to, or just plain can't, = turn them off, stop trying to add value to SIP applications at all. They = should eave it to the endpoints to figure things out, with the various = NAT traversal technologies we've been trying to standardize. (And by = "add value", I mean "break"). But I'm not sure what that means for this draft :-) > -hadriel >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Sun Jun 12 23:14:03 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11EB11E8092 for ; Sun, 12 Jun 2011 23:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYEv7cwgMg0m for ; Sun, 12 Jun 2011 23:14:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C856111E8081 for ; Sun, 12 Jun 2011 23:14:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-01-4df5aaa2912d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.10.09774.2AAA5FD4; Mon, 13 Jun 2011 08:13:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 13 Jun 2011 08:13:54 +0200 From: Christer Holmberg To: Paul Kyzivat , "simple@ietf.org" Date: Mon, 13 Jun 2011 08:13:53 +0200 Thread-Topic: [Simple] terminology - B2BUA / SBC / ALG / "other" Thread-Index: AcwnzelOjYRRKYpLRcu0yXPX6A/qoABwiyIA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3608A8@ESESSCMS0356.eemea.ericsson.se> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <4DF2B5AA.5030202@cisco.com> In-Reply-To: <4DF2B5AA.5030202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 06:14:03 -0000 Hi, >From a SIP/SDP perspective, what is relevant for sessmatch, is that the box= we are talking about anchors media either by modifying the SDP c/m-line, o= r by enabling MSRP B2BUA functionality. Whatever else it does, when it comes e.g. to doing DNS lookups on the R-URI= , adding Record-Route headers etc is in my opinion not relevant as far as s= essmatch is concerned. So, I would suggest that we choose *a* term, and then add some definition t= ext to clarify that. Maybe "Intermediary" would be a "neutral" term? Then, if people want to have a more general and wider discussion about SBCs= , ALGs etc, I agree with Paul that such discussion should take place elsewh= ere, because it is not MSRP specific, neither is it the intention of sessma= tch to provide such description. Regards, Christer =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 11. kes=E4kuuta 2011 3:24 > To: simple@ietf.org > Subject: [Simple] terminology - B2BUA / SBC / ALG / "other" >=20 > Hadriel, >=20 > On 6/10/2011 1:07 PM, Hadriel Kaplan wrote: >=20 > > For example, a 3GPP IBCF is not an "ALG", nor is a=20 > P-CSCF+BGF, nor is=20 > > an SBC. Instead, they are addressed hosts - the hosts to which the > > SIP+MSRP UAs target their packets/connections. From a SIP=20 > > SIP+perspective, > > such hosts are B2BUA's not ALGs; and from an MSRP perspective such=20 > > hosts are transport relays, similar to SOCKS relays. > > > > This is not a small difference. True "ALGs", such as those in=20 > > routers/NATs, cannot be easily avoided by host=20 > applications, except by=20 > > obfuscating their protocol traffic (e.g., by using encryption, or=20 > > changing port numbers); and if they happen to use encryption or=20 > > authentication then the ALG function no longer works, if it was=20 > > needed. A SIP B2BUA/Proxy, on the other hand, is addressed by the=20 > > host application - the application can use TLS or IPsec to=20 > the B2BUA,=20 > > or avoid the B2BUA by addressing a different next-hop. >=20 > I'd like to clarify something you seem to be saying about an=20 > SBC and/or B2BUA. (Because I think there are things calling=20 > themselves SBCs that aren't truly B2BUAs and hence aren't=20 > actually *any* well defined sip > entity.) >=20 > AFAIK a UA always has an address which addresses itself, that=20 > it inserts as the Contact address of sip messages it sends.=20 > And so a B2BUA also has this property, on each "side". A UA,=20 > and a B2BUA, end up receiving messages that contain their=20 > address in the R-URI and that have no Route header. (A very=20 > clear example of a B2BUA is a conference focus. All the=20 > participating devices know they are exchanging signaling with=20 > the focus.) >=20 > IMO a device that receives and processes sip messages while=20 > there is still a non-empty Route header, or that receives=20 > messages that contain some address other than its own in the=20 > R-URI, is not a UA/B2BUA. > It can be a proxy if it follows the 3261 rules for proxies.=20 > If it doesn't follow the rules for proxies, then it is not a=20 > well defined sip server of any sort. >=20 > This includes devices that claim to be proxies except that=20 > they sometimes generate their own 200 responses to REGISTER,=20 > or sometimes originate an in-dialog BYE. >=20 > AFAIK an SBC could in some cases be constructed as a B2BUA,=20 > but in many/most cases SBCs is actually an example of the=20 > less-well-defined "thing". And ISTM that ALGs as Wikipedia=20 > defines them are also this fuzzy sort of thing. I don't know=20 > if there is a meaningful distinction between an ALG and an SBC. >=20 > Do you find this taxonomy valid, or do you have something=20 > different in mind? >=20 > Thanks, > Paul >=20 > BTW, if this turns out to be an interesting discussion we=20 > should move it to some other list. But I'll leave it here for=20 > now, since that is where the context has been established. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From saul@ag-projects.com Mon Jun 13 00:50:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989519E8004 for ; Mon, 13 Jun 2011 00:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0fOEioPWUAM for ; Mon, 13 Jun 2011 00:50:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0309E9E8006 for ; Mon, 13 Jun 2011 00:50:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 13184B01B7; Mon, 13 Jun 2011 09:50:03 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6C61DB017C; Mon, 13 Jun 2011 09:49:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3608A8@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 13 Jun 2011 09:49:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <4DF2B5AA.5030202@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3608A8@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 07:50:07 -0000 Hi, On Jun 13, 2011, at 8:13 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > =46rom a SIP/SDP perspective, what is relevant for sessmatch, is that = the box we are talking about anchors media either by modifying the SDP = c/m-line, or by enabling MSRP B2BUA functionality. >=20 > Whatever else it does, when it comes e.g. to doing DNS lookups on the = R-URI, adding Record-Route headers etc is in my opinion not relevant as = far as sessmatch is concerned. >=20 I agree. B2BUA functionality could be used for the SIP part but this = specification could be used to anchor MSRP media and fix NAT issues (for = MSRP). > So, I would suggest that we choose *a* term, and then add some = definition text to clarify that. Maybe "Intermediary" would be a = "neutral" term? >=20 I personally don't find the term ALG confusing, but I understand the = points that have been risen. Intermediary could work. > Then, if people want to have a more general and wider discussion about = SBCs, ALGs etc, I agree with Paul that such discussion should take place = elsewhere, because it is not MSRP specific, neither is it the intention = of sessmatch to provide such description. >=20 Agreed. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Jun 13 09:09:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964B511E813E for ; Mon, 13 Jun 2011 09:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKGGCbkrXfzE for ; Mon, 13 Jun 2011 09:09:04 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 015A411E8137 for ; Mon, 13 Jun 2011 09:09:03 -0700 (PDT) Received: by qwc23 with SMTP id 23so3019328qwc.31 for ; Mon, 13 Jun 2011 09:09:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.151 with SMTP id n23mr3784864qci.268.1307981343072; Mon, 13 Jun 2011 09:09:03 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Mon, 13 Jun 2011 09:09:02 -0700 (PDT) In-Reply-To: References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <54BA2106-697C-4C39-8465-DE5DD62607F3@acmepacket.com> Date: Mon, 13 Jun 2011 18:09:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Draft ACE: ALG terminology X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:09:04 -0000 2011/6/11 Hadriel Kaplan : > InBoundProxy and OutBoundProxy happen to be middleboxes able to relay med= ia at a transport layer, by acting as SIP B2BUAs. =C2=A0For every "media" t= ype other than MSRP, including other TCP-based ones such as rfc4582 BFCP, s= uch middleboxes typically perform relaying at the transport layer, splicing= together TCP sockets or UDP ports without modifying application payload. Thanks for the explanation. So then, if those SBC are real/valid SIP nodes within the path, why does SIP over TLS makes media anchoring imposible for them? This is, alice speaks SIP over TLS with the SBC, and the SBC with bob, so the SBC *can* read/modify the SDP in order to anchor media. But in all these threads, it was assumed that SIP over TLS made imposible the "work" of ALG boxes. I do know it's imposible for real ALG boxes (routers which don't speak SIP but just inspect plain text messages and perform painful substitutions) to anchor media when SIP goes through TLS, but in an SBC this should not be a problem, so are all of us speaking about SBC's? Or do I miss something? > There are some exceptions like SRTP encryption or codec transcoding, whic= h obviously require going higher layers... Why SRTP is a problem? The encoding/decoding is made by real endpoints, rig= ht? Regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@cisco.com Mon Jun 13 09:22:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5821921F84CD for ; Mon, 13 Jun 2011 09:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmDT-iJUP9LY for ; Mon, 13 Jun 2011 09:22:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85621F84C9 for ; Mon, 13 Jun 2011 09:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4435; q=dns/txt; s=iport; t=1307982176; x=1309191776; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dDG1AWiHSAx1bJMMYM/5YLrVtXnvFu/CQLI/TQXujyM=; b=VfxN2KfSaczGpr/XSljWzlOFawWAQ2C/Vxjgxf8OltqCIkk8dZKuWB6H Gqdko4ahTdQ1/OeA2SDVL+8gZp5D3yNQbfgIVL66np6YkBM8XZAwET29h ICtoetBj1DSCuq33e4eUVm6X3v5+xwuhGtvmUhpAxR7jomu3wsKHIwrRi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIY49k2rRDoH/2dsb2JhbABEDqY6d4hyoXydVYMZgwsEkTSET4sq X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="712641087" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2011 16:22:56 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5DGMt2T013315; Mon, 13 Jun 2011 16:22:55 GMT Message-ID: <4DF6395F.7020705@cisco.com> Date: Mon, 13 Jun 2011 12:22:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hadriel Kaplan References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <4DF2B5AA.5030202@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:22:59 -0000 On 6/11/2011 12:53 PM, Hadriel Kaplan wrote: > > Paul, > The distinction I'm trying to point out is not Proxy vs. B2BUA vs. something in between, but rather that they're not "ALGs". An "ALG" is a function performed transparently - i.e., by an inline device such as in a Router. The SIP messages aren't addressed to it even at the IP layer, and the TCP connection is not actually terminated at the ALG. For example an FTP ALG: the FTP ALG in a NAT only "works" because all packets between the two happen to cross it due to IP routing, and FTP is in cleartext. If IP routing changes to route around the ALG, or were FTP to run over TLS, the ALG would not work. > > I'm fairly positive that an "ALG" is not the type of device the seesmatch draft is trying to support. I haven't been following the sessmatch discussion very closely, so I guess I don't know about that. (W as really trying to shanghai your comment to discuss something else. :-) > Other comments inline... I'd like to take that discussion out of the simple mailing list. Perhaps it belongs in sipcore, but I think its still to half baked for that, so instead I'm going to continue on sip-implementors. Thanks, Paul > On Jun 10, 2011, at 8:24 PM, Paul Kyzivat wrote: > >> AFAIK a UA always has an address which addresses itself, that it inserts >> as the Contact address of sip messages it sends. And so a B2BUA also has >> this property, on each "side". A UA, and a B2BUA, end up receiving >> messages that contain their address in the R-URI and that have no Route >> header. (A very clear example of a B2BUA is a conference focus. All the >> participating devices know they are exchanging signaling with the focus.) > > I don't know of any normative language that says a UAS can only receive messages without Route headers or with itself in the RURI. The only language around that I know of is this in 3261: > If the Request-URI does not identify an address that the > UAS is willing to accept requests for, it SHOULD reject the request > with a 404 (Not Found) response. > Luckily, the UAS side of SBCs are willing to accept requests for a lot. ;) > > If your UAC in cisco.com is set to use a PBX as its local outbound proxy for all requests, and the UAC generates a request to hkaplan@acmepacket.com, the request will have a RURI not belonging to the PBX when the PBX receives it, but the PBX can still act the role of B2BUA, replacing the Contact with itself, etc. > > Arguably a true P-CSCF is not a full B2BUA because it does not put itself in the Contact, but it does mess with SDP, generate BYEs, hide Via/Record-Route, etc. > > >> IMO a device that receives and processes sip messages while there is >> still a non-empty Route header, or that receives messages that contain >> some address other than its own in the R-URI, is not a UA/B2BUA. >> It can be a proxy if it follows the 3261 rules for proxies. If it >> doesn't follow the rules for proxies, then it is not a well defined sip >> server of any sort. > > I'm a little confused by your description of server types based on what SIP headers/fields they receive. If I build a pure rfc3261 UAS (eg, a softphone) and someone sends it a SIP request with a Route header or a RURI not identifying it, does that change the type of device I built? What if my UAS has a config setting that, when enabled, makes my UAS do something with such a request other than reject it? It just seems weird to describe role in terms of what you receive, as opposed to what you do. (maybe I'm taking you too literally) > > Regardless, as you've said many times, the terms aren't really system types but rather "roles", which can change dynamically based on policies/situations. > > >> AFAIK an SBC could in some cases be constructed as a B2BUA, but in >> many/most cases SBCs is actually an example of the less-well-defined >> "thing". And ISTM that ALGs as Wikipedia defines them are also this >> fuzzy sort of thing. I don't know if there is a meaningful distinction >> between an ALG and an SBC. > > Afaik most "SBCs" are constructed to perform the role of B2BUAs. At least of the half dozen vendors or so I know of, which comprise most of the SBC market. There are probably devices which claim to be SBCs that are inline ALGs instead, just as there are probably devices which claim to be Proxies but aren't. > > -hadriel > > > From saul@ag-projects.com Tue Jun 14 00:16:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6776A11E8105 for ; Tue, 14 Jun 2011 00:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlp-TZ5Zf3ep for ; Tue, 14 Jun 2011 00:16:57 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0DE11E8070 for ; Tue, 14 Jun 2011 00:16:56 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 41EEFB01C1; Tue, 14 Jun 2011 09:16:54 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 82BECB00E6; Tue, 14 Jun 2011 09:16:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Jun 2011 09:16:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54BCB20F-FAFB-4EF4-B44D-3940B2E80C5B@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:16:58 -0000 Hi, On Jun 9, 2011, at 5:31 PM, Christer Holmberg wrote: > =20 > Hi, > =20 > In order for people to easier understand, and get a full picture of = the new alternative sessmatch mechanism, now known as ACE, we have = submitted a new version (-12) of the draft-ietf-simple-msrp-sessmatch = (for administrative reasons the draft name still contains sessmatch), = which tries to describe it. > =20 > Happy reading :) > =20 Some comments after a first read: Section 1, paragrapth 2: "that anchor and controls" -> "that anchor and = control" Section 1, paragraph 3: Instead of saying that MSRP does not work I = think it would be more correct to say that the MSRP media can't be = anchored. Section 1, paragraph 3: "topmost SDP a=3Dpath", mentioning that the = a=3Dpath may come in form of a single line and that in such case the = leftmost URI applies would be nice. Section 1, paragraph 4: "that in certain cases", now it's in most cases, = right? Section 1, paragraph 4: "ALGs that anchor the MSRP connection", what = about: "ALGs that want to anchor the MSRP media" Section 1, paragraph 4: "can use the SDP c/m line" -> "will use the SDP = c/m line" I'm a bit concerned about the use of the a=3Dsetup attribute here. If = Alice calls Bob (both supporting ACE), will the ALG modify the setup = attribute? Also, Section 4.2 says that if a relay is being used, = a=3Dsetup: passive MUST be used, which is forbidden by RFC6135 (sec = 4.2.2). Thus, if a non-ACE endpoint receives such a request it will = reject it. AFAIS this was added to avoid using B2BUA mode, but it = doesn't really help. The best-effort solution would be to use 'actpass' = instead and hope for the other end to become active. Else, I guess a = mention about this change to RFC6135 needs to be added somewhere. Section 5, paragraph 1: "networks where ALGs are present", I'd like to = see a mention to the fact that those ALGs want to anchor media. Those are my 2 cents for now. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Tue Jun 14 02:09:13 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ABC9E8019 for ; Tue, 14 Jun 2011 02:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDbGUOlOISK2 for ; Tue, 14 Jun 2011 02:09:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0917F9E800C for ; Tue, 14 Jun 2011 02:09:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fd-4df725370756 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 83.CD.20773.73527FD4; Tue, 14 Jun 2011 11:09:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 14 Jun 2011 11:09:11 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Tue, 14 Jun 2011 11:09:10 +0200 Thread-Topic: [Simple] Draft new version: ACE - the extension previously known as sessmatch - Saul's comments (140611) Thread-Index: AcwqYwsV5G+hMjWlSIGagYwZwmT4PwAAGwbA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1106@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E36016B@ESESSCMS0356.eemea.ericsson.se> <54BCB20F-FAFB-4EF4-B44D-3940B2E80C5B@ag-projects.com> In-Reply-To: <54BCB20F-FAFB-4EF4-B44D-3940B2E80C5B@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch - Saul's comments (140611) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 09:09:13 -0000 Hi Saul,=20 Comments inline. --------- >Some comments after a first read: >=20 >Section 1, paragrapth 2: "that anchor and controls" -> "that=20 >anchor and control" I'll fix as suggested. --------- >Section 1, paragraph 3: Instead of saying that MSRP does not=20 >work I think it would be more correct to say that the MSRP=20 >media can't be anchored. I'll fix as suggested. --------- >Section 1, paragraph 3: "topmost SDP a=3Dpath", mentioning that=20 >the a=3Dpath may come in form of a single line and that in such=20 >case the leftmost URI applies would be nice. I am not sure we normally say that, because it's according to the ABNF rule= s. --------- >Section 1, paragraph 4: "that in certain cases", now it's in=20 >most cases, right? Yes. I'll fix that. --------- >Section 1, paragraph 4: "ALGs that anchor the MSRP=20 >connection", what about: "ALGs that want to anchor the MSRP media" I'll fix as suggested. --------- >Section 1, paragraph 4: "can use the SDP c/m line" -> "will=20 >use the SDP c/m line" I'll fix as suggested. --------- =20 >I'm a bit concerned about the use of the a=3Dsetup attribute=20 >here. If Alice calls Bob (both supporting ACE), will the ALG=20 >modify the setup attribute? Also, Section 4.2 says that if a=20 >relay is being used, a=3Dsetup: passive MUST be used, which is=20 >forbidden by RFC6135 (sec 4.2.2). Thus, if a non-ACE endpoint=20 >receives such a request it will reject it. AFAIS this was=20 >added to avoid using B2BUA mode, but it doesn't really help.=20 >The best-effort solution would be to use 'actpass' instead=20 >and hope for the other end to become active. Else, I guess a=20 >mention about this change to RFC6135 needs to be added somewhere. Good point. Eventhough I don't think it really matters, since the draft defines a fallb= ack mechanism, the intention is not to break RFC 6135, so I'll change it to= "actpass". ---------=20 >Section 5, paragraph 1: "networks where ALGs are present",=20 >I'd like to see a mention to the fact that those ALGs want to=20 >anchor media. I'll fix that.=20 --------- Thank You for the comments! :) Regards, Christer From christer.holmberg@ericsson.com Tue Jun 14 05:27:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393BA11E80B5 for ; Tue, 14 Jun 2011 05:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h4u4SmHJtd6 for ; Tue, 14 Jun 2011 05:27:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EDFAD11E80A8 for ; Tue, 14 Jun 2011 05:27:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d4-4df753c44daa Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F0.3D.09774.4C357FD4; Tue, 14 Jun 2011 14:27:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 14 Jun 2011 14:27:44 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Tue, 14 Jun 2011 14:27:43 +0200 Thread-Topic: Sessmatch: New name, abstract and applicability proposal Thread-Index: AcwqjnV3owO9f1DsQpmPDwdPOiEfmA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A131DESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Sessmatch: New name, abstract and applicability proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:27:51 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A131DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is some suggested name/abstract/applicability text. Note that I have kept the name of the ALG/SBC/B2BUA/whatever-terminology-we= -will-use open for now. I have asked Hadriel to provide some definition tex= t regarding that. ----------- Name: "Connection Establishment for Media Anchoring (CAMA) for the Message Ses= sion Relay Protocol (MSRP)" I think that name is short and descriptive. The applicability (see below) s= ection will then talk about in what types of networks etc the extension is = applicable. ----------- For the Abstract section, I suggest the following modified text: "Abstract This document defines an MSRP extension, Connection Establishment for Me= dia Anchoring (CAMA). Support of the extension is optional. MSRP endpoints c= an implement the extension in order to allow MSRP communication in networks where anchor the MSRP connection, without the need for the to enable MSRP B2BUA functionality. The document also defines a Session Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that can be used by MSRP endpoints to indicate support of the CAMA extension." ----------- For the Applicability section, I suggest the following modified text: "3. Applicability statement This document defines an MSRP extension, Connection Establishment for Me= dia Anchoring (CAMA). Support of the extension is optional. MSRP endpoints c= an implement the extension in order to allow MSRP communication in networks where anchor the MSRP connection, without the need for the to enable MSRP B2BUA functionality. The document also defines a Session Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that can be used by MSRP endpoints to indicate support of the CAMA extension. The CAMA extension is primarily intended for MSRP endpoints that operate in networks in which that want to anchor media connections are deployed, without the need for those to enable MSRP B2BUA functionality. An example of such network is the IP Multimedia Subsystem (IMS) defined by the 3rd Generation Partnership Project (3GPP). The extension is also useful for other MSRP endpoints operating in other networks, but that communicate with MSRP endpoints in networks with such , unless there is a gateway between the networks that by default always enable MSRP B2BUA functionality." --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A131DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
Hi,
 
Below is some suggest= ed name/abstract/applicability text.
 
Note that I have kept= the name of the ALG/SBC/B2BUA/whatever-terminology-we-will-use open for no= w. I have asked Hadriel to provide some definition text regarding that.
 
-----------
 
 
Name:
 
   "Co= nnection Establishment for Media Anchoring (CAMA) for the Message Session R= elay Protocol (MSRP)"
 
 
I think that name is = short and descriptive. The applicability (see below) section will then talk= about in what types of networks etc the extension is applicable.
 
 
-----------
 
 
For the Abstract sect= ion, I suggest the following modified text:
 
 
"Abstract=
 
   This doc= ument defines an MSRP extension, Connection Establishment for Media =
   Anchorin= g (CAMA). Support of the extension is optional. MSRP endpoints can <= /div>
   implemen= t the extension in order to allow MSRP communication in
   networks= where <insert ALGs/SBCs/B2BUAs/whatever word we will use>
   anchor t= he MSRP connection, without the need for the <ALGs/SBCs/B2BUAs>
   to enabl= e MSRP B2BUA functionality.  The document also defines a Session
   Descript= ion Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that can
   be used = by MSRP endpoints to indicate support of the CAMA extension."
 
 
-----------
 
 
For the Applicability= section, I suggest the following modified text:
 
 
"3.  Applic= ability statement
 
   This doc= ument defines an MSRP extension, Connection Establishment for Media =
   Anchorin= g (CAMA). Support of the extension is optional. MSRP endpoints can <= /div>
   implemen= t the extension in order to allow MSRP communication in
   networks= where <insert ALGs/SBCs/B2BUAs/whatever word we will use>
   anchor t= he MSRP connection, without the need for the <ALGs/SBCs/B2BUAs>
   to enabl= e MSRP B2BUA functionality.  The document also defines a Session
   Descript= ion Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that can
   be used = by MSRP endpoints to indicate support of the CAMA extension.
 
   The CAMA= extension is primarily intended for MSRP endpoints
   that ope= rate in networks in which <ALGs/SBCs/B2BUAs> that want to
   anchor m= edia connections are deployed, without the need for those <ALGs/SBCs/B2B= UAs>
   to enabl= e MSRP B2BUA functionality. An example of such network is the IP
   Multimed= ia Subsystem (IMS) defined by the 3rd Generation Partnership
   Project = (3GPP). The extension is also useful for other MSRP endpoints
   operatin= g in other networks, but that communicate with MSRP endpoints in
   networks= with such <ALGs/SBCs/B2BUAs>, unless there is a gateway between
   the netw= orks that by default always enable MSRP B2BUA functionality."
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A131DESESSCMS0356e_-- From ibc@aliax.net Tue Jun 14 05:31:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C183F9E8008 for ; Tue, 14 Jun 2011 05:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqZZMRe65ont for ; Tue, 14 Jun 2011 05:31:20 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B758228014 for ; Tue, 14 Jun 2011 05:31:20 -0700 (PDT) Received: by qwc23 with SMTP id 23so3554015qwc.31 for ; Tue, 14 Jun 2011 05:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.115.21 with SMTP id g21mr4760708qcq.230.1308054679415; Tue, 14 Jun 2011 05:31:19 -0700 (PDT) Received: by 10.229.189.209 with HTTP; Tue, 14 Jun 2011 05:31:19 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Jun 2011 14:31:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch: New name, abstract and applicability proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:31:21 -0000 2011/6/14 Christer Holmberg : > Name: > > =C2=A0=C2=A0 "Connection Establishment for Media Anchoring (CAMA) for the= Message > Session Relay Protocol (MSRP)" Hi, wouldn't be "CEMA"? I've seen however that you use CAMA various times in your mail. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jun 14 05:33:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687259E8005 for ; Tue, 14 Jun 2011 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8yzdfWw0JcU for ; Tue, 14 Jun 2011 05:33:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1C111E8123 for ; Tue, 14 Jun 2011 05:33:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-54-4df755315ab0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4A.85.20773.13557FD4; Tue, 14 Jun 2011 14:33:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 14 Jun 2011 14:33:53 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 14 Jun 2011 14:33:52 +0200 Thread-Topic: [Simple] Sessmatch: New name, abstract and applicability proposal Thread-Index: AcwqjveNZW9wxx3RRMKakFuFcXW22gAAFTeQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1331@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch: New name, abstract and applicability proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:33:57 -0000 Correct. CEMA. Regards, Christer=20 > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 > Sent: 14. kes=E4kuuta 2011 15:31 > To: Christer Holmberg > Cc: simple@ietf.org > Subject: Re: [Simple] Sessmatch: New name, abstract and=20 > applicability proposal >=20 > 2011/6/14 Christer Holmberg : > > Name: > > > > =A0=A0 "Connection Establishment for Media Anchoring (CAMA) for the=20 > > Message Session Relay Protocol (MSRP)" >=20 > Hi, wouldn't be "CEMA"? I've seen however that you use CAMA=20 > various times in your mail. >=20 > -- > I=F1aki Baz Castillo > > = From ag@ag-projects.com Tue Jun 14 05:54:48 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1656E21F84D9 for ; Tue, 14 Jun 2011 05:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, 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 r46R+xvuqT6H for ; Tue, 14 Jun 2011 05:54:47 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E991521F84D7 for ; Tue, 14 Jun 2011 05:54:46 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8D494B01B6; Tue, 14 Jun 2011 14:54:45 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 1AB4EB017C; Tue, 14 Jun 2011 14:54:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--963598002 From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Jun 2011 14:54:43 +0200 Message-Id: <4FD51A74-4E3D-4EDE-91D1-A3A21A8937DD@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch: New name, abstract and applicability proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:54:48 -0000 --Apple-Mail-8--963598002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christer, The name, abstract and applicability clearly indicates the purpose and = context of this new MSRP extension. It looks very good! Best regards, Adrian P.S. This comment is not suppose to address any technical issues (if any = at all present in the draft), but just the name, abstract and = applicability. On Jun 14, 2011, at 2:27 PM, Christer Holmberg wrote: > =20 > =20 > Hi, > =20 > Below is some suggested name/abstract/applicability text. > =20 > Note that I have kept the name of the = ALG/SBC/B2BUA/whatever-terminology-we-will-use open for now. I have = asked Hadriel to provide some definition text regarding that. > =20 > ----------- > =20 > =20 > Name: > =20 > "Connection Establishment for Media Anchoring (CAMA) for the = Message Session Relay Protocol (MSRP)" > =20 > =20 > I think that name is short and descriptive. The applicability (see = below) section will then talk about in what types of networks etc the = extension is applicable. > =20 > =20 > ----------- > =20 > =20 > For the Abstract section, I suggest the following modified text: > =20 > =20 > "Abstract > =20 > This document defines an MSRP extension, Connection Establishment = for Media > Anchoring (CAMA). Support of the extension is optional. MSRP = endpoints can > implement the extension in order to allow MSRP communication in > networks where > anchor the MSRP connection, without the need for the = > to enable MSRP B2BUA functionality. The document also defines a = Session > Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that = can > be used by MSRP endpoints to indicate support of the CAMA = extension." > =20 > =20 > ----------- > =20 > =20 > For the Applicability section, I suggest the following modified text: > =20 > =20 > "3. Applicability statement > =20 > This document defines an MSRP extension, Connection Establishment = for Media > Anchoring (CAMA). Support of the extension is optional. MSRP = endpoints can > implement the extension in order to allow MSRP communication in > networks where > anchor the MSRP connection, without the need for the = > to enable MSRP B2BUA functionality. The document also defines a = Session > Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that = can > be used by MSRP endpoints to indicate support of the CAMA = extension. > =20 > The CAMA extension is primarily intended for MSRP endpoints > that operate in networks in which that want to > anchor media connections are deployed, without the need for those = > to enable MSRP B2BUA functionality. An example of such network is = the IP > Multimedia Subsystem (IMS) defined by the 3rd Generation = Partnership > Project (3GPP). The extension is also useful for other MSRP = endpoints > operating in other networks, but that communicate with MSRP = endpoints in > networks with such , unless there is a gateway = between > the networks that by default always enable MSRP B2BUA = functionality." > =20 > =20 > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-8--963598002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Christer,

The = name, abstract and applicability clearly indicates the purpose and = context of this new MSRP extension.

It looks = very good!

Best = regards,
Adrian

P.S. This comment is = not suppose to address any technical issues (if any at all present in = the draft), but just the name, abstract and = applicability.

On Jun 14, 2011, at 2:27 PM, = Christer Holmberg wrote:

 
 
Hi,
 
Below is some suggested = name/abstract/applicability text.
 
Note that I have kept the name of the = ALG/SBC/B2BUA/whatever-terminology-we-will-use open for now. I have = asked Hadriel to provide some definition text regarding = that.
 
-----------
 
 
Name:
 
   "Connection Establishment for Media = Anchoring (CAMA) for the Message Session Relay Protocol = (MSRP)"
 
 
I think that name is short and descriptive. The applicability = (see below) section will then talk about in what types of networks etc = the extension is applicable.
 
 
-----------
 
 
For the Abstract section, I suggest the = following modified text:
 
 
"Abstract
 
   This document defines an MSRP = extension, Connection Establishment for Media
   Anchoring = (CAMA). Support of the extension is optional. MSRP endpoints = can
   implement the extension in order to allow MSRP = communication in
   networks where <insert = ALGs/SBCs/B2BUAs/whatever word we will use>
   anchor the MSRP = connection, without the need for the = <ALGs/SBCs/B2BUAs>
   to enable MSRP B2BUA = functionality.  The document also defines a = Session
   Description Protocol (SDP) [RFC4566] attribute, = a=3Dmsrp-cama, that can
   be used by MSRP endpoints to indicate = support of the CAMA extension."
 
 
-----------
 
 
For the Applicability = section, I suggest the following modified text:
 
 
"3.  Applicability = statement
 
   This document defines an MSRP extension, = Connection Establishment for Media
   Anchoring (CAMA). Support of the = extension is optional. MSRP endpoints can
   implement the = extension in order to allow MSRP communication in
   networks where = <insert ALGs/SBCs/B2BUAs/whatever word we will = use>
   anchor the MSRP connection, without the need for = the <ALGs/SBCs/B2BUAs>
   to enable MSRP B2BUA = functionality.  The document also defines a = Session
   Description Protocol (SDP) [RFC4566] attribute, = a=3Dmsrp-cama, that can
   be used by MSRP endpoints to indicate = support of the CAMA extension.
 
   The CAMA extension is primarily = intended for MSRP endpoints
   that operate in networks in which = <ALGs/SBCs/B2BUAs> that want to
   anchor media = connections are deployed, without the need for those = <ALGs/SBCs/B2BUAs>
   to enable MSRP B2BUA functionality. = An example of such network is the IP
   Multimedia = Subsystem (IMS) defined by the 3rd Generation = Partnership
   Project (3GPP). The extension is also useful for = other MSRP endpoints
   operating in other networks, but that = communicate with MSRP endpoints in
   networks with such = <ALGs/SBCs/B2BUAs>, unless there is a gateway = between
   the networks that by default always enable MSRP = B2BUA functionality."
 
 
 
_____________________________________= __________
Simple mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= --Apple-Mail-8--963598002-- From saul@ag-projects.com Tue Jun 14 06:53:09 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A84511E813D for ; Tue, 14 Jun 2011 06:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH38w02Ci4qk for ; Tue, 14 Jun 2011 06:53:08 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8807311E813A for ; Tue, 14 Jun 2011 06:53:08 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8968CB01C1; Tue, 14 Jun 2011 15:53:07 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5C369B01B1; Tue, 14 Jun 2011 15:53:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Jun 2011 15:53:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C9B06D4-131B-4755-8F4B-6A3F9D2C85E7@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch: New name, abstract and applicability proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 13:53:09 -0000 Hi, On Jun 14, 2011, at 2:27 PM, Christer Holmberg wrote: > =20 > =20 > Hi, > =20 > Below is some suggested name/abstract/applicability text. > =20 > Note that I have kept the name of the = ALG/SBC/B2BUA/whatever-terminology-we-will-use open for now. I have = asked Hadriel to provide some definition text regarding that. > =20 > ----------- > =20 > =20 > Name: > =20 > "Connection Establishment for Media Anchoring (CAMA) for the = Message Session Relay Protocol (MSRP)" > =20 > =20 > I think that name is short and descriptive. The applicability (see = below) section will then talk about in what types of networks etc the = extension is applicable. > =20 > =20 > ----------- > =20 > =20 > For the Abstract section, I suggest the following modified text: > =20 > =20 > "Abstract > =20 > This document defines an MSRP extension, Connection Establishment = for Media > Anchoring (CAMA). Support of the extension is optional. MSRP = endpoints can > implement the extension in order to allow MSRP communication in > networks where > anchor the MSRP connection, without the need for the = > to enable MSRP B2BUA functionality. The document also defines a = Session > Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that = can > be used by MSRP endpoints to indicate support of the CAMA = extension." > =20 > =20 In the sentence where it says "... without the need for the XXX to = enable MSRP B2BUA ..." I'd add something like "on all scenarios" or = "always" in the end. > ----------- > =20 > =20 > For the Applicability section, I suggest the following modified text: > =20 > =20 > "3. Applicability statement > =20 > This document defines an MSRP extension, Connection Establishment = for Media > Anchoring (CAMA). Support of the extension is optional. MSRP = endpoints can > implement the extension in order to allow MSRP communication in > networks where > anchor the MSRP connection, without the need for the = > to enable MSRP B2BUA functionality. The document also defines a = Session > Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that = can > be used by MSRP endpoints to indicate support of the CAMA = extension. > =20 > The CAMA extension is primarily intended for MSRP endpoints > that operate in networks in which that want to > anchor media connections are deployed, without the need for those = > to enable MSRP B2BUA functionality. An example of such network is = the IP > Multimedia Subsystem (IMS) defined by the 3rd Generation = Partnership > Project (3GPP). The extension is also useful for other MSRP = endpoints > operating in other networks, but that communicate with MSRP = endpoints in > networks with such , unless there is a gateway = between > the networks that by default always enable MSRP B2BUA = functionality." > =20 > =20 I really like these new texts, they look really descriptive and nice :-) Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Tue Jun 14 12:34:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73751F0C59 for ; Tue, 14 Jun 2011 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2yCXB4-+9Jl for ; Tue, 14 Jun 2011 12:34:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DDAED1F0C3F for ; Tue, 14 Jun 2011 12:34:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-6d-4df7b7e09a86 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 71.D0.20773.0E7B7FD4; Tue, 14 Jun 2011 21:34:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 14 Jun 2011 21:34:54 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Tue, 14 Jun 2011 21:31:45 +0200 Thread-Topic: [Simple] Sessmatch: New name, abstract and applicability proposal Thread-Index: AcwqmnKuqP9MgmrmTJCc10/Qer9GGQALz+zO Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A443@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A131D@ESESSCMS0356.eemea.ericsson.se>, <5C9B06D4-131B-4755-8F4B-6A3F9D2C85E7@ag-projects.com> In-Reply-To: <5C9B06D4-131B-4755-8F4B-6A3F9D2C85E7@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch: New name, abstract and applicability proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 19:34:59 -0000 Hi, >> For the Abstract section, I suggest the following modified text: >> >> >> "Abstract >> >> This document defines an MSRP extension, Connection Establishment for= Media >> Anchoring (CAMA). Support of the extension is optional. MSRP endpoint= s can >> implement the extension in order to allow MSRP communication in >> networks where >> anchor the MSRP connection, without the need for the >> to enable MSRP B2BUA functionality. The document also defines a Sess= ion >> Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cama, that c= an >> be used by MSRP endpoints to indicate support of the CAMA extension." >> > > >In the sentence where it says "... without the need for the XXX to enable = MSRP B2BUA ..." I'd add something like "on all scenarios" or "always" in th= e end. I guess I could say "in most cases", in order to have alligned wording with= the change you earlier proposed in section 1/paragraph 4. Regards, Christer= From christer.holmberg@ericsson.com Wed Jun 15 04:53:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F231F0CA0 for ; Wed, 15 Jun 2011 04:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-0-CbPOkHKH for ; Wed, 15 Jun 2011 04:53:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BA0431F0C9A for ; Wed, 15 Jun 2011 04:53:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0d-4df89d2ec47e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.24.20773.E2D98FD4; Wed, 15 Jun 2011 13:53:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 13:53:17 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Wed, 15 Jun 2011 13:53:17 +0200 Thread-Topic: CEMA: ALG definition proposal Thread-Index: AcwrUtBiquHUgAmdR/+q8XUrBsp/0w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A197FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 11:53:20 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A197FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In order to avoid confusion, missunderstandings, and general discussions ab= out what an ALG does and doesn't do, I have put togheter some definition te= xt which explains what we mean by ALG within the scope of the sessmatch dra= ft. ------------ ALG: Within the scope of this document, ALG refers to a network SIP devi= ce that modifies SDP media address:port information in order to steer (anchor) media flows described in the SDP, including TCP con= nections used for MSRP communication, through a media proxy function controlled by the SIP device. Other SIP related functi= ons (e.g. related to routing, modification of SIP information etc) performed by the SIP device, and whether it device creates separate SI= P dialogs in each direction or not, is outside the scope of the definition. Section 5 describes assumptions regarding how the ALG ha= ndles MSRP in order to support the extension defined in this document. ------------ Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A197FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
In order to avoid confusion, missunderstandings, and = general discussions about what an ALG does and doesn't do, I have put toghe= ter some definition text which explains what we mean by ALG within the scop= e of the sessmatch draft.
 
------------
 
ALG:    Within the scope of this docum= ent, ALG refers to a network SIP device that modifies SDP media address:por= t information in
order to steer (anchor) media flows described in the = SDP, including TCP connections used for MSRP communication, through a
media proxy function controlled by the SIP device. Ot= her SIP related functions (e.g. related to routing, modification of SIP inf= ormation
etc) performed by the SIP device, and whether it devi= ce creates separate SIP dialogs in each direction or not, is outside the sc= ope
of the definition. Section 5 describes assumptions re= garding how the ALG handles MSRP in order to support the extension defined =
in this document.
 
------------
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A197FESESSCMS0356e_-- From ibc@aliax.net Wed Jun 15 05:23:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E74C11E80F1 for ; Wed, 15 Jun 2011 05:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC1ZFQkpCdzZ for ; Wed, 15 Jun 2011 05:23:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1C3311E80F0 for ; Wed, 15 Jun 2011 05:23:32 -0700 (PDT) Received: by qwc23 with SMTP id 23so256951qwc.31 for ; Wed, 15 Jun 2011 05:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.17 with SMTP id q17mr333650qca.154.1308140610639; Wed, 15 Jun 2011 05:23:30 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 05:23:30 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 14:23:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 12:23:33 -0000 2011/6/15 Christer Holmberg : > In order to avoid confusion, missunderstandings, and general discussions > about what an ALG does and doesn't do, I have put togheter some definitio= n > text which explains what we mean by ALG within the scope of the sessmatch > draft. > > ------------ > > ALG:=C2=A0=C2=A0=C2=A0 Within the scope of this document, ALG refers to a= network SIP > device that modifies SDP media address:port information in > order to steer (anchor) media flows described in the SDP, including TCP > connections used for MSRP communication, through a > media proxy function controlled by the SIP device. Other SIP related > functions (e.g. related to routing, modification of SIP information > etc) performed by the SIP device, and whether it device creates separate = SIP > dialogs in each direction or not, is outside the scope > of the definition. Section 5 describes assumptions regarding how the ALG > handles MSRP in order to support the extension defined > in this document. > > ------------ Hi Christer, this text is nice, but does it mean that this draft will not cover those layer 3 devices (i.e. NAT routers) which perform ugly SIP inspection/modification? (this is what I call "SIP ALG routers"). I do hate those devices but my question is, why not to include them? Unfortunately they do exist. If they are not covered in the draft it seems that the draft is just writen in favour of 5-6 big vendors in all the world building complex SBC devices. On the other side, it could be just better to ignore such SIP ALG routers as I also would hate them to be quoted in any IETF spec. Honestly I don't know the purpose of my comment :) --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Jun 15 05:45:37 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E867721F8518 for ; Wed, 15 Jun 2011 05:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOJchkqaScr1 for ; Wed, 15 Jun 2011 05:45:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE8821F8517 for ; Wed, 15 Jun 2011 05:45:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b4-4df8a96fb868 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E2.A1.09774.F69A8FD4; Wed, 15 Jun 2011 14:45:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 15 Jun 2011 14:45:35 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 15 Jun 2011 14:45:34 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrVwsQrDDviBzsRuK3CIiOe/fzswAAllbg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 12:45:38 -0000 Hi,=20 >>------------ >> >> ALG:=A0=A0=A0 Within the scope of this document, ALG refers to a=20 >> network SIP device that modifies SDP media address:port information in o= rder to=20 >> steer (anchor) media flows described in the SDP, including TCP=20 >> connections used for MSRP communication, through a media proxy=20 >> function controlled by the SIP device. Other SIP related functions=20 >> (e.g. related to routing, modification of SIP information >> etc) performed by the SIP device, and whether it device creates=20 >> separate SIP dialogs in each direction or not, is outside=20 >> the scope of the definition. Section 5 describes assumptions regarding=20 >> how the ALG handles MSRP in order to support the extension defined in th= is=20 >> document. >> >> ------------ >=20 >Hi Christer, this text is nice, but does it mean that this=20 >draft will not cover those layer 3 devices (i.e. NAT routers)=20 >which perform ugly SIP inspection/modification? (this is what=20 >I call "SIP ALG routers"). >=20 >I do hate those devices but my question is, why not to include them? >Unfortunately they do exist. If they are not covered in the=20 >draft it seems that the draft is just writen in favour of 5-6=20 >big vendors in all the world building complex SBC devices. >=20 >On the other side, it could be just better to ignore such SIP=20 >ALG routers as I also would hate them to be quoted in any IETF spec. >=20 >Honestly I don't know the purpose of my comment :) And I am not sure I understand it :) The purpose of the definition text was that we don't need to have general d= iscussions about what types of nodes are included or excluded, or that the = name we use means something else. We now say what we mean by ALG within the= scope of sessmatch. And, the only thing we care about is that they anchor MSRP media, as descri= bed in the definition text. Whatever else they do, or whatever else they might be called, doesn't matte= r from a sessmatch/CEMA perspective. Regards, Christer From ibc@aliax.net Wed Jun 15 06:01:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAA611E80F0 for ; Wed, 15 Jun 2011 06:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1Iip7MbDzss for ; Wed, 15 Jun 2011 06:01:27 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 078C611E80FC for ; Wed, 15 Jun 2011 06:01:26 -0700 (PDT) Received: by qwc23 with SMTP id 23so282135qwc.31 for ; Wed, 15 Jun 2011 06:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.17 with SMTP id q17mr373717qca.154.1308142879904; Wed, 15 Jun 2011 06:01:19 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 06:01:19 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:01:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:01:27 -0000 2011/6/15 Christer Holmberg : > The purpose of the definition text was that we don't need to have general= discussions about what types of nodes are included or excluded, or that th= e name we use means something else. We now say what we mean by ALG within t= he scope of sessmatch. Ok, so what about NAT routers (which are not SIP nodes, of course) with SIP ALG? couldn't them make usage of CEMA? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 15 06:02:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1059111E80F0 for ; Wed, 15 Jun 2011 06:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzjjJhKwgpWJ for ; Wed, 15 Jun 2011 06:02:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 710E111E80EF for ; Wed, 15 Jun 2011 06:02:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so283118qwc.31 for ; Wed, 15 Jun 2011 06:02:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.17 with SMTP id q17mr375416qca.154.1308142960757; Wed, 15 Jun 2011 06:02:40 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 06:02:40 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:02:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:02:42 -0000 2011/6/15 I=C3=B1aki Baz Castillo : > 2011/6/15 Christer Holmberg : >> The purpose of the definition text was that we don't need to have genera= l discussions about what types of nodes are included or excluded, or that t= he name we use means something else. We now say what we mean by ALG within = the scope of sessmatch. > > Ok, so what about NAT routers (which are not SIP nodes, of course) > with SIP ALG? couldn't them make usage of CEMA? Of course such ugly devices could never fallback to MSRP B2BUA. Ok, forget my questions please, it's better tu assume that SIP ALG routers don't exist. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Wed Jun 15 06:04:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F163111E811C for ; Wed, 15 Jun 2011 06:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjMlsY1PxGNU for ; Wed, 15 Jun 2011 06:04:38 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 72F1011E80EF for ; Wed, 15 Jun 2011 06:04:38 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 34441B01C7; Wed, 15 Jun 2011 15:04:37 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 9921AB017C; Wed, 15 Jun 2011 15:04:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 15 Jun 2011 15:04:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:04:39 -0000 On Jun 15, 2011, at 3:01 PM, I=F1aki Baz Castillo wrote: > 2011/6/15 Christer Holmberg : >> The purpose of the definition text was that we don't need to have = general discussions about what types of nodes are included or excluded, = or that the name we use means something else. We now say what we mean by = ALG within the scope of sessmatch. >=20 > Ok, so what about NAT routers (which are not SIP nodes, of course) > with SIP ALG? couldn't them make usage of CEMA? >=20 No, because their purpose is not media anchoring. -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Wed Jun 15 06:06:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5923811E8110 for ; Wed, 15 Jun 2011 06:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDrGUpQpltyh for ; Wed, 15 Jun 2011 06:06:17 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D784111E80EF for ; Wed, 15 Jun 2011 06:06:16 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CFC52B01C2; Wed, 15 Jun 2011 15:06:15 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 39FD8B017C; Wed, 15 Jun 2011 15:06:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:06:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:06:17 -0000 Hi, On Jun 15, 2011, at 1:53 PM, Christer Holmberg wrote: > =20 > Hi, > =20 > In order to avoid confusion, missunderstandings, and general = discussions about what an ALG does and doesn't do, I have put togheter = some definition text which explains what we mean by ALG within the scope = of the sessmatch draft. > =20 > ------------ > =20 > ALG: Within the scope of this document, ALG refers to a network SIP = device that modifies SDP media address:port information in > order to steer (anchor) media flows described in the SDP, including = TCP connections used for MSRP communication, through a > media proxy function controlled by the SIP device. Other SIP related = functions (e.g. related to routing, modification of SIP information > etc) performed by the SIP device, and whether it device creates = separate SIP dialogs in each direction or not, is outside the scope > of the definition. Section 5 describes assumptions regarding how the = ALG handles MSRP in order to support the extension defined > in this document. > =20 > ------------ > =20 I think this is an accurate description of what an ALG means in *this* = particular case. +1 Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Jun 15 06:21:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3F11E80FC for ; Wed, 15 Jun 2011 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiU4KUou6VBK for ; Wed, 15 Jun 2011 06:21:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48C9E800A for ; Wed, 15 Jun 2011 06:21:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so296554qwc.31 for ; Wed, 15 Jun 2011 06:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.17 with SMTP id q17mr399955qca.154.1308144100921; Wed, 15 Jun 2011 06:21:40 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 06:21:40 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:21:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:21:42 -0000 2011/6/15 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> Ok, so what about NAT routers (which are not SIP nodes, of course) >> with SIP ALG? couldn't them make usage of CEMA? > > No, because their purpose is not media anchoring. I don't understand your point. A NAT router does "anchor" any communication from a user in the LAN with an external server/user. In addition, painful SIP ALG NAT routers perform criminal replacements in SIP messages so signalling and media "can" work when a user is behind NAT. So a SIP ALG router could perfectly implement CEMA and modify the SDP so an external MSRP client could talk to a MSRP client in the LAN (let's suppose there is no MSRP relay neither the external user supports announcing MSRP passive mode). Am I wrong? maybe the above is not "anchoring"? --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Jun 15 06:34:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B4F11E812C for ; Wed, 15 Jun 2011 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2S0Wy+FhXnV for ; Wed, 15 Jun 2011 06:34:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7118511E8126 for ; Wed, 15 Jun 2011 06:34:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b9-4df8b4ec027b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 99.7C.20773.CE4B8FD4; Wed, 15 Jun 2011 15:34:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 15 Jun 2011 15:34:36 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 15 Jun 2011 15:34:35 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrXzClu4oJXJCiSDS5adR2FHSFwQAARjmw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A90@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:34:38 -0000 Hi,=20 >>>Ok, so what about NAT routers (which are not SIP nodes, of course)=20 >>>with SIP ALG? couldn't them make usage of CEMA? >> >>No, because their purpose is not media anchoring. >=20 >I don't understand your point. A NAT router does "anchor" any=20 >communication from a user in the LAN with an external=20 >server/user. In addition, painful SIP ALG NAT routers perform=20 >criminal replacements in SIP messages so signalling and media=20 >"can" work when a user is behind NAT. >=20 >So a SIP ALG router could perfectly implement CEMA and modify=20 >the SDP so an external MSRP client could talk to a MSRP=20 >client in the LAN (let's suppose there is no MSRP relay=20 >neither the external user supports announcing MSRP passive mode). >=20 >Am I wrong? maybe the above is not "anchoring"? If the device anchors MSRP media, as described in the proposed defintion te= xt, then it is covered by the defintion. I don't see how we would be able to start excluding certain devices based o= n OTHER functions they perform, that are not related to the CEMA extension. Regards, Christer From saul@ag-projects.com Wed Jun 15 06:41:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1911E8146 for ; Wed, 15 Jun 2011 06:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHFSjGDC-p3z for ; Wed, 15 Jun 2011 06:41:24 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 805B711E8141 for ; Wed, 15 Jun 2011 06:41:24 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D8AA7B01C5; Wed, 15 Jun 2011 15:41:23 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 18886B00E6; Wed, 15 Jun 2011 15:41:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 15 Jun 2011 15:41:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:41:25 -0000 Hi, On Jun 15, 2011, at 3:21 PM, I=F1aki Baz Castillo wrote: > 2011/6/15 Sa=FAl Ibarra Corretg=E9 : >>> Ok, so what about NAT routers (which are not SIP nodes, of course) >>> with SIP ALG? couldn't them make usage of CEMA? >>=20 >> No, because their purpose is not media anchoring. >=20 > I don't understand your point. A NAT router does "anchor" any > communication from a user in the LAN with an external server/user. In > addition, painful SIP ALG NAT routers perform criminal replacements in > SIP messages so signalling and media "can" work when a user is behind > NAT. >=20 No. Home routers don't anchor media. Anchoring means adding yourself in = the middle for inspecting the media, measuring quality, etc. > So a SIP ALG router could perfectly implement CEMA and modify the SDP > so an external MSRP client could talk to a MSRP client in the LAN > (let's suppose there is no MSRP relay neither the external user > supports announcing MSRP passive mode). >=20 > Am I wrong? maybe the above is not "anchoring"? >=20 I'd say that this spec does not intend to cover routers that perform = some modifications to the SIP messages in order to 'fix' NAT issues, = even if they make it worse :-) This spec is targeted at SIP entities = that insert themselves in the media path. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Jun 15 06:42:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006BB11E8145 for ; Wed, 15 Jun 2011 06:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOOfTcd4uy0S for ; Wed, 15 Jun 2011 06:42:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09E7711E8126 for ; Wed, 15 Jun 2011 06:42:21 -0700 (PDT) Received: by qwc23 with SMTP id 23so312289qwc.31 for ; Wed, 15 Jun 2011 06:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.193.2 with SMTP id ds2mr443887qab.303.1308145341273; Wed, 15 Jun 2011 06:42:21 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 06:42:21 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A90@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A90@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:42:21 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:42:23 -0000 2011/6/15 Christer Holmberg : > If the device anchors MSRP media, as described in the proposed defintion = text, then it is covered by the defintion. >From your first mail: > ALG: Within the scope of this document, ALG refers to a network SIP de= vice that modifies SDP media address:port information in order to steer (an= chor) media flows described in the SDP The text clearly defines an ALG as a real SIP device (which can be a proxy, a pseudo-proxy, a B2BUA.... whatever, but something routeable at SIP level). A SIP ALG NAT router is not a SIP device but IMHO it could perform SDP replacement in order to "allow" MSRP communication between internal (NATted) and external users. So, does this draft cover SIP ALG NAT routers? Maybe it occurs that the "ALG" definition above does not mean that the draft only covers those "ALG" devices. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 15 06:46:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A6121F8453 for ; Wed, 15 Jun 2011 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-Lcnv8XKzlz for ; Wed, 15 Jun 2011 06:46:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9891321F8450 for ; Wed, 15 Jun 2011 06:46:17 -0700 (PDT) Received: by qyk7 with SMTP id 7so283912qyk.10 for ; Wed, 15 Jun 2011 06:46:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.212 with SMTP id e20mr428660qce.192.1308145576823; Wed, 15 Jun 2011 06:46:16 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 06:46:16 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:46:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:46:18 -0000 2011/6/15 Sa=C3=BAl Ibarra Corretg=C3=A9 : > I'd say that this spec does not intend to cover routers that perform some= modifications to the SIP messages in order to 'fix' NAT issues, even if th= ey make it worse :-) This spec is targeted at SIP entities that insert them= selves in the media path. What would prevent a SIP ALG router to insert itself in the media path instead of doing an ugly IP replacement in the SDP? Also I don't think that the motivation for anchoring media (inspecting the media, measuring quality, solving NAT) gets importance here. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Wed Jun 15 07:00:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3949E8013 for ; Wed, 15 Jun 2011 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.608 X-Spam-Level: X-Spam-Status: No, score=-1.608 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxipCZxAgYhw for ; Wed, 15 Jun 2011 07:00:59 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E7C969E800A for ; Wed, 15 Jun 2011 07:00:58 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2D22FB01C7; Wed, 15 Jun 2011 16:00:58 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 89CE4B00E6; Wed, 15 Jun 2011 16:00:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 15 Jun 2011 16:00:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:00:59 -0000 Hi, On Jun 15, 2011, at 3:46 PM, I=F1aki Baz Castillo wrote: > 2011/6/15 Sa=FAl Ibarra Corretg=E9 : >> I'd say that this spec does not intend to cover routers that perform = some modifications to the SIP messages in order to 'fix' NAT issues, = even if they make it worse :-) This spec is targeted at SIP entities = that insert themselves in the media path. >=20 > What would prevent a SIP ALG router to insert itself in the media path > instead of doing an ugly IP replacement in the SDP? >=20 Nothing, really. > Also I don't think that the motivation for anchoring media (inspecting > the media, measuring quality, solving NAT) gets importance here. >=20 It's actually the key point :-) -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed Jun 15 07:21:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277D911E8122 for ; Wed, 15 Jun 2011 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfhV6mcDg2Yo for ; Wed, 15 Jun 2011 07:21:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87311E811B for ; Wed, 15 Jun 2011 07:21:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-a0-4df8bff1b29f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B0.E0.09774.1FFB8FD4; Wed, 15 Jun 2011 16:21:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 15 Jun 2011 16:21:37 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 15 Jun 2011 16:21:36 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrZKdfR31tnoCoSHCZrZuZTtYjNgAAsE5w Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:21:40 -0000 Hi, Would it be more clear if the text said "SIP stateful device"? Because, I don't think a non-SIP device can be SIP stateful :) Regards, Christer=20 > -----Original Message----- > From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]=20 > Sent: 15. kes=E4kuuta 2011 17:01 > To: I=F1aki Baz Castillo > Cc: Christer Holmberg; simple@ietf.org > Subject: Re: [Simple] CEMA: ALG definition proposal >=20 > Hi, >=20 > On Jun 15, 2011, at 3:46 PM, I=F1aki Baz Castillo wrote: >=20 > > 2011/6/15 Sa=FAl Ibarra Corretg=E9 : > >> I'd say that this spec does not intend to cover routers=20 > that perform some modifications to the SIP messages in order=20 > to 'fix' NAT issues, even if they make it worse :-) This spec=20 > is targeted at SIP entities that insert themselves in the media path. > >=20 > > What would prevent a SIP ALG router to insert itself in the=20 > media path=20 > > instead of doing an ugly IP replacement in the SDP? > >=20 >=20 > Nothing, really. >=20 > > Also I don't think that the motivation for anchoring media=20 > (inspecting=20 > > the media, measuring quality, solving NAT) gets importance here. > >=20 >=20 > It's actually the key point :-) >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > = From ibc@aliax.net Wed Jun 15 07:44:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD22121F8554 for ; Wed, 15 Jun 2011 07:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv6eieynYkC6 for ; Wed, 15 Jun 2011 07:44:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCB721F854C for ; Wed, 15 Jun 2011 07:44:15 -0700 (PDT) Received: by qwc23 with SMTP id 23so361698qwc.31 for ; Wed, 15 Jun 2011 07:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.115.21 with SMTP id g21mr498275qcq.230.1308149054533; Wed, 15 Jun 2011 07:44:14 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 07:44:14 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 16:44:14 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:44:15 -0000 2011/6/15 Christer Holmberg : > Would it be more clear if the text said "SIP stateful device"? > Because, I don't think a non-SIP device can be SIP stateful :) Right, just Chuck Norris can do that. But if you use such term, then SIP ALG routers are discarded from this spec. I still wonder why a SIP ALG router could not use this spec. Let's suppose: - alice (which supports CEMA) in public Internet sends INVITE to bob (behind NAT). - bob's SIP ALG painful-router replaces the c=3D line with its public IP and set some port in m=3D line of MSRP stream (CEMA?). - Maybe the router also destroys SIP signalling or whatever, but "that is out of the scope of this mail". :) - alice is also CEMA compliant (Big-Vendor-$$$$$ Professional-Certified-=E2=82=AC=E2=82=AC=E2=82=AC=E2=82=AC=E2=82=AC-Phone)= so MSRP works. In this example, the node performing CEMA is not a SIP device. My question is: should this draft cover such posibility? or should it deny it? --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed Jun 15 07:54:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6187021F85B8 for ; Wed, 15 Jun 2011 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5teWt7R+y5Ww for ; Wed, 15 Jun 2011 07:54:35 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id AB7C821F8574 for ; Wed, 15 Jun 2011 07:54:34 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E518CB01B9; Wed, 15 Jun 2011 16:54:33 +0200 (CEST) Received: from ag-blink.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 51BBCB01C9; Wed, 15 Jun 2011 16:54:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Adrian Georgescu In-Reply-To: Date: Wed, 15 Jun 2011 16:54:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:54:35 -0000 Ideally This draft must not be used in implementations over the public Internet = where MSRP protocol has already provisions in place to handle traffic = for users behind NAT-ed routers by using standard MSRP Relays. The scope = must be narrowed down to 3GPP closed network deployments only where = there is no need or requirement to use Relays.=20 On Jun 15, 2011, at 4:44 PM, I=F1aki Baz Castillo wrote: > 2011/6/15 Christer Holmberg : >> Would it be more clear if the text said "SIP stateful device"? >> Because, I don't think a non-SIP device can be SIP stateful :) >=20 > Right, just Chuck Norris can do that. >=20 > But if you use such term, then SIP ALG routers are discarded from this > spec. I still wonder why a SIP ALG router could not use this spec. > Let's suppose: >=20 > - alice (which supports CEMA) in public Internet sends INVITE to bob > (behind NAT). > - bob's SIP ALG painful-router replaces the c=3D line with its public = IP > and set some port in m=3D line of MSRP stream (CEMA?). > - Maybe the router also destroys SIP signalling or whatever, but "that > is out of the scope of this mail". :) > - alice is also CEMA compliant (Big-Vendor-$$$$$ > Professional-Certified-=80=80=80=80=80-Phone) so MSRP works. >=20 > In this example, the node performing CEMA is not a SIP device. My > question is: should this draft cover such posibility? or should it > deny it? >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Wed Jun 15 08:14:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DC521F8441 for ; Wed, 15 Jun 2011 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feouNhFFVBRg for ; Wed, 15 Jun 2011 08:14:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9730B11E812E for ; Wed, 15 Jun 2011 08:14:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c8-4df8cc671aeb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.70.20773.76CC8FD4; Wed, 15 Jun 2011 17:14:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 17:14:47 +0200 From: Christer Holmberg To: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= Date: Wed, 15 Jun 2011 17:10:52 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrarOTn+JCMk1gQvGrpjGo9gWsQwAA7caf Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:14:49 -0000 Hi, >>Would it be more clear if the text said "SIP stateful device"? >>Because, I don't think a non-SIP device can be SIP stateful :) > >Right, just Chuck Norris can do that. Good old Chuck is too cool for any of this :) >But if you use such term, then SIP ALG routers are discarded from this >spec. I still wonder why a SIP ALG router could not use this spec. >Let's suppose: > >- alice (which supports CEMA) in public Internet sends INVITE to bob >(behind NAT). >- bob's SIP ALG painful-router replaces the c=3D line with its public IP >and set some port in m=3D line of MSRP stream (CEMA?). >- Maybe the router also destroys SIP signalling or whatever, but "that >is out of the scope of this mail". :) >- alice is also CEMA compliant (Big-Vendor-$$$$$ >Professional-Certified-=80=80=80=80=80-Phone) so MSRP works. > >In this example, the node performing CEMA is not a SIP device. My >question is: should this draft cover such posibility? or should it >deny it? If it's SIP stateful, how can it not be a SIP device? What is your definition of SIP device? Regards, Christer= From ibc@aliax.net Wed Jun 15 08:26:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5D11E813B for ; Wed, 15 Jun 2011 08:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9gPpUvzf86f for ; Wed, 15 Jun 2011 08:26:17 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9811E80BB for ; Wed, 15 Jun 2011 08:26:12 -0700 (PDT) Received: by qwc23 with SMTP id 23so396170qwc.31 for ; Wed, 15 Jun 2011 08:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.212 with SMTP id e20mr555745qce.192.1308151571949; Wed, 15 Jun 2011 08:26:11 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 08:26:11 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 17:26:11 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:26:18 -0000 2011/6/15 Christer Holmberg : >>In this example, the node performing CEMA is not a SIP device. My >>question is: should this draft cover such posibility? or should it >>deny it? > > If it's SIP stateful, how can it not be a SIP device? It's not SIP stateful (I understand SIP transaction stateful). It's just a layer 3 router but implements ugly SIP ALG to replace private IP's with public IP, just it. But let's suppose that in the case of MSRP it does it "well" (according to CEMA spec). > What is your definition of SIP device? Something that listens in a port at application level and is reachable at application level (SIP protocol). A SIP ALG router will never generate a SIP response or request, it just forwards requests and responses and apply painful IP substitution to the whole message/headers. Just to clarify: I'm speaking about cheap routers implementing SIP ALG feature, like most in this list: http://www.voip-info.org/wiki/view/Routers+SIP+ALG --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Jun 15 10:25:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3436021F8526 for ; Wed, 15 Jun 2011 10:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AolulxokdH4 for ; Wed, 15 Jun 2011 10:25:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA7E121F84F2 for ; Wed, 15 Jun 2011 10:25:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-25-4df8eaea31ff Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.2C.09774.AEAE8FD4; Wed, 15 Jun 2011 19:24:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 19:24:58 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 15 Jun 2011 19:24:57 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrcJBHQ9ixrRcaQBOkqLF9YVGoiwAD9Sho Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:25:06 -0000 Hi, >>>In this example, the node performing CEMA is not a SIP device. My >>>question is: should this draft cover such posibility? or should it >>>deny it? >> >>If it's SIP stateful, how can it not be a SIP device? > >It's not SIP stateful (I understand SIP transaction stateful). It's >just a layer 3 router but implements ugly SIP ALG to replace private >IP's with public IP, just it. But let's suppose that in the case of >MSRP it does it "well" (according to CEMA spec). > >>What is your definition of SIP device? > >Something that listens in a port at application level and is reachable >at application level (SIP protocol). A SIP ALG router will never >generate a SIP response or request, it just forwards requests and >responses and apply painful IP substitution to the whole >message/headers. > >Just to clarify: I'm speaking about cheap routers implementing SIP ALG >feature, like most in this list: >http://www.voip-info.org/wiki/view/Routers+SIP+ALG It's difficult for me to understand how such devices would be able to modif= y SDP, Call-ID etc in a consistant way throughout the session, without main= taining SIP state... Anyway, the intention of the definition text was to avoid having these kind= of discussions. So, what if we only use "device", then? Again, what is rel= evant is the fact that it anchors media - not what else it does or doesn't = do. Regards, Christer= From ag@ag-projects.com Wed Jun 15 10:32:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04CD21F85D6 for ; Wed, 15 Jun 2011 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 8ot-iCiMBwlf for ; Wed, 15 Jun 2011 10:32:58 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0A321F85D4 for ; Wed, 15 Jun 2011 10:32:58 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E1494B01C2; Wed, 15 Jun 2011 19:32:56 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 1C01AB00E6; Wed, 15 Jun 2011 19:32:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 19:32:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF8B68A-4B0C-4B6E-B0B1-C63C0049187A@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:32:58 -0000 >=20 > It's difficult for me to understand how such devices would be able to = modify SDP, Call-ID etc in a consistant way throughout the session, = without maintaining SIP state... As ridiculous as it sounds they use regular expressions the sip message = and keep no state. As is clear text protocol and the developer has no clue about SIP = protocol or a state machine, he spends his 4 hours budget on solving the = problem like this. We know it happened with SIP. So the question is how to completely = discourage this initiatives when it comes to MSRP.=20 Because this is what this draft would stimulates indirectly, though not = the intention of the authors. > Anyway, the intention of the definition text was to avoid having these = kind of discussions. So, what if we only use "device", then? Again, what = is relevant is the fact that it anchors media - not what else it does or = doesn't do. >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Wed Jun 15 10:43:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97621F8609 for ; Wed, 15 Jun 2011 10:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CXbIg4e6-yX for ; Wed, 15 Jun 2011 10:43:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 51AA021F8608 for ; Wed, 15 Jun 2011 10:43:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b6-4df8ef50e15b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.83.09774.05FE8FD4; Wed, 15 Jun 2011 19:43:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 15 Jun 2011 19:43:41 +0200 From: Christer Holmberg To: Adrian Georgescu Date: Wed, 15 Jun 2011 19:39:05 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrgkSfXAS2BLFAQ4WjxskuMUNaHQAANqTZ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se>, <5BF8B68A-4B0C-4B6E-B0B1-C63C0049187A@ag-projects.com> In-Reply-To: <5BF8B68A-4B0C-4B6E-B0B1-C63C0049187A@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:43:46 -0000 Hi, >>It's difficult for me to understand how such devices would be able to mod= ify SDP, Call-ID etc in a consistant way throughout the session, without ma= intaining SIP state... > >As ridiculous as it sounds they use regular expressions the sip message an= d keep no state. > >As is clear text protocol and the developer has no clue about SIP protocol= or a state machine, he spends his 4 hours budget on solving the problem li= ke this. > >We know it happened with SIP. So the question is how to completely discour= age this initiatives when it comes to MSRP. > >Because this is what this draft would stimulates indirectly, though not th= e intention of the authors. Keep in mind that the device we are talking about needs to enable MSRP B2BU= A functionality in some cases, and that requires more than modifying SIP/SD= P information. We also make other ALG assumptions, as described in section = 5. I don't think the type of device mentioned by I=F1aki would "fit" into that= definition :) Regards, Christer= From ibc@aliax.net Wed Jun 15 10:48:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27C11E80F6 for ; Wed, 15 Jun 2011 10:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGLQmnri30zS for ; Wed, 15 Jun 2011 10:48:00 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDA111E80BB for ; Wed, 15 Jun 2011 10:48:00 -0700 (PDT) Received: by qyk29 with SMTP id 29so2416039qyk.10 for ; Wed, 15 Jun 2011 10:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.17 with SMTP id q17mr1833qca.154.1308160079743; Wed, 15 Jun 2011 10:47:59 -0700 (PDT) Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 10:47:59 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 19:47:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:48:01 -0000 2011/6/15 Christer Holmberg : >>Just to clarify: I'm speaking about cheap routers implementing SIP ALG >>feature, like most in this list: >>http://www.voip-info.org/wiki/view/Routers+SIP+ALG > > It's difficult for me to understand how such devices would be able to mod= ify SDP, Call-ID etc in a consistant way throughout the session, without ma= intaining SIP state... Christer, don't take me wrong, but your comment scares me. Could you please visit the real world and contract any commercial ADSL with any Internet provider for residential market in any country of the world? : ) *All* the Internet routers (home internet routers, yes, but homes do exist in the world) I've tested come with SIP ALG built-in and enabled by default, and *all* of them break SIP signalling (and the worst, some of them don't allow dissabling SIP ALG). So, if people like you making such kind of specifications are not aware of the real problems of VoIP in the real world, should we expect that the history will be repeated for any new protocol (i.e. MSRP)? Please don't take me wrong. Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Wed Jun 15 10:50:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B770F11E80F6 for ; Wed, 15 Jun 2011 10:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, 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 bSf2Q3SH9HY9 for ; Wed, 15 Jun 2011 10:50:41 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4014B11E8081 for ; Wed, 15 Jun 2011 10:50:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 15 Jun 2011 13:50:39 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jun 2011 13:50:39 -0400 From: Hadriel Kaplan To: Christer Holmberg Date: Wed, 15 Jun 2011 13:50:37 -0400 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrhJGC18LBHhxFQ9+5r6BW8tgwFQ== Message-ID: <12FA7E09-B450-43F2-BD58-3D917EDE5910@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_12FA7E09B45043F2BD583D917EDE5910acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:50:43 -0000 --_000_12FA7E09B45043F2BD583D917EDE5910acmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How about... Middlebox: Within the scope of this document, "Middlebox" refers to a SIP e= ntity between the UAC and ultimate UAS, that modifies SDP media address:por= t information in order to relay (anchor) media flows described in the SDP, including TCP con= nections used for MSRP communication, through a media proxy function contro= lled by the Middlebox. Unlike an RFC 4976 MSRP Relay, a Middlebox does not = modify MSRP headers nor process MSRP messages at the application layer, but= rather operates at the IP and transport layers only. Other SIP related fu= nctions (e.g. related to routing, modification of SIP information, etc.) pe= rformed by the Middlebox, and whether it is a SIP B2BUA or not, is outside = the scope of the definition. Section 5 describes assumptions regarding how = the Middlebox handles MSRP in order to support the extension defined in thi= s document. On Jun 15, 2011, at 7:53 AM, Christer Holmberg wrote: Hi, In order to avoid confusion, missunderstandings, and general discussions ab= out what an ALG does and doesn't do, I have put togheter some definition te= xt which explains what we mean by ALG within the scope of the sessmatch dra= ft. ------------ ALG: Within the scope of this document, ALG refers to a network SIP devi= ce that modifies SDP media address:port information in order to steer (anchor) media flows described in the SDP, including TCP con= nections used for MSRP communication, through a media proxy function controlled by the SIP device. Other SIP related functi= ons (e.g. related to routing, modification of SIP information etc) performed by the SIP device, and whether it device creates separate SI= P dialogs in each direction or not, is outside the scope of the definition. Section 5 describes assumptions regarding how the ALG ha= ndles MSRP in order to support the extension defined in this document. ------------ Regards, Christer --_000_12FA7E09B45043F2BD583D917EDE5910acmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable order to relay (anchor) media flows described in the SDP, incl= uding TCP connections used for MSRP communication, through a media pro= xy function controlled by the Middlebox. Unlike an RFC 4976 MSRP Relay, a M= iddlebox does not modify MSRP headers nor process MSRP messages at the appl= ication layer, but rather operates at the IP and transport layers only. &nb= sp;Other SIP related functions (e.g. related to routing, modification of SI= P information, etc.) performed by the Middlebox, and whether it is a S= IP B2BUA or not, is outside the scope of the definition. Section 5 des= cribes assumptions regarding how the Middlebox handles MSRP in order to sup= port the extension defined in this document.



On Jun 15, 2011, at 7:53 AM, Christer Holmberg wrote= :

 
Hi,
 
In order to avoid confusion, missunderstandings, and general= discussions about what an ALG does and doesn't do, I have put togheter som= e definition text which explains what we mean by ALG within the scope of th= e sessmatch draft.
 
------------
 
ALG:    Within the scope of = this document, ALG refers to a network SIP device that modifies SDP media a= ddress:port information in
order to steer= (anchor) media flows described in the SDP, including TCP connections used = for MSRP communication, through a
media p= roxy function controlled by the SIP device. Other SIP related functions (e.= g. related to routing, modification of SIP information
etc) performed by the SIP device, and whether it device creat= es separate SIP dialogs in each direction or not, is outside the scope
of the definition. Section 5 describes assump= tions regarding how the ALG handles MSRP in order to support the extension = defined
in this document.
 
------------
 
Re= gards,
 
Christer
 
<ATT00001..c>

= = --_000_12FA7E09B45043F2BD583D917EDE5910acmepacketcom_-- From christer.holmberg@ericsson.com Wed Jun 15 10:53:19 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56AA11E812B for ; Wed, 15 Jun 2011 10:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc9neNq0Pmu2 for ; Wed, 15 Jun 2011 10:53:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 370D911E8125 for ; Wed, 15 Jun 2011 10:53:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c1-4df8f180d9e8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.12.20773.081F8FD4; Wed, 15 Jun 2011 19:53:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 19:53:04 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 15 Jun 2011 19:48:49 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrhF6qkcFuaCjtQ52Wr1c72QbaIgAAByeT Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:53:20 -0000 Hi, >>>Just to clarify: I'm speaking about cheap routers implementing SIP ALG >>>feature, like most in this list: >>>http://www.voip-info.org/wiki/view/Routers+SIP+ALG >> >> It's difficult for me to understand how such devices would be able to mo= dify SDP, Call-ID etc in a consistant way throughout the session, without m= aintaining SIP state... > >Christer, don't take me wrong, but your comment scares me. Could you >please visit the real world and contract any commercial ADSL with any >Internet provider for residential market in any country of the world? >: ) Trust me - I know what stuff exists out there :) My issue is how these kind of entities would be able to support CEMA. For e= xample, I don't think they are able to enable MSRP B2BUA functionality, whi= ch the draft assumes an ALG is able to. So, therefor I don't think they are within the scope of the CEMA definition= of ALG. Regards, Christer= From HKaplan@acmepacket.com Wed Jun 15 10:55:29 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF38211E811E for ; Wed, 15 Jun 2011 10:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 WisunV2h+Eil for ; Wed, 15 Jun 2011 10:55:29 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0411E80F3 for ; Wed, 15 Jun 2011 10:55:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 15 Jun 2011 13:55:28 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jun 2011 13:55:28 -0400 From: Hadriel Kaplan To: Christer Holmberg Date: Wed, 15 Jun 2011 13:55:26 -0400 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrhT2BHJF2szVnRQWPR9p++uExVw== Message-ID: <38FE0AAE-8CCD-44C2-A79B-3CA2843D3942@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFT Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:55:29 -0000 On Jun 15, 2011, at 8:45 AM, Christer Holmberg wrote: > The purpose of the definition text was that we don't need to have general= discussions about what types of nodes are included or excluded, or that th= e name we use means something else. We now say what we mean by ALG within t= he scope of sessmatch. Sure, but if our definition goes against common industry parlance, then it'= s not useful. An "ALG" really does denote something already, and given the= confusion on this mailing list I think it would be safer not to use the te= rm. > And, the only thing we care about is that they anchor MSRP media, as desc= ribed in the definition text. Well... ALGs don't actually "anchor" MSRP or media the same way as "normal"= SIP B2BUAs do. For example, they modify the SDP and the IP/transport in o= ne direction but not the other. Thus even on the wire you'd see a differen= ce. -hadriel From christer.holmberg@ericsson.com Wed Jun 15 10:58:19 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB4311E80C7 for ; Wed, 15 Jun 2011 10:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9NMHOFk8N-7 for ; Wed, 15 Jun 2011 10:58:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5BF11E8081 for ; Wed, 15 Jun 2011 10:58:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-db-4df8f2b73ca8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 55.98.09774.7B2F8FD4; Wed, 15 Jun 2011 19:58:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 19:58:15 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Wed, 15 Jun 2011 19:56:48 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrhT2BHJF2szVnRQWPR9p++uExVwAAFs0q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A451@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se>, <38FE0AAE-8CCD-44C2-A79B-3CA2843D3942@acmepacket.com> In-Reply-To: <38FE0AAE-8CCD-44C2-A79B-3CA2843D3942@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:58:19 -0000 Hi, >>The purpose of the definition text was that we don't need to have general= discussions about what types of=20 >>nodes are included or excluded, or that the name we use means something e= lse. We now say what we mean=20 >>by ALG within the scope of sessmatch. > >Sure, but if our definition goes against common industry parlance, then it= 's not useful. An "ALG" really does >denote something already, and given t= he confusion on this mailing list I think it would be safer not to use the = >term. No problem, we can use whatever term :) At this point I was more focusing on the actual definition text. Regards, Christer= From ibc@aliax.net Wed Jun 15 11:00:30 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D85411E8081 for ; Wed, 15 Jun 2011 11:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+IpKm54navT for ; Wed, 15 Jun 2011 11:00:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78A5B11E8089 for ; Wed, 15 Jun 2011 11:00:29 -0700 (PDT) Received: by ywp31 with SMTP id 31so550635ywp.31 for ; Wed, 15 Jun 2011 11:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.187.18 with SMTP id k18mr66951ybf.19.1308160828891; Wed, 15 Jun 2011 11:00:28 -0700 (PDT) Received: by 10.147.182.4 with HTTP; Wed, 15 Jun 2011 11:00:28 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44F@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 20:00:28 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 18:00:30 -0000 2011/6/15 Christer Holmberg : > My issue is how these kind of entities would be able to support CEMA. For= example, I don't think they are able to enable MSRP B2BUA functionality, w= hich the draft assumes an ALG is able to. No, Dragon-IP-Net or Chiun-Chiun-Tech-IP vendors will indeed not include MSRP B2BUA funcionality in their home routers. But they *will* do ugly replacements in SIP traffic within their routers (so they can announce a "SIP enchanded" label or "Works with SIP"). If CEMA let such vendors doing it in a way that, at least, could work, then maybe they decide to implement it instead of performing a global regex substitution in the whole SIP message as they do now. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Jun 15 11:12:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338BD11E80C7 for ; Wed, 15 Jun 2011 11:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyldm2lX+tp0 for ; Wed, 15 Jun 2011 11:12:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6A15D11E80F6 for ; Wed, 15 Jun 2011 11:12:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-11-4df8f5f0b5b3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 36.08.20773.0F5F8FD4; Wed, 15 Jun 2011 20:12:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 20:12:00 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 15 Jun 2011 20:11:59 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: Acwrhh0/1Q1Rh2edSsKhC1V2sKE2jAAAGTh1 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A453@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44F@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 18:12:02 -0000 Hi, >>My issue is how these kind of entities would be able to support CEMA. For= example, I don't think they are able to enable MSRP B2BUA functionality, w= hich the draft assumes an ALG is able to. > >No, Dragon-IP-Net or Chiun-Chiun-Tech-IP vendors will indeed not >include MSRP B2BUA funcionality in their home routers. But they *will* >do ugly replacements in SIP traffic within their routers (so they can >announce a "SIP enchanded" label or "Works with SIP"). Yes, but they are already doing it today, and they will continue to do it. = It has nothing to do with CEMA. They will probably not even read the CEMA s= pec :) >If CEMA let such vendors doing it in a way that, at least, could work, >then maybe they decide to implement it instead of performing a global >regex substitution in the whole SIP message as they do now. I don't understand what you mean by "let such vendors doing". CEMA assumes = that the devices can enable MSRP B2BUA functionality. If they don't, they w= ill break things in the same way as they already do... Regards, Christer= From ibc@aliax.net Wed Jun 15 11:16:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B9411E8123 for ; Wed, 15 Jun 2011 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9VCiz2A-rur for ; Wed, 15 Jun 2011 11:16:17 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE011E8089 for ; Wed, 15 Jun 2011 11:16:17 -0700 (PDT) Received: by gxk19 with SMTP id 19so562914gxk.31 for ; Wed, 15 Jun 2011 11:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.77.195 with SMTP id d43mr60284yhe.272.1308161776992; Wed, 15 Jun 2011 11:16:16 -0700 (PDT) Received: by 10.147.182.4 with HTTP; Wed, 15 Jun 2011 11:16:16 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A453@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A0A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1B1C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A446@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A449@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A453@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 20:16:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 18:16:18 -0000 2011/6/15 Christer Holmberg : >>If CEMA let such vendors doing it in a way that, at least, could work, >>then maybe they decide to implement it instead of performing a global >>regex substitution in the whole SIP message as they do now. > > I don't understand what you mean by "let such vendors doing". CEMA assume= s that the devices can enable MSRP B2BUA functionality. If they don't, they= will break things in the same way as they already do... Right. But there is however the case in which the MSRP endpoint behind NAT suports CEMA, and the SIP ALG NAT router (not a SIP entity) performs SDP modification as CEMA states. Then MSRP could work. But if the SIP ALG NAT router just performs a whole IP substitution in the SIP message then it will break MSRP, for sure. Anyhow, maybe it's just better to ignore SIP ALG routers ;) --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Jun 15 11:19:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC2B11E8133 for ; Wed, 15 Jun 2011 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaA-A3HrsktE for ; Wed, 15 Jun 2011 11:19:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA66111E810E for ; Wed, 15 Jun 2011 11:19:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-30-4df8f793a54d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 43.70.09774.397F8FD4; Wed, 15 Jun 2011 20:19:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 15 Jun 2011 20:18:59 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Wed, 15 Jun 2011 20:18:59 +0200 Thread-Topic: [Simple] CEMA: ALG definition proposal Thread-Index: AcwrhJGC18LBHhxFQ9+5r6BW8tgwFQAAz3F9 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A454@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se>, <12FA7E09-B450-43F2-BD58-3D917EDE5910@acmepacket.com> In-Reply-To: <12FA7E09-B450-43F2-BD58-3D917EDE5910@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 18:19:01 -0000 Hi Hadriel, As I said in another reply, I have no problem to call the device "Middlebox= ", if it's less confusing :) However, your proposed text does not cover the case when the device enables= MSRP B2BUA functionality. Middlebox: Within the scope of this document, Middlebox refers to a netw= ork SIP device that modifies SDP media address:port information in order to steer (anchor) media flows described in the SDP, including TCP con= nections used for MSRP communication, through a media proxy function controlled by the SIP device. In most cases the media = proxy function relays the MSRP messages without modification, while in other cases it enables MSRP B2BUA functionality. Other SIP related funct= ions (e.g. related to routing, modification of SIP information etc) performed by the SIP device, and whether it acts a SIP B2BUA or not, i= s outside the scope of the definition. Section 5 describes additional assumptions regarding how the Middlebox handles MSRP in order to support th= e extension defined in this document. Regards, Christer ________________________________ From: Hadriel Kaplan [HKaplan@acmepacket.com] Sent: Wednesday, June 15, 2011 8:50 PM To: Christer Holmberg Cc: simple@ietf.org Subject: Re: [Simple] CEMA: ALG definition proposal How about... Middlebox: Within the scope of this document, "Middlebox" refers to a SIP e= ntity between the UAC and ultimate UAS, that modifies SDP media address:por= t information in order to relay (anchor) media flows described in the SDP, including TCP con= nections used for MSRP communication, through a media proxy function contro= lled by the Middlebox. Unlike an RFC 4976 MSRP Relay, a Middlebox does not = modify MSRP headers nor process MSRP messages at the application layer, but= rather operates at the IP and transport layers only. Other SIP related fu= nctions (e.g. related to routing, modification of SIP information, etc.) pe= rformed by the Middlebox, and whether it is a SIP B2BUA or not, is outside = the scope of the definition. Section 5 describes assumptions regarding how = the Middlebox handles MSRP in order to support the extension defined in thi= s document. On Jun 15, 2011, at 7:53 AM, Christer Holmberg wrote: Hi, In order to avoid confusion, missunderstandings, and general discussions ab= out what an ALG does and doesn't do, I have put togheter some definition te= xt which explains what we mean by ALG within the scope of the sessmatch dra= ft. ------------ ALG: Within the scope of this document, ALG refers to a network SIP devi= ce that modifies SDP media address:port information in order to steer (anchor) media flows described in the SDP, including TCP con= nections used for MSRP communication, through a media proxy function controlled by the SIP device. Other SIP related functi= ons (e.g. related to routing, modification of SIP information etc) performed by the SIP device, and whether it device creates separate SI= P dialogs in each direction or not, is outside the scope of the definition. Section 5 describes assumptions regarding how the ALG ha= ndles MSRP in order to support the extension defined in this document. ------------ Regards, Christer From ibc@aliax.net Wed Jun 15 11:28:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061811E8141 for ; Wed, 15 Jun 2011 11:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id undatQ1APZ+H for ; Wed, 15 Jun 2011 11:28:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34A8A11E810E for ; Wed, 15 Jun 2011 11:28:07 -0700 (PDT) Received: by ywp31 with SMTP id 31so570125ywp.31 for ; Wed, 15 Jun 2011 11:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.65.21 with SMTP id n21mr84068yaa.9.1308162486730; Wed, 15 Jun 2011 11:28:06 -0700 (PDT) Received: by 10.147.182.4 with HTTP; Wed, 15 Jun 2011 11:28:06 -0700 (PDT) In-Reply-To: <12FA7E09-B450-43F2-BD58-3D917EDE5910@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A197F@ESESSCMS0356.eemea.ericsson.se> <12FA7E09-B450-43F2-BD58-3D917EDE5910@acmepacket.com> Date: Wed, 15 Jun 2011 20:28:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] CEMA: ALG definition proposal X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 18:28:12 -0000 2011/6/15 Hadriel Kaplan : > How about... > > Middlebox:=C2=A0Within the scope of this document, "Middlebox" refers to = a SIP > entity between the UAC and ultimate UAS, that modifies SDP media > address:port information in > order to relay (anchor) media flows described in the SDP, including TCP > connections used for MSRP communication, through a=C2=A0media proxy funct= ion > controlled by the Middlebox. Unlike an RFC 4976 MSRP Relay, a Middlebox d= oes > not modify MSRP headers nor process MSRP messages at the application laye= r, > but rather operates at the IP and transport layers only. =C2=A0Other SIP = related > functions (e.g. related to routing, modification of SIP information,=C2= =A0etc.) > performed by the Middlebox, and whether it is a SIP B2BUA or not, is outs= ide > the scope=C2=A0of the definition. Section 5 describes assumptions regardi= ng how > the Middlebox handles MSRP in order to support the extension defined=C2= =A0in this > document. I understand it, no doubts after reading it. I like it. --=20 I=C3=B1aki Baz Castillo From nancy.greene@ericsson.com Wed Jun 15 19:49:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A1A11E8136 for ; Wed, 15 Jun 2011 19:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=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 46iq-HFfdxDy for ; Wed, 15 Jun 2011 19:49:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 447D111E80DC for ; Wed, 15 Jun 2011 19:49:20 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5G2nGtD032756 for ; Wed, 15 Jun 2011 21:49:20 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.12]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 15 Jun 2011 22:49:18 -0400 From: Nancy Greene To: "simple@ietf.org" Date: Wed, 15 Jun 2011 22:49:16 -0400 Thread-Topic: Q on Message-ID in MSRP 200 OK Thread-Index: Acwrz/q0w30A7nJOSOy11SsQsvdv0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Simple] Q on Message-ID in MSRP 200 OK X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 02:49:21 -0000 I have a question about whether Message-ID is expected in an MSRP 200 OK. M= SRP Relays RFC4976 has examples with it there, but isn't it an error to inc= lude it? In MSRP RFC4975 chapter 7.2 Creating responses only talks about To-path and= From-path being added in MSRP responses. Yet, an example from MSRP Relays RFC 4976 shows Message-ID: MSRP 6aef 200 OK To-Path: msrps://alice.example.org:7965/bar;tcp From-Path: msrps://a.example.org:9000/kjfjan;tcp Message-ID: 87652 -------6aef$ =20 Nancy= From internet-drafts@ietf.org Thu Jun 16 00:57:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EDA21F85E9; Thu, 16 Jun 2011 00:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v71UVuxe1XnV; Thu, 16 Jun 2011 00:57:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3982221F85E1; Thu, 16 Jun 2011 00:57:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616075749.1998.57992.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 00:57:49 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-sessmatch-13.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 07:57:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Filename : draft-ietf-simple-msrp-sessmatch-13.txt Pages : 14 Date : 2011-06-16 This document defines an MSRP extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. MSRP endpoints can implement the extension in order to allow MSRP communication in networks where Middleboxes anchor the MSRP connection, without the need for the Middleboxes to enable MSRP B2BUA functionality in most cases. The document also defines a Session Description Protocol (SDP) [RFC4566] attribute, a=3Dmsrp-cema, that can be used by MSRP endpoints to indicate support of the CEMA extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-13.txt From christer.holmberg@ericsson.com Thu Jun 16 01:05:37 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7011E80B8 for ; Thu, 16 Jun 2011 01:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVOYjCC1TdJ1 for ; Thu, 16 Jun 2011 01:05:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 95EFD11E8078 for ; Thu, 16 Jun 2011 01:05:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-51-4df9b94f0115 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9B.44.09774.F49B9FD4; Thu, 16 Jun 2011 10:05:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 16 Jun 2011 10:05:18 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Thu, 16 Jun 2011 10:05:18 +0200 Thread-Topic: Draft new version: draft-ietf-simple-msrp-sessmatch-13 (CEMA) Thread-Index: Acwr/CF3nYOz95dMSH+XivJSZdQ+LA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new version: draft-ietf-simple-msrp-sessmatch-13 (CEMA) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:05:37 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the latest e-mail discussions, I've submitted a new version of the= sessmatch draft. The major changes are: - Updated name, abstract and applicability - Added Middlebox definition - Replaced "ALG" with "Middlebox" - Due to a comment from Saul that an offer cannot contain a=3Dsetup:passive= , and in order to make the text more clear, I updated the MSRP Answerer sec= tion. Happy Reading! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the latest e-mail discussions, I've submitte= d a new version of the sessmatch draft.
 
The major changes are:
 
- Updated name, abstract and applicability
- Added Middlebox definition
- Replaced "ALG" with "Middlebox"=
- Due to a comment from Saul that an offer cannot con= tain a=3Dsetup:passive, and in order to make the text more clear, I updated= the MSRP Answerer section.
 
Happy Reading!
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07ESESSCMS0356e_-- From christer.holmberg@ericsson.com Thu Jun 16 01:07:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39DE11E80C0 for ; Thu, 16 Jun 2011 01:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA8rZojeFiSo for ; Thu, 16 Jun 2011 01:07:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0722F11E8078 for ; Thu, 16 Jun 2011 01:07:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-da-4df9b9a1336f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 50.55.20773.1A9B9FD4; Thu, 16 Jun 2011 10:06:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 16 Jun 2011 10:06:56 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Thu, 16 Jun 2011 10:06:54 +0200 Thread-Topic: [Simple] Draft new version: draft-ietf-simple-msrp-sessmatch-13 (CEMA) Thread-Index: Acwr/CF3nYOz95dMSH+XivJSZdQ+LAAAC3iQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3E6C09@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3E6C07@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C09ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Draft new version: draft-ietf-simple-msrp-sessmatch-13 (CEMA) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:07:04 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C09ESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And, I of course changed the title also :) Regards, Christer ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 16. kes=E4kuuta 2011 11:05 To: simple@ietf.org Subject: [Simple] Draft new version: draft-ietf-simple-msrp-sessmatch-13 (C= EMA) Hi, Based on the latest e-mail discussions, I've submitted a new version of the= sessmatch draft. The major changes are: - Updated name, abstract and applicability - Added Middlebox definition - Replaced "ALG" with "Middlebox" - Due to a comment from Saul that an offer cannot contain a=3Dsetup:passive= , and in order to make the text more clear, I updated the MSRP Answerer sec= tion. Happy Reading! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C09ESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
And, I of course changed the title also=20 :)
 
Regards,
 
Christer

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: 16. kes=E4kuuta 2011 11:05
To:=20 simple@ietf.org
Subject: [Simple] Draft new version:=20 draft-ietf-simple-msrp-sessmatch-13 (CEMA)

 
Hi,
 
Based on the latest e-mail discussions, I've submitte= d a new=20 version of the sessmatch draft.
 
The major changes are:
 
- Updated name, abstract and applicability
- Added Middlebox definition
- Replaced "ALG" with "Middlebox"
- Due to a comment from Saul that an offer cannot con= tain=20 a=3Dsetup:passive, and in order to make the text more clear, I updated th= e MSRP=20 Answerer section.
 
Happy Reading!
 
Regards,
 
Christer
 
--_000_7F2072F1E0DE894DA4B517B93C6A0585194E3E6C09ESESSCMS0356e_-- From ben@nostrum.com Fri Jun 24 11:46:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC611E80EE for ; Fri, 24 Jun 2011 11:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bod8WW2aRYKp for ; Fri, 24 Jun 2011 11:46:34 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFE111E8084 for ; Fri, 24 Jun 2011 11:46:32 -0700 (PDT) Received: from dn3-227.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p5OIjFuD041917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 24 Jun 2011 13:45:16 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jun 2011 13:45:15 -0500 Message-Id: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 18:46:35 -0000 (as chair) Hi, The latest version of the sessmatch draft ( = draft-ietf-simple-msrp-sessmatch-13) is a significant change of = direction from older version. The essential difference is that the new = version involves compliant endpoints using the SDP m and c lines to = establish TCP connections, rather than the previous approach of making = clients more resilient to a middlebox changing an MSRP URI in the a=3Dpath= attribute. The draft refers to this new approach as CEMA. Do people thinks this is the right direction to take this work? I'm not = asking if the draft is perfect and ready to go--we certainly expect = discussion and potential changes in the details. The point is to decide = if we should move forward with the CEMA approach instead of the previous = sessmatch approach. (In a perfect world, we probably would put CEMA in a separate draft so = the two could be compared. But unless people strongly object, I think we = can still compare the approaches with the current draft structure.) Please send opinions and comments to the SIMPLE list no later than 11 = July 2011. Sooner is better. (This is probably longer than we need, but = I know we're into prime vacation time for a number of people, including = myself. I've allotted extra time in hopes of getting more comments) Thanks! Ben.= From ben@nostrum.com Fri Jun 24 11:54:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46FE11E818E for ; Fri, 24 Jun 2011 11:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmr5M4FhATPr for ; Fri, 24 Jun 2011 11:54:52 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 279BF11E80C6 for ; Fri, 24 Jun 2011 11:54:52 -0700 (PDT) Received: from [172.16.3.227] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p5OIraxj042637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 13:53:36 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> Date: Fri, 24 Jun 2011 13:53:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <04ABB8C4-FA7F-41FD-B235-4A512116F12E@nostrum.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 18:54:52 -0000 (as individual) IMO, the CEMA approach is better than the previous sessmatch approach = that encouraged middleboxes to change URLs in the SDP offer and answer. However, I would like to better understand which scenarios allow for = CEMA to work, vs which scenarios require fallback to 4975 behavior, with = middleboxes acting as MSRP b2buas, along with how common each class of = scenario really is. I wonder whether CEMA solves enough cases where we would not be better = off to simply advise (perhaps in an informational rfc) middlebox makers = that, if they want to carry MSRP, they have to act either as an MSRP = b2bua or an RFC4976 MSRP Relay. Thanks! Ben. On Jun 24, 2011, at 1:45 PM, Ben Campbell wrote: > (as chair) >=20 > Hi, >=20 > The latest version of the sessmatch draft ( = draft-ietf-simple-msrp-sessmatch-13) is a significant change of = direction from older version. The essential difference is that the new = version involves compliant endpoints using the SDP m and c lines to = establish TCP connections, rather than the previous approach of making = clients more resilient to a middlebox changing an MSRP URI in the a=3Dpath= attribute. The draft refers to this new approach as CEMA. >=20 > Do people thinks this is the right direction to take this work? I'm = not asking if the draft is perfect and ready to go--we certainly expect = discussion and potential changes in the details. The point is to decide = if we should move forward with the CEMA approach instead of the previous = sessmatch approach. >=20 > (In a perfect world, we probably would put CEMA in a separate draft so = the two could be compared. But unless people strongly object, I think we = can still compare the approaches with the current draft structure.) >=20 > Please send opinions and comments to the SIMPLE list no later than 11 = July 2011. Sooner is better. (This is probably longer than we need, but = I know we're into prime vacation time for a number of people, including = myself. I've allotted extra time in hopes of getting more comments) >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Fri Jun 24 15:45:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7D11E8129 for ; Fri, 24 Jun 2011 15:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGVrAol1KIqJ for ; Fri, 24 Jun 2011 15:45:20 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADDB411E8130 for ; Fri, 24 Jun 2011 15:45:20 -0700 (PDT) Received: by qyk9 with SMTP id 9so650587qyk.10 for ; Fri, 24 Jun 2011 15:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.212 with SMTP id e20mr2909280qce.192.1308955519791; Fri, 24 Jun 2011 15:45:19 -0700 (PDT) Received: by 10.229.181.209 with HTTP; Fri, 24 Jun 2011 15:45:19 -0700 (PDT) In-Reply-To: <04ABB8C4-FA7F-41FD-B235-4A512116F12E@nostrum.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <04ABB8C4-FA7F-41FD-B235-4A512116F12E@nostrum.com> Date: Sat, 25 Jun 2011 00:45:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 22:45:21 -0000 2011/6/24 Ben Campbell : > However, I would like to better understand which scenarios allow for CEMA= to work, vs which scenarios require fallback to 4975 behavior, with middle= boxes acting as MSRP b2buas, along with how common each class of scenario r= eally is. I think the same. I'd would like all the scenarios (working and non working) to be fully detailed and explained in the draft (and not just in a mail thread in this maillist). --=20 I=C3=B1aki Baz Castillo From gonzalo.camarillo@ericsson.com Mon Jun 27 00:14:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA021F85F3 for ; Mon, 27 Jun 2011 00:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvEzoBqG6Z5O for ; Mon, 27 Jun 2011 00:14:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8D21F85F9 for ; Mon, 27 Jun 2011 00:14:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-40-4e082dc02db0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.B8.20773.0CD280E4; Mon, 27 Jun 2011 09:14:09 +0200 (CEST) Received: from [131.160.36.20] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 27 Jun 2011 09:14:07 +0200 Message-ID: <4E082DBF.4080904@ericsson.com> Date: Mon, 27 Jun 2011 10:14:07 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ben Campbell References: <21026437C2BC0D45BE196CB0A35EFEFD0686370D@ex2-del1.synapse.com> <6556D034-FE56-46CF-B87C-340615AC5F61@ag-projects.com> <21026437C2BC0D45BE196CB0A35EFEFD06863775@ex2-del1.synapse.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Umang Singh , "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:14:12 -0000 Hi, exactly. As Ben said, that RFC does not describe requirements SBCs need to meet. Instead, it describes functions that can be commonly found in SIP deployments. The "requirements" in the RFC are requirements on SIP to support those functions in ways that do not break things. Cheers, Gonzalo On 07/06/2011 9:16 PM, Ben Campbell wrote: > (As individual) > > On Jun 7, 2011, at 11:25 AM, Umang Singh wrote: > >> Hi, >> Requirements from SBC are defined in an IETF spec (http://tools.ietf.org/html/rfc5853). Topology hiding and media anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I think we should accept the presence and proliferation of SBCs and not call them an anomaly as it is specified in an IETF specification. >> > > I think that RFC5853 is badly named. It doesn't define requirements in the sense of protocol or standards requirements. It's more of a collection of common behaviors of SBCs. Note that it is an informational RFC, not a standards track one. > > Or more to the point, nothing in RFC 5853 should be taken to recommend or condone SBC behavior, other than places where it may suggest solutions to certain problems that might be more friendly to the SIP architecture. > >> The reasons for not mandating a fallback which in turn would mean adding the MSRP B2BUA functionality in a SBC is that SBC could anchor media by just functioning as a TCP/IP relay just as it does for RTP traffic. The difference with MSRP is that MSRP packets contain MSRP URIs exchanged in signaling and matching of MSRP session to TCP connection is done on the basis of that. For a node like the SBC, functioning as a MSRP B2BUA has a huge performance overhead as compared to functioning as a TCP/IP relay. As the draft in question discusses possibilities of making MSRP work with such ALGs/SBCs in the path, I think this point is worthy of discussion. >> >> Regards, >> Umang >> >> -----Original Message----- >> From: Saúl Ibarra Corretgé [mailto:saul@ag-projects.com] >> Sent: Tuesday, June 07, 2011 6:01 PM >> To: Umang Singh >> Cc: simple@ietf.org >> Subject: Re: [Simple] Sessmatch - an alternative approach >> >> Hi, >> >> On Jun 7, 2011, at 2:02 PM, Umang Singh wrote: >> >>> Hi Christer, >>> What about the scenario where 2 RFC 4975 compliant UA's try to establish >>> MSRP session on the basis of a=path with an ALG(more specifically SBC) >>> in the path? As SBC won't modify the a=path, the UA's can bypass the SBC >>> in the media path. Media anchoring would not work in this case. The >>> assumption that a firewall will drop any traffic not directed to the ALG >>> might not be a valid one specially if both the UA's are in the same >>> network. >>> >>> Also, one of the basic functions of the SBC is topology hiding which >>> will not be done on the a=path attribute. >>> >> >> Is there any document/draft/spec where SBC recommended or mandatory features are listed? >> >> >>> I don't agree with mandating the fallback mechanism either. Apart from >>> performance, another valid reason for not implementing the MSRP B2BUA >>> functionality in SBC's is the cost associated with the same. >>> >> >> Cost can't justify breaking an IETF protocol. What is your suggestion, just not having a fallback mechanism? >> >> -- >> Saúl Ibarra Corretgé >> AG Projects >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From gonzalo.camarillo@ericsson.com Mon Jun 27 00:24:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FE221F860E for ; Mon, 27 Jun 2011 00:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sgLj6dH+5fE for ; Mon, 27 Jun 2011 00:24:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D64F821F85DD for ; Mon, 27 Jun 2011 00:24:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d3-4e083034aafa Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.7A.20773.430380E4; Mon, 27 Jun 2011 09:24:37 +0200 (CEST) Received: from [131.160.36.20] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 27 Jun 2011 09:24:36 +0200 Message-ID: <4E083034.1040904@ericsson.com> Date: Mon, 27 Jun 2011 10:24:36 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <4DF2B5AA.5030202@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:24:38 -0000 Hi Hadriel, > The distinction I'm trying to point out is not Proxy vs. B2BUA vs. > something in between, but rather that they're not "ALGs". An "ALG" > is a function performed transparently - i.e., by an inline device > such as in a Router. The SIP messages aren't addressed to it even at > the IP layer, and the TCP connection is not actually terminated at > the ALG. For example an FTP ALG: the FTP ALG in a NAT only "works" > because all packets between the two happen to cross it due to IP > routing, and FTP is in cleartext. If IP routing changes to route > around the ALG, or were FTP to run over TLS, the ALG would not work. > > I'm fairly positive that an "ALG" is not the type of device the > seesmatch draft is trying to support. I agree with you the use of the term ALG in the draft is confusing. I actually made the same comment to the authors a while ago because the first time I read the draft, I made the same interpretation as you did (i.e., ALG are not explicitly addressed). I agree the draft should be clear when describing how addressing works. Cheers, Gonzalo From christer.holmberg@ericsson.com Mon Jun 27 02:16:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FD421F8676 for ; Mon, 27 Jun 2011 02:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcVh-89-lex9 for ; Mon, 27 Jun 2011 02:16:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 35EFB21F8674 for ; Mon, 27 Jun 2011 02:16:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a8-4e084a558b1b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A0.FF.20773.55A480E4; Mon, 27 Jun 2011 11:16:05 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 27 Jun 2011 11:16:04 +0200 From: Christer Holmberg To: Gonzalo Camarillo , Hadriel Kaplan Date: Mon, 27 Jun 2011 11:16:04 +0200 Thread-Topic: [Simple] terminology - B2BUA / SBC / ALG / "other" Thread-Index: Acw0m0l5K/ZFSUPwSF+fa3OHsAa1aQAD3CJg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB61820C6@ESESSCMS0356.eemea.ericsson.se> References: <50DBFCDF-7B29-437A-BFEA-A4BC8DF03E79@acmepacket.com> <4DF2B5AA.5030202@cisco.com> <4E083034.1040904@ericsson.com> In-Reply-To: <4E083034.1040904@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Paul Kyzivat , "simple@ietf.org" Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 09:16:07 -0000 Hi, In the latest version (-13) we talk about "middleboxes" instead, and we hav= e also added clarification/definition text. Regards, Christer=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Gonzalo Camarillo Sent: 27. kes=E4kuuta 2011 10:25 To: Hadriel Kaplan Cc: Paul Kyzivat; simple@ietf.org Subject: Re: [Simple] terminology - B2BUA / SBC / ALG / "other" Hi Hadriel, > The distinction I'm trying to point out is not Proxy vs. B2BUA vs. > something in between, but rather that they're not "ALGs". An "ALG" > is a function performed transparently - i.e., by an inline device such=20 > as in a Router. The SIP messages aren't addressed to it even at the=20 > IP layer, and the TCP connection is not actually terminated at the=20 > ALG. For example an FTP ALG: the FTP ALG in a NAT only "works" > because all packets between the two happen to cross it due to IP=20 > routing, and FTP is in cleartext. If IP routing changes to route=20 > around the ALG, or were FTP to run over TLS, the ALG would not work. >=20 > I'm fairly positive that an "ALG" is not the type of device the=20 > seesmatch draft is trying to support. I agree with you the use of the term ALG in the draft is confusing. I actua= lly made the same comment to the authors a while ago because the first time= I read the draft, I made the same interpretation as you did (i.e., ALG are= not explicitly addressed). I agree the draft should be clear when describing how addressing works. Cheers, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From R.Jesske@telekom.de Mon Jun 27 02:27:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9721F8681 for ; Mon, 27 Jun 2011 02:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4KEgmPFvA7t for ; Mon, 27 Jun 2011 02:27:57 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 62CBB21F867E for ; Mon, 27 Jun 2011 02:27:57 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jun 2011 11:27:30 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by he110890 ([10.134.92.131]) with mapi; Mon, 27 Jun 2011 11:27:00 +0200 From: To: , Date: Mon, 27 Jun 2011 11:26:57 +0200 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acwynxr/PdulHJISToucApeAXXnVhgCDNoAQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> In-Reply-To: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 09:27:58 -0000 Hi, Yes I think that is the right direction to go. Roland > -----Urspr=FCngliche Nachricht----- > Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > Im Auftrag von Ben Campbell > Gesendet: Freitag, 24. Juni 2011 20:45 > An: Simple WG > Betreff: [Simple] Consensus Call on sessmatch-13 > > (as chair) > > Hi, > > The latest version of the sessmatch draft ( > draft-ietf-simple-msrp-sessmatch-13) is a significant change > of direction from older version. The essential difference is > that the new version involves compliant endpoints using the > SDP m and c lines to establish TCP connections, rather than > the previous approach of making clients more resilient to a > middlebox changing an MSRP URI in the a=3Dpath attribute. The > draft refers to this new approach as CEMA. > > Do people thinks this is the right direction to take this > work? I'm not asking if the draft is perfect and ready to > go--we certainly expect discussion and potential changes in > the details. The point is to decide if we should move forward > with the CEMA approach instead of the previous sessmatch approach. > > (In a perfect world, we probably would put CEMA in a separate > draft so the two could be compared. But unless people > strongly object, I think we can still compare the approaches > with the current draft structure.) > > Please send opinions and comments to the SIMPLE list no later > than 11 July 2011. Sooner is better. (This is probably longer > than we need, but I know we're into prime vacation time for a > number of people, including myself. I've allotted extra time > in hopes of getting more comments) > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From HKaplan@acmepacket.com Mon Jun 27 09:27:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C719C11E811A for ; Mon, 27 Jun 2011 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWdQ-Ot-bmgN for ; Mon, 27 Jun 2011 09:27:16 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1E22A11E80DB for ; Mon, 27 Jun 2011 09:27:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 27 Jun 2011 12:27:10 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Mon, 27 Jun 2011 12:27:11 -0400 From: Hadriel Kaplan To: " " Date: Mon, 27 Jun 2011 12:27:09 -0400 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw05xAfa4SvqjP+TBikiHAOlAz0uA== Message-ID: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "simple@ietf.org" Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:27:17 -0000 +1 On Jun 27, 2011, at 5:26 AM, wr= ote: > Hi, > Yes I think that is the right direction to go. >=20 > Roland >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] >> Im Auftrag von Ben Campbell >> Gesendet: Freitag, 24. Juni 2011 20:45 >> An: Simple WG >> Betreff: [Simple] Consensus Call on sessmatch-13 >>=20 >> (as chair) >>=20 >> Hi, >>=20 >> The latest version of the sessmatch draft ( >> draft-ietf-simple-msrp-sessmatch-13) is a significant change >> of direction from older version. The essential difference is >> that the new version involves compliant endpoints using the >> SDP m and c lines to establish TCP connections, rather than >> the previous approach of making clients more resilient to a >> middlebox changing an MSRP URI in the a=3Dpath attribute. The >> draft refers to this new approach as CEMA. >>=20 >> Do people thinks this is the right direction to take this >> work? I'm not asking if the draft is perfect and ready to >> go--we certainly expect discussion and potential changes in >> the details. The point is to decide if we should move forward >> with the CEMA approach instead of the previous sessmatch approach. >>=20 >> (In a perfect world, we probably would put CEMA in a separate >> draft so the two could be compared. But unless people >> strongly object, I think we can still compare the approaches >> with the current draft structure.) >>=20 >> Please send opinions and comments to the SIMPLE list no later >> than 11 July 2011. Sooner is better. (This is probably longer >> than we need, but I know we're into prime vacation time for a >> number of people, including myself. I've allotted extra time >> in hopes of getting more comments) >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From nancy.greene@ericsson.com Mon Jun 27 09:32:16 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37F511E8124 for ; Mon, 27 Jun 2011 09:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZWRHhivUt8d for ; Mon, 27 Jun 2011 09:32:16 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id EECC911E80C7 for ; Mon, 27 Jun 2011 09:32:15 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5RGWFqR017879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jun 2011 11:32:15 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 27 Jun 2011 12:32:14 -0400 From: Nancy Greene To: "simple@ietf.org" Date: Mon, 27 Jun 2011 12:32:14 -0400 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw05xAfa4SvqjP+TBikiHAOlAz0uAAAIvpg Message-ID: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:32:16 -0000 I also support sessmatch-13 Nancy=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Hadriel Kaplan Sent: June-27-11 12:27 PM To: Cc: simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 +1 On Jun 27, 2011, at 5:26 AM, wr= ote: > Hi, > Yes I think that is the right direction to go. >=20 > Roland >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im=20 >> Auftrag von Ben Campbell >> Gesendet: Freitag, 24. Juni 2011 20:45 >> An: Simple WG >> Betreff: [Simple] Consensus Call on sessmatch-13 >>=20 >> (as chair) >>=20 >> Hi, >>=20 >> The latest version of the sessmatch draft ( >> draft-ietf-simple-msrp-sessmatch-13) is a significant change of=20 >> direction from older version. The essential difference is that the=20 >> new version involves compliant endpoints using the SDP m and c lines=20 >> to establish TCP connections, rather than the previous approach of=20 >> making clients more resilient to a middlebox changing an MSRP URI in=20 >> the a=3Dpath attribute. The draft refers to this new approach as CEMA. >>=20 >> Do people thinks this is the right direction to take this work? I'm=20 >> not asking if the draft is perfect and ready to go--we certainly=20 >> expect discussion and potential changes in the details. The point is=20 >> to decide if we should move forward with the CEMA approach instead of=20 >> the previous sessmatch approach. >>=20 >> (In a perfect world, we probably would put CEMA in a separate draft=20 >> so the two could be compared. But unless people strongly object, I=20 >> think we can still compare the approaches with the current draft=20 >> structure.) >>=20 >> Please send opinions and comments to the SIMPLE list no later than 11=20 >> July 2011. Sooner is better. (This is probably longer than we need,=20 >> but I know we're into prime vacation time for a number of people,=20 >> including myself. I've allotted extra time in hopes of getting more=20 >> comments) >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From md3135@att.com Mon Jun 27 09:33:03 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259821F8595 for ; Mon, 27 Jun 2011 09:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cUQBA6yeFf6 for ; Mon, 27 Jun 2011 09:33:02 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 559B211E80C7 for ; Mon, 27 Jun 2011 09:32:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1309192378!17593019!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17209 invoked from network); 27 Jun 2011 16:32:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jun 2011 16:32:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5RGVoNC026376 for ; Mon, 27 Jun 2011 12:31:50 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5RGVkWs026279 for ; Mon, 27 Jun 2011 12:31:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2011 12:32:52 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw05xAfa4SvqjP+TBikiHAOlAz0uAAAIvpgAAAPKiA= References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com><580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> From: "DOLLY, MARTIN C (ATTSI)" To: "Nancy Greene" , Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:33:03 -0000 +1 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Nancy Greene Sent: Monday, June 27, 2011 12:32 PM To: simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 I also support sessmatch-13 Nancy=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Hadriel Kaplan Sent: June-27-11 12:27 PM To: Cc: simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 +1 On Jun 27, 2011, at 5:26 AM, = wrote: > Hi, > Yes I think that is the right direction to go. >=20 > Roland >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im=20 >> Auftrag von Ben Campbell >> Gesendet: Freitag, 24. Juni 2011 20:45 >> An: Simple WG >> Betreff: [Simple] Consensus Call on sessmatch-13 >>=20 >> (as chair) >>=20 >> Hi, >>=20 >> The latest version of the sessmatch draft ( >> draft-ietf-simple-msrp-sessmatch-13) is a significant change of=20 >> direction from older version. The essential difference is that the=20 >> new version involves compliant endpoints using the SDP m and c lines=20 >> to establish TCP connections, rather than the previous approach of=20 >> making clients more resilient to a middlebox changing an MSRP URI in=20 >> the a=3Dpath attribute. The draft refers to this new approach as = CEMA. >>=20 >> Do people thinks this is the right direction to take this work? I'm=20 >> not asking if the draft is perfect and ready to go--we certainly=20 >> expect discussion and potential changes in the details. The point is=20 >> to decide if we should move forward with the CEMA approach instead of = >> the previous sessmatch approach. >>=20 >> (In a perfect world, we probably would put CEMA in a separate draft=20 >> so the two could be compared. But unless people strongly object, I=20 >> think we can still compare the approaches with the current draft=20 >> structure.) >>=20 >> Please send opinions and comments to the SIMPLE list no later than 11 = >> July 2011. Sooner is better. (This is probably longer than we need,=20 >> but I know we're into prime vacation time for a number of people,=20 >> including myself. I've allotted extra time in hopes of getting more=20 >> comments) >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From atle.monrad@ericsson.com Tue Jun 28 04:01:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4508611E8103 for ; Tue, 28 Jun 2011 04:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cppaiWQaHOD for ; Tue, 28 Jun 2011 04:01:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5627211E8077 for ; Tue, 28 Jun 2011 04:01:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e2-4e09b46bd850 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 11.5E.20773.B64B90E4; Tue, 28 Jun 2011 13:00:59 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.179]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 28 Jun 2011 13:00:58 +0200 From: Atle Monrad To: "simple@ietf.org" Date: Tue, 28 Jun 2011 13:00:57 +0200 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw05xAfa4SvqjP+TBikiHAOlAz0uAAAIvpgAAAPKiAAJKrBgA== Message-ID: <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com><580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 11:01:01 -0000 +1 from me aswell Thanks to Ben for a constructive proposal ! /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= DOLLY, MARTIN C (ATTSI) Sent: 28. juni 2011 00:33 To: Nancy Greene; simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 +1 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Nancy Greene Sent: Monday, June 27, 2011 12:32 PM To: simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 I also support sessmatch-13 Nancy=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Hadriel Kaplan Sent: June-27-11 12:27 PM To: Cc: simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 +1 On Jun 27, 2011, at 5:26 AM, wr= ote: > Hi, > Yes I think that is the right direction to go. >=20 > Roland >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im=20 >> Auftrag von Ben Campbell >> Gesendet: Freitag, 24. Juni 2011 20:45 >> An: Simple WG >> Betreff: [Simple] Consensus Call on sessmatch-13 >>=20 >> (as chair) >>=20 >> Hi, >>=20 >> The latest version of the sessmatch draft ( >> draft-ietf-simple-msrp-sessmatch-13) is a significant change of=20 >> direction from older version. The essential difference is that the=20 >> new version involves compliant endpoints using the SDP m and c lines=20 >> to establish TCP connections, rather than the previous approach of=20 >> making clients more resilient to a middlebox changing an MSRP URI in=20 >> the a=3Dpath attribute. The draft refers to this new approach as CEMA. >>=20 >> Do people thinks this is the right direction to take this work? I'm=20 >> not asking if the draft is perfect and ready to go--we certainly=20 >> expect discussion and potential changes in the details. The point is=20 >> to decide if we should move forward with the CEMA approach instead of=20 >> the previous sessmatch approach. >>=20 >> (In a perfect world, we probably would put CEMA in a separate draft=20 >> so the two could be compared. But unless people strongly object, I=20 >> think we can still compare the approaches with the current draft >> structure.) >>=20 >> Please send opinions and comments to the SIMPLE list no later than 11=20 >> July 2011. Sooner is better. (This is probably longer than we need,=20 >> but I know we're into prime vacation time for a number of people,=20 >> including myself. I've allotted extra time in hopes of getting more >> comments) >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From laura.liess.dt@googlemail.com Tue Jun 28 06:52:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A451821F8609 for ; Tue, 28 Jun 2011 06:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwk0ZKR4LUfT for ; Tue, 28 Jun 2011 06:52:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1721F8606 for ; Tue, 28 Jun 2011 06:52:33 -0700 (PDT) Received: by vws12 with SMTP id 12so196409vws.31 for ; Tue, 28 Jun 2011 06:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=vskJmu7HV7Frwqovazavm4RzDuAC09zwvJ2YrmyZIuM=; b=SyvCVAuIH0lkF/KCRcWBZH80x9s2fdw84tk8NdPLiPc5Zw3vUKRbMjWE0RLCtgyDHs kyB/zXQVbEkP9DZ3l6Tbv8dMvYJVLQ1gh5GtPPtXj7J8joCOypiGAQlsPuxKYZ8hmZaw 0n5rI407/taS7vl78ytGpykF9uF3k831gDUrc= MIME-Version: 1.0 Received: by 10.52.177.133 with SMTP id cq5mr5648126vdc.225.1309269152729; Tue, 28 Jun 2011 06:52:32 -0700 (PDT) Received: by 10.52.112.201 with HTTP; Tue, 28 Jun 2011 06:52:32 -0700 (PDT) In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se> Date: Tue, 28 Jun 2011 15:52:32 +0200 Message-ID: From: Laura Liess To: "simple@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:52:34 -0000 I support this draft. Laura > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C (ATTSI) > Sent: 28. juni 2011 00:33 > To: Nancy Greene; simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 > > +1 > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Nancy Greene > Sent: Monday, June 27, 2011 12:32 PM > To: simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 > > I also support sessmatch-13 > > Nancy > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: June-27-11 12:27 PM > To: > Cc: simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 > > > +1 > > > On Jun 27, 2011, at 5:26 AM, = wrote: > >> Hi, >> Yes I think that is the right direction to go. >> >> Roland >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im >>> Auftrag von Ben Campbell >>> Gesendet: Freitag, 24. Juni 2011 20:45 >>> An: Simple WG >>> Betreff: [Simple] Consensus Call on sessmatch-13 >>> >>> (as chair) >>> >>> Hi, >>> >>> The latest version of the sessmatch draft ( >>> draft-ietf-simple-msrp-sessmatch-13) is a significant change of >>> direction from older version. The essential difference is that the >>> new version involves compliant endpoints using the SDP m and c lines >>> to establish TCP connections, rather than the previous approach of >>> making clients more resilient to a middlebox changing an MSRP URI in >>> the a=3Dpath attribute. The draft refers to this new approach as CEMA. >>> >>> Do people thinks this is the right direction to take this work? I'm >>> not asking if the draft is perfect and ready to go--we certainly >>> expect discussion and potential changes in the details. The point is >>> to decide if we should move forward with the CEMA approach instead of >>> the previous sessmatch approach. >>> >>> (In a perfect world, we probably would put CEMA in a separate draft >>> so the two could be compared. But unless people strongly object, I >>> think we can still compare the approaches with the current draft >>> structure.) >>> >>> Please send opinions and comments to the SIMPLE list no later than 11 >>> July 2011. Sooner is better. (This is probably longer than we need, >>> but I know we're into prime vacation time for a number of people, >>> including myself. I've allotted extra time in hopes of getting more >>> comments) >>> >>> Thanks! >>> >>> Ben. >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From victor.pascual.avila@gmail.com Tue Jun 28 09:26:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F5411E8124 for ; Tue, 28 Jun 2011 09:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2rLU6AoUi7l for ; Tue, 28 Jun 2011 09:26:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 194DE11E8114 for ; Tue, 28 Jun 2011 09:26:23 -0700 (PDT) Received: by iwn39 with SMTP id 39so386981iwn.31 for ; Tue, 28 Jun 2011 09:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=gcgZMn1borK3a6B2h0OnCsv8xJsD42fvbcELZaalEpM=; b=YWD1aY6E5dVmiLOVP8fWvChVjDoORV5OAFHcy+lYVS8zNKfpsLFb7sdA2zg8r/549Z yOhIUNhLwzSfQM6amOCZB711V/fbUfyeMTRI3dzQ0vOx9lTOCxE7yBYbPShC24he+SZX sZzW825gN6X3Xoplts785Ox/AwpOInlY7QjLo= MIME-Version: 1.0 Received: by 10.231.74.7 with SMTP id s7mr7170800ibj.172.1309278382329; Tue, 28 Jun 2011 09:26:22 -0700 (PDT) Received: by 10.231.33.76 with HTTP; Tue, 28 Jun 2011 09:26:22 -0700 (PDT) In-Reply-To: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se> Date: Tue, 28 Jun 2011 18:26:22 +0200 Message-ID: From: Victor Pascual Avila To: "simple@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:26:24 -0000 +1 On Tue, Jun 28, 2011 at 3:52 PM, Laura Liess wrote: > I support this draft. > > Laura > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf= Of DOLLY, MARTIN C (ATTSI) >> Sent: 28. juni 2011 00:33 >> To: Nancy Greene; simple@ietf.org >> Subject: Re: [Simple] Consensus Call on sessmatch-13 >> >> +1 >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf= Of Nancy Greene >> Sent: Monday, June 27, 2011 12:32 PM >> To: simple@ietf.org >> Subject: Re: [Simple] Consensus Call on sessmatch-13 >> >> I also support sessmatch-13 >> >> Nancy >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf= Of Hadriel Kaplan >> Sent: June-27-11 12:27 PM >> To: >> Cc: simple@ietf.org >> Subject: Re: [Simple] Consensus Call on sessmatch-13 >> >> >> +1 >> >> >> On Jun 27, 2011, at 5:26 AM, = wrote: >> >>> Hi, >>> Yes I think that is the right direction to go. >>> >>> Roland >>> >>> >>>> -----Urspr=C3=BCngliche Nachricht----- >>>> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im >>>> Auftrag von Ben Campbell >>>> Gesendet: Freitag, 24. Juni 2011 20:45 >>>> An: Simple WG >>>> Betreff: [Simple] Consensus Call on sessmatch-13 >>>> >>>> (as chair) >>>> >>>> Hi, >>>> >>>> The latest version of the sessmatch draft ( >>>> draft-ietf-simple-msrp-sessmatch-13) is a significant change of >>>> direction from older version. The essential difference is that the >>>> new version involves compliant endpoints using the SDP m and c lines >>>> to establish TCP connections, rather than the previous approach of >>>> making clients more resilient to a middlebox changing an MSRP URI in >>>> the a=3Dpath attribute. The draft refers to this new approach as CEMA. >>>> >>>> Do people thinks this is the right direction to take this work? I'm >>>> not asking if the draft is perfect and ready to go--we certainly >>>> expect discussion and potential changes in the details. The point is >>>> to decide if we should move forward with the CEMA approach instead of >>>> the previous sessmatch approach. >>>> >>>> (In a perfect world, we probably would put CEMA in a separate draft >>>> so the two could be compared. But unless people strongly object, I >>>> think we can still compare the approaches with the current draft >>>> structure.) >>>> >>>> Please send opinions and comments to the SIMPLE list no later than 11 >>>> July 2011. Sooner is better. (This is probably longer than we need, >>>> but I know we're into prime vacation time for a number of people, >>>> including myself. I've allotted extra time in hopes of getting more >>>> comments) >>>> >>>> Thanks! >>>> >>>> Ben. >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --=20 Victor Pascual =C3=81vila From saul@ag-projects.com Wed Jun 29 00:55:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04221F8671 for ; Wed, 29 Jun 2011 00:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDiNMQ-bBYOO for ; Wed, 29 Jun 2011 00:55:34 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B98AD21F8669 for ; Wed, 29 Jun 2011 00:55:31 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 58303B01B1; Wed, 29 Jun 2011 09:48:58 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 666CAB0181; Wed, 29 Jun 2011 09:48:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> Date: Wed, 29 Jun 2011 09:48:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:55:35 -0000 On Jun 24, 2011, at 8:45 PM, Ben Campbell wrote: > (as chair) >=20 > Hi, >=20 > The latest version of the sessmatch draft ( = draft-ietf-simple-msrp-sessmatch-13) is a significant change of = direction from older version. The essential difference is that the new = version involves compliant endpoints using the SDP m and c lines to = establish TCP connections, rather than the previous approach of making = clients more resilient to a middlebox changing an MSRP URI in the a=3Dpath= attribute. The draft refers to this new approach as CEMA. >=20 > Do people thinks this is the right direction to take this work? I'm = not asking if the draft is perfect and ready to go--we certainly expect = discussion and potential changes in the details. The point is to decide = if we should move forward with the CEMA approach instead of the previous = sessmatch approach. >=20 > (In a perfect world, we probably would put CEMA in a separate draft so = the two could be compared. But unless people strongly object, I think we = can still compare the approaches with the current draft structure.) >=20 > Please send opinions and comments to the SIMPLE list no later than 11 = July 2011. Sooner is better. (This is probably longer than we need, but = I know we're into prime vacation time for a number of people, including = myself. I've allotted extra time in hopes of getting more comments) >=20 Hi, I do like and support the CEMA approach. Small question/comment for Christer: in section 4.3: is it necessary to = mention point 3? Since that is not alloweb as per RFC6135, the offer = should be rejected, right? I'd remove point 3 and extend the note to = mention that "if the SDP offer contains a a=3Dsetup:passive attribute = the request MUST be rejected". Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From HKaplan@acmepacket.com Wed Jun 29 09:00:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD42711E809B for ; Wed, 29 Jun 2011 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arZq7YEClYfc for ; Wed, 29 Jun 2011 09:00:11 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4027C11E808E for ; Wed, 29 Jun 2011 09:00:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 29 Jun 2011 11:58:51 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 29 Jun 2011 11:59:47 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 29 Jun 2011 11:59:46 -0400 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw2dZERrJofKh06RpiGLxqt3qUQjw== Message-ID: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:00:13 -0000 On Jun 29, 2011, at 3:48 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Small question/comment for Christer: in section 4.3: is it necessary to m= ention point 3? Since that is not alloweb as per RFC6135, the offer should = be rejected, right? I'd remove point 3 and extend the note to mention that = "if the SDP offer contains a a=3Dsetup:passive attribute the request MUST b= e rejected". I don't think so... because the middlebox will likely set it to be that in = the offer/answer before it sends it to the UA behind a NAT (to force the UA= to open the TCP connection to the middlebox). -hadriel From saul@ag-projects.com Wed Jun 29 23:55:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A4E11E80E1 for ; Wed, 29 Jun 2011 23:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQdTM9onrVr9 for ; Wed, 29 Jun 2011 23:55:48 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAA111E8074 for ; Wed, 29 Jun 2011 23:55:48 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6EA35B0181; Thu, 30 Jun 2011 08:55:47 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id DB7CAB0181; Thu, 30 Jun 2011 08:55:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Thu, 30 Jun 2011 08:55:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 06:55:49 -0000 >=20 > I don't think so... because the middlebox will likely set it to be = that in the offer/answer before it sends it to the UA behind a NAT (to = force the UA to open the TCP connection to the middlebox). >=20 That is plain wrong. The middlebox can't do that. RFC6135 forbids it and = the current draft version (13) does not allow it either, I just = suggested a clarification. See the changelog from draft 12. I've seen middleboxes doing such things to force the recipient to also = become active and then do 'TCP stitching' to bridge both ends. The = correct way of doing it would be putting 'actpass', and leave the = responsibility of deciding if it want to be active or passive to the = recipient. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Thu Jun 30 03:03:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE1921F87DE for ; Thu, 30 Jun 2011 03:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFIqBzt2LUH5 for ; Thu, 30 Jun 2011 03:03:51 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6B221F87D5 for ; Thu, 30 Jun 2011 03:03:50 -0700 (PDT) Received: by qyk29 with SMTP id 29so1525006qyk.10 for ; Thu, 30 Jun 2011 03:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.19 with SMTP id u19mr1334727qct.173.1309428230256; Thu, 30 Jun 2011 03:03:50 -0700 (PDT) Received: by 10.229.240.15 with HTTP; Thu, 30 Jun 2011 03:03:50 -0700 (PDT) In-Reply-To: <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> Date: Thu, 30 Jun 2011 12:03:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:03:52 -0000 2011/6/30 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> I don't think so... because the middlebox will likely set it to be that = in the offer/answer before it sends it to the UA behind a NAT (to force the= UA to open the TCP connection to the middlebox). >> > > That is plain wrong. The middlebox can't do that. RFC6135 forbids it and = the current draft version (13) does not allow it either, I just suggested a= clarification. See the changelog from draft 12. > > I've seen middleboxes doing such things to force the recipient to also be= come active and then do 'TCP stitching' to bridge both ends. The correct wa= y of doing it would be putting 'actpass', and leave the responsibility of d= eciding if it want to be active or passive to the recipient. Fully agree. Any other approach (so what Hadriel says) breaks the protocol. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Thu Jun 30 06:04:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE47D21F868D for ; Thu, 30 Jun 2011 06:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTVrd3sf75Uz for ; Thu, 30 Jun 2011 06:04:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE81521F868C for ; Thu, 30 Jun 2011 06:04:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Jun 2011 09:04:05 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 30 Jun 2011 09:04:05 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Thu, 30 Jun 2011 09:04:04 -0400 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw3JjAeaCdh8W94Qi+RFPWzVv1V7Q== Message-ID: <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> In-Reply-To: <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:04:08 -0000 On Jun 30, 2011, at 2:55 AM, Sa=FAl Ibarra Corretg=E9 wrote: >>=20 >> I don't think so... because the middlebox will likely set it to be that = in the offer/answer before it sends it to the UA behind a NAT (to force the= UA to open the TCP connection to the middlebox). >>=20 >=20 > That is plain wrong. The middlebox can't do that. RFC6135 forbids it and = the current draft version (13) does not allow it either, I just suggested a= clarification. See the changelog from draft 12. >=20 > I've seen middleboxes doing such things to force the recipient to also be= come active and then do 'TCP stitching' to bridge both ends. The correct wa= y of doing it would be putting 'actpass', and leave the responsibility of d= eciding if it want to be active or passive to the recipient. Yup, that's exactly why we do it - to force a UA behind a NAT to become act= ive, and stitch if necessary. It's worked so far, afaik. -hadriel From saul@ag-projects.com Thu Jun 30 06:16:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF811E8070 for ; Thu, 30 Jun 2011 06:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-M+y4L4PEXO for ; Thu, 30 Jun 2011 06:16:33 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id F08BE22800E for ; Thu, 30 Jun 2011 06:16:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E13E7B01BA; Thu, 30 Jun 2011 15:16:31 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 653FCB0181; Thu, 30 Jun 2011 15:16:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> Date: Thu, 30 Jun 2011 15:16:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:16:33 -0000 Hi, >=20 > Yup, that's exactly why we do it - to force a UA behind a NAT to = become active, and stitch if necessary. It's worked so far, afaik. >=20 Well, that's not the right thing to do, for the reasons I stated in my = previous email. Earlier you said you supported this draft, but the way = you use it breaks it. There seems to be an inconsistency here. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Thu Jun 30 07:25:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECA721F857A for ; Thu, 30 Jun 2011 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n7lij4DePEu for ; Thu, 30 Jun 2011 07:25:32 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0821F8579 for ; Thu, 30 Jun 2011 07:25:32 -0700 (PDT) Received: by qyk9 with SMTP id 9so89438qyk.10 for ; Thu, 30 Jun 2011 07:25:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.19 with SMTP id u19mr1536335qct.173.1309443931663; Thu, 30 Jun 2011 07:25:31 -0700 (PDT) Received: by 10.229.240.15 with HTTP; Thu, 30 Jun 2011 07:25:31 -0700 (PDT) In-Reply-To: <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> Date: Thu, 30 Jun 2011 16:25:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:25:33 -0000 2011/6/30 Hadriel Kaplan : >> I've seen middleboxes doing such things to force the recipient to also b= ecome active and then do 'TCP stitching' to bridge both ends. The correct w= ay of doing it would be putting 'actpass', and leave the responsibility of = deciding if it want to be active or passive to the recipient. > > Yup, that's exactly why we do it - to force a UA behind a NAT to become a= ctive, and stitch if necessary. =C2=A0It's worked so far, afaik. It works if you try it in your own environment (wallen warden) with MSRP clients behaving as you desire. But the mechanism you use breaks the standard, do you agree? (you should). That is a "WorksForMe" or "WorksInMyWallenGarden" argument, but it breaks MSRP protocol, so this draft should not cover such case (even if it works for you). Please, respect the MSRP standard ;) --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Thu Jun 30 08:09:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3C11E8185 for ; Thu, 30 Jun 2011 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQORayi8nv+5 for ; Thu, 30 Jun 2011 08:09:56 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1911E817E for ; Thu, 30 Jun 2011 08:09:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 30 Jun 2011 11:09:51 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 30 Jun 2011 11:09:51 -0400 From: Hadriel Kaplan To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Thu, 30 Jun 2011 11:09:45 -0400 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw3N8Js/nwqxASzRxKLzu6tcqfKyA== Message-ID: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFV Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:09:56 -0000 SSBkb24ndCBzZWUgaG93IGl0IGJyZWFrcyBNU1JQLiAgSXQncyBub3QgY29tcGxpYW50IHRvIHRo ZSBtdXN0LCBidXQgdGhlIGFjbSByZmMgZG9lcyBub3QgdGVsbCB0aGUgVUFTIHRvIHJlamVjdCBp dCBub3Igc2hvdWxkIGl0LiAgDQotSGFkcmllbA0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9u IEp1biAzMCwgMjAxMSwgYXQgMTA6MjYgQU0sICJJw7Fha2kgQmF6IENhc3RpbGxvIiA8aWJjQGFs aWF4Lm5ldD4gd3JvdGU6DQoNCj4gMjAxMS82LzMwIEhhZHJpZWwgS2FwbGFuIDxIS2FwbGFuQGFj bWVwYWNrZXQuY29tPjoNCj4+PiBJJ3ZlIHNlZW4gbWlkZGxlYm94ZXMgZG9pbmcgc3VjaCB0aGlu Z3MgdG8gZm9yY2UgdGhlIHJlY2lwaWVudCB0byBhbHNvIGJlY29tZSBhY3RpdmUgYW5kIHRoZW4g ZG8gJ1RDUCBzdGl0Y2hpbmcnIHRvIGJyaWRnZSBib3RoIGVuZHMuIFRoZSBjb3JyZWN0IHdheSBv ZiBkb2luZyBpdCB3b3VsZCBiZSBwdXR0aW5nICdhY3RwYXNzJywgYW5kIGxlYXZlIHRoZSByZXNw b25zaWJpbGl0eSBvZiBkZWNpZGluZyBpZiBpdCB3YW50IHRvIGJlIGFjdGl2ZSBvciBwYXNzaXZl IHRvIHRoZSByZWNpcGllbnQuDQo+PiANCj4+IFl1cCwgdGhhdCdzIGV4YWN0bHkgd2h5IHdlIGRv IGl0IC0gdG8gZm9yY2UgYSBVQSBiZWhpbmQgYSBOQVQgdG8gYmVjb21lIGFjdGl2ZSwgYW5kIHN0 aXRjaCBpZiBuZWNlc3NhcnkuICBJdCdzIHdvcmtlZCBzbyBmYXIsIGFmYWlrLg0KPiANCj4gSXQg d29ya3MgaWYgeW91IHRyeSBpdCBpbiB5b3VyIG93biBlbnZpcm9ubWVudCAod2FsbGVuIHdhcmRl bikgd2l0aA0KPiBNU1JQIGNsaWVudHMgYmVoYXZpbmcgYXMgeW91IGRlc2lyZS4gQnV0IHRoZSBt ZWNoYW5pc20geW91IHVzZSBicmVha3MNCj4gdGhlIHN0YW5kYXJkLCBkbyB5b3UgYWdyZWU/ICh5 b3Ugc2hvdWxkKS4gVGhhdCBpcyBhICJXb3Jrc0Zvck1lIiBvcg0KPiAiV29ya3NJbk15V2FsbGVu R2FyZGVuIiBhcmd1bWVudCwgYnV0IGl0IGJyZWFrcyBNU1JQIHByb3RvY29sLCBzbyB0aGlzDQo+ IGRyYWZ0IHNob3VsZCBub3QgY292ZXIgc3VjaCBjYXNlIChldmVuIGlmIGl0IHdvcmtzIGZvciB5 b3UpLg0KPiANCj4gUGxlYXNlLCByZXNwZWN0IHRoZSBNU1JQIHN0YW5kYXJkIDspDQo+IA0KPiAN Cj4gLS0gDQo+IEnDsWFraSBCYXogQ2FzdGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo= From saul@ag-projects.com Thu Jun 30 08:18:54 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FD321F85A6 for ; Thu, 30 Jun 2011 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt2Vb3RzWv7Q for ; Thu, 30 Jun 2011 08:18:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC6621F859B for ; Thu, 30 Jun 2011 08:18:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 51B62B01BA; Thu, 30 Jun 2011 17:18:49 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id B3C40B017C; Thu, 30 Jun 2011 17:18:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Thu, 30 Jun 2011 17:18:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DBB8711-D171-4DE2-A08E-A73AA1935F78@ag-projects.com> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:18:54 -0000 > I don't see how it breaks MSRP. It's not compliant to the must, but = the acm rfc does not tell the UAS to reject it nor should it. =20 > -Hadriel >=20 =46rom RFC6135: "The UA MUST NOT use the a=3Dsetup "passive" attribute value in an SDP offer." As a UA what am I supposed to do if I get such a request? RFC says it = MUST never happen, so rejecting it is the best an endpoint can do. It breaks MSRP in the sense that implementations compliant with RFC6135 = will most likely reject such requests as they don't comply to the = standard. What really puzzles me is the fact that you support this draft but at = the same time "It's not compliant to the must". If everyone would do = that there is no point in putting MAY, MUST, SHOUD or whatever on an = RFC. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Thu Jun 30 08:24:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D48A11E81FC for ; Thu, 30 Jun 2011 08:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PewT+SRhusNI for ; Thu, 30 Jun 2011 08:24:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52AA211E81FA for ; Thu, 30 Jun 2011 08:24:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so1925460qwc.31 for ; Thu, 30 Jun 2011 08:24:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.23.69 with SMTP id q5mr1583060qcb.249.1309447479779; Thu, 30 Jun 2011 08:24:39 -0700 (PDT) Received: by 10.229.240.15 with HTTP; Thu, 30 Jun 2011 08:24:39 -0700 (PDT) In-Reply-To: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> Date: Thu, 30 Jun 2011 17:24:39 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:24:43 -0000 2011/6/30 Hadriel Kaplan : > I don't see how it breaks MSRP. =C2=A0It's not compliant to the must So which is your exact understanding for "MUST" keyword in a RFC?? You cannot say that you support this draft and at the same time break the MSRP protocol with your non compliant impelmentation. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Thu Jun 30 09:02:48 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A06911E8186 for ; Thu, 30 Jun 2011 09:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkLKSO9Vyugn for ; Thu, 30 Jun 2011 09:02:47 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB05F228018 for ; Thu, 30 Jun 2011 09:02:47 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 30 Jun 2011 12:02:47 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 30 Jun 2011 12:02:46 -0400 From: Hadriel Kaplan To: =?utf-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?= Date: Thu, 30 Jun 2011 12:02:40 -0400 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw3PycFeEE89IAXRxumARG/+TGxzw== Message-ID: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> <1DBB8711-D171-4DE2-A08E-A73AA1935F78@ag-projects.com> In-Reply-To: <1DBB8711-D171-4DE2-A08E-A73AA1935F78@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:02:48 -0000 Rmlyc3QsIGl0IGlzIG5vdCB0aGUgcm9sZSBvZiBhIFVBIHRvIHBvbGljZSB0aGUgUkZDLiAgSW4g ZmFjdCwgdGhlIElFVEYgZ2VuZXJhbGx5IGV4cGVjdHMgZGV2aWNlcyB0byBiZSBzdHJpY3Qgb24g c2VuZCBidXQgbGliZXJhbCBvbiByZWNlaXB0LiAgU2Vjb25kLCB0aGUgQWNtIHJmYyBzYXlzIGRl dmljZXMgbXVzdCBzdXBwb3J0IHBhc3NpdmUgKHRob3VnaCBpdCBkb2Vzbid0IHNheSB3aGVuKS4g IFRoZXJlJ3Mgbm8gcmVhbCByZWFzb24gdG8gcmVqZWN0IHN1Y2ggYW4gb2ZmZXIgaXMgdGhlcmU/ ICBBbnN3ZXIgaXQgd2l0aCBhY3RpdmUsIGFzIHBlciB0aGUgcmZjIGZvciBzZXR1cCBhdHRyaWJ1 dGUuDQoNCkhvdyBhYm91dCB3ZSBwdXQgYSBsaW5lIHNheWluZyBhIFVBUyBzaG91bGQgYWNjZXB0 IGEgcGFzc2l2ZSBvZmZlciB3aXRoIGFjdGl2ZT8NCg0KLUhhZHJpZWwNCg0KU2VudCBmcm9tIG15 IGlQaG9uZQ0KDQpPbiBKdW4gMzAsIDIwMTEsIGF0IDExOjE5IEFNLCAiU2HDumwgSWJhcnJhIENv cnJldGfDqSIgPHNhdWxAYWctcHJvamVjdHMuY29tPiB3cm90ZToNCg0KPiANCj4+IEkgZG9uJ3Qg c2VlIGhvdyBpdCBicmVha3MgTVNSUC4gIEl0J3Mgbm90IGNvbXBsaWFudCB0byB0aGUgbXVzdCwg YnV0IHRoZSBhY20gcmZjIGRvZXMgbm90IHRlbGwgdGhlIFVBUyB0byByZWplY3QgaXQgbm9yIHNo b3VsZCBpdC4gIA0KPj4gLUhhZHJpZWwNCj4+IA0KPiANCj4gRnJvbSBSRkM2MTM1Og0KPiANCj4g IlRoZSBVQSBNVVNUIE5PVCB1c2UgdGhlIGE9c2V0dXAgInBhc3NpdmUiIGF0dHJpYnV0ZSB2YWx1 ZSBpbiBhbiBTRFANCj4gICBvZmZlci4iDQo+IA0KPiBBcyBhIFVBIHdoYXQgYW0gSSBzdXBwb3Nl ZCB0byBkbyBpZiBJIGdldCBzdWNoIGEgcmVxdWVzdD8gUkZDIHNheXMgaXQgTVVTVCBuZXZlciBo YXBwZW4sIHNvIHJlamVjdGluZyBpdCBpcyB0aGUgYmVzdCBhbiBlbmRwb2ludCBjYW4gZG8uDQo+ IA0KPiBJdCBicmVha3MgTVNSUCBpbiB0aGUgc2Vuc2UgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY29t cGxpYW50IHdpdGggUkZDNjEzNSB3aWxsIG1vc3QgbGlrZWx5IHJlamVjdCBzdWNoIHJlcXVlc3Rz IGFzIHRoZXkgZG9uJ3QgY29tcGx5IHRvIHRoZSBzdGFuZGFyZC4NCj4gDQo+IFdoYXQgcmVhbGx5 IHB1enpsZXMgbWUgaXMgdGhlIGZhY3QgdGhhdCB5b3Ugc3VwcG9ydCB0aGlzIGRyYWZ0IGJ1dCBh dCB0aGUgc2FtZSB0aW1lICJJdCdzIG5vdCBjb21wbGlhbnQgdG8gdGhlIG11c3QiLiBJZiBldmVy eW9uZSB3b3VsZCBkbyB0aGF0IHRoZXJlIGlzIG5vIHBvaW50IGluIHB1dHRpbmcgTUFZLCBNVVNU LCBTSE9VRCBvciB3aGF0ZXZlciBvbiBhbiBSRkMuDQo+IA0KPiANCj4gLS0NCj4gU2HDumwgSWJh cnJhIENvcnJldGfDqQ0KPiBBRyBQcm9qZWN0cw0KPiANCj4gDQo+IA0K From saul@ag-projects.com Thu Jun 30 09:18:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A9A11E8233 for ; Thu, 30 Jun 2011 09:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shZR2iI1reSc for ; Thu, 30 Jun 2011 09:18:01 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BE6FA11E8228 for ; Thu, 30 Jun 2011 09:18:00 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D13D5B01B9; Thu, 30 Jun 2011 18:17:59 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id ADD96B0181; Thu, 30 Jun 2011 18:17:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Thu, 30 Jun 2011 18:17:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> <1DBB8711-D171-4DE2-A08E-A73AA1935F78@ag-projects.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:18:01 -0000 Hi, On Jun 30, 2011, at 6:02 PM, Hadriel Kaplan wrote: > First, it is not the role of a UA to police the RFC. In fact, the = IETF generally expects devices to be strict on send but liberal on = receipt. Second, the Acm rfc says devices must support passive (though = it doesn't say when). There's no real reason to reject such an offer is = there? Answer it with active, as per the rfc for setup attribute. >=20 It's mentioned as a MUST I'm not sure about how 'flexible' an = implementation should be in that matter. > How about we put a line saying a UAS should accept a passive offer = with active? >=20 I see no need for changing what RFC6135 says. What about something like: = "MSRP endpoints supporting this specification MUST become active upon = receiving an offer with 'actpass' " Would that be reasonable for you? -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Thu Jun 30 09:18:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C28511E8229 for ; Thu, 30 Jun 2011 09:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEdwp7qe3Reg for ; Thu, 30 Jun 2011 09:18:38 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB89E11E821A for ; Thu, 30 Jun 2011 09:18:38 -0700 (PDT) Received: by qyk9 with SMTP id 9so167491qyk.10 for ; Thu, 30 Jun 2011 09:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.23.69 with SMTP id q5mr1638215qcb.249.1309450718000; Thu, 30 Jun 2011 09:18:38 -0700 (PDT) Received: by 10.229.240.15 with HTTP; Thu, 30 Jun 2011 09:18:37 -0700 (PDT) In-Reply-To: References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> <1DBB8711-D171-4DE2-A08E-A73AA1935F78@ag-projects.com> Date: Thu, 30 Jun 2011 18:18:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Consensus Call on sessmatch-13 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:18:39 -0000 2011/6/30 Sa=C3=BAl Ibarra Corretg=C3=A9 : > I see no need for changing what RFC6135 says. What about something like: = "MSRP endpoints supporting this specification MUST become active upon recei= ving an offer with 'actpass' " Would that be reasonable for you? This should be the way to go. --=20 I=C3=B1aki Baz Castillo